idnits 2.17.1 draft-ietf-hokey-emsk-hierarchy-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 878. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 889. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 896. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 902. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 23, 2008) is 5785 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC0822' is defined on line 823, but no explicit reference was found in the text == Unused Reference: 'RFC4282' is defined on line 829, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA256' -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Salowey 3 Internet-Draft Cisco Systems 4 Updates: eap-keying (RFC Ed to L. Dondeti 5 replace this with RFC number) V. Narayanan 6 (if approved) Qualcomm, Inc 7 Intended status: Standards Track M. Nakhjiri 8 Expires: December 25, 2008 Motorola 9 June 23, 2008 11 Specification for the Derivation of Root Keys from an Extended Master 12 Session Key (EMSK) 13 draft-ietf-hokey-emsk-hierarchy-07 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 25, 2008. 40 Abstract 42 The Extensible Authentication Protocol (EAP) defined the Extended 43 Master Session Key (EMSK) generation, but reserved it for unspecified 44 future uses. This memo reserves the EMSK for the sole purpose of 45 deriving root keys. Root keys are are master keys that can be used 46 for multiple purposes, identified by usage definitions. This 47 document also specifies a mechanism for avoiding conflicts between 48 root keys by deriving them in a manner that guarantee cryptographic 49 separation. Finally, this document also defines one such root key 50 usage: domain specific root keys are root keys made available to and 51 used within specific key management domains. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Applicable usages of keys derived from the EMSK . . . . . 3 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Cryptographic Separation and Coordinated Key Derivation . . . 6 59 3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 7 60 3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 7 61 3.1.1. On the KDFs . . . . . . . . . . . . . . . . . . . . . 8 62 3.1.2. Default KDF . . . . . . . . . . . . . . . . . . . . . 9 63 3.2. EMSK and USRK Name Derivation . . . . . . . . . . . . . . 9 64 4. Domain Specific Root Key Derivation . . . . . . . . . . . . . 10 65 4.1. Applicability of Multi-Domain usages . . . . . . . . . . . 12 66 5. Requirements for Usage Definitions . . . . . . . . . . . . . . 12 67 5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 13 68 6. Requirements for EAP System . . . . . . . . . . . . . . . . . 14 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 14 71 7.2. Cryptographic separation of keys . . . . . . . . . . . . . 15 72 7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 15 73 7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 15 74 7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 15 75 7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 16 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 16 78 8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 17 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 84 Intellectual Property and Copyright Statements . . . . . . . . . . 20 86 1. Introduction 88 This document deals with keys generated by authenticated key exchange 89 mechanisms defined within the EAP framework [RFC3748]. EAP defines 90 two types of keying material; a Master Session Key (MSK) and an 91 Extended Master Session Key (EMSK). The EAP specification implicitly 92 assumes that the MSK produced by EAP will be used for a single 93 purpose at a single device, however it does reserve the EMSK for 94 future use. This document defines the EMSK to be used solely for 95 deriving root keys using the key derivation specified. The root keys 96 are meant for specific purposes called usages; a special usage class 97 is the domain specific root keys made available to and used within 98 specific key management domains. This document also provides 99 guidelines for creating usage definitions for the various uses of EAP 100 key material and for the management of the root keys. In this 101 document, the terms application and usage (or "usage definition") 102 refer to a specific use case of the EAP keying material. 104 Different uses for keys derived from the EMSK have been proposed. 105 Some examples include hand off across access points in various mobile 106 technologies, mobile IP authentication and higher layer application 107 authentication. In order for a particular usage of EAP key material 108 to make use of this specification it must specify a so-called usage 109 definition. This document does not define how the derived Usage 110 Specific Root Keys (USRK) are used, see the following section for 111 discussion of applicable usages. It does define a framework for the 112 derivation of USRKs for different purposes such that different usages 113 can be developed independently from one another. The goal is to have 114 security properties of one usage have minimal or no effect on the 115 security properties of other usages. 117 This document does define a special class of USRK, called a Domain 118 Specific Root Key (DSRK) for use in deriving keys specific to a key 119 management domain. Each DSRK is a root key used to derive Domain 120 Specific Usage Specific Root Keys (DSUSRK). The DSUSRKs are USRKs 121 specific to a particular key management domain. 123 In order to keep root keys for specific purposes separate from one 124 another, two requirements are defined in the following sections. One 125 is coordinated key derivation and another is cryptographic 126 separation. 128 1.1. Applicable usages of keys derived from the EMSK 130 The EMSK is typically established as part of network access 131 authentication and authorization. It is expected that keys derived 132 from EMSK will be used in protocols related to network access, such 133 as handover optimizations, and the scope of these protocols is 134 usually restricted to the endpoints of the lower layers over which 135 EAP packets are sent. 137 In particular, it is inappropriate for the security of higher layer 138 applications to solely rely on keys derived from network access 139 authentication. Even when used together with another, independent 140 security mechanism, the use of these keys needs to be carefully 141 evaluated with regards to the benefits of the optimization and the 142 need to support multiple solutions. Performance optimizations may 143 not warrant the close tie-in that may be required between the layers 144 in order to use EAP-based keys. Such optimizations may be offset by 145 the complexities of managing the validity and usage of key materials. 146 Keys generated from subsequent EAP authentications may be beyond the 147 knowledge and control of applications. 149 From an architectural point of view, applications should not make 150 assumptions about the lower layer technology (such as network access 151 authentication) used on any particular hop along the path between the 152 application endpoints. 154 From a practical point of view, making such assumptions would 155 complicate using those applications over lower layers that do not use 156 EAP, and make it more difficult for applications and network access 157 technologies to evolve independently of each other. 159 Parties using keys derived from EMSK also need trust relationships 160 with the EAP endpoints, and mechanisms for securely communicating the 161 keys. 163 For most applications, it is not appropriate to assume that all 164 current and future access networks are trusted to secure the 165 application function. Instead, applications should implement the 166 required security mechanisms in access independent manner. 168 Implementation considerations may also complicate communication of 169 keys to an application from the lower layer. For instance, in many 170 configurations applications may run on a different device than the 171 one providing EAP-based network access to it. 173 Given all this, it is NOT RECOMMENDED to use keys derived from the 174 EMSK as an exclusive security mechanism, when their usage is not 175 inherently, and by permanent nature, tied to the lower layer where 176 network access authentication was performed. 178 Keys derived from EAP are pairwise by nature and are not directly 179 suitable for multicast or other group usages such as those involved 180 in some routing protocols. It is possible to use keys derived from 181 EAP in protocols that distribute group keys to group participants. 183 The definition of these group key distribution protocols is beyond 184 the scope of this document and would require additional 185 specification. 187 1.2. Terminology 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in [RFC2119] 193 The following terms are taken from [RFC3748]: EAP Server, peer, 194 authenticator, Master Session Key (MSK), Extended Master Session Key 195 (EMSK), Cryptographic Separation. 197 Usage Definition 198 An application of cryptographic key material to provide one or 199 more security functions such as authentication, authorization, 200 encryption or integrity protection for related applications or 201 services. This document provides guidelines and recommendations 202 for what should be included in usage definitions. This document 203 does not place any constraints on the types of use cases or 204 services that create usage definitions. 206 Usage Specific Root Key (USRK) 207 Keying material derived from the EMSK for a particular usage 208 definition. It is used to derive child keys in a way defined by 209 its usage definition. 211 Key Management Domain 212 A key management domain is specified by the scope of a given root 213 key. The scope is the collection of systems authorized to access 214 key material derived from that key. Systems within a key 215 management domain may be authorized to (1) derive key materials, 216 (2) use key materials, or (3) distribute key materials to other 217 systems in the same domain. A derived key's scope is constrained 218 to a subset of the scope of the key it is derived from. In this 219 document the term domain refers to a key management domain unless 220 otherwise qualified. 222 Domain Specific Root Key (DSRK) 223 Keying material derived from the EMSK that is restricted to use in 224 a specific key management domain. It is used to derive child keys 225 for a particular usage definition. The child keys derived from a 226 DSRK are referred to as domain specific usage specific root keys 227 (DSUSRK). DSUSRKs are similar to the USRK, except in the fact 228 that their scope is restricted to the same domain as the parent 229 DSRK from which it is derived. 231 2. Cryptographic Separation and Coordinated Key Derivation 233 The EMSK is used to derive keys for multiple use cases, and thus it 234 is required that the derived keys are cryptographically separate. 235 Cryptographic separation means that when multiple keys are derived 236 from an EMSK, given any derived key it is computationally infeasible 237 to derive any of the other derived keys. Note that deriving the EMSK 238 from any combinations of the derived keys must also be 239 computationally infeasible. In practice this means that derivation 240 of an EMSK from a derived key or derivation of one child key from 241 another must require an amount of computation equivalent to that 242 required to, say, reversing a cryptographic hash function. 244 Cryptographic separation of keys derived from the same key can be 245 achieved in many ways. Two obvious methods are as follows: it is 246 plausible to use the IKEv2 PRF [RFC4306] on the EMSK and generate a 247 key stream. Keys of various lengths may be provided as required from 248 the key stream for various uses. The other option is to derive keys 249 from EMSK by providing different inputs to the PRF. However, it is 250 desirable that derivation of one child key from the EMSK is 251 independent of derivation of another child key. This allows child 252 keys to be derived in any order, independent of other keys. Thus it 253 is desirable to use the second option from above. That implies the 254 additional input to the PRF must be different for each child key 255 derivation. This additional input to the PRF must be coordinated 256 properly to meet the requirement of cryptographic separation and to 257 prevent reuse of key material between usages. 259 If cryptographic separation is not maintained then the security of 260 one usage depends upon the security of all other usages that use key 261 derived from the EMSK. If a system does not have this property then 262 a usage's security depends upon all other usages deriving keys from 263 the same EMSK, which is undesirable. In order to prevent security 264 problems in one usage from interfering with another usage, the 265 following cryptographic separation is required: 267 o It MUST be computationally infeasible to compute the EMSK from any 268 root key derived from it. 269 o Any root key MUST be cryptographically separate from any other 270 root key derived from the same EMSK or DSRK 271 o Derivation of USRKs MUST be coordinated so that two separate 272 cryptographic usages do not derive the same key. 273 o Derivation of DSRKs MUST be coordinated so that two separate key 274 management domains do not derive the same key. 275 o Derivation of DSRKs and USRKs MUST be specified such that no 276 domain can obtain a USRK by providing a domain name identical to a 277 Usage Key Label. 279 This document provides guidelines for a key derivation mechanism, 280 which can be used with existing and new EAP methods to provide 281 cryptographic separation between usages of EMSK. This allows for the 282 development of new usages without cumbersome coordination between 283 different usage definitions. 285 3. EMSK Key Root Derivation Framework 287 The EMSK key derivation framework provides a coordinated means for 288 generating multiple root keys from an EMSK. Further keys may then be 289 derived from the root key for various purposes, including encryption, 290 integrity protection, entity authentication by way of proof of 291 possession, and subsequent key derivation. A root key is derived 292 from the EMSK for specific set of uses set forth in a usage 293 definition described in Section 5. 295 The basic EMSK root key hierarchy looks as follows: 297 EMSK 298 / \ 299 USRK1 USRK2 301 This document defines how to derive usage specific root keys (USRK) 302 from the EMSK and also defines a specific USRK called a domain 303 specific root key (DSRK). DSRK are root keys restricted to use in a 304 particular key management domain. From the DSRK, usage specific root 305 keys for a particular application may be derived (DSUSRK). The 306 DSUSRKs are equivalent to USRKs that are restricted to use in a 307 particular domain. The details of lower levels of key hierarchy are 308 outside scope of this document. The key hierarchy looks as follows: 310 EMSK 311 / \ 312 USRK DSRK 313 / \ 314 DSUSRK1 DSUSRK2 316 3.1. USRK Derivation 318 The EMSK Root Key derivation function (KDF) derives a USRK from the 319 EMSK, a key label, optional data, and output length. The KDF is 320 expected to give the same output for the same input. The basic key 321 derivation function is given below. 323 USRK = KDF(EMSK, key label | "\0" | optional data | length) 325 Where: 327 | denotes concatenation 328 "\0" is a NULL octet (0x00 in hex) 329 length is a 2 octet unsigned integer in network byte order 331 The key labels are printable ASCII strings unique for each usage 332 definition and are a maximum of 255 octets. In general they are of 333 the form label-string@specorg where specorg is the organization that 334 controls the specification of the usage definition of the Root Key. 335 The key label is intended to provide global uniqueness. Rules for 336 the allocation of these labels are given in Section 8. 338 The NULL octet after the key label is used to avoid collisions if one 339 key label is a prefix of another label (e.g. "foobar" and 340 "foobarExtendedV2"). This is considered a simpler solution than 341 requiring a key label assignment policy that prevents prefixes from 342 occurring. 344 For the optional data the KDF MUST be capable of processing at least 345 2048 opaque octets. The optional data must be constant during the 346 execution of the KDF. Usage definitions MAY use the EAP session-ID 347 [I-D.ietf-eap-keying] in the specification of the optional data 348 parameter that go into the KDF function. This provides the advantage 349 of providing data into the key derivation that is unique to the 350 session that generated the keys. 352 The KDF must be able to process input keys of up to 256 bytes. It 353 may do this by providing a mechanism for "hashing" long keys down to 354 a suitable size that can be consumed by the underlying derivation 355 algorithm. 357 The length is a 2-octet unsigned integer in network byte order of the 358 output key length in octets. An implementation of the KDF MUST be 359 capable of producing at least 2048 octets of output, however it is 360 RECOMMENDED that Root Keys be at least 64 octets long. 362 A usage definition requiring derivation of a Root Key must specify 363 all the inputs (other than EMSK) to the key derivation function. 365 USRKs MUST be at least 64 octets in length. 367 3.1.1. On the KDFs 369 This specification allows for the use of different KDFs. However, in 370 order to have a coordinated key derivation function the same KDF 371 function MUST be used for all key derivations for a given EMSK. If 372 no KDF is specified, then the default KDF specified in Section 3.1.2 373 MUST be used. A system may provide the capability to negotiate 374 additional KDFs. KDFs are assigned numbers through IANA following 375 the policy set in section Section 8. The rules for negotiating a KDF 376 are as follows: 378 o If no other KDF is specified the KDF specified in this document 379 MUST be used. This is the "default" KDF. 380 o The initial authenticated key exchange MAY specify a favored KDF. 381 For example an EAP method may define a preferred KDF to use in its 382 specification. If the initial authenticated key exchange 383 specifies a KDF then this MUST override the default KDF. 385 Note that usage definitions MUST NOT concern themselves with the 386 details of the KDF construction or the KDF selection, they only need 387 to worry about the inputs specified in Section 3. 389 3.1.2. Default KDF 391 The default KDF for deriving root keys from an EMSK is taken from the 392 PRF+ key expansion specified in [RFC4306] based on HMAC-SHA-256 393 [SHA256]. The PRF+ construction was chosen because of its simplicity 394 and efficiency over other mechanisms such as those used in [RFC4346]. 395 The motivation for the design of PRF+ is described in [SIGMA]. The 396 definition of PRF+ from [RFC4306]is given below: 398 PRF+ (K,S) = T1 | T2 | T3 | T4 | ... 400 Where: 402 T1 = PRF (K, S | 0x01) 403 T2 = PRF (K, T1 | S | 0x02) 404 T3 = PRF (K, T2 | S | 0x03) 405 T4 = PRF (K, T3 | S | 0x04) 407 continuing as needed to compute the required length of key material. 408 The key, K, is the EMSK and S is the concatenation of key label, the 409 NULL octet, optional data and length defined in Section 3.1. For 410 this specification the PRF is taken as HMAC-SHA-256 [SHA256]. Since 411 PRF+ is only defined for 255 iterations it may produce up to 8160 412 octets of key material. 414 3.2. EMSK and USRK Name Derivation 416 The EAP keying framework [I-D.ietf-eap-keying] specifies that the 417 EMSK MUST be named using the EAP Session-Id and a binary or textual 418 indication. Following that requirement, the EMSK name SHALL be 419 derived as follows: 421 EMSKname = KDF ( EAP Session-ID, "EMSK" | "\0" | length ) 423 Where: 425 | denotes concatenation 426 "EMSK" consists of the 4 ASCII values for the letters 427 "\0" = is a NULL octet (0x00 in hex) 428 length is the 2 octet unsigned integer 8 in network byte order 430 It is RECOMMENDED that all keys derived from the EMSK are referred to 431 by the EMSKname and the context of the descendant key usage. This is 432 the default behavior. Any exceptions SHALL be signaled by individual 433 usages. 435 USRKs MAY be named explicitly with a name derivation specified as 436 follows: 438 USRKName = 439 KDF(EAP Session-ID, key label|"\0"|optional data|length) 441 Where: 443 key label and optional data MUST be the same as those used 444 in the corresponding USRK derivation 445 length is the 2 octet unsigned integer 8 in network byte order 447 USRKName derivation and usage is applicable when there is ambiguity 448 in the referencing the keys using the EMSKname and the associated 449 context of the USRK usage. The usage SHALL signal such an exception 450 in key naming, so both parties know the key name used. 452 4. Domain Specific Root Key Derivation 454 A specific USRK called a Domain Specific Root Key (DSRK) is derived 455 from the EMSK for a specific set of usages in a particular key 456 management domain. Usages derive specific keys for specific services 457 from this DSRK. The DSRK may be distributed to a key management 458 domain for a specific set of usages so keys can be derived within the 459 key management domain for those usages. DSRK based usages will 460 follow a key hierarchy similar to the following: 462 EMSK 463 / \ 464 / \ 465 / \ 466 / \ 467 DSRK1 DSRK2 468 / \ / \ 469 / \ / \ 470 DSUSRK11 DSUSRK12 DSUSRK21 DSUSRK22 472 The DSRK is a USRK with a key label of "dsrk@ietf.org" and the 473 optional data containing a domain label. The optional data MUST 474 contain an ASCII string representing the key management domain that 475 the root key is being derived for. The DSRK MUST be at least 64 476 octets long. 478 Domain Specific Usage Specific Root Keys (DSUSRK) are derived from 479 the DSRK. The KDF is expected to give the same output for the same 480 input. The basic key derivation function is given below. 482 DSUSRK = KDF(DSRK, key label | "\0" | optional data | length) 484 The key labels are printable ASCII strings unique for each usage 485 definition within a DSRK usage and are a maximum of 255 octets. In 486 general they are of the form label-string@specorg where specorg is 487 the organization that controls the specification of the usage 488 definition of the DSRK. The key label is intended to provide global 489 uniqueness. Rules for the allocation of these labels are given in 490 Section 8. For the optional data the KDF MUST be capable of 491 processing at least 2048 opaque octets. The optional data must be 492 constant during the execution of the KDF. The length is a 2-octet 493 unsigned integer in network byte order of the output key length in 494 octets. An implementation of the KDF MUST be capable of producing at 495 least 2048 octets of output, however it is RECOMMENDED that DSUSRKs 496 be at least 64 octets long. 498 Usages that make use of the DSRK must define how the peer learns the 499 domain label to use in a particular derivation. A multi-domain usage 500 must define how both DSRKs and specific DSUSRKs are transported to 501 different key management domains. Note that usages may define 502 alternate ways to constrain specific keys to particular key 503 management domains. 505 To facilitate the use of EMSKname to refer to keys derived from 506 DSRKs, EMSKname SHOULD be sent along with the DSRK. The exception is 507 when a DSRKname is expected to be used. The usage SHALL signal such 508 an exception in key naming, so both parties know the key name used. 510 DSUSRKs MAY be named explicitly with a name derivation specified as 511 follows: 513 DSUSRKName = 514 KDF(EMSKName,key label | "\0" | optional data | length) 516 where length is the 2 octet unsigned integer 8 in network byte order. 518 4.1. Applicability of Multi-Domain usages 520 When a DSRK is distributed to a domain the domain can generate any 521 DSUSRKs it wishes. This keys can be used to authorize entities in a 522 domain to perform specific functions. In cases where it is 523 appropriate for only a specific domain to be authorized to perform a 524 function the usage SHOULD NOT be defined as multi-domain. 526 In some cases only certain domains are authorized for a particular 527 Multi-Domain usage. In this case domains that do not have full 528 authorization should not receive the DSRK and should only receive 529 DSUSRKs for the usages which they are authorized. If it is possible 530 for a peer to know which domains are authorized for a particular 531 usage without relying on restricting access to the DSRK to specific 532 domains then this recommendation may be relaxed. 534 5. Requirements for Usage Definitions 536 In order for a usage definition to meet the guidelines for USRK usage 537 it must meet the following recommendations: 539 o The usage must define if it is a domain enabled usage. 540 o The usage definition MUST NOT use the EMSK in any other way except 541 to derive Root Keys using the key derivation specified in 542 Section 3 of this document. They MUST NOT use the EMSK directly. 543 o The usage definition SHOULD NOT require caching of the EMSK. It 544 is RECOMMENDED that the Root Key derived specifically for the 545 usage definition rather than the EMSK should be used to derive 546 child keys for specific cryptographic operations. 547 o Usage definition MUST define distinct key labels and optional data 548 used in the key derivation described in Section 3. Usage 549 definitions are encouraged to use the key name described in 550 Section 3.2 and include additional data in the optional data to 551 provide additional entropy. 552 o Usage definitions MUST define the length of their Root Keys. It 553 is RECOMMENDED that the Root Keys be at least as long as the EMSK 554 (at least 64 octets). 556 o Usage definitions MUST define how they use their Root Keys. This 557 includes aspects of key management covered in the next section on 558 Root Key Management guidelines. 559 o 561 5.1. Root Key Management Guidelines 563 This section makes recommendations for various aspects of key 564 management of the Root Key including lifetime, child key derivation, 565 caching and transport. 567 It is RECOMMENDED that the Root Key is only used for deriving child 568 keys. A usage definition must specify how and when the derivation of 569 child keys should be done. It is RECOMMENDED that usages following 570 similar considerations for key derivation are as outlined in this 571 document for the Root Key derivation with respect to cryptographic 572 separation and key reuse. In addition, usages should take into 573 consideration the number of keys that will be derived from the Root 574 Key and ensure that enough entropy is introduced in the derivation to 575 support this usage. It is desirable that the entropy is provided by 576 the two parties that derive the child key. 578 Root Keys' lifetimes should not be more than that of the EMSK. Thus, 579 when the EMSK expires, the Root Keys derived from it should be 580 removed from use. If a new EMSK is derived from a subsequent EAP 581 transaction then a usage implementation should begin to use the new 582 Root Keys derived from the new EMSK as soon as possible. Whether or 583 not child keys associated with a Root Key are replaced depends on the 584 requirements of the usage definition. It is conceivable that some 585 usage definition forces the child key to be replaced and others allow 586 child keys to be used based on the policy of the entities that use 587 the child key. 589 Recall that the EMSK never leaves the EAP peer and server. That also 590 holds true for some Root Keys; however, some Root Keys may be 591 provided to other entities for child key derivation and delivery. 592 Each usage definition specification will specify delivery caching 593 and/or delivery procedures. Note that the purpose of the key 594 derivation in Section 3 is to ensure that Root Keys are 595 cryptographically separate from each other and the EMSK. In other 596 words, given a Root Key, it is computationally infeasible to derive 597 the EMSK, any other Root Keys, or child keys associated with other 598 Root Keys. In addition to the Root Key, several other parameters may 599 need to be sent. 601 Root Key names may be derived using the EAP Session ID, and thus the 602 key name may need to be sent along with the key. When Root Keys are 603 delivered to another entity, the EMSKname and the lifetime associated 604 with the specific root keys MUST also be transported to that entity. 605 Recommendations for transporting keys are discussed in the security 606 considerations (Section 7.4). 608 Usage definition may also define how keys are bound to particular 609 entities. This can be done through the inclusion of usage parameters 610 and identities in the child key derivation. Some of this data is 611 described as "channel bindings" in [RFC3748]. 613 6. Requirements for EAP System 615 The system that wishes to make use of EAP root keys derived from the 616 EMSK must take certain things into consideration. The following is a 617 list of these considerations: 619 o The EMSK MUST NOT be used for any other purpose than the key 620 derivation described in this document. 621 o The EMSK MUST be secret and not known to someone observing the 622 authentication mechanism protocol exchange. 623 o The EMSK MUST be maintained within a protected location inside the 624 entity where it is generated. Only root keys derived according to 625 this specification may be exported from this boundary. 626 o The EMSK MUST be unique for each EAP session 627 o The EAP method MUST provide an identifier for the EAP transaction 628 that generated the key 629 o The system MUST define which usage definitions are used and how 630 they are invoked. 631 o The system may define ways to select an alternate PRF for key 632 derivation as defined in Section 3.1. 634 The system MAY use the MSK transmitted to the NAS in any way it 635 chooses in accordance with [RFC3748] [I-D.ietf-eap-keying] and other 636 relevant specifications. This is required for backward 637 compatibility. New usage definitions following this specification 638 MUST NOT use the MSK. If more than one usage uses the MSK, then the 639 cryptographic separation is not achieved. Implementations MUST 640 prevent such combinations. 642 7. Security Considerations 644 7.1. Key strength 646 The effective key strength of the derived keys will never be greater 647 than the strength of the EMSK (or a master key internal to an EAP 648 mechanism). 650 7.2. Cryptographic separation of keys 652 The intent of the KDF is to derive keys that are cryptographically 653 separate: the compromise of one of the usage specific root keys 654 (USRKs) should not compromise the security of other USRKs or the 655 EMSK. It is believed that the KDF chosen provides the desired 656 separation. 658 7.3. Implementation 660 An implementation of an EAP framework should keep the EMSK internally 661 as close to where it is derived as possible and only provide an 662 interface for obtaining Root Keys. It may also choose to restrict 663 which callers have access to which keys. A usage definition MUST NOT 664 assume that any entity outside the EAP server or EAP peer EAP 665 framework has access to the EMSK. In particular it MUST NOT assume 666 that a lower layer has access to the EMSK. 668 7.4. Key Distribution 670 In some cases it will be necessary or convenient to distribute USRKs 671 from where they are generated. Since these are secret keys they MUST 672 be transported with their integrity and confidentiality maintained. 673 They MUST be transmitted between authenticated and authorized 674 parties. It is also important that the context of the key usage be 675 transmitted along with the key. This includes information to 676 identify the key and constraints on its usage such as lifetime. 678 This document does not define a mechanism for key transport. It is 679 up to usage definitions and the systems that use them to define how 680 keys are distributed. Usage definition designers may enforce 681 constraints on key usage by various parties by deriving a key 682 hierarchy and by providing entities only with the keys in the 683 hierarchy that they need. 685 7.5. Key Lifetime 687 The key lifetime is dependent upon how the key is generated and how 688 the key is used. Since the Root Key is the responsibility of the 689 usage definition it must determine how long the key is valid for. If 690 key lifetime or key strength information is available from the 691 authenticated key exchange then this information SHOULD be used in 692 determining the lifetime of the key. If possible it is recommended 693 that key lifetimes be coordinated throughout the system. Setting a 694 key lifetime shorter that a system lifetime may result is keys 695 becoming invalid with no convenient way to refresh them. Setting a 696 key lifetime to longer may result in decreased security since the key 697 may be used beyond its recommended lifetime. 699 7.6. Entropy consideration 701 The number of root keys derived from the EMSK is expected to be low. 702 Note that there is no randomness required to be introduced into the 703 EMSK to root key derivation beyond the root key labels. Thus, if 704 many keys are going to be derived from an Root Key it is important 705 that Root Key to child key derivation introduce fresh random numbers 706 in deriving each key. 708 8. IANA Considerations 710 The keywords "Private Use", "Specification Required" and "IETF 711 Consensus" that appear in this document when used to describe 712 namespace allocation are to be interpreted as described in [RFC5226]. 714 8.1. Key Labels 716 This specification introduces a new name space for "USRK key labels". 717 Key labels MUST be printable US-ASCII strings, and MUST NOT contain 718 the characters at-sign ("@") except as noted below, comma (","), 719 whitespace, control characters (ASCII codes 32 or less), or the ASCII 720 code 127 (DEL). Labels are case-sensitive, and MUST NOT be longer 721 than 64 characters. 723 Labels can be assigned based on Specification Required policy 724 [RFC5226]. In addition, the labels "experimental1" and 725 "experimental2" are reserved for experimental use. The following 726 considerations apply to their use: 728 Production networks do not necessarily support the use of 729 experimental code points. The network scope of support for 730 experimental values should carefully be evaluated before deploying 731 any experiment across extended network domains, such as the public 732 Internet. The potential to disrupt the stable operation of EAP 733 devices is a consideration when planning an experiment using such 734 code points. 736 The network administrators should ensure that each code point is used 737 consistently to avoid interference between experiments. Particular 738 attention should be given to security vulnerabilities and the freedom 739 of different domains to employ their own experiments. Cross-domain 740 usage is NOT RECOMMENDED. 742 Similarly, labels "private1" and "private2" have been reserved for 743 Private Use within an organization. Again, cross-domain usage of 744 these labels is NOT RECOMMENDED. 746 Labels starting with a string and followed by the "@" and a valid, 747 fully qualified Internet domain name [RFC1034] can be requested by by 748 the person or organization who are in control of the domain name. 749 Such labels can be allocated based on Expert Review with 750 Specification Required. Besides the review needed for Specification 751 Required (see Section 4.1 of [RFC5226]), the expert needs to review 752 the proposed usage for conformance to this specification, including 753 the suitability of the usage according to the applicability statement 754 outlined in Section 1.1. It is RECOMMENDED that the specification 755 contain the following information: 757 o A description of the usage 758 o The key label to be used 759 o Length of the Root Key 760 o If optional data is used, what it is and how it is maintained 761 o How child keys will be derived from the Root Key and how they will 762 be used 763 o How lifetime of the Root Key and its child keys will be managed 764 o Where the Root Keys or child keys will be used and how they are 765 communicated if necessary 767 The following labels are reserved by this document: "EMSK", 768 "dsrk@ietf.org". 770 8.2. PRF numbers 772 This specification introduces a new number space for "EMSK PRF 773 numbers". The numbers are int he range 0 to 255 Numbers from 0 to 774 220 are assigned through the policy IETF Consensus and numbers in the 775 range 221 to 255 are left for Private Use. The initial registry 776 should contain the following values: 778 0 RESERVED 779 1 HMAC-SHA-256 PRF+ (Default) 781 9. Acknowledgements 783 This document expands upon previous collaboration with Pasi Eronen. 784 This document reflects conversations with Bernard Aboba, Jari Arkko, 785 Avi Lior, David McGrew, Henry Haverinen, Hao Zhou, Russ Housley, Glen 786 Zorn, Charles Clancy, Dan Harkins, Alan DeKok, Yoshi Ohba and members 787 of the EAP and HOKEY working groups. 789 Thanks to Dan Harkins for the idea of using a single root key name to 790 refer to all keys. 792 10. References 794 10.1. Normative References 796 [I-D.ietf-eap-keying] 797 Aboba, B., Simon, D., and P. Eronen, "Extensible 798 Authentication Protocol (EAP) Key Management Framework", 799 draft-ietf-eap-keying-22 (work in progress), 800 November 2007. 802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 803 Requirement Levels", BCP 14, RFC 2119, March 1997. 805 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 806 Levkowetz, "Extensible Authentication Protocol (EAP)", 807 RFC 3748, June 2004. 809 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 810 RFC 4306, December 2005. 812 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 813 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 814 May 2008. 816 [SHA256] National Institute of Standards and Technology, "Secure 817 Hash Standard", FIPS 180-2, August 2002. 819 With Change Notice 1 dated February 2004 821 10.2. Informative References 823 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 824 text messages", STD 11, RFC 822, August 1982. 826 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 827 STD 13, RFC 1034, November 1987. 829 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 830 Network Access Identifier", RFC 4282, December 2005. 832 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 833 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 835 [SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to 836 Authenticated Diffie-Hellman and its Use in the IKE 837 Protocols", LNCS 2729, Springer, 2003. 839 Available at http://www.informatik.uni-trier.de/~ley/db/ 840 conf/crypto/crypto2003.html 842 Authors' Addresses 844 Joseph Salowey 845 Cisco Systems 847 Email: jsalowey@cisco.com 849 Lakshminath Dondeti 850 Qualcomm, Inc 852 Email: ldondeti@qualcomm.com 854 Vidya Narayanan 855 Qualcomm, Inc 857 Email: vidyan@qualcomm.com 859 Madjid Nakhjiri 860 Motorola 862 Email: madjid.nakhjiri@motorola.com 864 Full Copyright Statement 866 Copyright (C) The IETF Trust (2008). 868 This document is subject to the rights, licenses and restrictions 869 contained in BCP 78, and except as set forth therein, the authors 870 retain all their rights. 872 This document and the information contained herein are provided on an 873 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 874 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 875 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 876 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 877 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 878 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 880 Intellectual Property 882 The IETF takes no position regarding the validity or scope of any 883 Intellectual Property Rights or other rights that might be claimed to 884 pertain to the implementation or use of the technology described in 885 this document or the extent to which any license under such rights 886 might or might not be available; nor does it represent that it has 887 made any independent effort to identify any such rights. Information 888 on the procedures with respect to rights in RFC documents can be 889 found in BCP 78 and BCP 79. 891 Copies of IPR disclosures made to the IETF Secretariat and any 892 assurances of licenses to be made available, or the result of an 893 attempt made to obtain a general license or permission for the use of 894 such proprietary rights by implementers or users of this 895 specification can be obtained from the IETF on-line IPR repository at 896 http://www.ietf.org/ipr. 898 The IETF invites any interested party to bring to its attention any 899 copyrights, patents or patent applications, or other proprietary 900 rights that may cover technology that may be required to implement 901 this standard. Please address the information to the IETF at 902 ietf-ipr@ietf.org.