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