>>>>> "Dan" == Dan Harkins <[EMAIL PROTECTED]> 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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf