eap Mailing List: [Issue ] EMSK usage guidelines

[Joseph Salowey (jsalowey]

Guidelines for the usage of the EMSK

Submitter name: Joe Salowey
Submitter email address: jsalowey [at] cisco.com
Date first submitted: 1/19/2004
Reference: 
Document: Keying Framework
Comment type: 'T' Technical
Priority: 'S'
Section: Section 2.4 and Section 5
Rationale/Explanation of issue:

Guidelines need to be set for the usage of the EMSK material.

Suggested text from draft-salowey-eap-key-deriv-02.txt

2.4 Requirements for EMSK usage  

EAP reserves a portion of keying material, called the EMSK, for 
extended uses.  Keys derived from this key material may be used to
key applications on different devices and different processes separate
from the entity that receives the MSK. 

If the keying material is used to provide keys for multiple 
Applications or devices, it is desired that the keys will be 
cryptographically separate. Cryptographic separation means that 
knowledge of one key does not provide an easy way to determine another 
key derived from the same key material.  This is also known as 
computationally independent.   
    
This section provides guidelines for a mechanism which can be used 
with existing and new EAP methods and applications to provide 
cryptographic separation between keys derived for different applications

and devices.  These derived keys are referred to in this section as
Application Master Session Keys or AMSK.  
 
2.4.1 Requirements for EAP methods 
      
   In order for an EAP method to meet the guidelines for EMSK usage it 
   must meet the following requirements.   
    
     o It must specify how to derive the EMSK  
    
     o The key material used for the EMSK MUST be computationally 
          independent of the MSK and TEKs. 
    
     o The EMSK MUST NOT be used for any other purpose than the key 
        derivation described in this document.   
    
     o The EMSK MUST be secret and not known to someone observing the 
        authentication mechanism protocol exchange. 

     o The EMSK MUST be maintained within the EAP server.  Only keys 
        (AMSKs) derived according to this specification may be exported 
        from the EAP server. 
 
     o The EMSK MUST be unique for each session.  
 
     o The EAP mechanism SHOULD provide a way of naming the EMSK. 

   Implementations of EAP frameworks on the EAP-Peer and EAP-Server
SHOULD 
   provide an interface to obtain AMSKs.  The implementation MAY 
   restrict which callers can obtain which keys. 
    
2.4.2 Requirements for EAP applications 
    
   In order for an application to meet the guidelines for EMSK usage it 
   must meet the following,  
    
     o The application MAY use the MSK transmitted to the NAS in any 
        way it chooses. This is required for backward compatibility. New

        applications following this specification SHOULD NOT use the 
        MSK. If more than one application uses the MSK, then the 
        cryptographic separation is not achieved. Implementations SHOULD

        prevent such combinations. 
         
     o The application MUST NOT use the EMSK in any other way except to 
        derive Application Master Session Keys (AMSK) using the key 
        derivation specified in this document.  It MUST NOT 
        use the EMSK directly for cryptographic protection of data. 
      
     o Applications MUST define distinct key labels, application 
        specific data, length of derived key material used in the key 
          derivation described in section 2.4.3. 
 
     o Applications MUST define how they use their AMSK to derive TSKs 
        for their use. 

2.4.3 EAP AMSK Key Derivation 
    
   The EAP EMSK usage guidelines provide a means for generating multiple

   application-specific master keys (AMSKs). These AMSKs are then used 
   to derive transient session keys (TSKs), which are used as actual 
   ciphering keys. This allows multiple applications to use keys 
   independently derived from the EAP method.  
    
   The EAP EMSK usage guidelines AMSK key derivation function (KDF) 
   derives an AMSK from the Extended Master Session Key (EMSK) described

   above, an application key label, optional application data, and 
   output length.  
    
      AMSK = KDF(EMSK, key label, optional application data, length) 
    
   The key labels are printable ASCII strings unique for each 
   application (see Section 5 for IANA Considerations).  
    
   Additional ciphering keys (TSKs) can be derived from the AMSK using 
   an application specific key derivation mechanism. In many cases, this

   AMSK->TSK derivation can simply split the AMSK to pieces of correct 
   length. In particular, it is not necessary to use a cryptographic 
   one-way function. Note that the length of the AMSK must be specified 
   by the application.  
    
2.4.3.1 The EAP AMSK Key Derivation Function 
    
   The EAP key derivation function is taken from the PRF+ key expansion 
   PRF from [IKEv2].  This KDF takes 4 parameters as input: secret, 
   label, application data, and output length.  It is only defined for 
   255 iterations so it may produce up to 5100 bytes of key material.  
    
   For the purposes of this specification the secret is taken as the 
   EMSK, the label is the key label described above concatenated with a 
   NUL byte, the application data is also described above and the output

   length is two bytes.  The application data is optional and may not be

   used by some applications.  The KDF is based on HMAC-SHA1 [RFC2104] 
   [SHA1]. For this specification we have: 
    
   KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ... 
    
      where: 
      T1 = prf (K, S | 0x01) 
      T2 = prf (K, T1 | S | 0x02) 
      T3 = prf (K, T2 | S | 0x03) 
      T4 = prf (K, T3 | S | 0x04) 
    
      prf = HMAC-SHA1 
      K = EMSK 
      L = key label 
      D = application data 
      O = OutputLength (2 bytes) 
      S = L | "\0" | D | O 
        
    
   The prf+ construction was chosen because of its simplicity and 
   efficiency over other PRFs such as those used in [TLS].  The 
   motivation for the design of this PRF is described in [SIGMA].   
    
   The NUL byte after the key label is used to avoid collisions if one 
   key label is a prefix of another label (e.g. "foobar" and 
   "foobarExtendedV2"). This is considered a simpler solution than 
   requiring a key label assignment policy that prevents prefixes from 
   occurring. 
 
5. IANA Considerations 
 
   This specification introduces a new name space for "key labels".  Key

   labels are ASCII strings and are assigned on a first come first 
   served basis.  It is RECOMMENDED that a reference to a specification 
   that provides the following information 
    
     o A description of the application 
     o The key label to be used 
     o How TSKs will be derived from the AMSK and how they will be used 
     o If application specific data is used, what it is and how it is 
        maintained 
     o Where the AMSKs or TSKs will be used and how they are 
        communicated if necessary.