draft-ietf-hokey-emsk-hierarchy-03.txt   draft-ietf-hokey-emsk-hierarchy-04.txt 
Network Working Group J. Salowey Network Working Group J. Salowey
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track L. Dondeti Intended status: Standards Track L. Dondeti
Expires: July 12, 2008 V. Narayanan Expires: August 27, 2008 V. Narayanan
Qualcomm, Inc Qualcomm, Inc
M. Nakhjiri M. Nakhjiri
Motorola Motorola
January 9, 2008 February 24, 2008
Specification for the Derivation of Root Keys from an Extended Master Specification for the Derivation of Root Keys from an Extended Master
Session Key (EMSK) Session Key (EMSK)
draft-ietf-hokey-emsk-hierarchy-03.txt draft-ietf-hokey-emsk-hierarchy-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 12, 2008. This Internet-Draft will expire on August 27, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
An Extended Master Session Key (EMSK) is a cryptographic key An Extended Master Session Key (EMSK) is a cryptographic key
generated from an Extensible Authentication Protocol (EAP) exchange generated from an Extensible Authentication Protocol (EAP) exchange
reserved solely for the purpose of deriving master keys for one or reserved solely for the purpose of deriving master keys for one or
skipping to change at page 2, line 15 skipping to change at page 2, line 15
mechanism for avoiding conflicts between root keys by deriving mechanism for avoiding conflicts between root keys by deriving
cryptographically separate keys from the EMSK. This document also cryptographically separate keys from the EMSK. This document also
describes a usage for domain specific root keys made available to and describes a usage for domain specific 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Cryptographic Separation and Coordinated Key Derivation . . . 4 2. Cryptographic Separation and Coordinated Key Derivation . . . 4
3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 5 3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 6
3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 6 3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 6
3.2. The USRK Derivation Function . . . . . . . . . . . . . . . 7 3.1.1. On the KDFs . . . . . . . . . . . . . . . . . . . . . 7
3.3. Default PRF . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.2. Default KDF . . . . . . . . . . . . . . . . . . . . . 8
3.4. Key Naming and Usage Data . . . . . . . . . . . . . . . . 8 3.2. EMSK and USRK Name Derivation . . . . . . . . . . . . . . 9
4. Domain Specific Root Key Derivation . . . . . . . . . . . . . 9 4. Domain Specific Root Key Derivation . . . . . . . . . . . . . 9
5. Requirements for Usage Definitions . . . . . . . . . . . . . . 10 5. Requirements for Usage Definitions . . . . . . . . . . . . . . 11
5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 11 5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 11
6. Requirements for EAP System . . . . . . . . . . . . . . . . . 12 6. Requirements for EAP System . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Cryptographic separation of keys . . . . . . . . . . . . . 12 7.2. Cryptographic separation of keys . . . . . . . . . . . . . 13
7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 13 7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 13
7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 13 7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 14
7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 13 7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 14
7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 13 7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19
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 either for specific purposes called usages. This document are meant for specific purposes called usages; a special usage class
also provides guidelines for creating usage definitions for the is the domain specific root keys made available to and used within
various uses of EAP key material and for the management of the root specific key management domains. This document also provides
keys. In this document, the terms application and usage (or "usage guidelines for creating usage definitions for the various uses of EAP
definition") refer to a specific use case of the EAP keying material. key material and for the management of the root keys. In this
document, the terms application and usage (or "usage definition")
refer to a specific use case of the EAP keying material.
Different uses for keys derived from the EMSK have been proposed. 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) should be used or discuss what types of use Specific Root Keys (USRK) should be used or discuss what types of use
cases are valid. It does define a framework for the derivation of cases are valid. It does define a framework for the derivation of
USRKs for different purposes such that different usages can be USRKs for different purposes such that different usages can be
skipping to change at page 3, line 41 skipping to change at page 3, line 43
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. Terminology 1.1. 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
skipping to change at page 4, line 12 skipping to change at page 4, line 14
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 constrains 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
skipping to change at page 6, line 14 skipping to change at page 6, line 19
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 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
/ \ / \
USRK USRK USRK1 USRK2
This document defines how to derive usage specific root keys (USRK) This document defines how to derive usage specific root keys (USRK)
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). DSRK 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 (DSUSRK). 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:
skipping to change at page 6, line 38 skipping to change at page 7, line 5
/ \ / \
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, optional data, length) USRK = KDF(EMSK, key label | "\0" | optional data | length)
Where:
| denotes concatenation
"\0" is a NULL octet (0x00 in hex)
length is a 2 octet unsigned integer in network byte order
The key labels are printable ASCII strings unique for each usage The key labels are printable ASCII strings unique for each usage
definition and are a maximum of 255 bytes. 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. For the the allocation of these labels are given in Section 8.
optional data the KDF MUST be capable of processing at least 2048
opaque octets. The optional data must be constant during the
execution of the KDF. The length is a 2 byte unsigned integer in
network byte order of the output key length in octets. An
implementation of the KDF MUST be capable of producing at least 2048
octets of output, however it is RECOMMENDED that Root Keys be at
least 64 octets long.
A usage definition requiring derivation of a Root Key must specify The NULL octet after the key label is used to avoid collisions if one
all the inputs (other than EMSK) to the key derivation function. key label is a prefix of another label (e.g. "foobar" and
"foobarExtendedV2"). This is considered a simpler solution than
requiring a key label assignment policy that prevents prefixes from
occurring.
3.2. The USRK Derivation Function For the optional data the KDF MUST be capable of processing at least
2048 opaque octets. The optional data must be constant during the
execution of the KDF. Usage definitions MAY use the EAP session-ID
[I-D.ietf-eap-keying] 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.
The USRK key derivation function is based on a pseudo random function The KDF must be able to process input keys of up to 256 bytes. It
(PRF) that has the following function prototype: may do this by providing a mechanism for "hashing" long keys down to
a suitable size that can be consumed by the underlying derivation
algorithm.
KDF = PRF(key, data) The length is a 2-octet unsigned integer in network byte order of the
output key length in octets. An implementation of the KDF MUST be
capable of producing at least 2048 octets of output, however it is
RECOMMENDED that Root Keys be at least 64 octets long.
where: A usage definition requiring derivation of a Root Key must specify
all the inputs (other than EMSK) to the key derivation function.
key = EMSK USRKs MUST be at least 64 octets in length.
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 NULL byte (0x00 in hex)
+ denotes concatenation
The NULL byte after the key label is used to avoid collisions if one 3.1.1. On the KDFs
key label is a prefix of another label (e.g. "foobar" and
"foobarExtendedV2"). This is considered a simpler solution than
requiring a key label assignment policy that prevents prefixes from
occurring.
This specification allows for the use of different PRFs. However, in This specification allows for the use of different KDFs. However, in
order to have a coordinated key derivation function the same PRF 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 PRF is specified, then the default PRF specified in Section 3.3 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 PRFs. PRFs 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 PRF the policy set in section Section 8. The rules for negotiating a KDF
are as follows: are as follows:
o If no other PRF is specified the PRF specified in this document o If no other KDF is specified the KDF specified in this document
MUST be used. This is the "default" PRF. MUST be used. This is the "default" KDF.
o The initial authenticated key exchange MAY specify a favored PRF. o The initial authenticated key exchange MAY specify a favored KDF.
For example an EAP method may define a preferred PRF to use in its For example an EAP method may define a preferred KDF to use in its
specification. If the initial authenticated key exchange specification. If the initial authenticated key exchange
specifies a PRF then this MUST override the default PRF. specifies a KDF then this MUST override the default KDF.
o A system MAY specify a separate default KDF if all participants
o A system MAY specify a separate default PRF if all participants within the system have the knowledge of which KDF to use. If
within the system have the knowledge of which PRF to use. If specified this MUST take precedence over key exchange defined KDF.
specified this MUST take precedence over key exchange defined PRF.
Note that usage definitions MUST NOT concern themselves with the Note that usage definitions MUST NOT concern themselves with the
details of the PRF construction or the PRF 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.3. Default PRF 3.1.2. Default KDF
The default PRF 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 PRF from [RFC4306] based on HMAC-SHA-256 [SHA256]. PRF+ key expansion specified in [RFC4306] based on HMAC-SHA-256
The prf+ construction was chosen because of its simplicity and [SHA256]. The PRF+ construction was chosen because of its simplicity
efficiency over other PRFs such as those used in [RFC4346]. The and efficiency over other mechanisms such as those used in [RFC4346].
motivation for the design of this 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 data defined in Section 3.2. The key, K, is the EMSK and S is the concatenation of key label, the
For this specification the PRF is taken as HMAC-SHA-256 [SHA256]. NULL octet, optional data and length defined in Section 3.1. For
Since PRF+ is only defined for 255 iterations it may produce up to this specification the PRF is taken as HMAC-SHA-256 [SHA256]. Since
8160 bytes of key material. PRF+ is only defined for 255 iterations it may produce up to 8160
octets of key material.
3.4. Key Naming and Usage Data 3.2. EMSK and USRK Name Derivation
It is RECOMMENDED that the authenticated key exchange export a value, The EAP keying framework [I-D.ietf-eap-keying] specifies that the
an EAP Session-ID, that is known to both sides to provide a way to EMSK MUST be named using the EAP Session-Id and a binary or textual
identify the exchange and the keys derived by the exchange. The EAP indication. Following that requirement, the EMSK name SHALL be
keying framework [I-D.ietf-eap-keying] defines this value and derived as follows:
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 USRK has a name derived as follows: EMSKname = KDF ( EAP Session-ID, "EMSK" | "\0" | length )
USRK Name = SHA-256-64 ( EAP Session-ID | key-label ) Where:
where SHA-256-64 is the first 64 bits from the SHA-256 output | denotes concatenation
"EMSK" consists of the 4 ASCII values for the letters
"\0" = is a NULL octet (0x00 in hex)
length is the 2 octet unsigned integer 8 in network byte order
Usage definitions MAY use the EAP session-ID in the specification of It is RECOMMENDED that all keys derived from the EMSK are referred to
the optional data parameter that go into the KDF function. This by the EMSKname and the context of the descendant key usage. This is
provides the advantage of providing data into the key derivation that the default behavior. Any exceptions SHALL be signaled by individual
is unique to the session that generated the keys. usages.
USRKs MAY be named explicitly with a name derivation specified as
follows:
USRKName =
KDF(EAP Session-ID, key label|"\0"|optional data|length)
Where:
key label and optional data MUST be the same as those used
in the corresponding USRK derivation
length is the 2 octet unsigned integer 8 in network byte order
USRKName derivation and usage is applicable when there is ambiguity
in the referencing the keys using the EMSKname and the associated
context of the USRK usage. The usage SHALL signal such an exception
in key naming, so both parties know the key name used.
4. Domain Specific Root Key Derivation 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 keys can be derived within the
key management domain for those usages. DSRK based usages will key management domain for those usages. DSRK based usages will
follow a key hierarchy similar to the following: follow a key hierarchy similar to the following:
EMSK EMSK
/ \ / \
/ \ / \
/ \
/ \
DSRK1 DSRK2 DSRK1 DSRK2
/ \ / \ / \ / \
/ \ DSUSRK21 DSUSRK22 / \ / \
DSUSRK11 DSUSRK12 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 that
the root key is being derived for. The DSRK is MUST be 64 octets the root key is being derived for. The DSRK MUST be at least 64
long. octets long.
Domain Specific Usage Specific Root Keys (DSUSRK) are derived from Domain Specific Usage Specific Root Keys (DSUSRK) 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, 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 bytes. 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 byte 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.
It is RECOMMENDED that each DSUSRK has a name derived as follows:
DSUSRK Name = SHA-256-64( DSRK Name | key-label )
where SHA-256-64 is the first 64 bits from the SHA-256 output
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
DSRKs, EMSKname SHOULD be sent along with the DSRK. The exception is
when a DSRKname is expected to be used. The usage SHALL signal such
an exception in key naming, so both parties know the key name used.
DSUSRKs MAY be named explicitly with a name derivation specified as
follows:
DSUSRKName =
KDF(EMSKName,key label | "\0" | optional data | length)
where length is the 2 octet unsigned integer 8 in network byte order.
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 usage
it must meet the following recommendations: 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 o Usage definition MUST define distinct key labels and optional data
used in the key derivation described in Section 3. Usage 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.4 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 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 only used for deriving child It is RECOMMENDED that the Root Key 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
skipping to change at page 11, line 45 skipping to change at page 12, line 35
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. Root Key name should be derived using the EAP need to be sent.
Session ID, and thus the key name needs to be sent along with the
key. When Root Keys are delivered to another entity, the lifetime Root Key names may be derived using the EAP Session ID, and thus the
associated with the specific root keys MUST also be transported to key name may need to be sent along with the key. When Root Keys are
that entity. Recommendations for transporting keys are discussed in delivered to another entity, the EMSKname and the lifetime associated
the security considerations (Section 7.4). with the specific root keys MUST also be transported to that entity.
Recommendations for transporting keys are discussed in the security
considerations (Section 7.4).
Usage definition may also define how keys are bound to particular Usage definition 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
skipping to change at page 12, line 27 skipping to change at page 13, line 24
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.2. 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 NAS in any way it
chooses. This is required for backward compatibility. New usage chooses. This is required for backward compatibility. New usage
definitions following this specification MUST NOT use the MSK. If definitions following this specification MUST NOT use the MSK. If
more than one usage uses the MSK, then the cryptographic separation more than one usage uses the MSK, then the cryptographic separation
is not achieved. Implementations MUST prevent such combinations. is not achieved. Implementations MUST prevent such combinations.
7. Security Considerations 7. Security Considerations
7.1. Key strength 7.1. Key strength
skipping to change at page 15, line 5 skipping to change at page 15, line 48
nothing to do with STD 11 [RFC0822] or [RFC4282]. An example of a nothing to do with STD 11 [RFC0822] or [RFC4282]. An example of a
key label is "service@example.com" (without the double quotes). key label is "service@example.com" (without the double quotes).
Labels within the "ietf.org" organization are assigned based on the Labels within the "ietf.org" organization are assigned based on the
IETF CONSENSUS policy with specification recommended. Labels from IETF CONSENSUS policy with specification recommended. Labels from
other organizations may be registered with IANA by the person or other organizations may be registered with IANA by the person or
organization controlling the domain with an assignment policy of organization controlling the domain with an assignment policy of
SPECIFICATION REQUIRED. It is RECOMMENDED that the specification SPECIFICATION REQUIRED. It is RECOMMENDED that the specification
contain the following information: contain the following information:
The following labels are reserved by this document: "EMSK",
"dsrk@ietf.org".
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
skipping to change at page 15, line 30 skipping to change at page 16, line 30
range 221 to 255 are left for PRIVATE USE. The initial registry range 221 to 255 are left for PRIVATE USE. The initial registry
should contain the following values: should contain 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 and members of the Avi Lior, David McGrew, Henry Haverinen, Hao Zhou, Russ Housley, Glen
EAP working group. Zorn, Charles Clancy, Dan Harkins, Alan DeKok, Yoshi Ohba and members
of the EAP and HOKEY working groups.
Thanks to Dan Harkins for the idea of using a single root key name to
refer to all keys.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
 End of changes. 55 change blocks. 
131 lines changed or deleted 171 lines changed or added

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