[Security] channel bindings
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 but nothing from today. What is the
> Eric, do you have some information about that. On the other hand,
> may have similar problems. You can not know that until someone
> 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
> > works, and at the risk of sounding really arrogant, I'm worried
> > 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
> do not recognize the certificates. What XEP-0250 does is exchange
> information what certificates the clients will use to detect if SRP
> 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.
> 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
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Security