GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5295

Network Working Group J. Salowey Request for Comments: 5295 Cisco Systems Updates: 5247 L. Dondeti Category: Standards Track V. Narayanan

                                                         Qualcomm, Inc
                                                           M. Nakhjiri
                                                              Motorola
                                                           August 2008
           Specification for the Derivation of Root Keys
             from an Extended Master Session Key (EMSK)

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Abstract

 The Extensible Authentication Protocol (EAP) defined the Extended
 Master Session Key (EMSK) generation, but reserved it for unspecified
 future uses.  This memo reserves the EMSK for the sole purpose of
 deriving root keys.  Root keys are master keys that can be used for
 multiple purposes, identified by usage definitions.  This document
 also specifies a mechanism for avoiding conflicts between root keys
 by deriving them in a manner that guarantees cryptographic
 separation.  Finally, this document also defines one such root key
 usage: Domain-Specific Root Keys are root keys made available to and
 used within specific key management domains.

Salowey, et al. Standards Track [Page 1] RFC 5295 EMSK Root Key Derivation August 2008

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1.  Applicable Usages of Keys Derived from the EMSK  . . . . .  3
   1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
 2.  Cryptographic Separation and Coordinated Key Derivation  . . .  6
 3.  EMSK Key Root Derivation Framework . . . . . . . . . . . . . .  7
   3.1.  USRK Derivation  . . . . . . . . . . . . . . . . . . . . .  8
     3.1.1.  On the KDFs  . . . . . . . . . . . . . . . . . . . . .  9
     3.1.2.  Default KDF  . . . . . . . . . . . . . . . . . . . . .  9
   3.2.  EMSK and USRK Name Derivation  . . . . . . . . . . . . . . 10
 4.  Domain-Specific Root Key Derivation  . . . . . . . . . . . . . 11
   4.1.  Applicability of Multi-Domain Usages . . . . . . . . . . . 12
 5.  Requirements for Usage Definitions . . . . . . . . . . . . . . 13
   5.1.  Root Key Management Guidelines . . . . . . . . . . . . . . 13
 6.  Requirements for EAP System  . . . . . . . . . . . . . . . . . 14
 7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   7.1.  Key Strength . . . . . . . . . . . . . . . . . . . . . . . 15
   7.2.  Cryptographic Separation of Keys . . . . . . . . . . . . . 15
   7.3.  Implementation . . . . . . . . . . . . . . . . . . . . . . 15
   7.4.  Key Distribution . . . . . . . . . . . . . . . . . . . . . 16
   7.5.  Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 16
   7.6.  Entropy Consideration  . . . . . . . . . . . . . . . . . . 16
 8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   8.1.  Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 17
   8.2.  PRF Numbers  . . . . . . . . . . . . . . . . . . . . . . . 18
 9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
   10.2. Informative References . . . . . . . . . . . . . . . . . . 19

Salowey, et al. Standards Track [Page 2] RFC 5295 EMSK Root Key Derivation August 2008

1. Introduction

 This document deals with keys generated by authenticated key exchange
 mechanisms defined within the EAP framework [RFC3748].  EAP defines
 two types of keying material: a Master Session Key (MSK) and an
 Extended Master Session Key (EMSK).  The EAP specification implicitly
 assumes that the MSK produced by EAP will be used for a single
 purpose at a single device; however, it does reserve the EMSK for
 future use.  This document defines the EMSK to be used solely for
 deriving root keys using the key derivation specified.  The root keys
 are meant for specific purposes called usages; a special usage class
 is the Domain-Specific Root Keys made available to and used within
 specific key management domains.  This document also provides
 guidelines for creating usage definitions for the various uses of EAP
 key material and for the management of the root keys.  In this
 document, the terms application and usage (or "usage definition")
 refer to a specific use case of the EAP keying material.
 Different uses for keys derived from the EMSK have been proposed.
 Some examples include hand-off across access points in various mobile
 technologies, mobile IP authentication, and higher-layer application
 authentication.  In order for a particular usage of EAP key material
 to make use of this specification, it must specify a so-called usage
 definition.  This document does not define how the derived Usage-
 Specific Root Keys (USRK) are used; see the following section for
 discussion of applicable usages.  It does define a framework for the
 derivation of USRKs for different purposes such that different usages
 can be developed independently from one another.  The goal is to have
 security properties of one usage have minimal or no effect on the
 security properties of other usages.
 This document does define a special class of USRK, called a Domain-
 Specific Root Key (DSRK) for use in deriving keys specific to a key
 management domain.  Each DSRK is a root key used to derive Domain-
 Specific Usage-Specific Root Keys (DSUSRK).  The DSUSRKs are USRKs
 specific to a particular key management domain.
 In order to keep root keys for specific purposes separate from one
 another, two requirements are defined in the following sections.  One
 is coordinated key derivation and another is cryptographic
 separation.

1.1. Applicable Usages of Keys Derived from the EMSK

 The EMSK is typically established as part of network access
 authentication and authorization.  It is expected that keys derived
 from EMSK will be used in protocols related to network access, such

Salowey, et al. Standards Track [Page 3] RFC 5295 EMSK Root Key Derivation August 2008

 as handover optimizations, and the scope of these protocols is
 usually restricted to the endpoints of the lower layers over which
 EAP packets are sent.
 In particular, it is inappropriate for the security of higher-layer
 applications to solely rely on keys derived from network access
 authentication.  Even when used together with another, independent
 security mechanism, the use of these keys needs to be carefully
 evaluated with regards to the benefits of the optimization and the
 need to support multiple solutions.  Performance optimizations may
 not warrant the close tie-in that may be required between the layers
 in order to use EAP-based keys.  Such optimizations may be offset by
 the complexities of managing the validity and usage of key materials.
 Keys generated from subsequent EAP authentications may be beyond the
 knowledge and control of applications.
 From an architectural point of view, applications should not make
 assumptions about the lower-layer technology (such as network access
 authentication) used on any particular hop along the path between the
 application endpoints.
 From a practical point of view, making such assumptions would
 complicate using those applications over lower layers that do not use
 EAP, and make it more difficult for applications and network access
 technologies to evolve independently of each other.
 Parties using keys derived from EMSK also need trust relationships
 with the EAP endpoints, and mechanisms for securely communicating the
 keys.
 For most applications, it is not appropriate to assume that all
 current and future access networks are trusted to secure the
 application function.  Instead, applications should implement the
 required security mechanisms in an access-independent manner.
 Implementation considerations may also complicate communication of
 keys to an application from the lower layer.  For instance, in many
 configurations, application protocol endpoints may be different from
 the EAP endpoints.
 Given all this, it is NOT RECOMMENDED to use keys derived from the
 EMSK as an exclusive security mechanism, when their usage is not
 inherently, and by permanent nature, tied to the lower layer where
 network access authentication was performed.

Salowey, et al. Standards Track [Page 4] RFC 5295 EMSK Root Key Derivation August 2008

 Keys derived from EAP are pair-wise by nature and are not directly
 suitable for multicast or other group usages such as those involved
 in some routing protocols.  It is possible to use keys derived from
 EAP in protocols that distribute group keys to group participants.
 The definition of these group key distribution protocols is beyond
 the scope of this document and would require additional
 specification.

1.2. Terminology

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].
 The following terms are taken from [RFC3748]: EAP Server, peer,
 authenticator, Master Session Key (MSK), Extended Master Session Key
 (EMSK), Cryptographic Separation.
 Usage Definition
    An application of cryptographic key material to provide one or
    more security functions such as authentication, authorization,
    encryption, or integrity protection for related applications or
    services.  This document provides guidelines and recommendations
    for what should be included in usage definitions.  This document
    does not place any constraints on the types of use cases or
    services that create usage definitions.
 Usage-Specific Root Key (USRK)
    Keying material derived from the EMSK for a particular usage
    definition.  It is used to derive child keys in a way defined by
    its usage definition.
 Key Management Domain
    A key management domain is specified by the scope of a given root
    key.  The scope is the collection of systems authorized to access
    key material derived from that key.  Systems within a key
    management domain may be authorized to (1) derive key materials,
    (2) use key materials, or (3) distribute key materials to other
    systems in the same domain.  A derived key's scope is constrained
    to a subset of the scope of the key from which it is derived.  In
    this document, the term "domain" refers to a key management domain
    unless otherwise qualified.
 Domain Specific Root Key (DSRK)
    Keying material derived from the EMSK that is restricted to use in
    a specific key management domain.  It is used to derive child keys
    for a particular usage definition.  The child keys derived from a

Salowey, et al. Standards Track [Page 5] RFC 5295 EMSK Root Key Derivation August 2008

    DSRK are referred to as Domain-Specific Usage-Specific Root Keys
    (DSUSRKs).  A DSUSRK is similar to the USRK, except in the fact
    that its scope is restricted to the same domain as the parent DSRK
    from which it is derived.

2. Cryptographic Separation and Coordinated Key Derivation

 The EMSK is used to derive keys for multiple use cases, and thus it
 is required that the derived keys are cryptographically separate.
 Cryptographic separation means that when multiple keys are derived
 from an EMSK, given any derived key, it is computationally infeasible
 to derive any of the other derived keys.  Note that deriving the EMSK
 from any combinations of the derived keys must also be
 computationally infeasible.  In practice, this means that derivation
 of an EMSK from a derived key or derivation of one child key from
 another must require an amount of computation equivalent to that
 required to, say, reversing a cryptographic hash function.
 Cryptographic separation of keys derived from the same key can be
 achieved in many ways.  Two obvious methods are as follows:
 o  Use a Pseudo-Random Function (PRF) on the EMSK and generate a key
    stream.  Keys of various lengths may be provided as required from
    the key stream for various uses.
 o  Derive keys from EMSK by providing different inputs to the PRF.
 However, it is desirable that derivation of one child key from the
 EMSK is independent of derivation of another child key.  Independent
 derivation of keys from the EMSK allows child keys to be derived in
 any order, independent of other keys.  Thus, it is desirable to use
 option 2 from above.  Using the second option implies the additional
 input to the PRF must be different for each child key derivation.
 This additional input to the PRF must be coordinated properly to meet
 the requirement of cryptographic separation and to prevent reuse of
 key material between usages.
 If cryptographic separation is not maintained, then the security of
 one usage depends upon the security of all other usages that use keys
 derived from the EMSK.  If a system does not have this property, then
 a usage's security depends upon all other usages deriving keys from
 the same EMSK, which is undesirable.  In order to prevent security
 problems in one usage from interfering with another usage, the
 following cryptographic separation is required:
 o  It MUST be computationally infeasible to compute the EMSK from any
    root key derived from it.

Salowey, et al. Standards Track [Page 6] RFC 5295 EMSK Root Key Derivation August 2008

 o  Any root key MUST be cryptographically separate from any other
    root key derived from the same EMSK or DSRK.
 o  Derivation of USRKs MUST be coordinated so that two separate
    cryptographic usages do not derive the same key.
 o  Derivation of DSRKs MUST be coordinated so that two separate key
    management domains do not derive the same key.
 o  Derivation of DSRKs and USRKs MUST be specified such that no
    domain can obtain a USRK by providing a domain name identical to a
    Usage Key Label.
 This document provides guidelines for a key derivation mechanism that
 can be used with existing and new EAP methods to provide
 cryptographic separation between usages of EMSK.  This allows for the
 development of new usages without cumbersome coordination between
 different usage definitions.

3. EMSK Key Root Derivation Framework

 The EMSK key derivation framework provides a coordinated means for
 generating multiple root keys from an EMSK.  Further keys may then be
 derived from the root key for various purposes, including encryption,
 integrity protection, entity authentication by way of proof of
 possession, and subsequent key derivation.  A root key is derived
 from the EMSK for a specific set of uses set forth in a usage
 definition described in Section 5.
 The basic EMSK root key hierarchy looks as follows:
                    EMSK
                   /    \
                 USRK1  USRK2
 This document defines how to derive Usage-Specific Root Keys (USRKs)
 from the EMSK and also defines a specific USRK called a Domain-
 Specific Root Key (DSRK).  DSRKs are root keys restricted to use in a
 particular key management domain.  From the DSRK, Usage-Specific Root
 Keys for a particular application may be derived (DSUSRKs).  The
 DSUSRKs are equivalent to USRKs that are restricted to use in a
 particular domain.  The details of lower levels of key hierarchy are
 outside scope of this document.  The key hierarchy looks as follows:

Salowey, et al. Standards Track [Page 7] RFC 5295 EMSK Root Key Derivation August 2008

                    EMSK
                   /    \
                USRK   DSRK
                      /    \
                 DSUSRK1 DSUSRK2

3.1. USRK Derivation

 The EMSK Root Key Derivation Function (KDF) derives a USRK from the
 EMSK, a key label, optional data, and output length.  The KDF is
 expected to give the same output for the same input.  The basic key
 derivation function is given below.
      USRK = KDF(EMSK, key label | "\0" | optional data | length)
    where:
      | denotes concatenation
      "\0" is a NULL octet (0x00 in hex)
      length is a 2-octet unsigned integer in network byte order
 The key labels are printable ASCII strings unique for each usage
 definition and are a maximum of 255 octets.  In general, they are of
 the form label-string@specorg, where specorg is the organization that
 controls the specification of the usage definition of the Root Key.
 The key label is intended to provide global uniqueness.  Rules for
 the allocation of these labels are given in Section 8.
 The NULL octet 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.
 For the optional data, the KDF MUST be capable of processing at least
 2048 opaque octets.  The optional data must be constant during the
 execution of the KDF.  Usage definitions MAY use the EAP Session-ID
 [RFC5247] in the specification of the optional data parameter that
 goes into the KDF function.  In this case, the advantage is that data
 provided into the key derivation is unique to the session that
 generated the keys.
 The KDF must be able to process input keys of up to 256 bytes.  It
 may do this by providing a mechanism for "hashing" long keys down to
 a suitable size that can be consumed by the underlying derivation
 algorithm.

Salowey, et al. Standards Track [Page 8] RFC 5295 EMSK Root Key Derivation August 2008

 The length is a 2-octet unsigned integer in network byte order of the
 output key length in octets.  An implementation of the KDF MUST be
 capable of producing at least 2048 octets of output; however, it is
 RECOMMENDED that Root Keys be at least 64 octets long.
 A usage definition requiring derivation of a Root Key must specify
 all the inputs (other than EMSK) to the key derivation function.
 USRKs MUST be at least 64 octets in length.

3.1.1. On the KDFs

 This specification allows for the use of different KDFs.  However, in
 order to have a coordinated key derivation function, the same KDF
 function MUST be used for all key derivations for a given EMSK.  If
 no KDF is specified, then the default KDF specified in Section 3.1.2
 MUST be used.  A system may provide the capability to negotiate
 additional KDFs.  KDFs are assigned numbers through IANA following
 the policy set in Section 8.  The rules for negotiating a KDF are as
 follows:
 o  If no other KDF is specified, the KDF specified in this document
    MUST be used.  This is the "default" KDF.
 o  The initial authenticated key exchange MAY specify a favored KDF.
    For example, an EAP method may define a preferred KDF to use in
    its specification.  If the initial authenticated key exchange
    specifies a KDF, then this MUST override the default KDF.
 Note that usage definitions MUST NOT concern themselves with the
 details of the KDF construction or the KDF selection, they only need
 to worry about the inputs specified in Section 3.

3.1.2. Default KDF

 The default KDF for deriving root keys from an EMSK is taken from the
 PRF+ key expansion specified in [RFC4306] based on HMAC-SHA-256
 [SHA256].  The PRF+ construction was chosen because of its simplicity
 and efficiency over other mechanisms such as those used in [RFC4346].
 The motivation for the design of PRF+ is described in [SIGMA].  The
 definition of PRF+ from [RFC4306] is given below:

Salowey, et al. Standards Track [Page 9] RFC 5295 EMSK Root Key Derivation August 2008

      PRF+ (K,S) = 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)
 continuing as needed to compute the required length of key material.
 The key, K, is the EMSK and S is the concatenation of the key label,
 the NULL octet, optional data, and length defined in Section 3.1.
 For this specification, the PRF is taken as HMAC-SHA-256 [SHA256].
 Since PRF+ is only defined for 255 iterations, it may produce up to
 8160 octets of key material.

3.2. EMSK and USRK Name Derivation

 The EAP keying framework [RFC5247] specifies that the EMSK MUST be
 named using the EAP Session-ID and a binary or textual indication.
 Following that requirement, the EMSK name SHALL be derived as
 follows:
      EMSKname = KDF ( EAP Session-ID, "EMSK" | "\0" | length )
 where:
      | denotes concatenation
      "EMSK" consists of the 4 ASCII values for the letters
      "\0" = is a NULL octet (0x00 in hex)
      length is the 2-octet unsigned integer 8 in network byte order
 It is RECOMMENDED that all keys derived from the EMSK are referred to
 by the EMSKname and the context of the descendant key usage.  This is
 the default behavior.  Any exceptions SHALL be signaled by individual
 usages.
 USRKs MAY be named explicitly with a name derivation specified as
 follows:
       USRKName =
            KDF(EAP Session-ID, key label|"\0"|optional data|length)
  where:
       key label and optional data MUST be the same as those used
         in the corresponding USRK derivation
       length is the 2-octet unsigned integer 8 in network byte order

Salowey, et al. Standards Track [Page 10] RFC 5295 EMSK Root Key Derivation August 2008

 USRKName derivation and usage are applicable when there is ambiguity
 in referencing the keys using the EMSKname and the associated context
 of the USRK usage.  The usage SHALL signal such an exception in key
 naming, so both parties know the key name used.

4. Domain-Specific Root Key Derivation

 A specific USRK called a Domain-Specific Root Key (DSRK) is derived
 from the EMSK for a specific set of usages in a particular key
 management domain.  Usages derive specific keys for specific services
 from this DSRK.  The DSRK may be distributed to a key management
 domain for a specific set of usages so that keys can be derived
 within the key management domain for those usages.  DSRK-based usages
 will follow a key hierarchy similar to the following:
                                 EMSK
                                /    \
                               /      \
                              /        \
                             /          \
                        DSRK1            DSRK2
                       /  \                /  \
                      /    \              /    \
                DSUSRK11  DSUSRK12  DSUSRK21  DSUSRK22
 The DSRK is a USRK with a key label of "dsrk@ietf.org" and the
 optional data containing a domain label.  The optional data MUST
 contain an ASCII string representing the key management domain for
 which the root key is being derived.  The DSRK MUST be at least 64
 octets long.
 Domain-Specific Usage-Specific Root Keys (DSUSRKs) are derived from
 the DSRK.  The KDF is expected to give the same output for the same
 input.  The basic key derivation function is given below.
      DSUSRK = KDF(DSRK, key label | "\0" | optional data | length)
 The key labels are printable ASCII strings unique for each usage
 definition within a DSRK usage and are a maximum of 255 octets.  In
 general, they are of the form label-string@specorg where specorg is
 the organization that controls the specification of the usage
 definition of the DSRK.  The key label is intended to provide global
 uniqueness.  Rules for the allocation of these labels are given in
 Section 8.  For the optional data, the KDF MUST be capable of
 processing at least 2048 opaque octets.  The optional data must be
 constant during the execution of the KDF.  The length is a 2-octet
 unsigned integer in network byte order of the output key length in
 octets.  An implementation of the KDF MUST be capable of producing at

Salowey, et al. Standards Track [Page 11] RFC 5295 EMSK Root Key Derivation August 2008

 least 2048 octets of output; however, it is RECOMMENDED that DSUSRKs
 be at least 64 octets long.
 Usages that make use of the DSRK must define how the peer learns the
 domain label to use in a particular derivation.  A multi-domain usage
 must define how both DSRKs and specific DSUSRKs are transported to
 different key management domains.  Note that usages may define
 alternate ways to constrain specific keys to particular key
 management domains.
 To facilitate the use of EMSKname to refer to keys derived from
 DSRKs, EMSKname SHOULD be sent along with the DSRK.  The exception is
 when a DSRKname is expected to be used.  The usage SHALL signal such
 an exception in key naming, so both parties know the key name used.
 DSUSRKs MAY be named explicitly with a name derivation specified as
 follows:
      DSUSRKName =
           KDF(EMSKName,key label | "\0" | optional data | length)
 where length is the 2-octet unsigned integer 8 in network byte order.

4.1. Applicability of Multi-Domain Usages

 The DSUSRKs generated by a domain can be used to authorize entities
 in a domain to perform specific functions.  In cases where it is
 appropriate for only a specific domain to be authorized to perform a
 function, the usage SHOULD NOT be defined as multi-domain.
 In some cases, only certain domains are authorized for a particular
 multi-domain usage.  In this case, domains that do not have full
 authorization should not receive the DSRK and should only receive
 DSUSRKs for the usages for which they are authorized.  If it is
 possible for a peer to know which domains are authorized for a
 particular usage without relying on restricting access to the DSRK to
 specific domains, then this recommendation may be relaxed.

Salowey, et al. Standards Track [Page 12] RFC 5295 EMSK Root Key Derivation August 2008

5. Requirements for Usage Definitions

 In order for a usage definition to meet the guidelines for USRK
 usage, it must meet the following recommendations:
 o  The usage must define if it is a domain-enabled usage.
 o  The usage definition MUST NOT use the EMSK in any other way except
    to derive Root Keys using the key derivation specified in
    Section 3 of this document.  They MUST NOT use the EMSK directly.
 o  The usage definition SHOULD NOT require caching of the EMSK.  It
    is RECOMMENDED that the Root Key derived specifically for the
    usage definition (rather than the EMSK) should be used to derive
    child keys for specific cryptographic operations.
 o  Usage definitions MUST define distinct key labels and optional
    data used in the key derivation described in Section 3.  Usage
    definitions are encouraged to use the key name described in
    Section 3.2 and include additional data in the optional data to
    provide additional entropy.
 o  Usage definitions MUST define the length of their Root Keys.  It
    is RECOMMENDED that the Root Keys be at least as long as the EMSK
    (at least 64 octets).
 o  Usage definitions MUST define how they use their Root Keys.  This
    includes aspects of key management covered in the next section on
    Root Key management guidelines.

5.1. Root Key Management Guidelines

 This section makes recommendations for various aspects of key
 management of the Root Key including lifetime, child key derivation,
 caching, and transport.
 It is RECOMMENDED that the Root Key is only used for deriving child
 keys.  A usage definition must specify how and when the derivation of
 child keys should be done.  It is RECOMMENDED that usages following
 similar considerations for key derivation are as outlined in this
 document for the Root Key derivation with respect to cryptographic
 separation and key reuse.  In addition, usages should take into
 consideration the number of keys that will be derived from the Root
 Key and ensure that enough entropy is introduced in the derivation to
 support this usage.  It is desirable that the entropy is provided by
 the two parties that derive the child key.

Salowey, et al. Standards Track [Page 13] RFC 5295 EMSK Root Key Derivation August 2008

 Root Keys' lifetimes should not be more than that of the EMSK.  Thus,
 when the EMSK expires, the Root Keys derived from it should be
 removed from use.  If a new EMSK is derived from a subsequent EAP
 transaction, then a usage implementation should begin to use the new
 Root Keys derived from the new EMSK as soon as possible.  Whether or
 not child keys associated with a Root Key are replaced depends on the
 requirements of the usage definition.  It is conceivable that some
 usage definition forces the child key to be replaced and others allow
 child keys to be used based on the policy of the entities that use
 the child key.
 Recall that the EMSK never leaves the EAP peer and server.  That also
 holds true for some Root Keys; however, some Root Keys may be
 provided to other entities for child key derivation and delivery.
 Each usage definition specification will specify delivery caching
 and/or delivery procedures.  Note that the purpose of the key
 derivation in Section 3 is to ensure that Root Keys are
 cryptographically separate from each other and the EMSK.  In other
 words, given a Root Key, it is computationally infeasible to derive
 the EMSK, any other Root Keys, or child keys associated with other
 Root Keys.  In addition to the Root Key, several other parameters may
 need to be sent.
 Root Key names may be derived using the EAP Session-ID, and thus the
 key name may need to be sent along with the key.  When Root Keys are
 delivered to another entity, the EMSKname and the lifetime associated
 with the specific root keys MUST also be transported to that entity.
 Recommendations for transporting keys are discussed in the Security
 Considerations (Section 7.4).
 Usage definitions may also define how keys are bound to particular
 entities.  This can be done through the inclusion of usage parameters
 and identities in the child key derivation.  Some of this data is
 described as "channel bindings" in [RFC3748].

6. Requirements for EAP System

 The system that wishes to make use of EAP root keys derived from the
 EMSK must take certain things into consideration.  The following is a
 list of these considerations:
 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.

Salowey, et al. Standards Track [Page 14] RFC 5295 EMSK Root Key Derivation August 2008

 o  The EMSK MUST be maintained within a protected location inside the
    entity where it is generated.  Only root keys derived according to
    this specification may be exported from this boundary.
 o  The EMSK MUST be unique for each EAP session
 o  The EAP method MUST provide an identifier for the EAP transaction
    that generated the key.
 o  The system MUST define which usage definitions are used and how
    they are invoked.
 o  The system may define ways to select an alternate PRF for key
    derivation as defined in Section 3.1.
 The system MAY use the MSK transmitted to the Network Access Server
 (NAS) in any way it chooses in accordance with [RFC3748], [RFC5247],
 and other relevant specifications.  This is required for backward
 compatibility.  New usage definitions following this specification
 MUST NOT use the MSK.  If more than one usage uses the MSK, then the
 cryptographic separation is not achieved.  Implementations MUST
 prevent such combinations.

7. Security Considerations

7.1. Key Strength

 The effective key strength of the derived keys will never be greater
 than the strength of the EMSK (or a master key internal to an EAP
 mechanism).

7.2. Cryptographic Separation of Keys

 The intent of the KDF is to derive keys that are cryptographically
 separate: the compromise of one of the Usage-Specific Root Keys
 (USRKs) should not compromise the security of other USRKs or the
 EMSK.  It is believed that the KDF chosen provides the desired
 separation.

7.3. Implementation

 An implementation of an EAP framework should keep the EMSK internally
 as close to where it is derived as possible and only provide an
 interface for obtaining Root Keys.  It may also choose to restrict
 which callers have access to which keys.  A usage definition MUST NOT
 assume that any entity outside the EAP server or EAP peer has access
 to the EMSK.  In particular, it MUST NOT assume that a lower layer
 has access to the EMSK.

Salowey, et al. Standards Track [Page 15] RFC 5295 EMSK Root Key Derivation August 2008

7.4. Key Distribution

 In some cases, it will be necessary or convenient to distribute USRKs
 from where they are generated.  Since these are secret keys, they
 MUST be transported with their integrity and confidentiality
 maintained.  They MUST be transmitted between authenticated and
 authorized parties.  It is also important that the context of the key
 usage be transmitted along with the key.  This includes information
 to identify the key and constraints on its usage such as lifetime.
 This document does not define a mechanism for key transport.  It is
 up to usage definitions and the systems that use them to define how
 keys are distributed.  Usage definition designers may enforce
 constraints on key usage by various parties by deriving a key
 hierarchy and by providing entities only with the keys in the
 hierarchy that they need.

7.5. Key Lifetime

 The key lifetime is dependent upon how the key is generated and how
 the key is used.  Since the Root Key is the responsibility of the
 usage definition, it must determine how long the key is valid for.
 If key lifetime or key strength information is available from the
 authenticated key exchange, then this information SHOULD be used in
 determining the lifetime of the key.  If possible, it is recommended
 that key lifetimes be coordinated throughout the system.  Setting a
 key lifetime shorter that a system lifetime may result in keys
 becoming invalid with no convenient way to refresh them.  Setting a
 key lifetime to longer may result in decreased security since the key
 may be used beyond its recommended lifetime.

7.6. Entropy Consideration

 The number of root keys derived from the EMSK is expected to be low.
 Note that there is no randomness required to be introduced into the
 EMSK-to-Root-Key derivation beyond the root key labels.  Thus, if
 many keys are going to be derived from a Root Key, it is important
 that Root-Key-to-child-key derivation introduce fresh random numbers
 in deriving each key.

8. IANA Considerations

 The keywords "Private Use", "Specification Required", and "IETF
 Consensus" that appear in this document when used to describe
 namespace allocation are to be interpreted as described in [RFC5226].

Salowey, et al. Standards Track [Page 16] RFC 5295 EMSK Root Key Derivation August 2008

8.1. Key Labels

 This specification introduces a new name space for "USRK Key Labels".
 Key labels MUST be printable US-ASCII strings, and MUST NOT contain
 the characters at-sign ("@") except as noted below, comma (","),
 whitespace, control characters (ASCII codes 32 or less), or the ASCII
 code 127 (DEL).  Labels are case-sensitive and MUST NOT be longer
 than 64 characters.
 Labels can be assigned based on Specification Required policy
 [RFC5226].  In addition, the labels "experimental1" and
 "experimental2" are reserved for experimental use.  The following
 considerations apply to their use:
 Production networks do not necessarily support the use of
 experimental code points.  The network scope of support for
 experimental values should carefully be evaluated before deploying
 any experiment across extended network domains, such as the public
 Internet.  The potential to disrupt the stable operation of EAP
 devices is a consideration when planning an experiment using such
 code points.
 The network administrators should ensure that each code point is used
 consistently to avoid interference between experiments.  Particular
 attention should be given to security vulnerabilities and the freedom
 of different domains to employ their own experiments.  Cross-domain
 usage is NOT RECOMMENDED.
 Similarly, labels "private1" and "private2" have been reserved for
 Private Use within an organization.  Again, cross-domain usage of
 these labels is NOT RECOMMENDED.
 Labels starting with a string and followed by the "@" and a valid,
 fully qualified Internet domain name [RFC1034] can be requested by
 the person or organization that is in control of the domain name.
 Such labels can be allocated based on Expert Review with
 Specification Required.  Besides the review needed for Specification
 Required (see Section 4.1 of [RFC5226]), the expert needs to review
 the proposed usage for conformance to this specification, including
 the suitability of the usage according to the applicability statement
 outlined in Section 1.1.  It is RECOMMENDED that the specification
 contain the following information:
 o  A description of the usage
 o  The key label to be used
 o  Length of the Root Key

Salowey, et al. Standards Track [Page 17] RFC 5295 EMSK Root Key Derivation August 2008

 o  If optional data is used, what it is and how it is maintained
 o  How child keys will be derived from the Root Key and how they will
    be used
 o  How lifetime of the Root Key and its child keys will be managed
 o  Where the Root Keys or child keys will be used and how they are
    communicated if necessary
 The following labels are reserved by this document: "EMSK",
 "dsrk@ietf.org".

8.2. PRF Numbers

 This specification introduces a new number space for "EMSK PRF
 numbers".  The numbers are in the range 0 to 255.  Numbers from 0 to
 220 are assigned through the policy IETF Consensus, and numbers in
 the range 221 to 255 are left for Private Use.  The initial registry
 contains the following values:
    0 RESERVED
    1 HMAC-SHA-256 PRF+ (Default)

9. Acknowledgements

 This document expands upon previous collaboration with Pasi Eronen.
 This document reflects conversations with Bernard Aboba, Jari Arkko,
 Avi Lior, David McGrew, Henry Haverinen, Hao Zhou, Russ Housley, Glen
 Zorn, Charles Clancy, Dan Harkins, Alan DeKok, Yoshi Ohba, and
 members of the EAP and HOKEY working groups.
 Thanks to Dan Harkins for the idea of using a single root key name to
 refer to all keys.

Salowey, et al. Standards Track [Page 18] RFC 5295 EMSK Root Key Derivation August 2008

10. References

10.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
            Levkowetz, "Extensible Authentication Protocol (EAP)",
            RFC 3748, June 2004.
 [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
            RFC 4306, December 2005.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008.
 [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
            Authentication Protocol (EAP) Key Management Framework",
            RFC 5247, August 2008.
 [SHA256]   National Institute of Standards and Technology, "Secure
            Hash Standard", FIPS 180-2, With Change Notice 1 dated
            February 2004, August 2002.

10.2. Informative References

 [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
            STD 13, RFC 1034, November 1987.
 [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
            (TLS) Protocol Version 1.1", RFC 4346, April 2006.
 [SIGMA]    Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to
            Authenticated Diffie-Hellman and its Use in the IKE
            Protocols", LNCS 2729, Springer, 2003,
            <http://www.informatik.uni-trier.de/~ley/db/conf/
            crypto/crypto2003.html>.

Salowey, et al. Standards Track [Page 19] RFC 5295 EMSK Root Key Derivation August 2008

Authors' Addresses

 Joseph Salowey
 Cisco Systems
 EMail: jsalowey@cisco.com
 Lakshminath Dondeti
 Qualcomm, Inc
 EMail: ldondeti@qualcomm.com
 Vidya Narayanan
 Qualcomm, Inc
 EMail: vidyan@qualcomm.com
 Madjid Nakhjiri
 Motorola
 EMail: madjid.nakhjiri@motorola.com

Salowey, et al. Standards Track [Page 20] RFC 5295 EMSK Root Key Derivation August 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Salowey, et al. Standards Track [Page 21]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5295.txt · Last modified: 2008/08/26 23:34 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki