--- 1/draft-ietf-hokey-emsk-hierarchy-03.txt 2008-02-24 22:12:14.000000000 +0100 +++ 2/draft-ietf-hokey-emsk-hierarchy-04.txt 2008-02-24 22:12:15.000000000 +0100 @@ -1,23 +1,23 @@ Network Working Group J. Salowey Internet-Draft Cisco Systems Intended status: Standards Track L. Dondeti -Expires: July 12, 2008 V. Narayanan +Expires: August 27, 2008 V. Narayanan Qualcomm, Inc M. Nakhjiri Motorola - January 9, 2008 + February 24, 2008 Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) - draft-ietf-hokey-emsk-hierarchy-03.txt + draft-ietf-hokey-emsk-hierarchy-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -28,21 +28,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on July 12, 2008. + This Internet-Draft will expire on August 27, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract An Extended Master Session Key (EMSK) is a cryptographic key generated from an Extensible Authentication Protocol (EAP) exchange reserved solely for the purpose of deriving master keys for one or @@ -50,61 +50,63 @@ mechanism for avoiding conflicts between root keys by deriving cryptographically separate keys from the EMSK. This document also describes a usage for domain specific root keys made available to and used within specific key management domains. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Cryptographic Separation and Coordinated Key Derivation . . . 4 - 3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 5 + 3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 6 3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. The USRK Derivation Function . . . . . . . . . . . . . . . 7 - 3.3. Default PRF . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.4. Key Naming and Usage Data . . . . . . . . . . . . . . . . 8 + 3.1.1. On the KDFs . . . . . . . . . . . . . . . . . . . . . 7 + 3.1.2. Default KDF . . . . . . . . . . . . . . . . . . . . . 8 + 3.2. EMSK and USRK Name Derivation . . . . . . . . . . . . . . 9 4. Domain Specific Root Key Derivation . . . . . . . . . . . . . 9 - 5. Requirements for Usage Definitions . . . . . . . . . . . . . . 10 + 5. Requirements for Usage Definitions . . . . . . . . . . . . . . 11 5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 11 - 6. Requirements for EAP System . . . . . . . . . . . . . . . . . 12 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 12 - 7.2. Cryptographic separation of keys . . . . . . . . . . . . . 12 + 6. Requirements for EAP System . . . . . . . . . . . . . . . . . 13 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 13 + 7.2. Cryptographic separation of keys . . . . . . . . . . . . . 13 7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 13 - 7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 13 - 7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 13 - 7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 13 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 14 - 8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 15 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 - Intellectual Property and Copyright Statements . . . . . . . . . . 18 + 7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 14 + 7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 14 + 7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 14 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 15 + 8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 16 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 + Intellectual Property and Copyright Statements . . . . . . . . . . 19 1. Introduction This document deals with keys generated by authenticated key exchange mechanisms defined within the EAP framework [RFC3748]. EAP defines two types of keying material; a Master Session Key (MSK) and an Extended Master Session Key (EMSK). The EAP specification implicitly 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 future use. This document defines the EMSK to be used solely for deriving root keys using the key derivation specified. The root keys - are meant either for specific purposes called usages. This document - also provides guidelines for creating usage definitions for the - various uses of EAP key material and for the management of the root - keys. In this document, the terms application and usage (or "usage - definition") refer to a specific use case of the EAP keying material. + are meant for specific purposes called usages; a special usage class + is the domain specific root keys made available to and used within + specific key management domains. This document also provides + guidelines for creating usage definitions for the various uses of EAP + key material and for the management of the root keys. In this + document, the terms application and usage (or "usage definition") + refer to a specific use case of the EAP keying material. Different uses for keys derived from the EMSK have been proposed. Some examples include hand off across access points in various mobile technologies, mobile IP authentication and higher layer application authentication. In order for a particular usage of EAP key material to make use of this specification it must specify a so-called usage definition. This document does not define how the derived Usage Specific Root Keys (USRK) should be used or discuss what types of use cases are valid. It does define a framework for the derivation of USRKs for different purposes such that different usages can be @@ -112,30 +114,29 @@ security properties of one usage have minimal or no effect on the security properties of other usages. This document does define a special class of USRK, called a Domain Specific Root Key (DSRK) for use in deriving keys specific to a key management domain. Each DSRK is a root key used to derive Domain Specific Usage Specific Root Keys (DSUSRK). The DSUSRKs are USRKs specific to a particular key management domain. 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 separation. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] - The following terms are taken from [RFC3748]: EAP Server, peer, authenticator, Master Session Key (MSK), Extended Master Session Key (EMSK), Cryptographic Separation. Usage Definition An application of cryptographic key material to provide one or more security functions such as authentication, authorization, encryption or integrity protection for related applications or services. This document provides guidelines and recommendations for what should be included in usage definitions. This document @@ -132,21 +133,21 @@ The following terms are taken from [RFC3748]: EAP Server, peer, authenticator, Master Session Key (MSK), Extended Master Session Key (EMSK), Cryptographic Separation. Usage Definition An application of cryptographic key material to provide one or more security functions such as authentication, authorization, encryption or integrity protection for related applications or services. This document provides guidelines and recommendations 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 constraints on the types of use cases or services that create usage definitions. Usage Specific Root Key (USRK) Keying material derived from the EMSK for a particular usage definition. It is used to derive child keys in a way defined by its usage definition. Key Management Domain A key management domain is specified by the scope of a given root key. The scope is the collection of systems authorized to access @@ -228,21 +229,21 @@ derived from the root key for various purposes, including encryption, integrity protection, entity authentication by way of proof of possession, and subsequent key derivation. A root key is derived from the EMSK for specific set of uses set forth in a usage definition described in Section 5. The basic EMSK root key hierarchy looks as follows: EMSK / \ - USRK USRK + USRK1 USRK2 This document defines how to derive usage specific root keys (USRK) from the EMSK and also defines a specific USRK called a domain specific root key (DSRK). DSRK are root keys restricted to use in a particular key management 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 are outside scope of this document. The key hierarchy looks as follows: @@ -252,212 +253,242 @@ / \ 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 | "\0" | optional data | length) + + Where: + + | denotes concatenation + "\0" is a NULL octet (0x00 in hex) + length is a 2 octet unsigned integer in network byte order 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 octets. 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 Root Key. 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 Root Keys be at - least 64 octets long. + the allocation of these labels are given in Section 8. - A usage definition requiring derivation of a Root Key must specify - all the inputs (other than EMSK) to the key derivation function. + The NULL octet after the key label is used to avoid collisions if one + key label is a prefix of another label (e.g. "foobar" and + "foobarExtendedV2"). This is considered a simpler solution than + requiring a key label assignment policy that prevents prefixes from + occurring. -3.2. The USRK Derivation Function + 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. Usage definitions MAY use the EAP session-ID + [I-D.ietf-eap-keying] in the specification of the optional data + parameter that go into the KDF function. This provides the advantage + of providing data into the key derivation that is unique to the + session that generated the keys. - The USRK key derivation function is based on a pseudo random function - (PRF) that has the following function prototype: + The KDF must be able to process input keys of up to 256 bytes. It + may do this by providing a mechanism for "hashing" long keys down to + a suitable size that can be consumed by the underlying derivation + algorithm. - KDF = PRF(key, data) + The length is a 2-octet 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 Root Keys be at least 64 octets long. - where: + A usage definition requiring derivation of a Root Key must specify + all the inputs (other than EMSK) to the key derivation function. - key = EMSK - data = label + "\0" + op-data + length - label = ASCII key label - op-data = optional data - length = 2 byte unsigned integer in network byte order - '\0' = is a NULL byte (0x00 in hex) - + denotes concatenation + USRKs MUST be at least 64 octets in length. - 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 - "foobarExtendedV2"). This is considered a simpler solution than - requiring a key label assignment policy that prevents prefixes from - occurring. +3.1.1. On the KDFs - This specification allows for the use of different PRFs. However, in - order to have a coordinated key derivation function the same PRF + This specification allows for the use of different KDFs. However, in + order to have a coordinated key derivation function the same KDF function MUST be used for all key derivations for a given EMSK. If - no PRF is specified, then the default PRF specified in Section 3.3 + no KDF is specified, then the default KDF specified in Section 3.1.2 MUST be used. A system may provide the capability to negotiate - additional PRFs. PRFs are assigned numbers through IANA following - the policy set in section Section 8. The rules for negotiating a PRF + additional KDFs. KDFs are assigned numbers through IANA following + the policy set in section Section 8. The rules for negotiating a KDF are as follows: - o If no other PRF is specified the PRF specified in this document - MUST be used. This is the "default" 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 + o If no other KDF is specified the KDF specified in this document + MUST be used. This is the "default" 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 specification. If the initial authenticated key exchange - specifies a PRF then this MUST override the default PRF. - - o A system MAY specify a separate default PRF if all participants - within the system have the knowledge of which PRF to use. If - specified this MUST take precedence over key exchange defined PRF. + 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 - details of the PRF construction or the PRF 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. -3.3. Default PRF +3.1.2. Default KDF - 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]. - The prf+ construction was chosen because of its simplicity and - efficiency over other PRFs such as those used in [RFC4346]. The - motivation for the design of this PRF is described in [SIGMA]. 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 + [SHA256]. The PRF+ construction was chosen because of its simplicity + and efficiency over other mechanisms such as those used in [RFC4346]. + The motivation for the design of PRF+ is described in [SIGMA]. The definition of PRF+ from [RFC4306]is given below: - prf+ (K,S) = T1 | T2 | T3 | T4 | ... + PRF+ (K,S) = T1 | T2 | T3 | T4 | ... Where: - T1 = prf (K, S | 0x01) - T2 = prf (K, T1 | S | 0x02) - T3 = prf (K, T2 | S | 0x03) - T4 = prf (K, T3 | S | 0x04) + T1 = PRF (K, S | 0x01) + T2 = PRF (K, T1 | S | 0x02) + T3 = PRF (K, T2 | S | 0x03) + T4 = PRF (K, T3 | S | 0x04) 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.2. - 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 - 8160 bytes of key material. + The key, K, is the EMSK and S is the concatenation of key label, the + NULL octet, optional data and length defined in Section 3.1. 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 8160 + octets of key material. -3.4. Key Naming and Usage Data +3.2. EMSK and USRK Name Derivation - 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 - identify the exchange and the keys derived by the exchange. The EAP - 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 - on the Session-ID in [I-D.ietf-eap-keying] is RECOMMENDED. + The EAP keying framework [I-D.ietf-eap-keying] specifies that the + EMSK MUST be named using the EAP Session-Id and a binary or textual + indication. Following that requirement, the EMSK name SHALL be + derived as follows: - It is RECOMMENDED that each USRK has a name derived as follows: + EMSKname = KDF ( EAP Session-ID, "EMSK" | "\0" | length ) - USRK Name = SHA-256-64 ( EAP Session-ID | key-label ) + Where: - where SHA-256-64 is the first 64 bits from the SHA-256 output + | denotes concatenation + "EMSK" consists of the 4 ASCII values for the letters + "\0" = is a NULL octet (0x00 in hex) + length is the 2 octet unsigned integer 8 in network byte order - Usage definitions MAY use the EAP session-ID in the specification of - the optional data parameter that go into the KDF function. This - provides the advantage of providing data into the key derivation that - is unique to the session that generated the keys. + It is RECOMMENDED that all keys derived from the EMSK are referred to + by the EMSKname and the context of the descendant key usage. This is + the default behavior. Any exceptions SHALL be signaled by individual + usages. + + USRKs MAY be named explicitly with a name derivation specified as + follows: + + USRKName = + KDF(EAP Session-ID, key label|"\0"|optional data|length) + + Where: + + key label and optional data MUST be the same as those used + in the corresponding USRK derivation + length is the 2 octet unsigned integer 8 in network byte order + + USRKName derivation and usage is applicable when there is ambiguity + in the referencing the keys using the EMSKname and the associated + context of the USRK usage. The usage SHALL signal such an exception + in key naming, so both parties know the key name used. 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 key management domain. Usages derive specific keys for specific services from this DSRK. The DSRK may be distributed to a key management domain for a specific set of usages so keys can be derived within the key management domain for those usages. DSRK based usages will follow a key hierarchy similar to the following: EMSK / \ / \ + / \ + / \ DSRK1 DSRK2 / \ / \ - / \ DSUSRK21 DSUSRK22 - DSUSRK11 DSUSRK12 + / \ / \ + DSUSRK11 DSUSRK12 DSUSRK21 DSUSRK22 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 key management domain that - the root key is being derived for. The DSRK is MUST be 64 octets - long. + the root key is being derived for. The DSRK MUST be at least 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) + DSUSRK = KDF(DSRK, key label | "\0" | 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 + definition within a DSRK usage and are a maximum of 255 octets. 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 + constant during the execution of the KDF. The length is a 2-octet 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 at least 64 octets long. - It is RECOMMENDED that each DSUSRK has a name derived as follows: - - DSUSRK Name = SHA-256-64( DSRK Name | key-label ) - - where SHA-256-64 is the first 64 bits from the SHA-256 output - Usages that make use of the DSRK must define how the peer learns the domain label to use in a particular derivation. A multi-domain usage must define how both DSRKs and specific DSUSRKs are transported to different key management domains. Note that usages may define alternate ways to constrain specific keys to particular key management domains. + To facilitate the use of EMSKname to refer to keys derived from + DSRKs, EMSKname SHOULD be sent along with the DSRK. The exception is + when a DSRKname is expected to be used. The usage SHALL signal such + an exception in key naming, so both parties know the key name used. + + DSUSRKs MAY be named explicitly with a name derivation specified as + follows: + + DSUSRKName = + KDF(EMSKName,key label | "\0" | optional data | length) + + where length is the 2 octet unsigned integer 8 in network byte order. + 5. Requirements for Usage Definitions In order for a usage definition to meet the guidelines for USRK usage 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 to derive Root Keys using the key derivation specified in Section 3 of this document. They MUST NOT use the EMSK directly. o The usage definition SHOULD NOT require caching of the EMSK. It is RECOMMENDED that the Root Key derived specifically for the usage definition rather than the EMSK should be used to derive child keys for specific cryptographic operations. o Usage definition MUST define distinct key labels and optional data used in the key derivation described in Section 3. Usage definitions are encouraged to use the key name described in - Section 3.4 and include additional data in the optional data to + Section 3.2 and include additional data in the optional data to provide additional entropy. o Usage definitions MUST define the length of their Root Keys. It is RECOMMENDED that the Root Keys be at least as long as the EMSK (at least 64 octets). o Usage definitions MUST define how they use their Root Keys. This includes aspects of key management covered in the next section on Root Key Management guidelines. - o 5.1. Root Key Management Guidelines This section makes recommendations for various aspects of key management of the Root Key including lifetime, child key derivation, caching and transport. It is RECOMMENDED that the Root Key only used for deriving child keys. A usage definition must specify how and when the derivation of @@ -484,26 +515,28 @@ Recall that the EMSK never leaves the EAP peer and server. That also holds true for some Root Keys; however, some Root Keys may be provided to other entities for child key derivation and delivery. Each usage definition specification will specify delivery caching and/or delivery procedures. Note that the purpose of the key derivation in Section 3 is to ensure that Root Keys are cryptographically separate from each other and the EMSK. In other words, given a Root Key, it is computationally infeasible to derive the EMSK, any other Root Keys, or child keys associated with other Root Keys. In addition to the Root Key, several other parameters may - need to be sent. Root Key name should be derived using the EAP - Session ID, and thus the key name needs to be sent along with the - key. When Root Keys are delivered to another entity, the lifetime - associated with the specific root keys MUST also be transported to - that entity. Recommendations for transporting keys are discussed in - the security considerations (Section 7.4). + need to be sent. + + Root Key names may be derived using the EAP Session ID, and thus the + key name may need to be sent along with the key. When Root Keys are + delivered to another entity, the EMSKname and the lifetime associated + with the specific root keys MUST also be transported to 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 entities. This can be done through the inclusion of usage parameters and identities in the child key derivation. Some of this data is described as "channel bindings" in [RFC3748]. 6. Requirements for EAP System The system that wishes to make use of EAP root keys derived from the EMSK must take certain things into consideration. The following is a @@ -515,21 +548,21 @@ authentication mechanism protocol exchange. o The EMSK MUST be maintained within a protected location inside the entity where it is generated. Only root keys derived according to this specification may be exported from this boundary. o The EMSK MUST be unique for each EAP session o The EAP method MUST provide an identifier for the EAP transaction that generated the key o The system MUST define which usage definitions are used and how they are invoked. o The system may define ways to select an alternate PRF for key - derivation as defined in Section 3.2. + derivation as defined in Section 3.1. The system MAY use the MSK transmitted to the NAS in any way it chooses. This is required for backward compatibility. New usage definitions following this specification 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.1. Key strength @@ -632,20 +665,23 @@ 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 IETF CONSENSUS policy with specification recommended. Labels from other organizations may be registered with IANA by the person or organization controlling the domain with an assignment policy of SPECIFICATION REQUIRED. It is RECOMMENDED that the specification contain the following information: + The following labels are reserved by this document: "EMSK", + "dsrk@ietf.org". + o A description of the usage o The key label to be used o Length of the Root Key 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 be used 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 communicated if necessary @@ -657,22 +693,26 @@ range 221 to 255 are left for PRIVATE USE. The initial registry should contain the following values: 0 RESERVED 1 HMAC-SHA-256 PRF+ (Default) 9. Acknowledgements This document expands upon previous collaboration with Pasi Eronen. This document reflects conversations with Bernard Aboba, Jari Arkko, - Avi Lior, David McGrew, Henry Haverinen, Hao Zhou and members of the - EAP working group. + Avi Lior, David McGrew, Henry Haverinen, Hao Zhou, Russ Housley, Glen + Zorn, Charles Clancy, Dan Harkins, Alan DeKok, Yoshi Ohba and members + of the EAP and HOKEY working groups. + + Thanks to Dan Harkins for the idea of using a single root key name to + refer to all keys. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 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,