idnits 2.17.1 draft-engelstad-pana-eap-over-udp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 208 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 40: '... a PAA and a PaC MAY use EAPoUDP to au...' RFC 2119 keyword, line 80: '... a PAA and a PaC MAY use EAPoUDP to au...' RFC 2119 keyword, line 90: '... or the PaC MAY want to terminate...' RFC 2119 keyword, line 103: '...s for itself. It MAY also have discove...' RFC 2119 keyword, line 168: '...tion (I-A), a PAA or a PaC MAY want to...' (29 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8105 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 746, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 749, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 752, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2284 (ref. '2') (Obsoleted by RFC 3748) -- Duplicate reference: RFC2284, mentioned in '3', was also mentioned in '2'. ** Obsolete normative reference: RFC 2284 (ref. '3') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2486 (ref. '4') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 3041 (ref. '5') (Obsoleted by RFC 4941) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Paal Engelstad 3 Telenor R&D, California 4 Expires August 2002 February 2002 6 EAP over UDP (EAPoUDP) 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet- Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 27 Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This document is an individual submission for the PANA Working Group 31 of the Internet Engineering Task Force (IETF). Comments should be 32 submitted to the mailing list pana@research.telcordia.com. 34 Abstract 36 This document specifies the Extensible Authentication Protocol over 37 UDP (EAPoUDP) to be used for network access authentication. An 38 access domain is represented by one or many PANA Authentication 39 Agents (PAAs). Before a PANA Client (PaC) is granted access to the 40 domain, a PAA and a PaC MAY use EAPoUDP to authenticate each other. 41 EAPoUDP is a variation of the Extensible Authentication Protocol 42 (PPP EAP) [2], but runs instead over IP - either IPv4 or IPv6. 43 Unlike PPP EAP, EAPoUDP allows authentication over any link layer 44 technology. Furthermore, the PAA and the PaC need not be on the same 45 link. EAPoUDP uses UDP as its transport protocol. 47 EAP over UDP February 2002 49 Table of Contents 51 1 Introduction.....................................................2 52 2 Terminology......................................................3 53 3 UDP as transport protocol........................................4 54 4 EAPoUDP reuses PPP EAP message formats...........................4 55 4.1 EAPoUDP message format.......................................4 56 4.2 Types for Request/Response messages..........................6 57 4.3 MD-5 Challenge for Re-Authentication.........................6 58 5 EAPoUDP authentication schemes...................................9 59 5.1 Starting the authentication session..........................9 60 5.2 Initial Authentication......................................11 61 5.3 Re-authentication...........................................12 62 5.4 Disconnect..................................................13 63 5.5 Back-end communication......................................13 64 6 Further work....................................................14 65 6.1 Selection of remaining methods..............................14 66 6.2 Retransmission and timeout mechanisms.......................14 67 7 Security Considerations.........................................14 68 IANA Considerations...............................................14 69 Acknowledgements..................................................14 70 References........................................................14 71 Author's Address..................................................15 73 1 Introduction 75 This document specifies the Extensible Authentication Protocol over 76 UDP (EAPoUDP) to be used for network access authentication. 78 An access domain is represented by one or many PANA Authentication 79 Agents (PAAs). Before a PANA Client (PaC) is granted access to the 80 domain, a PAA and a PaC MAY use EAPoUDP to authenticate each other. 82 EAPoUDP calls for methods for Initial Authentication (I-A), Re- 83 Authentication (R-A) and Disconnect Notification (D-N). I-A is for 84 mutual authentication, which a PaC and a PAA are expected to perform 85 before the PaC is granted access to an access domain. A product of 86 the I-A method is a session key established between PaC and PAA. 87 This session key can be used for R-A, when a PAA or a PaC wants to 88 re-authenticate the other party and validate that it is still 89 present and alive. After successful authentication, either the PAA 90 or the PaC MAY want to terminate the authentication relationship by 91 sending a (D-N) to the other party. 93 EAPoUDP is a variation of the Extensible Authentication Protocol 94 (PPP EAP) [2]. Unlike PPP EAP, EAPoUDP runs over IP - either IPv4 or 95 IPv6. Thus, it allows PaCs and PAAs to authenticate each other over 96 any link layer technology, and they do not need to be on the same 97 link. For a lightweight solution, UDP is chosen as transport 98 protocol. 100 EAP over UDP February 2002 102 EAPoUDP assumes that prior to authentication the PaC has configured 103 a valid IPv4 or IPv6 address for itself. It MAY also have discovered 104 an IP-address for at least one PAA in the access domain. PAA 105 Discovery mechanisms are proposed and detailed in [1]. 107 Where to locate PAAs (e.g. with a PAA located on each access router 108 or with a pool of PAAs located anywhere in the access domain) 109 represents an architectural tradeoff. The PANA WG may leave to 110 implementers and operators to decide which architecture best fits 111 their needs. Alternatively, the PANA WG may mandate that PAAs are 112 located on access routers. The scheme presented in this document 113 should accommodate all alternative PAA configurations. 115 2 Terminology 117 This document uses the following terminology same as in [10]: 119 Device Identifier (DI) 121 This is the identifier used by the network as a handle to control 122 and police the network access of a client. Depending on the 123 access technology, identifier might contain any of IP address, 124 link-layer address, switch port number, etc. of a device. PANA 125 authentication agent keeps a table for binding device identifiers 126 to the PANA clients. 128 PANA Client (PaC) 130 This is the entity wishing to obtain network access from a PANA 131 authentication agent within a network. A PANA client is 132 associated with a network device and a set of credentials to 133 prove its identity within the scope of PANA. 135 PANA Authentication Agent (PAA) 137 This is the entity whose responsibility is to authenticate the 138 credentials provided by a PANA client and grant network access 139 service to the device associated with the client and identified 140 by a DI. 142 In addition, the following terms are introduced: 144 Initiator 146 The Initiator (i.e. like a PPP EAP Authenticator [2], [3]) of an 147 EAPoUDP authentication method is the entity (i.e. a PaC or a PAA) 148 that sends the EAPoUDP Request(s) to a Peer. 150 Peer 152 EAP over UDP February 2002 154 The Peer of an EAP-based authentication method is the entity 155 (i.e. a PaC or a PAA) that sends the EAPoUDP Response(s) back to 156 an Initiator. 158 Initial Authentication (I-A) 160 Initial Authentication is the method for mutual authentication, 161 that a PaC and a PAA are expected to perform before the PaC is 162 granted access to an access domain. A product of I-A is a session 163 key is established between PaC and PAA, which is used for Re- 164 Authentication (below). 166 Re-Authentication (R-A) 168 After Initial Authentication (I-A), a PAA or a PaC MAY want to 169 re-authenticate the other party and validate that it is still 170 present and alive. A common method for R-A is that the Initiator 171 sends a challenge to the Peer. The Peer computes a hash over the 172 challenge, keyed by a session key, and returns the result to the 173 Initiator. The Peer and Initiator use the session key established 174 during the Initial Authentication to key the hash. This document 175 specifies a method for re-authentication (R-A). 177 Disconnect Notification (D-N) 179 After successful authentication, either the PAA or the PaC MAY 180 want to explicitly terminate the authentication relationship by 181 sending a Disconnect-Notification (D-N) to the other party. D-Ns 182 alone cannot guarantee disconnect. Due to Denial-of-Service (DoS) 183 threats, D-N cannot be guaranteed to reach the other party. 184 Disconnect can only be guaranteed by mandatory timeout mechanisms 185 implemented in I-A and R-A. Thus, D-N is a function to optimize 186 EAPoUDP. D-Ns MUST be integrity protected to avoid being a tool 187 for DoS attacks. 189 3 UDP as transport protocol 191 This document suggests that EAPoUDP uses UDP as its transport 192 protocol. 194 For a lightweight solution, UDP and ICMP are both attractive 195 alternatives. UDP is chosen here to allow for application layer 196 implementations. 198 EAPoUDP SHOULD use IANA-assigned port numbers (TBD). 200 4 EAPoUDP reuses PPP EAP message formats 202 4.1 EAPoUDP message format 204 EAP over UDP February 2002 206 The EAPoUDP specification follows that of PPP EAP ([2], [3]) unless 207 otherwise specified in this document. 209 The EAPoUDP packet reuses the PPP EAP format ([2], [3]). An EAPoUDP 210 packet will be sent as follows: 212 +-----------+------------+-------------+ 213 | IP header | UDP header | EAP message | 214 +-----------+------------+-------------+ 216 All messages begins with a 32-bit header following the UDP header: 218 0 1 2 3 219 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Code | Identifier | Length | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Data ... 224 +-+-+-+-+ 226 Code 228 The Code field is one octet and identifies the type of EAPoUDP 229 message. EAPoUDP Codes reuse the following EAP Codes: 231 1 Request 232 2 Response 233 3 Success 234 4 Failure 236 Identifier 238 The Identifier field is one octet and is used - together with 239 source and destination IP-addresses (i.e. IP-addresses of 240 Initiator and Peer) - to match responses with requests. 242 Length 244 The Length field is two octets and indicates the length (in 245 octets) of the EAPoIP message including the Code, Identifier, 246 Length and Data fields. 248 Data 250 The Data field is zero or more octets. The Code field determines 251 the format of the Data field. 253 The Data field of Request and Response messages consists of an 254 additional Type field of 1 octet followed by Type-Data: 256 0 1 2 3 257 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 259 EAP over UDP February 2002 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Code | Identifier | Length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type | Type-Data ... 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 267 Type (Request/Response messages) 269 This Type field of Request/Response messages indicates which 270 authentication method is carried in Type-Data. 272 Type-Data 274 The Type-Data field is zero or more octets and carries 275 information associated with the authentication method. The Type 276 field determines the format of the Type-Data field. 278 4.2 Types for Request/Response messages 280 EAPoUDP reuses some selected PPP EAP methods. However, PPP EAP 281 methods cannot blindly be ported into EAPoUDP without taking 282 security threats into account. On multi-access links, PPP EAP 283 methods that are vulnerable to attacks (including eavesdropping, 284 address spoofing, replay attacks and man-in-the-middle attacks), 285 MUST NOT be used with EAPoUDP. 287 EAPoUDP will explicitly specify which PPP EAP methods to be used, 288 and assign a type value to the selected method. Other PPP EAP 289 methods MUST NOT be used with EAPoUDP. 291 The following EAPoUDP Types are supported in EAPoUDP: 293 Type 295 1 Identity 296 2 Notification 297 3 NAK 298 4 MD-5 Challenge for Re-Authentication 299 TBD Selected method for Initial Authentication 300 TBD Selected method for Disconnect-Notification 302 Other Types MUST NOT be used. 304 To ensure correct and secure operation in a multi-access 305 environment, EAPoUDP imposes additional requirements on the 306 operation of selected PPP EAP methods. Next sub-section summarizes 307 the additional requirements imposed on the MD-5 Challenge method 308 selected for EAPoUDP re-authentication. 310 4.3 MD-5 Challenge for Re-Authentication 312 EAP over UDP February 2002 314 4.3.1 MD-5 Challenge/Response format 316 This document proposes to reuse the PPP EAP MD-5 Challenge/Response 317 authentication method for EAPoUDP re-authentication ([2], [3]). 318 However, we have modified the Type-Data format of challenges and 319 responses to incorporate an optional Device Identifier. The content 320 of the Type-Data field is summarized below. 322 0 1 2 3 323 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Value-Length | Value ... 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 327 | Name-Length | Name ... 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 329 | DI-Length | Device Identifier of Peer ... 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 332 Value-Length 334 This is the length, in octets, of the Value field, which MUST be 335 at least one octet. 337 Value 339 The Value field contains a challenge in Request messages, and a 340 calculated MD-5 hash (Section 4.3.2) in Response messages. 342 Name-Length 344 This is the length, in octets, of the Name field, which SHOULD be 345 at least one octet. 347 Name 349 The Name field contains the Network Access Identifier (NAI) of 350 the sender of the message. A request message, for example, would 351 contain a NAI of the Initiator, and a response message would 352 contain a NAI of the Peer. This field MAY contain a temporary 353 NAI, which MAY have been derived during Initial Authentication. 355 DI-Length 357 This is the length, in octets, of the Device Identifier field. If 358 a Device Identifier is not present in the message, the value is 359 set to zero. 361 Device Identifier 363 This field contains a Device Identifier of the Peer. The 364 Initiator MAY include a Device Identifier in a challenge request 365 to confirm that the IP (or MAC) source addresses of packets 367 EAP over UDP February 2002 369 received from the Peer is correct. The Initiator incorporates the 370 address(es) into the Device Identifier, generates a random 371 challenge, and sends the challenge request message to the Peer. 372 The Peer MUST copy the Device Identifier field from the Challenge 373 message into the same field of the response message. (Later 374 versions of this document MAY open for more extensive 375 negotiations of Device Identifier values.) The Peer MUST validate 376 that the information in the Device Identifier is correct. The 377 Peer MUST NOT return a valid Response message if the information 378 is not correct. 380 The format of the Device Identifier will be specified in a follow-on 381 document. 383 4.3.2 MD-5 Hash Calculation 385 To ensure correct and secure operation in a multi-access 386 environment, EAPoUDP imposes requirements on how the MD-5 hash is 387 calculated: 389 The MD-5 hash MUST be calculated over a stream of octets in 390 sequence consisting of the Network Access Identifier (NAI) of 391 Peer, followed by (concatenated with) Device Identifier of Peer 392 (if present), followed by (concatenated with) the Identifier 393 octet, followed by (concatenated with) the session key for re- 394 authentication, and followed by (concatenated with) the Challenge 395 Value. The Device Identifier is copied from the Device Identifier 396 field in the MD-5 Response message. 398 Since the MD-5 hash is calculated over the NAI of the Peer, it will 399 protect against reflection attacks, even when Initiator and Peer use 400 the same session key for re-authentication in both directions. In 401 comparison, the original PPP EAP MD-5 hash is only calculated over 402 the Identifier, session key, and Challenge, and requires different 403 session keys in each direction. 405 An Initiator can protect against address spoofing attacks of a 406 Peer's IP-address (or MAC-address) by sending a challenge to the 407 Peer with the Peer's addresses incorporated into the Device 408 Identifier field. The Peer confirms the validity of the addresses by 409 returning the hash calculated over both challenge and device 410 identifier. 412 4.3.3 Validation of Device Identifier of a Peer 414 The Initial Authentication method sets up a cache consisting of the 415 other party's identifier, session keys and IP-address (and/or MAC 416 address). Upon receiving an EAPoUDP packet, a PAA or PaC checks the 417 source address, and consults the cache to find the sender's identity 418 and session keys. 420 EAP over UDP February 2002 422 However, the selected Initial Authentication method may not be 423 capable of ensuring that the addresses in the cache are correct, and 424 have not been subject to a IP-spoofing attack by a malicious Man-In- 425 The-Middle (MITM). In that case, the Initial Authentication MAY be 426 followed by Re-authentication where the IP- (and/or MAC-) 427 address(es) are incorporated in the Device Identifier. Thus, the re- 428 authentication method can be used as a means to verify the 429 correctness of addresses in the cache. After one successful re- 430 authentication, PAA can safely grant PaC access to the domain. 432 5 EAPoUDP authentication schemes 434 5.1 Starting the authentication session 436 The specification of EAPoUDP should determine the ways in which 437 Initial Authentication (I-A) can be started. There are a number of 438 possibilities, and the following three sub-sections describe some 439 alternatives. 441 Without loss of generality, we assume in the following discussion 442 that the EAPoUDP I-A method is carried out with PAA as the 443 Initiator. 445 5.1.1 Alternative 1: I-A triggered by the access network 447 The following diagram shows a model, but not details, describing the 448 message exchange where the access network triggers PAA to start 449 Initial Authentication: 451 PaC AP/AR/DHCP/DAD/etc. PAA 452 | | | 453 | | | 454 | | 1a) A trigger | 455 | |----------------->| 456 | | (PaC IP-address) | 457 | | 458 | | 459 | 1b) Identity Request | 460 |<------------------------------------| 461 | 1c) Idenity Response (PaC-ID) | 462 |------------------------------------>| 463 | | 464 | | 465 | 2a) Initial-Auth.: First Request | 466 |<------------------------------------| 468 In this alternative, PAA should be co-located with the entity that 469 sends the trigger, e.g. with the Access Router or DHCP server. 471 The messages are described as follows: 473 EAP over UDP February 2002 475 PaC Discovery: 477 1a) Trigger 479 Initially, PAA receives a trigger indicating the arrival of a 480 new and un-authenticated PaC. The trigger may come from DHCP 481 (e.g. the DHCP server sends a signal to PAA after having 482 assigned an IP-address to a new PaC), or from another protocol 483 entity. The trigger SHOULD provide PAA with the IP-address of 484 the PaC. 486 1b) Identity Request 488 PAA sends an EAPoUDP Identity Request to the given IP-address 489 of the PaC to find out the identity of the PaC. 491 1c) Identity Response 493 PaC returns its identity in an EAPoUDP Identity Response. 495 Initial Authentication: 497 2a) After having obtained PaC's identity, the PAA starts Initial 498 Authentication (Section 5.2). 500 5.1.2 Alternative 2: I-A triggered by unsolicited Identity Response 502 The following diagram shows a model describing the message exchange 503 where the I-A is triggered by a PaC. After having discovered a PAA, 504 the PaC sends it an unsolicited Identity Request, which triggers the 505 PAA to start Initial Authentication: 507 PaC AR/DHCP server PAA 508 | | | 509 | | | 510 |1a) PAA Discovery | | 511 |<---------------->| | 512 | | | 513 | | 514 | | 515 |1b) (Unsolicited) Identity Response | 516 |------------------------------------>| 517 | | 518 | | 519 | 2a) Initial-Auth.: First Request | 520 |<------------------------------------| 522 The messages are described as follows: 524 1a) PAA discovery [1]: 526 EAP over UDP February 2002 528 A PaC discovers the IP-address and identity of a PAA (e.g. in a 529 DHCP option). PAA Discovery mechanisms are proposed and detailed 530 in [1]. 532 1b) (Unsolicited) Identity Response: 534 If the client can positively determine that it has to 535 authenticate, e.g. through successful PAA discovery, it MAY send 536 an unsolicited Identity Response to the PAA, containing the PaC's 537 Identifier. The PaC is free to pick the Identifier octet value. 538 The client MUST NOT send an unsolicited Identity Response if it 539 has already received an Identity Request. (The same method has 540 been proposed in [7].) 542 Initial Authentication: 544 2a) The unsolicited Identity Request triggers the PAA to start 545 Initial Authentication (Section 5.2). 547 5.1.3 Alternative 3: I-A triggered by anycasted PAA discovery 549 The following diagram shows the message exchange where a PaC uses 550 anycast to discover PAA. This triggers PAA to start Initial 551 Authentication: 553 PaC PAA 554 | | 555 | | 556 | | 557 | 1a) (Anycasted) Identity Request | 558 |------------------------------------>| 559 | 1b) (Unicasted) Identity Response | 560 |<------------------------------------| 561 | | 562 | 1c) Identity Request | 563 |<------------------------------------| 564 | 1d) Identity Response (PaC-ID) | 565 |------------------------------------>| 566 | | 567 | | 568 | 2a) Initial-Auth.: First Request | 569 |<------------------------------------| 571 The anycasted Identity Request triggers PAA to discover PaC's 572 Identity (message 1c and 1d), before starting Initial Authentication 573 (Section 5.2). 575 5.2 Initial Authentication 577 PAA is assumed to be the Initiator of Initial Authentication. 579 EAP over UDP February 2002 581 PaC PAA 582 | | 583 | 2a) Initial-Auth.: First Request | 584 |<------------------------------------| 585 | | 586 | Possible additional Requests and | +--------+ 587 | Responses: | |Local | 588 |------------------------------------>|lookup credent.| storage| 589 |<------------------------------------|-------------->| or | 590 |------------------------------------>|return credent.|AAA- | 591 |<------------------------------------|<--------------| infra- | 592 | | | struct.| 593 | | +--------+ 594 | 2n) Initial-Auth.: Last Response | 595 |------------------------------------>| 596 | | 598 The messages are described as follows: 600 2a) The PAA initiates the Initial Authentication (I-A) by sending 601 an I-A-Request to the PaC. 603 The I-A method eventually selected by PANA WG may call for 604 additional Request/Response exchanges. 606 2n) PaC returns the last I-A-Response. 608 For Initial Authentication, PAA MAY use a local storage, a back-end 609 AAA infrastructure, a Certificate Authority or some other kind of 610 Trusted Third Party (TTP) to verify credentials of a PaC, and to 611 obtain credentials that can be verified by the PaC. The actual 612 process for obtaining and verifying credentials is out of scope for 613 the EAPoUDP specification. 615 EAPoUDP Success and Failure messages, which parallel those of PPP 616 EAP ([2], [3]), have been omitted here for simplicity. 618 5.3 Re-authentication 620 A PAA or PaC MAY re-authenticate the other party at any time after 621 Initial Authentication. 623 Initiator Peer 624 (PAA/PaC) (PaC/PAA) 625 | | 626 | 3a) Re-authentication Challenge | 627 |------------------------------------>| 628 | | 629 | 3b) Re-authentication Response | 630 |<------------------------------------| 631 | | 633 EAP over UDP February 2002 635 PAA MAY act as an Initiator when re-authenticating PaC as a Peer, or 636 PaC MAY act as an Initiator when re-authenticating the PAA as a 637 Peer. 639 5.4 Disconnect 641 A PAA or PaC MAY terminate the authentication relationship by 642 sending a Disconnect Notification to the other party any time after 643 Initial Authentication. 645 Initiator Peer 646 (PAA/PaC) (PaC/PAA) 647 | | 648 | 5) Disconnect Notification | 649 |------------------------------------>| 650 | | 652 One way of ensuring the integrity of a Disconnect Notification is to 653 require the Initial Authentication method generate a separate 654 Disconnect One-time Password (D-OTP) to integrity-protect the 655 Disconnect Notification message. 657 5.5 Back-end communication 659 There are a number of different ways that a PAA may interact with 660 the back-end for authentication to verify credentials of PaCs and to 661 obtain credentials that can be used by PaC to authenticate PAA. The 662 examples above provide one possible scenario: 664 PaC PAA 665 | | +--------+ 666 | EAPoUDP msg. | |Local | 667 |------------->|lookup credentials & verifiers | storage| 668 | |------------------------------>| or | 669 | |return credentials & verifiers |AAA- | 670 | |<------------------------------| infra- | 671 | EAPoUDP msg. | | struct.| 672 |<-------------| +--------+ 673 | | 675 Another scenario may call for the use of PAA as a pass-through as 676 follows: 678 PaC PAA 679 | | 680 | EAPoUDP msg. | +--------+ 681 |------------->| Forwarded EAPoUDP message | | 682 | |---------------------------->| Auth.- | 683 | | Returned EAPoUDP message | | 684 | |<----------------------------| server | 685 | EAPoUDP msg. | (+ master session keys) | | 687 EAP over UDP February 2002 689 |<-------------| +--------+ 690 | | 692 There might be other possible scenarios. This issue is 693 implementation dependent and is out of scope for EAPoUDP. 695 6 Further work 697 6.1 Selection of remaining methods 699 PANA WG MUST select the specific methods used for Initial 700 Authentication and Disconnect Notification. Both EAP AKA [7] and EAP 701 SRP-SHA1 [8] are methods that may be considered for Initial 702 Authentication. 704 Algorithms to derive session keys from Initial Authentication should 705 also be specified. EAP-independent key-derivation algorithms are 706 under development [9]. 708 6.2 Retransmission and timeout mechanisms 710 The EAPoUDP protocol may require specific retransmission and timeout 711 mechanisms being used as default for all messages. Specific (i.e. 712 non-default) time-out and re-transmission mechanisms MAY be 713 specified for selected EAPoUDP message types where user input (e.g. 714 a password) is expected. 716 7 Security Considerations 718 EAPoUDP reuses existing EAP methods, but the multi-access, multi-hop 719 environment it MAY operate in raises additional security threats. 720 The final EAPoUDP specification MUST therefore further ensure that 721 each EAPoUDP method can be used securely in this environment [10]. 723 IANA Considerations 725 IANA need to assign a UDP port number for EAPoUDP. 727 Acknowledgements 729 ... 731 References 733 EAP over UDP February 2002 735 [1] Engelstad, P., "Discovery Mechanism for PANA Authentication 736 Agents (PAA-discovery)", , January 2002, Work in Progress. 739 [2] Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication 740 Protocol", RFC 2284, March 1998. 742 [3] Blunk, L., Vollbrecht, J., and Aboba, B., "Extensible 743 Authentication Protocol (EAP)", (RFC2284bis), November 2001, Work in Progress. 746 [4] Aboba, B., Beadles, M. "The Network Access Identifier", RFC 2486, 747 January 1999. 749 [5] Narten, T., and Draves, R., "Privacy Extensions for Stateless 750 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 752 [6] Tsirtis, G., "EAP over ICMP", , January 2002, Work in Progress. 755 [7] Arkko, J., Haverinen, H., "EAP AKA Authentication", , November 2001, Work in Progress. 758 [8] Carlson, J., Aboba, B., Haverinen, H.,"EAP SRP-SHA1 759 Authentication Protocol", , 760 July 2001, Work in Progress. 762 [9] Aboba, B., Simon, D. "The EAP Keying Problem", , February 2002, Work in Progress. 765 [10] Yegin (ed.) et al., "Protocol for Carrying Authentication for 766 Network Access (PANA) Requirements and Terminology", , February 2002, Work in Progress. 769 Author's Address 771 Paal E. Engelstad 772 Telenor R&D (California) 773 399 Sherman Ave. Suite #12 774 Palo Alto, CA 94306, USA 776 Tel.: + 1-650- 714 7537 777 e-mail: paal@telenorisv.com