Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-05
"Black, David" <david.black@emc.com> Fri, 12 July 2013 15:04 UTC
Return-Path: <david.black@emc.com>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534A511E810E; Fri, 12 Jul 2013 08:04:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.477
X-Spam-Level:
X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFaD0y+EAbNI; Fri, 12 Jul 2013 08:04:37 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1381811E811A; Fri, 12 Jul 2013 08:04:32 -0700 (PDT)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6CF4Cqn004158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 11:04:13 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 12 Jul 2013 11:04:04 -0400
Received: from mxhub17.corp.emc.com (mxhub17.corp.emc.com [10.254.93.46]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6CF43ka003859; Fri, 12 Jul 2013 11:04:03 -0400
Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Fri, 12 Jul 2013 11:04:03 -0400
From: "Black, David" <david.black@emc.com>
To: "stefan.winter@restena.lu" <stefan.winter@restena.lu>, "jsalowey@cisco.com" <jsalowey@cisco.com>, General Area Review Team <gen-art@ietf.org>
Date: Fri, 12 Jul 2013 11:04:01 -0400
Thread-Topic: Gen-ART review of draft-ietf-abfab-eapapplicability-05
Thread-Index: Ac5rzQ3h5Vr98eb9RParuraCHgwUcgQTfgIgAL1zdeA=
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712983F32EC@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712983F2C87@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712983F2C87@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: "abfab@ietf.org" <abfab@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "Black, David" <david.black@emc.com>
Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-05
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/abfab>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jul 2013 15:04:41 -0000
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@restena.lu; jsalowey@cisco.com; General Area > Review Team > Cc: ietf@ietf.org; abfab@ietf.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.winter@restena.lu; jsalowey@cisco.com; General Area Review Team > > Cc: ietf@ietf.org; abfab@ietf.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.black@emc.com Mobile: +1 (978) 394-7754 > > ----------------------------------------------------
- [abfab] Gen-ART review of draft-ietf-abfab-eapapp… Black, David
- Re: [abfab] Gen-ART review of draft-ietf-abfab-ea… Sam Hartman
- Re: [abfab] Gen-ART review of draft-ietf-abfab-ea… Black, David
- Re: [abfab] Gen-ART review of draft-ietf-abfab-ea… Joseph Salowey (jsalowey)
- Re: [abfab] Gen-ART review of draft-ietf-abfab-ea… Black, David
- Re: [abfab] Gen-ART review of draft-ietf-abfab-ea… Joseph Salowey (jsalowey)
- Re: [abfab] Gen-ART review of draft-ietf-abfab-ea… Sam Hartman
- Re: [abfab] Gen-ART review of draft-ietf-abfab-ea… Black, David
- Re: [abfab] Gen-ART review of draft-ietf-abfab-ea… Joseph Salowey (jsalowey)
- Re: [abfab] Gen-ART review of draft-ietf-abfab-ea… Joseph Salowey (jsalowey)
- Re: [abfab] Gen-ART review of draft-ietf-abfab-ea… Sam Hartman
- Re: [abfab] Gen-ART review of draft-ietf-abfab-ea… Black, David
- [abfab] Gen-ART review of draft-ietf-abfab-eapapp… Black, David
- Re: [abfab] Gen-ART review of draft-ietf-abfab-ea… Black, David
- Re: [abfab] [Gen-art] Gen-ART review of draft-iet… Jari Arkko