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