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

[Eitan Isaacson]

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.

1
http://telepathy.freedesktop.org/wiki/Authentication#UnifiedInterface
2
http://people.freedesktop.org/~eitani/telepathy-spec-authentication/spec
3
http://git.collabora.co.uk/?p=user/eitan/telepathy-spec.git;a=log;h=refs/heads/authentication
4
http://git.collabora.co.uk/?p=user/eitan/authentication-whiteboard.git;a=blob;f=client_chatroom.txt;hb=inline-negotiation
5
http://git.collabora.co.uk/?p=user/eitan/authentication-whiteboard.git;a=blob;f=client_server.txt;hb=inline-negotiation
6
http://git.collabora.co.uk/?p=user/eitan/authentication-whiteboard.git;a=blob;f=client_client.txt;hb=inline-negotiation


On Mon, 2010-02-01 at 18:49 +0000, Will Thompson wrote:
> On 25/01/10 23:46, Dafydd Harries wrote:
> > Ar 25/01/2010 am 22:15, ysgrifennodd Will Thompson:
> >> Relatedly: perhaps this is a good reason to have an explicit Abort(): it
> >> means the CM knows that the UI explicitly said "no, don't bother" rather
> >> than crashing.
> >
> > Doesn't Destroy() already accomplish that?
> 
> So, the UI should call Destroy() to explicitly give up?
> 
> >> Also relatedly, and has just occurred to me: if you mess up the
> >> challenge, do we really want a new channel to pop up and be
> >> dispatched? That would mean a UI that wants to keep a prompt window on
> >> the screen until the connection succeeds or fails is a bit harder than
> >> it would be if there's at most one auth channel per connection attempt;
> >> however, allowing repeated auth attempt on the same channel might
> >> complicate the interface.
> >
> > I'm not sure I understand this prompt interface. Surely any prompt must at
> > least be disabled while the response round trips.
> 
> That's true. I'm not sure I understand my point now either.
> 
> >>> So far, we haven't needed the authentication identity part. But I think we
> >>> should include it in case mechanisms/protocols we haven't encountered yet
> >>> require it. I'm not sure how we should include it, however.
> >>
> >> Would it be something that you could include along with the choice of
> >> mechanism? “I want to use Kerberos; I am<foo>  and own<bar>.”
> >
> > Actually, I think this is always transmitted in a mechanism-specific way in
> > responses to challenges. E.g. in Kerberos it's passed in the first response.
> >
> > As far as I can tell, with the KERBEROS_V4 mechanism, the authorization
> > identity was always implicit (i.e. the server had to derive it from the
> > authentication identity) because it's never sent as part of the SASL exchange.
> >
> > I'm really confused about Kerberos 5 and SASL. The reference for the
> > KERBEROS_V5 mechanism is a person, not a document.
> 
> Ugh.
> 
>  > The RFC for the GSSAPI
> > mechanism is called “The Kerberos V5 ("GSSAPI") Simple Authentication and
> > Security Layer (SASL) Mechanism”, but talks entirely not in terms of protocol
> > but in terms of GSSAPI functions I'm not familiar with.
> >
> > In short, I don't know how the authn vs. authz distinction works in practice.
> > Trying to divine it from the standards has been an excercise in frustration.
> 
> But based on what you have divined from other protocols, it sounds like 
> assuming it's transmitted in-band with the challenges and responses is safe.
> 
> > So, in review:
> >
> > We definitely need:
> >
> >   1. client → server SASL
> >   2. server → client X.509
> >   3. client → service authentication for SIP that we assume can be shoehorned
> >      into SASL (hmm, how do we indicate the identity of authenticator in this
> >      case?)
> >   4. OTR
> >
> > We might need:
> >
> >   5. client → server X.509
> >   6. server → client SASL
> >   7. client → client SASL
> >
> > Out of these, my proposal currently covers #1 and most of #3, and Eitan's
> > proposal covers #2.
> 
> And we just had some discussion in Cambridge about XTLS and SSL 
> verification — which Sjoerd is writing up — and reckon we can adapt 
> Eitan's proposal to cover #4 too.
> 
> > My biggest questions boil down to:
> >
> >   * Should we be worrying about unifying all of these, or just
> >     accept that there might be multiple similar interfaces and some inelegance
> >     and push ahead?
> 
> I personally think that we'll either end up with a handful of similar 
> interfaces, or one really ugly and hard-to-understand interface; so if I 
> were you I'd push ahead.
> 
> >   * How much should I be worrying about #5/#6/#7? Should I just concentrate on
> >     what we know we need or worry about future expansion?
> 
> Under the same handful-of-similar-interfaces umbrella, I'd say the 
> former. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/telepathy/attachments/20100310/3af1e76b/attachment.pgp>