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

[Nicolas Williams <Nicolas.Williams@sun.com>]

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