[Security] channel bindings

Dave Cridland dave at cridland.net
Wed Feb 11 06:37:58 CST 2009

On Wed Feb 11 10:32:13 2009, Winfried Tilanus wrote:
> On 02/10/2009 11:52 PM, Kurt Zeilenga wrote:
> Hi,
> > Here is a really brief explanation of what channel bindings are
> > about.
> Thank you Kurt for this correction of my wrong assumptions. I am  
> still
> trying to understand what it really does, so I will keep asking dumb
> questions and will keep making comments that need correction. I  
> hope you
> (and the others) don't mind.
These are not dumb questions - getting your head around both the  
problem and how it solves it is not easy.

> > The IETF is developing mechanisms such as SASL/SCRAM that  
> providing
> > channeling bind support.  When used, the client can confirm that  
> the
> > SCRAM end-point and the TLS end-point its talking to are in-fact  
> the
> > same end-point.  Likewise, the server can confirm the SCRAM and  
> > end-points its talking to are in-fact the same.
> Can somebody please be a bit more specific on what avenues of  
> attack are
> closed by knowing that the SCRAM and the TLS end-points are the  
> same. My
> common-sense says that at best you might know they are both  
> connected to
> the same MITM.
This is the trick - you have a shared secret, agreed between the  
endpoints, in such a way that the MITM cannot know it.

DIGEST-MD5 will prove that the endpoints which exchanged the shared  
secret are the same as the endpoints of the authentication.

SCRAM - because it does Channel Binding - proves that *and* that the  
endpoints of the secure channel are also the same - this prevents  
there being a passive MITM.

In a sense, this is all about ensuring that one channel has the  
security properties of another.

I'm suggesting using SCRAM here a lot rather than making our own,  
primarily because making our own seems significantly more prone to  
error, and I'm anticipating that SCRAM will end up being a popular  
choice for a password mechanism on server and client alike anyway.

> Or to state my question in another way: what openings does channel
> binding provide for XMPP?

These are, by the way, excellent questions:

>  Does it enable server authentication without
> server certificates

The scenario we're talking about here mostly concerns peer to peer  
sessions, like e2e/xtls or SRTP. In an S2S case, I'm not sure it'd  
work at all. In a C2S case, a server offering SCRAM and TLS needn't  
have a certificate at all, and you could tell (with reasonable  
assurance) that there was no MITM. Addition of a server certificate  
strengthens the security involved, although I suspect that if you've  
successfully stolen the authentication database anyway, you've  
probably stolen the private key, too.

(Yes, this is avoidable if you have smartcards etc).

> ? Does it enable us to do e2e security without the
> hassle of certificates or exchanging secrets?

We could insist on channel binding all the time, but that involves  
exchanging secrets all the time. By essentially requiring a  
certificate (at least for the common case), we can have both ends  
verify each other's certificates by exchanging a secret once.

>  Or does it enable e2e
> security when only one of the endpoints has a certificate?
It could be used for that - I confess I've not thought in depth about  
what you'd be able to prove, nor how useful this is outside the C2S  

The problem there is that you need a (one-time) shared secret which  
is unique to the pair of endpoints, and in exchanging *that* it seems  
likely that some anonymity would be lost.

I'd fully expect cases where this is really useful - and I'm thinking  
in terms of your HelpIM project - that the end which had a  
certificate would have one signed by a trusted CA, rather than using  
the Channel Binding operation.

> thanks for helping me in understanding this thing,

I hope this helps, somewhat.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Security mailing list