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(_dot_)org mailing lists by 2007-04-11. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)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(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf