Subject: [AAA-WG]: Issue: Key AVPs + security considerations

From: <[email-masked]>
Date: Thu, 19 Jun 2003 17:11:37 +0300

Hi,

Here's an issue related to keying AVPs.

I'm working on the security considerations section, and will 
post something here early next week.  However, it seems
that many (most?) of the security considerations are not
actually EAP-specific but apply also to NASREQ.  How should
this be handled? (NASREQ-11 doesn't have much security
considerations)

BTW, if somebody is interested in intermediate versions, I'm
posting them on a web page every now and then:
http://www.cs.hut.fi/~peronen/eap/diameter_eap.html 

Best regards,
Pasi

Key AVPs
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: 19 Jun 2003
Reference: 
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.