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

[Will Thompson]

On 25/01/10 19:57, Dafydd Harries wrote:
> Ar 20/01/2010 am 17:59, ysgrifennodd Will Thompson:
>> SaslAuthentication:
>> • Is SaslMechanism an ASCII string
>
> Yes. IANA maintains a list of them:
>
> http://www.iana.org/assignments/sasl-mechanisms

Aha, cool.

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

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.

>> • Identity/rôle: is it inside the sasl mech's string of misc? Use case
>>     please?
>
> "String of misc"?

I was under the impression that there was some data supplied along with
each entry in the list of supported mechanisms, but I was wrong.

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

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

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

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

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

-- 
Will