ietf
[Top] [All Lists]

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

2007-04-03 18:36:46
"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