RE: Gen-ART review of draft-ietf-abfab-eapapplicability-05

And the -05 version includes the text to address that editorial nit - it's
ready for publication as a Proposed Standard RFC.  Many thanks to the authors
for productively addressing the review comments.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Monday, July 08, 2013 4:44 PM
> To: Black, David; stefan(_dot_)winter(_at_)restena(_dot_)lu; 
> jsalowey(_at_)cisco(_dot_)com; General Area
> Review Team
> Cc: ietf(_at_)ietf(_dot_)org; abfab(_at_)ietf(_dot_)org
> Subject: Gen-ART review of draft-ietf-abfab-eapapplicability-04
>
> 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: stefan(_dot_)winter(_at_)restena(_dot_)lu; 
> > jsalowey(_at_)cisco(_dot_)com; General Area Review Team
> > Cc: ietf(_at_)ietf(_dot_)org; abfab(_at_)ietf(_dot_)org; 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
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > david(_dot_)black(_at_)emc(_dot_)com        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------