idnits 2.17.1 draft-ietf-hokey-emsk-hierarchy-04.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 795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 813. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 819. 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 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 (February 24, 2008) is 5899 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) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) -- 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 (~~), 1 warning (==), 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 Intended status: Standards Track L. Dondeti 5 Expires: August 27, 2008 V. Narayanan 6 Qualcomm, Inc 7 M. Nakhjiri 8 Motorola 9 February 24, 2008 11 Specification for the Derivation of Root Keys from an Extended Master 12 Session Key (EMSK) 13 draft-ietf-hokey-emsk-hierarchy-04.txt 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 August 27, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 An Extended Master Session Key (EMSK) is a cryptographic key 47 generated from an Extensible Authentication Protocol (EAP) exchange 48 reserved solely for the purpose of deriving master keys for one or 49 more purposes identified as usage definitions. This memo specifies a 50 mechanism for avoiding conflicts between root keys by deriving 51 cryptographically separate keys from the EMSK. This document also 52 describes a usage for domain specific root keys made available to and 53 used within specific key management domains. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Cryptographic Separation and Coordinated Key Derivation . . . 4 60 3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 6 61 3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 6 62 3.1.1. On the KDFs . . . . . . . . . . . . . . . . . . . . . 7 63 3.1.2. Default KDF . . . . . . . . . . . . . . . . . . . . . 8 64 3.2. EMSK and USRK Name Derivation . . . . . . . . . . . . . . 9 65 4. Domain Specific Root Key Derivation . . . . . . . . . . . . . 9 66 5. Requirements for Usage Definitions . . . . . . . . . . . . . . 11 67 5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 11 68 6. Requirements for EAP System . . . . . . . . . . . . . . . . . 13 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 13 71 7.2. Cryptographic separation of keys . . . . . . . . . . . . . 13 72 7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 13 73 7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 14 74 7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 14 75 7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 14 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 15 78 8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 16 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 84 Intellectual Property and Copyright Statements . . . . . . . . . . 19 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) should be used or discuss what types of use 111 cases are valid. It does define a framework for the derivation of 112 USRKs for different purposes such that different usages can be 113 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. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119] 133 The following terms are taken from [RFC3748]: EAP Server, peer, 134 authenticator, Master Session Key (MSK), Extended Master Session Key 135 (EMSK), Cryptographic Separation. 137 Usage Definition 138 An application of cryptographic key material to provide one or 139 more security functions such as authentication, authorization, 140 encryption or integrity protection for related applications or 141 services. This document provides guidelines and recommendations 142 for what should be included in usage definitions. This document 143 does not place any constraints on the types of use cases or 144 services that create usage definitions. 146 Usage Specific Root Key (USRK) 147 Keying material derived from the EMSK for a particular usage 148 definition. It is used to derive child keys in a way defined by 149 its usage definition. 151 Key Management Domain 152 A key management domain is specified by the scope of a given root 153 key. The scope is the collection of systems authorized to access 154 key material derived from that key. Systems within a key 155 management domain may be authorized to (1) derive key materials, 156 (2) use key materials, or (3) distribute key materials to other 157 systems in the same domain. A derived key's scope is constrained 158 to a subset of the scope of the key it is derived from. In this 159 document the term domain refers to a key management domain unless 160 otherwise qualified. 162 Domain Specific Root Key (DSRK) 163 Keying material derived from the EMSK that is restricted to use in 164 a specific key management domain. It is used to derive child keys 165 for a particular usage definition. The child keys derived from a 166 DSRK are referred to as domain specific usage specific root keys 167 (DSUSRK). DSUSRKs are similar to the USRK, except in the fact 168 that their scope is restricted to the same domain as the parent 169 DSRK from which it is derived. 171 2. Cryptographic Separation and Coordinated Key Derivation 173 The EMSK is used to derive keys for multiple use cases, and thus it 174 is required that the derived keys are cryptographically separate. 175 Cryptographic separation means that when multiple keys are derived 176 from an EMSK, given any derived key it is computationally infeasible 177 to derive any of the other derived keys. Note that deriving the EMSK 178 from any combinations of the derived keys must also be 179 computationally infeasible. In practice this means that derivation 180 of an EMSK from a derived key or derivation of one child key from 181 another must require an amount of computation equivalent to that 182 required to, say, reversing a cryptographic hash function. 184 Cryptographic separation of keys derived from the same key can be 185 achieved in many ways. Two obvious methods are as follows: it is 186 plausible to use the IKEv2 PRF [RFC4306] on the EMSK and generate a 187 key stream. Keys of various lengths may be provided as required from 188 the key stream for various uses. The other option is to derive keys 189 from EMSK by providing different inputs to the PRF. However, it is 190 desirable that derivation of one child key from the EMSK is 191 independent of derivation of another child key. This allows child 192 keys to be derived in any order, independent of other keys. Thus it 193 is desirable to use the second option from above. That implies the 194 additional input to the PRF must be different for each child key 195 derivation. This additional input to the PRF must be coordinated 196 properly to meet the requirement of cryptographic separation and to 197 prevent reuse of key material between usages. 199 If cryptographic separation is not maintained then the security of 200 one usage depends upon the security of all other usages that use key 201 derived from the EMSK. If a system does not have this property then 202 a usage's security depends upon all other usages deriving keys from 203 the same EMSK, which is undesirable. In order to prevent security 204 problems in one usage from interfering with another usage, the 205 following cryptographic separation is required: 207 o It MUST be computationally infeasible to compute the EMSK from any 208 root key derived from it. 209 o Any root key MUST be cryptographically separate from any other 210 root key derived from the same EMSK or DSRK 211 o Derivation of USRKs MUST be coordinated so that two separate 212 cryptographic usages do not derive the same key. 213 o Derivation of DSRKs MUST be coordinated so that two separate key 214 management domains do not derive the same key. 215 o Derivation of DSRKs and USRKs MUST be specified such that no 216 domain can obtain a USRK by providing a domain name identical to a 217 Usage Key Label. 219 This document provides guidelines for a key derivation mechanism, 220 which can be used with existing and new EAP methods to provide 221 cryptographic separation between usages of EMSK. This allows for the 222 development of new usages without cumbersome coordination between 223 different usage definitions. 225 3. EMSK Key Root Derivation Framework 227 The EMSK key derivation framework provides a coordinated means for 228 generating multiple root keys from an EMSK. Further keys may then be 229 derived from the root key for various purposes, including encryption, 230 integrity protection, entity authentication by way of proof of 231 possession, and subsequent key derivation. A root key is derived 232 from the EMSK for specific set of uses set forth in a usage 233 definition described in Section 5. 235 The basic EMSK root key hierarchy looks as follows: 237 EMSK 238 / \ 239 USRK1 USRK2 241 This document defines how to derive usage specific root keys (USRK) 242 from the EMSK and also defines a specific USRK called a domain 243 specific root key (DSRK). DSRK are root keys restricted to use in a 244 particular key management domain. From the DSRK, usage specific root 245 keys for a particular application may be derived (DSUSRK). The 246 DSUSRKs are equivalent to USRKs that are restricted to use in a 247 particular domain. The details of lower levels of key hierarchy are 248 outside scope of this document. The key hierarchy looks as follows: 250 EMSK 251 / \ 252 USRK DSRK 253 / \ 254 DSUSRK1 DSUSRK2 256 3.1. USRK Derivation 258 The EMSK Root Key derivation function (KDF) derives a USRK from the 259 EMSK, a key label, optional data, and output length. The KDF is 260 expected to give the same output for the same input. The basic key 261 derivation function is given below. 263 USRK = KDF(EMSK, key label | "\0" | optional data | length) 265 Where: 267 | denotes concatenation 268 "\0" is a NULL octet (0x00 in hex) 269 length is a 2 octet unsigned integer in network byte order 271 The key labels are printable ASCII strings unique for each usage 272 definition and are a maximum of 255 octets. In general they are of 273 the form label-string@specorg where specorg is the organization that 274 controls the specification of the usage definition of the Root Key. 275 The key label is intended to provide global uniqueness. Rules for 276 the allocation of these labels are given in Section 8. 278 The NULL octet after the key label is used to avoid collisions if one 279 key label is a prefix of another label (e.g. "foobar" and 280 "foobarExtendedV2"). This is considered a simpler solution than 281 requiring a key label assignment policy that prevents prefixes from 282 occurring. 284 For the optional data the KDF MUST be capable of processing at least 285 2048 opaque octets. The optional data must be constant during the 286 execution of the KDF. Usage definitions MAY use the EAP session-ID 287 [I-D.ietf-eap-keying] in the specification of the optional data 288 parameter that go into the KDF function. This provides the advantage 289 of providing data into the key derivation that is unique to the 290 session that generated the keys. 292 The KDF must be able to process input keys of up to 256 bytes. It 293 may do this by providing a mechanism for "hashing" long keys down to 294 a suitable size that can be consumed by the underlying derivation 295 algorithm. 297 The length is a 2-octet unsigned integer in network byte order of the 298 output key length in octets. An implementation of the KDF MUST be 299 capable of producing at least 2048 octets of output, however it is 300 RECOMMENDED that Root Keys be at least 64 octets long. 302 A usage definition requiring derivation of a Root Key must specify 303 all the inputs (other than EMSK) to the key derivation function. 305 USRKs MUST be at least 64 octets in length. 307 3.1.1. On the KDFs 309 This specification allows for the use of different KDFs. However, in 310 order to have a coordinated key derivation function the same KDF 311 function MUST be used for all key derivations for a given EMSK. If 312 no KDF is specified, then the default KDF specified in Section 3.1.2 313 MUST be used. A system may provide the capability to negotiate 314 additional KDFs. KDFs are assigned numbers through IANA following 315 the policy set in section Section 8. The rules for negotiating a KDF 316 are as follows: 318 o If no other KDF is specified the KDF specified in this document 319 MUST be used. This is the "default" KDF. 320 o The initial authenticated key exchange MAY specify a favored KDF. 321 For example an EAP method may define a preferred KDF to use in its 322 specification. If the initial authenticated key exchange 323 specifies a KDF then this MUST override the default KDF. 324 o A system MAY specify a separate default KDF if all participants 325 within the system have the knowledge of which KDF to use. If 326 specified this MUST take precedence over key exchange defined KDF. 328 Note that usage definitions MUST NOT concern themselves with the 329 details of the KDF construction or the KDF selection, they only need 330 to worry about the inputs specified in Section 3. 332 3.1.2. Default KDF 334 The default KDF for deriving root keys from an EMSK is taken from the 335 PRF+ key expansion specified in [RFC4306] based on HMAC-SHA-256 336 [SHA256]. The PRF+ construction was chosen because of its simplicity 337 and efficiency over other mechanisms such as those used in [RFC4346]. 338 The motivation for the design of PRF+ is described in [SIGMA]. The 339 definition of PRF+ from [RFC4306]is given below: 341 PRF+ (K,S) = T1 | T2 | T3 | T4 | ... 343 Where: 345 T1 = PRF (K, S | 0x01) 346 T2 = PRF (K, T1 | S | 0x02) 347 T3 = PRF (K, T2 | S | 0x03) 348 T4 = PRF (K, T3 | S | 0x04) 350 continuing as needed to compute the required length of key material. 351 The key, K, is the EMSK and S is the concatenation of key label, the 352 NULL octet, optional data and length defined in Section 3.1. For 353 this specification the PRF is taken as HMAC-SHA-256 [SHA256]. Since 354 PRF+ is only defined for 255 iterations it may produce up to 8160 355 octets of key material. 357 3.2. EMSK and USRK Name Derivation 359 The EAP keying framework [I-D.ietf-eap-keying] specifies that the 360 EMSK MUST be named using the EAP Session-Id and a binary or textual 361 indication. Following that requirement, the EMSK name SHALL be 362 derived as follows: 364 EMSKname = KDF ( EAP Session-ID, "EMSK" | "\0" | length ) 366 Where: 368 | denotes concatenation 369 "EMSK" consists of the 4 ASCII values for the letters 370 "\0" = is a NULL octet (0x00 in hex) 371 length is the 2 octet unsigned integer 8 in network byte order 373 It is RECOMMENDED that all keys derived from the EMSK are referred to 374 by the EMSKname and the context of the descendant key usage. This is 375 the default behavior. Any exceptions SHALL be signaled by individual 376 usages. 378 USRKs MAY be named explicitly with a name derivation specified as 379 follows: 381 USRKName = 382 KDF(EAP Session-ID, key label|"\0"|optional data|length) 384 Where: 386 key label and optional data MUST be the same as those used 387 in the corresponding USRK derivation 388 length is the 2 octet unsigned integer 8 in network byte order 390 USRKName derivation and usage is applicable when there is ambiguity 391 in the referencing the keys using the EMSKname and the associated 392 context of the USRK usage. The usage SHALL signal such an exception 393 in key naming, so both parties know the key name used. 395 4. Domain Specific Root Key Derivation 397 A specific USRK called a Domain Specific Root Key (DSRK) is derived 398 from the EMSK for a specific set of usages in a particular key 399 management domain. Usages derive specific keys for specific services 400 from this DSRK. The DSRK may be distributed to a key management 401 domain for a specific set of usages so keys can be derived within the 402 key management domain for those usages. DSRK based usages will 403 follow a key hierarchy similar to the following: 405 EMSK 406 / \ 407 / \ 408 / \ 409 / \ 410 DSRK1 DSRK2 411 / \ / \ 412 / \ / \ 413 DSUSRK11 DSUSRK12 DSUSRK21 DSUSRK22 415 The DSRK is a USRK with a key label of "dsrk@ietf.org" and the 416 optional data containing a domain label. The optional data MUST 417 contain an ASCII string representing the key management domain that 418 the root key is being derived for. The DSRK MUST be at least 64 419 octets long. 421 Domain Specific Usage Specific Root Keys (DSUSRK) are derived from 422 the DSRK. The KDF is expected to give the same output for the same 423 input. The basic key derivation function is given below. 425 DSUSRK = KDF(DSRK, key label | "\0" | optional data | length) 427 The key labels are printable ASCII strings unique for each usage 428 definition within a DSRK usage and are a maximum of 255 octets. In 429 general they are of the form label-string@specorg where specorg is 430 the organization that controls the specification of the usage 431 definition of the DSRK. The key label is intended to provide global 432 uniqueness. Rules for the allocation of these labels are given in 433 Section 8. For the optional data the KDF MUST be capable of 434 processing at least 2048 opaque octets. The optional data must be 435 constant during the execution of the KDF. The length is a 2-octet 436 unsigned integer in network byte order of the output key length in 437 octets. An implementation of the KDF MUST be capable of producing at 438 least 2048 octets of output, however it is RECOMMENDED that DSUSRKs 439 be at least 64 octets long. 441 Usages that make use of the DSRK must define how the peer learns the 442 domain label to use in a particular derivation. A multi-domain usage 443 must define how both DSRKs and specific DSUSRKs are transported to 444 different key management domains. Note that usages may define 445 alternate ways to constrain specific keys to particular key 446 management domains. 448 To facilitate the use of EMSKname to refer to keys derived from 449 DSRKs, EMSKname SHOULD be sent along with the DSRK. The exception is 450 when a DSRKname is expected to be used. The usage SHALL signal such 451 an exception in key naming, so both parties know the key name used. 453 DSUSRKs MAY be named explicitly with a name derivation specified as 454 follows: 456 DSUSRKName = 457 KDF(EMSKName,key label | "\0" | optional data | length) 459 where length is the 2 octet unsigned integer 8 in network byte order. 461 5. Requirements for Usage Definitions 463 In order for a usage definition to meet the guidelines for USRK usage 464 it must meet the following recommendations: 466 o The usage must define if it is a domain enabled usage. 467 o The usage definition MUST NOT use the EMSK in any other way except 468 to derive Root Keys using the key derivation specified in 469 Section 3 of this document. They MUST NOT use the EMSK directly. 470 o The usage definition SHOULD NOT require caching of the EMSK. It 471 is RECOMMENDED that the Root Key derived specifically for the 472 usage definition rather than the EMSK should be used to derive 473 child keys for specific cryptographic operations. 474 o Usage definition MUST define distinct key labels and optional data 475 used in the key derivation described in Section 3. Usage 476 definitions are encouraged to use the key name described in 477 Section 3.2 and include additional data in the optional data to 478 provide additional entropy. 479 o Usage definitions MUST define the length of their Root Keys. It 480 is RECOMMENDED that the Root Keys be at least as long as the EMSK 481 (at least 64 octets). 482 o Usage definitions MUST define how they use their Root Keys. This 483 includes aspects of key management covered in the next section on 484 Root Key Management guidelines. 485 o 487 5.1. Root Key Management Guidelines 489 This section makes recommendations for various aspects of key 490 management of the Root Key including lifetime, child key derivation, 491 caching and transport. 493 It is RECOMMENDED that the Root Key only used for deriving child 494 keys. A usage definition must specify how and when the derivation of 495 child keys should be done. It is RECOMMENDED that usages following 496 similar considerations for key derivation are as outlined in this 497 document for the Root Key derivation with respect to cryptographic 498 separation and key reuse. In addition, usages should take into 499 consideration the number of keys that will be derived from the Root 500 Key and ensure that enough entropy is introduced in the derivation to 501 support this usage. It is desirable that the entropy is provided by 502 the two parties that derive the child key. 504 Root Keys' lifetimes should not be more than that of the EMSK. Thus, 505 when the EMSK expires, the Root Keys derived from it should be 506 removed from use. If a new EMSK is derived from a subsequent EAP 507 transaction then a usage implementation should begin to use the new 508 Root Keys derived from the new EMSK as soon as possible. Whether or 509 not child keys associated with a Root Key are replaced depends on the 510 requirements of the usage definition. It is conceivable that some 511 usage definition forces the child key to be replaced and others allow 512 child keys to be used based on the policy of the entities that use 513 the child key. 515 Recall that the EMSK never leaves the EAP peer and server. That also 516 holds true for some Root Keys; however, some Root Keys may be 517 provided to other entities for child key derivation and delivery. 518 Each usage definition specification will specify delivery caching 519 and/or delivery procedures. Note that the purpose of the key 520 derivation in Section 3 is to ensure that Root Keys are 521 cryptographically separate from each other and the EMSK. In other 522 words, given a Root Key, it is computationally infeasible to derive 523 the EMSK, any other Root Keys, or child keys associated with other 524 Root Keys. In addition to the Root Key, several other parameters may 525 need to be sent. 527 Root Key names may be derived using the EAP Session ID, and thus the 528 key name may need to be sent along with the key. When Root Keys are 529 delivered to another entity, the EMSKname and the lifetime associated 530 with the specific root keys MUST also be transported to that entity. 531 Recommendations for transporting keys are discussed in the security 532 considerations (Section 7.4). 534 Usage definition may also define how keys are bound to particular 535 entities. This can be done through the inclusion of usage parameters 536 and identities in the child key derivation. Some of this data is 537 described as "channel bindings" in [RFC3748]. 539 6. Requirements for EAP System 541 The system that wishes to make use of EAP root keys derived from the 542 EMSK must take certain things into consideration. The following is a 543 list of these considerations: 545 o The EMSK MUST NOT be used for any other purpose than the key 546 derivation described in this document. 547 o The EMSK MUST be secret and not known to someone observing the 548 authentication mechanism protocol exchange. 549 o The EMSK MUST be maintained within a protected location inside the 550 entity where it is generated. Only root keys derived according to 551 this specification may be exported from this boundary. 552 o The EMSK MUST be unique for each EAP session 553 o The EAP method MUST provide an identifier for the EAP transaction 554 that generated the key 555 o The system MUST define which usage definitions are used and how 556 they are invoked. 557 o The system may define ways to select an alternate PRF for key 558 derivation as defined in Section 3.1. 560 The system MAY use the MSK transmitted to the NAS in any way it 561 chooses. This is required for backward compatibility. New usage 562 definitions following this specification MUST NOT use the MSK. If 563 more than one usage uses the MSK, then the cryptographic separation 564 is not achieved. Implementations MUST prevent such combinations. 566 7. Security Considerations 568 7.1. Key strength 570 The effective key strength of the derived keys will never be greater 571 than the strength of the EMSK (or a master key internal to an EAP 572 mechanism). 574 7.2. Cryptographic separation of keys 576 The intent of the KDF is to derive keys that are cryptographically 577 separate: the compromise of one of the usage specific root keys 578 (USRKs) should not compromise the security of other USRKs or the 579 EMSK. It is believed that the KDF chosen provides the desired 580 separation. 582 7.3. Implementation 584 An implementation of an EAP framework should keep the EMSK internally 585 as close to where it is derived as possible and only provide an 586 interface for obtaining Root Keys. It may also choose to restrict 587 which callers have access to which keys. A usage definition MUST NOT 588 assume that any entity outside the EAP server or EAP peer EAP 589 framework has access to the EMSK. In particular it MUST NOT assume 590 that a lower layer has access to the EMSK. 592 7.4. Key Distribution 594 In some cases it will be necessary or convenient to distribute USRKs 595 from where they are generated. Since these are secret keys they MUST 596 be transported with their integrity and confidentiality maintained. 597 They MUST be transmitted between authenticated and authorized 598 parties. It is also important that the context of the key usage be 599 transmitted along with the key. This includes information to 600 identify the key and constraints on its usage such as lifetime. 602 This document does not define a mechanism for key transport. It is 603 up to usage definitions and the systems that use them to define how 604 keys are distributed. Usage definition designers may enforce 605 constraints on key usage by various parties by deriving a key 606 hierarchy and by providing entities only with the keys in the 607 hierarchy that they need. 609 7.5. Key Lifetime 611 The key lifetime is dependent upon how the key is generated and how 612 the key is used. Since the Root Key is the responsibility of the 613 usage definition it must determine how long the key is valid for. If 614 key lifetime or key strength information is available from the 615 authenticated key exchange then this information SHOULD be used in 616 determining the lifetime of the key. If possible it is recommended 617 that key lifetimes be coordinated throughout the system. Setting a 618 key lifetime shorter that a system lifetime may result is keys 619 becoming invalid with no convenient way to refresh them. Setting a 620 key lifetime to longer may result in decreased security since the key 621 may be used beyond its recommended lifetime. 623 7.6. Entropy consideration 625 The number of root keys derived from the EMSK is expected to be low. 626 Note that there is no randomness required to be introduced into the 627 EMSK to root key derivation beyond the root key labels. Thus, if 628 many keys are going to be derived from an Root Key it is important 629 that Root Key to child key derivation introduce fresh random numbers 630 in deriving each key. 632 8. IANA Considerations 634 The keywords "PRIVATE USE", "SPECIFICATION REQUIRED" and "IETF 635 CONSENSUS" that appear in this document when used to describe 636 namespace allocation are to be interpreted as described in [RFC2434]. 638 8.1. Key Labels 640 This specification introduces a new name space for "USRK key labels". 641 Key labels are of one of two formats: "label-string" or 642 "label-string@specorg" (without the double quotes). 644 Labels of the form "label-string" registered by the IANA MUST be 645 printable US-ASCII strings, and MUST NOT contain the characters at- 646 sign ("@"), comma (","), whitespace, control characters (ASCII codes 647 32 or less), or the ASCII code 127 (DEL). Labels are case-sensitive, 648 and MUST NOT be longer than 64 characters. Labels of this form are 649 assigned based on the IETF CONSENSUS policy. 651 Labels with the at-sign in them of the form "label-string@specorg" 652 where the part preceding the at-sign is the label. The format of the 653 part preceding the at-sign is not specified; however, these labels 654 MUST be printable US-ASCII strings, and MUST NOT contain the comma 655 character (","), whitespace, control characters (ASCII codes 32 or 656 less), or the ASCII code 127 (DEL). They MUST have only a single at- 657 sign in them. The part following the at-sign MUST be a valid, fully 658 qualified Internet domain name [RFC1034] controlled by the person or 659 organization defining the label. Labels are case-sensitive, and MUST 660 NOT be longer than 64 characters. It is up to each organization how 661 it manages its local namespace. Note that the total number of octets 662 in a label is limited to 255. It has been noted that these labels 663 resemble STD 11 [RFC0822] addresses and network access identifiers 664 (NAI) defined in [RFC4282]. This is purely coincidental and has 665 nothing to do with STD 11 [RFC0822] or [RFC4282]. An example of a 666 key label is "service@example.com" (without the double quotes). 668 Labels within the "ietf.org" organization are assigned based on the 669 IETF CONSENSUS policy with specification recommended. Labels from 670 other organizations may be registered with IANA by the person or 671 organization controlling the domain with an assignment policy of 672 SPECIFICATION REQUIRED. It is RECOMMENDED that the specification 673 contain the following information: 675 The following labels are reserved by this document: "EMSK", 676 "dsrk@ietf.org". 678 o A description of the usage 679 o The key label to be used 680 o Length of the Root Key 681 o If optional data is used, what it is and how it is maintained 682 o How child keys will be derived from the Root Key and how they will 683 be used 684 o How lifetime of the Root Key and its child keys will be managed 685 o Where the Root Keys or child keys will be used and how they are 686 communicated if necessary 688 8.2. PRF numbers 690 This specification introduces a new number space for "EMSK PRF 691 numbers". The numbers are int he range 0 to 255 Numbers from 0 to 692 220 are assigned through the policy IETF CONSENSUS and numbers in the 693 range 221 to 255 are left for PRIVATE USE. The initial registry 694 should contain the following values: 696 0 RESERVED 697 1 HMAC-SHA-256 PRF+ (Default) 699 9. Acknowledgements 701 This document expands upon previous collaboration with Pasi Eronen. 702 This document reflects conversations with Bernard Aboba, Jari Arkko, 703 Avi Lior, David McGrew, Henry Haverinen, Hao Zhou, Russ Housley, Glen 704 Zorn, Charles Clancy, Dan Harkins, Alan DeKok, Yoshi Ohba and members 705 of the EAP and HOKEY working groups. 707 Thanks to Dan Harkins for the idea of using a single root key name to 708 refer to all keys. 710 10. References 712 10.1. Normative References 714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 715 Requirement Levels", BCP 14, RFC 2119, March 1997. 717 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 718 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 719 October 1998. 721 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 722 Levkowetz, "Extensible Authentication Protocol (EAP)", 723 RFC 3748, June 2004. 725 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 726 RFC 4306, December 2005. 728 [SHA256] National Institute of Standards and Technology, "Secure 729 Hash Standard", FIPS 180-2, August 2002. 731 With Change Notice 1 dated February 2004 733 10.2. Informative References 735 [I-D.ietf-eap-keying] 736 Aboba, B., Simon, D., and P. Eronen, "Extensible 737 Authentication Protocol (EAP) Key Management Framework", 738 draft-ietf-eap-keying-22 (work in progress), 739 November 2007. 741 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 742 text messages", STD 11, RFC 822, August 1982. 744 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 745 STD 13, RFC 1034, November 1987. 747 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 748 Network Access Identifier", RFC 4282, December 2005. 750 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 751 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 753 [SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to 754 Authenticated Diffie-Hellman and its Use in the IKE 755 Protocols", LNCS 2729, Springer, 2003. 757 Available at http://www.informatik.uni-trier.de/~ley/db/ 758 conf/crypto/crypto2003.html 760 Authors' Addresses 762 Joseph Salowey 763 Cisco Systems 765 Email: jsalowey@cisco.com 766 Lakshminath Dondeti 767 Qualcomm, Inc 769 Email: ldondeti@qualcomm.com 771 Vidya Narayanan 772 Qualcomm, Inc 774 Email: vidyan@qualcomm.com 776 Madjid Nakhjiri 777 Motorola 779 Email: madjid.nakhjiri@motorola.com 781 Full Copyright Statement 783 Copyright (C) The IETF Trust (2008). 785 This document is subject to the rights, licenses and restrictions 786 contained in BCP 78, and except as set forth therein, the authors 787 retain all their rights. 789 This document and the information contained herein are provided on an 790 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 791 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 792 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 793 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 794 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 795 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 797 Intellectual Property 799 The IETF takes no position regarding the validity or scope of any 800 Intellectual Property Rights or other rights that might be claimed to 801 pertain to the implementation or use of the technology described in 802 this document or the extent to which any license under such rights 803 might or might not be available; nor does it represent that it has 804 made any independent effort to identify any such rights. Information 805 on the procedures with respect to rights in RFC documents can be 806 found in BCP 78 and BCP 79. 808 Copies of IPR disclosures made to the IETF Secretariat and any 809 assurances of licenses to be made available, or the result of an 810 attempt made to obtain a general license or permission for the use of 811 such proprietary rights by implementers or users of this 812 specification can be obtained from the IETF on-line IPR repository at 813 http://www.ietf.org/ipr. 815 The IETF invites any interested party to bring to its attention any 816 copyrights, patents or patent applications, or other proprietary 817 rights that may cover technology that may be required to implement 818 this standard. Please address the information to the IETF at 819 ietf-ipr@ietf.org. 821 Acknowledgment 823 Funding for the RFC Editor function is provided by the IETF 824 Administrative Support Activity (IASA).