[Security] channel bindings

Dave Cridland dave at cridland.net
Tue Feb 17 09:56:26 CST 2009

On Thu Feb 12 14:03:16 2009, Dirk Meyer wrote:
> Right. That is my major problem. Searching for 'SRP and patent  
> issues' I
> see many posts from 200[234] but nothing from today. What is the  
> status?
> Eric, do you have some information about that. On the other hand,  
> may have similar problems. You can not know that until someone  
> claims
> you are violating a patent.
SCRAM itself is based around some very old ideas, and earlier  
versions of the draft documented just how old these were.

Channel binding itself is relatively new, as I understand things, but  
I know of no IPR involved, and the IETF's IPR policy would,  
hopefully, shed light on any important IPR.

> > d) I'm frankly not sure I've grasped how the SRP/PSK-to-X.509  
> dance
> > works, and at the risk of sounding really arrogant, I'm worried  
> that
> > might mean few people within the XMPP community grasp it either.
> Well, with SRP we need to know if we need it. Once we started
> certificate based TLS, it is too late to switch to SRP when the  
> clients
> do not recognize the certificates. What XEP-0250 does is exchange  
> some
> information what certificates the clients will use to detect if SRP  
> is
> needed or not. That's all. 

I was under the impression that you could negotiate with your  
self-signed certificates, and then one or other end could cause a  
renegotiation with SRP, which would be integrity protected with the  
previous magic, thus proving the previous X.509 incantation and  
current SRP spell were cast by the same entity.

> We need something similar for SASL: after TLS
> is complete we need to figure out if one client wants to play SASL.  
> In
> fact, I have no idea how to do that. Does it only work for e2e chat
> messages because it is XML? Is it possible to use a file transfer as
> first Jingle application and still use SASL?
There's no need for the channel used to run the channel binding  
exchange on to the the same as the channel it's binding, rather  
curiously - the channel used is expected to potentially have a MITM  
present, otherwise there'd be no point in channel binding.

So we can use the existing XMPP C2S/S2S/S2C hops to actually run the  
channel binding on.

One nice advantage of this is that you can verify the file transfer  
is legitimate whilst the transfer is in progress, for instance - or,  
just as usefully, one could verify a voice call without cutting audio.

> That may be a problem. How to get the finished messages

OpenSSL certainly has the channel binding data accessible via a (as  
usual, undocumented) API.

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