Telepathy Wiki - Authentication

Notes on new Telepathy interfaces for various authentication needs.

Scope

Client connection authentication that doesn't use a stored secret (e.g. Kerberos or Google's temporary tokens as opposed to a password).
Asking for credentials for channels (e.g. password-protected chatrooms).
Asking users whether to accept or reject server credentials (e.g. SSL certificates that can't be verified through the standard trust mechanisms). It should be possible to accept certificates permanently (continuity checking). Currently, each account has to accept or reject all unverifiable certificates. In theory you could include details of trusted certificates as connection parameters, but this doesn't allow leap-of-faith; you have to get the details via an out-of-band method.
Asking users whether to accept contacts' credentials. This should work similarly to checking servers' credentials. The case where we expect this to turn up is Jabber XTLS.
Allowing users not to store connection passwords but to enter them as needed.

Authentication is split into two kinds: local (we need to provide credentials) and remote (a peer needs to provide credentials).

Created when a peer wants us to authenticate ourselves.

Property: Resource : o
- Object path of the resource undergoing authentication. This might be a connection or a channel.

Property: SaslMechanism: s
Property: State : u
- Pending
- Authenticated
- Failed
Property: Challenge : as
- A list with either 0 or 1 items.
- The item, if present, is a string describing an authentication challenge sent by the peer, which may be empty.
- If the list is empty, then the peer has not issued a challenge.
Signal: Challenge : s
- Emitted when a challenge is received.
Method: Respond : s -> ()
Method: Abort : () -> ()
Signal: Failure : ()
Signal: Success : ()

Created when we want to authenticate the peer.

This is an attempt to make a unified interface for all types of authentication, TLS, SASL and protocol specific schemes like chatrooms or XTLS.

Property: PeerIdentity: s (ro)
Property: State : (u: AuthenticationState)
Property: Challenges: as
Property: Mechanism: s
Method: Respond: s -> ()
Signal: StateChanged: (u: AuthenticationState)
Signal: Challenge: s
Signal: MechanismNegotiated: s
Type: AuthenticationState (u)
- Pending_Mechanism
- Pending_Authentication
- Authenticated
- Failed
Type: AuthenticationRejectReason (u)
- Aborted
- Invalid_Authorization_Id
- Invalid_Mechanism
- Mechanism_Too_Weak
- Not_Authorized
- Cert_Not_Provided
- Cert_Untrusted
- Cert_Expired
- Cert_Not_Activated
- Cert_Peer_Mismatch
- Cert_Fingerprint_Mismatch
- Cert_Self_Signed
- Other
Type: MechanismDetails (sa{sv})
- Mechanism_Name (s)
- Mechanism_Info (a{sv})

Separate authentication of the peer to us from authentication of ourselves to the peer? This would avoid the channel working in two modes at once.
This interface suffers from the seesion handler interface inversion antipattern: it would be more elegant if the CM could call a Respond() method on the channel handler.
Who decides which authentication mechanism to use? Is is the CM or the channel handler? Eitan: I believe the channel handler should be able to do this. We need it in the XTLS case especially.
How to retry authentication when Abort() is called?
Is it ok for CMs to present as SASL authentication challenges which are not SASL in the underlying protocol? (E.g. passwords for chatrooms in XMPP.) I think yes.
Include concept of identity/role to authenticate as? This might come up with some SASL mechanisms.
Naming of "LocalAuthentication"/"RemoteAuthentication" may be unclear.
Sjoerd suggests that local and remote authentication may not always be seperable. In this case, we should combine both channel types, and have something like a PendingAuthenticationDirections property which is 0, 1, or 2.
How does the CM know when we don't trust the remote peer? Is it always clear from context, or does the client need to tell it to initiate remote authentication sometimes?