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

[Dafydd Harries]

Ar 25/01/2010 am 22:15, ysgrifennodd Will Thompson:
> >> • Could Abort() just be Close()? Or do we need a reason in Abort() for
> >>     XMPP? “I'm aborting because the server sent an incorrect challenge.”
> >>     etc. cf. Call
> >
> > This was to preserve correspondance with the SASL RFC, but I'm not sure how
> > useful it is, and actually it doesn't really cover the full SASL abort
> > semantics:
> >
> > http://tools.ietf.org/html/rfc4422#section-3.5
> 
> Hmm. Do we need to expose anything more complicated than a no-arg method 
> given that the SASL RFC doesn't specify what non-protocol-specific 
> information is conveyed in either direction?
> 
> >> • Do they need to be Destroyable, if they respawn? No: Close() is like
> >>     Destroy() in this diagram. The CM should only ever pop up a new
> >>     challenge channel if the previous one failed rather than just being
> >>     closed.
> >
> > "This diagram"?
> 
> Sorry, reference to a RL conversation I failed to tidy up when 
> clarifying my notes.
> 
>   • If the UI successfully responds to all the channel's challenges, the
>     channel goes away, connecting succeeds, and everyone's happy.
>   • If the UI messes up a challenge, a new challenge channel can pop up a
>     protocol-determined number of times to give the user more chances;
>     when they're exhausted, connecting fails.
>   • If a challenge pops up, and the handler crashes, MC will call Close()
>     on the channel.
> 
> So what should the CM do in the third case? Should it respawn more
> challenge channels as in the second case, or give up? If the former,
> should the channels implement Destroyable so that MC can get rid of them
> if the UI keeps crashing?
> 
> 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?

> 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.

> > Again, this is part of the SASL model. It has two concepts of identity: the
> > authentication identity (who you are) and the authorization identity (who you
> > act as). I might /authenticate/ that /I am/ the owner of a particular X.509
> > ceritificate so that I am /authorized/ to /act as/
> > xmpp:dafydd.harries at collabora.co.uk.
> >
> > 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. 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.

> >> • Separable: OTR's “phone your contact, agree on a codeword, both type
> >>     it into your client, clients exchange hashes” verification method is a
> >>     counter-example.
> >
> > Ok, so how does everything work when you need to authenticate both ways? While
> > some SASL mechanisms may allow clients to identify the server, SASL is
> > inherently asymmetric and geared towards authentication of the client to the
> > server.
> 
> Hmm. Maybe this is a sign that while client–client authentication
> resembles client–server authentication, they're different enough to
> warrant distinct API.
> 
> Perhaps the right way to model this is:
> 
>   • A channel type;
>   • A server→client SASL interface (as has been focused on);
>   • A client→server SASL interface;
>   • An OTR-style shared secret interface.

Perhaps. It would make me a bit sad if there were three interfaces with a lot
of overlap, but perhaps it would be clearer.

> Do we expect to use SASL for client–client authentication?

I don't specifically know of a case where it will happen.

> >> • How does the CM know when we don't trust the peer? Sjoerd says: part
> >>     of the challenge can be the server saying it knows a hash of your
> >>     password, so that you know the server is not MITMed.
> >
> > This doesn't really answer the question. What if the mechanism you're using
> > doesn't allow you to trust the peer? Putting the policy in the CM feels wrong.
> >
> > If you get a certificate from the server and verify it, or if you have some
> > means from the forward-SASL to identify the server (or at least know that it
> > knows your password, which isn't exactly the same thing), then everything's
> > good. But if those things don't happen during connection, what do you do?
> > Should you be able to initiate reverse-SASL, assuming the protocol allows it?
> > Does the authentication handler just disconnect the connection? Or does the
> > client get to do it? If the authentication handler does it, how does the
> > client know that that's why the connection was terminated? Do we add a new
> > connection termination reason?
> 
> If the protocol supports reverse-SASL, maybe the untrusting handler
> could request such a channel?

That makes sense.

> Indicating that the client doesn't trust the server's identity could be
> an argument to the Abort() method.

I'm not sure the CM can do anything useful with that information though.

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.

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?
 * 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?