Hi Sam,
On Wed, April 4, 2007 6:16 pm, Sam Hartman wrote:
>>>>>> "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.
I just don't see that in draft-housley-aaa-key-mgmt-09.txt which says:
Following the principle of least privilege, parties MUST NOT
have access to keying material that is not needed to perform
their role. A party has access to a particular key if it has
access to all of the secret information needed to derive it.
The role of the particular party is an authenticator and this key is
for that purpose. There's nothing there about a purpose involving
specific entities ("peer foo and authenticator bar"). I snipped the 2nd
paragraph in that section because it talks about session keys, and:
> 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.
They are not keys used for bulk traffic protection. At least not in
my mind. There is something the aforementioned draft refers to as a
"secure association protocol" used to derive keys used for bulk traffic
protection-- like 802.11's "4 way handshake". The 2nd paragraph that I
snipped above deals with such a "secure association protocol" and the
identities identified in that protocol are low-layer identities-- a BSSID
or a MAC address-- used to send protected packets/frames between the
peer and authenticator.
I guess you could use the key being distributed directly as a bulk
traffic protection key but then return handoffs-- peer goes from A to
B and back to A-- would require additional trips to the AAA server
which is something we want to avoid.
> 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?
Provided there are no channel binding issues and the all parties are
authenticated and the authenticated identity is authorized to hold the
distributed key I guess there isn't anything wrong.
The reason I'm bringing this up, though, is because AAA is now being
used as a key distribution protocol-- 802.11r and HOKEY-- and these issues
are not being addressed in that use of AAA. In discussions with people
it is apparent they think the channel binding mention in the
aforementioned draft deals with EAP. They think authentication of all
parties just means establishing some security association (using a RADIUS
shared secret for instance, or an IPsec SA) and the identity that was
authenticated during its creation is irrelevant and not used during the
distribution of a key. Any new security issues that they might create by
using AAA as a key distribution protocol are ignored and compliance to
"the Housley Criteria" is claimed.
> 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.
I will step away from that question. I did not intend on introducing
any new issues when I brought it up. Although I honestly don't see how
you can solve the issue of binding a common authenticator identity between
the peer and AAA server (the two entities that share the secret that is
being disclosed to the authenticator) without involving the peer.
Dan.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf