Sam,
The keys in this hypothetical protocol are for network access and
giving them to authenticators for that purpose would seem to fall
under the "key scope" requirement.
These are not session keys so the text relating the session keys
is not applicable.
So the domino effect is the only text that could seem to prohibit
this. As long as the same key wasn't given to more than one authenticator
though then this is satisfied. A way to prevent the same key being sent
to different authenticators is to allow the authenticator to choose an
identity to advertise to the peer-- "I'm 'foo'"-- and to tell the server--
"give me a key specific to 'foo'". That identity is mixed into the key
derivation function. This is essentially what 802.11r is doing. This has
channel binding/lying NAS issues though. I'm not quite sure yet what HOKEY
is doing in this regard (how is the distributed key separated from other
keys) but it appears to suffer from the same problems since people are
advocating solutions that do not fix this problem.
Finally, I'm not trying to delay anything. I said it before and I'll
say it again: if the general feeling is that the I-D already addresses
these issues or there is no consensus to solve the problem then publish it
as an RFC. It is important to have an RFC talking about these things, it's
just my personal opinion that it does not go far enough.
Dan.
On Tue, April 3, 2007 5:23 pm, Sam Hartman wrote:
"Dan" == Dan Harkins <dharkins(_at_)lounge(_dot_)org> writes:
Dan> Sam,
Dan> I guess the question is, what text in this I-D would
Dan> prevent a new key distribution protocol based on AAA in which
Dan> the authentication server sent a copy of the peer's keys
Dan> willy-nilly to every authenticator it had a security
Dan> association with?
First, note that I do not claim we have the text right; I'm asking
Russ and Bernard to evaluate that.
So, I'll tell you what the closest text is for this, but you are
welcome to argue that the current text does not reflect our consensus.
Under limit key scope:
Following the principle of least privilege, parties MUST NOT
have access to keying material that is not needed to perform
their role.
Also see:
Strong, fresh session keys
While preserving algorithm independence, session keys MUST be
strong and fresh. Each session deserves an independent session
key.
A fresh cryptographic key is one that is generated specifically
for the intended use. In this situation, a secure association
protocol is used to establish session keys. The AAA protocol
and EAP method MUST ensure that the keying material supplied as
an input to session key derivation is fresh, and the secure
association protocol MUST generate a separate session key for
each session, even if the keying material provided by EAP is
cached. A cached key persists after the authentication
exchange has completed. For the AAA/EAP server, key caching
can happen when state is kept on the server. For the NAS or
client, key caching can happen when the NAS or client does not
destroy keying material immediately following the derivation of
session keys.
Prevent the Domino effect
Compromise of a single peer MUST NOT compromise keying material
held by any other peer within the system, including session
keys and long-term keys. Likewise, compromise of a single
authenticator MUST NOT compromise keying material held by any
other authenticator within the system. In the context of a key
hierarchy, this means that the compromise of one node in the
key hierarchy must not disclose the information necessary to
compromise other branches in the key hierarchy. Obviously, the
compromise of the root of the key hierarchy will compromise all
of the keys; however, a compromise in one branch MUST NOT
result in the compromise of other branches.
I think given these requirements what you propose would not be
appropriate.
Dan> Another question: has the peer no say in to whom its
Dan> secrets are disclosed? If you think it does then what in the
Dan> I-D addresses that concern and if you don't think it does
Dan> then why?
I find no requirements related to this. I do not believe there is
consensus to have such requirements nor do I believe it appropriate to
delay the document while you attempt to build such a consensus.
--Sam
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf