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

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

The -04 version of this draft resolves the minor issue noted in
the Gen-ART review of the -03 version.

There is a remaining editorial nit, in that the one use of
"non-network" in the -04 version would benefit from clarification.
I suggest the following text change to the start of the paragraph
that's split across pages 3 and 4 (change is to last line of excerpt):

OLD
   Operators need to carefully consider the security implications before
   relaxing these requirements.  One potentially serious attack exists
   when channel binding is not required and EAP authentication is
   introduced into an existing non-network service.

NEW
   Operators need to carefully consider the security implications before
   relaxing these requirements.  One potentially serious attack exists
   when channel binding is not required and EAP authentication is
   introduced into an existing service other than network access.
	
Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Monday, June 17, 2013 10:39 PM
> To: [e-mail]; [e-mail]; General Area Review Team
> Cc: [e-mail]; [e-mail]; Black, David
> Subject: Gen-ART review of draft-ietf-abfab-eapapplicability-03
> 
> 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]
> ----------------------------------------------------