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
