Subject: RE: Last Call: 'Guidance for AAA Key Management' to BCP (draft-housley-aaa-key-mgmt)

From: "Alper Yegin" <[email-masked]>
Date: Tue, 10 Oct 2006 16:22:23 +0300

I think this is a good and much-needed document. Thanks to the authors and
whoever else contributed to it.

The title and the abstract starts reading like a general AAA key management
guideline, but later the document gets too EAP-specific. Is the intent to
provide general guidelines that should also be followed by non-EAP-based
systems? Can we clarify that?

      4-Way Handshake
         A pairwise Authentication and Key Management Protocol (AKMP)
         defined in [802.11i], which confirms mutual possession of a
         Pairwise Master Key by two parties anon  a copyright statement alone to cover the IETF's use,
that is IMHO broken. The IETF's reliance on "That there must be two
physically interoperable ports of any protocol" implemented to meet the
Standards Practice takes this out of the Copyright alone Area and creates
that Industrial Design that has to be protected.

My point to the Aesthetic Patent was that it was a tad easier to deal with
IMHO.

Todd Glassey

----- Original Message ----- 
From: "Yaakov Stein" <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 09, 2006 11:59 PM
Subject: RE: WIPO issues (was: Network Endpoint Assessment (nea))

To qualify for protection, an industrial design must be aesthetic,
and I believe that elegant design should be one of our goals in protocol
design.

However, industrial designs are "divorced from all technical aspects of
the article",
and thus at least some small portion of our ongoing work may be
ineligible for protection.

A major obstacle to be overcome before applying for design protection
for our work
is the fact that ASCII RFCs can not contain lines or colors,
and would probably be rejected by the appropriate national offices.

Finally, please note the treaties:
   Terribly Complex Protection for Intellectual Property (TCP/IP)
   Ugly Dumb Protection for Intellectual Property (UDP/IP)
may directly impact our work.

Y(J)S

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 10 Oct 2006 16:22:23 +0300

4-Way Handshake
         A pairwise Authentication and Key Management Protocol (AKMP)
         defined in [802.11i], which confirms mutual possession of a
         Pairwise Master Key by two parties and distributes a Group Key.

Isn't "4-way handshake" a specific example of "secure association" protocol?
If so, probably we can present this as an example of the latter in the
terminology section.

      Cryptographic algorithm independent

         The AAA key management protocol MUST be cryptographic algorithm
         independent.  However, an EAP method MAY depend on a specific
         cryptographic algorithm.

Why is the requirement softer on the EAP methods?

      Limit key scope

         Following the principle of least privilege, parties MUST NOT
         have access to keying material that is not needed to perform
         their own role.  A party has access to a particular key if it
         has access to all of the secret information needed to derive
         it.

         When a secure association protocol is used to establish session
         keys, the secure association protocol MUST specify the scope
         for session keys, clearly identifying the parties to whom the
         session key is available.

Alper> The second paragraph reads as if it is a specific application of the
requirement stated in the first paragraph. Do we really want to make a
specific requirement on the "secure association protocols", or are we using
this as an example of how the aforementioned requirement is applied to a
protocol?

If the intent is the latter one, how about a more general statement like
"Any protocol that establishes sessions keys MUST specify the scope of these
keys, clearly identifying the parties to whom the session key is available."

And how would we apply this to EAP? There is no authenticator ID known to
EAP peer, yet they share an MSK.

      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.  There are many
         implications of this requirement; however, two implications
         deserve highlighting.  First, the scope of the keying material
         must be defined and understood by all parties that communicate
         with a party that holds that keying material.  Second, a party
         that holds keying material in a key hierarchy must not share
         that keying material with parties that are associated with
         other branches in the key hierarchy.

The second paragraph makes sense. But somehow the requirements in the first
paragraph are more restrictive than the general requirement in the second
paragraph. More specifically, if a solution derives one set of keys on an
authenticator and passes it to another one (effectively identifying the
second one as its child in the key hierarchy), that's allowed by the second
paragraph, but not the first one. Is that the intent?

      Bind key to its context

         Keying material MUST be bound to the appropriate context, which
         includes:

            o  The manner in which the keying material is expected to
               be used;

            o  The other parties that are expected to have access to
               the keying material; and

Isn't this same as key scoping? If so, we can say that key scooping is a
subset of binding key to its context.

            o  The expected lifetime of the keying material.

Does it make sense to mention something like "Lifetime of a child key MUST
NOT be greater than the lifetime of its parent in the key hierarchy."?

         For this reason, EAP methods SHOd distributes a Group Key.

Isn't "4-way handshake" a specific example of "secure association" protocol?
If so, probably we can present this as an example of the latter in the
terminology section.

      Cryptographic algorithm independent

         The AAA key management protocol MUST be cryptographic algorithm
         independent.  However, an EAP method MAY depend on a specific
         cryptographic algorithm.

Why is the requirement softer on the EAP methods?

      Limit key scope

         Following the principle of least privilege, parties MUST NOT
         have access to keying material that is not needed to perform
         their own role.  A party has access to a particular key if it
         has access to all of the secret information needed to derive
         it.

         When a secure association protocol is used to establish session
         keys, the secure association protocol MUST specify the scope
         for session keys, clearly identifying the parties to whom the
         session key is available.

Alper> The second paragraph reads as if it is a specific application of the
requirement stated in the first paragraph. Do we really want to make a
specific requirement on the "secure association protocols", or are we using
this as an example of how the aforementioned requirement is applied to a
protocol?

If the intent is the latter one, how about a more general statement like
"Any protocol that establishes sessions keys MUST specify the scope of these
keys, clearly identifying the parties to whom the session key is available."

And how would we apply this to EAP? There is no authenticator ID known to
EAP peer, yet they share an MSK.

      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.  There are many
         implications of this requirement; however, two implications
         deserve highlighting.  First, the scope of the keying material
         must be defined and understood by all parties that communicate
         with a party that holds that keying material.  Second, a party
         that holds keying material in a key hierarchy must not share
         that keying material with parties that are associated with
         other branches in the key hierarchy.

The second paragraph makes sense. But somehow the requirements in the first
paragraph are more restrictive than the general requirement in the second
paragraph. More specifically, if a solution derives one set of keys on an
authenticator and passes it to another one (effectively identifying the
second one as its child in the key hierarchy), that's allowed by the second
paragraph, but not the first one. Is that the intent?

      Bind key to its context

         Keying material MUST be bound to the appropriate context, which
         includes:

            o  The manner in which the keying material is expected to
               be used;

            o  The other parties that are expected to have access to
               the keying material; and

Isn't this same as key scoping? If so, we can say that key scooping is a
subset of binding key to its context.

            o  The expected lifetime of the keying material.

Does it make sense to mention something like "Lifetime of a child key MUST
NOT be greater than the lifetime of its parent in the key hierarchy."?

         For this reason, EAP methods SHOULD
         provide a mechanism for identity protection of EAP peers, but
         such protection is not a requirement.

"SHOULD" and "not a requirement" seem to clash. We should either make it a
"MAY", or remove the ",but ...".

Regards,

Alper

ULD
         provide a mechanism for identity protection of EAP peers, but
         such protection is not a requirement.

"SHOULD" and "not a requirement" seem to clash. We should either make it a
"MAY", or remove the ",but ...".

Regards,

Alper