In reading this draft (-09 version) I came up with a few questions and comments: Section 3 - Section 3 is a bit confusing it seems that much of the text is section 3.1 (detailed description of exchanges) should go into section 3.0 because it seems that much of the process should be the same for local or remote cases. Currently it is difficult to really tell what pertains to local, remote and both. It does not appear to be clear how the peer knows if it is in the "home" case or the "local" case, whether the network is capable of ERX (and vice versa) or how the peer knows what key to use. Perhaps I missed this elsewhere in the document. Section 4 - Section 4.1.1 duplicates text in internet-drafts/draft-ietf-hokey-emsk-hierarchy-03.txt. It really should not. It should reference KDF functions instead of PRFs. I believe if you replace prf+ with KDF it would be fine. Do you want to use the naming defined in internet-drafts/draft-ietf-hokey-emsk-hierarchy-03.txt or are you specifying your own? Are these key names really necessary? They do no appear to be used anywhere? Why such a long key label? Section 5 - Section 5.1 What state are you referencing here? I don't think the CalledStation-ID is what you want to reference, I believe RADIUS routing is typically done with the username when EAP is used. Why is it only RECOMMENDED to maintain this state? It seems either it is a MUST or it doesn't matter. In general authenticators do not do routing, AAA does routing. Authenticators copy the correct attributes from EAP into the correct attributes in the AAA message. This seems much more complicated (routing, multiple attributes TLVs etc). Its not clear if the 3 sub-bullets of the first bullet refer to what the authenticator needs to do or the peer needs to do. It seems that the authenticator should be able to extract a single field from the peer message to determine what to do with it. Either it will handle it locally or it will pass the message within the AAA protocol copying the appropriate field into the message. Is the integrity checksum a keyed hash or MAC (if so why use another term?)? If so what key is used? If a key is used in the context in the packet enough to determine the key? Is it possible that more that one EMSK has been generated by the same peer? Why must the authenticator rely upon the information cached from the EAP exchange, isn't there enough information in ERX messages? The whole routing section is complex and is not something that authenticators generally do now. Why do you need an alternate to R1KName-NAI? Why is the peer name necessary? Why isn't a R1KName an NAI? Should the R1Kname sent by the server match the one sent by the client? Section 5.1.1 It seems there is another option other than obtaining a DSRK from the home domain, you may retrieve the rRK derived from the DSRK. There are also key distribuiton attributes for RADIUS defined in http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt and http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-08.txt. Is there a reason why we need to diverge? Section 5.2 Ditto of most of the concerns in 5.1/5.1.1. Do we need two sections? Section 5.3 It would be helpful if the identity field (R1Kname-NAI) was in a deterministic place within the packet so the authenticator has less work to do to extract it. I don't see why peer name is useful (or R1Kname-TLV). -----Original Message----- From: The IESG [mailto:iesg-secretary@xxxxxxxx] Sent: Thursday, January 24, 2008 8:13 AM To: IETF-Announce Cc: hokey@xxxxxxxx Subject: Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard The IESG has received a request from the Handover Keying WG (hokey) to consider the following document: - 'EAP Extensions for EAP Re-authentication Protocol (ERP) ' <draft-ietf-hokey-erx-08.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@xxxxxxxx mailing lists by 2008-02-07. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-hokey-erx-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag= 15997&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf