[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard)

Nicolas Williams wrote:

On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey wrote:


If the TLS tunnel is only server authenticated and the client supports a
particular SASL method (perhaps even in a different protocol)that
provides mutual authentication both inside and outside a TLS tunnel
there is a vulnerability. In this case if only the message protection
of TLS is used you cannot be sure that the client endpoint of the TLS
tunnel is the same client endpoint that the server authenticated with
SASL.

To mitigate this problem you can:

- Use the protection from the inner SASL method
- Have the SASL authentication mechanism authenticate the TLS Session ID
or some similar parameter - Require different credentials be used by a SASL mechanism when
operating inside or outside a TLS tunnel. 


Why does this sound really familiar?  Ah, because one solution is to
"bind" one layer (SASL) to the key exchange and negotiation of the other
(TLS) to prove that there's no MITM at the lower layer (TLS) - which, of
course, relies on an MITM's inability to make the key exchange/nego look
the same on both side of the lower layer channel.

In the GSS-API we call this channel bindings. Perhaps SASL should have

The second solution you give is an attempt at doing just this sort of
binding.

Unfortunately, a TLS MITM can make the TLS session ID be the same on
both sides of the tunnel - that's because in TLS the server assigns the
session ID which, in turn, is not bound or required to be bound in any
way to the TLS key exchange / negotiation.  So you can't use TLS session
IDs as channel bindings.

Cheers,

Nico



The channel binding would be made utilizing the TLS Client and Server Finished Messages. If both the client and server concatenate those messages in a well defined order, they can then attempt to verify that both the client and server have the same bytes. This is how TELNET AUTH binds to TLS when STARTTLS is used. The benefit of this is that we would get mutual authentication from SASL which would allow TLS to be used in anonymous-DH mode completely removing the need to have or validate X.509 certificates.

Unfortunately, SASL does not have this functionality at the current time. I very much think it should. If it did, this entire discussion of the use of SASL Security Layers on top of TLS could just go away.

I completely understand why the SASL folks want to be able to use a SASL Security Layer on top of TLS when they do not have the ability to bind to lower layers. Unfortunately, if SASL Security Layers are always to be used then I believe that TLS should never be negotiated. To do so adds nothing to the strength of the security of the session, increases the complexity, wastes CPU cycles, and spreads FUD regarding the trustworthiness of TLS. The lack of trust is not caused by TLS, but by the inability of SASL to verify a previously known shared secret between two parties.

Jeffrey Altman



Jeffrey Altman

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature