Subject: [AAA-WG]: Re: Issue 414: Keying AVPs

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Aug 2003 07:09:00 -0700 (PDT)

I've finally gotten the -07 draft of the EAP Keying Framework out:

http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-07.txt

This clarifies a few issues.  While the AAA-Key AVP will *generally*
contain the MSK, this might not necessarily be the case -- it could for
example contain a quantity derived from the EMSK and even in some cases,
one derived from the MSK.  For example, if the MSK is not actually sent to
the NAS, then quantities derived off the MSK could be used to provide
cryptographic separation between material sent to different NASes.

So the -07 version makes a distinction between the AAA-Key, and the MSK
and EMSK (and quantities derived from them).

All this to say that perhaps the AVP should be named "EAP-Key" or
something like that.

I agree that including a list of ciphers with the AAA-Key AVP is not a
good idea since this keying material MUST be ciphersuite independent,
according to the Key Framework draft.  Similarly, directionality is not
useful since this is keying material, not a session key.

However, it does strike me that perhaps a key lifetime might make sense,
since overloading Session-Timeout or another equivalent AVP seems like a
bad idea.

One issue which is still open is whether the Key-Name should be included
along with the key.  IEEE 802.11i has a new PMK naming proposal in D5.0
which essentially names keys based on the key itself as well as
Called-Station-Id and Calling-Station-Id.  However, I'm not clear how the
station knows which algorithm was used to generate the key (could be one
of several).

I don't care much for options 3 and 4.

-----------------------------------------------------------------------------
Issue 414: Key AVPs
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: 19 Jun 2003
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg04961.html
Document: EAP-01
Comment type: T
Priority: 1
Section: various
Rationale/Explanation of issue:

What should the AVPs for transporting keys look like?
Here are some alternatives for starting a discussion:

Alternative 1:

   EAP-Master-Session-Key (OctetString)

   Pros/cons:
   + Simple
   + Does not try to solve all keying problems forever, but just
     enough for EAP.
   + Consistent with 2284bis
   + The Diameter server doesn't have to know what the key is used for
   - The Diamater server doesn't know what the key is used for
   - New AVPs may be needed for more complex needs in the future
     (but if we don't know them yet, we can define them later).

Alternative 2:

   From old NASREQ-09:

   NAS-Session-Key ::= < AVP Header: 408 >
                       { NAS-Key-Direction }
                       { NAS-Key-Type }
                       { NAS-Key-Data }
                       { NAS-Key-Binding }                            |
                       [ NAS-Key-Lifetime ]
                       [ NAS-IV ]
                     * [ AVP ]

   NAS-Key-Direction: (BIDIRECTIONAL, UPLINK, DOWNLINK)
   NAS-Key-Type:      (CIPHER_KEY, INTEGRITY_KEY, MASTER_CIPHER_KEY,
                       MASTER_INTEGRITY_KEY, MASTER_KEY)
   NAS-Key-Binding:   (DES, 3DES, RC4-40, RC4-128)

   Pros/cons.
   - The Key-Type/Binding is complex, but it still can't specify even
     something simple like "use this key for 802.11i PMK" -- a
     BIDIRECTIONAL,MASTER_KEY could be used for some other purpose!
   - Including a list of ciphers here is probably not a good idea.

Alternative 3:

   EAP-Session-Key ::= < AVP Header: TBD >
                       { EAP-Key-Type }
                    1* { EAP-Key-Data }
                     * [ AVP ]

   EAP-Key-Type is of type Enumerated, with the following
   values assigned:

   IEEE_802_11I_PAIRWISE_MASTER_KEY (1)
      A single EAP-Key-Data AVP contains the Pairwise Master Key
      to be used in 802.11i four-way handshake.

   IEEE_802_11_WEP_KEY (2)
      A single EAP-Key-Data AVP contains the 802.11 WEP key
      (TBD: is this correct?).

   MS_MPPE_KEYS (3)
      Two EAP-Key-Data AVPs included, first containing the
      downlink (send) key, and the second the uplink (recv) key.

   IKE_V2_AUTH_KEY (4)
      A single EAP-Key-Data AVP contains the MSK for IKEv2
      authentication.

   PANA_something (5)
      To be defined when PANA progresses.

   Pros/cons:
   + Simple binding, extensible
   - ?

Alternative 4:

   Like 3, but instead of creating a new Enumeration
   namespace, just use the AVP namespace. That is,
   create four new AVPs:

   IEEE-802-11i-Pairwise-Master-Key
   IEEE-802-11-WEP-Key
   MS-MPPE-Keys
   IKEv2-Auth-Key

   Pros/cons:
   + Grouped AVPs can include other stuff, like encryption policies
     for MPPE, or allowed cipher algorithms, etc.
   + Any new use for EAP will probably require a spec saying
     how it is used with RADIUS/Diameter anyway (e.g. we will soon
     need a "IKEv2 RADIUS/Diameter Usage Guidelines" document, similar
     to the existing "IEEE 802.1X RADIUS Usage Guidelines")
   + New keying AVPs can be defined using the normal ABNF syntax.
   + New AVP required for new key uses -- it's a good thing if they
     keys can't be used for other purposes too easily.
   - New AVP required for new key uses.