[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-hokey-emsk-hierarchy

Network Working Group                                         J. Salowey
Internet-Draft                                             Cisco Systems
Expires: December 21, 2006                                    L. Dondeti
                                                            V. Narayanan
                                                           Qualcomm, Inc
                                                             M. Nakhjiri
                                                           Motorola Labs
                                                           June 19, 2006

Specification for the Derivation of Usage Specific Root Keys (USRK) from
                 an Extended Master Session Key (EMSK)

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   An Extended Master Session Key (EMSK) is a cryptographic key
   generated from an Extensible Authentication Protocol (EAP) exchange
   reserved solely for the purpose of deriving master keys for one or

Salowey, et al.         Expires December 21, 2006               [Page 1]

Internet-Draft               USRK Derivation                   June 2006

   more purposes identified as usage definitions.  This document
   specifies a mechanism for deriving cryptographically separate root
   keys from the EMSK, called usage specific root Keys (USRK).  The
   document provides a set of requirements for avoiding conflicts
   between usage definitions to ensure this cryptographic separation.
   The USRK is used according to the usage definition defined for a
   specific purpose.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Cryptographic Separation and Coordinated Key Derivation  . . .  4
   3.  USRK Key Derivation Framework  . . . . . . . . . . . . . . . .  5
     3.1   The  USRK Key Derivation Function  . . . . . . . . . . . .  6
     3.2   Default PRF  . . . . . . . . . . . . . . . . . . . . . . .  7
     3.3   Key Naming and Application Data  . . . . . . . . . . . . .  8
   4.  Requirements for Usage Definitions . . . . . . . . . . . . . .  8
     4.1   USRK Management Guidelines . . . . . . . . . . . . . . . .  9
   5.  Requirements for EAP System  . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
     6.1   Key strength . . . . . . . . . . . . . . . . . . . . . . . 10
     6.2   Cryptographic separation of keys . . . . . . . . . . . . . 10
     6.3   Implementation . . . . . . . . . . . . . . . . . . . . . . 11
     6.4   Key Distribution . . . . . . . . . . . . . . . . . . . . . 11
     6.5   Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 11
     6.6   Entropy consideration  . . . . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
     7.1   USRK Key Labels  . . . . . . . . . . . . . . . . . . . . . 12
     7.2   PRF numbers  . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1   Normative References . . . . . . . . . . . . . . . . . . . 13
     9.2   Informative References . . . . . . . . . . . . . . . . . . 14
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 16

Salowey, et al.         Expires December 21, 2006               [Page 2]

Internet-Draft               USRK Derivation                   June 2006

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
   assume that the MSK keying material 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 called usage specific root keys (USRK).  This document also
   provides guidelines for creating usage definitions for the various
   applications of EAP key material and for the management of the USRKs.
   Note that previously USRKs were referred to as application master
   session keys (AMSKs), however this term proved to be confusing as it
   suggest a particular class of usages dealing with higher layer
   applications that it was not limited to serve.  In this document
   terms application and usage (or "usage definition") to refer to a
   specific use case of the EAP keying material for which a USRK is

   <editor's note: the terminology is not clear yet.  We need to work
   this out.  Context has been suggested as a replacement for usage and

   Different applications 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
   application of EAP key material to make use of this specification it
   must specify a usage definition.  This document does not define how
   applications should use the derived USRKs or discuss whether such
   uses are valid.  It does define a framework for the derivation of
   USRKs for different purposes such that different applications can be
   developed independently from one another.  The goal is to have
   security properties of one usage have minimal affect on the security
   properties of other usages.

   In order to keep specific uses separate from one another two
   requirements are defined in the following sections.  One is
   coordinated key derivation and another is cryptographic separation.

1.1  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119]

Salowey, et al.         Expires December 21, 2006               [Page 3]

Internet-Draft               USRK Derivation                   June 2006

   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 a related applications or
      services.  This document provides guidelines and recommendations
      for what should be included in usage definitions.  This document
      does not place any constrains on the types of applications or
      services that create usage definitions.

   Usage Specific Root Key (USRK)
      Keying material derived from the EMSK for a particular usage
      definition as specified in this document.  It is used to derive
      child keys in a way defined by its usage definition.
      <editor's note: USRK have been previously called AMSK for
      application master session key.>

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: it is
   plausible to use the IKEv2 PRF on the EMSK and generate a key stream.
   Keys of various lengths as required may be provided from the key
   stream for various uses.  The other option is to 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.  This allows child
   keys to be derived in any order, independent of other keys.  Thus it
   is desirable to the second option from above.  That 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.

Salowey, et al.         Expires December 21, 2006               [Page 4]

Internet-Draft               USRK Derivation                   June 2006

   If cryptographic separation is not maintained then the security of
   one usage depends upon the security of all other usages that use key
   derived from the EMSK.  If a system does not have this property then
   a usage's security depends upon all other applications deriving keys
   from the same EMSK, which is undesirable.  In order to prevent
   security problems in one application from interfering with another
   application the following cryptographic separation is required:

   o  It MUST be computationally infeasible to compute the EMSK from any
   o  Any USRK must be cryptographically separate from any other USRK
      derived from the same EMSK
   o  Derivation of USRKs must be coordinated so that two separate
      cryptographic usages do not derive the same key.

   This document provides guidelines for a mechanism, which can be used
   with existing and new EAP methods and applications to provide
   cryptographic separation between applications of EAP keying material.
   This allows for the development of new usages without cumbersome
   coordination between different usage definitions.

3.  USRK Key Derivation Framework

   The USRK key derivation framework provides a coordinated means for
   generating multiple usage specific root keys (USRKs) from an EMSK.
   Further keys may then be derived from the USRK for various purposes,
   including encryption, integrity protection, entity authentication by
   way of proof of possession, and subsequent key derivation.  The
   usages of the USRK are set forth in a usage definition described in
   Section 4.

   The USRK key derivation function (KDF) derives an USRK from the
   Extended Master Session Key (EMSK) described above, an 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, optional data, length)

   The key labels are printable ASCII strings unique for each usage
   definition and are a maximum of 255 bytes.  In general they are of
   the form label-string@domain where domain is the organization that
   controls the specification of the usage definition of the USRK.  The
   key label is intended to provide global uniqueness.  Rules for the
   allocation of these labels are given in Section 7.  For the optional
   data the KDF MUST be capable of processing at least 2048 opaque
   octets.  The length is a 2 byte unsigned integer in network byte
   order.  An implementation of the KDF MUST be capable of producing at

Salowey, et al.         Expires December 21, 2006               [Page 5]

Internet-Draft               USRK Derivation                   June 2006

   least 2048 octets of output, however it is RECOMMENDED that USRKs be
   64 octets long.

   A usage definition requiring derivation of an USRK, must specify the
   all inputs (other than EMSK) to the key derivation function.

3.1  The  USRK Key Derivation Function

   The EMSK key derivation function is based on a pseudo random function
   (PRF) that has the following function prototype:

        KDF = PRF(key, data)

   <Editor's Note: there has been some discussion as to whether the PRF
   should instead be something like

   KDF = PRF( key, PRF( key,data ) )

   in case the PRF will not generate sufficiently different outputs if
   the data does not differ significantly for 2 usage definitions.  For
   example it is possible that the data may differ by only a single
   octet.  However since hashing the data will not increase its entropy
   it is not clear that this actually helps.  More discussion is needed.


        key = EMSK
        data = label + "\0" + op-data + length
        label = ASCII key label
        op-data = optional data
        length = 2 byte unsigned integer in network byte order
        '\0' = is a NUL byte (0x00 in hex)
        + denotes concatenation

   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

   This specification allows for the use of different PRFs, however in
   order to have a coordinated key derivation function the same PRF
   function MUST be used for all key derivations for a given EMSK.  If
   no PRF is specified then the default PRF specified in Section 3.2
   MUST be used.  A system may provide the capability to negotiate

Salowey, et al.         Expires December 21, 2006               [Page 6]

Internet-Draft               USRK Derivation                   June 2006

   additional PRFs.  PRFs are assigned numbers through IANA following
   the policy set in section Section 7.  The rules for negotiating a PRF
   are as follows:

   o  The initial authenticated key exchange MAY specify a favored PRF
      as a hint.  For example an EAP method may define a preferred PRF
      to use in its specification.
   o  If the authenticated EAP key exchange is carried within another
      lower layer protocol that has negotiation capabilities then this
      protocol MAY attempt to negotiate a PRF to use. <editor's note: Is
      this a good idea, the concern is that it may lead to usage
      definitions trying to control what the PRF which may be difficult
      to manage. >
   o  If no other PRF is specified the PRF specified in this document
      MUST be used.
   o  If the initial authenticated key exchange specifies a PRF then
      this MUST override the default PRF.
   o  A system MAY specify a separate default PRF if all participants
      within the system have the knowledge of which PRF to use.  If
      specified this MUST take precedence over key exchange defined PRF.
   o  If the system allows a lower layer protocol to negotiates a PRF
      then the negotiated PRF MUST be used.  It SHOULD take into account
      any hints that are provide by the authenticated key exchange.
      Note that this capability MUST protect against bidding down

   Note that usage definitions MUST not concern themselves with the
   details of the PRF construction or the PRF selection, they only need
   to worry about the inputs specified in Section 3.

3.2  Default PRF

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

        prf+ (K,S) = T1 | T2 | T3 | T4 | ...


        T1 = prf (K, S | 0x01)
        T2 = prf (K, T1 | S | 0x02)
        T3 = prf (K, T2 | S | 0x03)
        T4 = prf (K, T3 | S | 0x04)

Salowey, et al.         Expires December 21, 2006               [Page 7]

Internet-Draft               USRK Derivation                   June 2006

   continuing as needed to compute the required length of key material.
   The key, K, is the EMSK and S is the data 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 bytes of key material.

3.3  Key Naming and Application Data

   It is RECOMMENDED that the authenticated key exchange export a value,
   an EAP Session-ID, that is known to both sides to provide a way to
   identify the exchange and the keys derived by the exchange.  The EAP
   keying framework [I-D.ietf-eap-keying] defines this value and
   provides an example of how to name an EMSK.  The use of names based
   on the Session-ID in [I-D.ietf-eap-keying] is RECOMMENDED.

   It is RECOMMENDED that each root key has a name derived as follows:

        USRK key name = prf-64( EAP Session-ID, key-label )

   where prf-64 is the first 64 bits from the output

   Usage definitions MAY use the EAP session-ID in the specification of
   the optional data parameter that go into the KDF function.  This
   provides the advantage of providing data into the key derivation that
   is unique to the session that generated the keys.

4.  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 definition MUST NOT use the EMSK in any other way except
      to derive usage specific root Keys (USRK) 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 USRK derived specifically for the usage
      definition rather than the EMSK should be used as a root key to
      derive child keys for specific cryptographic operations.
   o  Usage definition 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.3 and include additional data in the optional data to
      provide additional entropy.
   o  Usage definitions MUST define the length of their USRK.  It is
      RECOMMENDED that the USRK be at least as long as the EMSK (64

Salowey, et al.         Expires December 21, 2006               [Page 8]

Internet-Draft               USRK Derivation                   June 2006

   o  Usage definitions MUST define how they use their USRK.  This
      includes aspects of key management covered in the next section on
      USRK Management guidelines.

4.1  USRK Management Guidelines

   In this section makes recommendations for various aspects of key
   management of the USRK including lifetime, child key derivation,
   caching and transport.

   It is RECOMMENDED that the USRK only used as a root key 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 as are
   outlined in this document for the USRK 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 USRK and ensure that the 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.

   USRKs have the same lifetime as the EMSK.  Thus, when the EMSK
   expires the USRKs derived from it should be removed from use.  If a
   new EMSK is derived from a subsequent EAP transaction then an usage
   implementation should begin to use the new USRK derived from the new
   EMSK as soon as possible.  Whether or not child keys associated with
   an USRK are replaced depends on the requirements of the usage
   definition.  It is conceivable that some usage definition force the
   child key to be replaced and others to allow child keys to be used
   based on the policy of the entities that use the child key.

   <editor's note: It seems it may desirable for a USRK lifetimes to
   vary with usage definitions as well>

   Recall that the EMSK never leaves the EAP peer and server.  That also
   holds true for some USRKs; however, some USRKs 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 USRKs are cryptographically separate from
   each other and the EMSK.  In other words, given an USRK, it is
   computationally infeasible to derive the EMSK, any other USRKs, or
   child keys associated with other USRKs.  In addition to the USRK,
   several other parameters may need to be sent.  An USRK name should be
   derived from the EMSK key name, and thus the key name needs to be
   sent along with the key.  When USRKs are delivered to another entity,
   the lifetime associated with the specific root keys MUST also be
   transported to that entity.

Salowey, et al.         Expires December 21, 2006               [Page 9]

Internet-Draft               USRK Derivation                   June 2006

   Usage definition may also define how keys are bound to particular
   usages 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].

5.  Requirements for EAP System

   The system that wishes to make use of EAP USRKs must take certain
   things into consideration.  The following is a list of these

   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 a protected location inside the
      entity where it is generated.  Only keys (USRKs) derived according
      to this specification may be exported from this boundary.
   o  The EMSK MUST be unique for each 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 NAS in any way it
   chooses.  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.

6.  Security Considerations

6.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

6.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

Salowey, et al.         Expires December 21, 2006              [Page 10]

Internet-Draft               USRK Derivation                   June 2006

6.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 USRKs.  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 EAP
   framework has access to the EMSK.  In particular it MUST NOT assume
   that a lower layer has access to the EMSK.

6.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.

6.5  Key Lifetime

   The key lifetime is dependent upon how the key is generated and how
   the key is used.  Since the USRK 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 is 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.

6.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 an USRK it is important that
   USRK to child key derivation introduce fresh random numbers in

Salowey, et al.         Expires December 21, 2006              [Page 11]

Internet-Draft               USRK Derivation                   June 2006

   deriving each key.

7.  IANA Considerations

   CONSENSUS" that appear in this document when used to describe
   namespace allocation are to be interpreted as described in [RFC2434].

7.1  USRK Key Labels

   This specification introduces a new name space for "USRK key labels".
   Key labels are of one of two formats: "label-string" or
   "label-string@domain" (without the double quotes).

   Labels of the form "label-string" registered by the IANA MUST be
   printable US-ASCII strings, and MUST NOT contain the characters at-
   sign ("@"), 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 of this form are
   assigned based on the IETF CONSENSUS policy.

   Labels with the at-sign in them of the form "label-string@domain"
   where the part preceding the at-sign is the label.  The format of the
   part preceding the at-sign is not specified; however, these labels
   MUST be printable US-ASCII strings, and MUST NOT contain the comma
   character (","), whitespace, control characters (ASCII codes 32 or
   less), or the ASCII code 127 (DEL).  They MUST have only a single at-
   sign in them.  The part following the at-sign MUST be a valid, fully
   qualified internet domain name [RFC1034] controlled by the person or
   organization defining the label.  Labels are case-sensitive, and MUST
   NOT be longer than 64 characters.  It is up to each domain how it
   manages its local namespace.  Note that the total number of octets in
   a label is limited to 255.  It has been noted that these labels
   resemble STD 11 [RFC0822] addresses and network access identifiers
   (NAI) defined in [RFC4282].  This is purely coincidental and has
   nothing to do with STD 11 [RFC0822] or [RFC4282].  An example of a
   locally defined label is "service@example.com" (without the double

   Labels within the "ietf.org" domain are assigned based on the IETF
   CONSENSUS policy with specification recommended.  Labels from other
   domains may be registered with IANA by the person or organization
   controlling the domain with an assignment policy of SPECIFICATION
   REQUIRED.  It is RECOMMENDED that the specification contain the
   following information:

Salowey, et al.         Expires December 21, 2006              [Page 12]

Internet-Draft               USRK Derivation                   June 2006

   o  A description of the usage
   o  The key label to be used
   o  Length of the USRK
   o  If optional data is used, what it is and how it is maintained
   o  How child keys will be derived from the USRK and how they will be
   o  How lifetime of the USRK and its child keys will be managed
   o  Where the USRKs or child keys will be used and how they are
      communicated if necessary

7.2  PRF numbers

   This specification introduces a new number space for "EMSK PRF
   numbers".  The numbers are int he 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
   should contain the following values:

      0 RESERVED
      1 HMAC-SHA-256 PRF+ (Default)

8.  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 and members of the
   EAP working group.

9.  References

9.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [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.

Salowey, et al.         Expires December 21, 2006              [Page 13]

Internet-Draft               USRK Derivation                   June 2006

   [SHA256]   National Institute of Standards and Technology, "Secure
              Hash Standard", FIPS 180-2, August 2002.

              With Change Notice 1 dated February 2004

9.2  Informative References

              Aboba, B., "Extensible Authentication Protocol (EAP) Key
              Management Framework", draft-ietf-eap-keying-13 (work in
              progress), May 2006.

   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 2005.

   [SIGMA]    Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to
              Authenticated Diffie-Hellman and its Use in the IKE
              Protocols", LNCS 2729,  Springer, 2003.

              Available at http://www.informatik.uni-trier.de/~ley/db/

Authors' Addresses

   Joseph Salowey
   Cisco Systems

   Email: jsalowey@cisco.com

   Lakshminath Dondeti
   Qualcomm, Inc

   Email: ldondeti@qualcomm.com

Salowey, et al.         Expires December 21, 2006              [Page 14]

Internet-Draft               USRK Derivation                   June 2006

   Vidya Narayanan
   Qualcomm, Inc

   Email: vidyan@qualcomm.com

   Madjid Nakhjiri
   Motorola Labs

   Email: Madjid.nakhjiri@motorola.com

Salowey, et al.         Expires December 21, 2006              [Page 15]

Internet-Draft               USRK Derivation                   June 2006

Intellectual Property Statement

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Salowey, et al.         Expires December 21, 2006              [Page 16]

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/