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
TLS
> 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
case.
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.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
