draft-ietf-hokey-emsk-hierarchy-02.txt   draft-ietf-hokey-emsk-hierarchy-03.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: May 21, 2008 V. Narayanan Expires: July 12, 2008 V. Narayanan
Qualcomm, Inc Qualcomm, Inc
M. Nakhjiri M. Nakhjiri
Motorola Motorola
November 18, 2007 January 9, 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-02.txt draft-ietf-hokey-emsk-hierarchy-03.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 May 21, 2008. This Internet-Draft will expire on July 12, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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
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 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 . . . . . . . . . . . . . . 6 3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 5
3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 6 3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 6
3.2. The USRK Derivation Function . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 4, line 21 skipping to change at page 4, line 21
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 Key Management Domain
A key management domain is a collection of systems that share the A key management domain is specified by the scope of a given root
same access to key material. A single administrative domain may key. The scope is the collection of systems authorized to access
contain several key management domains in order to contain the key material derived from that key. Systems within a key
scope of key material to a group of related systems. A entity management domain may be authorized to (1) derive key materials,
that is not a member of a key management domain must not make use (2) use key materials, or (3) distribute key materials to other
of key material for that domain. Only the domain where the key systems in the same domain. A derived key's scope is constrained
material is originated may derive key material from the EMSK for to a subset of the scope of the key it is derived from. In this
other domains. In the case where key material is distributed to document the term domain refers to a key management domain unless
another domain, intermediate systems may have access to see the otherwise qualified.
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 specific key management domain. It is used to derive child keys a specific key management domain. It is used to derive child keys
for a particular usage definition. The child keys derived from a for a particular usage definition. The child keys derived from a
DSRK are referred to as domain specific usage specific root keys DSRK are referred to as domain specific usage specific root keys
(DSUSRK). DSUSRKs are similar to the USRK, except in the fact (DSUSRK). DSUSRKs are similar to the USRK, except in the fact
that their scope is restricted to the same domain as the parent that their scope is restricted to the same domain as the parent
DSRK from which it is derived. DSRK from which it is derived.
skipping to change at page 8, line 22 skipping to change at page 8, line 18
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 [RFC4346]. 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
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)
skipping to change at page 9, line 19 skipping to change at page 9, line 19
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 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 an 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 / \ DSUSRK21 DSUSRK22
skipping to change at page 10, line 21 skipping to change at page 10, line 21
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 = SHA-256-64( DSRK Name | key-label ) DSUSRK Name = SHA-256-64( DSRK Name | key-label )
where SHA-256-64 is the first 64 bits from the SHA-256 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 key managment 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.
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
skipping to change at page 16, line 24 skipping to change at page 16, line 24
Authentication Protocol (EAP) Key Management Framework", Authentication Protocol (EAP) Key Management Framework",
draft-ietf-eap-keying-22 (work in progress), draft-ietf-eap-keying-22 (work in progress),
November 2007. 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",
RFC 2246, January 1999.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to [SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and its Use in the IKE Authenticated Diffie-Hellman and its Use in the IKE
Protocols", LNCS 2729, Springer, 2003. Protocols", LNCS 2729, Springer, 2003.
Available at http://www.informatik.uni-trier.de/~ley/db/ Available at http://www.informatik.uni-trier.de/~ley/db/
conf/crypto/crypto2003.html conf/crypto/crypto2003.html
Authors' Addresses Authors' Addresses
Joseph Salowey Joseph Salowey
skipping to change at page 18, line 7 skipping to change at page 18, line 7
Email: vidyan@qualcomm.com Email: vidyan@qualcomm.com
Madjid Nakhjiri Madjid Nakhjiri
Motorola Motorola
Email: madjid.nakhjiri@motorola.com Email: madjid.nakhjiri@motorola.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 13 change blocks. 
24 lines changed or deleted 22 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/