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: <[email protected]> — 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 _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
