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:[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
