idnits 2.17.1 draft-salowey-eap-emsk-deriv-01.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 on line 692. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 682. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that usage definitions MUST not concern themselves with the details of the PRF construction or the PRF selection, they only need to worry about the inputs specified in Section 3. -- 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 19, 2006) is 6515 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' == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-13 -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) Summary: 5 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 Expires: December 21, 2006 L. Dondeti 5 V. Narayanan 6 Qualcomm, Inc 7 M. Nakhjiri 8 Motorola Labs 9 June 19, 2006 11 Specification for the Derivation of Usage Specific Root Keys (USRK) from 12 an Extended Master Session Key (EMSK) 13 draft-salowey-eap-emsk-deriv-01.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 December 21, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 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 document 50 specifies a mechanism for deriving cryptographically separate root 51 keys from the EMSK, called usage specific root Keys (USRK). The 52 document provides a set of requirements for avoiding conflicts 53 between usage definitions to ensure this cryptographic separation. 54 The USRK is used according to the usage definition defined for a 55 specific purpose. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Cryptographic Separation and Coordinated Key Derivation . . . 4 62 3. USRK Key Derivation Framework . . . . . . . . . . . . . . . . 5 63 3.1 The USRK Key Derivation Function . . . . . . . . . . . . 6 64 3.2 Default PRF . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.3 Key Naming and Application Data . . . . . . . . . . . . . 8 66 4. Requirements for Usage Definitions . . . . . . . . . . . . . . 8 67 4.1 USRK Management Guidelines . . . . . . . . . . . . . . . . 9 68 5. Requirements for EAP System . . . . . . . . . . . . . . . . . 10 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 6.1 Key strength . . . . . . . . . . . . . . . . . . . . . . . 10 71 6.2 Cryptographic separation of keys . . . . . . . . . . . . . 10 72 6.3 Implementation . . . . . . . . . . . . . . . . . . . . . . 11 73 6.4 Key Distribution . . . . . . . . . . . . . . . . . . . . . 11 74 6.5 Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 11 75 6.6 Entropy consideration . . . . . . . . . . . . . . . . . . 11 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 7.1 USRK Key Labels . . . . . . . . . . . . . . . . . . . . . 12 78 7.2 PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 13 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 9.1 Normative References . . . . . . . . . . . . . . . . . . . 13 82 9.2 Informative References . . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 84 Intellectual Property and Copyright Statements . . . . . . . . 16 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 assume that the MSK keying material produced by EAP will be used for 93 a single purpose at a single device, however it does reserve the EMSK 94 for 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 called usage specific root keys (USRK). This document also 97 provides guidelines for creating usage definitions for the various 98 applications of EAP key material and for the management of the USRKs. 99 Note that previously USRKs were referred to as application master 100 session keys (AMSKs), however this term proved to be confusing as it 101 suggest a particular class of usages dealing with higher layer 102 applications that it was not limited to serve. In this document 103 terms application and usage (or "usage definition") to refer to a 104 specific use case of the EAP keying material for which a USRK is 105 derived. 107 111 Different applications for keys derived from the EMSK have been 112 proposed. Some examples include hand off across access points in 113 various mobile technologies, mobile IP authentication and higher 114 layer application authentication. In order for a particular 115 application of EAP key material to make use of this specification it 116 must specify a usage definition. This document does not define how 117 applications should use the derived USRKs or discuss whether such 118 uses are valid. It does define a framework for the derivation of 119 USRKs for different purposes such that different applications can be 120 developed independently from one another. The goal is to have 121 security properties of one usage have minimal affect on the security 122 properties of other usages. 124 In order to keep specific uses separate from one another two 125 requirements are defined in the following sections. One is 126 coordinated key derivation and another is cryptographic 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 a 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 constrains on the types of applications 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 as specified in this document. It is used to derive 149 child keys in a way defined by its usage definition. 150 153 2. Cryptographic Separation and Coordinated Key Derivation 155 The EMSK is used to derive keys for multiple use cases, and thus it 156 is required that the derived keys are cryptographically separate. 157 Cryptographic separation means that when multiple keys are derived 158 from an EMSK, given any derived key it is computationally infeasible 159 to derive any of the other derived keys. Note that deriving the EMSK 160 from any combinations of the derived keys must also be 161 computationally infeasible. In practice this means that derivation 162 of an EMSK from a derived key or derivation of one child key from 163 another must require an amount of computation equivalent to that 164 required to say reversing a cryptographic hash function. 166 Cryptographic separation of keys derived from the same key can be 167 achieved in many ways. Two obvious methods are as follows: it is 168 plausible to use the IKEv2 PRF on the EMSK and generate a key stream. 169 Keys of various lengths as required may be provided from the key 170 stream for various uses. The other option is to derive keys from 171 EMSK by providing different inputs to the PRF. However, it is 172 desirable that derivation of one child key from the EMSK is 173 independent of derivation of another child key. This allows child 174 keys to be derived in any order, independent of other keys. Thus it 175 is desirable to the second option from above. That implies the 176 additional input to the PRF must be different for each child key 177 derivation. This additional input to the PRF must be coordinated 178 properly to meet the requirement of cryptographic separation and to 179 prevent reuse of key material between usages. 181 If cryptographic separation is not maintained then the security of 182 one usage depends upon the security of all other usages that use key 183 derived from the EMSK. If a system does not have this property then 184 a usage's security depends upon all other applications deriving keys 185 from the same EMSK, which is undesirable. In order to prevent 186 security problems in one application from interfering with another 187 application the following cryptographic separation is required: 189 o It MUST be computationally infeasible to compute the EMSK from any 190 USRK. 191 o Any USRK must be cryptographically separate from any other USRK 192 derived from the same EMSK 193 o Derivation of USRKs must be coordinated so that two separate 194 cryptographic usages do not derive the same key. 196 This document provides guidelines for a mechanism, which can be used 197 with existing and new EAP methods and applications to provide 198 cryptographic separation between applications of EAP keying material. 199 This allows for the development of new usages without cumbersome 200 coordination between different usage definitions. 202 3. USRK Key Derivation Framework 204 The USRK key derivation framework provides a coordinated means for 205 generating multiple usage specific root keys (USRKs) from an EMSK. 206 Further keys may then be derived from the USRK for various purposes, 207 including encryption, integrity protection, entity authentication by 208 way of proof of possession, and subsequent key derivation. The 209 usages of the USRK are set forth in a usage definition described in 210 Section 4. 212 The USRK key derivation function (KDF) derives an USRK from the 213 Extended Master Session Key (EMSK) described above, an key label, 214 optional data, and output length. The KDF is expected to give the 215 same output for the same input. The basic key derivation function is 216 given below. 218 USRK = KDF(EMSK, key label, optional data, length) 220 The key labels are printable ASCII strings unique for each usage 221 definition and are a maximum of 255 bytes. In general they are of 222 the form label-string@domain where domain is the organization that 223 controls the specification of the usage definition of the USRK. The 224 key label is intended to provide global uniqueness. Rules for the 225 allocation of these labels are given in Section 7. For the optional 226 data the KDF MUST be capable of processing at least 2048 opaque 227 octets. The length is a 2 byte unsigned integer in network byte 228 order. An implementation of the KDF MUST be capable of producing at 229 least 2048 octets of output, however it is RECOMMENDED that USRKs be 230 64 octets long. 232 A usage definition requiring derivation of an USRK, must specify the 233 all inputs (other than EMSK) to the key derivation function. 235 3.1 The USRK Key Derivation Function 237 The EMSK key derivation function is based on a pseudo random function 238 (PRF) that has the following function prototype: 240 KDF = PRF(key, data) 242 254 where: 256 key = EMSK 257 data = label + "\0" + op-data + length 258 label = ASCII key label 259 op-data = optional data 260 length = 2 byte unsigned integer in network byte order 261 '\0' = is a NUL byte (0x00 in hex) 262 + denotes concatenation 264 The NUL byte after the key label is used to avoid collisions if one 265 key label is a prefix of another label (e.g. "foobar" and 266 "foobarExtendedV2"). This is considered a simpler solution than 267 requiring a key label assignment policy that prevents prefixes from 268 occurring. 270 This specification allows for the use of different PRFs, however in 271 order to have a coordinated key derivation function the same PRF 272 function MUST be used for all key derivations for a given EMSK. If 273 no PRF is specified then the default PRF specified in Section 3.2 274 MUST be used. A system may provide the capability to negotiate 275 additional PRFs. PRFs are assigned numbers through IANA following 276 the policy set in section Section 7. The rules for negotiating a PRF 277 are as follows: 279 o The initial authenticated key exchange MAY specify a favored PRF 280 as a hint. For example an EAP method may define a preferred PRF 281 to use in its specification. 282 o If the authenticated EAP key exchange is carried within another 283 lower layer protocol that has negotiation capabilities then this 284 protocol MAY attempt to negotiate a PRF to use. 288 o If no other PRF is specified the PRF specified in this document 289 MUST be used. 290 o If the initial authenticated key exchange specifies a PRF then 291 this MUST override the default PRF. 292 o A system MAY specify a separate default PRF if all participants 293 within the system have the knowledge of which PRF to use. If 294 specified this MUST take precedence over key exchange defined PRF. 295 o If the system allows a lower layer protocol to negotiates a PRF 296 then the negotiated PRF MUST be used. It SHOULD take into account 297 any hints that are provide by the authenticated key exchange. 298 Note that this capability MUST protect against bidding down 299 attacks. 301 Note that usage definitions MUST not concern themselves with the 302 details of the PRF construction or the PRF selection, they only need 303 to worry about the inputs specified in Section 3. 305 3.2 Default PRF 307 The default PRF used for deriving USRKs from an EMSK is taken from 308 the PRF+ key expansion PRF from [RFC4306] based on HMAC-SHA-256 309 [SHA256]. The prf+ construction was chosen because of its simplicity 310 and efficiency over other PRFs such as those used in [RFC2246]. The 311 motivation for the design of this PRF is described in [SIGMA]. The 312 definition of PRF+ from [RFC4306]is given below: 314 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 316 Where: 318 T1 = prf (K, S | 0x01) 319 T2 = prf (K, T1 | S | 0x02) 320 T3 = prf (K, T2 | S | 0x03) 321 T4 = prf (K, T3 | S | 0x04) 323 continuing as needed to compute the required length of key material. 324 The key, K, is the EMSK and S is the data defined in Section 3.1. 325 For this specification the PRF is taken as HMAC-SHA-256 [SHA256]. 326 Since PRF+ is only defined for 255 iterations it may produce up to 327 8160 bytes of key material. 329 3.3 Key Naming and Application Data 331 It is RECOMMENDED that the authenticated key exchange export a value, 332 an EAP Session-ID, that is known to both sides to provide a way to 333 identify the exchange and the keys derived by the exchange. The EAP 334 keying framework [I-D.ietf-eap-keying] defines this value and 335 provides an example of how to name an EMSK. The use of names based 336 on the Session-ID in [I-D.ietf-eap-keying] is RECOMMENDED. 338 It is RECOMMENDED that each root key has a name derived as follows: 340 USRK key name = prf-64( EAP Session-ID, key-label ) 342 where prf-64 is the first 64 bits from the output 344 Usage definitions MAY use the EAP session-ID in the specification of 345 the optional data parameter that go into the KDF function. This 346 provides the advantage of providing data into the key derivation that 347 is unique to the session that generated the keys. 349 4. Requirements for Usage Definitions 351 In order for a usage definition to meet the guidelines for USRK usage 352 it must meet the following recommendations: 354 o The usage definition MUST NOT use the EMSK in any other way except 355 to derive usage specific root Keys (USRK) using the key derivation 356 specified in Section 3 of this document. They MUST NOT use the 357 EMSK directly. 358 o The usage definition SHOULD NOT require caching of the EMSK. It 359 is RECOMMENDED that the USRK derived specifically for the usage 360 definition rather than the EMSK should be used as a root key to 361 derive child keys for specific cryptographic operations. 362 o Usage definition MUST define distinct key labels and optional data 363 used in the key derivation described in Section 3. Usage 364 definitions are encouraged to use the key name described in 365 Section 3.3 and include additional data in the optional data to 366 provide additional entropy. 367 o Usage definitions MUST define the length of their USRK. It is 368 RECOMMENDED that the USRK be at least as long as the EMSK (64 369 bytes). 371 o Usage definitions MUST define how they use their USRK. This 372 includes aspects of key management covered in the next section on 373 USRK Management guidelines. 375 4.1 USRK Management Guidelines 377 In this section makes recommendations for various aspects of key 378 management of the USRK including lifetime, child key derivation, 379 caching and transport. 381 It is RECOMMENDED that the USRK only used as a root key for deriving 382 child keys. A usage definition must specify how and when the 383 derivation of child keys should be done. It is RECOMMENDED that 384 usages following similar considerations for key derivation as are 385 outlined in this document for the USRK derivation with respect to 386 cryptographic separation and key reuse. In addition usages should 387 take into consideration the number of keys that will be derived from 388 the USRK and ensure that the enough entropy is introduced in the 389 derivation to support this usage. It is desirable that the entropy 390 is provided by the two parties that derive the child key. 392 USRKs have the same lifetime as the EMSK. Thus, when the EMSK 393 expires the USRKs derived from it should be removed from use. If a 394 new EMSK is derived from a subsequent EAP transaction then an usage 395 implementation should begin to use the new USRK derived from the new 396 EMSK as soon as possible. Whether or not child keys associated with 397 an USRK are replaced depends on the requirements of the usage 398 definition. It is conceivable that some usage definition force the 399 child key to be replaced and others to allow child keys to be used 400 based on the policy of the entities that use the child key. 402 405 Recall that the EMSK never leaves the EAP peer and server. That also 406 holds true for some USRKs; however, some USRKs may be provided to 407 other entities for child key derivation and delivery. Each usage 408 definition specification will specify delivery caching and/or 409 delivery procedures. Note that the purpose of the key derivation in 410 Section 3 is to ensure that USRKs are cryptographically separate from 411 each other and the EMSK. In other words, given an USRK, it is 412 computationally infeasible to derive the EMSK, any other USRKs, or 413 child keys associated with other USRKs. In addition to the USRK, 414 several other parameters may need to be sent. An USRK name should be 415 derived from the EMSK key name, and thus the key name needs to be 416 sent along with the key. When USRKs are delivered to another entity, 417 the lifetime associated with the specific root keys MUST also be 418 transported to that entity. 420 Usage definition may also define how keys are bound to particular 421 usages entities. This can be done through the inclusion of usage 422 parameters and identities in the child key derivation. Some of this 423 data is described as "channel bindings" in [RFC3748]. 425 5. Requirements for EAP System 427 The system that wishes to make use of EAP USRKs must take certain 428 things into consideration. The following is a list of these 429 considerations: 431 o The EMSK MUST NOT be used for any other purpose than the key 432 derivation described in this document. 433 o The EMSK MUST be secret and not known to someone observing the 434 authentication mechanism protocol exchange. 435 o The EMSK MUST be maintained within a protected location inside the 436 entity where it is generated. Only keys (USRKs) derived according 437 to this specification may be exported from this boundary. 438 o The EMSK MUST be unique for each session 439 o The EAP method MUST provide an identifier for the EAP transaction 440 that generated the key 441 o The system MUST define which usage definitions are used and how 442 they are invoked. 443 o The system may define ways to select an alternate PRF for key 444 derivation as defined in Section 3.1. 446 The system MAY use the MSK transmitted to the NAS in any way it 447 chooses. This is required for backward compatibility. New usage 448 definitions following this specification MUST NOT use the MSK. If 449 more than one usage uses the MSK, then the cryptographic separation 450 is not achieved. Implementations MUST prevent such combinations. 452 6. Security Considerations 454 6.1 Key strength 456 The effective key strength of the derived keys will never be greater 457 than the strength of the EMSK (or a master key internal to an EAP 458 mechanism). 460 6.2 Cryptographic separation of keys 462 The intent of the KDF is to derive keys that are cryptographically 463 separate: the compromise of one of the usage specific root keys 464 (USRKs) should not compromise the security of other USRKs or the 465 EMSK. It is believed that the KDF chosen provides the desired 466 separation. 468 6.3 Implementation 470 An implementation of an EAP framework should keep the EMSK internally 471 as close to where it is derived as possible and only provide an 472 interface for obtaining USRKs. It may also choose to restrict which 473 callers have access to which keys. A usage definition MUST NOT 474 assume that any entity outside the EAP server or EAP peer EAP 475 framework has access to the EMSK. In particular it MUST NOT assume 476 that a lower layer has access to the EMSK. 478 6.4 Key Distribution 480 In some cases it will be necessary or convenient to distribute USRKs 481 from where they are generated. Since these are secret keys they MUST 482 be transported with their integrity and confidentiality maintained. 483 They MUST be transmitted between authenticated and authorized 484 parties. It is also important that the context of the key usage be 485 transmitted along with the key. This includes information to 486 identify the key and constraints on its usage such as lifetime. 488 This document does not define a mechanism for key transport. It is 489 up to usage definitions and the systems that use them to define how 490 keys are distributed. Usage definition designers may enforce 491 constraints on key usage by various parties by deriving a key 492 hierarchy and by providing entities only with the keys in the 493 hierarchy that they need. 495 6.5 Key Lifetime 497 The key lifetime is dependent upon how the key is generated and how 498 the key is used. Since the USRK is the responsibility of the usage 499 definition it must determine how long the key is valid for. If key 500 lifetime or key strength information is available from the 501 authenticated key exchange then this information SHOULD be used in 502 determining the lifetime of the key. If possible it is recommended 503 that key lifetimes be coordinated throughout the system. Setting a 504 key lifetime shorter that a system lifetime may result is keys 505 becoming invalid with no convenient way to refresh them. Setting a 506 key lifetime to longer may result in decreased security since the key 507 may be used beyond its recommended lifetime. 509 6.6 Entropy consideration 511 The number of root keys derived from the EMSK is expected to be low. 512 Note that there is no randomness required to be introduced into the 513 EMSK to root key derivation beyond the root key labels. Thus, if 514 many keys are going to be derived from an USRK it is important that 515 USRK to child key derivation introduce fresh random numbers in 516 deriving each key. 518 7. IANA Considerations 520 The keywords "PRIVATE USE", "SPECIFICATION REQUIRED" and "IETF 521 CONSENSUS" that appear in this document when used to describe 522 namespace allocation are to be interpreted as described in [RFC2434]. 524 7.1 USRK Key Labels 526 This specification introduces a new name space for "USRK key labels". 527 Key labels are of one of two formats: "label-string" or 528 "label-string@domain" (without the double quotes). 530 Labels of the form "label-string" registered by the IANA MUST be 531 printable US-ASCII strings, and MUST NOT contain the characters at- 532 sign ("@"), comma (","), whitespace, control characters (ASCII codes 533 32 or less), or the ASCII code 127 (DEL). Labels are case-sensitive, 534 and MUST NOT be longer than 64 characters. Labels of this form are 535 assigned based on the IETF CONSENSUS policy. 537 Labels with the at-sign in them of the form "label-string@domain" 538 where the part preceding the at-sign is the label. The format of the 539 part preceding the at-sign is not specified; however, these labels 540 MUST be printable US-ASCII strings, and MUST NOT contain the comma 541 character (","), whitespace, control characters (ASCII codes 32 or 542 less), or the ASCII code 127 (DEL). They MUST have only a single at- 543 sign in them. The part following the at-sign MUST be a valid, fully 544 qualified internet domain name [RFC1034] controlled by the person or 545 organization defining the label. Labels are case-sensitive, and MUST 546 NOT be longer than 64 characters. It is up to each domain how it 547 manages its local namespace. Note that the total number of octets in 548 a label is limited to 255. It has been noted that these labels 549 resemble STD 11 [RFC0822] addresses and network access identifiers 550 (NAI) defined in [RFC4282]. This is purely coincidental and has 551 nothing to do with STD 11 [RFC0822] or [RFC4282]. An example of a 552 locally defined label is "service@example.com" (without the double 553 quotes). 555 Labels within the "ietf.org" domain are assigned based on the IETF 556 CONSENSUS policy with specification recommended. Labels from other 557 domains may be registered with IANA by the person or organization 558 controlling the domain with an assignment policy of SPECIFICATION 559 REQUIRED. It is RECOMMENDED that the specification contain the 560 following information: 562 o A description of the usage 563 o The key label to be used 564 o Length of the USRK 565 o If optional data is used, what it is and how it is maintained 566 o How child keys will be derived from the USRK and how they will be 567 used 568 o How lifetime of the USRK and its child keys will be managed 569 o Where the USRKs or child keys will be used and how they are 570 communicated if necessary 572 7.2 PRF numbers 574 This specification introduces a new number space for "EMSK PRF 575 numbers". The numbers are int he range 0 to 255 Numbers from 0 to 576 220 are assigned through the policy IETF CONSENSUS and numbers in the 577 range 221 to 255 are left for PRIVATE USE. The initial registry 578 should contain the following values: 580 0 RESERVED 581 1 HMAC-SHA-256 PRF+ (Default) 583 8. Acknowledgements 585 This document expands upon previous collaboration with Pasi Eronen. 586 This document reflects conversations with Bernard Aboba, Jari Arkko, 587 Avi Lior, David McGrew, Henry Haverinen, Hao Zhou and members of the 588 EAP working group. 590 9. References 592 9.1 Normative References 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, March 1997. 597 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 598 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 599 October 1998. 601 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 602 Levkowetz, "Extensible Authentication Protocol (EAP)", 603 RFC 3748, June 2004. 605 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 606 RFC 4306, December 2005. 608 [SHA256] National Institute of Standards and Technology, "Secure 609 Hash Standard", FIPS 180-2, August 2002. 611 With Change Notice 1 dated February 2004 613 9.2 Informative References 615 [I-D.ietf-eap-keying] 616 Aboba, B., "Extensible Authentication Protocol (EAP) Key 617 Management Framework", draft-ietf-eap-keying-13 (work in 618 progress), May 2006. 620 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 621 text messages", STD 11, RFC 822, August 1982. 623 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 624 STD 13, RFC 1034, November 1987. 626 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 627 RFC 2246, January 1999. 629 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 630 Network Access Identifier", RFC 4282, December 2005. 632 [SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to 633 Authenticated Diffie-Hellman and its Use in the IKE 634 Protocols", LNCS 2729, Springer, 2003. 636 Available at http://www.informatik.uni-trier.de/~ley/db/ 637 conf/crypto/crypto2003.html 639 Authors' Addresses 641 Joseph Salowey 642 Cisco Systems 644 Email: jsalowey@cisco.com 646 Lakshminath Dondeti 647 Qualcomm, Inc 649 Email: ldondeti@qualcomm.com 650 Vidya Narayanan 651 Qualcomm, Inc 653 Email: vidyan@qualcomm.com 655 Madjid Nakhjiri 656 Motorola Labs 658 Email: Madjid.nakhjiri@motorola.com 660 Intellectual Property Statement 662 The IETF takes no position regarding the validity or scope of any 663 Intellectual Property Rights or other rights that might be claimed to 664 pertain to the implementation or use of the technology described in 665 this document or the extent to which any license under such rights 666 might or might not be available; nor does it represent that it has 667 made any independent effort to identify any such rights. Information 668 on the procedures with respect to rights in RFC documents can be 669 found in BCP 78 and BCP 79. 671 Copies of IPR disclosures made to the IETF Secretariat and any 672 assurances of licenses to be made available, or the result of an 673 attempt made to obtain a general license or permission for the use of 674 such proprietary rights by implementers or users of this 675 specification can be obtained from the IETF on-line IPR repository at 676 http://www.ietf.org/ipr. 678 The IETF invites any interested party to bring to its attention any 679 copyrights, patents or patent applications, or other proprietary 680 rights that may cover technology that may be required to implement 681 this standard. Please address the information to the IETF at 682 ietf-ipr@ietf.org. 684 Disclaimer of Validity 686 This document and the information contained herein are provided on an 687 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 688 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 689 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 690 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 691 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 692 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 694 Copyright Statement 696 Copyright (C) The Internet Society (2006). This document is subject 697 to the rights, licenses and restrictions contained in BCP 78, and 698 except as set forth therein, the authors retain all their rights. 700 Acknowledgment 702 Funding for the RFC Editor function is currently provided by the 703 Internet Society.