Hello again, Pardon my repetition but I have come up with a very valid reason why naming keys using HMAC-SHA-256 is a bad idea. If one wants to administratively remove all keys in a particular key hierarchy (which seems like an entirely reasonable request) one must do a linear search of all keys in all key hierarchies that a particular server maintains! This is because HMAC-SHA-256 has mapped all identifying key information for all key hierarchies to the same name space. It precludes using something like a hash table for fast lookup of all related keys. If keys were named by concatenating the EAP Session-ID with a string that identified the particular key in the key hierarchy rooted at the MK derived in that EAP Session-ID then the EAP Session-ID could be used as an index into a hash table and all keys for that particular key hierarchy could be looked up very efficiently. regards, Dan. On Fri, February 1, 2008 5:16 pm, Dan Harkins wrote: > > 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. > > > > > _______________________________________________ > HOKEY mailing list > HOKEY@xxxxxxxx > http://www.ietf.org/mailman/listinfo/hokey > _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf