Re: Where to specify details of channel bindings

[Nicolas Williams <[e-mail]>]

On Thu, Dec 01, 2005 at 10:51:02AM +0100, Simon Josefsson wrote:
> I started working on text in GS2 that would give guidance on exactly
> what channel binding data to specify when running under TLS.  It
> occurred to me that this isn't specific for GS2.  DIGEST-MD5 could use
> similar channel binding data guidance.

For TLS the answer is quite simple: the concatenation of the client and
server finished messages, in that order.

See:

draft-ietf-kitten-gssapi-channel-bindings-01.txt
draft-ietf-nfsv4-channel-bindings-03.txt

(Note: the text on IPsec channel bindings is way out of date.)

> I haven't thought through the following completely, but thought I
> should mention it to see if I have hit upon something useful.
> 
> Shouldn't the core document specify that if SASL is used below TLS,
> and the SASL mechanism support channel bindings, the channel binding
> must include the TLS session id?

s/below/above/?

Anyways, no, TLS session IDs are not strongly bound to TLS channels.

> It could be argued that the channel binding problem is inherent in
> SASL itself, and not specific to any mechanism.  That would argue for
> fixing it in the core document.
> 
> Other recommendations, for e.g. IPSEC channel bindings could be added
> too, but as far as I know, SASL over IPSEC isn't sufficiently widely
> used to let us make a informed choice.  There is also a larger layer
> violation in getting the IPSEC session id into the SASL library, or
> even worse, every SASL mechanism.

I agree, I think we could generalize the above drafts a bit, so they are
applicable to SASL.  See section 4.2 of draft-ietf-nfsv4-channel-
bindings-03.txt.

The bigger problem is negotiation of use of channel bindings.

Particularly when it comes to channels for which channel bindings will
be specified later, as opposed to now, or for which channel bindings are
difficult to obtain with existing implementations' interfaces.

E.g., client uses channel bindings to channel XYZ, the server is unaware
of the channel or can't get bindings for it, so it does not provide
channel bindings to the mechanism --> context establishment fails.

What we want from channel bindings is: to know whether the binding
succeeded so the app can choose to eschew session protection at the
higher layer.  It's OK if channel binding fails but context
establishment succeeds, AS LONG AS the application knows the binding
failed and so can choose how to proceed.

But the GSS-API doesn't provide this information -- it's all or nothing.

So in pure GSS-API contexts we'll be resorting to stacking a pseudo-
mechanism whose primary purpose is to indicate willingness to do channel
binding at mechanism negotiation time.  But in SASL/GS2 context we can
do better.

Nico
--