[Telepathy] Spec meeting notes on SASL authentication and SSL cert verification

[mikhail.zabaluev at nokia.com]

Hi,

> -----Original Message-----
> From: telepathy-bounces at lists.freedesktop.org [mailto:telepathy-
> bounces at lists.freedesktop.org] On Behalf Of ext Eitan Isaacson
> Sent: Thursday, March 11, 2010 12:04 AM
> To: Will Thompson
> Cc: telepathy at lists.freedesktop.org
> Subject: Re: [Telepathy] Spec meeting notes on SASL authentication and
> SSL cert verification
> 
> Hello folks.
> 
> Recently I was tasked with continuing the work that Dafydd started on
> SASL. The good news is that this allows a more unified approach with
> the
> SSL and other authentication schemes we have been working on,
> specifically XTLS. The bad news is that I scratched a lot of the
> previous work Cosimo and I did in favor of a more symmetric and and
> clean interface (imho, anyway). I think most discussion items that I
> observed have been included in this spec, let me know if not.
> 
> You could see an outline on the wiki page[1], browse the HTML spec[2],
> or checkout my branch[3].
> 
> I don't think the other iterations were a waste of time, on the server
> TLS front I have been maintaining a gabble implementation in lockstep
> to
> the rewrites and I am still sane. I feel like the actual code changes
> required for this are not too big (can't speak for XTLS though).
> 
> First a note about English: Verification and authentication are
> interchangeable. I know this seems obvious, but I just feel like
> pointing it out. In my mind at least - verification is remote
> authentication, meaning we are verifying the remote peer is who she
> says
> she is. So in the new spec I scratched all mentions of verification,
> and
> I have stuck with authentication exclusively while distinguishing
> between remote and local authentication.
> 
> In the old spec we had some weak points and some omissions that are
> critical to SASL:
>  - Variable number of response/challange round trips.
>  - Support for local authentication. the verification interface
> provided
> remote authentication, but the only local authentication we have is
> incomplete and hidden in the IdentityExchange interface.
>  - Simple mechanism negotiation, not necessary, but the current
> NegotiateVerification iface is very complex for SASL needs.
> 
> The new spec has a few benefits, imho:
>  - One channel. Take E2E for example, we used to have 3 consecutive
> channels. Negotiation, verification and certificate exchange. In this
> design there is only one (for better or worse).
>  - Incremental complexity: Take a look at the chatroom example[4] or
> the
> server TLS[5] example. They only require one interface. More complex
> exchanges like E2E[6] use more interfaces.
>  - The Challange/Respond pattern let's us be more flexible about
> different authentication stages, this is how I added certificate
> exchange in to the SRP_BOOTSTRAP method.
>  - The Challange/Respond pattern also makes the mechinism opaque and
> thus it is separate from the telepathy API. I think it was a mistake,
> for example, to have a certificate-specific API in telepathy.
>  - We unify the mechanism negotiation for all protocols and schemes
> under a common API.

Thanks. I like that the proposed way is friendly to cases when the dispatcher needs to pop up a separate authentication UI, which can even ignore differences between channel and connection auth. Also, this isolated UI process could have elevated privileges and be better secured.

Few minor comments:
- A challenge channel should present some human-readable string, to possibly inform what is being authenticated.
The string SHOULD be formed locally by the connection manager, so as to avoid presenting remotely supplied information as trusted.
- Maybe there should be a list of request tokens from the original channel request(s), available through the ChannelAuthentication interface, to refer to requested channels that will be created after the authentication is successful.

Best regards,
  Misha