draft-ietf-hokey-emsk-hierarchy-04.txt   draft-ietf-hokey-emsk-hierarchy-05.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: August 27, 2008 V. Narayanan Expires: October 24, 2008 V. Narayanan
Qualcomm, Inc Qualcomm, Inc
M. Nakhjiri M. Nakhjiri
Motorola Motorola
February 24, 2008 April 22, 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-04.txt draft-ietf-hokey-emsk-hierarchy-05.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 August 27, 2008. This Internet-Draft will expire on October 24, 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 The Extensible Authentication Protocol (EAP) defined the Extended
generated from an Extensible Authentication Protocol (EAP) exchange Master Session Key (EMSK) generation, but reserved it for unspecified
reserved solely for the purpose of deriving master keys for one or future uses. This memo reserves the EMSK for the sole purpose of
more purposes identified as usage definitions. This memo specifies a deriving root keys. Root keys are are master keys that can be used
mechanism for avoiding conflicts between root keys by deriving for multiple purposes, identified by usage definitions. This
cryptographically separate keys from the EMSK. This document also document also specifies a mechanism for avoiding conflicts between
describes a usage for domain specific root keys made available to and root keys by deriving them in a manner that guarantee cryptographic
separation. Finally, this document also defines one such root key
usage: domain specific root keys are root keys made available to and
used within specific key management domains. used within specific key management domains.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicable usages of keys derived from the EMSK . . . . . 3
2. Cryptographic Separation and Coordinated Key Derivation . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Cryptographic Separation and Coordinated Key Derivation . . . 5
3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 6 3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 6
3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 6 3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. On the KDFs . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. On the KDFs . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. Default KDF . . . . . . . . . . . . . . . . . . . . . 8 3.1.2. Default KDF . . . . . . . . . . . . . . . . . . . . . 8
3.2. EMSK and USRK Name Derivation . . . . . . . . . . . . . . 9 3.2. EMSK and USRK Name Derivation . . . . . . . . . . . . . . 9
4. Domain Specific Root Key Derivation . . . . . . . . . . . . . 9 4. Domain Specific Root Key Derivation . . . . . . . . . . . . . 10
5. Requirements for Usage Definitions . . . . . . . . . . . . . . 11 4.1. Applicability of Multi-Domain usages . . . . . . . . . . . 11
5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 11 5. Requirements for Usage Definitions . . . . . . . . . . . . . . 12
5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 12
6. Requirements for EAP System . . . . . . . . . . . . . . . . . 13 6. Requirements for EAP System . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Cryptographic separation of keys . . . . . . . . . . . . . 13 7.2. Cryptographic separation of keys . . . . . . . . . . . . . 14
7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 13 7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 14
7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 14 7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 14
7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 14 7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 15
7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 14 7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 16 8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19 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
skipping to change at page 3, line 29 skipping to change at page 3, line 29
key material and for the management of the root keys. In this key material and for the management of the root keys. In this
document, the terms application and usage (or "usage definition") document, the terms application and usage (or "usage definition")
refer to a specific use case of the EAP keying material. refer to a specific use case of the EAP keying material.
Different uses for keys derived from the EMSK have been proposed. Different uses for keys derived from the EMSK have been proposed.
Some examples include hand off across access points in various mobile Some examples include hand off across access points in various mobile
technologies, mobile IP authentication and higher layer application technologies, mobile IP authentication and higher layer application
authentication. In order for a particular usage of EAP key material authentication. In order for a particular usage of EAP key material
to make use of this specification it must specify a so-called usage to make use of this specification it must specify a so-called usage
definition. This document does not define how the derived Usage definition. This document does not define how the derived Usage
Specific Root Keys (USRK) should be used or discuss what types of use Specific Root Keys (USRK) are used, see the following section for
cases are valid. It does define a framework for the derivation of discussion of applicable usages. It does define a framework for the
USRKs for different purposes such that different usages can be derivation of USRKs for different purposes such that different usages
developed independently from one another. The goal is to have can be developed independently from one another. The goal is to have
security properties of one usage have minimal or no effect on the security properties of one usage have minimal or no effect on the
security properties of other usages. security properties of other usages.
This document does define a special class of USRK, called a Domain This document does define a special class of USRK, called a Domain
Specific Root Key (DSRK) for use in deriving keys specific to a key Specific Root Key (DSRK) for use in deriving keys specific to a key
management domain. Each DSRK is a root key used to derive Domain management domain. Each DSRK is a root key used to derive Domain
Specific Usage Specific Root Keys (DSUSRK). The DSUSRKs are USRKs Specific Usage Specific Root Keys (DSUSRK). The DSUSRKs are USRKs
specific to a particular key management domain. specific to a particular key management domain.
In order to keep root keys for specific purposes separate from one In order to keep root keys for specific purposes separate from one
another, two requirements are defined in the following sections. One another, two requirements are defined in the following sections. One
is coordinated key derivation and another is cryptographic is coordinated key derivation and another is cryptographic
separation. separation.
1.1. Terminology 1.1. Applicable usages of keys derived from the EMSK
The EMSK is established as part of network access authentication and
authorization. The derived keys need to be distributed to the
involved parties along with context necessary to use them. The
security of the system relies upon trust relationships between the
parties involved in this process. These trust relationships are the
basis for applying protection during key transport and ensuring
proper key usage. Hence, deriving USRKs or DSUSRKs for purposes
where placing trust in the entities involved in establishing network
access is inappropriate or not possible is NOT RECOMMENDED.
It is also only feasible to make use of EMSK usages when network
access occurs over an EAP-capable interface. If it is possible for
an entity to access these services though an interface that does not
involve EAP authentication and authorization with the appropriate
entities then alternate means of authentication and key establishment
for these services needs to be provided.
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119]
The following terms are taken from [RFC3748]: EAP Server, peer, The following terms are taken from [RFC3748]: EAP Server, peer,
authenticator, Master Session Key (MSK), Extended Master Session Key authenticator, Master Session Key (MSK), Extended Master Session Key
(EMSK), Cryptographic Separation. (EMSK), Cryptographic Separation.
Usage Definition Usage Definition
An application of cryptographic key material to provide one or An application of cryptographic key material to provide one or
more security functions such as authentication, authorization, more security functions such as authentication, authorization,
encryption or integrity protection for related applications or encryption or integrity protection for related applications or
services. This document provides guidelines and recommendations services. This document provides guidelines and recommendations
for what should be included in usage definitions. This document for what should be included in usage definitions. This document
skipping to change at page 11, line 18 skipping to change at page 11, line 41
an exception in key naming, so both parties know the key name used. an exception in key naming, so both parties know the key name used.
DSUSRKs MAY be named explicitly with a name derivation specified as DSUSRKs MAY be named explicitly with a name derivation specified as
follows: follows:
DSUSRKName = DSUSRKName =
KDF(EMSKName,key label | "\0" | optional data | length) KDF(EMSKName,key label | "\0" | optional data | length)
where length is the 2 octet unsigned integer 8 in network byte order. where length is the 2 octet unsigned integer 8 in network byte order.
4.1. Applicability of Multi-Domain usages
When a DSRK is distributed to a domain the domain can generate any
DSUSRKs it wishes. This keys can be used to authorize entities in a
domain to perform specific functions. In cases where it is
appropriate for only a specific domain to be authorized to perform a
function the usage SHOULD NOT be defined as multi-domain.
In some cases only certain domains are authorized for a particular
Multi-Domain usage. In this case domains that do not have full
authorization should not receive the DSRK and should only receive
DSUSRKs for the usages which they are authorized. If it is possible
for a peer to know which domains are authorized for a particular
usage without relying on restricting access to the DSRK to specific
domains then this recommendation may be relaxed.
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
skipping to change at page 11, line 50 skipping to change at page 12, line 41
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 is only used for deriving child
keys. A usage definition must specify how and when the derivation of keys. A usage definition must specify how and when the derivation of
child keys should be done. It is RECOMMENDED that usages following child keys should be done. It is RECOMMENDED that usages following
similar considerations for key derivation are as outlined in this similar considerations for key derivation are as outlined in this
document for the Root Key derivation with respect to cryptographic document for the Root Key derivation with respect to cryptographic
separation and key reuse. In addition, usages should take into separation and key reuse. In addition, usages should take into
consideration the number of keys that will be derived from the Root consideration the number of keys that will be derived from the Root
Key and ensure that enough entropy is introduced in the derivation to Key and ensure that enough entropy is introduced in the derivation to
support this usage. It is desirable that the entropy is provided by support this usage. It is desirable that the entropy is provided by
the two parties that derive the child key. the two parties that derive the child key.
 End of changes. 17 change blocks. 
34 lines changed or deleted 74 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/