draft-ietf-hokey-emsk-hierarchy-05.txt | draft-ietf-hokey-emsk-hierarchy-06.txt | |||
---|---|---|---|---|
Network Working Group J. Salowey | Network Working Group J. Salowey | |||
Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
Intended status: Standards Track L. Dondeti | Updates: eap-keying (RFC Ed to L. Dondeti | |||
Expires: October 24, 2008 V. Narayanan | replace this with RFC number) V. Narayanan | |||
Qualcomm, Inc | (if approved) Qualcomm, Inc | |||
M. Nakhjiri | Intended status: Standards Track M. Nakhjiri | |||
Motorola | Expires: December 25, 2008 Motorola | |||
April 22, 2008 | June 23, 2008 | |||
Specification for the Derivation of Root Keys from an Extended Master | Specification for the Derivation of Root Keys from an Extended Master | |||
Session Key (EMSK) | Session Key (EMSK) | |||
draft-ietf-hokey-emsk-hierarchy-05.txt | draft-ietf-hokey-emsk-hierarchy-06 | |||
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 October 24, 2008. | This Internet-Draft will expire on December 25, 2008. | |||
Copyright Notice | ||||
Copyright (C) The IETF Trust (2008). | ||||
Abstract | Abstract | |||
The Extensible Authentication Protocol (EAP) defined the Extended | The Extensible Authentication Protocol (EAP) defined the Extended | |||
Master Session Key (EMSK) generation, but reserved it for unspecified | Master Session Key (EMSK) generation, but reserved it for unspecified | |||
future uses. This memo reserves the EMSK for the sole purpose of | future uses. This memo reserves the EMSK for the sole purpose of | |||
deriving root keys. Root keys are are master keys that can be used | deriving root keys. Root keys are are master keys that can be used | |||
for multiple purposes, identified by usage definitions. This | for multiple purposes, identified by usage definitions. This | |||
document also specifies a mechanism for avoiding conflicts between | document also specifies a mechanism for avoiding conflicts between | |||
root keys by deriving them in a manner that guarantee cryptographic | root keys by deriving them in a manner that guarantee cryptographic | |||
separation. Finally, this document also defines one such root key | separation. Finally, this document also defines one such root key | |||
usage: domain specific root keys are root keys made available to and | usage: domain specific root keys are root keys made available to and | |||
used within specific key management domains. | used within specific key management domains. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Applicable usages of keys derived from the EMSK . . . . . 3 | 1.1. Applicable usages of keys derived from the EMSK . . . . . 3 | |||
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Cryptographic Separation and Coordinated Key Derivation . . . 5 | 2. Cryptographic Separation and Coordinated Key Derivation . . . 6 | |||
3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 6 | 3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 7 | |||
3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 7 | 3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.1.1. On the KDFs . . . . . . . . . . . . . . . . . . . . . 8 | 3.1.1. On the KDFs . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.1.2. Default KDF . . . . . . . . . . . . . . . . . . . . . 8 | 3.1.2. Default KDF . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.2. EMSK and USRK Name Derivation . . . . . . . . . . . . . . 9 | 3.2. EMSK and USRK Name Derivation . . . . . . . . . . . . . . 9 | |||
4. Domain Specific Root Key Derivation . . . . . . . . . . . . . 10 | 4. Domain Specific Root Key Derivation . . . . . . . . . . . . . 10 | |||
4.1. Applicability of Multi-Domain usages . . . . . . . . . . . 11 | 4.1. Applicability of Multi-Domain usages . . . . . . . . . . . 12 | |||
5. Requirements for Usage Definitions . . . . . . . . . . . . . . 12 | 5. Requirements for Usage Definitions . . . . . . . . . . . . . . 12 | |||
5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 12 | 5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 13 | |||
6. Requirements for EAP System . . . . . . . . . . . . . . . . . 13 | 6. Requirements for EAP System . . . . . . . . . . . . . . . . . 14 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 14 | 7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
7.2. Cryptographic separation of keys . . . . . . . . . . . . . 14 | 7.2. Cryptographic separation of keys . . . . . . . . . . . . . 15 | |||
7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 14 | 7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 15 | |||
7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 14 | 7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 15 | |||
7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 15 | 7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 15 | 7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 16 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | |||
8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 15 | 8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 16 | 8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 19 | Intellectual Property and Copyright Statements . . . . . . . . . . 20 | |||
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 | |||
skipping to change at page 3, line 49 | skipping to change at page 3, line 49 | |||
Specific Usage Specific Root Keys (DSUSRK). The DSUSRKs are USRKs | Specific Usage Specific Root Keys (DSUSRK). The DSUSRKs are USRKs | |||
specific to a particular key management domain. | specific to a particular key management domain. | |||
In order to keep root keys for specific purposes separate from one | In order to keep root keys for specific purposes separate from one | |||
another, two requirements are defined in the following sections. One | another, two requirements are defined in the following sections. One | |||
is coordinated key derivation and another is cryptographic | is coordinated key derivation and another is cryptographic | |||
separation. | separation. | |||
1.1. Applicable usages of keys derived from the EMSK | 1.1. Applicable usages of keys derived from the EMSK | |||
The EMSK is established as part of network access authentication and | The EMSK is typically established as part of network access | |||
authorization. The derived keys need to be distributed to the | authentication and authorization. It is expected that keys derived | |||
involved parties along with context necessary to use them. The | from EMSK will be used in protocols related to network access, such | |||
security of the system relies upon trust relationships between the | as handover optimizations, and the scope of these protocols is | |||
parties involved in this process. These trust relationships are the | usually restricted to the endpoints of the lower layers over which | |||
basis for applying protection during key transport and ensuring | EAP packets are sent. | |||
proper key usage. Hence, deriving USRKs or DSUSRKs for purposes | ||||
where placing trust in the entities involved in establishing network | ||||
access is inappropriate or not possible is NOT RECOMMENDED. | ||||
It is also only feasible to make use of EMSK usages when network | In particular, it is inappropriate for the security of higher layer | |||
access occurs over an EAP-capable interface. If it is possible for | applications to solely rely on keys derived from network access | |||
an entity to access these services though an interface that does not | authentication. Even when used together with another, independent | |||
involve EAP authentication and authorization with the appropriate | security mechanism, the use of these keys needs to be carefully | |||
entities then alternate means of authentication and key establishment | evaluated with regards to the benefits of the optimization and the | |||
for these services needs to be provided. | need to support multiple solutions. Performance optimizations may | |||
not warrant the close tie-in that may be required between the layers | ||||
in order to use EAP-based keys. Such optimizations may be offset by | ||||
the complexities of managing the validity and usage of key materials. | ||||
Keys generated from subsequent EAP authentications may be beyond the | ||||
knowledge and control of applications. | ||||
From an architectural point of view, applications should not make | ||||
assumptions about the lower layer technology (such as network access | ||||
authentication) used on any particular hop along the path between the | ||||
application endpoints. | ||||
From a practical point of view, making such assumptions would | ||||
complicate using those applications over lower layers that do not use | ||||
EAP, and make it more difficult for applications and network access | ||||
technologies to evolve independently of each other. | ||||
Parties using keys derived from EMSK also need trust relationships | ||||
with the EAP endpoints, and mechanisms for securely communicating the | ||||
keys. | ||||
For most applications, it is not appropriate to assume that all | ||||
current and future access networks are trusted to secure the | ||||
application function. Instead, applications should implement the | ||||
required security mechanisms in access independent manner. | ||||
Implementation considerations may also complicate communication of | ||||
keys to an application from the lower layer. For instance, in many | ||||
configurations applications may run on a different device than the | ||||
one providing EAP-based network access to it. | ||||
Given all this, it is NOT RECOMMENDED to use keys derived from the | ||||
EMSK as an exclusive security mechanism, when their usage is not | ||||
inherently, and by permanent nature, tied to the lower layer where | ||||
network access authentication was performed. | ||||
Keys derived from EAP are pairwise by nature and are not directly | ||||
suitable for multicast or other group usages such as those involved | ||||
in some routing protocols. It is possible to use keys derived from | ||||
EAP in protocols that distribute group keys to group participants. | ||||
The definition of these group key distribution protocols is beyond | ||||
the scope of this document and would require additional | ||||
specification. | ||||
1.2. Terminology | 1.2. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119] | document are to be interpreted as described in [RFC2119] | |||
The following terms are taken from [RFC3748]: EAP Server, peer, | The following terms are taken from [RFC3748]: EAP Server, peer, | |||
authenticator, Master Session Key (MSK), Extended Master Session Key | authenticator, Master Session Key (MSK), Extended Master Session Key | |||
(EMSK), Cryptographic Separation. | (EMSK), Cryptographic Separation. | |||
skipping to change at page 8, line 32 | skipping to change at page 9, line 17 | |||
additional KDFs. KDFs are assigned numbers through IANA following | additional KDFs. KDFs are assigned numbers through IANA following | |||
the policy set in section Section 8. The rules for negotiating a KDF | the policy set in section Section 8. The rules for negotiating a KDF | |||
are as follows: | are as follows: | |||
o If no other KDF is specified the KDF specified in this document | o If no other KDF is specified the KDF specified in this document | |||
MUST be used. This is the "default" KDF. | MUST be used. This is the "default" KDF. | |||
o The initial authenticated key exchange MAY specify a favored KDF. | o The initial authenticated key exchange MAY specify a favored KDF. | |||
For example an EAP method may define a preferred KDF to use in its | For example an EAP method may define a preferred KDF to use in its | |||
specification. If the initial authenticated key exchange | specification. If the initial authenticated key exchange | |||
specifies a KDF then this MUST override the default KDF. | specifies a KDF then this MUST override the default KDF. | |||
o A system MAY specify a separate default KDF if all participants | ||||
within the system have the knowledge of which KDF to use. If | ||||
specified this MUST take precedence over key exchange defined KDF. | ||||
Note that usage definitions MUST NOT concern themselves with the | Note that usage definitions MUST NOT concern themselves with the | |||
details of the KDF construction or the KDF selection, they only need | details of the KDF construction or the KDF selection, they only need | |||
to worry about the inputs specified in Section 3. | to worry about the inputs specified in Section 3. | |||
3.1.2. Default KDF | 3.1.2. Default KDF | |||
The default KDF for deriving root keys from an EMSK is taken from the | The default KDF for deriving root keys from an EMSK is taken from the | |||
PRF+ key expansion specified in [RFC4306] based on HMAC-SHA-256 | PRF+ key expansion specified in [RFC4306] based on HMAC-SHA-256 | |||
[SHA256]. The PRF+ construction was chosen because of its simplicity | [SHA256]. The PRF+ construction was chosen because of its simplicity | |||
skipping to change at page 14, line 17 | skipping to change at page 14, line 35 | |||
this specification may be exported from this boundary. | this specification may be exported from this boundary. | |||
o The EMSK MUST be unique for each EAP 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.1. | derivation as defined in Section 3.1. | |||
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 in accordance with [RFC3748] [I-D.ietf-eap-keying] and other | |||
definitions following this specification MUST NOT use the MSK. If | relevant specifications. This is required for backward | |||
more than one usage uses the MSK, then the cryptographic separation | compatibility. New usage definitions following this specification | |||
is not achieved. Implementations MUST prevent such combinations. | MUST NOT use the MSK. If more than one usage uses the MSK, then the | |||
cryptographic separation is not achieved. Implementations MUST | ||||
prevent such combinations. | ||||
7. Security Considerations | 7. Security Considerations | |||
7.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). | |||
7.2. Cryptographic separation of keys | 7.2. Cryptographic separation of keys | |||
skipping to change at page 15, line 42 | skipping to change at page 16, line 16 | |||
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 Root Key it is important | many keys are going to be derived from an Root Key it is important | |||
that Root Key to child key derivation introduce fresh random numbers | that Root Key to child key derivation introduce fresh random numbers | |||
in deriving each key. | in deriving each key. | |||
8. 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 [RFC5226]. | |||
8.1. 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 MUST be printable US-ASCII strings, and MUST NOT contain | |||
"label-string@specorg" (without the double quotes). | the characters at-sign ("@") except as noted below, comma (","), | |||
whitespace, control characters (ASCII codes 32 or less), or the ASCII | ||||
code 127 (DEL). Labels are case-sensitive, and MUST NOT be longer | ||||
than 64 characters. | ||||
Labels of the form "label-string" registered by the IANA MUST be | Labels can be assigned based on Specification Required policy | |||
printable US-ASCII strings, and MUST NOT contain the characters at- | [RFC5226]. In addition, the labels "experimental1" and | |||
sign ("@"), comma (","), whitespace, control characters (ASCII codes | "experimental2" are reserved for experimental use. The following | |||
32 or less), or the ASCII code 127 (DEL). Labels are case-sensitive, | considerations apply to their use: | |||
and MUST NOT be longer than 64 characters. Labels of this form are | ||||
assigned based on the IETF CONSENSUS policy. | ||||
Labels with the at-sign in them of the form "label-string@specorg" | Production networks do not necessarily support the use of | |||
where the part preceding the at-sign is the label. The format of the | experimental code points. The network scope of support for | |||
part preceding the at-sign is not specified; however, these labels | experimental values should carefully be evaluated before deploying | |||
MUST be printable US-ASCII strings, and MUST NOT contain the comma | any experiment across extended network domains, such as the public | |||
character (","), whitespace, control characters (ASCII codes 32 or | Internet. The potential to disrupt the stable operation of EAP | |||
less), or the ASCII code 127 (DEL). They MUST have only a single at- | devices is a consideration when planning an experiment using such | |||
sign in them. The part following the at-sign MUST be a valid, fully | code points. | |||
qualified Internet domain name [RFC1034] controlled by the person or | ||||
organization defining the label. Labels are case-sensitive, and MUST | ||||
NOT be longer than 64 characters. It is up to each organization how | ||||
it 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 | ||||
resemble STD 11 [RFC0822] addresses and network access identifiers | ||||
(NAI) defined in [RFC4282]. This is purely coincidental and has | ||||
nothing to do with STD 11 [RFC0822] or [RFC4282]. An example of a | ||||
key label is "service@example.com" (without the double quotes). | ||||
Labels within the "ietf.org" organization are assigned based on the | The network administrators should ensure that each code point is used | |||
IETF CONSENSUS policy with specification recommended. Labels from | consistently to avoid interference between experiments. Particular | |||
other organizations may be registered with IANA by the person or | attention should be given to security vulnerabilities and the freedom | |||
organization controlling the domain with an assignment policy of | of different domains to employ their own experiments. Cross-domain | |||
SPECIFICATION REQUIRED. It is RECOMMENDED that the specification | usage is NOT RECOMMENDED. | |||
contain the following information: | ||||
The following labels are reserved by this document: "EMSK", | Similarly, labels "private1" and "private2" have been reserved for | |||
"dsrk@ietf.org". | Private Use within an organization. Again, cross-domain usage of | |||
these labels is NOT RECOMMENDED. | ||||
Labels starting with a string and followed by the "@" and a valid, | ||||
fully qualified Internet domain name [RFC1034] can be requested by by | ||||
the person or organization who are in control of the domain name. | ||||
Such labels can be allocated based on Specification Required. It is | ||||
RECOMMENDED that the specification 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 | |||
The following labels are reserved by this document: "EMSK", | ||||
"dsrk@ietf.org". | ||||
8.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) | |||
9. 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, Russ Housley, Glen | Avi Lior, David McGrew, Henry Haverinen, Hao Zhou, Russ Housley, Glen | |||
Zorn, Charles Clancy, Dan Harkins, Alan DeKok, Yoshi Ohba and members | Zorn, Charles Clancy, Dan Harkins, Alan DeKok, Yoshi Ohba and members | |||
of the EAP and HOKEY working groups. | of the EAP and HOKEY working groups. | |||
Thanks to Dan Harkins for the idea of using a single root key name to | Thanks to Dan Harkins for the idea of using a single root key name to | |||
refer to all keys. | refer to all keys. | |||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[I-D.ietf-eap-keying] | ||||
Aboba, B., Simon, D., and P. Eronen, "Extensible | ||||
Authentication Protocol (EAP) Key Management Framework", | ||||
draft-ietf-eap-keying-22 (work in progress), | ||||
November 2007. | ||||
[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 | ||||
IANA Considerations Section in RFCs", BCP 26, RFC 2434, | ||||
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. | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | ||||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | ||||
May 2008. | ||||
[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] | ||||
Aboba, B., Simon, D., and P. Eronen, "Extensible | ||||
Authentication Protocol (EAP) Key Management Framework", | ||||
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. | |||
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The | [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The | |||
Network Access Identifier", RFC 4282, December 2005. | Network Access Identifier", RFC 4282, December 2005. | |||
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security | [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
skipping to change at page 19, line 44 | skipping to change at line 898 | |||
attempt made to obtain a general license or permission for the use of | attempt made to obtain a general license or permission for the use of | |||
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. | |||
Acknowledgment | ||||
Funding for the RFC Editor function is provided by the IETF | ||||
Administrative Support Activity (IASA). | ||||
End of changes. 27 change blocks. | ||||
100 lines changed or deleted | 136 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |