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

[Will Thompson]

Hello,

Today, Sjoerd, Simon and I went over Daf's SASL interface sketches, and
Eitan's CertificateVerification draft. Here are some (slightly scrappy,
sorry) notes I took from our discussion.

Extended connection authentication stuff
========================================

<http://telepathy.freedesktop.org/wiki/Authentication?action=recall&rev=11>

Scope:
• Correct to leave out channel passwords

LocalAuthentication:
• Probably needs an ObjectType property for the object's main interface.

SaslAuthentication:
• Is SaslMechanism an ASCII string
• 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.

• Can we have an example using the “3 questions” scene from Holy Grail
   please?

• 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

• Implementation details:
   ∘ This relies on MC being able to dispatch channel before being
     Connected. This is kind of wool-y in the spec, and we need to make
     it work in Connecting state and hack up McdConnection to support
     this.
   ∘ Need to make sure TpChannelManager can expose channels in Connecting
     state.
   ∘ Need to get the MC stuff in first, to avoid being unable to auth
     because the channels aren't dispatched or closed. Or, better, we
     need a way for the CM to know if this is supported at all —
     ContactCaps?  Then auth client could just depend on new enough MC.

• If you fail the first time around, should the CM pop up another
   channel? Yes, on XMPP: you can try N times before the server says no.
• 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.

TlsCertificateVerification:
• Resolved later: we took a look at Eitan's.

Reactions to each of the 'Open questions' listed:
• Separate channels for being authed and authing: talk to Cosimo, this
   is mostly for XTLS
• The method naming means this doesn't suffer from the SessionHandler
   antipattern, really. The challenges and responses are 1-shot anyway,
   can't be pipelined, can't be replaced under your feet. Strictly in
   ABAB lockstep so not a problem.
• The handler should pick which auth mech to use: see above.
• How to retry: need a use case for this.
• Fake SASL: yeah, sure. We have to deal with SASL anyway and it's
   general enough.
• Identity/rôle: is it inside the sasl mech's string of misc? Use case
   please?
• 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.
• 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.

Should LocalAuthentication channels also have a PasswordAuthentication
interface for lowering the barrier to entry to using this? Yes: SASL is
a reasonably high bar. It would be good to make Empathy let you provide
your password when you sign in without having to speak the whole of
SASL.

How does MC pick which of your several handlers for LocalAuthentication
to use?
• Same problem as how does it know whether to use Empathy or Kopete for
   text.
• If Empathy only does passwords, but you install another program which
   does Kerberos, you want the latter to be used where possible,
   probably.
• Pick by the one which has more capability tokens? Possible drawback:
   always pick the KDE one if you're on Gnome
• Pick the one that's running? No: Empathy's running, but your tp-krb
   thing isn't.
• Suppose I have two handlers. One can do krb and password; one can do
   google token and password; how do we not do the kerberos one when
   logging into Google (given that they're equally competent)?
   ∘ Maybe the answer is, don't do that.


Eitan's CertificateVerification interface
=========================================

<http://people.freedesktop.org/~sjoerd/telepathy-spec-cert_verification/spec/org.freedesktop.Telepathy.Channel.Type.CertificateVerification.DRAFT.html>

Sjoerd and Simon think we want different channel types for verifying
servers' certs and for verifying contacts', with a common interface,
rather like how (modern) tubes are. This clarifies what the "Resource"
is: it would become a property that is the connection (along with the
name of the server!) for servers. For channels, the CertVerification
object doesn't know which channels it's for; rather, the channels have
an interface saying they're awaiting verification, pointing to the
request. We discussed this in the telepathy@ thread “API sketches for
encrypted channels, and OTR” — beginning with Message-ID:
<4AD3A017.3020108 at collabora.co.uk> — in particular, Cosimo's replies
based on conversations with Sjoerd.

SendCertificate seems unexpected. What does the cert represent? What
does RequestedIdentity *mean*? Need examples.

State looks like FT, which is good.

GetCertificate() probably wants to be plural — Sjoerd should check this
— and to include the certs' properties. It could be a property —
Certificates: a{oa{sv}} — so that clients don't have to GetAll() on each
object.

But on closer inspection: Simon points out that you're accepting
the identity, so even if you have >1 cert then you only want to
accept/reject once. So we actually just want the channel to have an
array of PEM fingerprints, an Accept() method, and Reject( reason goes
here? ) method, and not have separate objects for each certificate.

Example:
• Simon presents his contacts with two certs identifying him, one from
   Collabora and one from CACert
• Will trusts Collabora but not CACert; Steve trusts CACert but not
   Collabora; Tollef trusts both; Bill Gates trusts neither.
• Simon doesn't care why Will, Steve or Tollef trust him; and if Bill
   doesn't, then he didn't trust any of the certs.
• So we don't need Accept() or Reject() to say anything the specific
   certs?

We want to avoid clients relying on the CMs doing preliminary
verification on certs, so maybe Certificate_Status should go away.
(Sjœrd may already have said this in an email.) A CM should present
certs without comment, and the client should say yes, no or meh; only in
the meh (legacy) case should the CM make its own judgements.

Scary situation: verification UI crashes, MC calls Close(), CM decides.
Would we ever be in a situation where the UI would reject a certificate
but the CM would accept the cert?

Solution: If we know that there is a client on the system which supports
this channel type, but the channel gets closed rather than accepted or
rejected, then the CM should be really strict on the fallback path
(rather than being lenient, as is Gabble's current default).

Side point: currently there's no way for CMs to get information on what
local clients support without implementing ContactCapabilities even if
the protocol doesn't actually do caps (such as SIP or GSM).
• Fix: add a property which is true in this situation (hence false for
   Gabble and other existing implementations of CCs)
• (Eitan, fancy doing this?)

-- 
Will