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 <[email protected]> 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:[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 >
