idnits 2.17.1 draft-ietf-hokey-reauth-ps-08.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 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 651. 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 10, 2008) is 5920 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-08 == 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 13, 2008 Motorola 6 V. Narayanan 7 L. Dondeti 8 Qualcomm 9 February 10, 2008 11 Handover Key Management and Re-authentication Problem Statement 12 draft-ietf-hokey-reauth-ps-08 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 13, 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 . . . . . . . . . . . . . . 6 61 5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7 62 5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 63 5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 64 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7 65 5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8 66 6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8 67 6.1. Method-Specific EAP Re-authentication . . . . . . . . . . 8 68 6.2. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9 69 6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 76 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 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 scenario, 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 The current models of EAP authentication and keying are frequently 114 not efficient in cases where the peer is a mobile device 115 [MSA03][KP01]. In existing implementations, when a peer arrives at 116 the new authenticator, it runs an EAP method irrespective of whether 117 it has been authenticated to the network recently and has unexpired 118 keying material. A full EAP method execution involves an EAP- 119 Response/Identity message from the peer to server, followed by one or 120 more round trips between the EAP server and peer to perform the 121 authentication, followed by the EAP-Success or EAP-Failure message 122 from the EAP server to peer. At a minimum, the peer has 2 round 123 trips with the EAP server. 125 There have been attempts to solve the problem of efficient re- 126 authentication in various ways. However, those solutions are either 127 EAP-method specific or EAP lower-layer specific. Furthermore, these 128 solutions do not deal with scenarios involving handovers to new 129 authenticators, or do not conform to the AAA keying requirements 130 specified in [RFC4962]. 132 This document provides a detailed description of efficient EAP-based 133 re-authentication protocol design goals. The scope of this protocol 134 is specifically re-authentication and handover between authenticators 135 within a single administrative domain. Inter-technology handover and 136 inter-administrative-domain handover are outside the scope of this 137 protocol. 139 2. Terminology 141 In this document, several words are used to signify the requirements 142 of the specification. These words are often capitalized. The key 143 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 144 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 145 are to be interpreted as described in [RFC2119], with the 146 qualification that unless otherwise stated they apply to the design 147 of the re-authentication protocol, not its implementation or 148 application. 150 With respect to EAP, this document follows the terminology that has 151 been defined in [RFC3748] and [I-D.ietf-eap-keying]. 153 3. Problem Statement 155 Under the existing model, any re-authentication requires a full EAP 156 exchange with the EAP server to which the peer initially 157 authenticated [RFC3748]. This introduces handover latency from both 158 network transit time and processing delay. In service provider 159 networks, the home EAP server for a peer could be on the other side 160 of the world, and typical intercontinental latencies across the 161 Internet are 100 to 300 milliseconds per round trip [LGS07]. 162 Processing delays average a couple of milliseconds for symmetric-key 163 operations and hundreds of milliseconds for public-key operations. 165 An EAP conversation with a full EAP method run can take two or more 166 round trips and to complete, causing delays in re-authentication and 167 handover times. Some methods specify the use of keys and state from 168 the initial authentication to finish subsequent authentications in 169 fewer round trips and without using public-key operations (detailed 170 Section 6.1). However, even in those cases, multiple round trips to 171 the EAP server are required, resulting in unacceptable handover 172 times. 174 In summary, it is undesirable to run an EAP Identity and complete EAP 175 method exchange each time a peer authenticates to a new authenticator 176 or needs to extend its current authentication with the same 177 authenticator. Furthermore, it is desirable to specify a method- 178 independent, efficient, re-authentication protocol. Keying material 179 from the initial authentication can be used to enable efficient re- 180 authentication. It is also desirable to have a local server with 181 low-latency connectivity to the peer that can facilitate re- 182 authentication. Lastly, a re-authentication protocol should also be 183 capable of supporting scenarios where an EAP server passes 184 authentication information to a remote re-authentication server, 185 allowing a peer to re-authenticate locally without having to 186 communicate with its home re-authentication server. 188 These problems are the primary issues to be resolved. In solving 189 them, there are a number of constraints to conform to and those 190 result in some additional work to be done in the area of EAP keying. 192 4. Design Goals 194 The following are the goals and constraints in designing the EAP re- 195 authentication and key management protocol: 197 Lower latency operation: The protocol MUST be responsive to handover 198 and re-authentication latency performance objectives within a 199 mobile access network. A solution that reduces latency as 200 compared to a full EAP authentication will be most favorable, 201 since in networks that rely on reactive re-authentication this 202 will directly impact handover times. 204 EAP lower-layer independence: Any keying hierarchy and protocol 205 defined MUST be lower layer independent in order to provide 206 capabilities over heterogeneous technologies. The defined 207 protocols MAY require some additional support from the lower 208 layers that use it, but should not require any particular lower 209 layer. 211 EAP method independence: Changes to existing EAP methods MUST NOT be 212 required as a result of the re-authentication protocol. There 213 MUST be no requirements imposed on future EAP methods, provided 214 they satisfy [I-D.ietf-eap-keying] and [RFC4017]. Note that the 215 only EAP methods for which independence is required are those that 216 currently conform to the specifications of [I-D.ietf-eap-keying] 217 and [RFC4017]. In particular, methods that do not generate the 218 keys required by [I-D.ietf-eap-keying] need not be supported by 219 the re-authentication protocol. 221 AAA protocol compatibility and keying: Any modifications to EAP and 222 EAP keying MUST be compatible with RADIUS [I-D.ietf-radext-design] 223 and Diameter [I-D.ietf-dime-app-design-guide]. Extensions to both 224 RADIUS and Diameter to support these EAP modifications are 225 acceptable. The designs and protocols must be configurable to 226 satisfy the AAA key management requirements specified in RFC 4962 227 [RFC4962]. 229 Compatibility: Compatibility and co-existence with compliant 230 ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be 231 provided. Specifically, the protocol should be designed such that 232 fall back to EAP authentication occurs if not all devices in the 233 network support fast re-authentication. 234 Cryptographic Agility: Any re-authentication protocol MUST support 235 cryptographic algorithm agility, to avoid hard-coded primitives 236 whose security may eventually prove to be compromised. The 237 protocol MAY support cryptographic algorithm negotiation, provided 238 it does not adversely affect overall performance (i.e. by 239 requiring additional round trips). 241 5. Security Goals 243 The section draws from the guidance provided in [RFC4962] to further 244 define the security goals to be achieved by a complete re- 245 authentication keying solution. 247 5.1. Key Context and Domino Effect 249 Any key must have a well-defined scope and must be used in a specific 250 context and for the intended use. This specifically means the 251 lifetime and scope of each key must be defined clearly so that all 252 entities that are authorized to have access to the key have the same 253 context during the validity period. In a hierarchical key structure, 254 the lifetime of lower level keys must not exceed the lifetime of 255 higher level keys. This requirement may imply that the context and 256 the scope parameters have to be exchanged. Furthermore, the 257 semantics of these parameters must be defined to provide proper 258 channel binding specifications. The definition of exact parameter 259 syntax definition is part of the design of the transport protocol 260 used for the parameter exchange and that may be outside scope of this 261 protocol. 263 If a key hierarchy is deployed, compromising lower level keys must 264 not result in a compromise of higher level keys which were used to 265 derive the lower level keys. The compromise of keys at each level 266 must not result in compromise of other keys at the same level. The 267 same principle applies to entities that hold and manage a particular 268 key defined in the key hierarchy. Compromising keys on one 269 authenticator must not reveal the keys of another authenticator. 270 Note that the compromise of higher-level keys has security 271 implications on lower levels. 273 Guidance on parameters required, caching, storage and deletion 274 procedures to ensure adequate security and authorization provisioning 275 for keying procedures must be defined in a solution document. 277 All the keying material must be uniquely named so that it can be 278 managed effectively. 280 5.2. Key Freshness 282 As [RFC4962] defines, a fresh key is one that is generated for the 283 intended use. This would mean the key hierarchy must provide for 284 creation of multiple cryptographically separate child keys from a 285 root key at higher level. Furthermore, the keying solution needs to 286 provide mechanisms for refreshing each of the keys within the key 287 hierarchy. 289 5.3. Authentication 291 Each handover keying participant must be authenticated to any other 292 party with whom it communicates to the extent it is necessary to 293 ensure proper key scoping, and securely provide its identity to any 294 other entity that may require the identity for defining the key 295 scope. 297 5.4. Authorization 299 The EAP Key management document [I-D.ietf-eap-keying] discusses 300 several vulnerabilities that are common to handover mechanisms. One 301 important issue arises from the way the authorization decisions might 302 be handled at the AAA server during network access authentication. 303 For example, if AAA proxies are involved, they may influence 304 authorization decisions. Furthermore, the reasons for making a 305 particular authorization decision are not communicated to the 306 authenticator. In fact, the authenticator only knows the final 307 authorization result. The proposed solution must make efforts to 308 document and mitigate authorization attacks. 310 5.5. Channel Binding 312 Channel Binding procedures are needed to avoid a compromised 313 intermediate authenticator providing unverified and conflicting 314 service information to each of the peer and the EAP server. To 315 support fast re-authentication, there will be intermediate entities 316 between the peer and the back-end EAP server. Various keys need to 317 be established and scoped between these parties and some of these 318 keys may be parents to other keys. Hence the channel binding for 319 this architecture will need to consider layering intermediate 320 entities at each level to make sure that an entity with higher level 321 of trust can examine the truthfulness of the claims made by 322 intermediate parties. 324 5.6. Transport Aspects 326 Depending on the physical architecture and the functionality of the 327 elements involved, there may be a need for multiple protocols to 328 perform the key transport between entities involved in the handover 329 keying architecture. Thus, a set of requirements for each of these 330 protocols, and the parameters they will carry, must be developed. 332 The use of existing AAA protocols for carrying EAP messages and 333 keying material between the AAA server and AAA clients that have a 334 role within the architecture considered for the keying problem will 335 be carefully examined. Definition of specific parameters, required 336 for keying procedures and to be transferred over any of the links in 337 the architecture, are part of the scope. The relation of the 338 identities used by the transport protocol and the identities used for 339 keying also needs to be explored. 341 6. Use Cases and Related Work 343 In order to further clarify the items listed in scope of the proposed 344 work, this section provides some background on related work and the 345 use cases envisioned for the proposed work. 347 6.1. Method-Specific EAP Re-authentication 349 A number of EAP methods support fast re-authentication. In this 350 section we examine their properties in further detail. 352 EAP-SIM [RFC4186] and EAP-AKA [RFC4187] supports fast re- 353 authentication, bootstrapped by the keys generated during an initial 354 full authentication. In response to the typical EAP-Request/ 355 Identity, the peer sends a specially formatted identity indicating a 356 desire to perform a fast re-authentication. A single round-trip 357 occurs to verify knowledge of the existing keys and provide fresh 358 nonces for generating new keys. This is followed by an EAP success. 359 In the end, it requires a single local round trip between the peer 360 and authenticator, followed by another round trip between the peer 361 and EAP server. AKA is based on symmetric-key cryptography, so 362 processing latency is minimal. 364 EAP-TTLS [I-D.funk-eap-ttls-v0] and PEAP 365 [I-D.josefsson-pppext-eap-tls-eap] support using TLS session 366 resumption for fast re-authentication. During the TLS handshake, the 367 client includes the message ID of the previous session he wishes to 368 resume, and the server can echo that ID back if it agrees to resume 369 the session. EAP-FAST [RFC4851] also supports TLS session 370 resumption, but additionally allows stateless session resumption as 371 defined in [RFC4507]. Overall, for all three protocols there are 372 still two round trips between the peer and EAP server, in addition to 373 the local round trip for the Identity request and response. 375 To improve performance, fast re-authentication needs to reduce the 376 number of overall round trips. Optimal performance could result from 377 eliminating the EAP-Request/Identity and EAP-Response/Identity 378 messages observed in typical EAP method execution, and allowing a 379 single round trip between the peer and a local re-authentication 380 server. 382 6.2. IEEE 802.11r Applicability 384 One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D9.0], is in 385 the process of specifying a mechanism to avoid the problem of 386 repeated full EAP exchanges in a limited setting, by introducing a 387 two-level key hierarchy. The EAP authenticator is collocated with 388 what is known as an R0 Key Holder (R0-KH), which receives the MSK 389 from the EAP server. A pairwise master key (PMK-R0) is derived from 390 the last 32 octets of the MSK. Subsequently, the R0-KH derives an 391 PMK-R1 to be handed out to the attachment point of the peer. When 392 the peer moves from one R1-KH to another, a new PMK-R1 is generated 393 by the R0-KH and handed out to the new R1-KH. The transport protocol 394 used between the R0-KH and the R1-KH is not specified. 396 In some cases, a mobile may seldom move beyond the domain of the 397 R0-KH and this model works well. A full EAP authentication will 398 generally be repeated when the PMK-R0 expires. However, in general 399 cases mobiles may roam beyond the domain of R0-KHs (or EAP 400 authenticators), and the latency of full EAP authentication remains 401 an issue. 403 Another consideration is that there needs to be a key transfer 404 protocol between the R0-KH and the R1-KH; in other words, there is 405 either a star configuration of security associations between the key 406 holder and a centralized entity that serves as the R0-KH, or if the 407 first authenticator is the default R0-KH, there will be a full-mesh 408 of security associations between all authenticators. This is 409 undesirable. 411 The proposed work on EAP efficient re-authentication protocol aims at 412 addressing re-authentication in a lower layer agnostic manner that 413 also can fill some of the gaps in IEEE 802.11r. 415 6.3. CAPWAP Applicability 417 The CAPWAP protocol [I-D.ietf-capwap-protocol-specification] allows 418 the functionality of an IEEE 802.11 access point to be split into two 419 physical devices in enterprise deployments. Wireless Termination 420 Points (WTPs) implement the physical and low-level MAC layers, while 421 a centralized Access Controller (AC) provides higher-level management 422 and protocol execution. Client authentication is handled by the AC, 423 which acts as the AAA authenticator. 425 One of the many features provided by CAPWAP is the ability to roam 426 between WTPs without executing an EAP authentication. To accomplish 427 this, the AC caches the MSK from an initial EAP authentication, and 428 uses it to execute a separate four-way handshake with the station as 429 it moves between WTPs. The keys resulting from the four-way 430 handshake are then distributed to the WTP to which the station is 431 associated. CAPWAP is transparent to the station. 433 CAPWAP currently has no means to support roaming between ACs in an 434 enterprise network. The proposed work on EAP efficient re- 435 authentication addresses an inter-authenticator handover problem from 436 an EAP perspective, which applies during handover between ACs. 437 Inter-AC handover is a topic yet to be addressed in great detail and 438 the re-authentication work can potentially address it in an effective 439 manner. 441 7. Security Considerations 443 This document details the HOKEY problem statement. Since HOKEY is an 444 authentication protocol, there are a myriad of security-related 445 issues surrounding its development and deployment. 447 In this document, we have detailed a variety of security properties 448 inferred from [RFC4962] to which HOKEY must conform, including the 449 management of key context, scope, freshness, and transport; 450 resistance to attacks based on the domino effect; and authentication 451 and authorization. See section Section 5 for further details. 453 8. IANA Considerations 455 This document does not introduce any new IANA considerations. 457 9. Contributors 459 This document represents the synthesis of two problem statement 460 documents. In this section, we acknowledge their contributions, and 461 involvement in the early documents. 463 Mohan Parthasarathy 464 Nokia 465 Email: mohan.parthasarathy@nokia.com 467 Julien Bournelle 468 France Telecom R&D 469 Email: julien.bournelle@orange-ftgroup.com 471 Hannes Tschofenig 472 Siemens 473 Email: Hannes.Tschofenig@siemens.com 475 Rafael Marin Lopez 476 Universidad de Murcia 477 Email: rafa@dif.um.es 479 10. Acknowledgements 481 The authors would like to thank the participants of the HOKEY working 482 group for their review and comments, including Glen Zorn, Dan 483 Harkins, Joe Salowey, and Yoshi Ohba. The authors would also like to 484 thank those that provided last call reviews, including Bernard Aboba, 485 Alan DeKok, and Hannes Tschofenig. 487 11. References 489 11.1. Normative References 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 495 Levkowetz, "Extensible Authentication Protocol (EAP)", 496 RFC 3748, June 2004. 498 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 499 Authentication Protocol (EAP) Method Requirements for 500 Wireless LANs", RFC 4017, March 2005. 502 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 503 Authorization, and Accounting (AAA) Key Management", 504 BCP 132, RFC 4962, July 2007. 506 11.2. Informative References 508 [I-D.funk-eap-ttls-v0] 509 Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS 510 Authentication Protocol Version 0 (EAP-TTLSv0)", 511 draft-funk-eap-ttls-v0-02 (work in progress), 512 November 2007. 514 [I-D.ietf-capwap-protocol-specification] 515 Calhoun, P., "CAPWAP Protocol Specification", 516 draft-ietf-capwap-protocol-specification-08 (work in 517 progress), November 2007. 519 [I-D.ietf-dime-app-design-guide] 520 Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., 521 and J. Loughney, "Diameter Applications Design 522 Guidelines", draft-ietf-dime-app-design-guide-06 (work in 523 progress), January 2008. 525 [I-D.ietf-eap-keying] 526 Aboba, B., Simon, D., and P. Eronen, "Extensible 527 Authentication Protocol (EAP) Key Management Framework", 528 draft-ietf-eap-keying-22 (work in progress), 529 November 2007. 531 [I-D.ietf-radext-design] 532 Weber, G. and A. DeKok, "RADIUS Design Guidelines", 533 draft-ietf-radext-design-02 (work in progress), 534 December 2007. 536 [I-D.josefsson-pppext-eap-tls-eap] 537 Josefsson, S., Palekar, A., Simon, D., and G. Zorn, 538 "Protected EAP Protocol (PEAP) Version 2", 539 draft-josefsson-pppext-eap-tls-eap-10 (work in progress), 540 October 2004. 542 [RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and 543 Provisioning for Wireless Access Points (CAPWAP) Problem 544 Statement", RFC 3990, February 2005. 546 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 547 Protocol Method for Global System for Mobile 548 Communications (GSM) Subscriber Identity Modules (EAP- 549 SIM)", RFC 4186, January 2006. 551 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 552 Protocol Method for 3rd Generation Authentication and Key 553 Agreement (EAP-AKA)", RFC 4187, January 2006. 555 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 556 "Transport Layer Security (TLS) Session Resumption without 557 Server-Side State", RFC 4507, May 2006. 559 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 560 Flexible Authentication via Secure Tunneling Extensible 561 Authentication Protocol Method (EAP-FAST)", RFC 4851, 562 May 2007. 564 [IEEE.802-11R-D9.0] 565 "Information technology - Telecommunications and 566 information exchange between systems - Local and 567 metropolitan area networks - Specific requirements - Part 568 11: Wireless LAN Medium Access Control (MAC) and Physical 569 Layer (PHY) specifications - Amendment 2: Fast BSS 570 Transition", IEEE Standard 802.11r, January 2008. 572 [KP01] Koodli, R. and C. Perkins, "Fast Handover and Context 573 Relocation in Mobile Networks", ACM SIGCOMM Computer and 574 Communications Review, October 2001. 576 [LGS07] Ledlie, J., Gardner, P., and M. Selter, "Network 577 Coordinates in the Wild", USENIX Symposium on Networked 578 System Design and Implementation, April 2007. 580 [MSA03] Mishra, A., Shin, M., and W. Arbaugh, "An Empirical 581 Analysis of the IEEE 802.11 MAC-Layer Handoff Process", 582 ACM SIGCOMM Computer and Communications Review, 583 April 2003. 585 Authors' Addresses 587 T. Charles Clancy, Editor 588 Laboratory for Telecommunications Sciences 589 US Department of Defense 590 College Park, MD 591 USA 593 Email: clancy@LTSnet.net 594 Madjid Nakhjiri 595 Motorola 597 Email: madjid.nakhjiri@motorola.com 599 Vidya Narayanan 600 Qualcomm, Inc. 601 San Diego, CA 602 USA 604 Email: vidyan@qualcomm.com 606 Lakshminath Dondeti 607 Qualcomm, Inc. 608 San Diego, CA 609 USA 611 Email: ldondeti@qualcomm.com 613 Full Copyright Statement 615 Copyright (C) The IETF Trust (2008). 617 This document is subject to the rights, licenses and restrictions 618 contained in BCP 78, and except as set forth therein, the authors 619 retain all their rights. 621 This document and the information contained herein are provided on an 622 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 623 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 624 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 625 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 626 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 627 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 629 Intellectual Property 631 The IETF takes no position regarding the validity or scope of any 632 Intellectual Property Rights or other rights that might be claimed to 633 pertain to the implementation or use of the technology described in 634 this document or the extent to which any license under such rights 635 might or might not be available; nor does it represent that it has 636 made any independent effort to identify any such rights. Information 637 on the procedures with respect to rights in RFC documents can be 638 found in BCP 78 and BCP 79. 640 Copies of IPR disclosures made to the IETF Secretariat and any 641 assurances of licenses to be made available, or the result of an 642 attempt made to obtain a general license or permission for the use of 643 such proprietary rights by implementers or users of this 644 specification can be obtained from the IETF on-line IPR repository at 645 http://www.ietf.org/ipr. 647 The IETF invites any interested party to bring to its attention any 648 copyrights, patents or patent applications, or other proprietary 649 rights that may cover technology that may be required to implement 650 this standard. Please address the information to the IETF at 651 ietf-ipr@ietf.org. 653 Acknowledgment 655 Funding for the RFC Editor function is provided by the IETF 656 Administrative Support Activity (IASA).