idnits 2.17.1 draft-ietf-hokey-reauth-ps-04.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 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 520. 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 (September 28, 2007) is 6055 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-18 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 September 28, 2007 5 Expires: March 31, 2008 7 Handover Key Management and Re-authentication Problem Statement 8 draft-ietf-hokey-reauth-ps-04 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 March 31, 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 . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . 11 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 When a peer needs to re-affirm access to an authenticator or moves 154 from one authenticator to another, the current model requires the 155 peer to engage in a full EAP exchange with the EAP server in its home 156 domain [RFC3748]. 158 An EAP conversation with a full EAP method run can take several round 159 trips and significant time to complete, causing delays in re- 160 authentication and handover times. Some methods [RFC4187] specify 161 the use of keys and state from the initial authentication to finish 162 subsequent authentications in fewer round trips. However, even in 163 those cases, multiple round trips to the EAP server are still 164 involved. Furthermore, many commonly-used EAP methods do not offer 165 such a fast re-authentication feature. In summary, it is undesirable 166 to have to run a full EAP method each time a peer authenticates to a 167 new authenticator or needs to extend its current authentication with 168 the same authenticator. Furthermore, it is desirable to specify a 169 method-independent, efficient, re-authentication protocol. Keying 170 material from the full authentication can be used to enable efficient 171 re-authentication. 173 Significant network latency between the peer and EAP server is 174 another source of delay during re-authentication. It is desirable to 175 have a local server with low-latency connectivity to the peer that 176 can facilitate re-authentication. 178 Lastly, a re-authentication protocol should also be capable of 179 supporting handover keying. Handover keying allows re-authentication 180 keys to be passed to a different domain. Execution of the re- 181 authentication protocol in that domain will then allow handover from 182 one domain to another. 184 These problems are the primary issues to be resolved. In solving 185 them, there are a number of constraints to conform to and those 186 result in some additional work to be done in the area of EAP keying. 188 5. Design Goals 190 The following are the goals and constraints in designing the EAP re- 191 authentication and key management protocol: 193 Lower latency operation: The protocol MUST be responsive to handover 194 and re-authentication latency performance objectives within a 195 mobile access network. A solution that reduces latency as 196 compared to a full EAP authentication will be most favorable. 198 EAP lower-layer independence: Any keying hierarchy and protocol 199 defined MUST be lower layer independent in order to provide the 200 capability over heterogeneous technologies. The defined protocols 201 MAY require some additional support from the lower layers that use 202 it. Any keying hierarchy and protocol defined MUST accommodate 203 inter-technology heterogeneous handover. 205 EAP method independence: Changes to existing EAP methods MUST NOT be 206 required as a result of the re-authentication protocol. There 207 MUST be no requirements imposed on future EAP methods. Note that 208 the only EAP methods for which independence is required are those 209 that conform to the specifications of [I-D.ietf-eap-keying] and 210 [RFC4017]. 212 AAA protocol compatibility and keying: Any modifications to EAP and 213 EAP keying MUST be compatible with RADIUS and Diameter. 214 Extensions to both RADIUS and Diameter to support these EAP 215 modifications are acceptable. The designs and protocols must 216 satisfy the AAA key management requirements specified in RFC 4962 217 [RFC4962]. 219 Compatability: Compatibility and co-existence with compliant 220 ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be 221 provided. The keying hierarchy or protocol extensions MUST NOT 222 preclude the use of CAPWAP or IEEE 802.11r. 224 6. Security Goals 226 The section draws from the guidance provided in [RFC4962] to further 227 define the security goals to be achieved by a complete re- 228 authentication keying solution. 230 6.1. Key Context and Domino Effect 232 Any key MUST have a well-defined scope and MUST be used in a specific 233 context and for the intended use. This specifically means the 234 lifetime and scope of each key MUST be defined clearly so that all 235 entities that are authorized to have access to the key have the same 236 context during the validity period. In a hierarchical key structure, 237 the lifetime of lower level keys MUST NOT exceed the lifetime of 238 higher level keys. This requirement MAY imply that the context and 239 the scope parameters have to be exchanged. Furthermore, the 240 semantics of these parameters MUST be defined to provide proper 241 channel binding specifications. The definition of exact parameter 242 syntax definition is part of the design of the transport protocol 243 used for the parameter exchange and that may be outside scope of this 244 protocol. 246 If a key hierarchy is deployed, compromising lower level keys MUST 247 NOT result in a compromise of higher level keys which they were used 248 to derive the lower level keys. The compromise of keys at each level 249 MUST NOT result in compromise of other keys at the same level. The 250 same principle applies to entities that hold and manage a particular 251 key defined in the key hierarchy. Compromising keys on one 252 authenticator MUST NOT reveal the keys of another authenticator. 253 Note that the compromise of higher-level keys has security 254 implications on lower levels. 256 Guidance on parameters required, caching, storage and deletion 257 procedures to ensure adequate security and authorization provisioning 258 for keying procedures MUST be defined in a solution document. 260 All the keying material MUST be uniquely named so that it can be 261 managed effectively. 263 6.2. Key Freshness 265 As [RFC4962] defines, a fresh key is one that is generated for the 266 intended use. This would mean the key hierarchy MUST provide for 267 creation of multiple cryptographically separate child keys from a 268 root key at higher level. Furthermore, the keying solution needs to 269 provide mechanisms for refreshing each of the keys within the key 270 hierarchy. 272 6.3. Authentication 274 Each party in the handover keying architecture MUST be authenticated 275 to any other party with whom it communicates, and securely provide 276 its identity to any other entity that may require the identity for 277 defining the key scope. The identity provided MUST be meaningful 278 according to the protocol over which the two parties communicate. 280 6.4. Authorization 282 The EAP Key management document [I-D.ietf-eap-keying] discusses 283 several vulnerabilities that are common to handover mechanisms. One 284 important issue arises from the way the authorization decisions might 285 be handled at the AAA server during network access authentication. 286 For example, if AAA proxies are involved, they may also influence in 287 the authorization decision. Furthermore, the reasons for making a 288 particular authorization decision are not communicated to the 289 authenticator. In fact, the authenticator only knows the final 290 authorization result. The proposed solution MUST make efforts to 291 document and mitigate authorization attacks. 293 6.5. Channel Binding 295 Channel Binding procedures are needed to avoid a compromised 296 intermediate authenticator providing unverified and conflicting 297 service information to each of the peer and the EAP server. In the 298 architecture introduced in this document, there are multiple 299 intermediate entities between the peer and the back-end EAP server. 300 Various keys need to be established and scoped between these parties 301 and some of these keys may be parents to other keys. Hence the 302 channel binding for this architecture will need to consider layering 303 intermediate entities at each level to make sure that an entity with 304 higher level of trust can examine the truthfulness of the claims made 305 by intermediate parties. 307 6.6. Transport Aspects 309 Depending on the physical architecture and the functionality of the 310 elements involved, there may be a need for multiple protocols to 311 perform the key transport between entities involved in the handover 312 keying architecture. Thus, a set of requirements for each of these 313 protocols, and the parameters they will carry, MUST be developed. 314 Following the requirement specifications, recommendations will be 315 provided as to whether new protocols or extensions to existing 316 protocols are needed. 318 As mentioned, the use of existing AAA protocols for carrying EAP 319 messages and keying material between the AAA server and AAA clients 320 that have a role within the architecture considered for the keying 321 problem will be carefully examined. Definition of specific 322 parameters, required for keying procedures and to be transferred over 323 any of the links in the architecture, are part of the scope. The 324 relation of the identities used by the transport protocol and the 325 identities used for keying also needs to be explored. 327 7. Use Cases and Related Work 329 In order to further clarify the items listed in scope of the proposed 330 work, this section provides some background on related work and the 331 use cases envisioned for the proposed work. 333 7.1. IEEE 802.11r Applicability 335 One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D7.0], is in 336 the process of specifying a mechanism to avoid the problem of 337 repeated full EAP exchanges in a limited setting, by introducing a 338 two-level key hierarchy. The EAP authenticator is collocated with 339 what is known as an R0 Key Holder (R0-KH), which receives the MSK 340 from the EAP server. A pairwise master key (PMK-R0) is derived from 341 the last 32 octets of the MSK. Subsequently, the R0-KH derives an 342 PMK-R1 to be handed out to the attachment point of the peer. When 343 the peer moves from one R1-KH to another, a new PMK-R1 is generated 344 by the R0-KH and handed out to the new R1-KH. The transport protocol 345 used between the R0-KH and the R1-KH is not specified. 347 In some cases, a mobile may seldom move beyond the domain of the 348 R0-KH and this model works well. A full EAP authentication will 349 generally be repeated when the PMK-R0 expires. However, in general 350 cases mobiles may roam beyond the domain of R0-KHs (or EAP 351 authenticators), and the latency of full EAP authentication remains 352 an issue. 354 Another consideration is that there needs to be a key transfer 355 protocol between the R0-KH and the R1-KH; in other words, there is 356 either a star configuration of security associations between the key 357 holder and a centralized entity that serves as the R0-KH, or if the 358 first authenticator is the default R0-KH, there will be a full-mesh 359 of security associations between all authenticators. This is 360 undesirable. 362 The proposed work on EAP efficient re-authentication protocol aims at 363 addressing re-authentication in a lower layer agnostic manner that 364 also can fill some of the gaps in IEEE 802.11r. 366 7.2. IEEE 802.21 Applicability 368 The IEEE 802.21 working group [IEEE.802-21] is standardizing 369 mechanisms for media-independent handover. More specifically, they 370 are looking at transitions from one link-layer protocol to another, 371 which is currently beyond the scope of the HOKEY charter. 373 The techniques developed within HOKEY could be applicable to IEEE 374 802.21 if the necessary issues with handover between different lower 375 layers can be resolved. In particular, pre-authentication may be 376 more appropriate than re-authentication. 378 7.3. CAPWAP Applicability 380 The IETF CAPWAP WG [RFC3990] is developing a protocol between what is 381 termed an Access Controller (AC) and Wireless Termination Points 382 (WTP). The AC and WTP can be mapped to a WLAN switch and Access 383 Point respectively. The CAPWAP model supports both split and 384 integrated MAC architectures, with the authenticator always being 385 implemented at the AC. 387 The proposed work on EAP efficient re-authentication protocol 388 addresses an inter-authenticator handover problem from an EAP 389 perspective, which applies during handover between ACs. Inter- 390 controller handover is a topic yet to be addressed in great detail 391 and the re-authentication work can potentially address it in an 392 effective manner. 394 7.4. Inter-Technology Handover 396 EAP is used for access authentication by several technologies and is 397 under consideration for use over several other technologies going 398 forward. Given that, it should be feasible to support smoother 399 handover across technologies. That is one of the big advantages of 400 using a common authentication protocol. Authentication procedures 401 typically add substantial handover delays. 403 An EAP peer that has multiple radio technologies (802.11 and GSM, for 404 instance) must perform the full EAP exchange on each interface upon 405 every horizontal or vertical handover. With a method independent EAP 406 efficient re-authentication, it is feasible to support faster 407 handover even in the vertical handover cases, when the peer may be 408 roaming from one technology to another. 410 8. Security Considerations 412 This document details the HOKEY problem statement. Since HOKEY is an 413 authentication protocol, there are a myriad of security-related 414 issues surrounding its development and deployment. 416 In this document, we have detailed a variety of security properties 417 inferred from [RFC4962] to which HOKEY must conform, including the 418 management of key context, scope, freshness, and transport; 419 resistance to attacks based on the domino effect; and authentication 420 and authorization. See section Section 6 for further details. 422 9. IANA Considerations 424 This document does not introduce any new IANA considerations. 426 10. References 428 10.1. Normative References 430 [I-D.ietf-eap-keying] 431 Aboba, B., "Extensible Authentication Protocol (EAP) Key 432 Management Framework", draft-ietf-eap-keying-18 (work in 433 progress), February 2007. 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 438 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 439 Levkowetz, "Extensible Authentication Protocol (EAP)", 440 RFC 3748, June 2004. 442 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 443 Authentication Protocol (EAP) Method Requirements for 444 Wireless LANs", RFC 4017, March 2005. 446 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 447 Authorization, and Accounting (AAA) Key Management", 448 BCP 132, RFC 4962, July 2007. 450 10.2. Informative References 452 [RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and 453 Provisioning for Wireless Access Points (CAPWAP) Problem 454 Statement", RFC 3990, February 2005. 456 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 457 Protocol Method for 3rd Generation Authentication and Key 458 Agreement (EAP-AKA)", RFC 4187, January 2006. 460 [IEEE.802-11R-D7.0] 461 "Information technology - Telecommunications and 462 information exchange between systems - Local and 463 metropolitan area networks - Specific requirements - Part 464 11: Wireless LAN Medium Access Control (MAC) and Physical 465 Layer (PHY) specifications - Amendment 2: Fast BSS 466 Transition", IEEE Standard 802.11r, June 2007. 468 [IEEE.802-21] 469 "Media Independent Handover Working Group", IEEE Working 470 Group 802.21. 472 Author's Address 474 T. Charles Clancy, Editor 475 DoD Laboratory for Telecommunications Sciences 476 8080 Greenmead Drive 477 College Park, MD 20740 478 USA 480 Email: clancy@LTSnet.net 482 Full Copyright Statement 484 Copyright (C) The IETF Trust (2007). 486 This document is subject to the rights, licenses and restrictions 487 contained in BCP 78, and except as set forth therein, the authors 488 retain all their rights. 490 This document and the information contained herein are provided on an 491 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 492 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 493 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 494 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 495 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 496 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 498 Intellectual Property 500 The IETF takes no position regarding the validity or scope of any 501 Intellectual Property Rights or other rights that might be claimed to 502 pertain to the implementation or use of the technology described in 503 this document or the extent to which any license under such rights 504 might or might not be available; nor does it represent that it has 505 made any independent effort to identify any such rights. Information 506 on the procedures with respect to rights in RFC documents can be 507 found in BCP 78 and BCP 79. 509 Copies of IPR disclosures made to the IETF Secretariat and any 510 assurances of licenses to be made available, or the result of an 511 attempt made to obtain a general license or permission for the use of 512 such proprietary rights by implementers or users of this 513 specification can be obtained from the IETF on-line IPR repository at 514 http://www.ietf.org/ipr. 516 The IETF invites any interested party to bring to its attention any 517 copyrights, patents or patent applications, or other proprietary 518 rights that may cover technology that may be required to implement 519 this standard. Please address the information to the IETF at 520 ietf-ipr@ietf.org. 522 Acknowledgment 524 Funding for the RFC Editor function is provided by the IETF 525 Administrative Support Activity (IASA).