idnits 2.17.1 draft-ietf-hokey-reauth-ps-05.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 495. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 519. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2, 2007) is 6013 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-21 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HOKEY Working Group T. Clancy, Editor 3 Internet-Draft LTS 4 Intended status: Informational November 2, 2007 5 Expires: May 5, 2008 7 Handover Key Management and Re-authentication Problem Statement 8 draft-ietf-hokey-reauth-ps-05 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 5, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes the Handover Keying (HOKEY) problem 42 statement. The current EAP keying framework is not designed to 43 support re-authentication and handovers. This often cause 44 unacceptable latency in various mobile wireless environments. HOKEY 45 plans to address these HOKEY plans to address these problems by 46 implementing a generic mechanism to reuse derived EAP keying material 47 for handover. 49 Table of Contents 51 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 57 6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6 58 6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7 59 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 60 6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 61 6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7 62 6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 7 63 7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8 64 7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 8 65 7.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 9 66 7.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9 67 7.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 9 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 Intellectual Property and Copyright Statements . . . . . . . . . . 12 76 1. Contributors 78 The following authors contributed to the HOKEY problem statement 79 document: 81 o Julien Bournelle, France Telecom R&D, 82 julien.bournelle@orange-ftgroup.com 83 o Lakshminath Dondeti, QUALCOMM, ldondeti@qualcomm.com 84 o Rafael Marin Lopez, Universidad de Murcia, rafa@dif.um.es 85 o Madjid Nakhjiri, Motorola, madjid.nakhjiri@motorola.com 86 o Vidya Narayanan, QUALCOMM, vidyan@qualcomm.com 87 o Mohan Parthasarathy, Nokia, mohan.parthasarathy@nokia.com 88 o Hannes Tschofenig, Siemens, Hannes.Tschofenig@siemens.com 90 2. Introduction 92 The Extensible Authentication Protocol (EAP), specified in RFC 3748 93 [RFC3748] is a generic framework supporting multiple authentication 94 methods. The primary purpose of EAP is network access control. It 95 also supports exporting session keys derived during the 96 authentication. The EAP keying hierarchy defines two keys that are 97 derived at the top level, the master session key (MSK) and the 98 extended MSK (EMSK). 100 In many common deployment scenario, an EAP peer and EAP server 101 authenticate each other through a third party known as the pass- 102 through authenticator (hereafter referred to as simply 103 "authenticator"). The authenticator is responsible for translating 104 EAP packets from the layer 2 (L2) or layer 3 (L3) network access 105 technology to the AAA protocol. 107 According to [RFC3748], after successful authentication, the server 108 transports the MSK to the authenticator. The underlying L2 or L3 109 protocol uses the MSK to derive additional keys, including the 110 transient session keys (TSK) used per-packet access encryption and 111 enforcement. 113 Note that while the authenticator is one logical device, there can be 114 multiple physical devices involved. For example, the CAPWAP model 115 [RFC3990] splits authenticators into two logical devices: Wireless 116 Termination Points (WTPs) and Access Controllers (ACs). Depending on 117 the configuration, authenticator features can be split in a variety 118 of ways between physical devices, however from the EAP perspective 119 there is only one logical authenticator. 121 The current models of EAP authentication and keying are unfortunately 122 not efficient in case of mobile and wireless networks. When a peer 123 arrives at the new authenticator, or is expected to re-affirm its 124 access through the current authenticator, the security restraints 125 will require the peer to run an EAP method irrespective of whether it 126 has been authenticated to the network recently and has unexpired 127 keying material. A full EAP method execution may involves several 128 round trips between the EAP peer and the server. 130 There have been attempts to solve the problem of efficient re- 131 authentication in various ways. However, those solutions are either 132 EAP-method specific, EAP lower-layer specific, or are otherwise 133 limited in scope. Furthermore, these solutions do not deal with 134 scenarios involving handovers to new authenticators, or do not 135 conform to the AAA keying requirements specified in [RFC4962]. 137 This document provides a detailed description of EAP efficient re- 138 authentication protocol requirements. 140 3. Terminology 142 In this document, several words are used to signify the requirements 143 of the specification. These words are often capitalized. The key 144 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 145 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 146 are to be interpreted as described in [RFC2119]. 148 With respect to EAP, this document follows the terminology that has 149 been defined in [RFC3748] and [I-D.ietf-eap-keying]. 151 4. Problem Statement 153 Under the existing model, any re-authentication requires a full EAP 154 exchange with the EAP server in its home domain [RFC3748]. An EAP 155 conversation with a full EAP method run can take several round trips 156 and significant time to complete, causing delays in re-authentication 157 and handover times. Some methods [RFC4187] specify the use of keys 158 and state from the initial authentication to finish subsequent 159 authentications in fewer round trips. However, even in those cases, 160 multiple round trips to the EAP server are still involved. 161 Furthermore, many commonly-used EAP methods do not offer such a fast 162 re-authentication feature. In summary, it is undesirable to have to 163 run a full EAP method each time a peer authenticates to a new 164 authenticator or needs to extend its current authentication with the 165 same authenticator. Furthermore, it is desirable to specify a 166 method-independent, efficient, re-authentication protocol. Keying 167 material from the full authentication can be used to enable efficient 168 re-authentication. 170 Significant network latency between the peer and EAP server is 171 another source of delay during re-authentication. It is desirable to 172 have a local server with low-latency connectivity to the peer that 173 can facilitate re-authentication. 175 Lastly, a re-authentication protocol should also be capable of 176 supporting handover keying. Handover keying allows re-authentication 177 keys to be passed to a different re-authentication domain (not 178 necessarily a different AAA domain or administrative domain). 179 Execution of the re-authentication protocol in that re-authentication 180 domain will then allow handover from one re-authentication domain to 181 another. 183 These problems are the primary issues to be resolved. In solving 184 them, there are a number of constraints to conform to and those 185 result in some additional work to be done in the area of EAP keying. 187 5. Design Goals 189 The following are the goals and constraints in designing the EAP re- 190 authentication and key management protocol: 192 Lower latency operation: The protocol MUST be responsive to handover 193 and re-authentication latency performance objectives within a 194 mobile access network. A solution that reduces latency as 195 compared to a full EAP authentication will be most favorable. 197 EAP lower-layer independence: Any keying hierarchy and protocol 198 defined MUST be lower layer independent in order to provide the 199 capability over heterogeneous technologies. The defined protocols 200 MAY require some additional support from the lower layers that use 201 it. Any keying hierarchy and protocol defined MUST accommodate 202 inter-technology heterogeneous handover. 204 EAP method independence: Changes to existing EAP methods MUST NOT be 205 required as a result of the re-authentication protocol. There 206 MUST be no requirements imposed on future EAP methods. Note that 207 the only EAP methods for which independence is required are those 208 that conform to the specifications of [I-D.ietf-eap-keying] and 209 [RFC4017]. 211 AAA protocol compatibility and keying: Any modifications to EAP and 212 EAP keying MUST be compatible with RADIUS and Diameter. 213 Extensions to both RADIUS and Diameter to support these EAP 214 modifications are acceptable. The designs and protocols must 215 satisfy the AAA key management requirements specified in RFC 4962 216 [RFC4962]. 218 Compatability: Compatibility and co-existence with compliant 219 ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be 220 provided. The keying hierarchy or protocol extensions MUST NOT 221 preclude the use of CAPWAP or IEEE 802.11r. 223 6. Security Goals 225 The section draws from the guidance provided in [RFC4962] to further 226 define the security goals to be achieved by a complete re- 227 authentication keying solution. 229 6.1. Key Context and Domino Effect 231 Any key MUST have a well-defined scope and MUST be used in a specific 232 context and for the intended use. This specifically means the 233 lifetime and scope of each key MUST be defined clearly so that all 234 entities that are authorized to have access to the key have the same 235 context during the validity period. In a hierarchical key structure, 236 the lifetime of lower level keys MUST NOT exceed the lifetime of 237 higher level keys. This requirement MAY imply that the context and 238 the scope parameters have to be exchanged. Furthermore, the 239 semantics of these parameters MUST be defined to provide proper 240 channel binding specifications. The definition of exact parameter 241 syntax definition is part of the design of the transport protocol 242 used for the parameter exchange and that may be outside scope of this 243 protocol. 245 If a key hierarchy is deployed, compromising lower level keys MUST 246 NOT result in a compromise of higher level keys which they were used 247 to derive the lower level keys. The compromise of keys at each level 248 MUST NOT result in compromise of other keys at the same level. The 249 same principle applies to entities that hold and manage a particular 250 key defined in the key hierarchy. Compromising keys on one 251 authenticator MUST NOT reveal the keys of another authenticator. 252 Note that the compromise of higher-level keys has security 253 implications on lower levels. 255 Guidance on parameters required, caching, storage and deletion 256 procedures to ensure adequate security and authorization provisioning 257 for keying procedures MUST be defined in a solution document. 259 All the keying material MUST be uniquely named so that it can be 260 managed effectively. 262 6.2. Key Freshness 264 As [RFC4962] defines, a fresh key is one that is generated for the 265 intended use. This would mean the key hierarchy MUST provide for 266 creation of multiple cryptographically separate child keys from a 267 root key at higher level. Furthermore, the keying solution needs to 268 provide mechanisms for refreshing each of the keys within the key 269 hierarchy. 271 6.3. Authentication 273 Each party in the handover keying architecture MUST be authenticated 274 to any other party with whom it communicates, and securely provide 275 its identity to any other entity that may require the identity for 276 defining the key scope. The identity provided MUST be meaningful 277 according to the protocol over which the two parties communicate. 279 6.4. Authorization 281 The EAP Key management document [I-D.ietf-eap-keying] discusses 282 several vulnerabilities that are common to handover mechanisms. One 283 important issue arises from the way the authorization decisions might 284 be handled at the AAA server during network access authentication. 285 For example, if AAA proxies are involved, they may also influence in 286 the authorization decision. Furthermore, the reasons for making a 287 particular authorization decision are not communicated to the 288 authenticator. In fact, the authenticator only knows the final 289 authorization result. The proposed solution MUST make efforts to 290 document and mitigate authorization attacks. 292 6.5. Channel Binding 294 Channel Binding procedures are needed to avoid a compromised 295 intermediate authenticator providing unverified and conflicting 296 service information to each of the peer and the EAP server. In the 297 architecture introduced in this document, there are multiple 298 intermediate entities between the peer and the back-end EAP server. 299 Various keys need to be established and scoped between these parties 300 and some of these keys may be parents to other keys. Hence the 301 channel binding for this architecture will need to consider layering 302 intermediate entities at each level to make sure that an entity with 303 higher level of trust can examine the truthfulness of the claims made 304 by intermediate parties. 306 6.6. Transport Aspects 308 Depending on the physical architecture and the functionality of the 309 elements involved, there may be a need for multiple protocols to 310 perform the key transport between entities involved in the handover 311 keying architecture. Thus, a set of requirements for each of these 312 protocols, and the parameters they will carry, MUST be developed. 313 Following the requirement specifications, recommendations will be 314 provided as to whether new protocols or extensions to existing 315 protocols are needed. 317 As mentioned, the use of existing AAA protocols for carrying EAP 318 messages and keying material between the AAA server and AAA clients 319 that have a role within the architecture considered for the keying 320 problem will be carefully examined. Definition of specific 321 parameters, required for keying procedures and to be transferred over 322 any of the links in the architecture, are part of the scope. The 323 relation of the identities used by the transport protocol and the 324 identities used for keying also needs to be explored. 326 7. Use Cases and Related Work 328 In order to further clarify the items listed in scope of the proposed 329 work, this section provides some background on related work and the 330 use cases envisioned for the proposed work. 332 7.1. IEEE 802.11r Applicability 334 One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D7.0], is in 335 the process of specifying a mechanism to avoid the problem of 336 repeated full EAP exchanges in a limited setting, by introducing a 337 two-level key hierarchy. The EAP authenticator is collocated with 338 what is known as an R0 Key Holder (R0-KH), which receives the MSK 339 from the EAP server. A pairwise master key (PMK-R0) is derived from 340 the last 32 octets of the MSK. Subsequently, the R0-KH derives an 341 PMK-R1 to be handed out to the attachment point of the peer. When 342 the peer moves from one R1-KH to another, a new PMK-R1 is generated 343 by the R0-KH and handed out to the new R1-KH. The transport protocol 344 used between the R0-KH and the R1-KH is not specified. 346 In some cases, a mobile may seldom move beyond the domain of the 347 R0-KH and this model works well. A full EAP authentication will 348 generally be repeated when the PMK-R0 expires. However, in general 349 cases mobiles may roam beyond the domain of R0-KHs (or EAP 350 authenticators), and the latency of full EAP authentication remains 351 an issue. 353 Another consideration is that there needs to be a key transfer 354 protocol between the R0-KH and the R1-KH; in other words, there is 355 either a star configuration of security associations between the key 356 holder and a centralized entity that serves as the R0-KH, or if the 357 first authenticator is the default R0-KH, there will be a full-mesh 358 of security associations between all authenticators. This is 359 undesirable. 361 The proposed work on EAP efficient re-authentication protocol aims at 362 addressing re-authentication in a lower layer agnostic manner that 363 also can fill some of the gaps in IEEE 802.11r. 365 7.2. IEEE 802.21 Applicability 367 The IEEE 802.21 working group [IEEE.802-21] is standardizing 368 mechanisms for media-independent handover. More specifically, they 369 are looking at transitions from one link-layer protocol to another, 370 which is currently beyond the scope of the HOKEY charter. 372 The techniques developed within HOKEY could be applicable to IEEE 373 802.21 if the necessary issues with handover between different lower 374 layers can be resolved. In particular, pre-authentication may be 375 more appropriate than re-authentication. 377 7.3. CAPWAP Applicability 379 The IETF CAPWAP WG [RFC3990] is developing a protocol between what is 380 termed an Access Controller (AC) and Wireless Termination Points 381 (WTP). The AC and WTP can be mapped to a WLAN switch and Access 382 Point respectively. The CAPWAP model supports both split and 383 integrated MAC architectures, with the authenticator always being 384 implemented at the AC. 386 The proposed work on EAP efficient re-authentication protocol 387 addresses an inter-authenticator handover problem from an EAP 388 perspective, which applies during handover between ACs. Inter- 389 controller handover is a topic yet to be addressed in great detail 390 and the re-authentication work can potentially address it in an 391 effective manner. 393 7.4. Inter-Technology Handover 395 EAP is used for access authentication by several technologies and is 396 under consideration for use over several other technologies going 397 forward. Given that, it should be feasible to support smoother 398 handover across technologies. That is one of the big advantages of 399 using a common authentication protocol. Authentication procedures 400 typically add substantial handover delays. 402 An EAP peer that has multiple radio technologies (802.11 and GSM, for 403 instance) must perform the full EAP exchange on each interface upon 404 every horizontal or vertical handover. With a method independent EAP 405 efficient re-authentication, it is feasible to support faster 406 handover even in the vertical handover cases, when the peer may be 407 roaming from one technology to another. 409 8. Security Considerations 411 This document details the HOKEY problem statement. Since HOKEY is an 412 authentication protocol, there are a myriad of security-related 413 issues surrounding its development and deployment. 415 In this document, we have detailed a variety of security properties 416 inferred from [RFC4962] to which HOKEY must conform, including the 417 management of key context, scope, freshness, and transport; 418 resistance to attacks based on the domino effect; and authentication 419 and authorization. See section Section 6 for further details. 421 9. IANA Considerations 423 This document does not introduce any new IANA considerations. 425 10. References 427 10.1. Normative References 429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", BCP 14, RFC 2119, March 1997. 432 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 433 Levkowetz, "Extensible Authentication Protocol (EAP)", 434 RFC 3748, June 2004. 436 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 437 Authentication Protocol (EAP) Method Requirements for 438 Wireless LANs", RFC 4017, March 2005. 440 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 441 Authorization, and Accounting (AAA) Key Management", 442 BCP 132, RFC 4962, July 2007. 444 10.2. Informative References 446 [I-D.ietf-eap-keying] 447 Aboba, B., Simon, D., and P. Eronen, "Extensible 448 Authentication Protocol (EAP) Key Management Framework", 449 draft-ietf-eap-keying-21 (work in progress), October 2007. 451 [RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and 452 Provisioning for Wireless Access Points (CAPWAP) Problem 453 Statement", RFC 3990, February 2005. 455 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 456 Protocol Method for 3rd Generation Authentication and Key 457 Agreement (EAP-AKA)", RFC 4187, January 2006. 459 [IEEE.802-11R-D7.0] 460 "Information technology - Telecommunications and 461 information exchange between systems - Local and 462 metropolitan area networks - Specific requirements - Part 463 11: Wireless LAN Medium Access Control (MAC) and Physical 464 Layer (PHY) specifications - Amendment 2: Fast BSS 465 Transition", IEEE Standard 802.11r, June 2007. 467 [IEEE.802-21] 468 "Media Independent Handover Working Group", IEEE Working 469 Group 802.21. 471 Author's Address 473 T. Charles Clancy, Editor 474 DoD Laboratory for Telecommunications Sciences 475 8080 Greenmead Drive 476 College Park, MD 20740 477 USA 479 Email: clancy@LTSnet.net 481 Full Copyright Statement 483 Copyright (C) The IETF Trust (2007). 485 This document is subject to the rights, licenses and restrictions 486 contained in BCP 78, and except as set forth therein, the authors 487 retain all their rights. 489 This document and the information contained herein are provided on an 490 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 491 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 492 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 493 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 494 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 495 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 497 Intellectual Property 499 The IETF takes no position regarding the validity or scope of any 500 Intellectual Property Rights or other rights that might be claimed to 501 pertain to the implementation or use of the technology described in 502 this document or the extent to which any license under such rights 503 might or might not be available; nor does it represent that it has 504 made any independent effort to identify any such rights. Information 505 on the procedures with respect to rights in RFC documents can be 506 found in BCP 78 and BCP 79. 508 Copies of IPR disclosures made to the IETF Secretariat and any 509 assurances of licenses to be made available, or the result of an 510 attempt made to obtain a general license or permission for the use of 511 such proprietary rights by implementers or users of this 512 specification can be obtained from the IETF on-line IPR repository at 513 http://www.ietf.org/ipr. 515 The IETF invites any interested party to bring to its attention any 516 copyrights, patents or patent applications, or other proprietary 517 rights that may cover technology that may be required to implement 518 this standard. Please address the information to the IETF at 519 ietf-ipr@ietf.org. 521 Acknowledgment 523 Funding for the RFC Editor function is provided by the IETF 524 Administrative Support Activity (IASA).