[Security] channel bindings

Eric Rescorla ekr at rtfm.com
Tue Feb 17 10:00:28 CST 2009


I don't have time to write a full note here, but I wanted to observe that
the corresponding TLS mechanism to SCRAM is really TLS-PSK,
which *is* in OpenSSL. SRP differs from SCRAM and PSK in that
an attacker can't dictionary search the password offline, whereas
in SCRAM/PSK he can.

-Ekr


On Tue, Feb 17, 2009 at 7:56 AM, Dave Cridland <dave at cridland.net> wrote:
> 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, SCRAM
>> 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.
> --
> 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