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

On Thu, 11 Oct 2007, Nicolas Williams wrote:

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

I'm fine with taking a neutral position, just not an unclear one. The
problem I see today is that an application protocol designer may assume
that the channel bindign data is self-identifying; that is, that the
base channel binding document describes a single octet string containing
the prefix.  But the present document does _not_ describe a single octet
string; it describes a prefix and an octet string separately, and does not
specify how to combine them, except by calling the one a "prefix", which
is just vague enough to convince the casual reader that it's obvious what
to do.  After all, we didn't notice the problem until Simon tried to
define an application, and he's probably more aware of the issue than
most.

So, I think we need to do one of three things:

(1) Require that the prefix and data always be combined in a particular
    way, resulting in a single octet string for the application to work
    with(*).

(2) Specify a particular way of combining the prefix and data, for use
    when the application wants or needs to work with a single octet
    string.  Indicate that it is up to the application whether to use
    this method or treat the prefix and data separately.

(3) Clearly indicate that the prefix and data are separate, and that
    it is up to the application whether to handle them separately or
    together.

Especially in case (3), I think a lot of the ambiguity can be removed by
not using the word "prefix", which implies a particular approach to
combining what are really two separate protocol elements.  This usage
seems to be an artifact of how channel bindings are expected to be
transported in GSS-API and not really something that belongs in a generic
document.

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

This sort of assumes that the "obvious" thing to do is prfix the name to
the data, rather than treating them separately.  That sssumption seems
flawed to me, and the source of much confusion.

-- Jeff

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