--- 1/draft-ietf-hokey-emsk-hierarchy-04.txt 2008-04-23 18:12:23.000000000 +0200 +++ 2/draft-ietf-hokey-emsk-hierarchy-05.txt 2008-04-23 18:12:23.000000000 +0200 @@ -1,23 +1,23 @@ Network Working Group J. Salowey Internet-Draft Cisco Systems Intended status: Standards Track L. Dondeti -Expires: August 27, 2008 V. Narayanan +Expires: October 24, 2008 V. Narayanan Qualcomm, Inc M. Nakhjiri Motorola - February 24, 2008 + April 22, 2008 Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) - draft-ietf-hokey-emsk-hierarchy-04.txt + draft-ietf-hokey-emsk-hierarchy-05.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,66 +28,70 @@ 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 August 27, 2008. + This Internet-Draft will expire on October 24, 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 - more purposes identified as usage definitions. This memo specifies a - 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 + The Extensible Authentication Protocol (EAP) defined the Extended + Master Session Key (EMSK) generation, but reserved it for unspecified + 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 + for multiple purposes, identified by usage definitions. This + document also specifies a mechanism for avoiding conflicts between + root keys by deriving them in a manner that guarantee cryptographic + separation. Finally, this document also defines one such root key + usage: domain specific root keys are 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 + 1.1. Applicable usages of keys derived from the EMSK . . . . . 3 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Cryptographic Separation and Coordinated Key Derivation . . . 5 3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 6 - 3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 6 - 3.1.1. On the KDFs . . . . . . . . . . . . . . . . . . . . . 7 + 3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 7 + 3.1.1. On the KDFs . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . 11 - 5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 11 + 4. Domain Specific Root Key Derivation . . . . . . . . . . . . . 10 + 4.1. Applicability of Multi-Domain usages . . . . . . . . . . . 11 + 5. Requirements for Usage Definitions . . . . . . . . . . . . . . 12 + 5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 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. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 14 + 7.2. Cryptographic separation of keys . . . . . . . . . . . . . 14 + 7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 14 7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 14 - 7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 14 - 7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 14 + 7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 15 + 7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 15 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 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 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 @@ -100,43 +104,63 @@ 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 - developed independently from one another. The goal is to have + Specific Root Keys (USRK) are used, see the following section for + discussion of applicable usages. It does define a framework for the + derivation of USRKs for different purposes such that different usages + can be developed independently from one another. The goal is to have security properties of one usage have minimal or no effect on the security properties of 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 is coordinated key derivation and another is cryptographic separation. -1.1. Terminology +1.1. Applicable usages of keys derived from the EMSK + + The EMSK is established as part of network access authentication and + authorization. The derived keys need to be distributed to the + involved parties along with context necessary to use them. The + security of the system relies upon trust relationships between the + parties involved in this process. These trust relationships are the + basis for applying protection during key transport and ensuring + 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 + access occurs over an EAP-capable interface. If it is possible for + an entity to access these services though an interface that does not + involve EAP authentication and authorization with the appropriate + entities then alternate means of authentication and key establishment + for these services needs to be provided. + +1.2. 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 @@ -451,20 +475,36 @@ 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. +4.1. Applicability of Multi-Domain usages + + When a DSRK is distributed to a domain the domain can generate any + DSUSRKs it wishes. This keys can be used to authorize entities in a + domain to perform specific functions. In cases where it is + appropriate for only a specific domain to be authorized to perform a + function the usage SHOULD NOT be defined as multi-domain. + + In some cases only certain domains are authorized for a particular + Multi-Domain usage. In this case domains that do not have full + authorization should not receive the DSRK and should only receive + DSUSRKs for the usages which they are authorized. If it is possible + for a peer to know which domains are authorized for a particular + usage without relying on restricting access to the DSRK to specific + domains then this recommendation may be relaxed. + 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 @@ -483,21 +523,21 @@ 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 + It is RECOMMENDED that the Root Key is only used for deriving child keys. A usage definition must specify how and when the derivation of child keys should be done. It is RECOMMENDED that usages following similar considerations for key derivation are as outlined in this document for the Root Key derivation with respect to cryptographic separation and key reuse. In addition, usages should take into consideration the number of keys that will be derived from the Root Key and ensure that enough entropy is introduced in the derivation to support this usage. It is desirable that the entropy is provided by the two parties that derive the child key.