Re: Last Call: draft-williams-on-channel-binding (On the Use of Channel Bindings to Secure Channels) to Proposed Standard

[Lakshminath Dondeti <ldondeti at qualcomm.com>]

I think this draft is not ready for publication (I will respond 
separately on the applicability of this work to EAP channel binding): it 
is too abstract to the extent that it is confusing.  It is hard to keep 
track of the words channel binding and channel bindings, difficult to 
associate them with the descriptions, definitions and requirements, and 
finally map them to the variety of cases where the lower layer security 
channel is authenticated, partially authenticated or unauthenticated.

Some of the text is vague, for instance, in various places the goal is 
stated as "to avoid man-in-the-middle vulnerabilities."  I think it is 
important to be more precise than that.  Elsewhere in the document the 
motivation is clearer.

Some of the observations such as "For example, while IPsec [RFC4301] 
[RFC4303]
   [RFC4302] is amenable to being accelerated in hardware to handle very
   high link speeds, but IPsec key exchange protocols and the IPsec
   architecture are not as amenable to use as a security mechanism
   within applications, particularly applications that have users as
   clients. " don't belong in the document.  We can get into a debate 
on the correctness of that statement, but there's simply no point to 
that debate in the context of this document.

Other motivating factors such as better leveraging hardware 
implementations of crypto protocols are not universally applicable.

In Section 2.1, a requirement is stated as "MUST NOT leak secret 
information about the channel."  What is the secret information about 
the channel?

I didn't understand the "SHOULD" in "Applications SHOULD use mutual 
authentication at the application layer ..."   Is the premise that 
clients authenticate at the application layer and the other parties 
(servers, IPsec responders etc) authenticate at the network layer?

On "End-point channel bindings where the end-points are meaningful
      names SHOULD NOT be used when the channel does not provide
      confidentiality protection and privacy protection is desired." 
Does privacy refer to identity protection?  If so, "SHOULD provide for 
the use of a digest" doesn't seem appropriate.  Various mechanisms for 
identity privacy exist and there is no reason to RECOMMEND one mechanism.

In Section 8.1, I didn't understand the notion of mitigating 
impersonation by requiring confidentiality protection of secure 
channels.  Surely I am misunderstanding.  Please clarify.

Publication track:  Why is this document in "Proposed Standard" track? 
Perhaps a BCP might be more appropriate?

Editorial nits:

There are a bunch of dangling pointers that need to be fixed (Sec 2 and 
Sec 2.1); some typos (Page 7 in item 4) as well.

Overall, if the scope is limited to what's in the current version, 
perhaps the document will be ready after a revision and a re-review.

thanks,
Lakshminath


The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'On the Use of Channel Bindings to Secure Channels '
>    <draft-williams-on-channel-binding-01.txt> as a Proposed Standard
>
>    The introduction of this draft implies that the facility being
>   discussed applies only to GSS-API.  That is not the case and the rest
>    of the draft is clear on this point; this draft proposes to generalize
>    and clarify a facility that exists today in GSS-API both for GSS-API
>    use and for other authentication frameworks.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf at ietf.org mailing lists by 2007-04-11. Exceptionally, 
> comments may be sent to iesg at ietf.org instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-williams-on-channel-binding-01.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15078&rfc_flag=0
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce at ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf