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.nos...@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.ar...@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 <bcla...@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 mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
