On Fri Jun 8 09:51:06 2007, Ian Paterson wrote:
SASL External Auth (as specified in XEP-0178) relies on the TLS
layer to verify X.509 certificates.
Sort of...
However, clients connecting using BOSH (XEP-0124) don't use TLS
encryption, they use https:// instead (i.e., they do not present a
certificate before SASL). I think it might therefore be useful to
define a protocol independent of TLS that enables X.509 certificate
presentation and verification of ownership. The protocol would be
advertised as a stream feature and performed before SASL.
I think you're abusing SASL EXTERNAL, which basically is an agreement
between client and server that the channel has some property which
can be used to authenticate them. By tradition, this tends to mean
TLS auth, but that's purely an example.
I'm not convinced this is the case with the scenario you're
describing. In that scenario, you're looking at X.509 authentication
as a SASL mechanism. (FWIW, some people hoped TLS might end up as a
SASL mechanism in and of itself).
You might instead want the BOSH implementation to handle the
authentication, and then pass the authorization identifier it then
obtains through, perhaps using TLS-based strong auth and SASL
EXTERNAL, independent of what the client uses. (This is known as
proxy-auth, although for wordsmiths it's a different use of "proxy"
than "HTTP proxy" - it just happens that many reverse-proxies tend to
be doing proxy-auth).
There's good reasons for doing this, including that the newer SASL
mechanisms being designed are likely to support (and maybe require)
channel binding, and in this case, if the channel bindings used
related to the TLS session over which BOSH was run, a pass-through
authentication would fail, as it'd correctly detect a MITM. Equally,
running TLS-over-BOSH would be painful in the extreme, so we probably
don't want to be thinking about that.
I don't know enough about the TLS protocol. Perhaps it allows
certificate verification without resulting in any stream
encryption? In which case, there might not be any need to define a
new protocol.
Sort of - it supports an encryption algorithm NULL, which is roughly
the same thing. It's almost always disabled by default, since you
rarely want it to happen.
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
