>>>>> "Dan" == Dan Harkins <dharkins@xxxxxxxxxx> writes:
Dan> Sam,
Dan> The keys in this hypothetical protocol are for network
Dan> access and giving them to authenticators for that purpose
Dan> would seem to fall under the "key scope" requirement.
Key scope means giving an authenticator a key for a specific
purpose--something like authentication for network access between peer
foo and authenticator bar--not something general like network access.
Dan> These are not session keys so the text relating the session
Dan> keys is not applicable.
O, I definitely think they are session keys.
Dan> So the domino effect is the only text that could seem to
Dan> prohibit this. As long as the same key wasn't given to more
Dan> than one authenticator though then this is satisfied. A way
Dan> to prevent the same key being sent to different
Dan> authenticators is to allow the authenticator to choose an
Dan> identity to advertise to the peer-- "I'm 'foo'"-- and to tell
Dan> the server-- "give me a key specific to 'foo'". That identity
Dan> is mixed into the key derivation function. This is
Dan> essentially what 802.11r is doing. This has channel
Dan> binding/lying NAS issues though. I'm not quite sure yet what
Dan> HOKEY is doing in this regard (how is the distributed key
Dan> separated from other keys) but it appears to suffer from the
Dan> same problems since people are advocating solutions that do
Dan> not fix this problem.
Wait, what's wrong with giving 100 authenticators 100 different keys
provided that each authenticator is authorized to claim the identity
it plans to claim?
Isn't that exactly the sort of thing we do want to do?
BTW, I think your questions exploring what key scope and session keys
mean are good. The only issue I'm asking you to step away from at
this late point in the process is the question of whether clients
should be involved in deciding who their keys are given to.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf