On 02/10/2009 08:15 AM, Peter Saint-Andre wrote: Hi,
> To follow up on our conversation yesterday at the XMPP Summit, here are > some readings about channel bindings: > > http://blog.dave.cridland.net/?p=43 > http://tools.ietf.org/html/rfc5056 I wonder if I understand this thing correctly. If I read the rfc, it seems to me it is a specification describing how to delegate session protection from one layer to another, e.g. from an already e2e secured xmpp session to a jingle session. In Daves blog I miss the distinction between the channels at all. Can somebody please prove me wrong on the two channels? If this works on one channel it is the golden bullet against MITMs. Now, to continue my reading of the rfc, if I understand it correctly the rfc describes this: 1) You first set up a secure channel between two endpoints. 2) You set up a second channel between the same endpoints that has encryption and integrity checking, but does not have any protection against a MITM. 3) Both endpoints calculate a single octet that uniquely identifies the second channel. This octet is called "channel bindings". 4) The first, secured channel, is used to exchange that octet. If there is any mismatch, there is a MITM active. I think it is wise to reuse as many existing specifications as possible, so it might be good to look at what it takes to make use of rfc5056 in XMPP. Then I come up with: - For each encrypted secondary stream that might be opened (file transfer, jingle) we need a method to calculate the channel bindings. On http://tools.ietf.org/html/draft-williams-on-channel-binding-04#section-4 there are some examples for doing that on TLS and SSHv2. - A specification to exchange the bindings over the e2e secured XMPP stream. Because I never dived deep into the XEPs on things like file transfer and jingle (they are right now not very relevant for me), I can't say if working like this has any advantage over what is (or is not) specified until now. But channel binding might provide a nice specification to solve several similar problems. Anyway, this still doesn't solve the problem of securing the first e2e channel. As far as I can see, that is only possible if there is a signature of a mutually trusted party or if the endpoints share a secret. If you can't or don't want to work with certificates or a (PGP) web of trust, then it is the best to look for ways to make it as user friendly as possible to validate a shared secret. IMHO that is the biggest challenge of e2e security right now. best wishes, Winfried -- http://www.tilanus.com xmpp:[email protected] tel. 015-3613996 / 06-23303960 fax. 015-3614406
