idnits 2.17.1 draft-ietf-hokey-reauth-ps-09.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 674. 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 (February 23, 2008) is 5908 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-funk-eap-ttls-v0-02 == Outdated reference: A later version (-15) exists of draft-ietf-capwap-protocol-specification-09 == Outdated reference: A later version (-28) exists of draft-ietf-dime-app-design-guide-06 == Outdated reference: A later version (-19) exists of draft-ietf-radext-design-02 -- Obsolete informational reference (is this intentional?): RFC 4507 (Obsoleted by RFC 5077) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HOKEY Working Group T. Clancy 3 Internet-Draft LTS 4 Intended status: Informational M. Nakhjiri 5 Expires: August 26, 2008 Motorola 6 V. Narayanan 7 L. Dondeti 8 Qualcomm 9 February 23, 2008 11 Handover Key Management and Re-authentication Problem Statement 12 draft-ietf-hokey-reauth-ps-09 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 26, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document describes the Handover Keying (HOKEY) re-authentication 46 problem statement. The current Extensible Authentication Protocol 47 (EAP) keying framework is not designed to support re-authentication 48 and handovers without re-executing an EAP method. This often causes 49 unacceptable latency in various mobile wireless environments. This 50 document details the problem and defines design goals for a generic 51 mechanism to reuse derived EAP keying material for handover. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7 61 5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7 62 5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 63 5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 64 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8 65 5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8 66 6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9 67 6.1. Method-Specific EAP Re-authentication . . . . . . . . . . 9 68 6.2. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9 69 6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 76 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 78 Intellectual Property and Copyright Statements . . . . . . . . . . 15 80 1. Introduction 82 The Extensible Authentication Protocol (EAP), specified in RFC 3748 83 [RFC3748] is a generic framework supporting multiple authentication 84 methods. The primary purpose of EAP is network access control. It 85 also supports exporting session keys derived during the 86 authentication. The EAP keying hierarchy defines two keys that are 87 derived at the top level, the Master Session Key (MSK) and the 88 Extended Master Session Key (EMSK). 90 In many common deployment scenarios, an EAP peer and EAP server 91 authenticate each other through a third party known as the pass- 92 through authenticator (hereafter referred to as simply 93 "authenticator"). The authenticator is responsible for encapsulating 94 EAP packets from a network access technology lower layer within the 95 Authentication, Authorization, and Accounting (AAA) protocol. The 96 authenticator does not directly participate in the EAP exchange, and 97 simply acts as a gateway during the EAP method execution. 99 After successful authentication, the EAP server transports the MSK to 100 the authenticator. Note that this is performed using AAA protocols, 101 not EAP itself. The underlying L2 or L3 protocol uses the MSK to 102 derive additional keys, including the transient session keys (TSKs) 103 used for per-packet encryption and authentication. 105 Note that while the authenticator is one logical device, there can be 106 multiple physical devices involved. For example, the CAPWAP model 107 [RFC3990] splits authenticators into two logical devices: Wireless 108 Termination Points (WTPs) and Access Controllers (ACs). Depending on 109 the configuration, authenticator features can be split in a variety 110 of ways between physical devices, however from the EAP perspective 111 there is only one logical authenticator. 113 Wireless handover between access points or base stations is typically 114 a complex process that involves several layers of protocol execution. 115 Often times executing these protocols results in unacceptable delays 116 for many real-time applications such as voice [MSA03]. One part of 117 the handover process is EAP re-authentication, which can contribute 118 significantly to the overall handover time [MSPCA04]. Thus in many 119 environments we can lower overall handover time by lowering EAP re- 120 authentication time. 122 In EAP existing implementations, when a peer arrives at the new 123 authenticator, it runs an EAP method irrespective of whether it has 124 been authenticated to the network recently and has unexpired keying 125 material. This typically involves an EAP-Response/Identity message 126 from the peer to server, followed by one or more round trips between 127 the EAP server and peer to perform the authentication, followed by 128 the EAP-Success or EAP-Failure message from the EAP server to the 129 peer. At a minimum, the EAP exchange consists of 1.5 round trips. 130 However, given the way EAP interacts with AAA, and given that an EAP 131 identity exchange is typically employed, at least 2 round trips are 132 required to the EAP server. An even higher number of round trips is 133 required by the most commonly used EAP methods. For instance, EAP- 134 TLS requires at least 3 but typically 4 or more round trips. 136 There have been attempts to solve the problem of efficient re- 137 authentication in various ways. However, those solutions are either 138 EAP-method specific or EAP lower-layer specific. Furthermore, these 139 solutions do not deal with scenarios involving handovers to new 140 authenticators, or do not conform to the AAA keying requirements 141 specified in [RFC4962]. 143 This document provides a detailed description of efficient EAP-based 144 re-authentication protocol design goals. The scope of this protocol 145 is specifically re-authentication and handover between authenticators 146 within a single administrative domain. While the design goals 147 presented in this document may facilitate inter-technology handover 148 and inter-administrative-domain handover, they are outside the scope 149 of this protocol. 151 2. Terminology 153 In this document, several words are used to signify the requirements 154 of the specification. These words are often capitalized. The key 155 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 156 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 157 are to be interpreted as described in [RFC2119], with the 158 qualification that unless otherwise stated they apply to the design 159 of the re-authentication protocol, not its implementation or 160 application. 162 With respect to EAP, this document follows the terminology that has 163 been defined in [RFC3748] and [I-D.ietf-eap-keying]. 165 3. Problem Statement 167 Under the existing model, any re-authentication requires a full EAP 168 exchange with the EAP server to which the peer initially 169 authenticated [RFC3748]. This introduces handover latency from both 170 network transit time and processing delay. In service provider 171 networks, the home EAP server for a peer could be on the other side 172 of the world, and typical intercontinental latencies across the 173 Internet are 100 to 300 milliseconds per round trip [LGS07]. 175 Processing delays average a couple of milliseconds for symmetric-key 176 operations and hundreds of milliseconds for public-key operations. 178 An EAP conversation with a full EAP method run can take two or more 179 round trips to complete, causing delays in re-authentication and 180 handover times. Some methods specify the use of keys and state from 181 the initial authentication to finish subsequent authentications in 182 fewer round trips and without using public-key operations (detailed 183 Section 6.1). However, even in those cases, multiple round trips to 184 the EAP server are required, resulting in unacceptable handover 185 times. 187 In summary, it is undesirable to run an EAP Identity and complete EAP 188 method exchange each time a peer authenticates to a new authenticator 189 or needs to extend its current authentication with the same 190 authenticator. Furthermore, it is desirable to specify a method- 191 independent, efficient, re-authentication protocol. Keying material 192 from the initial authentication can be used to enable efficient re- 193 authentication. It is also desirable to have a local server with 194 low-latency connectivity to the peer that can facilitate re- 195 authentication. Lastly, a re-authentication protocol should also be 196 capable of supporting scenarios where an EAP server passes 197 authentication information to a remote re-authentication server, 198 allowing a peer to re-authenticate locally without having to 199 communicate with its home re-authentication server. 201 These problems are the primary issues to be resolved. In solving 202 them, there are a number of constraints to conform to and those 203 result in some additional work to be done in the area of EAP keying. 205 4. Design Goals 207 The following are the goals and constraints in designing the EAP re- 208 authentication and key management protocol: 210 Lower latency operation: The protocol MUST be responsive to handover 211 and re-authentication latency performance objectives within a 212 mobile access network. A solution that reduces latency as 213 compared to a full EAP authentication will be most favorable, 214 since in networks that rely on reactive re-authentication this 215 will directly impact handover times. 217 EAP lower-layer independence: Any keying hierarchy and protocol 218 defined MUST be lower layer independent in order to provide 219 capabilities over heterogeneous technologies. The defined 220 protocols MAY require some additional support from the lower 221 layers that use it, but should not require any particular lower 222 layer. 224 EAP method independence: Changes to existing EAP methods MUST NOT be 225 required as a result of the re-authentication protocol. There 226 MUST be no requirements imposed on future EAP methods, provided 227 they satisfy [I-D.ietf-eap-keying] and [RFC4017]. Note that the 228 only EAP methods for which independence is required are those that 229 currently conform to the specifications of [I-D.ietf-eap-keying] 230 and [RFC4017]. In particular, methods that do not generate the 231 keys required by [I-D.ietf-eap-keying] need not be supported by 232 the re-authentication protocol. 234 AAA protocol compatibility and keying: Any modifications to EAP and 235 EAP keying MUST be compatible with RADIUS [I-D.ietf-radext-design] 236 and Diameter [I-D.ietf-dime-app-design-guide]. Extensions to both 237 RADIUS and Diameter to support these EAP modifications are 238 acceptable. The designs and protocols must be configurable to 239 satisfy the AAA key management requirements specified in RFC 4962 240 [RFC4962]. 242 Compatibility: Compatibility and co-existence with compliant 243 ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments MUST be 244 provided. Specifically, the protocol should be designed such that 245 a peer not supporting fast re-reauthentication should still 246 function in a network supporting fast re-authentication, and also 247 a peer supporting fast re-authentication should still function in 248 a network not supporting fast re-authentication. 250 Cryptographic Agility: Any re-authentication protocol MUST support 251 cryptographic algorithm agility, to avoid hard-coded primitives 252 whose security may eventually prove to be compromised. The 253 protocol MAY support cryptographic algorithm negotiation, provided 254 it does not adversely affect overall performance (i.e. by 255 requiring additional round trips). 257 Impact to Existing Deployments: Any re-authentication protocol MAY 258 make changes to the peer, authenticator, and EAP server, as 259 necessary to meet the aforementioned design goals. In order to 260 facilitate protocol deployment, protocols should seek to minimize 261 the necessary changes, without sacrificing performance. 263 5. Security Goals 265 The section draws from the guidance provided in [RFC4962] to further 266 define the security goals to be achieved by a complete re- 267 authentication keying solution. 269 5.1. Key Context and Domino Effect 271 Any key must have a well-defined scope and must be used in a specific 272 context and for the intended use. This specifically means the 273 lifetime and scope of each key must be defined clearly so that all 274 entities that are authorized to have access to the key have the same 275 context during the validity period. In a hierarchical key structure, 276 the lifetime of lower level keys must not exceed the lifetime of 277 higher level keys. This requirement may imply that the context and 278 the scope parameters have to be exchanged. Furthermore, the 279 semantics of these parameters must be defined to provide proper 280 channel binding specifications. The definition of exact parameter 281 syntax definition is part of the design of the transport protocol 282 used for the parameter exchange and that may be outside scope of this 283 protocol. 285 If a key hierarchy is deployed, compromising lower level keys must 286 not result in a compromise of higher level keys which were used to 287 derive the lower level keys. The compromise of keys at each level 288 must not result in compromise of other keys at the same level. The 289 same principle applies to entities that hold and manage a particular 290 key defined in the key hierarchy. Compromising keys on one 291 authenticator must not reveal the keys of another authenticator. 292 Note that the compromise of higher-level keys has security 293 implications on lower levels. 295 Guidance on parameters required, caching, storage and deletion 296 procedures to ensure adequate security and authorization provisioning 297 for keying procedures must be defined in a solution document. 299 All the keying material must be uniquely named so that it can be 300 managed effectively. 302 5.2. Key Freshness 304 As [RFC4962] defines, a fresh key is one that is generated for the 305 intended use. This would mean the key hierarchy must provide for 306 creation of multiple cryptographically separate child keys from a 307 root key at higher level. Furthermore, the keying solution needs to 308 provide mechanisms for refreshing each of the keys within the key 309 hierarchy. 311 5.3. Authentication 313 Each handover keying participant must be authenticated to any other 314 party with whom it communicates to the extent it is necessary to 315 ensure proper key scoping, and securely provide its identity to any 316 other entity that may require the identity for defining the key 317 scope. 319 5.4. Authorization 321 The EAP Key management document [I-D.ietf-eap-keying] discusses 322 several vulnerabilities that are common to handover mechanisms. One 323 important issue arises from the way the authorization decisions might 324 be handled at the AAA server during network access authentication. 325 Furthermore, the reasons for making a particular authorization 326 decision are not communicated to the authenticator. In fact, the 327 authenticator only knows the final authorization result. The 328 proposed solution must make efforts to document and mitigate 329 authorization attacks. 331 5.5. Channel Binding 333 Channel Binding procedures are needed to avoid a compromised 334 intermediate authenticator providing unverified and conflicting 335 service information to each of the peer and the EAP server. To 336 support fast re-authentication, there will be intermediate entities 337 between the peer and the back-end EAP server. Various keys need to 338 be established and scoped between these parties and some of these 339 keys may be parents to other keys. Hence the channel binding for 340 this architecture will need to consider layering intermediate 341 entities at each level to make sure that an entity with higher level 342 of trust can examine the truthfulness of the claims made by 343 intermediate parties. 345 5.6. Transport Aspects 347 Depending on the physical architecture and the functionality of the 348 elements involved, there may be a need for multiple protocols to 349 perform the key transport between entities involved in the handover 350 keying architecture. Thus, a set of requirements for each of these 351 protocols, and the parameters they will carry, must be developed. 353 The use of existing AAA protocols for carrying EAP messages and 354 keying material between the AAA server and AAA clients that have a 355 role within the architecture considered for the keying problem will 356 be carefully examined. Definition of specific parameters, required 357 for keying procedures and to be transferred over any of the links in 358 the architecture, are part of the scope. The relation between the 359 identities used by the transport protocol and the identities used for 360 keying also needs to be explored. 362 6. Use Cases and Related Work 364 In order to further clarify the items listed in scope of the proposed 365 work, this section provides some background on related work and the 366 use cases envisioned for the proposed work. 368 6.1. Method-Specific EAP Re-authentication 370 A number of EAP methods support fast re-authentication. In this 371 section we examine their properties in further detail. 373 EAP-SIM [RFC4186] and EAP-AKA [RFC4187] support fast re- 374 authentication, bootstrapped by the keys generated during an initial 375 full authentication. In response to the typical EAP-Request/ 376 Identity, the peer sends a specially formatted identity indicating a 377 desire to perform a fast re-authentication. A single round-trip 378 occurs to verify knowledge of the existing keys and provide fresh 379 nonces for generating new keys. This is followed by an EAP success. 380 In the end, it requires a single local round trip between the peer 381 and authenticator, followed by another round trip between the peer 382 and EAP server. AKA is based on symmetric-key cryptography, so 383 processing latency is minimal. 385 EAP-TTLS [I-D.funk-eap-ttls-v0] and PEAP 386 [I-D.josefsson-pppext-eap-tls-eap] support using TLS session 387 resumption for fast re-authentication. During the TLS handshake, the 388 client includes the message ID of the previous session he wishes to 389 resume, and the server can echo that ID back if it agrees to resume 390 the session. EAP-FAST [RFC4851] also supports TLS session 391 resumption, but additionally allows stateless session resumption as 392 defined in [RFC4507]. Overall, for all three protocols there are 393 still two round trips between the peer and EAP server, in addition to 394 the local round trip for the Identity request and response. 396 To improve performance, fast re-authentication needs to reduce the 397 number of overall round trips. Optimal performance could result from 398 eliminating the EAP-Request/Identity and EAP-Response/Identity 399 messages observed in typical EAP method execution, and allowing a 400 single round trip between the peer and a local re-authentication 401 server. 403 6.2. IEEE 802.11r Applicability 405 One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D9.0], is in 406 the process of specifying a mechanism to avoid the problem of 407 repeated full EAP exchanges in a limited setting, by introducing a 408 two-level key hierarchy. The EAP authenticator is collocated with 409 what is known as an R0 Key Holder (R0-KH), which receives the MSK 410 from the EAP server. A pairwise master key (PMK-R0) is derived from 411 the last 32 octets of the MSK. Subsequently, the R0-KH derives an 412 PMK-R1 to be handed out to the attachment point of the peer. When 413 the peer moves from one R1-KH to another, a new PMK-R1 is generated 414 by the R0-KH and handed out to the new R1-KH. The transport protocol 415 used between the R0-KH and the R1-KH is not specified. 417 In some cases, a mobile may seldom move beyond the domain of the 418 R0-KH and this model works well. A full EAP authentication will 419 generally be repeated when the PMK-R0 expires. However, in general 420 cases mobiles may roam beyond the domain of R0-KHs (or EAP 421 authenticators), and the latency of full EAP authentication remains 422 an issue. 424 Another consideration is that there needs to be a key transfer 425 protocol between the R0-KH and the R1-KH; in other words, there is 426 either a star configuration of security associations between the key 427 holder and a centralized entity that serves as the R0-KH, or if the 428 first authenticator is the default R0-KH, there will be a full-mesh 429 of security associations between all authenticators. This is 430 undesirable. 432 The proposed work on EAP efficient re-authentication protocol aims at 433 addressing re-authentication in a lower layer agnostic manner that 434 also can fill some of the gaps in IEEE 802.11r. 436 6.3. CAPWAP Applicability 438 The CAPWAP protocol [I-D.ietf-capwap-protocol-specification] allows 439 the functionality of an IEEE 802.11 access point to be split into two 440 physical devices in enterprise deployments. Wireless Termination 441 Points (WTPs) implement the physical and low-level MAC layers, while 442 a centralized Access Controller (AC) provides higher-level management 443 and protocol execution. Client authentication is handled by the AC, 444 which acts as the AAA authenticator. 446 One of the many features provided by CAPWAP is the ability to roam 447 between WTPs without executing an EAP authentication. To accomplish 448 this, the AC caches the MSK from an initial EAP authentication, and 449 uses it to execute a separate four-way handshake with the station as 450 it moves between WTPs. The keys resulting from the four-way 451 handshake are then distributed to the WTP to which the station is 452 associated. CAPWAP is transparent to the station. 454 CAPWAP currently has no means to support roaming between ACs in an 455 enterprise network. The proposed work on EAP efficient re- 456 authentication addresses an inter-authenticator handover problem from 457 an EAP perspective, which applies during handover between ACs. 459 Inter-AC handover is a topic yet to be addressed in great detail and 460 the re-authentication work can potentially address it in an effective 461 manner. 463 7. Security Considerations 465 This document details the HOKEY problem statement. Since HOKEY is an 466 authentication protocol, there are a myriad of security-related 467 issues surrounding its development and deployment. 469 In this document, we have detailed a variety of security properties 470 inferred from [RFC4962] to which HOKEY must conform, including the 471 management of key context, scope, freshness, and transport; 472 resistance to attacks based on the domino effect; and authentication 473 and authorization. See Section 5 for further details. 475 8. IANA Considerations 477 This document does not introduce any new IANA considerations. 479 9. Contributors 481 This document represents the synthesis of two problem statement 482 documents. In this section, we acknowledge their contributions, and 483 involvement in the early documents. 485 Mohan Parthasarathy 486 Nokia 487 Email: mohan.parthasarathy@nokia.com 489 Julien Bournelle 490 France Telecom R&D 491 Email: julien.bournelle@orange-ftgroup.com 493 Hannes Tschofenig 494 Siemens 495 Email: Hannes.Tschofenig@siemens.com 497 Rafael Marin Lopez 498 Universidad de Murcia 499 Email: rafa@dif.um.es 501 10. Acknowledgements 503 The authors would like to thank the participants of the HOKEY working 504 group for their review and comments, including Glen Zorn, Dan 505 Harkins, Joe Salowey, and Yoshi Ohba. The authors would also like to 506 thank those that provided last call reviews, including Bernard Aboba, 507 Alan DeKok, Jari Arkko, and Hannes Tschofenig. 509 11. References 511 11.1. Normative References 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, March 1997. 516 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 517 Levkowetz, "Extensible Authentication Protocol (EAP)", 518 RFC 3748, June 2004. 520 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 521 Authentication Protocol (EAP) Method Requirements for 522 Wireless LANs", RFC 4017, March 2005. 524 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 525 Authorization, and Accounting (AAA) Key Management", 526 BCP 132, RFC 4962, July 2007. 528 11.2. Informative References 530 [I-D.funk-eap-ttls-v0] 531 Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS 532 Authentication Protocol Version 0 (EAP-TTLSv0)", 533 draft-funk-eap-ttls-v0-02 (work in progress), 534 November 2007. 536 [I-D.ietf-capwap-protocol-specification] 537 Calhoun, P., "CAPWAP Protocol Specification", 538 draft-ietf-capwap-protocol-specification-09 (work in 539 progress), February 2008. 541 [I-D.ietf-dime-app-design-guide] 542 Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., 543 and J. Loughney, "Diameter Applications Design 544 Guidelines", draft-ietf-dime-app-design-guide-06 (work in 545 progress), January 2008. 547 [I-D.ietf-eap-keying] 548 Aboba, B., Simon, D., and P. Eronen, "Extensible 549 Authentication Protocol (EAP) Key Management Framework", 550 draft-ietf-eap-keying-22 (work in progress), 551 November 2007. 553 [I-D.ietf-radext-design] 554 Weber, G. and A. DeKok, "RADIUS Design Guidelines", 555 draft-ietf-radext-design-02 (work in progress), 556 December 2007. 558 [I-D.josefsson-pppext-eap-tls-eap] 559 Josefsson, S., Palekar, A., Simon, D., and G. Zorn, 560 "Protected EAP Protocol (PEAP) Version 2", 561 draft-josefsson-pppext-eap-tls-eap-10 (work in progress), 562 October 2004. 564 [RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and 565 Provisioning for Wireless Access Points (CAPWAP) Problem 566 Statement", RFC 3990, February 2005. 568 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 569 Protocol Method for Global System for Mobile 570 Communications (GSM) Subscriber Identity Modules (EAP- 571 SIM)", RFC 4186, January 2006. 573 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 574 Protocol Method for 3rd Generation Authentication and Key 575 Agreement (EAP-AKA)", RFC 4187, January 2006. 577 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 578 "Transport Layer Security (TLS) Session Resumption without 579 Server-Side State", RFC 4507, May 2006. 581 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 582 Flexible Authentication via Secure Tunneling Extensible 583 Authentication Protocol Method (EAP-FAST)", RFC 4851, 584 May 2007. 586 [IEEE.802-11R-D9.0] 587 "Information technology - Telecommunications and 588 information exchange between systems - Local and 589 metropolitan area networks - Specific requirements - Part 590 11: Wireless LAN Medium Access Control (MAC) and Physical 591 Layer (PHY) specifications - Amendment 2: Fast BSS 592 Transition", IEEE Standard 802.11r, January 2008. 594 [LGS07] Ledlie, J., Gardner, P., and M. Selter, "Network 595 Coordinates in the Wild", USENIX Symposium on Networked 596 System Design and Implementation, April 2007. 598 [MSA03] Mishra, A., Shin, M., and W. Arbaugh, "An Empirical 599 Analysis of the IEEE 802.11 MAC-Layer Handoff Process", 600 ACM SIGCOMM Computer and Communications Review, 601 April 2003. 603 [MSPCA04] Mishra, A., Shin, M., Petroni, N., Clancy, T., and W. 604 Arbaugh, "Proactive Key Distribution using Neighbor 605 Graphs", IEEE Wireless Communications, February 2004. 607 Authors' Addresses 609 T. Charles Clancy, Editor 610 Laboratory for Telecommunications Sciences 611 US Department of Defense 612 College Park, MD 613 USA 615 Email: clancy@LTSnet.net 617 Madjid Nakhjiri 618 Motorola 620 Email: madjid.nakhjiri@motorola.com 622 Vidya Narayanan 623 Qualcomm, Inc. 624 San Diego, CA 625 USA 627 Email: vidyan@qualcomm.com 629 Lakshminath Dondeti 630 Qualcomm, Inc. 631 San Diego, CA 632 USA 634 Email: ldondeti@qualcomm.com 636 Full Copyright Statement 638 Copyright (C) The IETF Trust (2008). 640 This document is subject to the rights, licenses and restrictions 641 contained in BCP 78, and except as set forth therein, the authors 642 retain all their rights. 644 This document and the information contained herein are provided on an 645 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 646 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 647 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 648 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 649 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 650 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 652 Intellectual Property 654 The IETF takes no position regarding the validity or scope of any 655 Intellectual Property Rights or other rights that might be claimed to 656 pertain to the implementation or use of the technology described in 657 this document or the extent to which any license under such rights 658 might or might not be available; nor does it represent that it has 659 made any independent effort to identify any such rights. Information 660 on the procedures with respect to rights in RFC documents can be 661 found in BCP 78 and BCP 79. 663 Copies of IPR disclosures made to the IETF Secretariat and any 664 assurances of licenses to be made available, or the result of an 665 attempt made to obtain a general license or permission for the use of 666 such proprietary rights by implementers or users of this 667 specification can be obtained from the IETF on-line IPR repository at 668 http://www.ietf.org/ipr. 670 The IETF invites any interested party to bring to its attention any 671 copyrights, patents or patent applications, or other proprietary 672 rights that may cover technology that may be required to implement 673 this standard. Please address the information to the IETF at 674 ietf-ipr@ietf.org. 676 Acknowledgment 678 Funding for the RFC Editor function is provided by the IETF 679 Administrative Support Activity (IASA).