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.winter@xxxxxxxxxx; jsalowey@xxxxxxxxx; General Area > Review Team > Cc: ietf@xxxxxxxx; abfab@xxxxxxxx > 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.winter@xxxxxxxxxx; jsalowey@xxxxxxxxx; General Area Review Team > > Cc: ietf@xxxxxxxx; abfab@xxxxxxxx; 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.black@xxxxxxx Mobile: +1 (978) 394-7754 > > ----------------------------------------------------