Re: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]