draft-ietf-hokey-emsk-hierarchy-00.txt   draft-ietf-hokey-emsk-hierarchy-01.txt 
Network Working Group J. Salowey HOKEY Working Group J. Salowey
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: July 15, 2007 L. Dondeti Intended status: Standards Track L. Dondeti
V. Narayanan Expires: December 23, 2007 V. Narayanan
Qualcomm, Inc Qualcomm, Inc
M. Nakhjiri M. Nakhjiri
Huawei USA Huawei USA
January 11, 2007 June 21, 2007
Specification for the Derivation of Usage Specific Root Keys (USRK) from Specification for the Derivation of Root Keys from an Extended Master
an Extended Master Session Key (EMSK) Session Key (EMSK)
draft-ietf-hokey-emsk-hierarchy-00.txt draft-ietf-hokey-emsk-hierarchy-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 15, 2007. This Internet-Draft will expire on December 23, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (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 document more purposes identified as usage definitions. This memo specifies a
specifies a mechanism for deriving cryptographically separate root mechanism for avoiding conflicts between root keys by deriving
keys from the EMSK, called usage specific root Keys (USRK). The cryptographically separate keys from the EMSK. This document also
document provides a set of requirements for avoiding conflicts describes a usage for domain specific root keys made available to and
between usage definitions to ensure this cryptographic separation. used within specific administrative domains.
The USRK is used according to the usage definition defined for a
specific purpose.
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. USRK Key Derivation Framework . . . . . . . . . . . . . . . . 5 3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 5
3.1 The USRK Key Derivation Function . . . . . . . . . . . . 6 3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 6
3.2 Default PRF . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. The USRK Derivation Function . . . . . . . . . . . . . . . 6
3.3 Key Naming and Usage Data . . . . . . . . . . . . . . . . 7 3.3. Default PRF . . . . . . . . . . . . . . . . . . . . . . . 8
4. Requirements for Usage Definitions . . . . . . . . . . . . . . 8 3.4. Key Naming and Usage Data . . . . . . . . . . . . . . . . 8
4.1 USRK Management Guidelines . . . . . . . . . . . . . . . . 8 4. Domain Specific Root Key Derivation . . . . . . . . . . . . . 9
5. Requirements for EAP System . . . . . . . . . . . . . . . . . 9 5. Requirements for Usage Definitions . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 11
6.1 Key strength . . . . . . . . . . . . . . . . . . . . . . . 10 6. Requirements for EAP System . . . . . . . . . . . . . . . . . 12
6.2 Cryptographic separation of keys . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.3 Implementation . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 13
6.4 Key Distribution . . . . . . . . . . . . . . . . . . . . . 10 7.2. Cryptographic separation of keys . . . . . . . . . . . . . 13
6.5 Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 11 7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 13
6.6 Entropy consideration . . . . . . . . . . . . . . . . . . 11 7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 13
7.1 USRK Key Labels . . . . . . . . . . . . . . . . . . . . . 11 7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 14
7.2 PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 15
9.1 Normative References . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9.2 Informative References . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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
future use. This document defines the EMSK to be used solely for future use. This document defines the EMSK to be used solely for
deriving root keys using the key derivation specified. The root keys deriving root keys using the key derivation specified. The root keys
are called usage specific root keys (USRK). This document also are meant either for specific purposes called usages. This document
provides guidelines for creating usage definitions for the various also provides guidelines for creating usage definitions for the
uses of EAP key material and for the management of the USRKs. Note various uses of EAP key material and for the management of the root
that previously USRKs were referred to as application master session keys. In this document, the terms application and usage (or "usage
keys (AMSKs); however this term proved to be confusing as it suggests definition") refer to a specific use case of the EAP keying material.
a particular class of usages dealing with higher layer applications
that it was not limited to serve. In this document, the terms
application and usage (or "usage definition") refer to a specific use
case of the EAP keying material for which a USRK is derived.
<Editor's note: the terminology is not clear yet. We need to work
this out. Context has been suggested as a replacement for usage and
application.>
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 usage definition. to make use of this specification it must specify a so-called usage
This document does not define how the derived USRKs should be used or definition. This document does not define how the derived Usage
discuss what types of use cases are valid. It does define a Specific Root Keys (USRK) should be used or discuss what types of use
framework for the derivation of USRKs for different purposes such cases are valid. It does define a framework for the derivation of
that different usages can be developed independently from one USRKs for different purposes such that different usages can be
another. The goal is to have security properties of one usage have developed independently from one another. The goal is to have
minimal affect on the security properties of other usages. security properties of one usage have minimal or no effect on the
security properties of other usages.
In order to keep specific uses separate from one another two This document does define a special class of USRK, called a Domain
requirements are defined in the following sections. One is Specific Root Key (DSRK) for use in deriving keys specific to an
coordinated key derivation and another is cryptographic separation. administrative domain. Each DSRK is a root key used to derive USRKs
which are specific to a particular administrative domain, called
Domain Specific Usage Specific Root Keys (DSUSRK).
1.1 Terminology In order to keep root keys for specific purposes separate from one
another two requirements are defined in the following sections. One
is coordinated key derivation and another is cryptographic
separation.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119]
The following terms are taken from [RFC3748]: EAP Server, peer, The following terms are taken from [RFC3748]: EAP Server, peer,
authenticator, Master Session Key (MSK), Extended Master Session Key authenticator, Master Session Key (MSK), Extended Master Session Key
(EMSK), Cryptographic Separation. (EMSK), Cryptographic Separation.
Usage Definition Usage Definition
An application of cryptographic key material to provide one or An application of cryptographic key material to provide one or
more security functions such as authentication, authorization, more security functions such as authentication, authorization,
encryption or integrity protection for related applications or encryption or integrity protection for related applications or
services. This document provides guidelines and recommendations services. This document provides guidelines and recommendations
for what should be included in usage definitions. This document for what should be included in usage definitions. This document
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 as specified in this document. It is used to derive definition. It is used to derive child keys in a way defined by
child keys in a way defined by its usage definition. its usage definition.
<Editor's note: USRK have been previously called AMSK for
application master session key.> Domain Specific Root Key (DSRK)
Keying material derived from the EMSK that is restricted to use in
a particular administrative domain. It is used to derive child
keys for a particular usage definition. The child keys derived
from a DSRK are referred to as domain specific usage specific root
keys (DSUSRK). DSUSRKs are similar to the USRK, except in the
fact that their scope is restricted to the same domain as the
parent 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
of an EMSK from a derived key or derivation of one child key from of an EMSK from a derived key or derivation of one child key from
another must require an amount of computation equivalent to that another must require an amount of computation equivalent to that
required to, say, reversing a cryptographic hash function. required to, say, reversing a cryptographic hash function.
Cryptographic separation of keys derived from the same key can be Cryptographic separation of keys derived from the same key can be
achieved in many ways. Two obvious methods are as follows: it is achieved in many ways. Two obvious methods are as follows: it is
plausible to use the IKEv2 PRF [RFC4306] on the EMSK and generate a plausible to use the IKEv2 PRF [RFC4306] on the EMSK and generate a
key stream. Keys of various lengths as required may be provided from key stream. Keys of various lengths may be provided as required from
the key stream for various uses. The other option is to derive keys the key stream for various uses. The other option is to derive keys
from EMSK by providing different inputs to the PRF. However, it is from EMSK by providing different inputs to the PRF. However, it is
desirable that derivation of one child key from the EMSK is desirable that derivation of one child key from the EMSK is
independent of derivation of another child key. This allows child independent of derivation of another child key. This allows child
keys to be derived in any order, independent of other keys. Thus it keys to be derived in any order, independent of other keys. Thus it
is desirable to use the second option from above. That implies the is desirable to use the second option from above. That implies the
additional input to the PRF must be different for each child key additional input to the PRF must be different for each child key
derivation. This additional input to the PRF must be coordinated derivation. This additional input to the PRF must be coordinated
properly to meet the requirement of cryptographic separation and to properly to meet the requirement of cryptographic separation and to
prevent reuse of key material between usages. prevent reuse of key material between usages.
If cryptographic separation is not maintained then the security of If cryptographic separation is not maintained then the security of
one usage depends upon the security of all other usages that use key one usage depends upon the security of all other usages that use key
derived from the EMSK. If a system does not have this property then derived from the EMSK. If a system does not have this property then
a usage's security depends upon all other usages deriving keys from a usage's security depends upon all other usages deriving keys from
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
USRK. root key derived from it.
o Any USRK must be cryptographically separate from any other USRK o Any root key MUST be cryptographically separate from any other
derived from the same EMSK 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
administrative domains do not derive the same key.
This document provides guidelines for a mechanism, which can be used This document provides guidelines for a mechanism, which can be used
with existing and new EAP methods to provide cryptographic separation with existing and new EAP methods to provide cryptographic separation
between usages of EAP keying material. This allows for the between usages of EMSK. This allows for the development of new
development of new usages without cumbersome coordination between usages without cumbersome coordination between different usage
different usage definitions. definitions.
3. USRK Key Derivation Framework 3. EMSK Key Root Derivation Framework
The USRK key derivation framework provides a coordinated means for The EMSK key derivation framework provides a coordinated means for
generating multiple USRKs from an EMSK. Further keys may then be generating multiple root keys from an EMSK. Further keys may then be
derived from the USRK 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. The usages of the USRK possession, and subsequent key derivation. A root key is derived
are set forth in a usage definition described in Section 4. from the EMSK for specific set of uses set forth in a usage
definition described in Section 5.
The USRK key derivation function (KDF) derives an USRK from the EMSK The basic EMSK root key hierarchy looks as follows:
described above, a key label, optional data, and output length. The
KDF is expected to give the same output for the same input. The EMSK
basic key derivation function is given below. / \
USRK USRK
This document defines how to derive usage specific root keys (USRK)
from the EMSK an also defines a specific USRK called a domain
specific root key (DSRK). DSRK are root keys restricted to use in a
particular administrative domain. From the DSRK, usage specific root
keys for a particular application may be derived (DSUSRK). The
DSUSRKs are equivalent to USRKs that are restricted to use in a
particular domain. The details of lower levels of key hierarchy is
outside scope of this document. The key hierarchy looks as follows:
EMSK
/ \
USRK DSRK
/ \
DSUSRK1 DSUSRK2
3.1. USRK Derivation
The EMSK Root Key derivation function (KDF) derives a USRK from the
EMSK, a key label, optional data, and output length. The KDF is
expected to give the same output for the same input. The basic key
derivation function is given below.
USRK = KDF(EMSK, key label, optional data, length) USRK = KDF(EMSK, 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
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@domain where domain is the organization that the form label-string@specorg where specorg is the organization that
controls the specification of the usage definition of the USRK. The controls the specification of the usage definition of the Root Key.
key label is intended to provide global uniqueness. Rules for the The key label is intended to provide global uniqueness. Rules for
allocation of these labels are given in Section 7. For the optional the allocation of these labels are given in Section 8. For the
data the KDF MUST be capable of processing at least 2048 opaque optional data the KDF MUST be capable of processing at least 2048
octets. The optional data must be constant during the execution of opaque octets. The optional data must be constant during the
the KDF. The length is a 2 byte unsigned integer in network byte execution of the KDF. The length is a 2 byte unsigned integer in
order of the output key length in octets. An implementation of the network byte order of the output key length in octets. An
KDF MUST be capable of producing at least 2048 octets of output, implementation of the KDF MUST be capable of producing at least 2048
however it is RECOMMENDED that USRKs be 64 octets long. octets of output, however it is RECOMMENDED that Root Keys be 64
octets long.
A usage definition requiring derivation of an USRK must specify all A usage definition requiring derivation of a Root Key must specify
the inputs (other than EMSK) to the key derivation function. all the inputs (other than EMSK) to the key derivation function.
3.1 The USRK Key Derivation Function 3.2. The USRK Derivation Function
The EMSK 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)
where: where:
key = EMSK key = EMSK
data = label + "\0" + op-data + length data = label + "\0" + op-data + length
label = ASCII key label label = ASCII key label
op-data = optional data op-data = optional data
length = 2 byte unsigned integer in network byte order length = 2 byte unsigned integer in network byte order
'\0' = is a NUL byte (0x00 in hex) '\0' = is a NULL byte (0x00 in hex)
+ denotes concatenation + denotes concatenation
The NUL 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.2 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 7. 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 o If the authenticated EAP key exchange is carried within another
lower layer protocol that has negotiation capabilities then this lower layer protocol that has negotiation capabilities then this
protocol MAY attempt to negotiate a PRF to use. < editor's note: 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 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 definitions trying to control what the PRF which may be difficult
to manage. > to manage. VN: I don't understand how the lower layer can
o If the system allows a lower layer protocol to negotiates a PRF 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 then the negotiated PRF MUST be used. It SHOULD take into account
any hints that are provide by the authenticated key exchange. any hints that are provided by the authenticated key exchange.
Note that this capability MUST protect against bidding down Note that this capability MUST protect against bidding down
attacks. 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.2 Default PRF 3.3. Default PRF
The default PRF for deriving USRKs 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
definition of PRF+ from [RFC4306]is given below: definition of PRF+ from [RFC4306]is given below:
prf+ (K,S) = T1 | T2 | T3 | T4 | ... prf+ (K,S) = T1 | T2 | T3 | T4 | ...
Where: Where:
T1 = prf (K, S | 0x01) T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02) T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03) T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04) T4 = prf (K, T3 | S | 0x04)
continuing as needed to compute the required length of key material. continuing as needed to compute the required length of key material.
The key, K, is the EMSK and S is the data defined in Section 3.1. The key, K, is the EMSK and S is the data defined in Section 3.2.
For this specification the PRF is taken as HMAC-SHA-256 [SHA256]. For this specification the PRF is taken as HMAC-SHA-256 [SHA256].
Since PRF+ is only defined for 255 iterations it may produce up to Since PRF+ is only defined for 255 iterations it may produce up to
8160 bytes of key material. 8160 bytes of key material.
3.3 Key Naming and Usage Data 3.4. Key Naming and Usage Data
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 root key has a name derived as follows: It is RECOMMENDED that each USRK has a name derived as follows:
USRK key name = prf-64( EAP Session-ID, key-label ) USRK Name = prf-64( EAP Session-ID, key-label )
where prf-64 is the first 64 bits from the output where prf-64 is the first 64 bits from the 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. Requirements for Usage Definitions 4. Domain Specific Root Key Derivation
A specific USRK called a Domain Specific Root Key (DSRK) is derived
from the EMSK for a specific set of usages in a particular
administrative domain. Usages derive specific keys for specific
services from this DSRK. The DSRK may be distributed to an
administrative domain for a specific set of usages so keys can be
derived within the administrative domain for those usages. DSRK
based usages will follow a key hierarchy similar to the following:
EMSK
/ \
/ \
DSRK1 DSRK2
/ \ / \
/ \ DSUSRK21 DSUSRK22
DSUSRK11 DSUSRK12
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
contain an ASCII string representing the administrative domain that
the root key is being derived for. The DSRK is MUST be 64 octets
long.
Domain Specific Usage Specific Root Keys (DSUSRK) are derived from
the DSRK. The KDF is expected to give the same output for the same
input. The basic key derivation function is given below.
DSUSRK = KDF(DSRK, key label, optional data, length)
The key labels are printable ASCII strings unique for each usage
definition within a DSRK usage and are a maximum of 255 bytes. In
general they are of the form label-string@specorg where specorg is
the organization that controls the specification of the usage
definition of the DSRK. The key label is intended to provide global
uniqueness. Rules for the allocation of these labels are given in
Section 8. For the optional data the KDF MUST be capable of
processing at least 2048 opaque octets. The optional data must be
constant during the execution of the KDF. The length is a 2 byte
unsigned integer in network byte order of the output key length in
octets. An implementation of the KDF MUST be capable of producing at
least 2048 octets of output, however it is RECOMMENDED that DSUSRKs
be 64 octets long.
It is RECOMMENDED that each DSUSRK has a name derived as follows:
DSUSRK Name = prf-64( DSRK Name, key-label )
where prf-64 is the first 64 bits from the output
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
must define how both DSRKs and specific DSUSRKs are transported to
different administrative domains. Note that usages may define
alternate ways to constrain specific keys to particular
administrative doamins, however it is recommended that usages attempt
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
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 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 USRKs using the key derivation specified in Section 3 of to derive Root Keys using the key derivation specified in
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 USRK derived specifically for the usage is RECOMMENDED that the Root Key derived specifically for the
definition rather than the EMSK should be used as a root key to usage definition rather than the EMSK should be used to derive
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.3 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 USRK. It is
RECOMMENDED that the USRK be at least as long as the EMSK (64 o Usage definitions MUST define the length of their Root Keys. It
bytes). is RECOMMENDED that the Root Keys be at least as long as the EMSK
o Usage definitions MUST define how they use their USRK. This (64 bytes).
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
USRK Management guidelines. Root Key Management guidelines.
o
4.1 USRK 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 USRK 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 USRK only used as a root key for deriving It is RECOMMENDED that the Root Key only used for deriving child
child keys. A usage definition must specify how and when the keys. A usage definition must specify how and when the derivation of
derivation of child keys should be done. It is RECOMMENDED that child keys should be done. It is RECOMMENDED that usages following
usages following similar considerations for key derivation are as similar considerations for key derivation are as outlined in this
outlined in this document for the USRK derivation with respect to document for the Root Key derivation with respect to cryptographic
cryptographic separation and key reuse. In addition, usages should separation and key reuse. In addition, usages should take into
take into consideration the number of keys that will be derived from consideration the number of keys that will be derived from the Root
the USRK and ensure that enough entropy is introduced in the Key and ensure that enough entropy is introduced in the derivation to
derivation to support this usage. It is desirable that the entropy support this usage. It is desirable that the entropy is provided by
is provided by the two parties that derive the child key. the two parties that derive the child key.
USRKs have the same lifetime as the EMSK. Thus, when the EMSK Root Keys have the same lifetime as the EMSK. Thus, when the EMSK
expires, the USRKs derived from it should be removed from use. If a expires, the Root Keys derived from it should be removed from use.
new EMSK is derived from a subsequent EAP transaction then a usage If a new EMSK is derived from a subsequent EAP transaction then a
implementation should begin to use the new USRK derived from the new usage implementation should begin to use the new Root Keys derived
EMSK as soon as possible. Whether or not child keys associated with from the new EMSK as soon as possible. Whether or not child keys
a USRK are replaced depends on the requirements of the usage associated with a Root Key are replaced depends on the requirements
definition. It is conceivable that some usage definition forces the of the usage definition. It is conceivable that some usage
child key to be replaced and others allow child keys to be used based definition forces the child key to be replaced and others allow child
on the policy of the entities that use the child key. keys to be used based on the policy of the entities that use the
child key.
<editor's note: It seems it may desirable for a USRK lifetimes to <editor's note: It seems it may desirable for a Root Key lifetimes to
vary with usage definitions as well> 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 USRKs; however, some USRKs may be provided to holds true for some Root Keys; however, some Root Keys may be
other entities for child key derivation and delivery. Each usage provided to other entities for child key derivation and delivery.
definition specification will specify delivery caching and/or Each usage definition specification will specify delivery caching
delivery procedures. Note that the purpose of the key derivation in and/or delivery procedures. Note that the purpose of the key
Section 3 is to ensure that USRKs are cryptographically separate from derivation in Section 3 is to ensure that Root Keys are
each other and the EMSK. In other words, given an USRK, it is cryptographically separate from each other and the EMSK. In other
computationally infeasible to derive the EMSK, any other USRKs, or words, given a Root Key, it is computationally infeasible to derive
child keys associated with other USRKs. In addition to the USRK, the EMSK, any other Root Keys, or child keys associated with other
several other parameters may need to be sent. USRK name should be Root Keys. In addition to the Root Key, several other parameters may
derived from the EMSK key name, and thus the key name needs to be need to be sent. Root Key name should be derived using the EAP
sent along with the key. When USRKs are delivered to another entity, Session ID, and thus the key name needs to be sent along with the
the lifetime associated with the specific root keys MUST also be key. When Root Keys are delivered to another entity, the lifetime
transported to that entity. Recommendations for transporting keys associated with the specific root keys MUST also be transported to
are discussed in the security considerations (Section 6.4). that entity. Recommendations for transporting keys are discussed in
the security considerations (Section 7.4).
Usage definition may also define how keys are bound to particular Usage definition may also define how keys are bound to particular
usages entities. This can be done through the inclusion of usage entities. This can be done through the inclusion of usage parameters
parameters and identities in the child key derivation. Some of this and identities in the child key derivation. Some of this data is
data is described as "channel bindings" in [RFC3748]. described as "channel bindings" in [RFC3748].
5. Requirements for EAP System 6. Requirements for EAP System
The system that wishes to make use of EAP USRKs must take certain The system that wishes to make use of EAP root keys derived from the
things into consideration. The following is a list of these EMSK must take certain things into consideration. The following is a
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 keys (USRKs) derived according entity where it is generated. Only root keys derived according to
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 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.1. 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
more than one usage uses the MSK, then the cryptographic separation more than one usage uses the MSK, then the cryptographic separation
is not achieved. Implementations MUST prevent such combinations. is not achieved. Implementations MUST prevent such combinations.
6. Security Considerations 7. Security Considerations
6.1 Key strength 7.1. Key strength
The effective key strength of the derived keys will never be greater The effective key strength of the derived keys will never be greater
than the strength of the EMSK (or a master key internal to an EAP than the strength of the EMSK (or a master key internal to an EAP
mechanism). mechanism).
6.2 Cryptographic separation of keys 7.2. Cryptographic separation of keys
The intent of the KDF is to derive keys that are cryptographically The intent of the KDF is to derive keys that are cryptographically
separate: the compromise of one of the usage specific root keys separate: the compromise of one of the usage specific root keys
(USRKs) should not compromise the security of other USRKs or the (USRKs) should not compromise the security of other USRKs or the
EMSK. It is believed that the KDF chosen provides the desired EMSK. It is believed that the KDF chosen provides the desired
separation. separation.
6.3 Implementation 7.3. Implementation
An implementation of an EAP framework should keep the EMSK internally An implementation of an EAP framework should keep the EMSK internally
as close to where it is derived as possible and only provide an as close to where it is derived as possible and only provide an
interface for obtaining USRKs. It may also choose to restrict which interface for obtaining Root Keys. It may also choose to restrict
callers have access to which keys. A usage definition MUST NOT which callers have access to which keys. A usage definition MUST NOT
assume that any entity outside the EAP server or EAP peer EAP assume that any entity outside the EAP server or EAP peer EAP
framework has access to the EMSK. In particular it MUST NOT assume framework has access to the EMSK. In particular it MUST NOT assume
that a lower layer has access to the EMSK. that a lower layer has access to the EMSK.
6.4 Key Distribution 7.4. Key Distribution
In some cases it will be necessary or convenient to distribute USRKs In some cases it will be necessary or convenient to distribute USRKs
from where they are generated. Since these are secret keys they MUST from where they are generated. Since these are secret keys they MUST
be transported with their integrity and confidentiality maintained. be transported with their integrity and confidentiality maintained.
They MUST be transmitted between authenticated and authorized They MUST be transmitted between authenticated and authorized
parties. It is also important that the context of the key usage be parties. It is also important that the context of the key usage be
transmitted along with the key. This includes information to transmitted along with the key. This includes information to
identify the key and constraints on its usage such as lifetime. identify the key and constraints on its usage such as lifetime.
This document does not define a mechanism for key transport. It is This document does not define a mechanism for key transport. It is
up to usage definitions and the systems that use them to define how up to usage definitions and the systems that use them to define how
keys are distributed. Usage definition designers may enforce keys are distributed. Usage definition designers may enforce
constraints on key usage by various parties by deriving a key constraints on key usage by various parties by deriving a key
hierarchy and by providing entities only with the keys in the hierarchy and by providing entities only with the keys in the
hierarchy that they need. hierarchy that they need.
6.5 Key Lifetime 7.5. Key Lifetime
The key lifetime is dependent upon how the key is generated and how The key lifetime is dependent upon how the key is generated and how
the key is used. Since the USRK is the responsibility of the usage the key is used. Since the Root Key is the responsibility of the
definition it must determine how long the key is valid for. If key usage definition it must determine how long the key is valid for. If
lifetime or key strength information is available from the key lifetime or key strength information is available from the
authenticated key exchange then this information SHOULD be used in authenticated key exchange then this information SHOULD be used in
determining the lifetime of the key. If possible it is recommended determining the lifetime of the key. If possible it is recommended
that key lifetimes be coordinated throughout the system. Setting a that key lifetimes be coordinated throughout the system. Setting a
key lifetime shorter that a system lifetime may result is keys key lifetime shorter that a system lifetime may result is keys
becoming invalid with no convenient way to refresh them. Setting a becoming invalid with no convenient way to refresh them. Setting a
key lifetime to longer may result in decreased security since the key key lifetime to longer may result in decreased security since the key
may be used beyond its recommended lifetime. may be used beyond its recommended lifetime.
6.6 Entropy consideration 7.6. Entropy consideration
The number of root keys derived from the EMSK is expected to be low. The number of root keys derived from the EMSK is expected to be low.
Note that there is no randomness required to be introduced into the Note that there is no randomness required to be introduced into the
EMSK to root key derivation beyond the root key labels. Thus, if EMSK to root key derivation beyond the root key labels. Thus, if
many keys are going to be derived from an USRK it is important that many keys are going to be derived from an Root Key it is important
USRK to child key derivation introduce fresh random numbers in that Root Key to child key derivation introduce fresh random numbers
deriving each key. in deriving each key.
7. IANA Considerations 8. IANA Considerations
The keywords "PRIVATE USE", "SPECIFICATION REQUIRED" and "IETF The keywords "PRIVATE USE", "SPECIFICATION REQUIRED" and "IETF
CONSENSUS" that appear in this document when used to describe CONSENSUS" that appear in this document when used to describe
namespace allocation are to be interpreted as described in [RFC2434]. namespace allocation are to be interpreted as described in [RFC2434].
7.1 USRK Key Labels 8.1. Key Labels
This specification introduces a new name space for "USRK key labels". This specification introduces a new name space for "USRK key labels".
Key labels are of one of two formats: "label-string" or Key labels are of one of two formats: "label-string" or
"label-string@domain" (without the double quotes). "label-string@specorg" (without the double quotes).
Labels of the form "label-string" registered by the IANA MUST be Labels of the form "label-string" registered by the IANA MUST be
printable US-ASCII strings, and MUST NOT contain the characters at- printable US-ASCII strings, and MUST NOT contain the characters at-
sign ("@"), comma (","), whitespace, control characters (ASCII codes sign ("@"), comma (","), whitespace, control characters (ASCII codes
32 or less), or the ASCII code 127 (DEL). Labels are case-sensitive, 32 or less), or the ASCII code 127 (DEL). Labels are case-sensitive,
and MUST NOT be longer than 64 characters. Labels of this form are and MUST NOT be longer than 64 characters. Labels of this form are
assigned based on the IETF CONSENSUS policy. assigned based on the IETF CONSENSUS policy.
Labels with the at-sign in them of the form "label-string@domain" 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 domain how it
manages its local namespace. Note that the total number of octets in manages its local namespace. Note that the total number of octets in
a label is limited to 255. It has been noted that these labels 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 locally defined 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" domain are assigned based on the IETF
CONSENSUS policy with specification recommended. Labels from other CONSENSUS policy with specification recommended. Labels from other
domains may be registered with IANA by the person or organization domains may be registered with IANA by the person or organization
controlling the domain with an assignment policy of SPECIFICATION controlling the domain with an assignment policy of SPECIFICATION
REQUIRED. It is RECOMMENDED that the specification contain the REQUIRED. It is RECOMMENDED that the specification contain the
following information: 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 USRK 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 USRK and how they will be o How child keys will be derived from the Root Key and how they will
used be used
o How lifetime of the USRK and its child keys will be managed o How lifetime of the Root Key and its child keys will be managed
o Where the USRKs 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
7.2 PRF numbers 8.2. PRF numbers
This specification introduces a new number space for "EMSK PRF This specification introduces a new number space for "EMSK PRF
numbers". The numbers are int he range 0 to 255 Numbers from 0 to numbers". The numbers are int he range 0 to 255 Numbers from 0 to
220 are assigned through the policy IETF CONSENSUS and numbers in the 220 are assigned through the policy IETF CONSENSUS and numbers in the
range 221 to 255 are left for PRIVATE USE. The initial registry range 221 to 255 are left for PRIVATE USE. The initial registry
should contain the following values: should contain the following values:
0 RESERVED 0 RESERVED
1 HMAC-SHA-256 PRF+ (Default) 1 HMAC-SHA-256 PRF+ (Default)
8. Acknowledgements 9. Acknowledgements
This document expands upon previous collaboration with Pasi Eronen. This document expands upon previous collaboration with Pasi Eronen.
This document reflects conversations with Bernard Aboba, Jari Arkko, This document reflects conversations with Bernard Aboba, Jari Arkko,
Avi Lior, David McGrew, Henry Haverinen, Hao Zhou and members of the Avi Lior, David McGrew, Henry Haverinen, Hao Zhou and members of the
EAP working group. EAP working group.
9. References 10. References
9.1 Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
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
9.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., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-16 (work in Management Framework", draft-ietf-eap-keying-18 (work in
progress), January 2007. progress), February 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 15, line 5 skipping to change at page 18, line 5
Vidya Narayanan Vidya Narayanan
Qualcomm, Inc Qualcomm, Inc
Email: vidyan@qualcomm.com Email: vidyan@qualcomm.com
Madjid Nakhjiri Madjid Nakhjiri
Huawei USA Huawei USA
Email: mnakhjiri@huawei.com Email: mnakhjiri@huawei.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 15, line 29 skipping to change at page 18, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2007). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 84 change blocks. 
222 lines changed or deleted 331 lines changed or added

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