--- 1/draft-ietf-hokey-emsk-hierarchy-05.txt 2008-06-23 11:13:36.000000000 +0200 +++ 2/draft-ietf-hokey-emsk-hierarchy-06.txt 2008-06-23 11:13:36.000000000 +0200 @@ -1,23 +1,23 @@ Network Working Group J. Salowey Internet-Draft Cisco Systems -Intended status: Standards Track L. Dondeti -Expires: October 24, 2008 V. Narayanan - Qualcomm, Inc - M. Nakhjiri - Motorola - April 22, 2008 +Updates: eap-keying (RFC Ed to L. Dondeti +replace this with RFC number) V. Narayanan +(if approved) Qualcomm, Inc +Intended status: Standards Track M. Nakhjiri +Expires: December 25, 2008 Motorola + June 23, 2008 Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) - draft-ietf-hokey-emsk-hierarchy-05.txt + draft-ietf-hokey-emsk-hierarchy-06 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,71 +28,67 @@ 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 October 24, 2008. - -Copyright Notice - - Copyright (C) The IETF Trust (2008). + This Internet-Draft will expire on December 25, 2008. Abstract 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. 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 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Cryptographic Separation and Coordinated Key Derivation . . . 6 + 3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 7 3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 7 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 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.1. Root Key Management Guidelines . . . . . . . . . . . . . . 12 - 6. Requirements for EAP System . . . . . . . . . . . . . . . . . 13 + 5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 13 + 6. Requirements for EAP System . . . . . . . . . . . . . . . . . 14 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.2. Cryptographic separation of keys . . . . . . . . . . . . . 15 + 7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 15 + 7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 15 7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 15 - 7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 15 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 15 - 8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 16 + 7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 16 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 16 + 8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 - Intellectual Property and Copyright Statements . . . . . . . . . . 19 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 + Intellectual Property and Copyright Statements . . . . . . . . . . 20 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 @@ -124,36 +120,76 @@ 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. 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. + The EMSK is typically established as part of network access + authentication and authorization. It is expected that keys derived + from EMSK will be used in protocols related to network access, such + as handover optimizations, and the scope of these protocols is + usually restricted to the endpoints of the lower layers over which + EAP packets are sent. - 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. + In particular, it is inappropriate for the security of higher layer + applications to solely rely on keys derived from network access + authentication. Even when used together with another, independent + security mechanism, the use of these keys needs to be carefully + evaluated with regards to the benefits of the optimization and the + 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 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. @@ -338,23 +374,20 @@ 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 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 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 KDF construction or the KDF selection, they only need to worry about the inputs specified in Section 3. 3.1.2. Default KDF 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 @@ -592,24 +625,26 @@ 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.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. + chooses in accordance with [RFC3748] [I-D.ietf-eap-keying] and other + relevant specifications. 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 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 mechanism). 7.2. Cryptographic separation of keys @@ -665,127 +700,128 @@ 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 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 that Root Key to child key derivation introduce fresh random numbers in deriving each key. 8. IANA Considerations - The keywords "PRIVATE USE", "SPECIFICATION REQUIRED" and "IETF - CONSENSUS" that appear in this document when used to describe - namespace allocation are to be interpreted as described in [RFC2434]. + The keywords "Private Use", "Specification Required" and "IETF + Consensus" that appear in this document when used to describe + namespace allocation are to be interpreted as described in [RFC5226]. 8.1. Key Labels This specification introduces a new name space for "USRK key labels". - Key labels are of one of two formats: "label-string" or - "label-string@specorg" (without the double quotes). + Key labels MUST be printable US-ASCII strings, and MUST NOT contain + 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 - printable US-ASCII strings, and MUST NOT contain the characters at- - sign ("@"), 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 this form are - assigned based on the IETF CONSENSUS policy. + Labels can be assigned based on Specification Required policy + [RFC5226]. In addition, the labels "experimental1" and + "experimental2" are reserved for experimental use. The following + considerations apply to their use: - 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 - part preceding the at-sign is not specified; however, these labels - MUST be printable US-ASCII strings, and MUST NOT contain the comma - character (","), whitespace, control characters (ASCII codes 32 or - 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 - 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). + Production networks do not necessarily support the use of + experimental code points. The network scope of support for + experimental values should carefully be evaluated before deploying + any experiment across extended network domains, such as the public + Internet. The potential to disrupt the stable operation of EAP + devices is a consideration when planning an experiment using such + code points. - 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 network administrators should ensure that each code point is used + consistently to avoid interference between experiments. Particular + attention should be given to security vulnerabilities and the freedom + of different domains to employ their own experiments. Cross-domain + usage is NOT RECOMMENDED. - The following labels are reserved by this document: "EMSK", - "dsrk@ietf.org". + Similarly, labels "private1" and "private2" have been reserved for + 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 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 + The following labels are reserved by this document: "EMSK", + "dsrk@ietf.org". + 8.2. PRF numbers This specification introduces a new number space for "EMSK PRF 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 - range 221 to 255 are left for PRIVATE USE. The initial registry + 220 are assigned through the policy IETF Consensus and numbers in the + 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, 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 + [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 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. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 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 Hash Standard", FIPS 180-2, August 2002. With Change Notice 1 dated February 2004 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 text messages", STD 11, RFC 822, August 1982. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [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 @@ -852,15 +888,10 @@ attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA).