Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-radext-ieee802ext-10

From: Jari Arkko <[email-masked]>
Date: Wed, 26 Mar 2014 14:55:09 +0800

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 26 Mar 2014 11:41:30 +0200

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Mar 2014 08:17:53 -0400

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" <[email-masked]> wrote:
> 
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Mar 2014 23:18:52 -0500

I'm satisfied with the responses. I think it would not hurt to add some of the explanations from the various emails into the draft, but that's by no means a show stopper.

Thanks!

Ben.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 27 Mar 2014 09:04:24 +0200

Thanks, I have placed a no-obj position on the ballot. I agree with Ben that additional explanation might be useful.

Jari