Skip to main content

Last Call Review of draft-ietf-abfab-eapapplicability-03
review-ietf-abfab-eapapplicability-03-genart-lc-black-2013-06-18-00

Request Review of draft-ietf-abfab-eapapplicability
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-06-17
Requested 2013-06-06
Authors Stefan Winter , Joseph A. Salowey
I-D last updated 2013-06-18
Completed reviews Genart Telechat review of -05 by David L. Black (diff)
Genart Last Call review of -03 by David L. Black (diff)
Assignment Reviewer David L. Black
State Completed
Request Last Call review on draft-ietf-abfab-eapapplicability by General Area Review Team (Gen-ART) Assigned
Reviewed revision 03 (document currently at 06)
Result Ready w/issues
Completed 2013-06-18
review-ietf-abfab-eapapplicability-03-genart-lc-black-2013-06-18-00
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.black at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------