Dear Miguel, Thanks for the valuable view, see our replies inline.
Best regards, Zhen On Thu, Feb 2, 2012 at 10:51 PM, Miguel A. Garcia <[email protected]> wrote: > 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 <[email protected]> > 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" [CZ]: Good suggestion, we will revise the draft to reflect this. > > 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. [CZ] Okay. > > 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. > [CZ] Okay. > > - 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 [email protected] > > > 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. [CZ]: EMSK or DSRK lable is defined in the section 8.1 "Key Lables" of RFC5295. We will add reference to RFC5295 to fix this. Thanks. > > > /Miguel > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain -- Best regards, Zhen _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
