idnits 2.17.1 draft-ietf-hokey-key-mgm-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 706. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 712. 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 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 (January 31, 2008) is 5930 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) == Missing Reference: 'K' is mentioned on line 363, but not defined == Missing Reference: 'X' is mentioned on line 363, but not defined == Missing Reference: '0-4' is mentioned on line 554, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-hokey-emsk-hierarchy-03 == Outdated reference: A later version (-14) exists of draft-ietf-hokey-erx-08 ** Downref: Normative reference to an Informational RFC: RFC 3579 == Outdated reference: A later version (-09) exists of draft-ietf-hokey-reauth-ps-07 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nakhjiri 3 Internet-Draft Motorola 4 Expires: August 3, 2008 Y. Ohba 5 Toshiba 6 January 31, 2008 8 Derivation, delivery and management of EAP based keys for handover and 9 re-authentication 10 draft-ietf-hokey-key-mgm-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 3, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document describes a delivery framework for usage and domain 44 specific root keys (USRK and DSRK), derived as part of an EAP EMSK 45 hierarchy, and delivered from an EAP server to an intended third 46 party key holder. The framework description includes different 47 scenarios for key delivery, depending on the type of keys being 48 delivered. It also includes, specification of derivation of keys 49 required for security protection of key requests and delivery 50 signaling. 52 Table of Contents 54 1. Introduction and Problem statement . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Key Delivery Architecture . . . . . . . . . . . . . . . . . . 5 57 3.1. Three Party Key distribution Exchange (KDE) . . . . . . . 7 58 3.2. Derivation of keys protecting the KDE . . . . . . . . . . 10 59 3.3. Specification of context and scope for distributed keys . 11 60 3.4. Automated Key Management for KIts and KCts . . . . . . . . 11 61 3.5. 3 party key exchange scenarios . . . . . . . . . . . . . . 12 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 63 5. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 14 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 67 7.2. Informative references . . . . . . . . . . . . . . . . . . 15 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 69 Intellectual Property and Copyright Statements . . . . . . . . . . 17 71 1. Introduction and Problem statement 73 The ability of Extensible Authentication Protocol (EAP) framework 74 [RFC3748] in incorporating desired authentication methods and 75 generating master session keys (MSK and EMSK) [I-D.ietf-eap-keying] 76 has led to the idea of using MSK and/or EMSK for bootstrapping 77 further keys for a variety of security mechanisms. Especially, the 78 MSK has been widely used for bootstrapping the wireless link security 79 associations between the peer and the network attachment points. 80 Issues arising from the use of MSK and the current bootstrapping 81 methods when it comes to mobility performance and security are 82 described in [I-D.ietf-hokey-reauth-ps]. Thus new efforts are under 83 way to use EMSK instead of MSK for bootstrapping of keys for future 84 use cases [I-D.ietf-hokey-emsk-hierarchy], [I-D.ietf-hokey-erx]. For 85 instance [I-D.ietf-hokey-emsk-hierarchy] defines ways to create usage 86 specific root keys (USRK) for bootstrapping security of a specific 87 use case. [I-D.ietf-hokey-emsk-hierarchy] also defines ways to 88 create domain specific root keys for bootstrapping security of a set 89 of services within a domain. 91 Along with those lines, this document on the other hand provides a 92 specification of a mechanism for secure delivery of such EMSK child 93 keys from the EAP server, holding the EMSK, to the intended third 94 party destinations. This is to address the following concerns: 96 1. EAP authentication is a 2 party protocol executed between an EAP 97 peer and an EAP server and the EMSK is only generated and held at 98 these two parties [I-D.ietf-eap-keying], while USRK, DSRK and 99 DSUSRK are also generated only by these two parties, but they 100 typically need to be stored and utilized at third party key 101 holders (e.g. AAA servers/entities) that are logically or even 102 physically separate from the EAP server or peer. For instance, 103 handover keying and re-authentication service requires 104 distribution of keys a variety of intermediaries. This would 105 mean these root keys need to be delivered to these third party 106 key holders (KH) in a secure manner, while considering the 107 requirements stated in [RFC4962] 109 2. EAP authentication and EMSK generation process is oblivious to 110 the service and authorization requests following the initial EAP 111 authentication. Thus at the time of EAP authentication, the EAP 112 parties do not have access to the input data required for 113 creation of the USRK, DSRK or DSUSRK 114 [I-D.ietf-hokey-emsk-hierarchy]. Such input data is typically 115 acquired and delivered to the EAP server at a later stage. The 116 EAP server then performs the derivation function, followed by a 117 secure delivery of the resulting keys to these third party key 118 holders. 120 The purpose of this document is to show how the required input data 121 for root key derivation can be delivered to the EAP server, and how 122 the generated key material is delivered to the third party key holder 123 in a secure manner. The specification also includes derivation of 124 key material required for secure delivery and channel binding 125 procedures for these key materials to ensure that not only the keys 126 are not exposed to unintended parties during delivery, but also the 127 scope and usage context for the key is properly understood and agreed 128 upon by the initial parties. 130 The purpose of this document is not to provide exact syntax for the 131 signaling, only the general semantics for the parameters involved are 132 defined. The exact syntax for these parameters when carried by 133 specific protocols, such as AAA protocols [RFC3579] [RFC4072] or EAP 134 protocols are out of scope of this document. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 USRK: Usage Specific Root key. A root key generated from EMSK and 143 is used for a specific usage that is authorized for a peer, 144 following an EAP authentication. USRK is domain independent. 146 USR-KH: USRK holder. The USR-KH is responsible for receiving, 147 holding and protection of the USRK derived directly from EMSK. 149 DSRK: Domain Specific Root key. A root key generated from EMSK and 150 is used within a specific domain that EAP-authenticated peer is 151 authorized to receive services from or roam into. DSRK is usage 152 independent. 154 DSR-KH: DSRK holder. The DSRK holder is responsible for receiving, 155 holding and protection of the DSRK derived directly from EMSK. 157 DSUSRK: Domain Specific Usage Specific Root key. A root key 158 generated from EMSK and is used for a specific usage within a 159 specific domain that an EAP-authenticated peer is authorized to 160 receive services from. DSUSRK is both usage and domain dependent. 162 DSUSR-KH: DSRK holder. The DSUSRK holder is responsible for 163 receiving, holding and protection of the DSUSRK derived directly 164 from EMSK. 166 HOKEY server (HS): This is essentially a usage specific server, that 167 deals with re-authentication as specific usage (USR-KH for HOKEY). 169 IK and CK: Integrity and cipher keys, used to protect the key 170 delivery signaling between the peer and the EAP server. These two 171 keys are some times referred to as key delivery keys. 173 3. Key Delivery Architecture 175 The EAP server is only responsible for performing EAP authentication 176 and is not expected to be involved in any service authorization 177 decisions, neither is the EAP server aware of the future service 178 requests at the time of authentication. The authorization decisions 179 based on the user service profile and provisioning of services 180 including support for service security is expected to happen by third 181 parties, such as AAA servers or service servers. When EAP-based 182 keying is used, such servers will cache and use the USRKs, DSRKs or 183 DSUSRKs, generated from EMSK, as root keys for derivation of further 184 keys to secure the services they are providing. Thus they are 185 considered third party key holders (KH) with respect to the initial 186 two EAP parties (EAP peer and server). However, since EMSK cannot be 187 exported from EAP server, such third parties need to request the EAP 188 server to generate the relevant root key (USRK, DSRK, or DSUSRK) from 189 the EMSK and deliver the requested key to them. The third party 190 needs to provide the required input data to be used along with the 191 pseudo random function (PRF) to the EAP server to generate the 192 requested key. The following types of top level key holders can be 193 envisioned: 195 USRK holder (USR-KH): An entity acting as a recipient and then 196 holder of the usage specific root key (USRK). The USR-KH is 197 possibly responsible for derivation and distribution of any child 198 keys derived from USRK for that specific usage. The USR-KH by 199 definition is domain independent, which means the USR-KH can use 200 USRK to generate DSUSRK for each domain deploying that service. 201 It is possible that this USR-KH server is not physically disjunct 202 from the EAP server but is simply considered as a separate logic 203 to off-load the EAP server from the need to handle usage specific 204 services, such as HOKEY service. Security Requirements for 205 delivery of USRK from EAP server to a collocated USR-KH is 206 currently TBD. However, to keep the security specifications 207 generic here, we assume that USR-KH and EAP server are physically 208 separate and specify the delivery of USRK from EAP server to 209 USR-KH accordingly. 211 DSRK holder (DSR-KH): An entity acting as a recipient and then 212 holder of the domain specific root key (DSRK). The DSR-KH is 213 possibly responsible for derivation and distribution of any child 214 keys derived from DSRK for that specific domain. The most likely 215 realization of DSR-KH is a AAA server in the corresponding domain, 216 responsible for setting the policies for usage of DSRK within the 217 domain. 219 DSUSRK holder (DSUSR-KH): An entity acting as a recipient and then 220 holder of the domain specific and usage specific root key (DSUSRK) 221 delivered from the EAP server. The DSUSR-KH is possibly 222 responsible for derivation and distribution of any child keys 223 derived from DSUSRK for that specific domain and usage. The most 224 likely realization of DSUSR-KH is a AAA server in the 225 corresponding domain, responsible for the service offered within 226 the domain for the specific usage at hand. 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | EAP server | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 / | \ 232 / | \ 233 USRK1 / | USRK2 \ USRK3 234 (ABC) / | (XYZ) \(DSRK1) 235 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 236 | USR-KH1 | | USR-KH2 | | DSR-KH1 | 237 | HOKEY server | | XYZ server| +-+-+-+-+-+-+-+ 238 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ | 239 +-+-+-+-+-+-+-+ 240 | Domain 1 | 241 | DSUSR-KH | 242 |(home domain | 243 |HOKEY server)| 244 +-+-+-+-+-+-+-+ 246 +-+-+-+-+-+-+ 247 | peer | 248 +-+-+-+-+-+-+ 250 Figure 1: Key delivery for various EMSK child key cateories 252 As one can see, depending on the type of key being delivered, 253 different third party key holders are involved. Each of the top 254 level key holders (USR-KH, DSR-KH has a interface with the EAP 255 server, for delivering usage specific (and/or domain specific) input 256 data needed for root key generation (USRK, DSRK) to the EAP server 257 and receiving the resulting root key from the EAP server. The 258 DSUSR-KH is considered a top level key holder and has an interface 259 with EAP server, only when the DSUSRK is directly derived from the 260 EMSK and by the EAP server. 262 Regardless of the type of key being delivered, the model for EAP 263 based key derivation and delivery interface can be generalized as a 3 264 party key distribution model, since EAP authentication method 265 signaling and the following EMSK generation is performed between the 266 peer and the EAP server in a manner that is almost transparent to all 267 intermediaries, while the EMSK is used to derive the top level root 268 keys and deliver those to a third party key holder, such as USR-KH or 269 DSR-KH. 271 3.1. Three Party Key distribution Exchange (KDE) 273 In the following we describe the generic mechanism for a 3 party key 274 distribution exchange (KDE), where a key is distributed from a 275 network server (with parent key holder) to a third party. The 276 following shows a generic trust model for the 3 party key 277 distribution mechanism. The peer (P) and a parent key holder, called 278 "server" (S) in this model share a parent key (Kps) and a set of 279 security associations (SA1) for integrity and privacy protection of 280 signaling between the peer and the server (KIps and KCps). The goal 281 of the keying solution is to use the parent key (Kps) and generate a 282 child key (Kpt) to be shared between the peer and the third party 283 intermediary (T). The peer is able to generate Kpt, but Kpt needs to 284 be distributed to a third party intermediary (T). The goal of this 285 section is to provide a the general description of the KDE (key 286 distribution exchange) for distribution of Kpt from S to T. We also 287 assume that the server (S) and the third party (T) share a similar 288 set security association, SA2 (KIts, KCts). 290 +-+-+-+-+ +-+-+-+-+-+-+-+ 291 | | shared SA1 | | 292 | |------------------------------| server | 293 | Peer | | KH | 294 +-+-+-+-+ +-+-+-+-+-+-+-+ 295 | 296 +-+-+-+-+-+-+ V 297 | 3 rd party| | SA2 (Kpt) 298 | KH | ----------| 299 +-+-+-+-+-+-+ 301 Figure 2: Distribution of a child key from a parent key key holder to 302 a 3rd party child key key holder 304 The key distribution exchange described here is a modified version of 305 the Otway-Rees protocol that meets the requirements for such 3-party 306 lay-out, providing channel binding and avoids the lying intermediary 307 scenario. The exchange proposed below is to perform a channel 308 binding and avoid the lying intermediary scenario. The description 309 below can be carried over a generic transport and thus is independent 310 of the exact type of protocol that is used. However for the purpose 311 of this document the assumption is that the 3 party mechanism 312 parameters are carried for EAP messages that are themselves 313 encapsulated over a lower layer such as a AAA protocol or an access 314 protocol. 316 The 3 party key distribution basically consists of 1 exchange, i.e. 2 317 messages between the peer and the server. However, in most scenarios 318 each message traverses through the intermediary, i.e. Over two 319 logical hops (peer-third party) and (third party-server) even though 320 the exchange seems to consist of 4 logical messages. It should be 321 noted that the information in message 0 is typically conveyed as an 322 advertisement through other means. 324 peer Third party server 325 ----- -------- ------- 326 | KDE0(TID, SID, DID) | | 327 |<-----------------------| | 328 | KDE1 (PRT) | KDE2 (TRT) | 329 |----------------------->|------------------->| 330 | KDE4 (SAT) | KDE3 (TOK) | 331 |<-----------------------|<-------------------| 333 Figure 3: Handover using EAP-HR 335 KDE message 0: Third party sends its own identifier (TID), the 336 Server ID (SID) and the Domain ID (DID) to peer. These 337 identifiers need to be recognizable by the server S and when AAA 338 signaling is used may be carried as AAA attributes. Domain ID is 339 used to create domain specific keys or to assist in key 340 distribution. 342 KDE message 1: Peer sends a peer request token (PRT) to the third 343 party including the TID reported by the third party and a 344 freshness value. The contents of PRT are detailed below. 346 KDE message 2: Third party uses the PRT and creates a third party 347 request token (TRT) and sends it to the server. The contents of 348 TRT are detailed below. 350 KDE message 3: Server sends the Kpt to third party wrapped inside a 351 token called Key Token (TOK). The TOK carries a Server 352 Authorization Token (SAT) destined for the peer, carrying 353 assurance for the peer that the server has sent the key Kpt to the 354 properly identified third party (identified by TID) 356 KDE message 4: The third party extracts the SAT from the server and 357 forwards it to the peer. The successful receipt of message 4 by 358 peer means that the third party has successfully verified 359 integrity of message 3 and decrypted Kpt. 361 {X}K: X encrypted with key K 363 Int[K, X]: X || MIC (K, X), where MIC Message Integrity Code over X 364 with key K. 366 PRT : Int[KIps,(PID, TID, SID, DID, FVp, KT, KN_KIps)] 368 PRT (Peer Request Token) carries the identities of peer (PID), 369 server (SID), third party (TID) and domain (DID) along with the 370 signature. The signature is called the peer request authenticator 371 (PRA). KIps is a symmetric key shared between peer and Server for 372 signing and identified by KN_KIps. FVx is the Freshness Value 373 provided by the party X. A Freshness Value can be a nonce or a 374 time stamp. Use of nonce for FV may require additional mechanism 375 for the server to maintain the freshness. KT is the Key Type 376 requested by the peer. The KT is an 2-octet unsigned integer 377 which uniquely identifies the type of the key. 379 TRT : Int[KIts, (PID, TID), PRT] 381 TRT (Third party Request Token) carries the token from the peer 382 along with the third party and peer IDs and a signature for 383 integrity protection. KIts is the shared key used for signing 384 purposes. Providing third party identifier both explicitly by the 385 third party and both implicitly through PRT allows the server to 386 detect a lying third party. 388 TOK : Int[KIts, {Kpt}KCts, SAT] 390 TOK(Key Token) carries the key to be distributed to the third 391 party (Kpt) wrapped with an encryption key (KCts). KL_Kx is the 392 key lifetime for key Kx. 394 SAT : Int[KIps,(PID, TID, SID, DID, FVp+1, KN_Kpt, KL_Kpt, KN_KIps)] 396 SAT (Server Authorization Token) carries assurance (in form of 397 signature on the incremented nonce value) for the peer that the 398 server has sent the key Kpt to the properly identified third party 399 (identified by TID). 401 The exchange proposed above can avoid the lying intermediary 402 scenario, as follows: if an intermediary decided to announce two 403 different identifiers to the peer versus to the server, e.g. a down 404 link ID to the peer (DTID) and a different uplink ID to the server 405 (UTID). The peer uses DTID in its token towards the server, while 406 the intermediary uses its UTID in its token to the server. Server 407 must use the UTID from peer token to calculate the MIC in the third 408 party token ([PID, UTID]KIts) and if there is a match, then the 409 server can verify that DTID and UTID are the same as the TID and 410 proceed with generating and provisioning of Kpt, otherwise the server 411 MUST return a failure code instead of generating an Kpt. 413 3.2. Derivation of keys protecting the KDE 415 As shown in the generic description of the key distribution exchange, 416 to protect the exchange, at least one (or two) keys are required to 417 protect the exchange. These keys are an integrity and a cipher key. 418 These keys are generated from the EMSK hierarchy themselves. 419 However, as discussed when enumerating the various KDE use case 420 scenarios, the KDE can and need to be used in many different 421 scenarios for delivering keys. Depending on the key that is being 422 delivered, the integrity and cipher keys can be generated at 423 different levels of the key hierarchy as well. For instance to 424 protect the KDE performed to deliver an EMSK child key (USRK, DSRK, 425 or DSUSRK), these two keys are generated directly from EMSK. 427 KDRK (=EMSK or USRK or DSUSRK) 428 | 429 +----+---+ 430 | | 431 CK IK 433 Figure 4: Key delivery keys as EMSK Child keys 435 Cipher key (CK) and Integrity Key (IK) are used to protect KDE for 436 delivery of USRKs, DSRKs, DSUSRKs, per-authenticator master keys and 437 any other keys generated from EMSK. CK and IK are generated from 438 KDRK (Key Distribution Root Key) which is EMSK or DSRK. When KDRK is 439 EMSK, CK and IK are defined as USRKs. When KDRK is DSRK, CK and IK 440 are defined as DSUSRKs. 442 We refer to PRF used to generate the USRKs, USRK-PRF, and assume that 443 it can generate Z bits of output. 445 CK and IK, and their key names are defined using the algorithms 446 defined in [I-D.ietf-hokey-emsk-hierarchy] as follows: 448 IK = KDF(KDRK, IK_Label | NULL | Key_length) 450 IK_name = prf-64( Name_Base, IK_Label) 452 CK = KDF(KDRK, CK_Label | NULL | Key_length) 454 CK_name = prf-64( Name_Base, CK_Label) 456 The IK_Label and CK_Label are IANA-assigned ASCII strings "Key 457 Distribution Integrity Key" and "Key Distribution Cipher Key" 458 assigned from the Key Label name space in accordance with 459 [I-D.ietf-hokey-emsk-hierarchy]. This document specifies IANA 460 registration for the IK_Label and CK_Label above. 462 When KDRK is EMSK, Name_Base is EAP Session ID. 464 When KDRK is a USRK or a DSUSRK, Name_Base is the name of the USRK or 465 DSUSRK, respectively. 467 3.3. Specification of context and scope for distributed keys 469 The key lifetime of each distributed key MUST NOT be greater than 470 that of its parent key. 472 The key context of each distributed key is determined by the sequence 473 of KTs in the key hierarchy. When a DSRK is being delivered and the 474 DSRK applies to only a specific set of services, the service types 475 may need to be carried as part of context for the key. 477 The key scope of each distributed key is determined by the sequence 478 of (PID, SID, TID, DID)-tuples in the key hierarchy. 480 3.4. Automated Key Management for KIts and KCts 482 KIts and KCts require automated key management [RFC4107] since these 483 are long-term session keys used by more than two parties. It is 484 RECOMMENDED that Kerberos [RFC4120] be used as an automated key 485 management protocol for distributing KIts and KCts. If there is no 486 direct trust relationship between the third-party and the server, 487 then inter-realm Kerberos SHOULD be used to create a direct trust 488 relationship between the third-party and the server from a chain of 489 trust relationships. 491 3.5. 3 party key exchange scenarios 493 As mentioned earlier, EMSK can be used to generate any of the USRKs, 494 DSRKs and DSUSRKs. The following scenarios can be envisioned for 495 distribution of a key to a 3rd party. All scenarios assume the peer 496 and the EAP server have mutually authenticated to each other using an 497 EAP method and have generated an EMSK. Since the EAP server 498 performing EAP method authentication and EMSK generation resides in 499 peer's home domain, for practical purposes, for the mechanisms 500 described in this document, the USR-KH MUST reside in this domain. 501 Note that other key distribution scenarios may also be possible since 502 the key distribution protocol is designed to be generic. 504 Scenario 1: EAP server to USR-KH: The specific use case considered 505 in this document is HOKEY re-authentication service: The USR-KH is 506 a HOKEY server and USRK is rRK. The EAP server delivers the rRK 507 to the USR-KH. The trigger and mechanism for key delivery may 508 involve a specific request from the peer and another intermediary 509 (such as authenticator). 511 Scenario 2: EAP server to DSR-KH: In this scenario, a domain server, 512 typically a domain AAA server requires delivery of a DSRK for a 513 set of prespecified usages within the domain. DSR-KH and EAP 514 server are physically disjunct. Thus deployment of 3 party key 515 distribution exchange is required. 517 Scenario 3: DSR-KH to DSUSR-KH: In this scenario, a DSR-KH in a 518 specific domain delivers keying material to the DSUSR-KH in the 519 same domain. 521 The mapping between the protocol parameters in each scenario to the 522 protocol parameters of the KDE protocol defined in Section 3.1 is 523 given below, where IK_X and CK_X are IK and CK derived from key X, 524 respectively. 526 +-----------------------------+ 527 | Scenarios | 528 +-------+---------+---------+---------+ 529 | KDE | 1 | 2 | 3 | 530 | Param.| | | | 531 +-------+---------+---------+---------+ 532 | PID | EAP Peer ID | 533 +-------+---------+---------+---------+ 534 | SID | EAP Server ID |DSR-KH ID| 535 +-------+---------+---------+---------+ 536 | TID |HS ID(*1)|DSR-KH ID|HS ID(*2)| 537 +-------+---------+---------+---------+ 538 | Kpt | rRK | DSRK | rRK | 539 +-------+---------+---------+---------+ 540 | KIps | IK_EMSK | IK_DSRK | 541 +-------+---------+---------+---------+ 542 | KCps | CK_EMSK | CK_DSRK | 543 +-------+---------+---------+---------+ 544 | KIts | Any pre-existing key | 545 +-------+---------+---------+---------+ 546 | KCts | Any pre-existing key | 547 +-------+---------+---------+---------+ 548 (*1) HS ID is USR-KH ID for HOKEY 549 (*2) HS ID is DSUSR-KH ID for HOKEY 551 The key distribution exchanges for some of the above scenarios can be 552 recursively combined into a single 1.5-roundtrip exchange. For 553 example, a combined key distribution exchange for Scenarios 3 and 6 554 is illustrated in Figure 5 where KDE[0-4] and KDE'[0-4] are messages 555 for Scenarios 3 and 6, respectively. It is assumed in Figure 5 that 556 DSR-KH and DSUSR-KH are co-located in the same HOKEY server (i.e., 557 DSR-KH and DSUSR-KH have the same identity). 559 peer NAS DSR-KH/ EAP Server 560 DSUSR-KH 561 ----- -------- ------- ----- 562 | KDE0(TID, SID) | | | 563 | KDE0'(TID',SID') | | | 564 |<------------------| | | 565 | KDE1(PRT) | KDE1(PRT) | KDE2(TRT) | 566 | KDE1'(PRT') | KDE2'(TRT') | | 567 |------------------>|---------------->|--------------->| 568 | KDE4(SAT) | KDE4(SAT) | KDE3(TOK) | 569 | KDE4'(SAT') | KDE3'(TOK') | | 570 |<------------------|<--------------- |<---------------| 571 | | | | 572 Figure 5: Combined Message Exchange 574 4. Security Considerations 576 The key distribution mechanism described in this document assumes 577 existence of a direct trust relationship between the server and the 578 third party key holder. Such a direct trust relationship may be 579 dynamically created from a chain of transitive trust relationships 580 with the use of inter-realm Kerberos to distribute KIts and KCts as 581 described in Section 3.4. Therefore, the key distribution method 582 described in this document eliminates the need for hop-by-hop 583 security associations along the transitive trust relationship. 585 5. IANA consideration 587 This document defines new usage labels, such as those used in 588 generation of CK and IK. The corresponding labels (e.g. "Key 589 Distribution Integrity Key" and "Key Distribution Cipher key") need 590 to be assigned numerical values by IANA. 592 This document defines KT (Key Type) which is an IANA-assigned 2-octet 593 unsigned integer. The following Key Type values are allocated in 594 this document: 596 0 (DSRK) 598 1 (rRK) 600 6. Acknowledgements 602 The author would like to thank Dan Harkins, Chunqiang Li and Rafael 603 Marin Lopez for their valuable contribution to the formation of the 604 KDE. 606 7. References 608 7.1. Normative References 610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 611 Requirement Levels", BCP 14, RFC 2119, March 1997. 613 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 614 Levkowetz, "Extensible Authentication Protocol (EAP)", 615 RFC 3748, June 2004. 617 [I-D.ietf-hokey-emsk-hierarchy] 618 Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 619 "Specification for the Derivation of Root Keys from an 620 Extended Master Session Key (EMSK)", 621 draft-ietf-hokey-emsk-hierarchy-03 (work in progress), 622 January 2008. 624 [I-D.ietf-hokey-erx] 625 Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 626 authentication Protocol (ERP)", draft-ietf-hokey-erx-08 627 (work in progress), November 2007. 629 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 630 Dial In User Service) Support For Extensible 631 Authentication Protocol (EAP)", RFC 3579, September 2003. 633 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 634 Authentication Protocol (EAP) Application", RFC 4072, 635 August 2005. 637 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 638 Kerberos Network Authentication Service (V5)", RFC 4120, 639 July 2005. 641 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 642 Authorization, and Accounting (AAA) Key Management", 643 BCP 132, RFC 4962, July 2007. 645 7.2. Informative references 647 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 648 Key Management", BCP 107, RFC 4107, June 2005. 650 [I-D.ietf-eap-keying] 651 Aboba, B., Simon, D., and P. Eronen, "Extensible 652 Authentication Protocol (EAP) Key Management Framework", 653 draft-ietf-eap-keying-22 (work in progress), 654 November 2007. 656 [I-D.ietf-hokey-reauth-ps] 657 Clancy, C., Nakhjiri, M., Narayanan, V., and L. Dondeti, 658 "Handover Key Management and Re-authentication Problem 659 Statement", draft-ietf-hokey-reauth-ps-07 (work in 660 progress), November 2007. 662 Authors' Addresses 664 Madjid Nakhjiri 665 Motorola 667 Email: madjid.nakhjiri@motorola.com 669 Yoshihiro Ohba 670 Toshiba 672 Email: yohba@tari.toshiba.com 674 Full Copyright Statement 676 Copyright (C) The IETF Trust (2008). 678 This document is subject to the rights, licenses and restrictions 679 contained in BCP 78, and except as set forth therein, the authors 680 retain all their rights. 682 This document and the information contained herein are provided on an 683 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 684 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 685 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 686 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 687 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 688 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 690 Intellectual Property 692 The IETF takes no position regarding the validity or scope of any 693 Intellectual Property Rights or other rights that might be claimed to 694 pertain to the implementation or use of the technology described in 695 this document or the extent to which any license under such rights 696 might or might not be available; nor does it represent that it has 697 made any independent effort to identify any such rights. Information 698 on the procedures with respect to rights in RFC documents can be 699 found in BCP 78 and BCP 79. 701 Copies of IPR disclosures made to the IETF Secretariat and any 702 assurances of licenses to be made available, or the result of an 703 attempt made to obtain a general license or permission for the use of 704 such proprietary rights by implementers or users of this 705 specification can be obtained from the IETF on-line IPR repository at 706 http://www.ietf.org/ipr. 708 The IETF invites any interested party to bring to its attention any 709 copyrights, patents or patent applications, or other proprietary 710 rights that may cover technology that may be required to implement 711 this standard. Please address the information to the IETF at 712 ietf-ipr@ietf.org. 714 Acknowledgment 716 Funding for the RFC Editor function is provided by the IETF 717 Administrative Support Activity (IASA).