Hello, I believe this is a well organized and complete document. On numerous occasions while reviewing it I made a mental question regarding something only to have the question answered in a subsequent paragraph. I do have several comments though: 1. this protocol can be used in the presence of AAA proxies. Due to the nature of AAA proxies a peer or authenticator may not even know whether they are part of the communication chain. Therefore, from the view of a security threat their presence must be assumed by the peer and authenticator. The Domain referred to in section 2 (part of the EMSK key hierarchy draft) specifically allows for proxies as part of the distributed system of computers that define the Domain. This brings up many significant issues that are not addressed in this draft. - It cannot be claimed that a key is being bound to its context when the context cannot even be scoped. (Section 6) - The domino effect is not prevented because compromise of a proxy will compromise keying material on (other) authenticators. - A pairwise key is being given by one of the entities that share it, e.g. the server, to a 3rd entity, e.g. a proxy, without the consent of the other peer that shares the key, e.g. the peer. This brings up security considerations that are not discussed. - During discussions at a HOKEY meeting and on the list the rationale that justified proxies was that the peer is more concerned about receiving network access (which is confirmed in the ERP document when it says, "The primary purpose [of ERP] is network access control.") than about specifically authenticating "the network". Provided that service is obtained with no surprises in the bill at the end of the month the rationale was that the peer didn't care if the key was distributed to proxies if it was necessary to continue to provide network access. Which is a reasonable rationale. But it needs to be mentioned in this document. It has a unique threat model that is not discussed anywhere. - The aforementioned rationale begs the question of why have "Domain Specific Keys". If the peer doesn't care whether proxies have a key, potentially for a different domain, then it doesn't care about key separation between domains. This is significant added complexity for no benefit. - RFC4962 REQUIRES things-- bind key to its context, prevent the domino effect-- that ERP cannot support. ERP is a AAA key management protocol though and falls under the scope of RFC4962. There needs to be justification for why ERP is not meeting the mandatory requirements of RFC4962. I think all of these issues need addressing before advancement of this Internet-Draft. 2. Inter-Domain ERP It is this reviewers recollection that consensus was reached in HOKEY to require a peer to reauthenticate back to the home AAA server every time it attached to a POP in different domain. Therefore, I wonder why a "Domain-Specific" key, the DSRK, and all it's progeny-- DS-rIK, DS-rRK, DSUSRK, etc.-- continue to be used by this protocol. A "HOKEY-KEY", a USRK, should be derived from the EMSK and that is the key given, through proxies if need be, to the ER server in the visited domain. If the peer goes to a different domain then it does a full reauthentication resulting in a _new_ USRK, that has no relation to the previous USRK, being given to the ER server in the new domain. Again, it was my understanding that the group already reached consensus on this matter. 3. HMAC-SHA256 as a key naming technique SHA-256 is a computationally intensive operation; HMAC-SHA256 doubly so. There should, therefore, be some justification to use such a strong cryptographic mixing function if all one wants to do is "uniquely name a key". EAP methods export a Session-ID. An rIK can be named by the concatenation of Session-ID and "rIK". Similarly for the rMSK, rRK and the other keys being generated in ERP. This has the added benefit of allowing for key management to quickly identify keys based on common queries-- all the keys for a specific Session-ID, or all rIKs held by a particular entity. By using a strong cryptographic mixing function all specificity of the key names has been lost across every single key hierarchy that a HOKEY server may end up managing. This is a really bad idea and it should be changed before this Internet-Draft is advanced. 4. Section 5.3.2 EAP-Initiate/Re-Auth Packet This packet has the following field: +-+-+-+-+-+-+-+-+ |R|B|L| Reserved| +-+-+-+-+-+-+-+-+ And "R" is, itself, reserved. This makes no sense. Please << 1 this field. regards, Dan. _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf