idnits 2.17.1 draft-ietf-hokey-key-mgm-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 961. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 972. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 979. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 985. 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 (February 25, 2008) is 5904 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 360, but not defined == Missing Reference: 'X' is mentioned on line 360, but not defined == Missing Reference: '1-4' is mentioned on line 562, but not defined == Missing Reference: 'RFC4306' is mentioned on line 737, but not defined ** Obsolete undefined reference: RFC 4306 (Obsoleted by RFC 5996) == Missing Reference: 'RFC3602' is mentioned on line 730, but not defined == Missing Reference: 'RFC4595' is mentioned on line 738, but not defined == Unused Reference: 'RFC3579' is defined on line 850, but no explicit reference was found in the text == Unused Reference: 'RFC4072' is defined on line 854, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-hokey-emsk-hierarchy-04 == Outdated reference: A later version (-14) exists of draft-ietf-hokey-erx-12 ** Downref: Normative reference to an Informational RFC: RFC 3579 -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X691' ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 9 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 28, 2008 Y. Ohba 5 Toshiba 6 February 25, 2008 8 Derivation, delivery and management of EAP based keys for handover and 9 re-authentication 10 draft-ietf-hokey-key-mgm-03 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 28, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document describes a framework and a mechanism for deliverying 44 usage specific root keys (USRK and DSUSRK), derived as part of an EAP 45 EMSK hierarchy, and delivered from a 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. The mechanism description includes the definition for a 51 three-party key distribution exchange (KDE) protocol. 53 Table of Contents 55 1. Introduction and Problem statement . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Key Delivery Architecture . . . . . . . . . . . . . . . . . . 5 58 3.1. Three Party Key Distribution Exchange (KDE) . . . . . . . 7 59 3.2. Derivation of keys protecting the KDE . . . . . . . . . . 10 60 3.3. Specification of context and scope for distributed keys . 11 61 3.4. Automated key management for KIts and KCts . . . . . . . . 11 62 3.5. Key distribution exchange scenarios . . . . . . . . . . . 12 63 4. KDE Message Format . . . . . . . . . . . . . . . . . . . . . . 13 64 4.1. Message Syntax . . . . . . . . . . . . . . . . . . . . . . 14 65 4.2. Message Encoding . . . . . . . . . . . . . . . . . . . . . 17 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 67 5.1. Security Association between Server and Third Party . . . 17 68 5.2. Replay Protection . . . . . . . . . . . . . . . . . . . . 18 69 5.3. Distribution of Duplicate Kpt . . . . . . . . . . . . . . 18 70 6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 18 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 74 8.2. Informative references . . . . . . . . . . . . . . . . . . 20 75 Appendix A. KDE Transport . . . . . . . . . . . . . . . . . . . . 20 76 A.1. KDE Transport over UDP . . . . . . . . . . . . . . . . . . 20 77 A.2. KDE Transport over AAA . . . . . . . . . . . . . . . . . . 20 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 79 Intellectual Property and Copyright Statements . . . . . . . . . . 22 81 1. Introduction and Problem statement 83 The ability of Extensible Authentication Protocol (EAP) framework 84 [RFC3748] in incorporating desired authentication methods and 85 generating master session keys (MSK and EMSK) [I-D.ietf-eap-keying] 86 has led to the idea of using MSK and/or EMSK for bootstrapping 87 further keys for a variety of security mechanisms. Especially, the 88 MSK has been widely used for bootstrapping the wireless link security 89 associations between the peer and the network attachment points. 90 Issues arising from the use of MSK and the current bootstrapping 91 methods when it comes to mobility performance and security are 92 described in [I-D.ietf-hokey-reauth-ps]. Thus new efforts are under 93 way to use EMSK instead of MSK for bootstrapping of keys for future 94 use cases [I-D.ietf-hokey-emsk-hierarchy], [I-D.ietf-hokey-erx]. For 95 instance [I-D.ietf-hokey-emsk-hierarchy] defines ways to create usage 96 specific root keys (USRK) for bootstrapping security of a specific 97 use case. [I-D.ietf-hokey-emsk-hierarchy] also defines ways to 98 create domain specific root keys for bootstrapping security of a set 99 of services within a domain. 101 Along with those lines, this document on the other hand provides a 102 specification of a mechanism for secure delivery of such EMSK child 103 keys from the EAP server, holding the EMSK, to the intended third 104 party destinations. This is to address the following concerns: 106 1. EAP authentication is a 2 party protocol executed between an EAP 107 peer and an EAP server and the EMSK is only generated and held at 108 these two parties [I-D.ietf-eap-keying], while USRK and DSUSRK 109 are also generated only by these two parties, but they typically 110 need to be stored and utilized at third party key holders (e.g. 111 AAA servers/entities) that are logically or even physically 112 separate from the EAP server or peer. For instance, handover 113 keying and re-authentication service requires distribution of 114 keys a variety of intermediaries. This would mean these root 115 keys need to be delivered to these third party key holders (KH) 116 in a secure manner, while considering the requirements stated in 117 [RFC4962] 119 2. EAP authentication and EMSK generation process is oblivious to 120 the service and authorization requests following the initial EAP 121 authentication. Thus at the time of EAP authentication, the EAP 122 parties do not have access to the input data required for 123 creation of the USRK or DSUSRK [I-D.ietf-hokey-emsk-hierarchy]. 124 Such input data is typically acquired and delivered to a server 125 (the EAP server or DSR-KH) at a later stage. The server then 126 performs the derivation function, followed by a secure delivery 127 of the resulting keys to these third party key holders. 129 One purpose of this document is to show how the required input data 130 for root key derivation can be delivered to the server, and how the 131 generated key material is delivered to the third party key holder in 132 a secure manner. The specification also includes derivation of key 133 material required for secure delivery and channel binding procedures 134 for these key materials to ensure that not only the keys are not 135 exposed to unintended parties during delivery, but also the scope and 136 usage context for the key is properly understood and agreed upon by 137 the initial parties. 139 Another purpose of this document is to provide exact syntax for a 140 three-party key distribution exchange (KDE) protocol, a protocol used 141 for delivering USRK and and DSUSRK from a server to a third-party. 143 2. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 USRK: Usage Specific Root key. A root key generated from EMSK and 150 is used for a specific usage that is authorized for a peer, 151 following an EAP authentication. USRK is domain independent. 153 USR-KH: USRK holder. The USR-KH is responsible for receiving, 154 holding and protection of the USRK derived directly from EMSK. 156 DSRK: Domain Specific Root key. A root key generated from EMSK and 157 is used within a specific domain that EAP-authenticated peer is 158 authorized to receive services from or roam into. DSRK is usage 159 independent. 161 DSR-KH: DSRK holder. The DSRK holder is responsible for receiving, 162 holding and protection of the DSRK derived directly from EMSK. 164 DSUSRK: Domain Specific Usage Specific Root key. A root key 165 generated from DSRK and is used for a specific usage within a 166 specific domain that an EAP-authenticated peer is authorized to 167 receive services from. DSUSRK is both usage and domain dependent. 169 DSUSR-KH: DSRK holder. The DSUSRK holder is responsible for 170 receiving, holding and protection of the DSUSRK. 172 IK and CK: Integrity and cipher keys, used to protect the key 173 delivery signaling between the peer and the EAP server. These two 174 keys are some times referred to as key delivery keys. 176 3. Key Delivery Architecture 178 The EAP server is only responsible for performing EAP authentication 179 and is not expected to be involved in any service authorization 180 decisions, neither is the EAP server aware of the future service 181 requests at the time of authentication. The authorization decisions 182 based on the user service profile and provisioning of services 183 including support for service security is expected to happen by third 184 parties, such as AAA servers or service servers. When EAP-based 185 keying is used, such servers will cache and use the USRKs, DSRKs or 186 DSUSRKs, generated from EMSK, as root keys for derivation of further 187 keys to secure the services they are providing. Thus they are 188 considered third party key holders (KH) with respect to the initial 189 two EAP parties (EAP peer and server). However, since EMSK cannot be 190 exported from EAP server, such third parties need to request the EAP 191 server to generate the relevant root key (USRK) from the EMSK and 192 deliver the requested key to them. The third party needs to provide 193 the required input data to be used along with the pseudo random 194 function (PRF) to the EAP server to generate the requested key. The 195 following types of top level key holders can be envisioned: 197 USRK holder (USR-KH): An entity acting as a recipient and then 198 holder of the usage specific root key (USRK). The USR-KH is 199 possibly responsible for derivation and distribution of any child 200 keys derived from USRK for that specific usage. It is possible 201 that this USR-KH server is not physically disjunct from the EAP 202 server but is simply considered as a separate logic to off-load 203 the EAP server from the need to handle usage specific services, 204 such as HOKEY service. However, to keep the security 205 specifications generic here, we assume that USR-KH and EAP server 206 are physically separate and specify the delivery of USRK from EAP 207 server to USR-KH accordingly. 209 DSRK holder (DSR-KH): An entity acting as a recipient and then 210 holder of the domain specific root key (DSRK). The DSR-KH is 211 responsible for derivation and distribution of any child keys 212 derived from DSRK for that specific domain. The most likely 213 realization of DSR-KH is a AAA server in the corresponding domain, 214 responsible for setting the policies for usage of DSRK within the 215 domain. 217 DSUSRK holder (DSUSR-KH): An entity acting as a recipient and then 218 holder of the domain specific and usage specific root key (DSUSRK) 219 delivered from the EAP server. The DSUSR-KH is possibly 220 responsible for derivation and distribution of any child keys 221 derived from DSUSRK for that specific domain and usage. The most 222 likely realization of DSUSR-KH is a AAA server in the 223 corresponding domain, responsible for the service offered within 224 the domain for the specific usage at hand. 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | EAP server | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 / | \ 230 / | \ 231 USRK1 / | USRK2 \ USRK3 232 (ABC) / | (XYZ) \(DSRK1) 233 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 234 | USR-KH1 | | USR-KH2 | | DSR-KH1 | 235 | HOKEY server | | XYZ server| +-+-+-+-+-+-+-+ 236 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ | 237 +-+-+-+-+-+-+-+ 238 | Domain 1 | 239 | DSUSR-KH | 240 |(home domain | 241 |HOKEY server)| 242 +-+-+-+-+-+-+-+ 244 +-+-+-+-+-+-+ 245 | peer | 246 +-+-+-+-+-+-+ 248 Figure 1: Key delivery for various EMSK child key cateories 250 As one can see, depending on the type of key being delivered, 251 different third party key holders are involved. Each of the top 252 level key holders (USR-KH, DSR-KH has a interface with the EAP 253 server, for delivering usage specific (and/or domain specific) input 254 data needed for root key generation (USRK, DSRK) to the EAP server 255 and receiving the resulting root key from the EAP server. The 256 DSUSR-KH is considered a second-level key holder and has an interface 257 with DSR-KH. 259 Regardless of the type of key being delivered, the model for EAP 260 based key derivation and delivery interface can be generalized as a 3 261 party key distribution model, since EAP authentication method 262 signaling and the following EMSK generation is performed between the 263 peer and the EAP server in a manner that is almost transparent to all 264 intermediaries, while the EMSK is used to derive the top level root 265 keys and deliver those to a third party key holder, such as USR-KH or 266 DSR-KH. 268 3.1. Three Party Key Distribution Exchange (KDE) 270 In the following we describe the generic mechanism for a three- party 271 key distribution exchange (KDE), where a key is distributed from a 272 network server (with parent key holder) to a third party. The 273 following shows a generic trust model for the key distribution 274 mechanism to the third party. The peer (P) and a parent key holder, 275 called "server" (S) in this model share a parent key (Kps) and a set 276 of security associations (SA1) for integrity and privacy protection 277 of signaling between the peer and the server (KIps and KCps). The 278 goal of the keying solution is to use the parent key (Kps) and 279 generate a child key (Kpt) to be shared between the peer and the 280 third party intermediary (T). The peer is able to generate Kpt, but 281 Kpt needs to be distributed to a third party intermediary (T). The 282 goal of this section is to provide a the general description of the 283 KDE (key distribution exchange) for distribution of Kpt from S to T. 284 We also assume that the server (S) and the third party (T) share a 285 similar set security association, SA2 (KIts, KCts). 287 +-+-+-+-+ +-+-+-+-+-+-+-+ 288 | | shared SA1 | | 289 | |------------------------------| server | 290 | Peer | | KH | 291 +-+-+-+-+ +-+-+-+-+-+-+-+ 292 | 293 +-+-+-+-+-+-+ V 294 | 3 rd party| | SA2 (Kpt) 295 | KH | ----------| 296 +-+-+-+-+-+-+ 298 Figure 2: Distribution of a child key from a parent key key holder to 299 a 3rd party child key key holder 301 The key distribution exchange described here meets the requirements 302 for such 3-party lay-out, providing channel binding and avoids the 303 lying intermediary scenario. The exchange proposed below is to 304 perform a channel binding and avoid the lying intermediary scenario. 305 The description below can be carried over a generic transport and 306 thus is independent of the exact type of protocol that is used. 308 The key distribution to a third-party basically consists of 1 309 exchange, i.e. 2 messages between the peer and the server. However, 310 in most scenarios each message traverses through the intermediary, 311 i.e. Over two logical hops (peer-third party) and (third party- 312 server) even though the exchange seems to consist of 4 logical 313 messages. It should be noted that the information in message 0 is 314 typically conveyed as an advertisement through other means and hence 315 message 0 is optional. 317 peer Third party server 318 ----- -------- ------- 319 | KDE0*(TID, SID, DID*, KT) | | 320 |<----------------------------| | 321 | KDE1 (PRT) | KDE2 (TRT) | 322 |---------------------------->|------------------->| 323 | KDE4 (SAT) | KDE3 (TOK) | 324 |<----------------------------|<-------------------| 326 (*) optional 328 Figure 3: Handover using EAP-HR 330 KDE message 0 (optional): Third party sends its own identifier 331 (TID), the Server ID (SID), the Domain ID (DID) and the KT (Key 332 Type) to peer. These identifiers need to be recognizable by the 333 server S and when AAA signaling is used may be carried as AAA 334 attributes. KT is used for uniquely identifying the type of the 335 key. DID is used to create domain specific keys or to assist in 336 key distribution. DID is not included when the KT is other than 0 337 (DSRK) or 2 (DS-rRK). 339 KDE message 1: Peer sends a peer request token (PRT) to the third 340 party including the TID reported by the third party and a 341 freshness value. The contents of PRT are detailed below. 343 KDE message 2: Third party uses the PRT and creates a third party 344 request token (TRT) and sends it to the server. The contents of 345 TRT are detailed below. 347 KDE message 3: Server sends the Kpt to third party wrapped inside a 348 token called Key Token (TOK). The TOK carries a Server 349 Authorization Token (SAT) destined for the peer, carrying 350 assurance for the peer that the server has sent the key Kpt to the 351 properly identified third party (identified by TID). 353 KDE message 4: The third party extracts the SAT from the server and 354 forwards it to the peer. The successful receipt of message 4 by 355 peer means that the third party has successfully verified 356 integrity of message 3 and decrypted Kpt. 358 {X}K: X encrypted with key K 360 Int[K, X]: X || MIC (K, X), where MIC Message Integrity Code over X 361 with key K. 363 PRT : Int[KIps, (SEQps, PID, TID, SID, DID*, KT, KN_KIps)] 365 PRT (Peer Request Token) carries a sequence number (SEQps), the 366 identities of the peer (PID), the server (SID), the third party 367 (TID) and the domain (DID), the KT (Key Type) and the name of KIps 368 along with the signature. The signature is called the peer 369 request authenticator (PRA). KIps is a symmetric key shared 370 between peer and Server for signing and identified by KN_KIps. 371 SEQps is a sequence number generated by the peer and maintained 372 between the peer and server. The initial sequence number starts 373 from one (1). When the sequence number wraps up, then SA1 MUST be 374 deleted and any KDE message MUST NOT be generated or processed 375 thereafter. DID is not included when KT is other than 0 (DSRK) or 376 or 2 (DS-rRK). 378 TRT : Int[KIts, (Nt, PID, TID, PRT)] 380 TRT (Third party Request Token) carries the token from the peer 381 along with the third party and peer IDs and a signature for 382 integrity protection. KIts is the shared key used for signing 383 purposes. Nt is a nonce generated by the third party. Providing 384 third party identifier both explicitly by the third party and both 385 implicitly through PRT allows the server to detect a lying third 386 party. 388 TOK : Int[KIts, (Nt+1, PID, TID, SID, DID*, KT, {Kpt, KN_Kpt, 389 KL_Kpt}KCts, SAT)] 391 TOK(Key Token) carries the key to be distributed to the third 392 party (Kpt) wrapped with an encryption key (KCts). KL_Kx is the 393 key lifetime for key Kx. 395 SAT : Int[KIps,(SEQps+1, PID, TID, SID, DID*, KN_Kpt, KL_Kpt, 396 KN_KIps)] 398 SAT (Server Authorization Token) carries assurance (in form of 399 signature on the incremented nonce value) for the peer that the 400 server has sent the key Kpt to the properly identified third party 401 (identified by TID). DID is not included when KT is other than 0 402 (DSRK) or 2 (DS-rRK). 404 The exchange proposed above can avoid the lying intermediary 405 scenario, as follows: if an intermediary decided to announce two 406 different identifiers to the peer versus to the server, e.g. a down 407 link ID to the peer (DTID) and a different uplink ID to the server 408 (UTID). The peer uses DTID in its token towards the server, while 409 the intermediary uses its UTID in its token to the server. Server 410 must use the UTID from PRT to calculate the MIC in TRT and if there 411 is a match, then the server can verify that DTID and UTID are the 412 same as the TID and proceed with generating and provisioning of Kpt, 413 otherwise the server MUST return a failure code instead of generating 414 an Kpt. 416 3.2. Derivation of keys protecting the KDE 418 As shown in the generic description of the key distribution exchange, 419 to protect the exchange, at least one (or two) keys are required to 420 protect the exchange. These keys are an integrity and a cipher key. 421 These keys are generated from the EMSK hierarchy themselves. 422 However, as discussed when enumerating the various KDE use case 423 scenarios, the KDE can and need to be used in many different 424 scenarios for delivering keys. Depending on the key that is being 425 delivered, the integrity and cipher keys can be generated at 426 different levels of the key hierarchy as well. For instance to 427 protect the KDE performed to deliver a USRK, these two keys are 428 generated directly from EMSK. 430 KDRK 431 | 432 +----+---+ 433 | | 434 CK IK 436 Figure 4: Key delivery keys as EMSK Child keys 438 Cipher key (CK) and Integrity Key (IK) are used to protect KDE for 439 delivery of USRKs and DSUSRKs. CK and IK are generated from KDRK 440 (Key Distribution Root Key) which is either EMSK or DSRK in the use 441 cases described in this document. When KDRK is EMSK, CK and IK are 442 defined as USRKs. When KDRK is DSRK, CK and IK are defined as 443 DSUSRKs. The lengthes of CK and IK depends on actual integrity and 444 encryption algorithms in use. 446 If KDRK is the EMSK, then CK and IK are defined using the USRK 447 derivation algorithm defined in [I-D.ietf-hokey-emsk-hierarchy] as 448 follows: 450 IK = USRK(usage="kde-integrity-key@ietf.org", length) 452 CK = USRK(usage="kde-cipher-key@ietf.org", length) 454 USRK(usage, length) is the USRK key derivation function with the 455 usage and key length specified in the first and second parameters, 456 respectively. 458 If KDRK is the DSRK for domain="example.net", then CK and IK are 459 defined using the DSUSRK derivation algorithm defined in 460 [I-D.ietf-hokey-emsk-hierarchy] as follows: 462 IK = DSUSRK(usage="kde-integrity-key@ietf.org", domain, length) 464 CK = DSUSRK(usage="kde-cipher-key@ietf.org", domain, length) 466 DSUSRK(usage, domain, length) is the DSUSRK key derivation function 467 with the usage, domain and key length specified in the first, second 468 and third parameters, respectively. 470 If KDRK is other than the EMSK or DSRK, then CK and IK are defined 471 using the KDF defined in [I-D.ietf-hokey-emsk-hierarchy] as follows: 473 IK = KDF(KDRK, "kde-integrity-key@ietf.org" + length) 475 CK = KDF(KDRK, "kde-cipher-key@ietf.org" + length) 477 In this case, the IK and CK names are defined as SHA-1-64(KDRK-name + 478 "kde-integrity-key@ietf.org") and SHA-1-64(KDRK-name + 479 "kde-cipher@ietf.org"), respectively, where SHA-1-64 is the first 64- 480 octet of SHA-1. 482 3.3. Specification of context and scope for distributed keys 484 The key lifetime of each distributed key MUST NOT be greater than 485 that of its parent key. 487 The key context of each distributed key is determined by the sequence 488 of KTs in the key hierarchy. When a DSRK is being delivered and the 489 DSRK applies to only a specific set of services, the service types 490 may need to be carried as part of context for the key. Carrying such 491 a specific set of services are outside the scope of this document. 493 The key scope of each distributed key is determined by the sequence 494 of (PID, SID, TID, DID, KT)-tuples in the key hierarchy. 496 3.4. Automated key management for KIts and KCts 498 KIts and KCts require automated key management [RFC4107] since these 499 are long-term session keys used by more than two parties. Kerberos 500 [RFC4120] MAY be used as an automated key management protocol for 501 distributing KIts and KCts. If there is no direct trust relationship 502 between the third-party and the server, then inter-realm Kerberos MAY 503 be used to create a direct trust relationship between the third-party 504 and the server from a chain of trust relationships. 506 Note that the automated key management mechanism described above is 507 not required if hop-by-hop security is used for protecting KDE 508 messages. See Section 5 for more discussion. 510 3.5. Key distribution exchange scenarios 512 As mentioned earlier, EMSK can be used to generate any of the USRKs, 513 DSRKs and DSUSRKs. The following scenarios can be envisioned for 514 distribution of a key to a 3rd party. All scenarios assume the peer 515 and the EAP server have mutually authenticated to each other using an 516 EAP method and have generated an EMSK. Since the EAP server 517 performing EAP method authentication and EMSK generation resides in 518 peer's home domain, for practical purposes, for the mechanisms 519 described in this document, the USR-KH MUST reside in this domain. 520 Note that other key distribution scenarios may also be possible since 521 the key distribution protocol is designed to be generic. 523 Scenario 1: EAP server to USR-KH: In this scenario, an EAP server 524 delivers a USRK to a USR-KH. The trigger and mechanism for key 525 delivery may involve a specific request from the peer and another 526 intermediary (such as authenticator). In the case of HOKEY re- 527 authentication service, a DSRK or an rRK is distributed. 529 Scenario 2: DSR-KH to DSUSR-KH: In this scenario, a DSR-KH in a 530 specific domain delivers keying material to the DSUSR-KH in the 531 same domain. In the case of HOKEY re-authentication service, a 532 DS-rRK is distributed. 534 The mapping between the protocol parameters in each scenario to the 535 protocol parameters of the KDE protocol defined in Section 3.1 is 536 given below, where IK_X and CK_X are IK and CK derived from key X, 537 respectively. The keyName-NAI is defined in [I-D.ietf-hokey-erx]. 539 +------------+-------------+-------------+ 540 | KDE Param. | Scenario 1 | Scenario 2 | 541 +------------+-------------+-------------+ 542 | PID | keyName-NAI | 543 +------------+-------------+-------------+ 544 | SID |EAP Server ID| DSR-KH ID | 545 +------------+-------------+-------------+ 546 | TID | USR-KH ID | DSUSR-KH ID | 547 +------------+-------------+-------------+ 548 | Kpt | USRK | DSUSRK | 549 +------------+-------------+-------------+ 550 | KIps | IK_EMSK | IK_DSRK | 551 +------------+-------------+-------------+ 552 | KCps | CK_EMSK | CK_DSRK | 553 +------------+-------------+-------------+ 554 | KIts | Any pre-existing key | 555 +------------+---------------------------+ 556 | KCts | Any pre-existing key | 557 +------------+---------------------------+ 559 The key distribution exchanges for some of the above scenarios can be 560 recursively combined into a single 1.5-roundtrip exchange. For 561 example, a combined key distribution exchange for Scenarios 1 and 2 562 is illustrated in Figure 5 where KDE[1-4] and KDE'[1-4] are messages 563 for Scenarios 1 and 2, respectively. 565 peer DSUSR-KH DSR-KH EAP Server 566 ----- -------- ------- ----- 567 | KDE1 | KDE1 | KDE2 | 568 | KDE1' | KDE2' | | 569 |------------------>|---------------->|--------------->| 570 | KDE4 | KDE4 | KDE3 | 571 | KDE4' | KDE3' | | 572 |<------------------|<--------------- |<---------------| 573 | | | | 575 Figure 5: Combined Message Exchange 577 4. KDE Message Format 579 The format of KDE messages is defined here in terms of Abstract 580 Syntax Notation One (ASN.1) [X680], which provides a syntax for 581 specifying both the abstract layout of protocol messages as well as 582 their encodings. 584 4.1. Message Syntax 586 The syntax of KDE messages is defined here in terms of Abstract 587 Syntax Notation One (ASN.1) [X680], which provides a syntax for 588 specifying both the abstract layout of protocol messages as well as 589 their encodings. 591 -- OID for KDE 592 HokeyKdeV1 { 593 iso(1) identified-organization(3) dod(6) internet(1) 594 security(5) mechanisms(5) hokey(to be assigned by IANA) 595 kde-v1(1) 596 } DEFINITIONS AUTOMATIC TAGS ::= BEGIN 598 -- OID arc for HOKEY KDE 599 -- 600 -- This OID may be used to identify HOKEY KDE messages 601 -- encapsulated in other protocols. 602 -- 603 -- This OID also designates the OID arc for HOKEY KDE-related OIDs. 604 -- 605 id-hokey-kde-v1 OBJECT IDENTIFIER ::= { 606 iso(1) identified-organization(3) dod(6) internet(1) 607 security(5) mechanisms(5) hokey(to be assigned by IANA) 608 kde-v1(1) 609 } 611 UInt32 ::= INTEGER (0..4294967295) 612 -- unsigned 32 bit values 614 KDE-PDU ::= SEQUENCE { 615 version INTEGER (1..255) 616 -- Version of KDE protocol (=1 in this document) 617 payload KDE-Payload 618 -- Payload of KDE message 619 } 621 -- A payload contains one or more KDE messages. 623 -- The payload contains one or more KDE messages. Two or more KDE 624 -- messsage are allowed to support combined exchange. 625 KDE-Payload ::= SEQUENCE OF { 626 CHOICE { 627 kde0 KDE0 -- KDE0 628 kde1 KDE1, -- KDE1 629 kde2 KDE2, -- KDE2 630 kde3 KDE3, -- KDE3 631 kde4 KDE4 -- KDE4 633 } 634 } 636 KDE0 ::= SEQUENCE { 637 tid OCTET STRING, -- Third-party ID 638 sid OCTET STRING, -- Server ID 639 did OCTET STRING OPTIONAL, -- Domain ID 640 keytype INTEGER(0..255) 641 -- Key Type of Kpt (IANA assigned value) 642 } 644 KDE1 ::= SEQUENCE { 645 prt PRT -- Peer Request Token 646 } 648 KDE2 ::= SEQUENCE { 649 trt TRT -- Third Party Request Token 650 } 652 KDE3 ::= SEQUENCE { 653 tot TOT -- Key Token 654 } 656 KDE4 ::= SEQUENCE { 657 tot SAT -- Server Authorization Token 658 } 660 -- PRT (Peer Request Token) 661 PRT ::= SEQUENCE { 662 seq Uint32, -- Sequence Number (intial value is 1) 663 pid OCTET STRING, -- Peer ID 664 tid OCTET STRING, -- Third-party ID 665 sid OCTET STRING, -- Server ID 666 did OCTET STRING OPTIONAL, 667 -- Domain ID 668 keytype INTEGER(0..255) 669 -- Key Type of Kpt (IANA assigned value) 670 kips-name OCTET STRING, -- Key name of KIps 671 integrity-data IntegrityData 672 -- Integrity protection with KIps 673 } 675 -- TRT (Third party Request Token) 676 TRT ::= SEQUENCE { 677 tnonce Uint32 -- Third-party Nonce 678 pid OCTET STRING, -- Peer ID 679 tid OCTET STRING, -- Third-party ID 680 prt PRT 682 } 684 -- TOK (Key Token) 685 TOK ::= SEQUENCE { 686 tnonce Uint32 -- Third-party Nonce+1 687 pid OCTET STRING, -- Peer ID 688 tid OCTET STRING, -- Third-party ID 689 sid OCTET STRING, -- Server ID 690 did OCTET STRING OPTIONAL, 691 -- Domain ID 692 keytype INTEGER(0..255) 693 -- Key Type of Kpt (IANA assigned value) 694 enc-kpt EnctyptedData 695 -- Kpt and its name and lifetime encrypted with KCts 696 sat SAT, 697 integrity-data IntegrityData 698 -- Integrity protection with KIts 699 } 701 -- SAT (Server Authorization Token) 702 SAT ::= SEQUENCE { 703 seq Uint32, -- Sequence Number + 1 704 pid OCTET STRING, -- Peer ID 705 tid OCTET STRING, -- Third-party ID 706 sid OCTET STRING, -- Server ID 707 did OCTET STRING OPTIONAL, 708 -- Domain ID 709 kpt-name OCTET STRING, -- Key name of Kpt 710 kpt-lifetime Uint32 -- Lifetime of Kpt in seconds 711 kps-name OCTET STRING, -- Key name of Kps 712 integrity-data IntegrityData 713 -- Integrity protection with KIps 714 } 716 -- Integrity Data 717 IntegrityData ::= SEQUENCE { 718 integrity-algorithm IntegirityAlgorithm, -- integrity algorithm 719 mac OCTET_STRING -- message authentication code 720 } 722 -- Encrypted Data 723 EncryptedData ::= SEQUENCE { 724 encryption-algorithm EncryptionAlgorithm, -- encryption algorithm 725 cipher OCTET_STRING -- encrypted data 726 } 728 -- Encryption algorithm. The data contains an IKEv2 Transform ID of 729 -- Transform Type 1 [RFC4306] for the encryption algorithm. All KDE 730 -- implementations MUST support ENCR_AES_CBC [RFC3602]. It is allowed 731 -- to use null encryption (ENCR_NULL) for KDE2 and KDE3 in the case 732 -- where hop-by-hop security between third party and server is 733 -- acceptable. 734 EncryptionAlgorithm ::= UInt32 736 -- Integrith algorithm. The data contains an IKEv2 Transform ID of 737 -- Transform Type 3 [RFC4306] for the integrity algorithm. All KDE 738 -- implementations MUST support AUTH_HMAC_SHA1_160 (7) [RFC4595]. 739 -- It is allowed to use a null integrity mechanism (NONE) for 740 -- for KDE2 and KDE3 in the case where hop-by-hop security between 741 -- third party and server is acceptable. 743 IntegrityAlgorithm ::= UInt32 745 END 747 4.2. Message Encoding 749 The default encoding of KDE protocol messages shall obey the PER 750 (Packed Encoding Rules) of ASN.1 as described in [X691]. A KDE 751 transport protocol may specify other ASN.1 encoding method. 753 5. Security Considerations 755 5.1. Security Association between Server and Third Party 757 The key distribution mechanism described in this document is designed 758 to work with both end-to-end and hop-by-hop security association 759 between a server and a third party. 761 When end-to-end security is used, the key distribution mechanism 762 assumes existence of a direct trust relationship between the server 763 and the third party key holder. When such a direct trust 764 relationship may be dynamically created from a chain of transitive 765 trust relationships with the use of inter-realm Kerberos to 766 distribute KIts and KCts as described in Section 3.4. Therefore, the 767 key distribution method described in this document eliminates the 768 need for hop-by-hop security associations along the transitive trust 769 relationship. 771 When hop-by-hop security is used, no integrity protection and 772 encryption is provided within the KDE protocol. A null encryption 773 algorithm (ENCR_NULL) and a null integrity protection (NONE) are 774 specified in KDE. In this case, underlying transport protocol 775 security such as IPsec and (D)TLS MUST be used instead. The use of 776 hop-by-hop security implies that an intermediary on each hop can 777 access the distributed key material. Hence the use of hop-by-hop 778 security SHOULD be limited to an environment where an intermediary is 779 trusted not to use the distributed key material. 781 5.2. Replay Protection 783 The KDE protocol defines two freshness values to provide replay 784 protection. Sequence numbers generated by peer and maintained by 785 peer and server provide anti-replay for KDE messages 1, 2 and 4. 786 Nonces generated by third-party provide anti-replay for KDE message 787 3. 789 5.3. Distribution of Duplicate Kpt 791 If a Kpt is a USRK or a DSUSRK, it should be sufficient that 792 distribution of the Kpt happens only once during the lifetime of it's 793 root key, i.e., EMSK. Nevertheless, a peer may attempt to execute 794 the KDE protocol multiple times via the same third party with 795 specifying the same parameters in KDE message 1 except for sequence 796 number, for some reason such as loss of key state due to temporal 797 disconnection from the network. The server may accept such an 798 attempt and distribute a copy of the same Kpt back to the third 799 party, given that the lifetime of the Kpt (KL_Kpt) is recomputed such 800 that the key expiration time of the Kpt will not change for all 801 copies of the same Kpt. 803 6. IANA consideration 805 This document defines a new SMI Security for Mechanism Code for 806 hokey(to be assigned by IANA). 808 This document defines a new SMI Security for Mechanism hokey Code for 809 kde-v1(1). 811 This document defines new usage labels, such as those used in 812 generation of CK and IK. The corresponding labels, i.e., 813 "kde-cipher-key@ietf.org" for CK and "kde-integrity-key@ietf.org" for 814 IK, need to be assigned numerical values by IANA. 816 The Key Type namespace is used to identify the type of Kpt. The range 817 of values 0 - 65,535 are for permanent, standard message types, 818 allocated by IETF Consensus [IANA]. This document defines the values 819 0 (DSRK), 1 (rRK) and 2 (DS-rRK). 821 7. Acknowledgements 823 The author would like to thank Dan Harkins, Chunqiang Li, Rafael 824 Marin Lopez and Charles Clancy for their valuable contributions to 825 the formation of the KDE. 827 8. References 829 8.1. Normative References 831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 832 Requirement Levels", BCP 14, RFC 2119, March 1997. 834 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 835 Levkowetz, "Extensible Authentication Protocol (EAP)", 836 RFC 3748, June 2004. 838 [I-D.ietf-hokey-emsk-hierarchy] 839 Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 840 "Specification for the Derivation of Root Keys from an 841 Extended Master Session Key (EMSK)", 842 draft-ietf-hokey-emsk-hierarchy-04 (work in progress), 843 February 2008. 845 [I-D.ietf-hokey-erx] 846 Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 847 authentication Protocol (ERP)", draft-ietf-hokey-erx-12 848 (work in progress), February 2008. 850 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 851 Dial In User Service) Support For Extensible 852 Authentication Protocol (EAP)", RFC 3579, September 2003. 854 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 855 Authentication Protocol (EAP) Application", RFC 4072, 856 August 2005. 858 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 859 Kerberos Network Authentication Service (V5)", RFC 4120, 860 July 2005. 862 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 863 Authorization, and Accounting (AAA) Key Management", 864 BCP 132, RFC 4962, July 2007. 866 [X680] "Abstract Syntax Notation One (ASN.1): Specification of 867 Basic Notation, ITU-T Recommendation X.680 (2002).", 868 July 2002. 870 [X691] "Abstract Syntax Notation One (ASN.1): ASN.1 encoding 871 rules: Specification of Packed Encoding Rules (PER), ITU-T 872 Recommendation X.691 (2002).", July 2002. 874 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 875 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 876 October 1998. 878 8.2. Informative references 880 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 881 Key Management", BCP 107, RFC 4107, June 2005. 883 [I-D.ietf-eap-keying] 884 Aboba, B., Simon, D., and P. Eronen, "Extensible 885 Authentication Protocol (EAP) Key Management Framework", 886 draft-ietf-eap-keying-22 (work in progress), 887 November 2007. 889 [I-D.ietf-hokey-reauth-ps] 890 Clancy, C., Nakhjiri, M., Narayanan, V., and L. Dondeti, 891 "Handover Key Management and Re-authentication Problem 892 Statement", draft-ietf-hokey-reauth-ps-09 (work in 893 progress), February 2008. 895 Appendix A. KDE Transport 897 A.1. KDE Transport over UDP 899 This section defines UDP transport of KDE. A well-known port number 900 (to be assigned by IANA) is assigned for KDE. 902 For any KDE-PDU sent in response to another KDE-PDU received from the 903 other peer, the source port is set to the well-known port number (to 904 be assigned by IANA) assigned for KDE and the destination port is 905 copied from the source port of the received KDE-PDU. For other KDE- 906 PDUs, both the source and destination port numbers are set to the 907 well-known port number (to be assigned by IANA) assigned for KDE. 909 A.2. KDE Transport over AAA 911 When KDE messages are carried in AAA protocols, they are carried in a 912 RADIUS attribute or a corresponding Diameter AVP. The RADIUS 913 attribute for KDE is defined as follows: 915 0 1 2 3 916 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Type | Length | KDE-PDU ... 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 Figure 6: RADIUS Attribute for KDE 923 Type 925 IANA-TBD for KDE 927 Length 929 >=4 931 KDE-PDU 933 One KDE-PDU is included. 935 Authors' Addresses 937 Madjid Nakhjiri 938 Motorola 940 Email: madjid.nakhjiri@motorola.com 942 Yoshihiro Ohba 943 Toshiba 945 Email: yohba@tari.toshiba.com 947 Full Copyright Statement 949 Copyright (C) The IETF Trust (2008). 951 This document is subject to the rights, licenses and restrictions 952 contained in BCP 78, and except as set forth therein, the authors 953 retain all their rights. 955 This document and the information contained herein are provided on an 956 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 957 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 958 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 959 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 960 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 961 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 963 Intellectual Property 965 The IETF takes no position regarding the validity or scope of any 966 Intellectual Property Rights or other rights that might be claimed to 967 pertain to the implementation or use of the technology described in 968 this document or the extent to which any license under such rights 969 might or might not be available; nor does it represent that it has 970 made any independent effort to identify any such rights. Information 971 on the procedures with respect to rights in RFC documents can be 972 found in BCP 78 and BCP 79. 974 Copies of IPR disclosures made to the IETF Secretariat and any 975 assurances of licenses to be made available, or the result of an 976 attempt made to obtain a general license or permission for the use of 977 such proprietary rights by implementers or users of this 978 specification can be obtained from the IETF on-line IPR repository at 979 http://www.ietf.org/ipr. 981 The IETF invites any interested party to bring to its attention any 982 copyrights, patents or patent applications, or other proprietary 983 rights that may cover technology that may be required to implement 984 this standard. Please address the information to the IETF at 985 ietf-ipr@ietf.org. 987 Acknowledgment 989 Funding for the RFC Editor function is provided by the IETF 990 Administrative Support Activity (IASA).