idnits 2.17.1 draft-ietf-hokey-emsk-hierarchy-03.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 755. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 766. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 773. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 779. 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 (January 9, 2008) is 5924 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 (~~), 2 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 Intended status: Standards Track L. Dondeti 5 Expires: July 12, 2008 V. Narayanan 6 Qualcomm, Inc 7 M. Nakhjiri 8 Motorola 9 January 9, 2008 11 Specification for the Derivation of Root Keys from an Extended Master 12 Session Key (EMSK) 13 draft-ietf-hokey-emsk-hierarchy-03.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 July 12, 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 . . . . . . . . . . . . . . 5 61 3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 6 62 3.2. The USRK Derivation Function . . . . . . . . . . . . . . . 7 63 3.3. Default PRF . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.4. Key Naming and Usage Data . . . . . . . . . . . . . . . . 8 65 4. Domain Specific Root Key Derivation . . . . . . . . . . . . . 9 66 5. Requirements for Usage Definitions . . . . . . . . . . . . . . 10 67 5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 11 68 6. Requirements for EAP System . . . . . . . . . . . . . . . . . 12 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 12 71 7.2. Cryptographic separation of keys . . . . . . . . . . . . . 12 72 7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 13 73 7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 13 74 7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 13 75 7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 13 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 14 78 8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 15 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 84 Intellectual Property and Copyright Statements . . . . . . . . . . 18 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 either for specific purposes called usages. This document 97 also provides guidelines for creating usage definitions for the 98 various uses of EAP key material and for the management of the root 99 keys. In this document, the terms application and usage (or "usage 100 definition") refer to a specific use case of the EAP keying material. 102 Different uses for keys derived from the EMSK have been proposed. 103 Some examples include hand off across access points in various mobile 104 technologies, mobile IP authentication and higher layer application 105 authentication. In order for a particular usage of EAP key material 106 to make use of this specification it must specify a so-called usage 107 definition. This document does not define how the derived Usage 108 Specific Root Keys (USRK) should be used or discuss what types of use 109 cases are valid. It does define a framework for the derivation of 110 USRKs for different purposes such that different usages can be 111 developed independently from one another. The goal is to have 112 security properties of one usage have minimal or no effect on the 113 security properties of other usages. 115 This document does define a special class of USRK, called a Domain 116 Specific Root Key (DSRK) for use in deriving keys specific to a key 117 management domain. Each DSRK is a root key used to derive Domain 118 Specific Usage Specific Root Keys (DSUSRK). The DSUSRKs are USRKs 119 specific to a particular key management domain. 121 In order to keep root keys for specific purposes separate from one 122 another two requirements are defined in the following sections. One 123 is coordinated key derivation and another is cryptographic 124 separation. 126 1.1. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119] 132 The following terms are taken from [RFC3748]: EAP Server, peer, 133 authenticator, Master Session Key (MSK), Extended Master Session Key 134 (EMSK), Cryptographic Separation. 136 Usage Definition 137 An application of cryptographic key material to provide one or 138 more security functions such as authentication, authorization, 139 encryption or integrity protection for related applications or 140 services. This document provides guidelines and recommendations 141 for what should be included in usage definitions. This document 142 does not place any constrains on the types of use cases or 143 services that create usage definitions. 145 Usage Specific Root Key (USRK) 146 Keying material derived from the EMSK for a particular usage 147 definition. It is used to derive child keys in a way defined by 148 its usage definition. 150 Key Management Domain 151 A key management domain is specified by the scope of a given root 152 key. The scope is the collection of systems authorized to access 153 key material derived from that key. Systems within a key 154 management domain may be authorized to (1) derive key materials, 155 (2) use key materials, or (3) distribute key materials to other 156 systems in the same domain. A derived key's scope is constrained 157 to a subset of the scope of the key it is derived from. In this 158 document the term domain refers to a key management domain unless 159 otherwise qualified. 161 Domain Specific Root Key (DSRK) 162 Keying material derived from the EMSK that is restricted to use in 163 a specific key management domain. It is used to derive child keys 164 for a particular usage definition. The child keys derived from a 165 DSRK are referred to as domain specific usage specific root keys 166 (DSUSRK). DSUSRKs are similar to the USRK, except in the fact 167 that their scope is restricted to the same domain as the parent 168 DSRK from which it is derived. 170 2. Cryptographic Separation and Coordinated Key Derivation 172 The EMSK is used to derive keys for multiple use cases, and thus it 173 is required that the derived keys are cryptographically separate. 174 Cryptographic separation means that when multiple keys are derived 175 from an EMSK, given any derived key it is computationally infeasible 176 to derive any of the other derived keys. Note that deriving the EMSK 177 from any combinations of the derived keys must also be 178 computationally infeasible. In practice this means that derivation 179 of an EMSK from a derived key or derivation of one child key from 180 another must require an amount of computation equivalent to that 181 required to, say, reversing a cryptographic hash function. 183 Cryptographic separation of keys derived from the same key can be 184 achieved in many ways. Two obvious methods are as follows: it is 185 plausible to use the IKEv2 PRF [RFC4306] on the EMSK and generate a 186 key stream. Keys of various lengths may be provided as required from 187 the key stream for various uses. The other option is to derive keys 188 from EMSK by providing different inputs to the PRF. However, it is 189 desirable that derivation of one child key from the EMSK is 190 independent of derivation of another child key. This allows child 191 keys to be derived in any order, independent of other keys. Thus it 192 is desirable to use the second option from above. That implies the 193 additional input to the PRF must be different for each child key 194 derivation. This additional input to the PRF must be coordinated 195 properly to meet the requirement of cryptographic separation and to 196 prevent reuse of key material between usages. 198 If cryptographic separation is not maintained then the security of 199 one usage depends upon the security of all other usages that use key 200 derived from the EMSK. If a system does not have this property then 201 a usage's security depends upon all other usages deriving keys from 202 the same EMSK, which is undesirable. In order to prevent security 203 problems in one usage from interfering with another usage, the 204 following cryptographic separation is required: 206 o It MUST be computationally infeasible to compute the EMSK from any 207 root key derived from it. 208 o Any root key MUST be cryptographically separate from any other 209 root key derived from the same EMSK or DSRK 210 o Derivation of USRKs MUST be coordinated so that two separate 211 cryptographic usages do not derive the same key. 212 o Derivation of DSRKs MUST be coordinated so that two separate key 213 management domains do not derive the same key. 214 o Derivation of DSRKs and USRKs MUST be specified such that no 215 domain can obtain a USRK by providing a domain name identical to a 216 Usage Key Label. 218 This document provides guidelines for a key derivation mechanism, 219 which can be used with existing and new EAP methods to provide 220 cryptographic separation between usages of EMSK. This allows for the 221 development of new usages without cumbersome coordination between 222 different usage definitions. 224 3. EMSK Key Root Derivation Framework 226 The EMSK key derivation framework provides a coordinated means for 227 generating multiple root keys from an EMSK. Further keys may then be 228 derived from the root key for various purposes, including encryption, 229 integrity protection, entity authentication by way of proof of 230 possession, and subsequent key derivation. A root key is derived 231 from the EMSK for specific set of uses set forth in a usage 232 definition described in Section 5. 234 The basic EMSK root key hierarchy looks as follows: 236 EMSK 237 / \ 238 USRK USRK 240 This document defines how to derive usage specific root keys (USRK) 241 from the EMSK and also defines a specific USRK called a domain 242 specific root key (DSRK). DSRK are root keys restricted to use in a 243 particular key management domain. From the DSRK, usage specific root 244 keys for a particular application may be derived (DSUSRK). The 245 DSUSRKs are equivalent to USRKs that are restricted to use in a 246 particular domain. The details of lower levels of key hierarchy are 247 outside scope of this document. The key hierarchy looks as follows: 249 EMSK 250 / \ 251 USRK DSRK 252 / \ 253 DSUSRK1 DSUSRK2 255 3.1. USRK Derivation 257 The EMSK Root Key derivation function (KDF) derives a USRK from the 258 EMSK, a key label, optional data, and output length. The KDF is 259 expected to give the same output for the same input. The basic key 260 derivation function is given below. 262 USRK = KDF(EMSK, key label, optional data, length) 264 The key labels are printable ASCII strings unique for each usage 265 definition and are a maximum of 255 bytes. In general they are of 266 the form label-string@specorg where specorg is the organization that 267 controls the specification of the usage definition of the Root Key. 268 The key label is intended to provide global uniqueness. Rules for 269 the allocation of these labels are given in Section 8. For the 270 optional data the KDF MUST be capable of processing at least 2048 271 opaque octets. The optional data must be constant during the 272 execution of the KDF. The length is a 2 byte unsigned integer in 273 network byte order of the output key length in octets. An 274 implementation of the KDF MUST be capable of producing at least 2048 275 octets of output, however it is RECOMMENDED that Root Keys be at 276 least 64 octets long. 278 A usage definition requiring derivation of a Root Key must specify 279 all the inputs (other than EMSK) to the key derivation function. 281 3.2. The USRK Derivation Function 283 The USRK key derivation function is based on a pseudo random function 284 (PRF) that has the following function prototype: 286 KDF = PRF(key, data) 288 where: 290 key = EMSK 291 data = label + "\0" + op-data + length 292 label = ASCII key label 293 op-data = optional data 294 length = 2 byte unsigned integer in network byte order 295 '\0' = is a NULL byte (0x00 in hex) 296 + denotes concatenation 298 The NULL byte after the key label is used to avoid collisions if one 299 key label is a prefix of another label (e.g. "foobar" and 300 "foobarExtendedV2"). This is considered a simpler solution than 301 requiring a key label assignment policy that prevents prefixes from 302 occurring. 304 This specification allows for the use of different PRFs. However, in 305 order to have a coordinated key derivation function the same PRF 306 function MUST be used for all key derivations for a given EMSK. If 307 no PRF is specified, then the default PRF specified in Section 3.3 308 MUST be used. A system may provide the capability to negotiate 309 additional PRFs. PRFs are assigned numbers through IANA following 310 the policy set in section Section 8. The rules for negotiating a PRF 311 are as follows: 313 o If no other PRF is specified the PRF specified in this document 314 MUST be used. This is the "default" PRF. 315 o The initial authenticated key exchange MAY specify a favored PRF. 316 For example an EAP method may define a preferred PRF to use in its 317 specification. If the initial authenticated key exchange 318 specifies a PRF then this MUST override the default PRF. 320 o A system MAY specify a separate default PRF if all participants 321 within the system have the knowledge of which PRF to use. If 322 specified this MUST take precedence over key exchange defined PRF. 324 Note that usage definitions MUST NOT concern themselves with the 325 details of the PRF construction or the PRF selection, they only need 326 to worry about the inputs specified in Section 3. 328 3.3. Default PRF 330 The default PRF for deriving root keys from an EMSK is taken from the 331 PRF+ key expansion PRF from [RFC4306] based on HMAC-SHA-256 [SHA256]. 332 The prf+ construction was chosen because of its simplicity and 333 efficiency over other PRFs such as those used in [RFC4346]. The 334 motivation for the design of this PRF is described in [SIGMA]. The 335 definition of PRF+ from [RFC4306]is given below: 337 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 339 Where: 341 T1 = prf (K, S | 0x01) 342 T2 = prf (K, T1 | S | 0x02) 343 T3 = prf (K, T2 | S | 0x03) 344 T4 = prf (K, T3 | S | 0x04) 346 continuing as needed to compute the required length of key material. 347 The key, K, is the EMSK and S is the data defined in Section 3.2. 348 For this specification the PRF is taken as HMAC-SHA-256 [SHA256]. 349 Since PRF+ is only defined for 255 iterations it may produce up to 350 8160 bytes of key material. 352 3.4. Key Naming and Usage Data 354 It is RECOMMENDED that the authenticated key exchange export a value, 355 an EAP Session-ID, that is known to both sides to provide a way to 356 identify the exchange and the keys derived by the exchange. The EAP 357 keying framework [I-D.ietf-eap-keying] defines this value and 358 provides an example of how to name an EMSK. The use of names based 359 on the Session-ID in [I-D.ietf-eap-keying] is RECOMMENDED. 361 It is RECOMMENDED that each USRK has a name derived as follows: 363 USRK Name = SHA-256-64 ( EAP Session-ID | key-label ) 365 where SHA-256-64 is the first 64 bits from the SHA-256 output 367 Usage definitions MAY use the EAP session-ID in the specification of 368 the optional data parameter that go into the KDF function. This 369 provides the advantage of providing data into the key derivation that 370 is unique to the session that generated the keys. 372 4. Domain Specific Root Key Derivation 374 A specific USRK called a Domain Specific Root Key (DSRK) is derived 375 from the EMSK for a specific set of usages in a particular key 376 management domain. Usages derive specific keys for specific services 377 from this DSRK. The DSRK may be distributed to a key management 378 domain for a specific set of usages so keys can be derived within the 379 key management domain for those usages. DSRK based usages will 380 follow a key hierarchy similar to the following: 382 EMSK 383 / \ 384 / \ 385 DSRK1 DSRK2 386 / \ / \ 387 / \ DSUSRK21 DSUSRK22 388 DSUSRK11 DSUSRK12 390 The DSRK is a USRK with a key label of "dsrk@ietf.org" and the 391 optional data containing a domain label. The optional data MUST 392 contain an ASCII string representing the key management domain that 393 the root key is being derived for. The DSRK is MUST be 64 octets 394 long. 396 Domain Specific Usage Specific Root Keys (DSUSRK) are derived from 397 the DSRK. The KDF is expected to give the same output for the same 398 input. The basic key derivation function is given below. 400 DSUSRK = KDF(DSRK, key label, optional data, length) 402 The key labels are printable ASCII strings unique for each usage 403 definition within a DSRK usage and are a maximum of 255 bytes. In 404 general they are of the form label-string@specorg where specorg is 405 the organization that controls the specification of the usage 406 definition of the DSRK. The key label is intended to provide global 407 uniqueness. Rules for the allocation of these labels are given in 408 Section 8. For the optional data the KDF MUST be capable of 409 processing at least 2048 opaque octets. The optional data must be 410 constant during the execution of the KDF. The length is a 2 byte 411 unsigned integer in network byte order of the output key length in 412 octets. An implementation of the KDF MUST be capable of producing at 413 least 2048 octets of output, however it is RECOMMENDED that DSUSRKs 414 be at least 64 octets long. 416 It is RECOMMENDED that each DSUSRK has a name derived as follows: 418 DSUSRK Name = SHA-256-64( DSRK Name | key-label ) 420 where SHA-256-64 is the first 64 bits from the SHA-256 output 422 Usages that make use of the DSRK must define how the peer learns the 423 domain label to use in a particular derivation. A multi-domain usage 424 must define how both DSRKs and specific DSUSRKs are transported to 425 different key management domains. Note that usages may define 426 alternate ways to constrain specific keys to particular key 427 management domains. 429 5. Requirements for Usage Definitions 431 In order for a usage definition to meet the guidelines for USRK usage 432 it must meet the following recommendations: 434 o The usage must define if it is a domain enabled usage. 435 o The usage definition MUST NOT use the EMSK in any other way except 436 to derive Root Keys using the key derivation specified in 437 Section 3 of this document. They MUST NOT use the EMSK directly. 438 o The usage definition SHOULD NOT require caching of the EMSK. It 439 is RECOMMENDED that the Root Key derived specifically for the 440 usage definition rather than the EMSK should be used to derive 441 child keys for specific cryptographic operations. 442 o Usage definition MUST define distinct key labels and optional data 443 used in the key derivation described in Section 3. Usage 444 definitions are encouraged to use the key name described in 445 Section 3.4 and include additional data in the optional data to 446 provide additional entropy. 447 o Usage definitions MUST define the length of their Root Keys. It 448 is RECOMMENDED that the Root Keys be at least as long as the EMSK 449 (at least 64 octets). 450 o Usage definitions MUST define how they use their Root Keys. This 451 includes aspects of key management covered in the next section on 452 Root Key Management guidelines. 454 o 456 5.1. Root Key Management Guidelines 458 This section makes recommendations for various aspects of key 459 management of the Root Key including lifetime, child key derivation, 460 caching and transport. 462 It is RECOMMENDED that the Root Key only used for deriving child 463 keys. A usage definition must specify how and when the derivation of 464 child keys should be done. It is RECOMMENDED that usages following 465 similar considerations for key derivation are as outlined in this 466 document for the Root Key derivation with respect to cryptographic 467 separation and key reuse. In addition, usages should take into 468 consideration the number of keys that will be derived from the Root 469 Key and ensure that enough entropy is introduced in the derivation to 470 support this usage. It is desirable that the entropy is provided by 471 the two parties that derive the child key. 473 Root Keys' lifetimes should not be more than that of the EMSK. Thus, 474 when the EMSK expires, the Root Keys derived from it should be 475 removed from use. If a new EMSK is derived from a subsequent EAP 476 transaction then a usage implementation should begin to use the new 477 Root Keys derived from the new EMSK as soon as possible. Whether or 478 not child keys associated with a Root Key are replaced depends on the 479 requirements of the usage definition. It is conceivable that some 480 usage definition forces the child key to be replaced and others allow 481 child keys to be used based on the policy of the entities that use 482 the child key. 484 Recall that the EMSK never leaves the EAP peer and server. That also 485 holds true for some Root Keys; however, some Root Keys may be 486 provided to other entities for child key derivation and delivery. 487 Each usage definition specification will specify delivery caching 488 and/or delivery procedures. Note that the purpose of the key 489 derivation in Section 3 is to ensure that Root Keys are 490 cryptographically separate from each other and the EMSK. In other 491 words, given a Root Key, it is computationally infeasible to derive 492 the EMSK, any other Root Keys, or child keys associated with other 493 Root Keys. In addition to the Root Key, several other parameters may 494 need to be sent. Root Key name should be derived using the EAP 495 Session ID, and thus the key name needs to be sent along with the 496 key. When Root Keys are delivered to another entity, the lifetime 497 associated with the specific root keys MUST also be transported to 498 that entity. Recommendations for transporting keys are discussed in 499 the security considerations (Section 7.4). 501 Usage definition may also define how keys are bound to particular 502 entities. This can be done through the inclusion of usage parameters 503 and identities in the child key derivation. Some of this data is 504 described as "channel bindings" in [RFC3748]. 506 6. Requirements for EAP System 508 The system that wishes to make use of EAP root keys derived from the 509 EMSK must take certain things into consideration. The following is a 510 list of these considerations: 512 o The EMSK MUST NOT be used for any other purpose than the key 513 derivation described in this document. 514 o The EMSK MUST be secret and not known to someone observing the 515 authentication mechanism protocol exchange. 516 o The EMSK MUST be maintained within a protected location inside the 517 entity where it is generated. Only root keys derived according to 518 this specification may be exported from this boundary. 519 o The EMSK MUST be unique for each EAP session 520 o The EAP method MUST provide an identifier for the EAP transaction 521 that generated the key 522 o The system MUST define which usage definitions are used and how 523 they are invoked. 524 o The system may define ways to select an alternate PRF for key 525 derivation as defined in Section 3.2. 527 The system MAY use the MSK transmitted to the NAS in any way it 528 chooses. This is required for backward compatibility. New usage 529 definitions following this specification MUST NOT use the MSK. If 530 more than one usage uses the MSK, then the cryptographic separation 531 is not achieved. Implementations MUST prevent such combinations. 533 7. Security Considerations 535 7.1. Key strength 537 The effective key strength of the derived keys will never be greater 538 than the strength of the EMSK (or a master key internal to an EAP 539 mechanism). 541 7.2. Cryptographic separation of keys 543 The intent of the KDF is to derive keys that are cryptographically 544 separate: the compromise of one of the usage specific root keys 545 (USRKs) should not compromise the security of other USRKs or the 546 EMSK. It is believed that the KDF chosen provides the desired 547 separation. 549 7.3. Implementation 551 An implementation of an EAP framework should keep the EMSK internally 552 as close to where it is derived as possible and only provide an 553 interface for obtaining Root Keys. It may also choose to restrict 554 which callers have access to which keys. A usage definition MUST NOT 555 assume that any entity outside the EAP server or EAP peer EAP 556 framework has access to the EMSK. In particular it MUST NOT assume 557 that a lower layer has access to the EMSK. 559 7.4. Key Distribution 561 In some cases it will be necessary or convenient to distribute USRKs 562 from where they are generated. Since these are secret keys they MUST 563 be transported with their integrity and confidentiality maintained. 564 They MUST be transmitted between authenticated and authorized 565 parties. It is also important that the context of the key usage be 566 transmitted along with the key. This includes information to 567 identify the key and constraints on its usage such as lifetime. 569 This document does not define a mechanism for key transport. It is 570 up to usage definitions and the systems that use them to define how 571 keys are distributed. Usage definition designers may enforce 572 constraints on key usage by various parties by deriving a key 573 hierarchy and by providing entities only with the keys in the 574 hierarchy that they need. 576 7.5. Key Lifetime 578 The key lifetime is dependent upon how the key is generated and how 579 the key is used. Since the Root Key is the responsibility of the 580 usage definition it must determine how long the key is valid for. If 581 key lifetime or key strength information is available from the 582 authenticated key exchange then this information SHOULD be used in 583 determining the lifetime of the key. If possible it is recommended 584 that key lifetimes be coordinated throughout the system. Setting a 585 key lifetime shorter that a system lifetime may result is keys 586 becoming invalid with no convenient way to refresh them. Setting a 587 key lifetime to longer may result in decreased security since the key 588 may be used beyond its recommended lifetime. 590 7.6. Entropy consideration 592 The number of root keys derived from the EMSK is expected to be low. 593 Note that there is no randomness required to be introduced into the 594 EMSK to root key derivation beyond the root key labels. Thus, if 595 many keys are going to be derived from an Root Key it is important 596 that Root Key to child key derivation introduce fresh random numbers 597 in deriving each key. 599 8. IANA Considerations 601 The keywords "PRIVATE USE", "SPECIFICATION REQUIRED" and "IETF 602 CONSENSUS" that appear in this document when used to describe 603 namespace allocation are to be interpreted as described in [RFC2434]. 605 8.1. Key Labels 607 This specification introduces a new name space for "USRK key labels". 608 Key labels are of one of two formats: "label-string" or 609 "label-string@specorg" (without the double quotes). 611 Labels of the form "label-string" registered by the IANA MUST be 612 printable US-ASCII strings, and MUST NOT contain the characters at- 613 sign ("@"), comma (","), whitespace, control characters (ASCII codes 614 32 or less), or the ASCII code 127 (DEL). Labels are case-sensitive, 615 and MUST NOT be longer than 64 characters. Labels of this form are 616 assigned based on the IETF CONSENSUS policy. 618 Labels with the at-sign in them of the form "label-string@specorg" 619 where the part preceding the at-sign is the label. The format of the 620 part preceding the at-sign is not specified; however, these labels 621 MUST be printable US-ASCII strings, and MUST NOT contain the comma 622 character (","), whitespace, control characters (ASCII codes 32 or 623 less), or the ASCII code 127 (DEL). They MUST have only a single at- 624 sign in them. The part following the at-sign MUST be a valid, fully 625 qualified Internet domain name [RFC1034] controlled by the person or 626 organization defining the label. Labels are case-sensitive, and MUST 627 NOT be longer than 64 characters. It is up to each organization how 628 it manages its local namespace. Note that the total number of octets 629 in a label is limited to 255. It has been noted that these labels 630 resemble STD 11 [RFC0822] addresses and network access identifiers 631 (NAI) defined in [RFC4282]. This is purely coincidental and has 632 nothing to do with STD 11 [RFC0822] or [RFC4282]. An example of a 633 key label is "service@example.com" (without the double quotes). 635 Labels within the "ietf.org" organization are assigned based on the 636 IETF CONSENSUS policy with specification recommended. Labels from 637 other organizations may be registered with IANA by the person or 638 organization controlling the domain with an assignment policy of 639 SPECIFICATION REQUIRED. It is RECOMMENDED that the specification 640 contain the following information: 642 o A description of the usage 643 o The key label to be used 644 o Length of the Root Key 645 o If optional data is used, what it is and how it is maintained 646 o How child keys will be derived from the Root Key and how they will 647 be used 648 o How lifetime of the Root Key and its child keys will be managed 649 o Where the Root Keys or child keys will be used and how they are 650 communicated if necessary 652 8.2. PRF numbers 654 This specification introduces a new number space for "EMSK PRF 655 numbers". The numbers are int he range 0 to 255 Numbers from 0 to 656 220 are assigned through the policy IETF CONSENSUS and numbers in the 657 range 221 to 255 are left for PRIVATE USE. The initial registry 658 should contain the following values: 660 0 RESERVED 661 1 HMAC-SHA-256 PRF+ (Default) 663 9. Acknowledgements 665 This document expands upon previous collaboration with Pasi Eronen. 666 This document reflects conversations with Bernard Aboba, Jari Arkko, 667 Avi Lior, David McGrew, Henry Haverinen, Hao Zhou and members of the 668 EAP working group. 670 10. References 672 10.1. Normative References 674 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 675 Requirement Levels", BCP 14, RFC 2119, March 1997. 677 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 678 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 679 October 1998. 681 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 682 Levkowetz, "Extensible Authentication Protocol (EAP)", 683 RFC 3748, June 2004. 685 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 686 RFC 4306, December 2005. 688 [SHA256] National Institute of Standards and Technology, "Secure 689 Hash Standard", FIPS 180-2, August 2002. 691 With Change Notice 1 dated February 2004 693 10.2. Informative References 695 [I-D.ietf-eap-keying] 696 Aboba, B., Simon, D., and P. Eronen, "Extensible 697 Authentication Protocol (EAP) Key Management Framework", 698 draft-ietf-eap-keying-22 (work in progress), 699 November 2007. 701 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 702 text messages", STD 11, RFC 822, August 1982. 704 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 705 STD 13, RFC 1034, November 1987. 707 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 708 Network Access Identifier", RFC 4282, December 2005. 710 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 711 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 713 [SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to 714 Authenticated Diffie-Hellman and its Use in the IKE 715 Protocols", LNCS 2729, Springer, 2003. 717 Available at http://www.informatik.uni-trier.de/~ley/db/ 718 conf/crypto/crypto2003.html 720 Authors' Addresses 722 Joseph Salowey 723 Cisco Systems 725 Email: jsalowey@cisco.com 727 Lakshminath Dondeti 728 Qualcomm, Inc 730 Email: ldondeti@qualcomm.com 731 Vidya Narayanan 732 Qualcomm, Inc 734 Email: vidyan@qualcomm.com 736 Madjid Nakhjiri 737 Motorola 739 Email: madjid.nakhjiri@motorola.com 741 Full Copyright Statement 743 Copyright (C) The IETF Trust (2008). 745 This document is subject to the rights, licenses and restrictions 746 contained in BCP 78, and except as set forth therein, the authors 747 retain all their rights. 749 This document and the information contained herein are provided on an 750 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 751 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 752 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 753 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 754 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 755 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 757 Intellectual Property 759 The IETF takes no position regarding the validity or scope of any 760 Intellectual Property Rights or other rights that might be claimed to 761 pertain to the implementation or use of the technology described in 762 this document or the extent to which any license under such rights 763 might or might not be available; nor does it represent that it has 764 made any independent effort to identify any such rights. Information 765 on the procedures with respect to rights in RFC documents can be 766 found in BCP 78 and BCP 79. 768 Copies of IPR disclosures made to the IETF Secretariat and any 769 assurances of licenses to be made available, or the result of an 770 attempt made to obtain a general license or permission for the use of 771 such proprietary rights by implementers or users of this 772 specification can be obtained from the IETF on-line IPR repository at 773 http://www.ietf.org/ipr. 775 The IETF invites any interested party to bring to its attention any 776 copyrights, patents or patent applications, or other proprietary 777 rights that may cover technology that may be required to implement 778 this standard. Please address the information to the IETF at 779 ietf-ipr@ietf.org. 781 Acknowledgment 783 Funding for the RFC Editor function is provided by the IETF 784 Administrative Support Activity (IASA).