[Security] channel bindings

Winfried Tilanus winfried at tilanus.com
Tue Feb 10 08:34:30 CST 2009

On 02/10/2009 08:15 AM, Peter Saint-Andre wrote:


> 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
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,


xmpp:winfried at jabber.xs4all.nl
tel. 015-3613996 / 06-23303960
fax. 015-3614406

More information about the Security mailing list