[Standards] SASL External via X.509 without TLS

[Dave Cridland]

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:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade