idnits 2.17.1 draft-hoeper-hokey-arch-design-03.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 (July 12, 2010) is 5035 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5247' is defined on line 670, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5296 (Obsoleted by RFC 6696) -- No information found for draft-hokey-erp-aak - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Hoeper 3 Internet-Draft Motorola 4 Intended status: Informational S. Decugis 5 Expires: January 13, 2011 NICT 6 G. Zorn 7 Network Zen 8 Q. Wu 9 T. Taylor 10 Huawei 11 July 12, 2010 13 Handover Keying (HOKEY) Architecture Design 14 draft-hoeper-hokey-arch-design-03 16 Abstract 18 The Handover Keying (HOKEY) Working Group seeks to minimize handover 19 delay due to authentication when a peer moves from one point of 20 attachment to another. Work has progressed on two different 21 approaches to reduce handover delay: early authentication (so that 22 authentication does not need to be performed during handover), and 23 reuse of cryptographic material generated during an initial 24 authentication to save time during re-authentication. A starting 25 assumption is that the mobile host or "peer" is initially 26 authenticated using the Extensible Authentication Protocol (EAP), 27 executed between the peer and an EAP server as defined in RFC 3748. 29 This document documents the HOKEY architecture. Specifically, it 30 describes design objectives, the functional environment within which 31 handover keying operates, the functions to be performed by the HOKEY 32 architecture itself, and the assignment of those functions to 33 architectural components. It goes on to illustrate the operation of 34 the architecture within various deployment scenarios that are 35 described more fully in other documents produced by the HOKEY Working 36 Group. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on January 13, 2011. 55 Copyright Notice 57 Copyright (c) 2010 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.1. Reducing Signalling Overhead . . . . . . . . . . . . . . . 6 76 3.1.1. Minimized Communications with Home Servers . . . . . . 6 77 3.1.2. Integrated Local Domain Name (LDN) Discovery . . . . . 6 78 3.2. Better Deployment Scalability . . . . . . . . . . . . . . 7 79 4. Functions That Must Be Supported . . . . . . . . . . . . . . . 7 80 4.1. System Overview . . . . . . . . . . . . . . . . . . . . . 7 81 4.2. Pre-Authentication Function (Direct or Indirect) . . . . . 9 82 4.3. EAP Re-authentication Function . . . . . . . . . . . . . . 9 83 4.4. EAP Authentication Function . . . . . . . . . . . . . . . 10 84 4.5. Authenticated Anticipatory Keying (AAK) Function . . . . . 10 85 4.6. EAP-Based Handover Key Management . . . . . . . . . . . . 10 86 5. Components of the HOKEY Architecture . . . . . . . . . . . . . 10 87 5.1. Functions of the Peer . . . . . . . . . . . . . . . . . . 11 88 5.2. Functions of the Serving Authenticator . . . . . . . . . . 12 89 5.3. Functions of the Candidate Authenticator . . . . . . . . . 13 90 5.4. Functions of the EAP Server . . . . . . . . . . . . . . . 13 91 5.5. Functions of the ER Server . . . . . . . . . . . . . . . . 14 92 6. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 15 93 7. AAA Consideration . . . . . . . . . . . . . . . . . . . . . . 15 94 7.1. Standalone HOKEY server . . . . . . . . . . . . . . . . . 15 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 97 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 98 11. Informative References . . . . . . . . . . . . . . . . . . . . 16 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 101 1. Introduction 103 The Extensible Authentication Protocol (EAP) [RFC3748] is an 104 authentication framework that supports different types of 105 authentication methods. Originally designed for dial-up connections, 106 EAP is now commonly used for authentication in wireless access 107 networks. 109 When a host (or "peer", the term used from this point onward) changes 110 its point of attachment to the network, it must be re-authenticated. 111 If a full EAP authentication must be repeated, several message round- 112 trips between the peer and the home EAP server may be involved. The 113 resulting delay will result in degradation or in the worst case loss 114 of any service session in progress if communication is suspended 115 while re-authentication is carried out. The delay is worse if the 116 new point of attachment is in a visited network rather than the 117 peer's home network, because of the extra procedural steps involved 118 as well as because of the probable increase in round-trip time. 120 [RFC5169] describes this problem more fully and establishes design 121 goals for solutions to reduce re-authentication delay for transfers 122 within a single administrative domain. [RFC5169] also suggests a 123 number of ways to achieve a solution: 125 o specification of a method-independent, efficient, re- 126 authentication protocol; 128 o reuse of keying material from the initial authentication; 130 o deployment of re-authentication servers local to the peer to 131 reduce round-trip delay; and 133 o specification of the additional protocol needed to allow the EAP 134 server to pass authentication information to the local re- 135 authentication servers. 137 [RFC5295] tackles the problem of reuse of keying material by 138 specifying how to derive a hierarchy of cryptographically independent 139 purpose-specific keys from the results of the original EAP 140 authentication. [RFC5296] specifies a method-independent re- 141 authentication protocol (ERP) applicable to two specific deployment 142 scenarios: 144 o where the peer's home EAP server also performs re-authentication; 145 and 147 o where a local re-authentication server exists but is collocated 148 with a AAA proxy within the domain. 150 Other work provides further pieces of the solution or insight into 151 the problem. [RFC5749] provides an abstract mechanism for 152 distribution of keying material from the EAP server to re- 153 authentication servers. (The stated scope is more general, but is 154 restated in terms consistent with the present summary.) [RFC5836] 155 contrasts the EAP re-authentication (ER) strategy provided by 156 [RFC5296] (which [RFC5836] calls "vertical context transfer") with an 157 alternative strategy called "early authentication". 159 [RFC5836] defines EAP early authentication as the use of EAP by a 160 mobile peer to establish authenticated keying material on a target 161 attachment point prior to its arrival. Here, a full EAP execution 162 occurs before the handover of the peer takes place. Hence, the goal 163 of EAP early authentication is to complete all EAP-related 164 communications, including AAA signaling, in preparation for the 165 handover, before the mobile device actually moves. 167 Both EAP re-authentication and early authentication enable faster 168 inter-authenticator handovers. However, it is currently unclear how 169 the necessary handover infrastructure for ER is deployed and can be 170 integrated into existing EAP infrastructures. In particular, 171 previous work has not described how ER servers (as defined below) 172 should be integrated into local and home domain networks. 174 This document proposes a general HOKEY architecture and demonstrates 175 how it can be adapted to different deployment scenarios. To begin 176 with, Section 3 recalls the design objectives for the HOKEY 177 architecture. Section 4 reviews the functions that must be supported 178 within the architecture. Section 5 describes the components of the 179 HOKEY architecture. Finally, Section 6 describes the different 180 deployment scenarios that the HOKEY Working Group has addressed and 181 the information flows that must occur within those scenarios, by 182 reference to the documents summarized above where possible and 183 otherwise within this document itself. 185 2. Terminology 187 This document contains no normative language, hence [RFC2119] 188 language does not apply. 190 This document reuses most of the terms defined in Section 2.2 of 191 [RFC5836]. In addition, it defines the following: 193 EAP Early Authentication 194 See Section 3.3.2 of [RFC5836]. 196 EAP Re-authentication (ER) 197 The use of keying material derived from an initial EAP 198 authentication to enable single-roundtrip re-authentication of a 199 mobile peer. For a detailed description of the keying material 200 see Section 3 of [RFC5296]. 202 ER Server 203 A component of the HOKEY architecture that terminates the EAP re- 204 authentication exchange with the peer. 206 ER Key Management 207 An instantiation of the mechanism provided by [RFC5749] for 208 creating and delivering root keys from an EAP server to an ER 209 server. 211 3. Design Goals 213 This section investigates the design goals for the HOKEY 214 architecture. These include reducing the signaling overhead for re- 215 authentication and early authentication, integrating local domain 216 name discovery, and improving deployment scalability. These goals 217 supplement the discussion in [RFC5169]. 219 3.1. Reducing Signalling Overhead 221 3.1.1. Minimized Communications with Home Servers 223 ERP requires only one round trip, however, this roundtrip may require 224 communications between a peer and its home ER and/or home AAA server 225 even if the peer is currently attached to a visited (local) network. 226 As a result, even this one round trip may introduce long delays 227 because home ER and home AAA servers may be distant from the peer. 228 To lower the signaling overhead, communication with the home ER 229 server and home AAA server should be minimized. Ideally, a peer 230 should only need to communicate with local servers and other local 231 entities. 233 3.1.2. Integrated Local Domain Name (LDN) Discovery 235 Ideally, whenever a peer performs a handover, ERP is executed between 236 the peer and a local ER server, thus, reducing handover latency by 237 avoiding a full EAP authentication with the peer's home EAP server. 238 For this to work, ERP bootstrapping must occur before (implicit) or 239 during (explicit) a handover to transport the necessary re- 240 authentication root keys to the local ER server involved. Implicit 241 bootstrapping is preferable because it does not require communication 242 with the home ER server during handover (see previous section), but 243 it requires the peer to know the domain name of the ER server in 244 order to derive the necessary re-authentication keying material. 245 [RFC5296] does not specify such a domain name discovery mechanism and 246 suggests that the peer may learn the domain name through the EAP- 247 Initiate/Re-auth-Start message or via lower layer announcements. To 248 allow more efficient handovers, a HOKEY architecture should support 249 an efficient domain name discovery mechanism and allow its 250 integration with ERP implicit bootstrapping. Even in the case of 251 explicit bootstrapping, local domain name discovery should be 252 optimized such that it does not require contacting the home AAA 253 server, as is currently the case. 255 3.2. Better Deployment Scalability 257 To provide better deployment scalability, it should not be required 258 that the HOKEY server and AAA servers or proxies are collocated. 259 Separation of these entities may cause problems with routing, but 260 allows flexibility in deployment and implementation. 262 4. Functions That Must Be Supported 264 4.1. System Overview 266 This section views the HOKEY architecture as the implementation of a 267 subsystem providing authentication services to AAA. Not only does 268 AAA depend on the authentication subsystem, but the latter also 269 depends on AAA as a means for the routing and secure transport of 270 messages internal to the operation of network access authentication. 272 The operation of the authentication subsystem also depends on the 273 availability of a number of discovery functions: 275 o discovery of candidate access points, by the peer, by the serving 276 attachment point, or by some other entity; 278 o discovery of the authentication services supported at a given 279 candidate access point; 281 o discovery of the required server in the home domain when a 282 candidate access point is not in the same domain as the serving 283 attachment point, or no local server is available; 285 o peer discovery of the local domain name (LDN) when EAP re- 286 authentication is used with a local server. 288 It is assumed that these functions are provided by the environment 289 within which the authentication subsystem operates, and are outside 290 the scope of the authentication subsystem itself. Local domain name 291 discovery is a possible exception. 293 Figure 1 shows the major functions comprising the authentication 294 subsystem and their interdependencies. These functions are described 295 below. [EDITOR'S NOTE: These probably need refinement. The 296 relationship of pre-authentication to EAP authentication, for 297 instance, is currently not totally correct, when one takes account of 298 the roles described in Section 5. AAK also needs an extension of ER 299 key management.] 301 +------------------------------------------------------------+ 302 | AAA Network Access Authentication and Authorization | 303 +---+-------------.----------------------------+-------------+ 304 | /|\ | 305 | | Authentication subsystem | 306 +===|=============|============================|=============+ 307 | | +---------+----------+ +-------------V---------+ | 308 | | | Direct and | | EAP Re-authentication | | 309 | | | Indirect | +--+------+-------------+ | 310 | | | Pre-Authentication | / / | 311 | | +--------------------+ / / | 312 | | / / +---------------+ | 313 | | / | | Authenticated | | 314 | | / | | Anticipatory | | 315 | | / | | Keying (AAK) | | 316 | | / | +-------+-------+ | 317 | | / | | | 318 | +-V------------------+ / +---------V----------V--------+ | 319 | | EAP Authentication | | | ER Key Management | | 320 | +---------+----------+ | |+------------+ +------------+| | 321 | | | ||Handover Key| |Handover Key|| | 322 | | | || Derivation | |Distribution|| | 323 | | | |+------------+ +------+-----+| | 324 | | | +----------------------|------+ | 325 +===========|=============|=========================|========+ 326 | | | 327 +-----------V-------------V-------------------------V--------+ 328 | AAA routing and secure transport | 329 +------------------------------------------------------------+ 331 Arrows show the direction of functional dependency. 333 Figure 1: Authentication Subsystem Functional Overview 335 Figure 1 shows the following dependencies: 337 o When AAA is invoked to authenticate and authorize network access, 338 it uses one of two services offered by the authentication 339 subsystem: full EAP authentication, or EAP re-authentication. 341 o Pre-authentication triggers AAA network access authentication and 342 authorization at each candidate access point, which in turn causes 343 full EAP authentication to be invoked. 345 o EAP re-authentication invokes ER key management at the time of 346 authentication to create and distribute keying material to ER 347 servers. 349 o Authenticated anticipatory keying (AAK) relies on ER key 350 management to establish keying material on ER/AAK servers, but 351 uses an extension to ER key management to derive and establish 352 keying material on candidate authenticators. 354 EAP authentication, EAP re-authentication, and handover key 355 distribution depend on the routing and secure transport service 356 provided by AAA. Discovery functions and the function of 357 authentication and authorization of network entities (access points, 358 ER servers) are not shown. As stated above, these are external to 359 the authentication subsystem. 361 4.2. Pre-Authentication Function (Direct or Indirect) 363 The pre-authentication function is responsible for discovery of 364 candidate access points and completion of network access 365 authentication and authorization at each in advance of handover. The 366 operation of this function is described in general terms in 367 [RFC5836]. No document is yet available to describe the 368 implementation of pre-authentication in terms of specific protocols. 369 [RFC5873] could be part of the solution, but is Experimental rather 370 than Standards Track. 372 4.3. EAP Re-authentication Function 374 The EAP re-authentication function is responsible for authenticating 375 the peer at a specific access point using keying material derived 376 from a prior full EAP authentication. [RFC5169] provides the design 377 objectives for an implementation of this function. [RFC5296] 378 describes a protocol to implement EAP re-authentication subject to 379 the architectural restrictions noted above. Work is in progress to 380 relax those restrictions. 382 4.4. EAP Authentication Function 384 The EAP authentication function is responsible for authenticating the 385 peer at a specific access point using a full EAP exchange. [RFC3748] 386 defines the associated protocol. [RFC5836] shows the use of EAP as 387 part of pre-authentication. Note that the HOKEY Working Group has 388 not specified the non-AAA protocol required to transport EAP frames 389 over IP that is shown in Figures 3 and 5 of [RFC5836], although 390 [RFC5873] is a candidate. 392 4.5. Authenticated Anticipatory Keying (AAK) Function 394 The authenticated anticipatory keying function is responsible for 395 pre-placing keying material derived from an initial full EAP 396 authentication on candidate access points. The operation is carried 397 out in two steps: ER key management (with trigger not currently 398 specified) places root keys derived from initial EAP authentication 399 onto an ER/AAK server associated with the peer. When requested by 400 the peer, the ER/AAK server derives and pushes predefined master 401 session keys to a list of candidate access points. The operation of 402 the authenticated anticipatory keying function is described in very 403 general terms in [RFC5836]. A protocol implementation is being 404 specified in [I-D.hokey-erp-aak]. 406 4.6. EAP-Based Handover Key Management 408 EAP-based handover key management consists of EAP method independent 409 key derivation and distribution and comprises the following specific 410 functions: 412 o handover key derivation; and 414 o handover key distribution. 416 The derivation of handover keys is specified in [RFC5295], and key 417 distribution is specified in [RFC5749]. 419 5. Components of the HOKEY Architecture 421 This section describes the components of the HOKEY architecture, in 422 terms of the functions they perform. The components cooperate as 423 described in this section to carry out the functions described in the 424 previous section. Section 6 describes the different deployment 425 scenarios that are possible using these functions. 427 The components of the HOKEY architecture are as follows: 429 o the peer; 431 o the authenticator, which is a part of the serving access point and 432 candidate access points; 434 o the EAP server; and 436 o the ER server, either in the home domain or local to the 437 authenticator. 439 [EDITOR'S NOTE: probably have to add the ER/AAK server named in 440 [I-D.hokey-erp-aak] to this list.] 442 5.1. Functions of the Peer 444 The peer participates in the functions described in Section 4 as 445 shown in Table 1. 447 +--------------------+----------------------------------------------+ 448 | Function | Peer Role | 449 +--------------------+----------------------------------------------+ 450 | EAP authentication | Determines that full EAP authentication is | 451 | | needed based on context (e.g., initial | 452 | | authentication), prompting from the | 453 | | authenticator, or discovery that only EAP | 454 | | authentication is supported. Participates | 455 | | in the EAP exchange with the EAP server. | 456 | - | - | 457 | Direct | Discovers candidate access points. | 458 | pre-authentication | Initiates pre-authentication with each, | 459 | | followed by EAP authentication as above, but | 460 | | using IP rather than L2 transport for the | 461 | | EAP frames. | 462 | - | - | 463 | Indirect | Enters into a full EAP exchange when | 464 | pre-authentication | triggered, using either L2 or L3 transport | 465 | | for the frames. | 466 | - | - | 467 | EAP | Determines that EAP re-authentication is | 468 | re-authentication | possible based on discovery or authenticator | 469 | | prompting. Discovers ER server. | 470 | | Participates in ERP exchange with ER server. | 471 | - | - | 472 | Authenticated | Determines that AAK is possible based on | 473 | anticipatory | discovery or serving authenticator | 474 | keying | prompting. Discovers candidate access | 475 | | points. Sends request to serving | 476 | | authenticator to distribute keying material | 477 | | to the candidate access points. | 478 | - | - | 479 | ER key management | No role. | 480 +--------------------+----------------------------------------------+ 482 Table 1: Functions of the Peer 484 5.2. Functions of the Serving Authenticator 486 The serving authenticator participates in the functions described in 487 Section 4 as shown in Table 2. 489 +--------------------+----------------------------------------------+ 490 | Function | Serving Authenticator Role | 491 +--------------------+----------------------------------------------+ 492 | EAP authentication | No role. | 493 | - | - | 494 | Direct | No role. | 495 | pre-authentication | | 496 | - | - | 497 | Indirect | Discovers candidate access points. | 498 | pre-authentication | Initiates an EAP exchange between the peer | 499 | | and the EAP server through each candidate | 500 | | authenticator. Mediates between L2 | 501 | | transport of EAP frames on the peer side and | 502 | | a non-AAA protocol over IP toward the | 503 | | candidate access point. | 504 | - | - | 505 | EAP | No role. | 506 | re-authentication | | 507 | - | - | 508 | Authenticated | Mediates between L2 transport of AAK frames | 509 | anticipatory | on the peer side and AAA transport toward | 510 | keying | the ER/AAK server. | 511 | - | - | 512 | ER key management | No role. | 513 +--------------------+----------------------------------------------+ 515 Table 2: Functions of the Serving Authenticator 517 5.3. Functions of the Candidate Authenticator 519 The candidate authenticator participates in the functions described 520 in Section 4 as shown in Table 3. 522 +--------------------+----------------------------------------------+ 523 | Function | Candidate Authenticator Role | 524 +--------------------+----------------------------------------------+ 525 | EAP authentication | Invokes AAA network access authentication | 526 | | and authorization upon handover/initial | 527 | | attachment. Mediates between L2 transport | 528 | | of EAP frames on the peer link and AAA | 529 | | transport toward the EAP server. | 530 | - | - | 531 | Direct | Invokes AAA network access authentication | 532 | pre-authentication | and authorization when the peer initiates | 533 | | authentication. Mediates between non-AAA L3 | 534 | | transport of EAP frames on the peer side and | 535 | | AAA transport toward the EAP server. | 536 | - | - | 537 | Indirect | Same as direct pre-authentication, except | 538 | pre-authentication | that it communicates with the serving | 539 | | authenticator rather than the peer. | 540 | - | - | 541 | EAP | Invokes AAA network access authentication | 542 | re-authentication | and authorization upon handover. Discovers | 543 | | or is configured with the address of the ER | 544 | | server. Mediates between L2 transport of a | 545 | | ERP frames on the peer side and AAA | 546 | | transport toward the ER server. | 547 | - | - | 548 | Authenticated | Receives and saves pMSK. | 549 | anticipatory | | 550 | keying | | 551 | - | - | 552 | ER key management | No role. | 553 +--------------------+----------------------------------------------+ 555 Table 3: Functions of the Candidate Authenticator 557 5.4. Functions of the EAP Server 559 The EAP server participates in the functions described in Section 4 560 as shown in Table 4. 562 +--------------------+----------------------------------------------+ 563 | Function | EAP Server Role | 564 +--------------------+----------------------------------------------+ 565 | EAP authentication | Authenticates and authorizes the candidate | 566 | | access point to act as authenticator. | 567 | | Terminates EAP signalling between it and the | 568 | | peer via the candidate authenticator. | 569 | | Determines whether network access | 570 | | authentication succeeds or fails. Provides | 571 | | MSK to authenticator. | 572 | - | - | 573 | Direct | As for EAP authentication. | 574 | pre-authentication | | 575 | - | - | 576 | Indirect | As for EAP authentication. | 577 | pre-authentication | | 578 | - | - | 579 | EAP | Mutually authenticates with the ER server | 580 | re-authentication | and authorizes it for receiving keying | 581 | | amterial. Provides rRK or DSrRK to the ER | 582 | | server. | 583 | - | - | 584 | Authenticated | As for EAP re-authentication. | 585 | anticipatory | | 586 | keying | | 587 | - | - | 588 | ER key management | Creates rRK or DSrRK and distributes it to | 589 | | ER server requesting the information. | 590 +--------------------+----------------------------------------------+ 592 Table 4: Functions of the EAP Server 594 5.5. Functions of the ER Server 596 The ER server participates in the functions described in Section 4 as 597 shown in Table 5. [EDITOR'S NOTE: Need discussion of respective 598 roles of local and home ER server, or whether there should even be 599 such a distinction.] 600 +--------------------+----------------------------------------------+ 601 | Function | ER Server Role | 602 +--------------------+----------------------------------------------+ 603 | EAP authentication | No role. | 604 | - | - | 605 | Direct | No role. | 606 | pre-authentication | | 607 | - | - | 608 | Indirect | No role. | 609 | pre-authentication | | 610 | - | - | 611 | EAP | Authenticates and authorizes the candidate | 612 | re-authentication | access point to act as authenticator. | 613 | | Authenticates itself to the EAP server and | 614 | | acquires rRK or DSrRK as applicable when | 615 | | necessary. Terminates ERP signalling | 616 | | between it and the peer via the candidate | 617 | | authenticator. Determines whether network | 618 | | access authentication succeeds or fails. | 619 | | Provides MSK to authenticator. | 620 | - | - | 621 | Authenticated | Authenticates itself to the EAP server and | 622 | anticipatory | acquires rRK or DSrRK as applicable when | 623 | keying | necessary. Authenticates and authorizes the | 624 | | candidate access points to act as | 625 | | authenticator. Derives pMSKs and passes | 626 | | them to the candidate access points. | 627 | - | - | 628 | ER key management | Receives and saves rRK or DSrRK as | 629 | | applicable. | 630 +--------------------+----------------------------------------------+ 632 Table 5: Functions of the ER Server 634 6. Deployment Scenarios 636 The necessity for this section and its contents are TBD. 638 7. AAA Consideration 640 7.1. Standalone HOKEY server 642 TBD. 644 8. Security Considerations 646 TBD 648 9. IANA Considerations 650 This document has no actions for IANA. 652 10. Acknowledgments 654 The authors would like to thank Qin Wu, Mark Jones, and Zhen Cao for 655 their reviews of the previous version of this draft. 657 11. Informative References 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, March 1997. 662 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 663 Levkowetz, "Extensible Authentication Protocol (EAP)", 664 RFC 3748, June 2004. 666 [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, 667 "Handover Key Management and Re-Authentication Problem 668 Statement", RFC 5169, March 2008. 670 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 671 Authentication Protocol (EAP) Key Management Framework", 672 RFC 5247, August 2008. 674 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 675 "Specification for the Derivation of Root Keys from an 676 Extended Master Session Key (EMSK)", RFC 5295, 677 August 2008. 679 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 680 authentication Protocol (ERP)", RFC 5296, August 2008. 682 [RFC5749] Hoeper, K., Nakhjiri, M., and Y. Ohba, "Distribution of 683 EAP-Based Keys for Handover and Re-Authentication", 684 RFC 5749, March 2010. 686 [RFC5836] Ohba, Y., Wu, Q., and G. Zorn, "Extensible Authentication 687 Protocol (EAP) Early Authentication Problem Statement", 688 RFC 5836, April 2010. 690 [RFC5873] Ohba, Y. and A. Yegin, "Pre-Authentication Support for the 691 Protocol for Carrying Authentication for Network Access 692 (PANA)", RFC 5873, May 2010. 694 [I-D.hokey-erp-aak] 695 Cao, Z., Deng, H., Wang, Y., Wu, Q., and G. Zorn, "EAP Re- 696 authentication Protocol Extensions for Authenticated 697 Anticipatory Keying (ERP/AAK) (Work in Progress)", 698 May 2010. 700 Authors' Addresses 702 Katrin Hoeper 703 Motorola, Inc. 704 1301 E. Algonquin Road 705 Schaumburg, IL 60196 706 USA 708 Email: khoeper@motorola.com 710 Sebastien Decugis 711 NICT 712 4-2-1 Nukui-Kitamachi 713 Tokyo, Koganei 184-8795 714 Japan 716 Email: sdecugis@nict.go.jp 718 Glen Zorn 719 Network Zen 720 1310 East Thomas Street 721 Seattle, Washington 98102 722 USA 724 Email: gwz@net-zen.net 725 Qin Wu 726 Huawei Technologies Co.,Ltd 727 Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd. 728 Nanjing, JiangSu 210001 729 China 731 Phone: +86-25-84565892 732 Email: sunseawq@huawei.com 734 Tom Taylor 735 Huawei Technologies Co., Ltd 736 Ottawa 737 Canada 739 Email: tom111.taylor@bell.net