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

On Tuesday, October 09, 2007 03:59:31 PM -0400 Sam Hartman 
<hartmans-ietf@mit.edu> wrote:

>>>>>> "Simon" == Simon Josefsson <simon@josefsson.org> writes:
>
>     Simon> Sam Hartman <hartmans-ietf@mit.edu> writes:
>     >> The draft looks quite good, but there are a few things that
>     >> need to be resolved before I can last call it.
>
>     Simon> Thanks for your review!
>
> Your proposed fixes look good except for the following:
>     >> It also appears to violate the requirement that the name of the
>     >> channel type be used in the channel binding data.
>
>     Simon> I believe you are referring to this requirement:
>
>     Simon>       * The name of the type of channel binding MUST be
>     Simon> used by the application and/or authentication protocol to
>     Simon> avoid ambiguity about which of several possible types of
>     Simon> channels is being bound.  If nested instances of the same
>     Simon> type of channel are available then the innermost channel
>     Simon> MUST be used.
>
>     Simon> I thought that channel binding data had to contain a unique
>     Simon> prefix which would appears to solve that problem, without
>     Simon> having to require that protocols encode the channel binding
>     Simon> type too.  If my assumption is correct, it would be useful
>     Simon> to clarify this in d-w-on-channel-binding.  No change in
>     Simon> GS2 seems necessary.  Nico?
>
> I thought it was the responsibility of the application|framework to
> add the unique prefix.  The channel binding base draft provides a
> registry for this prefix, but I thought that the channel binding
> description did not include this prefix and left it up to the
> application.  If the channel binding format must include the prefix
> then I think we need to change the channel binding base draft.
>
> Comments?

I think the base draft is almost perfectly unclear on this issue.  The 
requirement Simon quotes makes it clear that the channel type must be 
communicated and that the application must use it to determine which 
channel's bindings are acutally in use, but says nothing about whether the 
communication is up to the application or by virtue of the channel binding 
data being self-identifying.

Another listed requirements is this:

   o  The channel bindings for a given type of secure channel MUST be
      constructed in such a way that an MITM could not easily force the
      channel bindings of a given channel to match those of another.

On the one hand, this suggests that channel bindings are _not_ inherently 
self-identifying, but at the same time, it imposes a requirement that is 
most easily met by making them so.  In addition, there are many places 
where the base document refers to the channel type name as a "prefix", 
implying that all channel bindings would start with a channel type name.

So, I think we need to update the base document to be clear on what should 
happen here.  I believe that correct behavior requires that channel types 
be identified in a consistent way for all channels, so this cannot be up to 
the individual channel type specifications.  It could be done on a 
per-application basis, but I see no benefit to doing so rather than using 
the same method for all applications.

-- Jeff

PS: IIRC, draft-williams-on-channel-bindings has already been approved and 
is awaiting publication as an RFC.  If it needs to change in order to 
address this issue, maybe someone should give the RFC Editor a heads up?

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