draft-ietf-hokey-emsk-hierarchy-01.txt   draft-ietf-hokey-emsk-hierarchy-02.txt 
HOKEY 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: December 23, 2007 V. Narayanan Expires: May 21, 2008 V. Narayanan
Qualcomm, Inc Qualcomm, Inc
M. Nakhjiri M. Nakhjiri
Huawei USA Motorola
June 21, 2007 November 18, 2007
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-01.txt draft-ietf-hokey-emsk-hierarchy-02.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 December 23, 2007. This Internet-Draft will expire on May 21, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
more purposes identified as usage definitions. This memo specifies a more purposes identified as usage definitions. This memo specifies a
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 administrative 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 . . . . . . . . . . . . . . . 6 3.2. The USRK Derivation Function . . . . . . . . . . . . . . . 7
3.3. Default PRF . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Default PRF . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Key Naming and Usage Data . . . . . . . . . . . . . . . . 8 3.4. Key Naming and Usage Data . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Cryptographic separation of keys . . . . . . . . . . . . . 13 7.2. Cryptographic separation of keys . . . . . . . . . . . . . 12
7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 13 7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 13
7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 13 7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 13
7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 13 7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 13
7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 14 7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 14
8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 18
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
skipping to change at page 3, line 35 skipping to change at page 3, line 35
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
developed independently from one another. The goal is to have 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 an Specific Root Key (DSRK) for use in deriving keys specific to a key
administrative domain. Each DSRK is a root key used to derive USRKs management domain. Each DSRK is a root key used to derive Domain
which are specific to a particular administrative domain, called Specific Usage Specific Root Keys (DSUSRK). The DSUSRKs are USRKs
Domain Specific Usage Specific Root Keys (DSUSRK). 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
skipping to change at page 4, line 20 skipping to change at page 4, line 20
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 constrains 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
A key management domain is a collection of systems that share the
same access to key material. A single administrative domain may
contain several key management domains in order to contain the
scope of key material to a group of related systems. A entity
that is not a member of a key management domain must not make use
of key material for that domain. Only the domain where the key
material is originated may derive key material from the EMSK for
other domains. In the case where key material is distributed to
another domain, intermediate systems may have access to see the
key material during the key distribution process, but they must
not make use of the key material.
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 particular administrative domain. It is used to derive child a specific key management domain. It is used to derive child keys
keys for a particular usage definition. The child keys derived for a particular usage definition. The child keys derived from a
from a DSRK are referred to as domain specific usage specific root DSRK are referred to as domain specific usage specific root keys
keys (DSUSRK). DSUSRKs are similar to the USRK, except in the (DSUSRK). DSUSRKs are similar to the USRK, except in the fact
fact that their scope is restricted to the same domain as the that their scope is restricted to the same domain as the parent
parent DSRK from which it is derived. DSRK 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
skipping to change at page 5, line 24 skipping to change at page 5, line 37
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 o Derivation of DSRKs MUST be coordinated so that two separate key
administrative 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
domain can obtain a USRK by providing a domain name identical to a
Usage Key Label.
This document provides guidelines for a mechanism, which can be used This document provides guidelines for a key derivation mechanism,
with existing and new EAP methods to provide cryptographic separation which can be used with existing and new EAP methods to provide
between usages of EMSK. This allows for the development of new cryptographic separation between usages of EMSK. This allows for the
usages without cumbersome coordination between different usage development of new usages without cumbersome coordination between
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 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 USRK USRK
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 an 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 administrative 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 is 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
skipping to change at page 6, line 37 skipping to change at page 7, line 8
definition and are a maximum of 255 bytes. In general they are of definition and are a maximum of 255 bytes. 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. For the
optional data the KDF MUST be capable of processing at least 2048 optional data the KDF MUST be capable of processing at least 2048
opaque octets. The optional data must be constant during the opaque octets. The optional data must be constant during the
execution of the KDF. The length is a 2 byte unsigned integer in execution of the KDF. The length is a 2 byte unsigned integer in
network byte order of the output key length in octets. An network byte order of the output key length in octets. An
implementation of the KDF MUST be capable of producing at least 2048 implementation of the KDF MUST be capable of producing at least 2048
octets of output, however it is RECOMMENDED that Root Keys be 64 octets of output, however it is RECOMMENDED that Root Keys be at
octets long. 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.
3.2. The USRK Derivation Function 3.2. The USRK Derivation Function
The USRK key derivation function is based on a pseudo random function The USRK key derivation function is based on a pseudo random function
(PRF) that has the following function prototype: (PRF) that has the following function prototype:
KDF = PRF(key, data) KDF = PRF(key, data)
skipping to change at page 7, line 23 skipping to change at page 7, line 37
length = 2 byte unsigned integer in network byte order length = 2 byte unsigned integer in network byte order
'\0' = is a NULL byte (0x00 in hex) '\0' = is a NULL byte (0x00 in hex)
+ denotes concatenation + denotes concatenation
The NULL byte after the key label is used to avoid collisions if one The NULL byte 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.
<Editor's note: there is ongoing discussion on the value of including
the length of the key in the key derivation.>
This specification allows for the use of different PRFs. However, in This specification allows for the use of different PRFs. However, in
order to have a coordinated key derivation function the same PRF order to have a coordinated key derivation function the same PRF
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 PRF is specified, then the default PRF specified in Section 3.3
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 PRFs. PRFs 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 PRF
are as follows: are as follows:
o If no other PRF is specified the PRF specified in this document o If no other PRF is specified the PRF specified in this document
skipping to change at page 7, line 37 skipping to change at page 8, line 4
order to have a coordinated key derivation function the same PRF order to have a coordinated key derivation function the same PRF
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 PRF is specified, then the default PRF specified in Section 3.3
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 PRFs. PRFs 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 PRF
are as follows: are as follows:
o If no other PRF is specified the PRF specified in this document o If no other PRF is specified the PRF specified in this document
MUST be used. This is the "default" PRF. MUST be used. This is the "default" PRF.
o The initial authenticated key exchange MAY specify a favored PRF. o The initial authenticated key exchange MAY specify a favored PRF.
For example an EAP method may define a preferred PRF to use in its For example an EAP method may define a preferred PRF 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 PRF then this MUST override the default PRF.
o If the authenticated EAP key exchange is carried within another
lower layer protocol that has negotiation capabilities then this
protocol MAY attempt to negotiate a PRF to use. < editor's note:
Is this a good idea, the concern is that it may lead to usage
definitions trying to control what the PRF which may be difficult
to manage. VN: I don't understand how the lower layer can
negotiate a PRF for keys derived from the EMSK. Given that these
keys are derived by the peer and server, it seems appropriate that
either the same PRF as used in the EAP method be used or the
default PRF be used. Anything else seems to be opening up room
for confusion. JAS: Perhaps we should remove this bullet and the
next one. >
o If the system allows a lower layer protocol to negotiate a PRF
then the negotiated PRF MUST be used. It SHOULD take into account
any hints that are provided by the authenticated key exchange.
Note that this capability MUST protect against bidding down
attacks.
o A system MAY specify a separate default PRF if all participants o A system MAY specify a separate default PRF if all participants
within the system have the knowledge of which PRF to use. If within the system have the knowledge of which PRF to use. If
specified this MUST take precedence over key exchange defined PRF. 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 PRF construction or the PRF 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.3. Default PRF
The default PRF for deriving root keys from an EMSK is taken from the The default PRF 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 PRF from [RFC4306] based on HMAC-SHA-256 [SHA256].
The prf+ construction was chosen because of its simplicity and The prf+ construction was chosen because of its simplicity and
efficiency over other PRFs such as those used in [RFC2246]. The efficiency over other PRFs such as those used in [RFC2246]. The
motivation for the design of this PRF is described in [SIGMA]. The motivation for the design of this PRF is described in [SIGMA]. The
skipping to change at page 9, line 7 skipping to change at page 9, line 5
It is RECOMMENDED that the authenticated key exchange export a value, It is RECOMMENDED that the authenticated key exchange export a value,
an EAP Session-ID, that is known to both sides to provide a way to an EAP Session-ID, that is known to both sides to provide a way to
identify the exchange and the keys derived by the exchange. The EAP identify the exchange and the keys derived by the exchange. The EAP
keying framework [I-D.ietf-eap-keying] defines this value and keying framework [I-D.ietf-eap-keying] defines this value and
provides an example of how to name an EMSK. The use of names based 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. on the Session-ID in [I-D.ietf-eap-keying] is RECOMMENDED.
It is RECOMMENDED that each USRK has a name derived as follows: It is RECOMMENDED that each USRK has a name derived as follows:
USRK Name = prf-64( EAP Session-ID, key-label ) USRK Name = SHA-256-64 ( EAP Session-ID | key-label )
where prf-64 is the first 64 bits from the output where SHA-256-64 is the first 64 bits from the SHA-256 output
Usage definitions MAY use the EAP session-ID in the specification of Usage definitions MAY use the EAP session-ID in the specification of
the optional data parameter that go into the KDF function. This the optional data parameter that go into the KDF function. This
provides the advantage of providing data into the key derivation that provides the advantage of providing data into the key derivation that
is unique to the session that generated the keys. is unique to the session that generated the keys.
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 from the EMSK for a specific set of usages in a particular key
administrative domain. Usages derive specific keys for specific management domain. Usages derive specific keys for specific services
services from this DSRK. The DSRK may be distributed to an from this DSRK. The DSRK may be distributed to an key management
administrative domain for a specific set of usages so keys can be domain for a specific set of usages so keys can be derived within the
derived within the administrative domain for those usages. DSRK key management domain for those usages. DSRK based usages will
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 / \ DSUSRK21 DSUSRK22
DSUSRK11 DSUSRK12 DSUSRK11 DSUSRK12
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 administrative 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 is MUST be 64 octets
long. 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, 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
skipping to change at page 10, line 13 skipping to change at page 10, line 10
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 byte
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 64 octets long. be at least 64 octets long.
It is RECOMMENDED that each DSUSRK has a name derived as follows: It is RECOMMENDED that each DSUSRK has a name derived as follows:
DSUSRK Name = prf-64( DSRK Name, key-label ) DSUSRK Name = SHA-256-64( DSRK Name | key-label )
where prf-64 is the first 64 bits from the output 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 administrative domains. Note that usages may define different key managment domains. Note that usages may define
alternate ways to constrain specific keys to particular alternate ways to constrain specific keys to particular key
administrative doamins, however it is recommended that usages attempt management domains.
to follw the DSRK and DSUSRK derivation if possible so they can take
advantages of the mechanisms being developed to manage and distribute
the information required to generate these keys and the keys
themselves.
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.
skipping to change at page 11, line 4 skipping to change at page 10, line 43
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.4 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
(64 bytes). (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 30 skipping to change at page 11, line 24
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 have the same lifetime as the EMSK. Thus, when the EMSK Root Keys' lifetimes should not be more than that of the EMSK. Thus,
expires, the Root Keys derived from it should be removed from use. when the EMSK expires, the Root Keys derived from it should be
If a new EMSK is derived from a subsequent EAP transaction then a removed from use. If a new EMSK is derived from a subsequent EAP
usage implementation should begin to use the new Root Keys derived transaction then a usage implementation should begin to use the new
from the new EMSK as soon as possible. Whether or not child keys Root Keys derived from the new EMSK as soon as possible. Whether or
associated with a Root Key are replaced depends on the requirements not child keys associated with a Root Key are replaced depends on the
of the usage definition. It is conceivable that some usage requirements of the usage definition. It is conceivable that some
definition forces the child key to be replaced and others allow child usage definition forces the child key to be replaced and others allow
keys to be used based on the policy of the entities that use the child keys to be used based on the policy of the entities that use
child key. the child key.
<editor's note: It seems it may desirable for a Root Key lifetimes to
vary with usage definitions as well. It must never be greater than
that of the EMSK, but, it may be less. >
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
skipping to change at page 12, line 31 skipping to change at page 12, line 21
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 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.2.
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
skipping to change at page 14, line 48 skipping to change at page 14, line 34
Labels with the at-sign in them of the form "label-string@specorg" Labels with the at-sign in them of the form "label-string@specorg"
where the part preceding the at-sign is the label. The format of the where the part preceding the at-sign is the label. The format of the
part preceding the at-sign is not specified; however, these labels part preceding the at-sign is not specified; however, these labels
MUST be printable US-ASCII strings, and MUST NOT contain the comma MUST be printable US-ASCII strings, and MUST NOT contain the comma
character (","), whitespace, control characters (ASCII codes 32 or character (","), whitespace, control characters (ASCII codes 32 or
less), or the ASCII code 127 (DEL). They MUST have only a single at- less), or the ASCII code 127 (DEL). They MUST have only a single at-
sign in them. The part following the at-sign MUST be a valid, fully sign in them. The part following the at-sign MUST be a valid, fully
qualified Internet domain name [RFC1034] controlled by the person or qualified Internet domain name [RFC1034] controlled by the person or
organization defining the label. Labels are case-sensitive, and MUST organization defining the label. Labels are case-sensitive, and MUST
NOT be longer than 64 characters. It is up to each domain how it NOT be longer than 64 characters. It is up to each organization how
manages its local namespace. Note that the total number of octets in it manages its local namespace. Note that the total number of octets
a label is limited to 255. It has been noted that these labels in a label is limited to 255. It has been noted that these labels
resemble STD 11 [RFC0822] addresses and network access identifiers resemble STD 11 [RFC0822] addresses and network access identifiers
(NAI) defined in [RFC4282]. This is purely coincidental and has (NAI) defined in [RFC4282]. This is purely coincidental and has
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
locally defined label is "service@example.com" (without the double key label is "service@example.com" (without the double quotes).
quotes).
Labels within the "ietf.org" domain are assigned based on the IETF Labels within the "ietf.org" organization are assigned based on the
CONSENSUS policy with specification recommended. Labels from other IETF CONSENSUS policy with specification recommended. Labels from
domains may be registered with IANA by the person or organization other organizations may be registered with IANA by the person or
controlling the domain with an assignment policy of SPECIFICATION organization controlling the domain with an assignment policy of
REQUIRED. It is RECOMMENDED that the specification contain the SPECIFICATION REQUIRED. It is RECOMMENDED that the specification
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
skipping to change at page 16, line 29 skipping to change at page 16, line 13
RFC 4306, December 2005. RFC 4306, December 2005.
[SHA256] National Institute of Standards and Technology, "Secure [SHA256] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS 180-2, August 2002. Hash Standard", FIPS 180-2, August 2002.
With Change Notice 1 dated February 2004 With Change Notice 1 dated February 2004
10.2. Informative References 10.2. Informative References
[I-D.ietf-eap-keying] [I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key Aboba, B., Simon, D., and P. Eronen, "Extensible
Management Framework", draft-ietf-eap-keying-18 (work in Authentication Protocol (EAP) Key Management Framework",
progress), February 2007. draft-ietf-eap-keying-22 (work in progress),
November 2007.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet [RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982. 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.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
skipping to change at page 17, line 16 skipping to change at page 17, line 4
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
Huawei USA Motorola
Email: mnakhjiri@huawei.com Email: madjid.nakhjiri@motorola.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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. 45 change blocks. 
111 lines changed or deleted 99 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/