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 11:44:10AM -0400, Jeffrey Altman wrote:
> Nicolas Williams wrote:
> >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.
> 
> 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.

Yeah - I offer as much in the post I just followed up with.

This sort of thing is extremely valuable.  The NFSv4 WG is quite
interested in channel bindings as a way to offload session cryptographic
protection from RPCSEC_GSS/GSS-API to IPsec and others.

See:

http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt

(The I-D will be updated soon, I hope, and will include much improved
 text about binding to IKEv2 IPsec transport-mode IKE_SAs, as well
 nonces and an additional 1/2 round-trip for the CCM-* pseudo-
 mechanisms' context tokens so as to make their context tokens
 un-replayable independently of the underlying, real mechanisms'
 context tokens' replayability.)

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

The discussion of what to use as channel bindings to TLS would still
have to be had, though you point out that TELNET already solves that
particular problem in a way that others could leverage.  But that still
leaves other channels to discuss (e.g., IPsec) - see my other followup
to Joe.

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

I agree.  But note that SASL doesn't have to "verify a previously ..." -
it just has to verify a value, public or not, that could not be made the
same for both parties by an MITM at the lower layer.

Cheers,

Nico
--