I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-abfab-eapapplicability-03
Reviewer: David L. Black
Review Date: June 17, 2003
IETF LC End Date: June 17, 2003
Summary:
This draft is on the right track but has open issues, described in the review.
This draft updates the applicability statement for EAP to include usage
for application layer access via EAP over GSSAPI. Additional security
requirements are introduced for environments in which EAP is used for
that purpose.
I found one open issue, which is minor, and may be editorial
Major issues: None
Minor issues: One
The next to last paragraph on p.3 begins with this sentence:
For these reasons, channel binding MUST be implemented by peers, EAP
servers and AAA servers in environments where EAP authentication is
used to access application layer services.
It appear that this "MUST" requirement applies to all uses of EAP,
including network access authentication, not just application layer access
authentication. If so, that's not immediately obvious from the text, and
an additional sentence should be added to make this clearer. If not,
the above sentence needs to exclude network access authentication from
that requirement.
Nits/editorial comments:
The same paragraph (p.3) continues with:
In addition, channel
binding MUST default to being required by peers for non-network
authentication. If the EAP server is aware that authentication is
for something other than a network service, it too MUST default to
requiring channel binding.
What is meant by "non-network authentication" and "other than a network
service"? If those mean "other than for network access authentication"
as the term "network access authentication" is used in section 1 and
RFC 3748, that meaning should be clarified.
idnits 2.12.17 generated this comment:
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
http://trustee.ietf.org/license-info for more information.)
idnits appears to be confused ;-). The -00 version of this draft is from 2012,
and this draft does not contain sufficient material from RFC 3748 that would
raise that concern, so this comment should be ok to ignore.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david(_dot_)black(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------