Re: [HOKEY] Fwd: Gen-ART review of draft-ietf-hokey-erp-aak-07

["Miguel A. Garcia" <[e-mail]>]

I did a quick past to the changes that I requested, and I think they are 
successfully implemented in version -08.

/Miguel

On 08/02/2012 13:52, Qin Wu wrote:
> Hi, Stephen and all:
> We have just done the update. Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-hokey-erp-aak-08
>
> Would you like to go ahead?
>
> Regards!
> -Qin
> ----- Original Message -----
> From: "Stephen Farrell"<[e-mail]>
> To: "Tina TSOU"<[e-mail]>
> Cc:<[e-mail]>;<[e-mail]>
> Sent: Wednesday, February 08, 2012 7:41 PM
> Subject: Re: [HOKEY] Fwd: Gen-ART review of draft-ietf-hokey-erp-aak-07
>
>
>>
>> Hi,
>>
>> IETF LC is ended for this.
>>
>> I think the only comment I saw a gen-art review (is
>> that right?) but that there are changes resulting from
>> that so I've marked this as revised I-D needed. Please
>> submit a -08 that includes the changes needed. (I'm not
>> sure if any of those will require something different
>> from IANA, but if they do please also respond to IANA's
>> mail, cc'ing me, if their actions are changed.)
>>
>> As soon as we have that I can put this on an IESG
>> telechat agenda,
>>
>> Thanks,
>> Stephen.
>>
>>
>> On 02/04/2012 07:21 PM, Tina TSOU wrote:
>>> Good catch. Thank u, Miguel.
>>>
>>> Sent from my iPad
>>>
>>> On Feb 2, 2012, at 7:04 AM, "Stephen Farrell"<[e-mail]>   wrote:
>>>
>>>>
>>>> FYI
>>>>
>>>> -------- Original Message --------
>>>> Subject: Gen-ART review of draft-ietf-hokey-erp-aak-07
>>>> Date: Thu, 2 Feb 2012 15:51:36 +0100
>>>> From: Miguel A. Garcia<[e-mail]>
>>>> To: Zhen Cao<[e-mail]>, Hui Deng<[e-mail]>, [e-mail], Stephen Farrell<[e-mail]>
>>>> CC: General Area Review Team<[e-mail]>
>>>>
>>>> I have been selected as the General Area Review Team (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 comments you may receive.
>>>>
>>>> Document: draft-ietf-hokey-erp-aak-07
>>>> Reviewer: Miguel Garcia<[e-mail]>
>>>> Review Date: 2011-01-02
>>>> IETF LC End Date: 2012-02-07
>>>>
>>>> Summary: This draft is on the right track but has open issues, described
>>>> in the review.
>>>>
>>>> Major issues:
>>>>
>>>> - None
>>>>
>>>> Minor issues:
>>>>
>>>> - The main problem I have with this draft is the lack of normative text
>>>> (RFC 2119 reserved words) in relevant paragraphs. If interoperability is
>>>> to be granted, an effort should be taken in adding quite a few more
>>>> normative statements.
>>>>
>>>> However, having said that, the section where I find more that there
>>>> should be more normative text, is Section 3, which is an "Overview"
>>>> section. In general, an overview section should use descriptive, but not
>>>> normative text.
>>>>
>>>> For example, take the last paragraph in Page 5 (that continues to Page
>>>> 6). One possible change is to make normative the text and move it outside
>>>> a section whose title is "Overview".
>>>>
>>>>     Upon receiving the message, the ERP/AAK server MUST first use the
>>>>     keyName indicated in the keyName-NAI to look up the rIK and MUST
>>>>     check the integrity and freshness of the message. Then the ERP/AAK
>>>>     server MUST verify the identity of the peer by checking the username
>>>>     portion of the KeyName-NAI.  If any of the checks fail, the server
>>>>     MUST send an early- authentication finish message (EAP-Finish/Re-auth
>>>>     with E-flag set) with the Result flag set to '1'.  Next, the server
>>>>     MUST authorize the CAP specified in the CAP-Identifier TLV.  In
>>>>     success case, the server MUST derive a pMSK from the pRK for each CAP
>>>>     carried in the the CAP-Identifier field using the sequence number
>>>>     associated with CAP-Identifier as an input to the key derivation.
>>>>     (see d. in the figure 1).
>>>>
>>>>     Then the ERP/AAK server MUST transport the pMSK to the authorized CAP
>>>>     via AAA Section 7 as described in figure 2 (see e.1,e.2 in the figure
>>>>     2). Note that key distribution in the figure 2 is one part of step d.
>>>>     in the figure 1.
>>>>
>>>> The the last paragraph in Section 3 also contains an "Optionally", which
>>>> I believe should be replaced with a capitalized "OPTIONAL"
>>>>
>>>> Another instance: towards the end of Section 5.2, the text reads:
>>>>
>>>>     HMAC-SHA256-128 is mandatory to implement and should be enabled in
>>>>     the default configuration.
>>>>
>>>> and should probably be:
>>>>
>>>>     HMAC-SHA256-128 is REQUIRED to be implemented and SHOULD be enabled in
>>>>     the default configuration.
>>>>
>>>> Similarly, the last paragraph in Section 5.2 reads:
>>>>
>>>>     If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is
>>>>     discarded silently.
>>>>
>>>> and should probably be:
>>>>
>>>>     If the EAP-Initiate/Re-auth packet is not supported by the SAP, it
>>>>     SHOULD be discarded silently.
>>>>
>>>>
>>>>
>>>> - Another topic, Section 9 (IANA Considerations) reads:
>>>>
>>>>     Further, this document registers a Early authentication usage label
>>>>     from the "USRK Key Labels" name space with a value:
>>>>
>>>>        EAP Early-Authentication Root [e-mail]
>>>>
>>>>
>>>> I am missing the sentence to name the master registry where the USRK Key
>>>> Labels subregistry is stored. This is the Extended Master Session Key
>>>> (EMSK) Parameters registry (I guess). And probably this comment is also
>>>> valid for the rest of the IANA actions: the main registry is not named,
>>>> and it is hard to find it.
>>>>
>>>>
>>>> /Miguel
>>>> --
>>>> Miguel A. Garcia
>>>> [phone]
>>>> Ericsson Spain
>>>> _______________________________________________
>>>> HOKEY mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/hokey
>>>
>> _______________________________________________
>> HOKEY mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hokey

-- 
Miguel A. Garcia
[phone]
Ericsson Spain