[Security] channel bindings
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:
> > Here is a really brief explanation of what channel bindings are
> > about.
> Thank you Kurt for this correction of my wrong assumptions. I am
> 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
> > channeling bind support. When used, the client can confirm that
> > SCRAM end-point and the TLS end-point its talking to are in-fact
> > 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
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Security