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

[Dafydd Harries]

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

> • It should probably be plural, so that the UI can pick the mechanism it
>    wants to use.
> • So the usage goes:
>    ∘ ChooseMethod( mechanism, crap ) where crap is some initial data
>      which you include with your choice of mechanism (which according to
>          Sjoerd is supported by SASL).
>    ∘ n times:
>      ‣ get Challenge()
>      ‣ call Respond()
>    ∘ get Success() or Failure()
> • One we have a ChooseMethod() method then we don't need the Challenge
>    property for state recovery.

Ok.

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

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

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

"String of misc"?

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.

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

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