Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments

[Nicolas Williams <[e-mail]>]

On Wed, Oct 10, 2007 at 01:52:20PM -0400, Jeffrey Hutzelman wrote:
> On Wednesday, October 10, 2007 06:38:11 PM +0200 Simon Josefsson 
> <[e-mail]> wrote:
> >No, it wasn't about APIs, it was about what is sent in the
> >"channel_binding_data" field over the wire.  If the current text in GS2
> >is not sufficient to build interoperable implementations, I'd appreciate
> >suggestions on what it has to say.

The on-channel-binding I-D doesn't say that the channel binding data is
sent -- there is not "channel_binding_data field" as such.  The
authentication mechanism must verify that the channel bindings match on
both ends, but that need not mean sending the channel binding data.

> Well, you brought up the question of whether the channel binding data 
> includes the prefix or not, and that's what we've been discussing.  So yes, 
> the document is insufficiently clear.  But the length of the ensuing 
> discussion does not mean that there is a major flaw; it just means that 
> we've examined the issue carefully before determining what it should say. 
> Now there will be additional discussion to determine how it should say it.

I'm not sure that there's any ambiguity:

      *  The name of the type of channel binding MUST be used by the
	 application and/or authentication protocol to avoid ambiguity
	 about which of several possible types of channels is being
	 bound.  If nested instances of the same type of channel are
	 available then the innermost channel MUST be used.

Now, GS2 *could* have a separate "slot" in the protocol for "channel
binding type name" and "channel binding data."  The GSS-API, OTOH, does
not provide such a slot, so GSS applications MUST prefix the channel
binding type name to the channel binding data in order to obtain a
single octet string that can be passed to GSS_Init_sec_context() or
GSS_Accept_sec_context().

So I think we really don't want to make any changes here.  Simon and the
SASL WG need to decide whether GS2 needs such a separate slot.  The
on-channel-bindings I-D is neutral on that issue.

Also, GS2 need not say who is responsible for determining the channel
binding data and type.  You could have a fully integrated channel and
authentication API that hides all these details from the application,
but you could also have disparate and unrelated channel and
authentication APIs, in which case the application is responsible for
determining the channel binding data and type.  Both are equally
acceptable, so on-channel-binding says nothing about them.

> Provided we clarify in draft-williams-on-channel-bindings that channel 
> binding data includes the prefix, there is no problem with the protocol 
> bits in GS2.  However, you are missing a requirement to check that the 
> channel binding data sent by the client and server is actually the same. 
> In fact, you provide virtually no information on what to do with the data 
> elements related to channel binding.  I think this needs some work.

I now believe that no such clarification is needed.  We may want to
clarify that application protocols using channel binding must specify
how the prefix is used, and we may want to suggest using it as, well, a
prefix (with a separator character), in those cases where a single
string is accepted by the authentication framework/mechanism.

Nico
-- 

_______________________________________________
CHANNEL-BINDING mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/channel-binding