[jdev] Re: [Psi-devel] Some login/sasl questions for 0.11

[Dave Cridland]

On Mon Feb  5 14:46:01 2007, Matthias Wimmer wrote:
> Dave Cridland schrieb:
>>> Concerning the question if establishing a SASL encryption layer 
>>> should be supported inside a connection, that is already 
>>> protected by a TLS layer:
>> 
>> This interested me, so I discussed this with the SASL guys in the 
>> office, and the result, as I understand it is as follows.
>> 
>> Basically, what you're discussing is related to Channel Binding - 
>> there's a lot of work going on in that area in the IETF at the 
>> moment, including an updated DIGEST-MD5 which does channel 
>> binding. There's other mechanisms under development which will 
>> also use channel binding. This basically ensures that both ends of 
>> the authentication have the same idea of the encrypted channel 
>> used.
> 
> Right.
> 
>> Now, if you use SASL security layers in addition to TLS, then this 
>> does negate the need for channel binding, but it also negates the 
>> need for TLS to a large degree. So for a server, you want SASL 
>> security layers, and ignore TLS.
>> 
>> Since SASL security layers are weaker, often, and also have 
>> certain undesirable properties, such as transmitting the userid 
>> and authid in the clear, though, you want to be using TLS as a 
>> client.
> 
> On the server side I also cannot just not offer TLS and only offer 
> a security layer in SASL. If I would do so, I would not allow the 
> client to authenticate using TLS - which is the probably strongest 
> way we currently have for client authentication and ensuring an 
> encrypting layer.
> 
> 
For some values of strongest, yes. Kerberos is also a possibility, 
though, as is SRP.


> I think if a server does not care that there is a security layer to 
> the client (current standard case), the connection should not use a 
> SASL security layer inside the TLS layer. But this shouldn't be the 
> client that decides that this SASL layer is not established, but 
> the server.
> Therefore I think that Psi should establish the auth-conf layer of 
> DIGEST-MD5 if that is offered by the server - but servers typically 
> should not offer this layer if TLS has already been established - 
> as it is the server for which it matters if that second security 
> layer exists or not.

Or, as a short-term possibility, you could run auth-int inside TLS, 
and then exchange XMPP-level channel binding messages, perhaps via a 
simple IQ. That'll have much the same effect as channel binding. (Of 
course, without the auth-int, it's meaningless).

That's got to be a lot cheaper than encrypting twice, and should work 
find in the normal case of there being no MITM. It's also much easier 
to code.

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