idnits 2.17.00 (12 Aug 2021) /tmp/idnits41108/draft-ietf-hokey-preauth-ps-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 21, 2010) is 4496 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 5296 (Obsoleted by RFC 6696) == Outdated reference: A later version (-15) exists of draft-aboba-radext-wlan-12 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Ohba, Ed. 3 Internet-Draft Toshiba 4 Intended status: Informational Q. Wu, Ed. 5 Expires: July 25, 2010 Huawei 6 G. Zorn, Ed. 7 Network Zen 8 January 21, 2010 10 Extensible Authentication Protocol (EAP) Early Authentication Problem 11 Statement 12 draft-ietf-hokey-preauth-ps-12 14 Abstract 16 Extensible Authentication Protocol (EAP) early authentication may be 17 defined as the use of EAP by a mobile device to establish 18 authenticated keying material on a target attachment point prior to 19 its arrival. This draft discusses the EAP early authentication 20 problem in detail. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on July 25, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 77 3.1. Handover Preparation . . . . . . . . . . . . . . . . . . . 6 78 3.2. Handover Execution . . . . . . . . . . . . . . . . . . . . 6 79 3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 6 80 3.3. Solution Space . . . . . . . . . . . . . . . . . . . . . . 7 81 3.3.1. Context Transfer . . . . . . . . . . . . . . . . . . . 7 82 3.3.2. Early Authentication . . . . . . . . . . . . . . . . . 7 83 4. System Overview . . . . . . . . . . . . . . . . . . . . . . . 8 84 5. Topological Classification of Handover Scenarios . . . . . . . 9 85 6. Models of Early Authentication . . . . . . . . . . . . . . . . 9 86 6.1. EAP Pre-authentication Usage Models . . . . . . . . . . . 10 87 6.1.1. The Direct Pre-authentication Model . . . . . . . . . 10 88 6.1.2. The Indirect Pre-authentication Usage Model . . . . . 11 89 6.2. The Authenticated Anticipatory Keying Usage Model . . . . 12 90 7. Architectural Considerations . . . . . . . . . . . . . . . . . 13 91 7.1. Authenticator Discovery . . . . . . . . . . . . . . . . . 13 92 7.2. Context Binding . . . . . . . . . . . . . . . . . . . . . 13 93 8. AAA Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 96 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 97 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 99 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 100 13.2. Informative References . . . . . . . . . . . . . . . . . . 17 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 103 1. Introduction 105 When a mobile device, during an active communication session, moves 106 from one access network to another and changes its attachment point, 107 the session may be subjected to disruption of service due to the 108 delay associated with the handover operation. The performance 109 requirements of a real-time application will vary based on the type 110 of application and its characteristics such as delay and packet loss 111 tolerance. For Voice over IP applications, ITU-T G.114 [ITU] 112 recommends a steady-state end-to-end delay of 150 ms as the upper 113 limit and rates 400 ms as generally unacceptable delay. Similarly, a 114 streaming application has tolerable packet error rates ranging from 115 0.1 to 0.00001 with a transfer delay of less than 300 ms. Any help 116 that an optimized handoff mechanism can provide toward meeting these 117 objectives is useful. The ultimate objective is to achieve seamless 118 handover with low latency, even when handover is between different 119 link technologies or between different AAA realms. 121 As a mobile device goes through a handover process, it is subjected 122 to delay because of the rebinding of its association at or across 123 several layers of the protocol stack and because of the additional 124 round trips needed for a new EAP exchange. Delays incurred within 125 each protocol layer affect the ongoing multimedia application and 126 data traffic within the client [WCM]. 128 The handover process often requires authentication and authorization 129 for acquisition or modification of resources assigned to the mobile 130 device. In most cases, these authentication and authorization 131 require interaction with a central authority in a realm. In some 132 cases the central authority may be distant from the mobile device. 133 The delay introduced due to such an authentication and authorization 134 procedure adds to the handover latency and consequently affects 135 ongoing application sessions [MQ7] The discussion in this document is 136 focused on mitigating delay due to EAP authentication. 138 2. Terminology 140 AAA 142 Authentication, Authorization, and Accounting (see below). RADIUS 143 [RFC2865] and Diameter [RFC3588] are examples of AAA protocols 144 defined in the IETF. 146 AAA realm 147 The set of access networks within the scope of a specific AAA 148 server. Thus, if a mobile device moves from one attachment point 149 to another within the same AAA realm, it continues to be served by 150 the same AAA server 152 Accounting 153 The act of collecting information on resource usage for the 154 purpose of trend analysis, auditing, billing, or cost allocation 155 [RFC2989]. 157 Attachment Point 158 A device, such as a wireless access point, that serves as a 159 gateway between access clients and a network. In the context of 160 this document, an attachment point must also support EAP 161 authenticator functionality and may act as a AAA client. 163 Authentication 164 The act of verifying a claimed identity, in the form of a pre- 165 existing label from a mutually known name space, as the originator 166 of a message (message authentication) or as the end-point of a 167 channel (entity authentication) [RFC2989]. 169 Authenticator 170 The end of the link initiating EAP authentication [RFC3748]. 172 Authorization 173 The act of determining if a particular right, such as access to 174 some resource, can be granted to the presenter of a particular 175 credential [RFC2989]. 177 Candidate Access Network 178 An access network that can potentially become the target access 179 network for a mobile device. Multiple access networks may be 180 candidates simultaneously. 182 Candidate Attachment Point 183 An attachment point that can potentially become the target 184 attachment point for a mobile device. Multiple attachment points 185 may be candidates simultaneously. 187 Candidate Authenticator 188 The EAP authenticator on the CAP. 190 EAP Server 191 The entity that terminates the EAP authentication method with the 192 peer [RFC3748]. EAP servers are often, but not necessarily, co- 193 located with AAA servers, using a AAA protocol to communicate with 194 remote pass-through authenticators. 196 Inter-AAA-realm Handover (Inter-realm Handover) 197 A handover across multiple AAA realms. 199 Inter-Technology Handover 200 A handover across different link layer technologies. 202 Intra-AAA-realm Handover (Intra-realm Handover) 203 A handover within the same AAA realm. Intra-AAA-realm handover 204 includes a handover across different authenticators within the 205 same AAA realm. 207 Intra-Technology Handover 208 A handover within the same link layer technology. 210 Master Session Key (MSK) 211 Keying material that is derived between the EAP peer and server 212 and exported by the EAP method [RFC3748]. 214 Peer 215 The entity that responds to the authenticator and requires 216 authentication[RFC3748]. 218 Serving Access Network 219 An access network that is currently serving the mobile device. 221 Serving Attachment Point (SAP) 222 An attachment point that is currently serving the mobile device. 224 Target Access Network 225 An access network that has been selected to be the new serving 226 access network for a mobile device. 228 Target Attachment Point (TAP) 229 An attachment point that has been selected to be the new SAP for a 230 mobile device. 232 3. Problem Statement 234 The basic mechanism of handover is a two-step procedure involving 236 o handover preparation and 238 o handover execution 240 3.1. Handover Preparation 242 Handover preparation includes the discovery of candidate attachment 243 points and selection of an appropriate target attachment point from 244 the candidate set. Handover preparation is outside the scope of this 245 document. 247 3.2. Handover Execution 249 Handover execution consists of setting up Layer 2 (L2) and Layer 3 250 (L3) connectivity with the TAP. Currently, handover execution 251 includes network access authentication and authorization performed 252 directly with the target network; this may include full EAP 253 authentication in the absence of any particular optimization for 254 handover key management. Following a successful EAP authentication, 255 a secure association procedure is typically performed between the 256 mobile device and the TAP to derive a new set of link-layer 257 encryption keys from EAP keying material such as the MSK. The 258 handover latency introduced by full EAP authentication has proven to 259 be higher than that which is acceptable for real-time application 260 scenarios [MQ7]; hence, reduction in handover latency due to EAP is a 261 necessary objective for such scenarios. 263 3.2.1. Examples 265 3.2.1.1. IEEE 802.11 267 In IEEE 802.11 WLANs [IEEE.802-11.2007] network access authentication 268 and authorization involves performing a new IEEE 802.1X 269 [IEEE.802-1X.2004] message exchange with the authenticator in the TAP 270 to execute an EAP exchange with the authentication server [WPA].There 271 has been some optimization work undertaken by the IEEE, but these 272 efforts have been scoped to IEEE link layer technologies; for 273 example, the work done in the IEEE 802.11f [IEEE.802-11F.2003] and 274 802.11r [IEEE.802-11R.2008] Task Groups applies only to intra- 275 technology handovers. 277 3.2.1.2. 3GPP TS33.402 279 3GPP Technical Specification 33.402 [TS33.402], defines the 280 authentication and key management procedures performed during 281 interworking between non-3GPP access networks and the Evolved Packet 282 System (EPS). Network access authentication and authorization 283 happens after the L2 connection is established between the mobile 284 device and a non-3GPP target access network, and involves an EAP 285 exchange between the mobile device and the 3GPP AAA server via the 286 non-3GPP target access network. These procedures are not really 287 independent of link technology, since they assume either that the 288 authenticator lies in the EPS network or that separate 289 authentications are performed in the access network and then in the 290 EPS network. 292 3.3. Solution Space 294 As the examples in the preceding sections illustrate, a solution is 295 needed to enable EAP early authentication for inter-AAA-realm 296 handovers and inter-technology handovers. A search for solutions at 297 the IP level may offer the necessary technology independence. 299 Optimized solutions for secure inter-authenticator handovers can be 300 seen either as security context transfer (e.g., using the EAP 301 Extensions for EAP Re-authentication Protocol (ERP)) [RFC5296], or as 302 EAP early authentication. 304 3.3.1. Context Transfer 306 Security context transfer involves transfer of reusable key context 307 to the TAP and can take two forms: horizontal and vertical. 309 Horizontal security context transfer (e.g., from SAP to TAP) is not 310 recommended because of the possibility that the compromise of one 311 attachment point might lead to the compromise of another (the so- 312 called Domino effect, [RFC4962]). Vertical context transfer is 313 similar to the initial establishment of keying material on an 314 attachment point in that the keys are sent from a trusted server to 315 the TAP as a direct result of a successful authentication. ERP 316 specifies vertical context transfer using existing EAP keying 317 material obtained from the home AAA server during the initial 318 authentication. A cryptographically independent re-authentication 319 key is derived and transmitted to the TAP as a result of successful 320 ERP authentication. This reduces handover delay for intra-realm 321 handovers by eliminating the need to run full EAP authentication with 322 the home EAP server. 324 However, in the case of inter-realm handover, ERP is either not 325 applicable or an additional optimization mechanism is needed to 326 establish a key on the TAP. 328 3.3.2. Early Authentication 330 In EAP early authentication, AAA-based authentication and 331 authorization for a CAP is performed while ongoing data communication 332 is in progress via the serving access network, the goal being to 333 complete AAA signaling for EAP before the mobile device moves. The 334 applicability of EAP early authentication is limited to the scenarios 335 where candidate authenticators can be discovered and an accurate 336 prediction of movement can be easily made. In addition, the 337 effectiveness of EAP early authentication may be less significant for 338 particular inter-technology handover scenarios where simultaneous use 339 of multiple technologies is not a major concern. 341 There are also several AAA issues related to EAP early 342 authentication, discussed in Section 8. 344 4. System Overview 346 Figure 1 shows the functional elements that are related to EAP early 347 authentication. These functional elements include a mobile device, a 348 SAP, a CAP and one or more AAA and EAP servers; for the sake of 349 convenience, the AAA and EAP servers are represented as being co- 350 located. When the SAP and CAP belong to different AAA realms, the 351 CAP may require a different set of user credentials than those used 352 by the peer when authenticating to the SAP. Alternatively, the CAP 353 and the SAP may rely on the same AAA server, located in the home 354 realm of the mobile device (MD). 356 +------+ +-------+ +---------+ +---------+ 357 | MD |------| SAP |------| | | | 358 +------+ +-------+ | IP | | EAP/AAA 359 . | |------| | 360 . Move | Network | | Server | 361 v +-------+ | | | | 362 | CAP |------| | | | 363 +-------+ +---------+ +---------+ 365 Figure 1: EAP Early Authentication Functional Elements 367 A mobile device is attached to the serving access network. Before 368 the MD performs handover from the serving access network to a 369 candidate access network, it performs EAP early authentication with a 370 candidate authenticator via the serving access network. The peer may 371 perform EAP early authentication with one or more candidate 372 authenticators. It is assumed that each attachment point has an IP 373 address. It is assumed that there is at least one CAP in each 374 candidate access network. The serving and candidate access networks 375 may use different link layer technologies. 377 Each authenticator is either a standalone authenticator or pass- 378 through authenticator [RFC3748]. When an authenticator acts as a 379 standalone authenticator, it also has the functionality of an EAP 380 server. When an authenticator acts as a pass-through authenticator, 381 it communicates with the EAP server, typically using a AAA transport 382 protocol such as RADIUS [RFC2865] or Diameter [RFC3588]. 384 If the CAP uses an MSK [RFC5247] for generating lower-layer ciphering 385 keys, EAP early authentication is used to proactively generate an MSK 386 for the CAP. 388 5. Topological Classification of Handover Scenarios 390 The complexity of the authentication and authorization part of 391 handover depends on whether it involves a change in EAP Server. 392 Consider first the case where the authenticators operate in pass- 393 through mode, so that the EAP Server is co-located with a AAA server. 394 Then there is a strict hierarchy of complexity, as follows: 396 1. inter-attachment-point handover with common AAA server: the CAP 397 and SAP are different entities, but the AAA server is the same. 398 There are two sub-cases here: 400 (a) the AAA server is common because both attachment points lie 401 within the same network, or 403 (b) the AAA server is common because AAA entities in the serving 404 and candidate networks proxy to a AAA server in the home 405 realm. 407 2. inter-AAA-realm handover: the CAP and SAP are different entities, 408 and the respective AAA servers also differ. As a result, 409 authentication in the candidate network requires a second set of 410 user credentials. 412 A third case is where one or both authenticators are co-located with 413 an EAP server. This has some of the characteristics of an inter-AAA- 414 realm handover, but offers less flexibility for resolution of the 415 early authentication problem. 417 Orthogonally to this classification, one can distinguish intra- 418 technology handover from inter-technology handover, thinking of the 419 link technologies involved. In the inter-technology case, it is 420 highly probable that the authenticators will differ. The most likely 421 cases are 1(b) or 2 in the above list. 423 6. Models of Early Authentication 425 As noted in Section 3, there are cases where early authentication is 426 applicable while ERP does not work. This section concentrates on 427 providing some models around which we can build our analysis of the 428 EAP early authentication problem. Different usage models can be 429 defined depending on whether 431 o the SAP is not involved in early authentication (direct pre- 432 authentication usage model), 434 o the SAP interacts only with the CAP (indirect pre-authentication 435 usage model), or 437 o the SAP interacts with the AAA server (the authenticated 438 anticipatory keying usage model). 440 It is assumed that the CAP and SAP are different entities. It is 441 further assumed in describing these models that there is no direct L2 442 connectivity between the peer and the candidate attachment point. 444 6.1. EAP Pre-authentication Usage Models 446 In the EAP pre-authentication model, the SAP does not interact with 447 the AAA server directly. Depending on how the SAP is involved in the 448 pre-authentication signaling, the EAP pre-authentication usage model 449 can be further categorized into the following two sub-models, direct 450 and indirect. 452 6.1.1. The Direct Pre-authentication Model 454 In this model, the SAP is not involved in the EAP exchange and only 455 forwards the EAP pre-authentication traffic as it would any other 456 data traffic. The direct pre-authentication model is based on the 457 assumption that the MD can discover candidate authenticators and 458 establish direct IP communication with them. It is applicable to any 459 of the cases described in Section 5. 461 Mobile Candidate Attachment AAA Server 462 Device Point(CAP) 463 +-----------+ +-------------------------+ +------------+ 464 | | | Candidate | | | 465 | Peer | | Authenticator | | EAP Server | 466 | | | | | | 467 +-----------+ +-------------------------+ +------------+ 468 | MD-CAP |<-->| MD-CAP | | CAP-AAA |<-->| CAP-AAA | 469 | Signaling | | Signaling | | Signaling | | Signaling | 470 +-----------+ +-----------+ +-----------+ +------------+ 472 Figure 2: Direct Pre-authentication Usage Model 474 The direct pre-authentication signaling for the usage model is shown 475 in Figure 3. 477 Mobile Serving Candidate AAA/EAP 478 Device Attachment Point Authenticator Server 479 (SAP) 480 | | | | 481 | | | | 482 | EAP over MD-CAP Signaling (L3) | EAP over AAA | 483 |<------------------+------------------->|<----------------->| 484 | | | | 485 | | | | 487 Figure 3: Direct Pre-authentication Signaling for the Usage Model 489 6.1.2. The Indirect Pre-authentication Usage Model 491 The indirect pre-authentication usage model is illustrated in 492 Figure 4. 494 Mobile Serving Candidate AAA 495 Device Attachment Point Attachment Point Server 496 (SAP) (CAP) 497 +----------+ +----------------+ +--------+ 498 | | | | | | 499 | EAP Peer | | Candidate | | EAP | 500 | | | Authenticator | | Server | 501 | | | | | | 502 +----------+ +---------+------+ +-------+--------+ +--------+ 503 | Peer-SA |<->| Peer-SA |SA-CA |<->| SA-CA | CA-AAA |<->| CA-AAA | 504 +----------+ +---------+------+ +-------+--------+ +--------+ 506 {-----------------------------Signaling---------------------------} 508 Figure 4: Indirect Pre-authentication Usage Model 510 In the indirect pre-authentication model, it is assumed that a trust 511 relationship exists between the serving network (or serving AAA 512 realm) and candidate network (or candidate AAA realm). The SAP is 513 involved in EAP pre-authentication signaling. This pre- 514 authentication model is needed if the peer cannot discover the 515 candidate authenticators identity or if direct IP communication 516 between the MD and CAP is not possible due to security or network 517 topology issues. 519 The role of the SAP in this pre-authentication model is to forward 520 EAP pre-authentication signaling between the mobile device and CAP; 521 the role of the CAP is to forward EAP pre-authentication signaling 522 between the peer (via the SAP) and EAP server and receive the 523 transported keying material. 525 The pre-authentication signaling for this model is shown in Figure 5. 527 Mobile Serving Candidate AAA/EAP 528 Device Attachment Point Attachment Point Server 529 (SAP) (CAP) 530 | | | | 531 | EAP over | EAP over | EAP over AAA | 532 | MD-SAP Signaling | SAP-CAP Signaling | | 533 | (L2 or L3) | (L3) | | 534 |<----------------->|<------------------<|<----------------->| 535 | | | | 536 | | | | 538 Figure 5: Indirect Pre-authentication Signaling for the Usage Model 540 In this model, the pre-authentication signaling path between a peer 541 and a candidate authenticator consists of two segments: peer to SAP 542 signaling (over L2 or L3) and SAP to CAP signaling over L3. 544 6.2. The Authenticated Anticipatory Keying Usage Model 546 In this model, it is assumed that there is no trust relationship 547 between the SAP and the CAP and the SAP is required to interact with 548 the AAA server directly. The authenticated anticipatory keying usage 549 model is illustrated in Figure 6. 551 Mobile Serving AAA Server Candidate 552 Device Attachment Point Attachment 553 (SAP) Point (CAP) 554 +---------+ +------------------+ +-----------------+ +--------+ 555 | | | | | | | | 556 | Peer | | Authenticator | | EAP Server | | AAA | 557 | | | | | | | Client | 558 +---------+ +------------------+ +-----------------+ +--------+ 559 | Peer-SA |<->| Peer-SA | SA-AAA |<->| SA-AAA | CA-AAA |<>| CA-AAA | 560 +---------+ +------------------+ +--------+--------+ +--------+ 561 {------------------------------Signaling---------------------------} 563 Figure 6: Authenticated Anticipatory Keying Usage Model 565 The SAP is involved in EAP authenticated anticipatory keying 566 signaling. 568 The role of the serving attachment point in this usage model is to 569 communicate with the peer on one side and exchange authenticated 570 anticipatory keying signaling with the EAP server on the other side. 571 The role of the candidate authenticator is to receive the transported 572 keying materials from the EAP server and to act as the serving 573 attachment point after handover occurs. The Peer-SA signaling is 574 performed over L2 or L3; the SA-AAA and AAA-CA segments operate over 575 L3. 577 7. Architectural Considerations 579 There are two architectural issues relating to early authentication: 580 authenticator discovery and context binding. 582 7.1. Authenticator Discovery 584 In general, early authentication requires the identity of a candidate 585 attachment point to be discovered by a peer, by a serving attachment 586 point, or by some other entity prior to handover. An attachment 587 point discovery protocol is typically defined as a separate protocol 588 from an early authentication protocol. For example, the IEEE 802.21 589 Information Service (IS) [IEEE.802-21] provides a link-layer- 590 independent mechanism for obtaining neighboring network information 591 by defining a set of Information Elements (IEs), where one of the IEs 592 is defined to contain an IP address of a attachment point. IEEE 593 802.21 IS queries for such an IE may be used as a method for 594 authenticator discovery. 596 If IEEE 802.21 IS or a similar mechanism is used, authenticator 597 discovery requires a database of information regarding the target 598 network; the provisioning of a server with such a database is another 599 issue. 601 7.2. Context Binding 603 When a candidate authenticator uses different EAP transport protocols 604 for normal authentication and early authentication, a mechanism is 605 needed to bind link-layer-independent context carried over early 606 authentication signaling to the link-layer-specific context of the 607 link to be established between the peer and the candidate 608 authenticator. The link-layer-independent context includes the 609 identities of the peer and authenticator as well as the MSK. The 610 link-layer-specific context includes link layer addresses of the peer 611 and the candidate authenticator. Such context binding can happen 612 before or after the peer changes its point of attachment. 614 There are at least two possible approaches to address the context 615 binding issue. The first approach is based on communicating the link 616 layer context as opaque data via early authentication signaling. The 617 second approach is based on running EAP over the link layer of the 618 candidate authenticator after the peer arrives at the authenticator, 619 using short-term credentials generated via early authentication. In 620 this case, the short-term credentials are shared between the peer and 621 the candidate authenticator. In both approaches, context binding 622 needs to be securely made between the peer and the candidate 623 authenticator. Also, the peer is not fully authorized by the 624 candidate authenticator until the peer completes the link-layer- 625 specific secure association procedure with the authenticator using 626 link layer signaling. 628 8. AAA Issues 630 Most of the AAA documents today do not distinguish between a normal 631 authentication and an early authentication and this creates a set of 632 open issues: 634 Early authentication authorization 635 Users may not be allowed to have more than one logon session at 636 the time. This means that while such users actively engage in a 637 session (as a result of a previously valid authentication), they 638 will not be able to perform early authentication. The AAA server 639 currently has no way of distinguishing between a normal 640 authentication request and an early authentication request. 642 Early authentication lifetime 643 Currently, AAA protocols define attributes carrying lifetime 644 information for a normal authentication session. Even when a user 645 profile and the AAA server support early authentication, the 646 lifetime for an early authentication session is typically valid 647 only for a short amount of time because the peer has not completed 648 its authentication at the target link layer. It is currently not 649 possible for a AAA server to indicate to the AAA client or a peer 650 the lifetime of the early authenticated session unless AAA 651 protocols are extended to carry early authentication session 652 lifetime information. In other words, it is not clear to the peer 653 or the authenticator when the early authentication session will 654 expire. 656 Early authentication retries 657 It is typically expected that shortly following the early 658 authentication process, the peer moves to the new point of 659 attachment and converts the early authentication state to a normal 660 authentication state (the procedure for which is not the topic of 661 this particular subsection). However, if the peer has not yet 662 moved to the new location and realizes that the early 663 authentication session is expiring, it may perform another early 664 authentication. Some limiting mechanism is needed to avoid an 665 unlimited number of early-authentication attempts. 667 Completion of network attachment 668 Once the peer has successfully attached to the new point of 669 attachment, it needs to convert its authentication state from 670 early authenticated to fully attached and authorized. If the AAA 671 server needs to differentiate between early authentication and 672 normal authentication, there may need to be a mechanism within the 673 AAA protocol to provide this indication to the AAA server. This 674 may be important from a billing perspective if the billing policy 675 does not charge for an early authenticated peer until the peer is 676 fully attached to the target authenticator. 678 Session resumption 679 In the case where the peer cycles between a network N1 with which 680 it has fully authenticated to another network N2 and then back to 681 N1, it should be possible to simply convert the fully 682 authenticated state on N1 to an early authenticated state. The 683 problems around handling session lifetime and keying material 684 caching need to be dealt with. 686 Multiple candidate attachment points 687 There may be situations where the peer needs to choose from among 688 a number of CAPs. In such cases, it is desirable for the peer to 689 perform early authentication with multiple candidate 690 authenticators. This amplifies the difficulties noted under the 691 point "Early authentication authorization". 693 Inter-AAA-realm handover support 694 There may be situations where the peer moves out of the home AAA 695 realm or across different visited AAA realms. In such cases, the 696 early authentication should be performed through the visited AAA 697 realm with the AAA server in the home AAA realm. It also requires 698 AAA in the visited realm to acquire the identity information of 699 the home AAA realms for routing the EAP early authentication 700 traffic. Knowledge of realm identities is required by both the 701 peer and AAA to generate the early authentication key for mutual 702 authentication between the peer and the visited AAA server. 704 Inter-technology support 705 Current specifications on early authentication mostly deal with 706 homogeneous 802.11 networks. AAA attributes such as Calling- 707 Station-ID [I-D.aboba-radext-wlan] may need to be expanded to 708 cover other access technologies. Furthermore, inter-technology 709 handovers may require a change of the peer identifier as part of 710 the handover. Investigation on the best type of identifiers for 711 peers that support multiple access technologies is required. 713 9. Security Considerations 715 This section specifically covers threats introduced to the EAP model 716 by early authentication. Security issues on general EAP and handover 717 are described in other documents such as RFC 3748 [RFC3748], RFC 4962 718 [RFC4962], RFC5169 [RFC5169] and RFC5247 [RFC5247]. 720 Since early authentication as described in this document needs to 721 work across multiple attachment points, any solution needs to 722 consider the following security threats. 724 First, a resource consumption denial of service attack is possible, 725 where an attacker that is not on the same IP link as the legitimate 726 peer or the candidate authenticator may send unprotected early 727 authentication messages to the legitimate peer or the candidate 728 authenticator. As a result, the latter may spend computational and 729 bandwidth resources on processing early authentication messages sent 730 by the attacker. This attack is possible in both the direct and 731 indirect pre-authentication scenarios. To mitigate this attack, the 732 candidate network or authenticator may apply non-cryptographic packet 733 filtering so that only early authentication messages received from a 734 specific set of serving networks or authenticators are processed. In 735 addition, a simple solution for the peer side would be to let the 736 peer always initiate EAP early authentication and not allow EAP early 737 authentication initiation from an authenticator. 739 Second, consideration for the channel binding problem described in 740 [RFC5247] is needed as lack of channel binding may enable an 741 authenticator to impersonate another authenticator or communicate 742 incorrect information via out-of-band mechanisms (such as via a AAA 743 or lower layer protocol) [RFC3748]. It should be noted that it is 744 relatively easier to launch such an impersonation attack for early 745 authentication than normal authentication because an attacker does 746 not need to be physically on the same link as the legitimate peer to 747 send an early authentication trigger to the peer. 749 10. IANA Considerations 751 This document makes no requests for IANA action. 753 11. Acknowledgments 755 The editors would like to thank Preetida Vinayakray, Shubhranshu 756 Singh, Ajay Rajkumar, Rafa Marin Lopez, Jong-Hyouk Lee, Maryna 757 Komarova, Katrin Hoeper, Subir Das, Charles Clancy, Jari Arkko, and 758 Bernard Aboba for their valuable input. 760 12. Contributors 762 The following people all contributed to this document: Alper E. 763 Yegin, Tom Taylor, Srinivas Sreemanthula, Madjid Nakhjiri, Mahalingam 764 Mani and Ashutosh Dutta. 766 13. References 768 13.1. Normative References 770 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 771 Levkowetz, "Extensible Authentication Protocol (EAP)", 772 RFC 3748, June 2004. 774 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 775 Authorization, and Accounting (AAA) Key Management", 776 BCP 132, RFC 4962, July 2007. 778 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 779 Authentication Protocol (EAP) Key Management Framework", 780 RFC 5247, August 2008. 782 13.2. Informative References 784 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 785 "Remote Authentication Dial In User Service (RADIUS)", 786 RFC 2865, June 2000. 788 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 789 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 791 [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, 792 "Handover Key Management and Re-Authentication Problem 793 Statement", RFC 5169, March 2008. 795 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 796 authentication Protocol (ERP)", RFC 5296, August 2008. 798 [I-D.aboba-radext-wlan] 799 Aboba, B., Malinen, J., Congdon, P., and J. Salowey, 800 "RADIUS Attributes for IEEE 802 Networks", 801 draft-aboba-radext-wlan-12 (work in progress), 802 October 2009. 804 [RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., 805 Shiino, H., Zorn, G., Dommety, G., C.Perkins, B.Patil, 806 D.Mitton, S.Manning, M.Beadles, P.Walsh, X.Chen, 807 S.Sivalingham, A.Hameed, M.Munson, S.Jacobs, B.Lim, 808 B.Hirschman, R.Hsu, Y.Xu, E.Campell, S.Baba, and E.Jaques, 809 "Criteria for Evaluating AAA Protocols for Network 810 Access", RFC 2989, November 2000. 812 [IEEE.802-1X.2004] 813 Institute of Electrical and Electronics Engineers, "Port- 814 Based Network Access Control", IEEE Standard 802.1X, 2004. 816 [IEEE.802-21] 817 Institute of Electrical and Electronics Engineers, "Draft 818 Standard for Local and Metropolitan Area Networks:Media 819 Independent Handover Services", IEEE Draft Standard 820 802.21, 2008. 822 [IEEE.802-11.2007] 823 Institute of Electrical and Electronics Engineers, 824 "Information technology - Telecommunications and 825 information exchange between systems - Local and 826 metropolitan area networks - Specific requirements - Part 827 11: Wireless LAN Medium Access Control (MAC) and Physical 828 Layer (PHY) specifications", IEEE Standard 802.11, 2007. 830 [IEEE.802-11R.2008] 831 Institute of Electrical and Electronics Engineers, 832 "Information technology - Telecommunications and 833 information exchange between systems - Local and 834 metropolitan area networks - Specific requirements - Part 835 11: Wireless LAN Medium Access Control (MAC) and Physical 836 Layer (PHY) specifications - Amendment 2: Fast BSS 837 Transition", IEEE Standard 802.11R, 2008. 839 [IEEE.802-11F.2003] 840 Institute of Electrical and Electronics Engineers, "IEEE 841 Trial-Use Recommended Practice for Multi-Vendor Access 842 Point Interoperability via an Inter-Access Point Protocol 843 Across Distribution Systems Supporting IEEE 802.11 844 Operation", IEEE Recommendation 802.11F, 2003. 846 [TS33.402] 847 3GPP, "System Architecture Evolution (SAE):Security 848 aspects of non-3GPP accesses (Release 8)", 3GPP 849 TS33.402 V8.3.1, 2009. 851 [ITU] ITU-T, "General Characteristics of International Telephone 852 Connections and International Telephone Circuits: One-Way 853 Transmission Time", ITU-T Recommendation G.114, 1998. 855 [WPA] The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)", Wi- 856 Fi WPA v3.1, 2004. 858 [MQ7] Lopez, R., Dutta, A., Ohba, Y., Schulzrinne, H., and A. 859 Skarmeta, "Network-layer Assisted Mechanism to Optimize 860 Authentication Delay During Handoff in 802.11 Networks", 861 The 4th Annual International Conference on Mobile and 862 Ubiquitous Systems: Computing, Networking and 863 Services (MOBIQUITOUS 2007), 2007. 865 [WCM] Dutta, A., Famorali, D., Das, S., Ohba, Y., and R. Lopez, 866 "Media-independent pre-authentication supporting secure 867 interdomain handover optimization", IEEE Wireless 868 Communications Volume 15, Issue 2, April 2008. 870 Authors' Addresses 872 Yoshihiro Ohba (editor) 873 Toshiba America Research, Inc. 874 1 Telcordia Drive 875 Piscataway, NJ 08854 876 USA 878 Phone: +1 732 699-5365 879 Email: yohba@tari.toshiba.com 881 Qin Wu (editor) 882 Huawei Technologies Co.,Ltd 883 SiteB, Floor 12F,Huihong Mansion, No.91.,Baixia Rd. 884 Nanjing, JiangSu 210001 885 China 887 Phone: +86 25 84565892 888 Email: sunseawq@huawei.com 889 Glen Zorn (editor) 890 Network Zen 891 1463 East Republican Street, 892 Seattle, Washington 98112 893 USA 895 Email: gwz@net-zen.net