Re: [Gen-art] Gen-ART LC Review of draft-ietf-radext-ieee802ext-10
Bernard Aboba <bernard_aboba@hotmail.com> Wed, 26 March 2014 12:17 UTC
Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEE71A0067 for <gen-art@ietfa.amsl.com>; Wed, 26 Mar 2014 05:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skwxClEdMyvF for <gen-art@ietfa.amsl.com>; Wed, 26 Mar 2014 05:17:56 -0700 (PDT)
Received: from blu0-omc2-s4.blu0.hotmail.com (blu0-omc2-s4.blu0.hotmail.com [65.55.111.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC4D1A0039 for <gen-art@ietf.org>; Wed, 26 Mar 2014 05:17:56 -0700 (PDT)
Received: from BLU406-EAS63 ([65.55.111.71]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Mar 2014 05:17:54 -0700
X-TMN: [+E1P1Of8mnFTqy5x4L+tQXQiBlYNBR1c]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU406-EAS63EE021E0D191EB124819B93640@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
References: <8C9EE7F2-AA3D-482A-B469-4A147D143954@nostrum.com> <530F38BE.3030508@cisco.com> <0B1AE081-091D-4EEE-A658-D0D80998EC0E@piuha.net> <DD025780-6108-44DF-9226-0535B6089204@gmail.com>
From: Bernard Aboba <bernard_aboba@hotmail.com>
MIME-Version: 1.0 (1.0)
In-Reply-To: <DD025780-6108-44DF-9226-0535B6089204@gmail.com>
Date: Wed, 26 Mar 2014 08:17:53 -0400
To: Jouni Korhonen <jouni.nospam@gmail.com>
X-OriginalArrivalTime: 26 Mar 2014 12:17:54.0397 (UTC) FILETIME=[6A3E98D0:01CF48ED]
Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/zcEG3iRQ_78JaSNKLR_-bbewKqI
Cc: Benoit Claise <bclaise@cisco.com>, Ben Campbell <ben@nostrum.com>, "gen-art@ietf.org Team (gen-art@ietf.org)" <gen-art@ietf.org>, "draft-ietf-radext-ieee802ext.all@tools.ietf.org" <draft-ietf-radext-ieee802ext.all@tools.ietf.org>
Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-radext-ieee802ext-10
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Mar 2014 12:17:59 -0000
In 802.1X-2010, the EAP Key Name is actually needed to calculate the session keys. So if it is unavailable, the NAS won't be able to decrypt traffic. Therefore treating the Accept as a Reject is probably the only viable option. > On Mar 26, 2014, at 5:42 AM, "Jouni Korhonen" <jouni.nospam@gmail.com> wrote: > > > I don't think there is anything that needs to be done for 2.2. It is > a normal capability exchange type of mechanism. > > The text is IMHO clear: > "in situations where the Attribute is required to provision service.." > > Then the lack of EAP-Key-Name means the service cannot be provisioned > and the NAS can safely interpret that as an Access-Reject, when > appropriate by the deployment. > > NAS doesn't include the attribute if it is not needed. And if it does, > the current text allows still accepting the service regardless the > lack of the attribute in the Access-Accept. > > > - Jouni > > >> On Mar 26, 2014, at 8:55 AM, Jari Arkko <jari.arkko@piuha.net> wrote: >> >> Thanks for the review. I did not see a response or change regarding 2.1 or 2.2. Does this need to be addressed? Authors? >> >> Jari >> >>> On Feb 27, 2014, at 9:08 PM, Benoit Claise <bclaise@cisco.com> wrote: >>> >>> Dear authors, >>> >>> Can you please follow up on that one. >>> >>> Regards, Benoit >>>> 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-radext-ieee802ext-10 >>>> Reviewer: Ben Campbell >>>> Review Date: 2014-01-31 >>>> IETF LC End Date: 2014-02-04 >>>> >>>> Summary: This draft is almost ready for publication as a standards track RFC. I have a small number of minor comments that may be worth considering prior to publication. >>>> >>>> Major issues: None >>>> >>>> Minor issues: >>>> >>>> -- 2.1, last paragraph: >>>> >>>> Does the last sentence imply Allowed-Called-Station-Id actually should (or SHOULD) not be used in non-wireless scenarios? (I note that the Network-Id-Name section talks about how 802.1X NID-Names should not be included in Called-Station-Id, but rather put in Network-Id-Name. Does that apply here as well? >>>> >>>> -- 2.2, last paragraph: "Since a NAS will typically only include a EAP-Key-Name Attribute in an Access-Request in situations where the Attribute is required to provision service, if an EAP-Key-Name Attribute is included in an Access-Request but is not present in the Access-Accept, the NAS SHOULD treat the Access-Accept as though it were an Access-Reject. " >>>> >>>> Is there a backwards compatibility issue? What if a NAS sends the field to a server that doesn't implement this draft? Is there an assumption that a NAS that supports this draft will only work with a server that also supports it? >>>> >>>> Or more to the point, is the "...typically only include...where required..." strong enough to require a normative SHOULD? Seems like this would discourage the inclusion of EAP-Key-Name in the non-typical case of it _not_ being required. Is that the intent? >>>> >>>> Nits/editorial comments: >>>> >>>> -- section 2.8: >>>> >>>> It might be worth expanding "EAPoL" >>>> >>>> >>>> >>>> . >>> >>> _______________________________________________ >>> Gen-art mailing list >>> Gen-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/gen-art >
- [Gen-art] Gen-ART LC Review of draft-ietf-radext-… Ben Campbell
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-rad… Benoit Claise
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-rad… Jari Arkko
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-rad… Jouni Korhonen
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-rad… Bernard Aboba
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-rad… Ben Campbell
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-rad… Jari Arkko