[Telepathy] telepathy-spec vs. XTLS: round 2

[Cosimo Cecchi]

On Fri, 2010-06-04 at 10:41 +0200, Cosimo Cecchi wrote:

> I went ahead and implemented this idea on top of the XTLSAuthentication
> interface I already wrote about.
> The telepathy-spec git branch can be found here [1]; there's also an
> HTML version available here [2].

Hi,

it's time for another update on where I got so far here.

First of all
------------

- telepathy-spec:
  git://git.collabora.co.uk/git/user/cosimoc/telepathy-spec.git
  (xtls-proposal branch)
- HTML version:
  http://people.collabora.co.uk/~cosimoc/xtls-proposal-spec/
- relevant bug report:
  https://bugs.freedesktop.org/show_bug.cgi?id=25954

Feedback
--------

I had a conversation with Sjoerd that gave some useful feedback about
what I proposed in my last mails.
        
        * It's not desirable for a client to have to deal with more than
        one subsequent channel for end-to-end authentication.
        * The idea of using transient objects to map authentication
        proposal looks nice, and we should expand on that rather than
        e.g. having a whole separate channel-that-does-it-all to deal
        with post-XTLS-handshake certificate exchange.
        * It doesn't make sense to Reject() a single proposal, you
        either accept one or reject them all.
        * It doesn't make sense for a Proposal object to have separate
        [Remote,Local]Method properties, as there are no protocols out
        there for E2E authentication that use different methods on each
        side.
        * On the same line, having [Remote,Local]Parameters properties
        for Proposal in a completely free-form is not optimal.
        * SRP should be completely decoupled from a (possible) eventual
        TLS certificate exchange (meant to avoid using SRP again in the
        future).
        
Changes on the interfaces
-------------------------

= org.freedesktop.Channel.Interface.XTLSAuthentication =

Mostly unchanged. The references to the TLSCertificateExchange channel
have been completely removed, in favour of the new authentication
interfaces for Proposal objects (explained below).

= org.freedesktop.Authentication.Proposal =

An authentication proposal is defined by its method property, which
identifies the interface it supports. For example, an authentication
proposal whose method is 'x509', would implement the
Authentication.Proposal.Interface.X509 interface, allowing clients to
use X.509 certificates to complete the authentication sessions.

Signals
        StateChanged 	(u: State) 	
Properties
        Method s Read only
        State u (Proposal_State) Read only
                None (0)
                Pending (1)
                Success (2)
                Failed (3)

The idea here is that handlers can look at the Method property and use
the implemented interface to complete the authentication process.
Also there's now a basic 'generic' quad-state inside the proposal, so
observers can watch the progress on the authentication process without
caring about the method-specific states of the implemented interface.

= org.freedesktop.Telepathy.Authentication.Proposal.Interface.X509 =

An authentication proposal that uses X.509 certificates to achieve
mutual TLS authentication between two clients.

Methods
        SendCertificateChain (s: Certificate) → o: Certificate_Object
Signals
        RemoteCertificateChainRecieved (o: Remote_Certificate)
        X509StateChanged (u: State, u: Reason)
Properties
        RemoteCertificateChain o Read only
        LocalCertificateChain o	Read only	
        RequestedIdentity s Read only
        LocalX509Fingerprint s Read only
        RemoteX509Fingerprint s	Read only
        X509State u (X509_Authentication_State) Read only
                None (0)
                Local_Certificate_Chain_Sent (1)
                Remote_Certificate_Chain_Received (2)
                Remote_Certificate_Chain_Accepted (3)
                Success (4)
                Failed (5)
        X509StateReason u (X509_Authentication_State_Reason) Read only
                None (0)
                Remote_Certificate_Rejected (1)
                Local_Certificate_Rejected (2)
                
This works basically in the same way the TLSCertificateExchange
interface I drafted in my previous mail used to. Moving these bits here
removes the need to dispatch an additional channel to verify the
certificate, which is now done inside the proposal, using transient
TLSCertificate objects.

More details on the states are available in the HTML version.

= org.freedesktop.Telepathy.Authentication.Proposal.Interface.SRP =

An authentication proposal that uses the Secure Remote Password protocol
(SRP) to achieve mutual TLS authentication between two clients.

When the SRP authentication is used in the context of an XTLS handshake,
it can be useful for the local client to obtain a certificate from the
remote client, to be used instead of the password for future
communications. In order to do that, the local client SHOULD request a
TLSCertificateCarrier channel to the remote client, once the SRP
authentication process successfully completes (more on that later).

Methods
        SetPassword (s: Password) → nothing 	
Signals
        SRPStateChanged (u: State, u: Reason)
Properties
        SRPState u (SRP_Authentication_State) Read only
                None (0)
                Password_Set (1)
                Success (2)
                Failed (3)
        SRPStateReason u (SRP_Authentication_State_Reason) Read only
                None (0)
                Other (1)
                Invalid_Username (2)
                Invalid_Password (3)

One of the implementation problems we have when using SRP is clients
should issue a <pubkey/> request on the (encrypted) wire any time after
a successful password exchange, in order to save certificates for later
use.

In this implementation, this is solved combining the
TLSCertificateCarrier channel (detailed below, but which really doesn't
do anything else than its name suggests ;) ), with the TargetChannels
property/signals machinery of the ClientAuthentication channel.

The idea is, once the SRP exchange is over, clients interested in
obtaining the certificate of the other peer request an Encrypted
TLSCertificateCarrier channel to the other side, with the right value
for the RequestedIdentity property, and eventually call
ReceiveCertificate() on that channel.

The nice thing is the channel would automatically be added to the
TargetChannels set of the ClientAuthentication channel.

= org.freedesktop.Telepathy.Channel.Type.TLSCertificateCarrier =

A channel type that carries a TLS certificate between two entities.

This is commonly used when a client connects to a remote server, which
presents a TLS certificate that should be verified.
The channel can also be dispatched as a result of an authentication
process not based on certificates (e.g. SRP), as in those cases it can
be useful to save a certificate of the remote client for future
recognition.
In the latter case this channel will also implement the Encryptable
interface, to indicate that the certificate is exchanged over an
already-secure connection between the clients.

Methods
        ProvideCertificate (s: Certificate) → nothing
        ReceiveCertificate () →	o: Certificate_Object
Properties
        RequestedIdentity s Read only
        Incoming b Read only
        
This works a bit like a vastly simplified FileTransfer channel.
If Incoming is TRUE, clients will call ReceiveCertificate() to get the
certificate sent by the other side, otherwise they will have to call
ProvideCertificate(). This kind of channel would also be dispatched when
connecting to a server, though in that case it would not be Encrypted.

The End
-------

Well, if you made this far, congratulations and grab an iced coffee or
something: it's 35C degrees here in Italy :P

Feedback welcome, as usual.

Cheers,

Cosimo