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

On Thu, Oct 11, 2007 at 12:33:21PM -0400, Sam Hartman wrote:
> I've become convinced that clarification is needed.
> I'll note that it's simpler if we say there is always one slot and that the
> 	challeng binding data includes the prefix and the separator.

Sure.

There already is a requirement that the name of the channel binding type
must be used to avoid ambiguity (3rd bullet, page 7).

I propose the following addition to that requirement:  "Where the
authentication interfaces provide a slot for channel binding data but no
slot for channel binfing type, then the application MUST prefix the
US-ASCII name of the channel binding type ("prefix"), and a separator
character, ':', to the channel binding data an octet string."

> I think that option is most likely to be interoperable.

The risk in not giving this guidance is that some apps/frameworks will
get this wrong.  I'm not sure that there's risk to interoperability, but
there's no need to argue about that.

> One down side of that option is that there may be people using channel
> bindings with GSS today in a manner that differs from that.

Tough.  But then, there aren't many of them.  Also, the ambiguity is
extremely unlikely to cause any problems, except in nested channel
circumstances.

> It probably is not a big deal since any given application will either
> use this framework or not.

Right.

> However we could be neutral on whether applications need one slot or
> two.  If so, we need to at least say that we're neutral on this.  I
> think we need to at least define a separator to use when you only have
> one slot.

That's my position.  However, if the consensus is that we should take a
less neutral position on this then I would propose this text:

   o In the interests of simplicity it is RECOMMENDED that
     authentication framework/mechanism APIs provide a single slot for
     channel binding data, and none for the name of channel binding
     type.

If we want to stay neutral on this issue we can always add this text:

   o Authentication framework/mechanism APIs MAY provide a slot for name
     of channel binding type that is distinct from a slot for channel
     binding data.  In that case applications MUST NOT prefix the name
     of the channel binding type to the channel binding data and MUST
     instead provide the name of the channel binding type as an input in
     the correct slot.

Nico
-- 

_______________________________________________
CHANNEL-BINDING mailing list
CHANNEL-BINDING@ietf.org
https://www1.ietf.org/mailman/listinfo/channel-binding