Hi Glen, On Sun, February 3, 2008 12:28 am, Glen Zorn wrote: > Dan Harkins <> scribbled on Saturday, February 02, 2008 8:46 AM: > >> 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) > > It doesn't seem particularly reasonable to me. The one reason I can > think of for this is to disable access for a particular user in some > domain; to do that it doesn't seem necessary to explicitly remove all > the keys in the hierarchy, just the root key (after disconnecting the > user). Disconnecting the user should delete the PMK, TSKs, etc., right? Yes, it should delete the other keys. And if I am the entity that holds the "root key" and you are an ER server that holds some derivatives like a DSUSRK and some derivatives of that like rMSKs for different authenticators in that "domain" then what information should I give you to identify the particular hierarchy I'm talking about? Remember you may hold other key hierarchies for other users in other domains for other usages and they all use the same name space. An incomprehensible string of random bits doesn't seem particularly helpful in accomplishing the task. >> one >> must do a linear search of all keys in all key hierarchies that a >> particular server maintains! >> 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. > > I won't argue that indexing the keystore by Session-ID is a bad idea > (though Username might be better), but I can't see how that depends upon > the actual key name. Glen, the issue is that not only is every key in the hierarchy mapped to the same name space, every key for every user's hierarchy for every domain for every usage is all mapped to the same name space! Yea, mapping by Username might be better. Oone reason is that you could develop a rational searching strategy to identify keys if you indexed with something like "Username". That is a great suggestion and a useful alternative to what is in the draft now. I would support such a change. Can you tell me one use for a key name that is an incomprehensible string of random bits? "Delete all keys associated with 0x58d610a8ff4128c9" "uhm, ok" If not then don't you agree the current key naming scheme is completely useless? Dan. _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf