draft-ietf-hokey-emsk-hierarchy-07.txt   rfc5295.txt 
Network Working Group J. Salowey Network Working Group J. Salowey
Internet-Draft Cisco Systems Request for Comments: 5295 Cisco Systems
Updates: eap-keying (RFC Ed to L. Dondeti Updates: 5247 L. Dondeti
replace this with RFC number) V. Narayanan Category: Standards Track V. Narayanan
(if approved) Qualcomm, Inc Qualcomm, Inc
Intended status: Standards Track M. Nakhjiri M. Nakhjiri
Expires: December 25, 2008 Motorola Motorola
June 23, 2008 August 2008
Specification for the Derivation of Root Keys from an Extended Master
Session Key (EMSK)
draft-ietf-hokey-emsk-hierarchy-07
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-
Drafts.
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 Specification for the Derivation of Root Keys
http://www.ietf.org/ietf/1id-abstracts.txt. from an Extended Master Session Key (EMSK)
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 25, 2008. 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 Abstract
The Extensible Authentication Protocol (EAP) defined the Extended The Extensible Authentication Protocol (EAP) defined the Extended
Master Session Key (EMSK) generation, but reserved it for unspecified Master Session Key (EMSK) generation, but reserved it for unspecified
future uses. This memo reserves the EMSK for the sole purpose of future uses. This memo reserves the EMSK for the sole purpose of
deriving root keys. Root keys are are master keys that can be used deriving root keys. Root keys are master keys that can be used for
for multiple purposes, identified by usage definitions. This multiple purposes, identified by usage definitions. This document
document also specifies a mechanism for avoiding conflicts between also specifies a mechanism for avoiding conflicts between root keys
root keys by deriving them in a manner that guarantee cryptographic by deriving them in a manner that guarantees cryptographic
separation. Finally, this document also defines one such root key separation. Finally, this document also defines one such root key
usage: domain specific root keys are root keys made available to and usage: Domain-Specific Root Keys are root keys made available to and
used within specific key management domains. used within specific key management domains.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicable usages of keys derived from the EMSK . . . . . 3 1.1. Applicable Usages of Keys Derived from the EMSK . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Cryptographic Separation and Coordinated Key Derivation . . . 6 2. Cryptographic Separation and Coordinated Key Derivation . . . 6
3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 7 3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 7
3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 7 3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. On the KDFs . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. On the KDFs . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. Default KDF . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. Default KDF . . . . . . . . . . . . . . . . . . . . . 9
3.2. EMSK and USRK Name Derivation . . . . . . . . . . . . . . 9 3.2. EMSK and USRK Name Derivation . . . . . . . . . . . . . . 10
4. Domain Specific Root Key Derivation . . . . . . . . . . . . . 10 4. Domain-Specific Root Key Derivation . . . . . . . . . . . . . 11
4.1. Applicability of Multi-Domain usages . . . . . . . . . . . 12 4.1. Applicability of Multi-Domain Usages . . . . . . . . . . . 12
5. Requirements for Usage Definitions . . . . . . . . . . . . . . 12 5. Requirements for Usage Definitions . . . . . . . . . . . . . . 13
5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 13 5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 13
6. Requirements for EAP System . . . . . . . . . . . . . . . . . 14 6. Requirements for EAP System . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Key Strength . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Cryptographic separation of keys . . . . . . . . . . . . . 15 7.2. Cryptographic Separation of Keys . . . . . . . . . . . . . 15
7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 15 7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 15
7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 15 7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 16
7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 15 7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 16
7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 16 7.6. Entropy Consideration . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 17 8.2. PRF Numbers . . . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
This document deals with keys generated by authenticated key exchange This document deals with keys generated by authenticated key exchange
mechanisms defined within the EAP framework [RFC3748]. EAP defines mechanisms defined within the EAP framework [RFC3748]. EAP defines
two types of keying material; a Master Session Key (MSK) and an two types of keying material: a Master Session Key (MSK) and an
Extended Master Session Key (EMSK). The EAP specification implicitly Extended Master Session Key (EMSK). The EAP specification implicitly
assumes that the MSK produced by EAP will be used for a single 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 purpose at a single device; however, it does reserve the EMSK for
future use. This document defines the EMSK to be used solely for future use. This document defines the EMSK to be used solely for
deriving root keys using the key derivation specified. The root keys deriving root keys using the key derivation specified. The root keys
are meant for specific purposes called usages; a special usage class are meant for specific purposes called usages; a special usage class
is the domain specific root keys made available to and used within is the Domain-Specific Root Keys made available to and used within
specific key management domains. This document also provides specific key management domains. This document also provides
guidelines for creating usage definitions for the various uses of EAP guidelines for creating usage definitions for the various uses of EAP
key material and for the management of the root keys. In this key material and for the management of the root keys. In this
document, the terms application and usage (or "usage definition") document, the terms application and usage (or "usage definition")
refer to a specific use case of the EAP keying material. refer to a specific use case of the EAP keying material.
Different uses for keys derived from the EMSK have been proposed. Different uses for keys derived from the EMSK have been proposed.
Some examples include hand off across access points in various mobile Some examples include hand-off across access points in various mobile
technologies, mobile IP authentication and higher layer application technologies, mobile IP authentication, and higher-layer application
authentication. In order for a particular usage of EAP key material authentication. In order for a particular usage of EAP key material
to make use of this specification it must specify a so-called usage to make use of this specification, it must specify a so-called usage
definition. This document does not define how the derived Usage definition. This document does not define how the derived Usage-
Specific Root Keys (USRK) are used, see the following section for Specific Root Keys (USRK) are used; see the following section for
discussion of applicable usages. It does define a framework for the discussion of applicable usages. It does define a framework for the
derivation of USRKs for different purposes such that different usages derivation of USRKs for different purposes such that different usages
can be developed independently from one another. The goal is to have 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 one usage have minimal or no effect on the
security properties of other usages. security properties of other usages.
This document does define a special class of USRK, called a Domain 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 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 management domain. Each DSRK is a root key used to derive Domain-
Specific Usage Specific Root Keys (DSUSRK). The DSUSRKs are USRKs Specific Usage-Specific Root Keys (DSUSRK). The DSUSRKs are USRKs
specific to a particular key management domain. specific to a particular key management domain.
In order to keep root keys for specific purposes separate from one In order to keep root keys for specific purposes separate from one
another, two requirements are defined in the following sections. One another, two requirements are defined in the following sections. One
is coordinated key derivation and another is cryptographic is coordinated key derivation and another is cryptographic
separation. separation.
1.1. Applicable usages of keys derived from the EMSK 1.1. Applicable Usages of Keys Derived from the EMSK
The EMSK is typically established as part of network access The EMSK is typically established as part of network access
authentication and authorization. It is expected that keys derived authentication and authorization. It is expected that keys derived
from EMSK will be used in protocols related to network access, such from EMSK will be used in protocols related to network access, such
as handover optimizations, and the scope of these protocols is as handover optimizations, and the scope of these protocols is
usually restricted to the endpoints of the lower layers over which usually restricted to the endpoints of the lower layers over which
EAP packets are sent. EAP packets are sent.
In particular, it is inappropriate for the security of higher layer In particular, it is inappropriate for the security of higher-layer
applications to solely rely on keys derived from network access applications to solely rely on keys derived from network access
authentication. Even when used together with another, independent authentication. Even when used together with another, independent
security mechanism, the use of these keys needs to be carefully security mechanism, the use of these keys needs to be carefully
evaluated with regards to the benefits of the optimization and the evaluated with regards to the benefits of the optimization and the
need to support multiple solutions. Performance optimizations may need to support multiple solutions. Performance optimizations may
not warrant the close tie-in that may be required between the layers 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 in order to use EAP-based keys. Such optimizations may be offset by
the complexities of managing the validity and usage of key materials. the complexities of managing the validity and usage of key materials.
Keys generated from subsequent EAP authentications may be beyond the Keys generated from subsequent EAP authentications may be beyond the
knowledge and control of applications. knowledge and control of applications.
From an architectural point of view, applications should not make From an architectural point of view, applications should not make
assumptions about the lower layer technology (such as network access assumptions about the lower-layer technology (such as network access
authentication) used on any particular hop along the path between the authentication) used on any particular hop along the path between the
application endpoints. application endpoints.
From a practical point of view, making such assumptions would From a practical point of view, making such assumptions would
complicate using those applications over lower layers that do not use complicate using those applications over lower layers that do not use
EAP, and make it more difficult for applications and network access EAP, and make it more difficult for applications and network access
technologies to evolve independently of each other. technologies to evolve independently of each other.
Parties using keys derived from EMSK also need trust relationships Parties using keys derived from EMSK also need trust relationships
with the EAP endpoints, and mechanisms for securely communicating the with the EAP endpoints, and mechanisms for securely communicating the
keys. keys.
For most applications, it is not appropriate to assume that all For most applications, it is not appropriate to assume that all
current and future access networks are trusted to secure the current and future access networks are trusted to secure the
application function. Instead, applications should implement the application function. Instead, applications should implement the
required security mechanisms in access independent manner. required security mechanisms in an access-independent manner.
Implementation considerations may also complicate communication of Implementation considerations may also complicate communication of
keys to an application from the lower layer. For instance, in many keys to an application from the lower layer. For instance, in many
configurations applications may run on a different device than the configurations, application protocol endpoints may be different from
one providing EAP-based network access to it. the EAP endpoints.
Given all this, it is NOT RECOMMENDED to use keys derived from the Given all this, it is NOT RECOMMENDED to use keys derived from the
EMSK as an exclusive security mechanism, when their usage is not EMSK as an exclusive security mechanism, when their usage is not
inherently, and by permanent nature, tied to the lower layer where inherently, and by permanent nature, tied to the lower layer where
network access authentication was performed. network access authentication was performed.
Keys derived from EAP are pairwise by nature and are not directly Keys derived from EAP are pair-wise by nature and are not directly
suitable for multicast or other group usages such as those involved suitable for multicast or other group usages such as those involved
in some routing protocols. It is possible to use keys derived from in some routing protocols. It is possible to use keys derived from
EAP in protocols that distribute group keys to group participants. EAP in protocols that distribute group keys to group participants.
The definition of these group key distribution protocols is beyond The definition of these group key distribution protocols is beyond
the scope of this document and would require additional the scope of this document and would require additional
specification. specification.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119].
The following terms are taken from [RFC3748]: EAP Server, peer, The following terms are taken from [RFC3748]: EAP Server, peer,
authenticator, Master Session Key (MSK), Extended Master Session Key authenticator, Master Session Key (MSK), Extended Master Session Key
(EMSK), Cryptographic Separation. (EMSK), Cryptographic Separation.
Usage Definition Usage Definition
An application of cryptographic key material to provide one or An application of cryptographic key material to provide one or
more security functions such as authentication, authorization, more security functions such as authentication, authorization,
encryption or integrity protection for related applications or encryption, or integrity protection for related applications or
services. This document provides guidelines and recommendations services. This document provides guidelines and recommendations
for what should be included in usage definitions. This document for what should be included in usage definitions. This document
does not place any constraints on the types of use cases or does not place any constraints on the types of use cases or
services that create usage definitions. services that create usage definitions.
Usage Specific Root Key (USRK) Usage-Specific Root Key (USRK)
Keying material derived from the EMSK for a particular usage Keying material derived from the EMSK for a particular usage
definition. It is used to derive child keys in a way defined by definition. It is used to derive child keys in a way defined by
its usage definition. its usage definition.
Key Management Domain Key Management Domain
A key management domain is specified by the scope of a given root 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. The scope is the collection of systems authorized to access
key material derived from that key. Systems within a key key material derived from that key. Systems within a key
management domain may be authorized to (1) derive key materials, management domain may be authorized to (1) derive key materials,
(2) use key materials, or (3) distribute key materials to other (2) use key materials, or (3) distribute key materials to other
systems in the same domain. A derived key's scope is constrained systems in the same domain. A derived key's scope is constrained
to a subset of the scope of the key it is derived from. In this to a subset of the scope of the key from which it is derived. In
document the term domain refers to a key management domain unless this document, the term "domain" refers to a key management domain
otherwise qualified. unless otherwise qualified.
Domain Specific Root Key (DSRK) Domain Specific Root Key (DSRK)
Keying material derived from the EMSK that is restricted to use in Keying material derived from the EMSK that is restricted to use in
a specific key management domain. It is used to derive child keys a specific key management domain. It is used to derive child keys
for a particular usage definition. The child keys derived from a for a particular usage definition. The child keys derived from a
DSRK are referred to as domain specific usage specific root keys DSRK are referred to as Domain-Specific Usage-Specific Root Keys
(DSUSRK). DSUSRKs are similar to the USRK, except in the fact (DSUSRKs). A DSUSRK is similar to the USRK, except in the fact
that their scope is restricted to the same domain as the parent that its scope is restricted to the same domain as the parent DSRK
DSRK from which it is derived. from which it is derived.
2. Cryptographic Separation and Coordinated Key Derivation 2. Cryptographic Separation and Coordinated Key Derivation
The EMSK is used to derive keys for multiple use cases, and thus it The EMSK is used to derive keys for multiple use cases, and thus it
is required that the derived keys are cryptographically separate. is required that the derived keys are cryptographically separate.
Cryptographic separation means that when multiple keys are derived Cryptographic separation means that when multiple keys are derived
from an EMSK, given any derived key it is computationally infeasible from an EMSK, given any derived key, it is computationally infeasible
to derive any of the other derived keys. Note that deriving the EMSK to derive any of the other derived keys. Note that deriving the EMSK
from any combinations of the derived keys must also be from any combinations of the derived keys must also be
computationally infeasible. In practice this means that derivation computationally infeasible. In practice, this means that derivation
of an EMSK from a derived key or derivation of one child key from of an EMSK from a derived key or derivation of one child key from
another must require an amount of computation equivalent to that another must require an amount of computation equivalent to that
required to, say, reversing a cryptographic hash function. required to, say, reversing a cryptographic hash function.
Cryptographic separation of keys derived from the same key can be Cryptographic separation of keys derived from the same key can be
achieved in many ways. Two obvious methods are as follows: it is achieved in many ways. Two obvious methods are as follows:
plausible to use the IKEv2 PRF [RFC4306] on the EMSK and generate a
key stream. Keys of various lengths may be provided as required 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 use 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.
If cryptographic separation is not maintained then the security of o Use a Pseudo-Random Function (PRF) on the EMSK and generate a key
one usage depends upon the security of all other usages that use key stream. Keys of various lengths may be provided as required from
derived from the EMSK. If a system does not have this property then 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 a usage's security depends upon all other usages deriving keys from
the same EMSK, which is undesirable. In order to prevent security the same EMSK, which is undesirable. In order to prevent security
problems in one usage from interfering with another usage, the problems in one usage from interfering with another usage, the
following cryptographic separation is required: following cryptographic separation is required:
o It MUST be computationally infeasible to compute the EMSK from any o It MUST be computationally infeasible to compute the EMSK from any
root key derived from it. root key derived from it.
o Any root key MUST be cryptographically separate from any other o Any root key MUST be cryptographically separate from any other
root key derived from the same EMSK or DSRK root key derived from the same EMSK or DSRK.
o Derivation of USRKs MUST be coordinated so that two separate o Derivation of USRKs MUST be coordinated so that two separate
cryptographic usages do not derive the same key. cryptographic usages do not derive the same key.
o Derivation of DSRKs MUST be coordinated so that two separate key o Derivation of DSRKs MUST be coordinated so that two separate key
management domains do not derive the same key. management domains do not derive the same key.
o Derivation of DSRKs and USRKs MUST be specified such that no 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 domain can obtain a USRK by providing a domain name identical to a
Usage Key Label. Usage Key Label.
This document provides guidelines for a key derivation mechanism, This document provides guidelines for a key derivation mechanism that
which can be used with existing and new EAP methods to provide can be used with existing and new EAP methods to provide
cryptographic separation between usages of EMSK. This allows for the cryptographic separation between usages of EMSK. This allows for the
development of new usages without cumbersome coordination between development of new usages without cumbersome coordination between
different usage definitions. different usage definitions.
3. EMSK Key Root Derivation Framework 3. EMSK Key Root Derivation Framework
The EMSK key derivation framework provides a coordinated means for The EMSK key derivation framework provides a coordinated means for
generating multiple root keys from an EMSK. Further keys may then be generating multiple root keys from an EMSK. Further keys may then be
derived from the root key for various purposes, including encryption, derived from the root key for various purposes, including encryption,
integrity protection, entity authentication by way of proof of integrity protection, entity authentication by way of proof of
possession, and subsequent key derivation. A root key is derived possession, and subsequent key derivation. A root key is derived
from the EMSK for specific set of uses set forth in a usage from the EMSK for a specific set of uses set forth in a usage
definition described in Section 5. definition described in Section 5.
The basic EMSK root key hierarchy looks as follows: The basic EMSK root key hierarchy looks as follows:
EMSK EMSK
/ \ / \
USRK1 USRK2 USRK1 USRK2
This document defines how to derive usage specific root keys (USRK) This document defines how to derive Usage-Specific Root Keys (USRKs)
from the EMSK and also defines a specific USRK called a domain from the EMSK and also defines a specific USRK called a Domain-
specific root key (DSRK). DSRK are root keys restricted to use in a Specific Root Key (DSRK). DSRKs are root keys restricted to use in a
particular key management domain. From the DSRK, usage specific root particular key management domain. From the DSRK, Usage-Specific Root
keys for a particular application may be derived (DSUSRK). The Keys for a particular application may be derived (DSUSRKs). The
DSUSRKs are equivalent to USRKs that are restricted to use in a DSUSRKs are equivalent to USRKs that are restricted to use in a
particular domain. The details of lower levels of key hierarchy are particular domain. The details of lower levels of key hierarchy are
outside scope of this document. The key hierarchy looks as follows: outside scope of this document. The key hierarchy looks as follows:
EMSK EMSK
/ \ / \
USRK DSRK USRK DSRK
/ \ / \
DSUSRK1 DSUSRK2 DSUSRK1 DSUSRK2
3.1. USRK Derivation 3.1. USRK Derivation
The EMSK Root Key derivation function (KDF) derives a USRK from the The EMSK Root Key Derivation Function (KDF) derives a USRK from the
EMSK, a key label, optional data, and output length. The KDF is 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 expected to give the same output for the same input. The basic key
derivation function is given below. derivation function is given below.
USRK = KDF(EMSK, key label | "\0" | optional data | length) USRK = KDF(EMSK, key label | "\0" | optional data | length)
Where: where:
| denotes concatenation | denotes concatenation
"\0" is a NULL octet (0x00 in hex) "\0" is a NULL octet (0x00 in hex)
length is a 2 octet unsigned integer in network byte order length is a 2-octet unsigned integer in network byte order
The key labels are printable ASCII strings unique for each usage The key labels are printable ASCII strings unique for each usage
definition and are a maximum of 255 octets. In general they are of definition and are a maximum of 255 octets. In general, they are of
the form label-string@specorg where specorg is the organization that the form label-string@specorg, where specorg is the organization that
controls the specification of the usage definition of the Root Key. controls the specification of the usage definition of the Root Key.
The key label is intended to provide global uniqueness. Rules for The key label is intended to provide global uniqueness. Rules for
the allocation of these labels are given in Section 8. the allocation of these labels are given in Section 8.
The NULL octet after the key label is used to avoid collisions if one 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 key label is a prefix of another label (e.g., "foobar" and
"foobarExtendedV2"). This is considered a simpler solution than "foobarExtendedV2"). This is considered a simpler solution than
requiring a key label assignment policy that prevents prefixes from requiring a key label assignment policy that prevents prefixes from
occurring. occurring.
For the optional data the KDF MUST be capable of processing at least For the optional data, the KDF MUST be capable of processing at least
2048 opaque octets. The optional data must be constant during the 2048 opaque octets. The optional data must be constant during the
execution of the KDF. Usage definitions MAY use the EAP session-ID execution of the KDF. Usage definitions MAY use the EAP Session-ID
[I-D.ietf-eap-keying] in the specification of the optional data [RFC5247] in the specification of the optional data parameter that
parameter that go into the KDF function. This provides the advantage goes into the KDF function. In this case, the advantage is that data
of providing data into the key derivation that is unique to the provided into the key derivation is unique to the session that
session that generated the keys. generated the keys.
The KDF must be able to process input keys of up to 256 bytes. It 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 may do this by providing a mechanism for "hashing" long keys down to
a suitable size that can be consumed by the underlying derivation a suitable size that can be consumed by the underlying derivation
algorithm. algorithm.
The length is a 2-octet unsigned integer in network byte order of the 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 output key length in octets. An implementation of the KDF MUST be
capable of producing at least 2048 octets of output, however it is capable of producing at least 2048 octets of output; however, it is
RECOMMENDED that Root Keys be at least 64 octets long. RECOMMENDED that Root Keys be at least 64 octets long.
A usage definition requiring derivation of a Root Key must specify A usage definition requiring derivation of a Root Key must specify
all the inputs (other than EMSK) to the key derivation function. all the inputs (other than EMSK) to the key derivation function.
USRKs MUST be at least 64 octets in length. USRKs MUST be at least 64 octets in length.
3.1.1. On the KDFs 3.1.1. On the KDFs
This specification allows for the use of different KDFs. However, in This specification allows for the use of different KDFs. However, in
order to have a coordinated key derivation function the same KDF order to have a coordinated key derivation function, the same KDF
function MUST be used for all key derivations for a given EMSK. If 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 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 MUST be used. A system may provide the capability to negotiate
additional KDFs. KDFs are assigned numbers through IANA following additional KDFs. KDFs are assigned numbers through IANA following
the policy set in section Section 8. The rules for negotiating a KDF the policy set in Section 8. The rules for negotiating a KDF are as
are as follows: follows:
o If no other KDF is specified the KDF specified in this document o If no other KDF is specified, the KDF specified in this document
MUST be used. This is the "default" KDF. MUST be used. This is the "default" KDF.
o The initial authenticated key exchange MAY specify a favored 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 For example, an EAP method may define a preferred KDF to use in
specification. If the initial authenticated key exchange its specification. If the initial authenticated key exchange
specifies a KDF then this MUST override the default KDF. specifies a KDF, then this MUST override the default KDF.
Note that usage definitions MUST NOT concern themselves with the Note that usage definitions MUST NOT concern themselves with the
details of the KDF construction or the KDF selection, they only need details of the KDF construction or the KDF selection, they only need
to worry about the inputs specified in Section 3. to worry about the inputs specified in Section 3.
3.1.2. Default KDF 3.1.2. Default KDF
The default KDF for deriving root keys from an EMSK is taken from the 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 PRF+ key expansion specified in [RFC4306] based on HMAC-SHA-256
[SHA256]. The PRF+ construction was chosen because of its simplicity [SHA256]. The PRF+ construction was chosen because of its simplicity
and efficiency over other mechanisms such as those used in [RFC4346]. and efficiency over other mechanisms such as those used in [RFC4346].
The motivation for the design of PRF+ is described in [SIGMA]. The The motivation for the design of PRF+ is described in [SIGMA]. The
definition of PRF+ from [RFC4306]is given below: definition of PRF+ from [RFC4306]is given below:
PRF+ (K,S) = T1 | T2 | T3 | T4 | ... PRF+ (K,S) = T1 | T2 | T3 | T4 | ...
Where: where:
T1 = PRF (K, S | 0x01) T1 = PRF (K, S | 0x01)
T2 = PRF (K, T1 | S | 0x02) T2 = PRF (K, T1 | S | 0x02)
T3 = PRF (K, T2 | S | 0x03) T3 = PRF (K, T2 | S | 0x03)
T4 = PRF (K, T3 | S | 0x04) T4 = PRF (K, T3 | S | 0x04)
continuing as needed to compute the required length of key material. continuing as needed to compute the required length of key material.
The key, K, is the EMSK and S is the concatenation of key label, the The key, K, is the EMSK and S is the concatenation of the key label,
NULL octet, optional data and length defined in Section 3.1. For the NULL octet, optional data, and length defined in Section 3.1.
this specification the PRF is taken as HMAC-SHA-256 [SHA256]. Since For this specification, the PRF is taken as HMAC-SHA-256 [SHA256].
PRF+ is only defined for 255 iterations it may produce up to 8160 Since PRF+ is only defined for 255 iterations, it may produce up to
octets of key material. 8160 octets of key material.
3.2. EMSK and USRK Name Derivation 3.2. EMSK and USRK Name Derivation
The EAP keying framework [I-D.ietf-eap-keying] specifies that the The EAP keying framework [RFC5247] specifies that the EMSK MUST be
EMSK MUST be named using the EAP Session-Id and a binary or textual named using the EAP Session-ID and a binary or textual indication.
indication. Following that requirement, the EMSK name SHALL be Following that requirement, the EMSK name SHALL be derived as
derived as follows: follows:
EMSKname = KDF ( EAP Session-ID, "EMSK" | "\0" | length ) EMSKname = KDF ( EAP Session-ID, "EMSK" | "\0" | length )
Where: where:
| denotes concatenation | denotes concatenation
"EMSK" consists of the 4 ASCII values for the letters "EMSK" consists of the 4 ASCII values for the letters
"\0" = is a NULL octet (0x00 in hex) "\0" = is a NULL octet (0x00 in hex)
length is the 2 octet unsigned integer 8 in network byte order 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 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 by the EMSKname and the context of the descendant key usage. This is
the default behavior. Any exceptions SHALL be signaled by individual the default behavior. Any exceptions SHALL be signaled by individual
usages. usages.
USRKs MAY be named explicitly with a name derivation specified as USRKs MAY be named explicitly with a name derivation specified as
follows: follows:
USRKName = USRKName =
KDF(EAP Session-ID, key label|"\0"|optional data|length) KDF(EAP Session-ID, key label|"\0"|optional data|length)
Where: where:
key label and optional data MUST be the same as those used key label and optional data MUST be the same as those used
in the corresponding USRK derivation in the corresponding USRK derivation
length is the 2 octet unsigned integer 8 in network byte order length is the 2-octet unsigned integer 8 in network byte order
USRKName derivation and usage are applicable when there is ambiguity
USRKName derivation and usage is applicable when there is ambiguity in referencing the keys using the EMSKname and the associated context
in the referencing the keys using the EMSKname and the associated of the USRK usage. The usage SHALL signal such an exception in key
context of the USRK usage. The usage SHALL signal such an exception naming, so both parties know the key name used.
in key naming, so both parties know the key name used.
4. Domain Specific Root Key Derivation 4. Domain-Specific Root Key Derivation
A specific USRK called a Domain Specific Root Key (DSRK) is derived 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 from the EMSK for a specific set of usages in a particular key
management domain. Usages derive specific keys for specific services management domain. Usages derive specific keys for specific services
from this DSRK. The DSRK may be distributed to a key management from this DSRK. The DSRK may be distributed to a key management
domain for a specific set of usages so keys can be derived within the domain for a specific set of usages so that keys can be derived
key management domain for those usages. DSRK based usages will within the key management domain for those usages. DSRK-based usages
follow a key hierarchy similar to the following: will follow a key hierarchy similar to the following:
EMSK EMSK
/ \ / \
/ \ / \
/ \ / \
/ \ / \
DSRK1 DSRK2 DSRK1 DSRK2
/ \ / \ / \ / \
/ \ / \ / \ / \
DSUSRK11 DSUSRK12 DSUSRK21 DSUSRK22 DSUSRK11 DSUSRK12 DSUSRK21 DSUSRK22
The DSRK is a USRK with a key label of "dsrk@ietf.org" and the 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 optional data containing a domain label. The optional data MUST
contain an ASCII string representing the key management domain that contain an ASCII string representing the key management domain for
the root key is being derived for. The DSRK MUST be at least 64 which the root key is being derived. The DSRK MUST be at least 64
octets long. octets long.
Domain Specific Usage Specific Root Keys (DSUSRK) are derived from Domain-Specific Usage-Specific Root Keys (DSUSRKs) are derived from
the DSRK. The KDF is expected to give the same output for the same the DSRK. The KDF is expected to give the same output for the same
input. The basic key derivation function is given below. input. The basic key derivation function is given below.
DSUSRK = KDF(DSRK, key label | "\0" | optional data | length) DSUSRK = KDF(DSRK, key label | "\0" | optional data | length)
The key labels are printable ASCII strings unique for each usage The key labels are printable ASCII strings unique for each usage
definition within a DSRK usage and are a maximum of 255 octets. In 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 general, they are of the form label-string@specorg where specorg is
the organization that controls the specification of the usage the organization that controls the specification of the usage
definition of the DSRK. The key label is intended to provide global definition of the DSRK. The key label is intended to provide global
uniqueness. Rules for the allocation of these labels are given in uniqueness. Rules for the allocation of these labels are given in
Section 8. For the optional data the KDF MUST be capable of Section 8. For the optional data, the KDF MUST be capable of
processing at least 2048 opaque octets. The optional data must be processing at least 2048 opaque octets. The optional data must be
constant during the execution of the KDF. The length is a 2-octet 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 unsigned integer in network byte order of the output key length in
octets. An implementation of the KDF MUST be capable of producing at octets. An implementation of the KDF MUST be capable of producing at
least 2048 octets of output, however it is RECOMMENDED that DSUSRKs least 2048 octets of output; however, it is RECOMMENDED that DSUSRKs
be at least 64 octets long. be at least 64 octets long.
Usages that make use of the DSRK must define how the peer learns the 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 domain label to use in a particular derivation. A multi-domain usage
must define how both DSRKs and specific DSUSRKs are transported to must define how both DSRKs and specific DSUSRKs are transported to
different key management domains. Note that usages may define different key management domains. Note that usages may define
alternate ways to constrain specific keys to particular key alternate ways to constrain specific keys to particular key
management domains. management domains.
To facilitate the use of EMSKname to refer to keys derived from To facilitate the use of EMSKname to refer to keys derived from
DSRKs, EMSKname SHOULD be sent along with the DSRK. The exception is 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 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. an exception in key naming, so both parties know the key name used.
DSUSRKs MAY be named explicitly with a name derivation specified as DSUSRKs MAY be named explicitly with a name derivation specified as
follows: follows:
DSUSRKName = DSUSRKName =
KDF(EMSKName,key label | "\0" | optional data | length) KDF(EMSKName,key label | "\0" | optional data | length)
where length is the 2 octet unsigned integer 8 in network byte order. where length is the 2-octet unsigned integer 8 in network byte order.
4.1. Applicability of Multi-Domain usages 4.1. Applicability of Multi-Domain Usages
When a DSRK is distributed to a domain the domain can generate any The DSUSRKs generated by a domain can be used to authorize entities
DSUSRKs it wishes. This keys can be used to authorize entities in a in a domain to perform specific functions. In cases where it is
domain to perform specific functions. In cases where it is
appropriate for only a specific domain to be authorized to perform a appropriate for only a specific domain to be authorized to perform a
function the usage SHOULD NOT be defined as multi-domain. function, the usage SHOULD NOT be defined as multi-domain.
In some cases only certain domains are authorized for a particular In some cases, only certain domains are authorized for a particular
Multi-Domain usage. In this case domains that do not have full multi-domain usage. In this case, domains that do not have full
authorization should not receive the DSRK and should only receive authorization should not receive the DSRK and should only receive
DSUSRKs for the usages which they are authorized. If it is possible DSUSRKs for the usages for which they are authorized. If it is
for a peer to know which domains are authorized for a particular possible for a peer to know which domains are authorized for a
usage without relying on restricting access to the DSRK to specific particular usage without relying on restricting access to the DSRK to
domains then this recommendation may be relaxed. specific domains, then this recommendation may be relaxed.
5. Requirements for Usage Definitions 5. Requirements for Usage Definitions
In order for a usage definition to meet the guidelines for USRK usage In order for a usage definition to meet the guidelines for USRK
it must meet the following recommendations: usage, it must meet the following recommendations:
o The usage must define if it is a domain-enabled usage.
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 o The usage definition MUST NOT use the EMSK in any other way except
to derive Root Keys using the key derivation specified in to derive Root Keys using the key derivation specified in
Section 3 of this document. They MUST NOT use the EMSK directly. Section 3 of this document. They MUST NOT use the EMSK directly.
o The usage definition SHOULD NOT require caching of the EMSK. It o The usage definition SHOULD NOT require caching of the EMSK. It
is RECOMMENDED that the Root Key derived specifically for the is RECOMMENDED that the Root Key derived specifically for the
usage definition rather than the EMSK should be used to derive usage definition (rather than the EMSK) should be used to derive
child keys for specific cryptographic operations. 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 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 definitions are encouraged to use the key name described in
Section 3.2 and include additional data in the optional data to Section 3.2 and include additional data in the optional data to
provide additional entropy. provide additional entropy.
o Usage definitions MUST define the length of their Root Keys. It 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 is RECOMMENDED that the Root Keys be at least as long as the EMSK
(at least 64 octets). (at least 64 octets).
o Usage definitions MUST define how they use their Root Keys. This o Usage definitions MUST define how they use their Root Keys. This
includes aspects of key management covered in the next section on includes aspects of key management covered in the next section on
Root Key Management guidelines. Root Key management guidelines.
o
5.1. Root Key Management Guidelines 5.1. Root Key Management Guidelines
This section makes recommendations for various aspects of key This section makes recommendations for various aspects of key
management of the Root Key including lifetime, child key derivation, management of the Root Key including lifetime, child key derivation,
caching and transport. caching, and transport.
It is RECOMMENDED that the Root Key is only used for deriving child 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 keys. A usage definition must specify how and when the derivation of
child keys should be done. It is RECOMMENDED that usages following child keys should be done. It is RECOMMENDED that usages following
similar considerations for key derivation are as outlined in this similar considerations for key derivation are as outlined in this
document for the Root Key derivation with respect to cryptographic document for the Root Key derivation with respect to cryptographic
separation and key reuse. In addition, usages should take into separation and key reuse. In addition, usages should take into
consideration the number of keys that will be derived from the Root consideration the number of keys that will be derived from the Root
Key and ensure that enough entropy is introduced in the derivation to Key and ensure that enough entropy is introduced in the derivation to
support this usage. It is desirable that the entropy is provided by support this usage. It is desirable that the entropy is provided by
the two parties that derive the child key. the two parties that derive the child key.
Root Keys' lifetimes should not be more than that of the EMSK. Thus, 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 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 removed from use. If a new EMSK is derived from a subsequent EAP
transaction then a usage implementation should begin to use the new transaction, then a usage implementation should begin to use the new
Root Keys derived from the new EMSK as soon as possible. Whether or 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 not child keys associated with a Root Key are replaced depends on the
requirements of the usage definition. It is conceivable that some requirements of the usage definition. It is conceivable that some
usage definition forces the child key to be replaced and others allow 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 child keys to be used based on the policy of the entities that use
the child key. the child key.
Recall that the EMSK never leaves the EAP peer and server. That also 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 holds true for some Root Keys; however, some Root Keys may be
provided to other entities for child key derivation and delivery. provided to other entities for child key derivation and delivery.
Each usage definition specification will specify delivery caching Each usage definition specification will specify delivery caching
and/or delivery procedures. Note that the purpose of the key and/or delivery procedures. Note that the purpose of the key
derivation in Section 3 is to ensure that Root Keys are derivation in Section 3 is to ensure that Root Keys are
cryptographically separate from each other and the EMSK. In other cryptographically separate from each other and the EMSK. In other
words, given a Root Key, it is computationally infeasible to derive words, given a Root Key, it is computationally infeasible to derive
the EMSK, any other Root Keys, or child keys associated with other the EMSK, any other Root Keys, or child keys associated with other
Root Keys. In addition to the Root Key, several other parameters may Root Keys. In addition to the Root Key, several other parameters may
need to be sent. need to be sent.
Root Key names may be derived using the EAP Session ID, and thus the 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 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 delivered to another entity, the EMSKname and the lifetime associated
with the specific root keys MUST also be transported to that entity. with the specific root keys MUST also be transported to that entity.
Recommendations for transporting keys are discussed in the security Recommendations for transporting keys are discussed in the Security
considerations (Section 7.4). Considerations (Section 7.4).
Usage definition may also define how keys are bound to particular Usage definitions may also define how keys are bound to particular
entities. This can be done through the inclusion of usage parameters entities. This can be done through the inclusion of usage parameters
and identities in the child key derivation. Some of this data is and identities in the child key derivation. Some of this data is
described as "channel bindings" in [RFC3748]. described as "channel bindings" in [RFC3748].
6. Requirements for EAP System 6. Requirements for EAP System
The system that wishes to make use of EAP root keys derived from the 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 EMSK must take certain things into consideration. The following is a
list of these considerations: list of these considerations:
skipping to change at page 14, line 21 skipping to change at page 14, line 48
described as "channel bindings" in [RFC3748]. described as "channel bindings" in [RFC3748].
6. Requirements for EAP System 6. Requirements for EAP System
The system that wishes to make use of EAP root keys derived from the 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 EMSK must take certain things into consideration. The following is a
list of these considerations: list of these considerations:
o The EMSK MUST NOT be used for any other purpose than the key o The EMSK MUST NOT be used for any other purpose than the key
derivation described in this document. derivation described in this document.
o The EMSK MUST be secret and not known to someone observing the o The EMSK MUST be secret and not known to someone observing the
authentication mechanism protocol exchange. authentication mechanism protocol exchange.
o The EMSK MUST be maintained within a protected location inside the o The EMSK MUST be maintained within a protected location inside the
entity where it is generated. Only root keys derived according to entity where it is generated. Only root keys derived according to
this specification may be exported from this boundary. this specification may be exported from this boundary.
o The EMSK MUST be unique for each EAP session o The EMSK MUST be unique for each EAP session
o The EAP method MUST provide an identifier for the EAP transaction o The EAP method MUST provide an identifier for the EAP transaction
that generated the key that generated the key.
o The system MUST define which usage definitions are used and how o The system MUST define which usage definitions are used and how
they are invoked. they are invoked.
o The system may define ways to select an alternate PRF for key o The system may define ways to select an alternate PRF for key
derivation as defined in Section 3.1. derivation as defined in Section 3.1.
The system MAY use the MSK transmitted to the NAS in any way it The system MAY use the MSK transmitted to the Network Access Server
chooses in accordance with [RFC3748] [I-D.ietf-eap-keying] and other (NAS) in any way it chooses in accordance with [RFC3748], [RFC5247],
relevant specifications. This is required for backward and other relevant specifications. This is required for backward
compatibility. New usage definitions following this specification compatibility. New usage definitions following this specification
MUST NOT use the MSK. If more than one usage uses the MSK, then the MUST NOT use the MSK. If more than one usage uses the MSK, then the
cryptographic separation is not achieved. Implementations MUST cryptographic separation is not achieved. Implementations MUST
prevent such combinations. prevent such combinations.
7. Security Considerations 7. Security Considerations
7.1. Key strength 7.1. Key Strength
The effective key strength of the derived keys will never be greater 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 than the strength of the EMSK (or a master key internal to an EAP
mechanism). mechanism).
7.2. Cryptographic separation of keys 7.2. Cryptographic Separation of Keys
The intent of the KDF is to derive keys that are cryptographically The intent of the KDF is to derive keys that are cryptographically
separate: the compromise of one of the usage specific root keys separate: the compromise of one of the Usage-Specific Root Keys
(USRKs) should not compromise the security of other USRKs or the (USRKs) should not compromise the security of other USRKs or the
EMSK. It is believed that the KDF chosen provides the desired EMSK. It is believed that the KDF chosen provides the desired
separation. separation.
7.3. Implementation 7.3. Implementation
An implementation of an EAP framework should keep the EMSK internally An implementation of an EAP framework should keep the EMSK internally
as close to where it is derived as possible and only provide an as close to where it is derived as possible and only provide an
interface for obtaining Root Keys. It may also choose to restrict interface for obtaining Root Keys. It may also choose to restrict
which callers have access to which keys. A usage definition MUST NOT which callers have access to which keys. A usage definition MUST NOT
assume that any entity outside the EAP server or EAP peer EAP assume that any entity outside the EAP server or EAP peer has access
framework has access to the EMSK. In particular it MUST NOT assume to the EMSK. In particular, it MUST NOT assume that a lower layer
that a lower layer has access to the EMSK. has access to the EMSK.
7.4. Key Distribution 7.4. Key Distribution
In some cases it will be necessary or convenient to distribute USRKs In some cases, it will be necessary or convenient to distribute USRKs
from where they are generated. Since these are secret keys they MUST from where they are generated. Since these are secret keys, they
be transported with their integrity and confidentiality maintained. MUST be transported with their integrity and confidentiality
They MUST be transmitted between authenticated and authorized maintained. They MUST be transmitted between authenticated and
parties. It is also important that the context of the key usage be authorized parties. It is also important that the context of the key
transmitted along with the key. This includes information to usage be transmitted along with the key. This includes information
identify the key and constraints on its usage such as lifetime. to identify the key and constraints on its usage such as lifetime.
This document does not define a mechanism for key transport. It is 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 up to usage definitions and the systems that use them to define how
keys are distributed. Usage definition designers may enforce keys are distributed. Usage definition designers may enforce
constraints on key usage by various parties by deriving a key constraints on key usage by various parties by deriving a key
hierarchy and by providing entities only with the keys in the hierarchy and by providing entities only with the keys in the
hierarchy that they need. hierarchy that they need.
7.5. Key Lifetime 7.5. Key Lifetime
The key lifetime is dependent upon how the key is generated and how 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 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 usage definition, it must determine how long the key is valid for.
key lifetime or key strength information is available from the If key lifetime or key strength information is available from the
authenticated key exchange then this information SHOULD be used in authenticated key exchange, then this information SHOULD be used in
determining the lifetime of the key. If possible it is recommended determining the lifetime of the key. If possible, it is recommended
that key lifetimes be coordinated throughout the system. Setting a that key lifetimes be coordinated throughout the system. Setting a
key lifetime shorter that a system lifetime may result is keys key lifetime shorter that a system lifetime may result in keys
becoming invalid with no convenient way to refresh them. Setting a becoming invalid with no convenient way to refresh them. Setting a
key lifetime to longer may result in decreased security since the key key lifetime to longer may result in decreased security since the key
may be used beyond its recommended lifetime. may be used beyond its recommended lifetime.
7.6. Entropy consideration 7.6. Entropy Consideration
The number of root keys derived from the EMSK is expected to be low. 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 Note that there is no randomness required to be introduced into the
EMSK to root key derivation beyond the root key labels. Thus, if EMSK-to-Root-Key derivation beyond the root key labels. Thus, if
many keys are going to be derived from an Root Key it is important 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 that Root-Key-to-child-key derivation introduce fresh random numbers
in deriving each key. in deriving each key.
8. IANA Considerations 8. IANA Considerations
The keywords "Private Use", "Specification Required" and "IETF The keywords "Private Use", "Specification Required", and "IETF
Consensus" that appear in this document when used to describe Consensus" that appear in this document when used to describe
namespace allocation are to be interpreted as described in [RFC5226]. namespace allocation are to be interpreted as described in [RFC5226].
8.1. Key Labels 8.1. Key Labels
This specification introduces a new name space for "USRK 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 Key labels MUST be printable US-ASCII strings, and MUST NOT contain
the characters at-sign ("@") except as noted below, comma (","), the characters at-sign ("@") except as noted below, comma (","),
whitespace, control characters (ASCII codes 32 or less), or the ASCII whitespace, control characters (ASCII codes 32 or less), or the ASCII
code 127 (DEL). Labels are case-sensitive, and MUST NOT be longer code 127 (DEL). Labels are case-sensitive and MUST NOT be longer
than 64 characters. than 64 characters.
Labels can be assigned based on Specification Required policy Labels can be assigned based on Specification Required policy
[RFC5226]. In addition, the labels "experimental1" and [RFC5226]. In addition, the labels "experimental1" and
"experimental2" are reserved for experimental use. The following "experimental2" are reserved for experimental use. The following
considerations apply to their use: considerations apply to their use:
Production networks do not necessarily support the use of Production networks do not necessarily support the use of
experimental code points. The network scope of support for experimental code points. The network scope of support for
experimental values should carefully be evaluated before deploying experimental values should carefully be evaluated before deploying
skipping to change at page 17, line 6 skipping to change at page 17, line 38
consistently to avoid interference between experiments. Particular consistently to avoid interference between experiments. Particular
attention should be given to security vulnerabilities and the freedom attention should be given to security vulnerabilities and the freedom
of different domains to employ their own experiments. Cross-domain of different domains to employ their own experiments. Cross-domain
usage is NOT RECOMMENDED. usage is NOT RECOMMENDED.
Similarly, labels "private1" and "private2" have been reserved for Similarly, labels "private1" and "private2" have been reserved for
Private Use within an organization. Again, cross-domain usage of Private Use within an organization. Again, cross-domain usage of
these labels is NOT RECOMMENDED. these labels is NOT RECOMMENDED.
Labels starting with a string and followed by the "@" and a valid, Labels starting with a string and followed by the "@" and a valid,
fully qualified Internet domain name [RFC1034] can be requested by by fully qualified Internet domain name [RFC1034] can be requested by
the person or organization who are in control of the domain name. the person or organization that is in control of the domain name.
Such labels can be allocated based on Expert Review with Such labels can be allocated based on Expert Review with
Specification Required. Besides the review needed for Specification Specification Required. Besides the review needed for Specification
Required (see Section 4.1 of [RFC5226]), the expert needs to review Required (see Section 4.1 of [RFC5226]), the expert needs to review
the proposed usage for conformance to this specification, including the proposed usage for conformance to this specification, including
the suitability of the usage according to the applicability statement the suitability of the usage according to the applicability statement
outlined in Section 1.1. It is RECOMMENDED that the specification outlined in Section 1.1. It is RECOMMENDED that the specification
contain the following information: contain the following information:
o A description of the usage o A description of the usage
o The key label to be used o The key label to be used
o Length of the Root Key o Length of the Root Key
o If optional data is used, what it is and how it is maintained 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 o How child keys will be derived from the Root Key and how they will
be used be used
o How lifetime of the Root Key and its child keys will be managed 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 o Where the Root Keys or child keys will be used and how they are
communicated if necessary communicated if necessary
The following labels are reserved by this document: "EMSK", The following labels are reserved by this document: "EMSK",
"dsrk@ietf.org". "dsrk@ietf.org".
8.2. PRF numbers 8.2. PRF Numbers
This specification introduces a new number space for "EMSK PRF This specification introduces a new number space for "EMSK PRF
numbers". The numbers are int he range 0 to 255 Numbers from 0 to 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 220 are assigned through the policy IETF Consensus, and numbers in
range 221 to 255 are left for Private Use. The initial registry the range 221 to 255 are left for Private Use. The initial registry
should contain the following values: contains the following values:
0 RESERVED 0 RESERVED
1 HMAC-SHA-256 PRF+ (Default) 1 HMAC-SHA-256 PRF+ (Default)
9. Acknowledgements 9. Acknowledgements
This document expands upon previous collaboration with Pasi Eronen. This document expands upon previous collaboration with Pasi Eronen.
This document reflects conversations with Bernard Aboba, Jari Arkko, This document reflects conversations with Bernard Aboba, Jari Arkko,
Avi Lior, David McGrew, Henry Haverinen, Hao Zhou, Russ Housley, Glen Avi Lior, David McGrew, Henry Haverinen, Hao Zhou, Russ Housley, Glen
Zorn, Charles Clancy, Dan Harkins, Alan DeKok, Yoshi Ohba and members Zorn, Charles Clancy, Dan Harkins, Alan DeKok, Yoshi Ohba, and
of the EAP and HOKEY working groups. members of the EAP and HOKEY working groups.
Thanks to Dan Harkins for the idea of using a single root key name to Thanks to Dan Harkins for the idea of using a single root key name to
refer to all keys. refer to all keys.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-eap-keying]
Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
draft-ietf-eap-keying-22 (work in progress),
November 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[SHA256] National Institute of Standards and Technology, "Secure [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Hash Standard", FIPS 180-2, August 2002. Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008.
With Change Notice 1 dated February 2004 [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 10.2. Informative References
[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", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to [SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and its Use in the IKE Authenticated Diffie-Hellman and its Use in the IKE
Protocols", LNCS 2729, Springer, 2003. Protocols", LNCS 2729, Springer, 2003,
<http://www.informatik.uni-trier.de/~ley/db/conf/
Available at http://www.informatik.uni-trier.de/~ley/db/ crypto/crypto2003.html>.
conf/crypto/crypto2003.html
Authors' Addresses Authors' Addresses
Joseph Salowey Joseph Salowey
Cisco Systems Cisco Systems
Email: jsalowey@cisco.com EMail: jsalowey@cisco.com
Lakshminath Dondeti Lakshminath Dondeti
Qualcomm, Inc Qualcomm, Inc
Email: ldondeti@qualcomm.com EMail: ldondeti@qualcomm.com
Vidya Narayanan Vidya Narayanan
Qualcomm, Inc Qualcomm, Inc
Email: vidyan@qualcomm.com EMail: vidyan@qualcomm.com
Madjid Nakhjiri Madjid Nakhjiri
Motorola Motorola
Email: madjid.nakhjiri@motorola.com EMail: madjid.nakhjiri@motorola.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 126 change blocks. 
251 lines changed or deleted 243 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/