Re: Where to specify details of channel bindings

[Simon Josefsson <[e-mail]>]

Nicolas Williams <[e-mail]> writes:

> 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

Oh.  Interesting.  I note that other conceivable channel bindings for
TLS are possible.  Extracting the client/server finished messages from
a TLS library is not generally possible.  Accessing the TLS PRF is not
generally possible, but I believe using this approach would be
cleaner.  It would also make sure we are deriving new material used
only for this particular SASL authentication, instead of re-using data
meant for other purposes.

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

Right.

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

Ah, I see.

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

Ouch.  This is a serious problem.  Couldn't SASL/GS2 use the
pseudo-mechanism to solve this problem, though?  Is the channel bind
negotiator pseudo-mechanism too inefficient?  I'm thinking that we
should avoid duplicating work that is already available.

Thanks,
Simon