On Tue Aug 19 19:03:06 2008, Eric Rescorla wrote:
What Dave is suggesting, I think, would be a garden variety TLS
handshake with
whatever ciphersuites you already support and self-signed certs.
Then you'd run
SASL with some challenge/response protocol and channel bindings
(you'd
almost certainly want mutual auth here) and then on the basis of
the C/R
note that you trusted the peer's self-signed cert
Right.
The interesting thing being that - assuming the shared secret
mechanism is something like SCRAM - this could be the same mechanism
we use to authenticate normally with the server - so there's really
virtually no new code involved, potentially, and it makes the general
operation even closer to "normal" XMPP channel setup.
[Note largely for Ekr - XMPP currently has MTI of DIGEST-MD5, and
this obviously needs changing. I'd personally go for SCRAM as the
replacement assuming it's ready in time, as it's a relatively simple
to implement mechanism which provides reasonable security for the
buck, and has been around for so long there's no chance of ikky IPR.]
I'll admit cheerfully this is not as strong, crypto-wise, as PAKE or
even fingerprinting, but it's still reasonably strong, as as
convenient to use for the user as PAKE, I think.
If a PAKE method that's definitively unencumbered shows up out of the
blue, we can of course switch to that quite easily - at worst having
a SASL EXTERNAL hoop to jump through.
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
