[Telepathy] telepathy-spec vs. XTLS: round 2
cosimoc at gnome.org
Wed Jun 9 08:57:48 PDT 2010
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 ; there's also an
> HTML version available here .
it's time for another update on where I got so far here.
First of all
- HTML version:
- relevant bug report:
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
* 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
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.
StateChanged (u: State)
Method s Read only
State u (Proposal_State) Read only
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.
SendCertificateChain (s: Certificate) → o: Certificate_Object
RemoteCertificateChainRecieved (o: Remote_Certificate)
X509StateChanged (u: State, u: Reason)
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
X509StateReason u (X509_Authentication_State_Reason) Read only
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
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).
SetPassword (s: Password) → nothing
SRPStateChanged (u: State, u: Reason)
SRPState u (SRP_Authentication_State) Read only
SRPStateReason u (SRP_Authentication_State_Reason) Read only
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
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
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.
ProvideCertificate (s: Certificate) → nothing
ReceiveCertificate () → o: Certificate_Object
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.
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.
More information about the telepathy