--- 1/draft-ietf-hokey-emsk-hierarchy-02.txt 2008-01-10 03:12:11.000000000 +0100 +++ 2/draft-ietf-hokey-emsk-hierarchy-03.txt 2008-01-10 03:12:11.000000000 +0100 @@ -1,23 +1,23 @@ Network Working Group J. Salowey Internet-Draft Cisco Systems Intended status: Standards Track L. Dondeti -Expires: May 21, 2008 V. Narayanan +Expires: July 12, 2008 V. Narayanan Qualcomm, Inc M. Nakhjiri Motorola - November 18, 2007 + January 9, 2008 Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) - draft-ietf-hokey-emsk-hierarchy-02.txt + draft-ietf-hokey-emsk-hierarchy-03.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,43 +28,43 @@ 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 May 21, 2008. + This Internet-Draft will expire on July 12, 2008. Copyright Notice - Copyright (C) The IETF Trust (2007). + 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 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 . . . . . . . . . . . . . . 6 + 3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 5 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 4. Domain Specific Root Key Derivation . . . . . . . . . . . . . 9 5. Requirements for Usage Definitions . . . . . . . . . . . . . . 10 5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 11 6. Requirements for EAP System . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 12 @@ -141,31 +141,29 @@ for what should be included in usage definitions. This document does not place any constrains 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 a collection of systems that share the - same access to key material. A single administrative domain may - contain several key management domains in order to contain the - scope of key material to a group of related systems. A entity - that is not a member of a key management domain must not make use - of key material for that domain. Only the domain where the key - material is originated may derive key material from the EMSK for - other domains. In the case where key material is distributed to - another domain, intermediate systems may have access to see the - key material during the key distribution process, but they must - not make use of the key material. + A key management domain is specified by the scope of a given root + key. The scope is the collection of systems authorized to access + key material derived from that key. Systems within a key + management domain may be authorized to (1) derive key materials, + (2) use key materials, or (3) distribute key materials to other + systems in the same domain. A derived key's scope is constrained + to a subset of the scope of the key it is derived from. In this + document the term domain refers to a key management domain unless + otherwise qualified. Domain Specific Root Key (DSRK) Keying material derived from the EMSK that is restricted to use in a specific key management 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. @@ -325,21 +323,21 @@ Note that usage definitions MUST NOT concern themselves with the details of the PRF construction or the PRF selection, they only need to worry about the inputs specified in Section 3. 3.3. Default PRF 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 [RFC2246]. The + efficiency over other PRFs such as those used in [RFC4346]. The motivation for the design of this PRF is described in [SIGMA]. The definition of PRF+ from [RFC4306]is given below: 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) @@ -369,21 +367,21 @@ 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. 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 an key management + 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 @@ -417,21 +415,21 @@ 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 managment domains. Note that usages may define + different key management domains. Note that usages may define alternate ways to constrain specific keys to particular key management domains. 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 @@ -699,26 +697,26 @@ 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 text messages", STD 11, RFC 822, August 1982. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. - [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", - RFC 2246, January 1999. - [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. + [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.1", RFC 4346, April 2006. + [SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols", LNCS 2729, Springer, 2003. Available at http://www.informatik.uni-trier.de/~ley/db/ conf/crypto/crypto2003.html Authors' Addresses Joseph Salowey @@ -735,21 +733,21 @@ Email: vidyan@qualcomm.com Madjid Nakhjiri Motorola Email: madjid.nakhjiri@motorola.com Full Copyright Statement - Copyright (C) The IETF Trust (2007). + Copyright (C) The IETF Trust (2008). 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