Support end-to-end encryption and authentication
Submitted by Cosimo Cecchi @cosimoc
Assigned to Telepathy bugs list
Description
Hi,
crypto-headaches are back again for everyone, now that I started working again on a proposal to integrate end-to-end security in Telepathy ;-P
An HTML version of my new spec draft can be found here [1], while the git branch for it is here [2].
Overview
The main ideas behind the design of this API are the following:
- clients should not deal with more than one additional channel to obtain a secure end-to-end channel.
- clients should be able to choose the encryption protocol used, if more than one are available (e.g. both OTR and XTLS could be available on an XMPP account).
- the handling of the additional channel can be done in a separate process, without forcing the requesting client to care about the encryption steps.
- clients which do not request encrypted channels can work without modifications.
To accomplish that, I added basically three fundamental types to the specification: the Encryptable interface, the ClientAuthentication channel type, and the Authentication.Proposal transient object. On top of them I also drafted some protocol-specific implementations.
Ch.Iface.Encryptable
This is the main entry point for requesting an encrypted channel, by specifying EncryptionRequired = TRUE in the request.
The EncryptionInterface is used to specify the protocol to be used for encryption (e.g. OTR vs. XTLS), and defines the interface supported by the ClientAuthentication channel that will be dispatched to authenticate the encryption process.
I thought this being a requestable property here could also play nice with the fact that a CM could advertise the possible protocols in RequestableChannelClasses.
Ch.Type.ClientAuthentication
It's the channel that will be dispatched to authenticate the encryption process. The base object also keeps track of the channels around that use this authentication, by using the TargetChannels property.
Channel.Interface.XTLSAuthentication is an XTLS interface for this kind of channel, and one might also write Channel.Interface.OTRAuthentication on the same line.
Auth.Proposal
It's a transient object that can be used to complete the authentication step. Each proposal implements one interface, which defines the protocol-specific methods to accept it.
How exactly the proposal objects are used and constructed is up to the interface of the ClientAuthentication channel.
I drafted implementation for Auth.Proposal.X509 and Auth.Proposal.SRP, to be used with the XTLSAuthentication interface.
There's a last object, which is Ch.Type.ClientTLSConnection, which is a way to exchange TLS certificates between clients; this is usually needed after SRP, and a channel of this kind would use the same Encryptable/ClientAuthentication process described before to signal that the exchange is linked to a previously authenticated session.
That's it for now, feedback welcome.
[1] http://people.collabora.co.uk/~cosimoc/e2e-encryption-spec/ [2] http://git.collabora.co.uk/?p=user/cosimoc/telepathy-spec.git;a=shortlog;h=refs/heads/e2e-encryption
Version: git master