Re: Update of GS2

[Simon Josefsson <[e-mail]>]

Nicolas Williams <[e-mail]> writes:

> On Thu, Jun 29, 2006 at 12:32:35PM +0200, Simon Josefsson wrote:
>> 5.  Channel Bindings
>> 
>>    [[This section is tentative further discussion on the topic.  This
>>    was written to provide an example of how the details of how one
>>    approach to this concept could look like.  There are other approaches
>>    that may be preferable.]]
>> 
>>    The GS2 mechanism provide its own token field for channel bindings,
>>    in addition to the "chan_binding" parameter in the GSS-API context
>>    functions.  The reason for this is that the GS2 mechanism wish to
>>    provide an option to proceed even if the channel bindings does not
>>    match.  The GSS-API framework specifies that authentication cannot
>>    proceed if channel bindings does not match.  The GSS-API framework
>>    also does not specify the kind of privacy layer the channel binding
>>    should be transferred under, thus making it possible for attackers to
>>    modify it to always make channel binding negotiation succeed.
>
> Strike the last sentence.  It's not useful -- we only need integrity
> protection for channel binding data, and GSS-API mechanisms that support
> channel binding do provide that.

Do the GSS-API framework require that "chan_binding"s are negotiated
in an integrity protected way?

What I'm getting at is this: is a GSS-API mechanism allowed (by the
framework) to send chan_binding in the clear, and use memcmp() with
the received data and the local channel binding data to test whether
the correct channel binding is used?

If the framework doesn't mandate integrity protection, it seems that
we have to re-implement this in GS2, which is done by sending the
channel binding data in a GSS_Wrap-protected token.

>>    The client can select, using the "Native Channel Bindings" bit,
>>    whether it wishes to use the "chan_bindings" parameter in the GSS-API
>>    layer or not.  If it wishes to use this, it is not possible to
>>    continue after a failed channel binding negotiation.
>
> I don't understand why we should use the GSS-API channel binding
> facility at all given that we need to build a SASL-specific channel
> binding facility to support the semantics we want.
>
> I think this text would be simplified if it required that
> GSS_C_NO_CHANNEL_BINDINGS be used for channel bindings in the GSS_Init/
> Accept_sec_context() calls.

I agree that it would be simpler.

The reason I added it was that some future GSS-API mechanism may, in
some configurations, require or need the channel binding to be present
in order for authentication to succeed.

However, if nobody else finds this property favorable, I'll drop it.
It would simplify the protocol, since the "Native Channel Binding"
flag can be dropped, including the complexity related to it.  This is
probably a good thing.

>>    For TLS, the channel binding data is specified in the next section.
>>    For other security layers, channel binding data will have to
>>    specified elsewhere, and this specification will have to be updated
>>    with explicit considerations.
>> 
>>    [[All channel bindings should go into a separate document.]]
>
> I've resubmitted draft-ietf-nfsv4-channel-bindings-04.txt, it doesn't
> have quite the txt below, but we can modify it.
>
>> 5.1.  Name Of Tls Channel For Use As Channel Binding

Ok, excellent!  I'll review it, and the next GS2 version should
reference it instead.

Thanks,
Simon