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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx mailing lists by 2007-04-11. Exceptionally, comments may be sent to iesg@xxxxxxxx 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf-announce


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]