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

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

On Thu, Oct 09, 2003 at 08:37:37AM -0700, Joseph Salowey wrote:

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

> [Joe] Yes, this is all too familiar
> 
> > 
Nico> In the GSS-API we call this channel bindings.  Perhaps SASL should
Nico> have

[I meant to say "Perhaps SASL should have a channel bindings facility."]

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

> [Joe] Yes, I agree the Session ID is probably not the best choice
> (although in would probably work in the case outlined, it will fail if
> the attacker can trick the client into accepting it as a valid TLS
> endpoint, but this is a different problem).  
> 
> In any case SASL might benefit from channel bindings, although one has
> to be careful with channel bindings (for example binding to addresses
> tends to cause problems).  Maybe it is possible to temporarily turn on
> SASL integrity services to authenticate binding information.  I don't
> think that SASL intends for the security layer to be removed after it
> starts, but I didn't find a place in the draft where it explicitly
> forbids it.  If it is allowed then applications which negotiate TLS can
> use this binding technique.

It's probably not possible to add a channel bindings facility to SASL at
this point, but it should be possible to describe how applications
should do channel binding with SASL, more or less as you describe.

And as you point out, the traditional use of GSS-API channel bindings to
bind to network addresses causes problems, and, I might add, isn't
really secure.

Therefore we need to generally address channel bindings for the channels
one might like to bind to:

 - What to use as channel bindings for SSHv2?

   Easy, the SSHv2 session ID!

 - What to use as channel bindings for TLS?

   TLS defines no suitable value.  So one may have to be constructed
   (e.g., hash of all TLS session setup messages).

 - What to use as channel bindings for IKEv1 IPsec?

   Don't.  IKEv1 rekeying isn't like SSHv2 rekeying - there's no binding
   to the previous or original IKE_SA - so that when the IKE_SA expires
   so do the bindings.

 - What to use as channel bindings for IKEv2 IPsec?

   IKEv2 rekeying does bind the new SA to the previous one, so binding
   to IPsec SAs negotiated with IKEv2 is ok, but we need to define the
   what to use as the channel bindings.

   I've asked the IPSEC WG to define a value for use as channel
   bindings, but so far they are ignoring me.

   Ultimately, the same octets of which signatures are exchanged in the
   AUTH part of the IKEv2 exchange (see section 2.15 of the IKEv2 draft)
   can be used as channel bindings, or, rather, a hash thereof.

 - What to use as channel bindings for Kerberos V-protected tunnels?

   Again, nothing useful for this is provided in RFC1510.  But who wants
   this?  :)  Still something could be defined (e.g., a hash of the AP
   exchange messages).

 - What to use as channel bindings for GSS-API-protected tunnels?

   Same thing.  I'd propose: the ret_flags of the context and a hash of
   the byte-wise concatenation of the context tokens used to initialize
   the context, in order.

 - What to use as channel bindings for SASL-protected tunnels?

   Again, same thing...

Cheers,

Nico
--