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/ |