idnits 2.17.1 draft-ietf-hokey-arch-design-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (January 13, 2012) is 4484 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-hokey-rfc5296bis-06 == Outdated reference: A later version (-11) exists of draft-ietf-hokey-erp-aak-06 == Outdated reference: A later version (-17) exists of draft-ietf-dime-erp-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn, Ed. 3 Internet-Draft Network Zen 4 Intended status: Informational Q. Wu 5 Expires: July 16, 2012 T. Taylor 6 Huawei 7 Y. Nir 8 Check Point 9 K. Hoeper 10 Motorola 11 S. Decugis 12 INSIDE Secure 13 January 13, 2012 15 Handover Keying (HOKEY) Architecture Design 16 draft-ietf-hokey-arch-design-11 18 Abstract 20 The Handover Keying (HOKEY) Working Group seeks to minimize handover 21 delay due to authentication when a peer moves from one point of 22 attachment to another. Work has progressed on two different 23 approaches to reduce handover delay: early authentication (so that 24 authentication does not need to be performed during handover), and 25 reuse of cryptographic material generated during an initial 26 authentication to save time during re-authentication. A basic 27 assumption is that the mobile host or "peer" is initially 28 authenticated using the Extensible Authentication Protocol (EAP), 29 executed between the peer and an EAP server as defined in RFC 3748. 31 This document defines the HOKEY architecture. Specifically, it 32 describes design objectives, the functional environment within which 33 handover keying operates, the functions to be performed by the HOKEY 34 architecture itself, and the assignment of those functions to 35 architectural components. It goes on to illustrate the operation of 36 the architecture within various deployment scenarios that are 37 described more fully in other documents produced by the HOKEY Working 38 Group. 40 Status of this Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on July 16, 2012. 57 Copyright Notice 59 Copyright (c) 2012 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.1. Reducing Signaling Overhead . . . . . . . . . . . . . . . 7 78 3.1.1. Minimized Communications with Home Servers . . . . . . 7 79 3.1.2. Minimized User Interaction for Authentication . . . . 7 80 3.2. Integrated Local Domain Name (LDN) Discovery . . . . . . . 7 81 3.3. Fault-tolerant re-authentication . . . . . . . . . . . . . 8 82 3.4. Improved Deployment Scalability . . . . . . . . . . . . . 8 83 4. Required Functionality . . . . . . . . . . . . . . . . . . . . 8 84 4.1. Authentication Subsystem Functional Overview . . . . . . . 8 85 4.2. Pre-Authentication Function (Direct or Indirect) . . . . . 9 86 4.3. EAP Re-authentication Function . . . . . . . . . . . . . . 9 87 4.4. EAP Authentication Function . . . . . . . . . . . . . . . 10 88 4.5. Authenticated Anticipatory Keying (AAK) Function . . . . . 10 89 4.6. Management of EAP-Based Handover Keys . . . . . . . . . . 10 90 5. Components of the HOKEY Architecture . . . . . . . . . . . . . 10 91 5.1. Functions of the Peer . . . . . . . . . . . . . . . . . . 11 92 5.2. Functions of the Serving Authenticator . . . . . . . . . . 12 93 5.3. Functions of the Candidate Authenticator . . . . . . . . . 13 94 5.4. Functions of the EAP Server . . . . . . . . . . . . . . . 13 95 5.5. Functions of the ER Server . . . . . . . . . . . . . . . . 14 96 6. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 15 97 6.1. Simple Re-authentication . . . . . . . . . . . . . . . . . 15 98 6.2. Intra-domain Handover . . . . . . . . . . . . . . . . . . 15 99 6.3. Inter-domain handover . . . . . . . . . . . . . . . . . . 16 100 6.4. Inter-technology handover . . . . . . . . . . . . . . . . 16 101 7. AAA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 102 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 16 103 7.2. Transport Aspect . . . . . . . . . . . . . . . . . . . . . 17 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 105 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 106 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 108 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 109 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 112 1. Introduction 114 The Extensible Authentication Protocol (EAP) [RFC3748] is an 115 authentication framework that supports different types of 116 authentication methods. Originally designed for dial-up connections, 117 EAP is now commonly used for authentication in in a variety of access 118 networks. 120 When a host (or "peer", the term used from this point onward) changes 121 its point of attachment to the network, it must be re-authenticated. 122 If a full EAP authentication must be repeated, several message round- 123 trips between the peer and the home EAP server may be involved. The 124 resulting delay will result in degradation or in the worst case loss 125 of any service session in progress if communication is suspended 126 while re-authentication is carried out. The delay is worse if the 127 new point of attachment is in a visited network rather than the 128 peer's home network, because of the extra procedural steps involved 129 as well as because of the probable increase in round-trip time. 131 RFC 5169 [RFC5169] describes this problem more fully and establishes 132 design goals for solutions to reduce re-authentication delay for 133 transfers within a single administrative domain. It also suggests a 134 number of ways to achieve a solution: 136 o specification of a method-independent, efficient, re- 137 authentication protocol based upon EAP; 139 o reuse of keying material from the initial EAP authentication; 141 o deployment of re-authentication servers local to the peer to 142 reduce round-trip delay; and 144 o specification of the additional protocol needed to allow the EAP 145 server to pass authentication information to the local re- 146 authentication servers. 148 RFC 5295 [RFC5295] tackles the problem of reuse of keying material by 149 specifying how to derive a hierarchy of cryptographically independent 150 purpose-specific keys from the results of the original EAP 151 authentication, while Wu, et al. [I-D.ietf-hokey-rfc5296bis] 152 specifies a method-independent re-authentication protocol (ERP) 153 applicable to two specific deployment scenarios: 155 o where the peer's home EAP server also performs re-authentication; 156 and 158 o where a local re-authentication server exists but is collocated 159 with a AAA proxy within the domain. 161 Other work provides further pieces of the solution or insight into 162 the problem. For the purpose of this memo, RFC 5749 [RFC5749] 163 provides an abstract mechanism for distribution of keying material 164 from the EAP server to re-authentication servers. RFC 5836 [RFC5836] 165 contrasts the EAP re-authentication (ER) strategy provided by ERP 166 with an alternative strategy called "early authentication". RFC 5836 167 defines EAP early authentication as the use of EAP by a mobile peer 168 to establish authenticated keying material on a target attachment 169 point prior to its arrival. Hence, the goal of EAP early 170 authentication is to complete all EAP-related communications, 171 including AAA signaling, in preparation for the handover, before the 172 mobile device actually moves. Early authentication includes direct 173 and indirect pre-authentication as well as Authenticated Anticipatory 174 Keying (AAK). All three early authentication mechanisms provide 175 means to securely establish authenticated keying material on a 176 Candidate Access Point (CAP) while still being connected to the 177 Serving Access Point (SAP) but vary in their respective system 178 assumptions and communication paths. In particular, direct pre- 179 authentication assumes that clients are capable of discovering 180 candidate access points and all communications are routed through the 181 serving access point. On the other hand, indirect pre-authentication 182 assumes an existing relationship between SAP and CAP, whereas the 183 discovery and selection of Candidate Access Points is outside the 184 scope of AAK. Furthermore, both direct and indirect pre- 185 authentication require a full EAP execution to occur before the 186 handover of the peer takes place, while AAK (like ERP 187 [I-D.ietf-hokey-rfc5296bis]) uses keys derived from the initial EAP 188 authentication. 190 Both EAP re-authentication and early authentication enable faster 191 inter-authenticator handovers. However, it is currently unclear how 192 the necessary handover infrastructure can be deployed and integrated 193 into existing EAP infrastructures. In particular, previous work has 194 not described how ER servers that act as endpoints in the re- 195 authentication process should be integrated into local and home 196 domain networks. Furthermore, it is currently unspecified how EAP 197 infrastructure can support the timely triggering of early 198 authentications and aid with the selection of candidate access 199 points. 201 This document proposes a general HOKEY architecture and demonstrates 202 how it can be adapted to different deployment scenarios. To begin 203 with, Section 3 recalls the design objectives for the HOKEY 204 architecture. Section 4 reviews the functions that must be supported 205 within the architecture. Section 5 describes the components of the 206 HOKEY architecture. Section 6 describes the different deployment 207 scenarios that the HOKEY Working Group has addressed and the 208 information flows that must occur within those scenarios, by 209 reference to the documents summarized above where possible and 210 otherwise within this document itself. Finally, Section 7 provides 211 an analysis of how AAA protocols can be applied in the HOKEY 212 architecture. 214 2. Terminology 216 This document contains no normative language, hence [RFC2119] 217 language does not apply. 219 This document reuses terms defined in Section 2.2 of Ohba, et al. 220 [RFC5836] and Section 2 of Wu, et al. [I-D.ietf-hokey-rfc5296bis]. 221 In addition, it defines the following: 223 DSrRK 224 Domain-Specific reauthentication Root Key. 226 EAP Early Authentication 227 The use of EAP by a mobile peer to establish authenticated keying 228 material on a target attachment point prior to its arrival, see 229 Ohba, et al. [RFC5836]. 231 ER Key Management 232 An instantiation of the mechanism described in Hoeper, et al. 233 [RFC5749] for creating and delivering root keys from an EAP server 234 to an ER server. 236 EAP Re-authentication (ER) 237 The use of keying material derived from an initial EAP 238 authentication to enable single-roundtrip re-authentication of a 239 mobile peer. For a detailed description of the keying material 240 see Section 4 of Wu, et al. [I-D.ietf-hokey-rfc5296bis]. 242 ER Server 243 A component of the HOKEY architecture that terminates the EAP re- 244 authentication exchange with the peer. 246 3. Design Goals 248 This section investigates the design goals for the HOKEY 249 architecture. These include reducing the signaling overhead for re- 250 authentication and early authentication, integrating local domain 251 name discovery, enabling fault-tolerant re-authentication and 252 improving deployment scalability. These goals supplement those 253 discussed in Section 4 of RFC 5169 [RFC5169]. Note that the 254 identification and selection of Candidate Access Points is not a goal 255 of the architecture, since those operations are generally specific to 256 the lower layer in use. 258 3.1. Reducing Signaling Overhead 260 3.1.1. Minimized Communications with Home Servers 262 ERP [I-D.ietf-hokey-rfc5296bis] requires only one round trip; 263 however, this roundtrip may require communication between a peer and 264 its home ER and/or home AAA server in explicit bootstrapping and 265 communication between local servers and home server in implicit 266 bootstrapping even if the peer is currently attached to a visited 267 (local) network. As a result, even this one round trip may introduce 268 long delays because the home ER and home AAA servers may be distant 269 from the peer and the network to which it is attached. To lower 270 signaling overhead, communication with the home ER server and home 271 AAA server should be minimized. Ideally, a peer should only need to 272 communicate with local servers and other local entities. 274 3.1.2. Minimized User Interaction for Authentication 276 When the peer is initially attached to the network or moves between 277 heterogeneous networks, full EAP authentication between the peer and 278 EAP server occurs and user interaction may be needed, e.g., a dialog 279 to prompt the user for credentials. To reduce latency, user 280 interaction for authentication at each handover should be minimized. 281 Ideally, user involvement should take place only during initial 282 authentication and subsequent re-authentication should occur 283 transparently. 285 3.2. Integrated Local Domain Name (LDN) Discovery 287 ERP bootstrapping must occur before (implicit) or during (explicit) a 288 handover to transport the necessary keys to the local ER server 289 involved. Implicit bootstrapping is preferable because it does not 290 require communication with the home ER server during handover, but it 291 requires the peer to know the domain name of the ER server before the 292 subsequent local ERP exchange happens in order to derive the 293 necessary re-authentication keying material. ERP 294 [I-D.ietf-hokey-rfc5296bis] does not specify such a domain name 295 discovery mechanism and suggests that the peer may learn the domain 296 name through the EAP-Initiate/ Re-auth-Start message or via lower- 297 layer announcements. However, domain name discovery happens after 298 the implicit bootstrapping completes, which may introduce extra 299 latency. To allow more efficient handovers, a HOKEY architecture 300 should support an efficient domain name discovery mechanism (for 301 example, see Zorn, Wu & Wang [RFC6440]) and allow its integration 302 with ERP implicit bootstrapping. Even in the case of explicit 303 bootstrapping, local domain name discovery should be optimized such 304 that it does not require contacting the home AAA server, as is 305 currently the case. 307 3.3. Fault-tolerant re-authentication 309 If all authentication services depend upon a remote server, a network 310 partition can result in the denial of service to valid users. 311 However, if for example an ER server exists in the local network, 312 previously authenticated users can re-authenticate even though a link 313 to the home or main authentication server doesn't exist. 315 3.4. Improved Deployment Scalability 317 To provide better deployment scalability, there should be no 318 requirement for the co-location of entities proving handover keying 319 services (e.g., ER servers) and AAA servers or proxies. Separation 320 of these entities may cause problems with routing, but allows greater 321 flexibility in deployment and implementation. 323 4. Required Functionality 325 4.1. Authentication Subsystem Functional Overview 327 The operation of the authentication subsystem provided by HOKEY also 328 depends on the availability of a number of discovery functions: 330 o discovery of candidate access points, by the peer, by the serving 331 attachment point, or by some other entity; 333 o discovery of the authentication services supported at a given 334 candidate access point; 336 o discovery of the required server in the home domain when a 337 candidate access point is not in the same domain as the serving 338 attachment point, or no local server is available; 340 o peer discovery of the local domain name (LDN) when EAP re- 341 authentication is used with a local server. 343 It is assumed that these functions are provided by the environment 344 within which the authentication subsystem operates, and are outside 345 the scope of the authentication subsystem itself. Local domain name 346 discovery is a possible exception. 348 The major functions comprising the authentication subsystem and their 349 inter-dependencies are discussed in greater detail below. 351 o When AAA is invoked to authorize network access, it uses one of 352 two services offered by the authentication subsystem: full EAP 353 authentication, or EAP re-authentication. Note that although AAA 354 may perform authentication directly in some cases, when EAP is 355 utilized AAA functions only as a transport for EAP messages and 356 the encryption keys (if any) resulting from successful EAP 357 authentication. 359 o Pre-authentication triggers AAA network access authorization at 360 each candidate access point, which in turn causes full EAP 361 authentication to be invoked. 363 o EAP re-authentication invokes ER key management at the time of 364 authentication to create and distribute keying material to ER 365 servers. 367 o Authenticated anticipatory keying (AAK) relies on ER key 368 management to establish keying material on ER/AAK servers, but 369 uses an extension to ER key management to derive and establish 370 keying material on candidate authenticators. AAK uses an 371 extension to EAP re-authentication to communicate with ER/AAK 372 servers. 374 EAP authentication, EAP re-authentication, and handover key 375 distribution depend on the routing and secure transport service 376 provided by AAA. Discovery functions and the function of 377 authentication and authorization of network entities (access points, 378 ER servers) are not shown. As stated above, these are external to 379 the authentication subsystem. 381 4.2. Pre-Authentication Function (Direct or Indirect) 383 The pre-authentication function is responsible for discovery of 384 candidate access points and completion of network access 385 authentication and authorization at each candidate access point in 386 advance of handover. The operation of this function is described in 387 general terms in Ohba, et al. [RFC5836]. No document is yet 388 available to describe the implementation of pre-authentication in 389 terms of specific protocols; Pre-Authentication Support for PANA 390 [RFC5873] could be part of the solution. 392 4.3. EAP Re-authentication Function 394 The EAP re-authentication function is responsible for authenticating 395 the peer at a specific access point using keying material derived 396 from a prior full EAP authentication. RFC 5169 [RFC5169] provides 397 the design objectives for an implementation of this function. ERP 398 [I-D.ietf-hokey-rfc5296bis] describes a protocol to implement EAP re- 399 authentication. 401 4.4. EAP Authentication Function 403 The EAP authentication function is responsible for authenticating the 404 peer at a specific access point using a full EAP exchange. Aboba, et 405 al. [RFC3748] defines the associated protocol, while Ohba, et al. 406 [RFC5836] describe the use of EAP as part of pre-authentication. 407 Note that the HOKEY Working Group has not specified the non-AAA 408 protocol required to transport EAP frames over IP that is shown in 409 Figures 3 and 5 of Ohba, et al. [RFC5836], although PANA [RFC5873] 410 is a candidate. 412 4.5. Authenticated Anticipatory Keying (AAK) Function 414 The authenticated anticipatory keying function is responsible for 415 pre-placing keying material derived from an initial full EAP 416 authentication on candidate access points. The operation is carried 417 out in two steps: ER key management (with trigger not currently 418 specified) places root keys derived from initial EAP authentication 419 onto an ER/AAK server associated with the peer. When requested by 420 the peer, the ER/AAK server derives and pushes predefined master 421 session keys to one or more candidate access points. The operation 422 of the authenticated anticipatory keying function is described in 423 very general terms in Ohba, et al. [RFC5836]. A protocol 424 specification exists (see Cao, et al. [I-D.ietf-hokey-erp-aak]). 426 4.6. Management of EAP-Based Handover Keys 428 Handover key management consists of EAP method independent key 429 derivation and distribution and comprises the following specific 430 functions: 432 o handover key derivation; and 434 o handover key distribution. 436 The derivation of handover keys is specified in Salowey, et al. 437 [RFC5295], and AAA-based key distribution is specified in Hoeper, 438 Nakhjiri & Ohba [RFC5749]. 440 5. Components of the HOKEY Architecture 442 This section describes the components of the HOKEY architecture in 443 terms of the functions they perform. The components cooperate as 444 described in this section to carry out the functions described in the 445 previous section. Section 6 describes the different deployment 446 scenarios that are possible using these functions. 448 The components of the HOKEY architecture are as follows: 450 o the peer; 452 o the authenticator, which is a part of the serving access point and 453 candidate access points; 455 o the EAP server; and 457 o the ER server, and 459 o the ER/AAK server , [I-D.ietf-hokey-erp-aak] either in the home 460 domain or local to the authenticator. 462 5.1. Functions of the Peer 464 The peer participates in the functions described in Section 4 as 465 shown in Table 1. 467 +--------------------+----------------------------------------------+ 468 | Function | Peer Role | 469 +--------------------+----------------------------------------------+ 470 | EAP authentication | Determines that full EAP authentication is | 471 | | needed based on context (e.g., initial | 472 | | authentication), prompting from the | 473 | | authenticator, or discovery that only EAP | 474 | | authentication is supported. Participates | 475 | | in the EAP exchange with the EAP server. | 476 | - | - | 477 | Direct | Discovers candidate access points. | 478 | pre-authentication | Initiates pre-authentication with each, | 479 | | followed by EAP authentication as above, but | 480 | | using IP rather than L2 transport for the | 481 | | EAP frames. | 482 | - | - | 483 | Indirect | Enters into a full EAP exchange when | 484 | pre-authentication | triggered, using either L2 or L3 transport | 485 | | for the frames. | 486 | - | - | 487 | EAP | Determines that EAP re-authentication is | 488 | re-authentication | possible based on discovery or authenticator | 489 | | prompting. Participates in ERP exchange | 490 | | with ER server. | 491 | - | - | 492 | Authenticated | Determines that AAK is possible based on | 493 | anticipatory | discovery or serving authenticator | 494 | keying | prompting. Discovers candidate access | 495 | | points. Participates in ERP/AAK exchange, | 496 | | requesting distribution of keying material | 497 | | to the candidate access points. | 498 | - | - | 499 | ER key management | No role. | 500 +--------------------+----------------------------------------------+ 502 Table 1: Functions of the Peer 504 5.2. Functions of the Serving Authenticator 506 The serving authenticator participates in the functions described in 507 Section 4 as shown in Table 2. 509 +--------------------+----------------------------------------------+ 510 | Function | Serving Authenticator Role | 511 +--------------------+----------------------------------------------+ 512 | EAP authentication | No role. | 513 | - | - | 514 | Direct | No role. | 515 | pre-authentication | | 516 | - | - | 517 | Indirect | Discovers candidate access points. | 518 | pre-authentication | Initiates an EAP exchange between the peer | 519 | | and the EAP server through each candidate | 520 | | authenticator. Mediates between L2 | 521 | | transport of EAP frames on the peer side and | 522 | | a non-AAA protocol over IP toward the | 523 | | candidate access point. | 524 | - | - | 525 | EAP | No role. | 526 | re-authentication | | 527 | - | - | 528 | Authenticated | Mediates between L2 transport of AAK frames | 529 | anticipatory | on the peer side and AAA transport toward | 530 | keying | the ER/AAK server. | 531 | - | - | 532 | ER key management | No role. | 533 +--------------------+----------------------------------------------+ 535 Table 2: Functions of the Serving Authenticator 537 5.3. Functions of the Candidate Authenticator 539 The candidate authenticator participates in the functions described 540 in Section 4 as shown in Table 3. 542 +--------------------+----------------------------------------------+ 543 | Function | Candidate Authenticator Role | 544 +--------------------+----------------------------------------------+ 545 | EAP authentication | Invokes AAA network access authentication | 546 | | and authorization upon handover/initial | 547 | | attachment. Mediates between L2 transport | 548 | | of EAP frames on the peer link and AAA | 549 | | transport toward the EAP server. | 550 | - | - | 551 | Direct | Invokes AAA network access authentication | 552 | pre-authentication | and authorization when the peer initiates | 553 | | authentication. Mediates between non-AAA L3 | 554 | | transport of EAP frames on the peer side and | 555 | | AAA transport toward the EAP server. | 556 | - | - | 557 | Indirect | Same as direct pre-authentication, except | 558 | pre-authentication | that it communicates with the serving | 559 | | authenticator rather than the peer. | 560 | - | - | 561 | EAP | Invokes AAA network access authentication | 562 | re-authentication | and authorization upon handover. Discovers | 563 | | or is configured with the address of the ER | 564 | | server. Mediates between L2 transport of a | 565 | | ERP frames on the peer side and AAA | 566 | | transport toward the ER server. | 567 | - | - | 568 | Authenticated | Receives and saves pMSK. | 569 | anticipatory | | 570 | keying | | 571 | - | - | 572 | ER key management | No role. | 573 +--------------------+----------------------------------------------+ 575 Table 3: Functions of the Candidate Authenticator 577 5.4. Functions of the EAP Server 579 The EAP server participates in the functions described in Section 4 580 as shown in Table 4. 582 +--------------------+----------------------------------------------+ 583 | Function | EAP Server Role | 584 +--------------------+----------------------------------------------+ 585 | EAP authentication | Terminates EAP signaling between it and the | 586 | | peer via the candidate authenticator. | 587 | | Determines whether network access | 588 | | authentication succeeds or fails. Provides | 589 | | MSK to authenticator (via AAA). | 590 | - | - | 591 | Direct | As for EAP authentication. | 592 | pre-authentication | | 593 | - | - | 594 | Indirect | As for EAP authentication. | 595 | pre-authentication | | 596 | - | - | 597 | EAP | Provides rRK or DSrRK to the ER server (via | 598 | re-authentication | AAA). | 599 | - | - | 600 | Authenticated | As for EAP re-authentication. | 601 | anticipatory | | 602 | keying | | 603 | - | - | 604 | ER key management | Creates rRK or DSrRK and distributes it to | 605 | | ER server requesting the information. | 606 +--------------------+----------------------------------------------+ 608 Table 4: Functions of the EAP Server 610 5.5. Functions of the ER Server 612 The ER server participates in the functions described in Section 4 as 613 shown in Table 5. 615 +--------------------+----------------------------------------------+ 616 | Function | ER Server Role | 617 +--------------------+----------------------------------------------+ 618 | EAP authentication | No role. | 619 | - | - | 620 | Direct | No role. | 621 | pre-authentication | | 622 | - | - | 623 | Indirect | No role. | 624 | pre-authentication | | 625 | - | - | 626 | EAP | Acquires rRK or DSrRK as applicable when | 627 | re-authentication | necessary. Terminates ERP signaling between | 628 | | it and the peer via the candidate | 629 | | authenticator. Determines whether network | 630 | | access authentication succeeds or fails. | 631 | | Provides MSK to authenticator. | 632 | - | - | 633 | Authenticated | And acquires rRK or DSrRK as applicable when | 634 | anticipatory | necessary. Derives pMSKs and passes them to | 635 | keying | the candidate access points. | 636 | - | - | 637 | ER key management | Receives and saves rRK or DSrRK as | 638 | | applicable. | 639 +--------------------+----------------------------------------------+ 641 Table 5: Functions of the ER Server 643 6. Usage Scenarios 645 Depending upon whether it involves a change in a domain or access 646 technology, we have the following the usage scenarios. 648 6.1. Simple Re-authentication 650 The peer remains stationary and re-authenticates to the original 651 access point. Note that in this case, the SAP takes the role of the 652 CAP in the discussion above. 654 6.2. Intra-domain Handover 656 The peer moves between two authenticators in the same domain. In 657 this scenario, the peer communicates with the ER server via the ER 658 authenticator within the same network. 660 6.3. Inter-domain handover 662 The peer moves between two different domains. In this scenario, the 663 peer communicates with more than one ER server via one or two 664 different ER authenticators. One ER server is located in the current 665 network as the peer, one is located in the previous network from 666 which the peer moves. Another ER server is located in the home 667 network to which the peer belongs. 669 6.4. Inter-technology handover 671 The peer moves between two heterogeneous networks. In this scenario, 672 the peer needs to support at least two access technologies. The 673 coverage of two access technologies usually is overlapped during 674 handover. In this case, only authentication corresponding to intra- 675 domain handover is required, i.e., the peer can communicate with the 676 same local ER server to complete authentication and obtain keying 677 materials corresponding to the peer. 679 7. AAA Considerations 681 This section provides an analysis of how the AAA protocol can be 682 applied in the hokey architecture in accordance with the 683 Authentication Subsystem Functional Overview (see Section 4.1) 685 7.1. Authorization 687 Authorization is a major issue in deployments. Wherever the peer 688 moves around, the home AAA server provides authorization for the peer 689 during its handover. However, it is unnecessary to couple 690 authorization with authentication at every handover, since 691 authorization is only needed when the peer is initially attached to 692 the network or moves between two different AAA domains. The EAP key 693 management document [RFC5247] discusses several vulnerabilities that 694 are common to handover mechanisms. One important issue arises from 695 the way the authorization decisions which might be handled at the AAA 696 server during network access authentication. For example, if AAA 697 proxies are involved, they may also influence in the authorization 698 decision. Furthermore, the reasons for choosing a particular 699 decision are not communicated to the AAA clients. In fact, the AAA 700 client only knows the final authorization result. Another issue 701 regards session management. In some circumstances when the peer 702 moves from one authenticator to another, the peer may be 703 authenticated by the different authenticator during a period of time 704 and the authenticator to which the peer is currently attached needs 705 to create a new AAA user session, however the AAA server should not 706 view these handoffs as different sessions. Otherwise this may affect 707 user experience and also cause accounting or logging issues. For 708 example, session ID creation, in most cases, is done by each 709 authenticator to which the peer attaches. In this sense, the new 710 authenticator acting as AAA client needs to create a new AAA user 711 session from scratch which forces its corresponding AAA Server to 712 terminate the existing user session with previous authenticator and 713 setup a new user session with the new authenticator. This may 714 complicate the set up and maintenance of the AAA user session. 716 7.2. Transport Aspect 718 The existing AAA protocols can be used to carry EAP messages and ERP 719 messages between the AAA server and AAA clients. AAA transport of 720 ERP messages is specified in Hoeper, Nakhjiri & Ohba [RFC5749] and 721 Bournelle, et al. [I-D.ietf-dime-erp]. AAA transport of EAP 722 messages is specified in [RFC4072]. Key transport also can be 723 performed through a AAA protocol. Zorn, Wu & Cakulev 724 [I-D.ietf-dime-local-keytran] specifies a set of Attribute-Value 725 Pairs (AVPs) providing native Diameter support of cryptographic key 726 delivery. 728 8. IANA Considerations 730 This document does not require any actions by IANA. 732 9. Security Considerations 734 This note does not introduce any new security vulnerabilities. 736 10. Acknowledgments 738 The authors would like to thank Mark Jones, Zhen Cao, Semyon 739 Mizikovsky, Stephen Farrell, Ondrej Sury, Richard Barnes, Jari Arkko 740 and Lionel Morand for their reviews and comments. 742 11. References 744 11.1. Normative References 746 [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, 747 "Handover Key Management and Re-Authentication Problem 748 Statement", RFC 5169, March 2008. 750 [RFC5836] Ohba, Y., Wu, Q., and G. Zorn, "Extensible Authentication 751 Protocol (EAP) Early Authentication Problem Statement", 752 RFC 5836, April 2010. 754 [I-D.ietf-hokey-rfc5296bis] 755 Wu, W., Cao, Z., Zorn, G., Shi, Y., and B. He, "EAP 756 Extensions for EAP Re-authentication Protocol (ERP)", 757 draft-ietf-hokey-rfc5296bis-06 (work in progress), 758 November 2011. 760 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 761 Levkowetz, "Extensible Authentication Protocol (EAP)", 762 RFC 3748, June 2004. 764 11.2. Informative References 766 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 767 Requirement Levels", BCP 14, RFC 2119, March 1997. 769 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 770 "Specification for the Derivation of Root Keys from an 771 Extended Master Session Key (EMSK)", RFC 5295, 772 August 2008. 774 [RFC5749] Hoeper, K., Nakhjiri, M., and Y. Ohba, "Distribution of 775 EAP-Based Keys for Handover and Re-Authentication", 776 RFC 5749, March 2010. 778 [RFC5873] Ohba, Y. and A. Yegin, "Pre-Authentication Support for the 779 Protocol for Carrying Authentication for Network Access 780 (PANA)", RFC 5873, May 2010. 782 [RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication 783 Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, 784 December 2011. 786 [I-D.ietf-hokey-erp-aak] 787 Cao, Z., Deng, H., Wang, Y., Wu, Q., and G. Zorn, "EAP Re- 788 authentication Protocol Extensions for Authenticated 789 Anticipatory Keying (ERP/AAK)", 790 draft-ietf-hokey-erp-aak-06 (work in progress), 791 October 2011. 793 [I-D.ietf-dime-erp] 794 Bournelle, J., Morand, L., Decugis, S., Wu, W., and G. 795 Zorn, "Diameter support for EAP Re-authentication Protocol 796 (ERP)", draft-ietf-dime-erp-07 (work in progress), 797 September 2011. 799 [I-D.ietf-dime-local-keytran] 800 Zorn, G., Wu, W., and V. Cakulev, "Diameter Attribute- 801 Value Pairs for Cryptographic Key Transport", 802 draft-ietf-dime-local-keytran-14 (work in progress), 803 August 2011. 805 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 806 Authentication Protocol (EAP) Key Management Framework", 807 RFC 5247, August 2008. 809 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 810 Authentication Protocol (EAP) Application", RFC 4072, 811 August 2005. 813 Authors' Addresses 815 Glen Zorn (editor) 816 Network Zen 817 227/358 Thanon Sanphawut 818 Bang Na, Bangkok 10260 819 Thailand 821 Phone: +66 (0) 87-0404617 822 Email: glenzorn@gmail.com 824 Qin Wu 825 Huawei Technologies Co.,Ltd 826 Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd. 827 Nanjing, JiangSu 210001 828 China 830 Phone: +86-25-84565892 831 Email: bill.wu@huawei.com 833 Tom Taylor 834 Huawei Technologies Co., Ltd 835 Ottawa, Ontario 836 Canada 838 Email: tom111.taylor@bell.net 839 Yoav Nir 840 Check Point 841 5 Hasolelim st. 842 Tel Aviv 67897 843 Israel 845 Email: ynir@checkpoint.com 847 Katrin Hoeper 848 Motorola, Inc. 849 1301 E. Algonquin Road 850 Schaumburg, IL 60196 851 USA 853 Email: khoeper@motorola.com 855 Sebastien Decugis 856 INSIDE Secure 857 41 Parc Club du Golf 858 Aix-en-Provence 13856 859 France 861 Phone: +33 (0)4 42 39 63 00 862 Email: sdecugis@freediameter.net