There is nothing in the document that says you must index keys only by key id. I don't really understand the problem here, there is other context associated with a key besides a name that can be used for indexing. The key name provides a fixed length unique identifier for the key. EAP Session-ID is not fixed length and can be awkward to use in protocols, most likely you will end up hashing it anyway. Joe > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Dan Harkins > Sent: Friday, February 01, 2008 5:46 PM > To: Dan Harkins > Cc: ietf@xxxxxxxx; hokey@xxxxxxxx > Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP > Extensions for EAP Re-authentication Protocol (ERP)) to > Proposed Standard > > > 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 mailing list > Ietf@xxxxxxxx > http://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf