[abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03

["Black, David" <[e-mail]>]

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
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------