ietf
[Top] [All Lists]

RE: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard

2008-02-03 13:33:45

  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 mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>