Thanks Miguel,

(cc'ing gen-art to close that loop)

S.

On 02/08/2012 02:01 PM, Miguel A. Garcia wrote:
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"<[email protected]>
To: "Tina TSOU"<[email protected]>
Cc:<[email protected]>;<[email protected]>
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"<[email protected]> 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<[email protected]>
To: Zhen Cao<[email protected]>, Hui Deng<[email protected]>,
[email protected], Stephen Farrell<[email protected]>
CC: General Area Review Team<[email protected]>

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"

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 [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.


/Miguel
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
HOKEY mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hokey

_______________________________________________
HOKEY mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hokey

_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to