I think this is ok, but my email client isn't distinguishing the new vs. old
text.
If it's just changes to produce this new bullet, I have a small edit:
o Channel binding MUST be used for all application authentication.
The EAP server MUST either require that the correct EAP lower-layer
attribute or another attribute indicating the purpose of the authentication
be present in the channel binding data for application authentication.
"MUST either require that" --> "MUST require that either"
Thanks,
--David
From: Joseph Salowey (jsalowey) [mailto:jsalowey(_at_)cisco(_dot_)com]
Sent: Wednesday, June 19, 2013 7:23 PM
To: Black, David
Cc: stefan(_dot_)winter(_at_)restena(_dot_)lu; General Area Review Team;
abfab(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
Thanks for the text, some revision to address
On Jun 18, 2013, at 12:34 PM, "Black, David"
<david(_dot_)black(_at_)emc(_dot_)com<mailto:david(_dot_)black(_at_)emc(_dot_)com>>
wrote:
[Joe] Good points, the text can be more specific:
"In environments where EAP is used for purposes other than network access
authentication all EAP servers MUST enforce channel bindings. For application
authentication, the EAP server MUST require that the correct EAP lower-layer
attribute be present in the channel binding data. For network access
authentication, the EAP server MUST require that if channel bindings are
present they MUST contain the correct EAP lower-layer attribute. All network
access EAP peer implementations SHOULD use channel bindings including the EAP
lower-layer attribute to explicitly identify the reason for authentication.
Any new usage of EAP MUST use channel bindings including the EAP lower-layer
attribute to prevent confusion with network access usage. "
This is looking good, modulo Sam's comment on EAP lower-layer vs. something
else that I'll leave to you and he to sort out. I have a suggested rewrite,
mostly to clarify MUST vs. SHOULD requirements for support vs. usage, and
to reformat into a structured bullet list of requirements (this is not
intended to change any requirements from what you wrote):
"In environments where EAP is used for purposes other than network access
authentication:
o All EAP servers and all application access EAP peers MUST
support channel bindings. All network access EAP peers
SHOULD support channel bindings.
o Channel binding MUST be used for all application authentication.
The EAP server MUST require that the correct EAP lower-layer
attribute be present in the channel binding data for
application authentication.
o Channel binding MUST be used for all application authentication.
The EAP server MUST either require that the correct EAP lower-layer
attribute or another attribute indicating the purpose of the authentication
be present in the channel binding data for application authentication.
o Channel binding SHOULD be used for all network access authentication,
and when channel binding data is present, the EAP server MUST
require that it contain the correct EAP lower-layer attribute
to explicitly identify the reason for authentication.
o Any new usage of EAP MUST use channel bindings including the
EAP lower-layer attribute to prevent confusion with network
access usage.
Thanks,
--David
-----Original Message-----
From: Joseph Salowey (jsalowey)
[mailto:jsalowey(_at_)cisco(_dot_)com<http://cisco.com>]
Sent: Tuesday, June 18, 2013 1:47 PM
To: Black, David
Cc:
stefan(_dot_)winter(_at_)restena(_dot_)lu<mailto:stefan(_dot_)winter(_at_)restena(_dot_)lu>;
General Area Review Team;
abfab(_at_)ietf(_dot_)org<mailto:abfab(_at_)ietf(_dot_)org>;
ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>
Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
I think we could state this a bit better as something like:
"In environments where EAP is used for applications authentication and network
access authentication all EAP servers MUST understand channel bindings and
require that application bindings MUST be present in application
authentication and that application bindings MUST be absent in network
authentication. All network access EAP peer implementations SHOULD support
channel binding to explicitly identify the reason for authentication. Any new
usage of EAP MUST support channel bindings to prevent confusion with network
access usage. "
That text is an improvement, and it's headed in the same direction as Sam's
comment - "application bindings MUST be present in application authentication"
is a "MUST use" requirement, not just a "MUST implement" requirement.
OTOH, I'm not clear on what "application bindings" means, as that term's not
in the current draft. Specifically, I'm a bit unclear on "application bindings
MUST be absent in network authentication" - does that mean that channel
binding must be absent, or that channel binding is optional, but if channel
binding is present, it MUST NOT be an "application binding", whatever that
is?
[Joe] Good points, the text can be more specific:
"In environments where EAP is used for purposes other than network access
authentication all EAP servers MUST enforce channel bindings. For application
authentication, the EAP server MUST require that the correct EAP lower-layer
attribute be present in the channel binding data. For network access
authentication, the EAP server MUST require that if channel bindings are
present they MUST contain the correct EAP lower-layer attribute. All network
access EAP peer implementations SHOULD use channel bindings including the EAP
lower-layer attribute to explicitly identify the reason for authentication.
Any new usage of EAP MUST use channel bindings including the EAP lower-layer
attribute to prevent confusion with network access usage. "
Does this help?
Thanks,
Joe