Hi Sam,
On Wed, April 4, 2007 6:16 pm, Sam Hartman wrote:
"Dan" == Dan Harkins <dharkins(_at_)lounge(_dot_)org> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf