idnits 2.17.1 draft-ietf-aaa-eap-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1734. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1711. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1724. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 17, 2004) is 7099 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) == Missing Reference: 'EAP-Master-Session-Key' is mentioned on line 255, but not defined ** Obsolete normative reference: RFC 3588 (ref. 'BASE') (Obsoleted by RFC 6733) == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-03 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-14 -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Eronen, Ed. 2 Internet-Draft Nokia 3 Expires: May 18, 2005 T. Hiller 4 Lucent Technologies 5 G. Zorn 6 Cisco Systems 7 November 17, 2004 9 Diameter Extensible Authentication Protocol (EAP) Application 10 draft-ietf-aaa-eap-10.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 18, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 The Extensible Authentication Protocol (EAP) provides a standard 46 mechanism for support of various authentication methods. This 47 document defines the Command-Codes and AVPs necessary to carry EAP 48 packets between a Network Access Server (NAS) and a back-end 49 authentication server. 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC2119]. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Extensible Authentication Protocol Support in Diameter . . . . 4 61 2.1 Advertising application support . . . . . . . . . . . . . 4 62 2.2 Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 63 2.3 Sessions and NASREQ interaction . . . . . . . . . . . . . 7 64 2.3.1 Scenario 1: Direct connection . . . . . . . . . . . . 8 65 2.3.2 Scenario 2: Direct connection with redirects . . . . . 9 66 2.3.3 Scenario 3: Direct EAP, authorization via agents . . . 10 67 2.3.4 Scenario 4: Proxy agents . . . . . . . . . . . . . . . 11 68 2.4 Invalid packets . . . . . . . . . . . . . . . . . . . . . 11 69 2.5 Retransmission . . . . . . . . . . . . . . . . . . . . . . 12 70 2.6 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 13 71 2.7 Accounting . . . . . . . . . . . . . . . . . . . . . . . . 13 72 2.8 Usage guidelines . . . . . . . . . . . . . . . . . . . . . 13 73 2.8.1 User-Name AVP . . . . . . . . . . . . . . . . . . . . 13 74 2.8.2 Conflicting AVPs . . . . . . . . . . . . . . . . . . . 14 75 2.8.3 Displayable messages . . . . . . . . . . . . . . . . . 14 76 2.8.4 Role reversal . . . . . . . . . . . . . . . . . . . . 15 77 2.8.5 Identifier space . . . . . . . . . . . . . . . . . . . 15 78 3. Command-Codes . . . . . . . . . . . . . . . . . . . . . . . . 16 79 3.1 Diameter-EAP-Request (DER) Command . . . . . . . . . . . . 16 80 3.2 Diameter-EAP-Answer (DEA) Command . . . . . . . . . . . . 17 81 4. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 19 82 4.1 New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 4.1.1 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . 19 84 4.1.2 EAP-Reissued-Payload AVP . . . . . . . . . . . . . . . 20 85 4.1.3 EAP-Master-Session-Key AVP . . . . . . . . . . . . . . 20 86 4.1.4 EAP-Key-Name AVP . . . . . . . . . . . . . . . . . . . 20 87 4.1.5 Accounting-EAP-Auth-Method AVP . . . . . . . . . . . . 20 88 5. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 20 89 5.1 EAP Command AVP Table . . . . . . . . . . . . . . . . . . 21 90 5.2 Accounting AVP Table . . . . . . . . . . . . . . . . . . . 22 91 6. RADIUS/Diameter interactions . . . . . . . . . . . . . . . . . 23 92 6.1 RADIUS Request forwarded as Diameter Request . . . . . . . 23 93 6.2 Diameter Request forwarded as RADIUS Request . . . . . . . 24 94 6.3 Accounting Requests . . . . . . . . . . . . . . . . . . . 25 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 97 8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 8.2 AVP editing . . . . . . . . . . . . . . . . . . . . . . . 27 99 8.3 Negotiation attacks . . . . . . . . . . . . . . . . . . . 28 100 8.4 Session key distribution . . . . . . . . . . . . . . . . . 29 101 8.5 Privacy issues . . . . . . . . . . . . . . . . . . . . . . 29 102 8.6 Note about EAP and impersonation . . . . . . . . . . . . . 30 103 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 105 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 31 106 10.2 Informative References . . . . . . . . . . . . . . . . . . . 31 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32 108 A. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 33 109 Intellectual Property and Copyright Statements . . . . . . . . 39 111 1. Introduction 113 The Extensible Authentication Protocol (EAP), defined in [EAP], is an 114 authentication framework which supports multiple authentication 115 mechanisms. EAP may be used on dedicated links as well as switched 116 circuits, and wired as well as wireless links. 118 To date, EAP has been implemented with hosts and routers that connect 119 via switched circuits or dial-up lines using PPP [RFC1661], IEEE 802 120 wired switches [IEEE-802.1X], and IEEE 802.11 wireless access points 121 [IEEE-802.11i]. EAP has also been adopted for IPsec remote access in 122 IKEv2 [IKEv2]. 124 This document specifies the Diameter EAP application that carries EAP 125 packets between a Network Access Server (NAS) working as an EAP 126 Authenticator and a back-end authentication server. The Diameter EAP 127 application is based on the Diameter Network Access Server 128 Application [NASREQ] and is intended for similar environments as 129 NASREQ. 131 In Diameter EAP application, authentication occurs between the EAP 132 client and its home Diameter server. This end-to-end authentication 133 reduces the possibility for fraudulent authentication, such as replay 134 and man-in-the-middle attacks. End-to-end authentication also 135 provides a possibility for mutual authentication, which is not 136 possible with PAP and CHAP in a roaming PPP environment. 138 The Diameter EAP application relies heavily on [NASREQ], and in 139 earlier drafts was part of the Diameter NASREQ application. It can 140 also be used in conjunction with NASREQ, selecting the application 141 based on the used authentication mechanism (EAP or PAP/CHAP). The 142 Diameter EAP application defines new Command-Codes and new AVPs 143 (Attribute-Value Pairs), and can work together with RADIUS EAP 144 support [RFC3579]. 146 2. Extensible Authentication Protocol Support in Diameter 148 2.1 Advertising application support 150 Diameter nodes conforming to this specification MAY advertise support 151 by including the value of TBD-BY-IANA in the Auth-Application-Id AVP 152 of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer 153 command [BASE]. 155 If the NAS receives a response with the Result-Code set to 156 DIAMETER_APPLICATION_UNSUPPORTED [BASE], it is an indication that the 157 Diameter server in the home realm does not support EAP. If possible, 158 the access device MAY attempt to negotiate another authentication 159 protocol, such as PAP or CHAP. An access device SHOULD be cautious 160 when determining whether a less secure authentication protocol will 161 be used, since this could be a result of a downgrade attack (see 162 Section 8.3). 164 2.2 Protocol Overview 166 The EAP conversation between the authenticating peer and the access 167 device begins with the initiation of EAP within a link layer, such as 168 PPP [RFC1661] or IEEE 802.11i [IEEE-802.11i]. Once EAP has been 169 initiated, the access device will typically send to the Diameter 170 server a Diameter-EAP-Request message with an empty EAP-Payload AVP, 171 signifying an EAP-Start. 173 If the Diameter home server is willing to do EAP authentication, it 174 responds with a Diameter-EAP-Answer message containing an EAP-Payload 175 AVP that includes an encapsulated EAP packet. The Result-Code AVP in 176 the message will be set to DIAMETER_MULTI_ROUND_AUTH, signifying that 177 a subsequent request is expected. The EAP payload is forwarded by 178 the access device to the EAP client. This is illustrated in the 179 diagram below. 181 User NAS Server 182 | | | 183 | (initiate EAP) | | 184 |<------------------------------>| | 185 | | Diameter-EAP-Request | 186 | | EAP-Payload(EAP Start) | 187 | |------------------------------->| 188 | | | 189 | | Diameter-EAP-Answer | 190 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 191 | | EAP-Payload(EAP Request #1) | 192 | |<-------------------------------| 193 | EAP Request #1 | | 194 |<-------------------------------| | 195 : : : 196 : ...continues... : 198 The initial Diameter-EAP-Answer in a multi-round exchange normally 199 includes an EAP-Request/Identity, requesting the EAP client to 200 identify itself. Upon receipt of the EAP client's EAP-Response, the 201 access device will then issue a second Diameter-EAP-Request message, 202 with the client's EAP payload encapsulated within the EAP-Payload 203 AVP. 205 A preferred approach is for the access device to issue the 206 EAP-Request/Identity message to the EAP client, and forward the 207 EAP-Response/Identity packet, encapsulated within the EAP-Payload 208 AVP, as a Diameter-EAP-Request to the Diameter server (see the 209 diagram below). This alternative reduces the number of Diameter 210 message round trips. When the EAP-Request/Identity message is issued 211 by the access device, it SHOULD interpret the EAP-Response/Identity 212 packet returned by the authenticating peer, and copy its value to a 213 User-Name AVP in Diameter-EAP-Request. This is useful in roaming 214 environments, since the Destination-Realm is needed for routing 215 purposes. Note that this alternative cannot be universally employed, 216 as there are circumstances where a user's identity is not needed 217 (such as when authorization occurs based on a calling or called phone 218 number). 220 User NAS Server 221 | | | 222 | (initiate EAP) | | 223 |<------------------------------>| | 224 | | | 225 | EAP Request(Identity) | | 226 |<-------------------------------| | 227 | | | 228 | EAP Response(Identity) | | 229 |------------------------------->| | 230 | | Diameter-EAP-Request | 231 | | EAP-Payload(EAP Response) | 232 | |------------------------------->| 233 : : : 234 : ...continues... : 236 The conversation continues until the Diameter server sends a 237 Diameter-EAP-Answer with a Result-Code AVP indicating success or 238 failure, and an optional EAP-Payload. The Result-Code AVP is used by 239 the access device to determine whether service is to be provided to 240 the EAP client. The access device MUST NOT rely on the contents of 241 the optional EAP-Payload to determine whether service is to be 242 provided. 244 : ...continued... : 245 : : : 246 | EAP Response #N | | 247 |------------------------------->| | 248 | | Diameter-EAP-Request | 249 | | EAP-Payload(EAP Response #N) | 250 | |------------------------------->| 251 | | | 252 | | Diameter-EAP-Answer | 253 | | Result-Code=DIAMETER_SUCCESS | 254 | | EAP-Payload(EAP Success) | 255 | | [EAP-Master-Session-Key] | 256 | | (authorization AVPs) | 257 | |<-------------------------------| 258 | | | 259 | EAP Success | | 260 |<-------------------------------| | 262 If authorization was requested, a Diameter-EAP-Answer with 263 Result-Code set to DIAMETER_SUCCESS SHOULD also include the 264 appropriate authorization AVPs required for the service requested 265 (see Section 5 and [NASREQ]). In some cases, the home server may not 266 be able to provide all necessary authorization AVPs; in this case, a 267 separate authorization step MAY be used as described in Section 268 2.3.3. Diameter-EAP-Answer messages whose Result-Code AVP is set to 269 DIAMETER_MULTI_ROUND_AUTH MAY include authorization AVPs. 271 A Diameter-EAP-Answer with successful Result-Code MAY also include an 272 EAP-Master-Session-Key AVP that contains keying material for 273 protecting the communication between the user and the NAS. Exactly 274 how this keying material is used depends on the link layer in 275 question, and is beyond the scope of this document. 277 A home Diameter server MAY request EAP re-authentication by issuing 278 the Re-Auth-Request [BASE] message to the Diameter client. 280 Should an EAP authentication session be interrupted due to a home 281 server failure, the session MAY be directed to an alternate server, 282 but the authentication session will have to be restarted from the 283 beginning. 285 2.3 Sessions and NASREQ interaction 287 The previous section introduced the basic protocol between the NAS 288 and the home server. Since the Diameter-EAP-Answer message may 289 include a Master Session Key (MSK) for protecting the communication 290 between the user and the NAS, care must be taken to ensure that this 291 key does not fall into wrong hands. 293 Basic Diameter security mechanisms (IPsec and TLS) protect Diameter 294 messages hop-by-hop. Since there are currently no end-to-end 295 (NAS-to-home server) security mechanisms defined for Diameter, this 296 section describes some possible scenarios how the messages could be 297 transported protected using these hop-by-hop mechanisms. 299 The list of scenarios is not intended to be exhaustive, and it is 300 possible to combine them. For instance, the first proxy agent after 301 the NAS could use redirects as in scenario 2 to bypass any additional 302 proxy agents. 304 2.3.1 Scenario 1: Direct connection 306 The simplest case is when the NAS contacts the home server directly. 307 All the authorization AVPs are delivered by the home server, as is 308 EAP keying material. 310 NAS home server 311 | | 312 | Diameter-EAP-Request | 313 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 314 | EAP-Payload(EAP Start) | 315 |---------------------------------------------------------------->| 316 | | 317 | Diameter-EAP-Answer | 318 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 319 | EAP-Payload(EAP Request) | 320 |<----------------------------------------------------------------| 321 | | 322 : ...more EAP Request/Response pairs... : 323 | | 324 | Diameter-EAP-Request | 325 | EAP-Payload(EAP Response) | 326 |---------------------------------------------------------------->| 327 | | 328 | Diameter-EAP-Answer | 329 | Result-Code=DIAMETER_SUCCESS | 330 | EAP-Payload(EAP Success) | 331 | EAP-Master-Session-Key | 332 | (authorization AVPs) | 333 |<----------------------------------------------------------------| 335 This scenario is the most likely to be used in small networks, or in 336 cases where Diameter agents are not needed to provide routing or 337 additional authorization AVPs. 339 2.3.2 Scenario 2: Direct connection with redirects 341 In this scenario the NAS uses a redirect agent to locate the home 342 server, and the rest of the session proceeds as before. 344 NAS Local redirect agent Home server 345 | | | 346 | Diameter-EAP-Request | | 347 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 348 | EAP-Payload(EAP Start) | | 349 |------------------------------->| | 350 | | | 351 | Diameter-EAP-Answer | 352 | Redirect-Host=homeserver.example.com | 353 | Redirect-Host-Usage=REALM_AND_APPLICATION | 354 |<-------------------------------| | 355 | : | 356 | Diameter-EAP-Request : | 357 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 358 | EAP-Payload(EAP Start) : | 359 |---------------------------------------------------------------->| 360 | : | 361 : ...rest of the session continues as in first case... : 362 : : : 364 The advantage of this scenario is that knowledge of realms and home 365 servers is centralized to a redirect agent, and it is not necessary 366 to modify the NAS configuration when, e.g., a new roaming agreement 367 is done. 369 2.3.3 Scenario 3: Direct EAP, authorization via agents 371 In this scenario the EAP authentication is done directly with the 372 home server (with Auth-Request-Type set to AUTHENTICATE_ONLY), and 373 the authorization AVPs are retrieved from the local proxy agents. 374 This scenario is intended for environments where the home server 375 cannot provide all the necessary authorization AVPs to the NAS. 377 NAS Local proxy agent Home server 378 | : | 379 | Diameter-EAP-Request : | 380 | Auth-Request-Type=AUTHENTICATE_ONLY | 381 | EAP-Payload(EAP Start) : | 382 |---------------------------------------------------------------->| 383 | : | 384 | : Diameter-EAP-Answer | 385 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 386 | : EAP-Payload(EAP Request) | 387 |<----------------------------------------------------------------| 388 | : | 389 : ...more EAP Request/Response pairs... : 390 | : | 391 | Diameter-EAP-Request : | 392 | EAP-Payload(EAP Response) : | 393 |---------------------------------------------------------------->| 394 | : | 395 | : Diameter-EAP-Answer | 396 | : Result-Code=DIAMETER_SUCCESS | 397 | : EAP-Payload(EAP Success) | 398 | : EAP-Master-Session-Key | 399 | : (authorization AVPs) | 400 |<----------------------------------------------------------------| 401 | | | 402 | AA-Request | | 403 | Auth-Request-Type=AUTHORIZE_ONLY | 404 | (some AVPs from first session) | | 405 |------------------------------->| | 406 | | | 407 | AA-Answer | | 408 | Result-Code=DIAMETER_SUCCESS | | 409 | (authorization AVPs) | | 410 |<-------------------------------| | 412 The NASREQ application is used here for authorization because the 413 realm-specific routing table supports routing based on application, 414 but not on Diameter commands. 416 2.3.4 Scenario 4: Proxy agents 418 Same as scenario 1, but through proxies. Note that in this case the 419 proxies can see the EAP session keys, so this is not suitable for 420 environments where proxies cannot be trusted for this. 422 NAS Local proxy/relay agent Home server 423 | | | 424 | Diameter-EAP-Request | | 425 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 426 | EAP-Payload(EAP Start) | | 427 |------------------------------->|------------------------------->| 428 | | | 429 | | Diameter-EAP-Answer | 430 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 431 | | EAP-Payload(EAP Request) | 432 |<-------------------------------|<-------------------------------| 433 | : | 434 : ...more EAP Request/Response pairs... : 435 | : | 436 | Diameter-EAP-Request | | 437 | EAP-Payload(EAP Response) | | 438 |------------------------------->|------------------------------->| 439 | | | 440 | | Diameter-EAP-Answer | 441 | | Result-Code=DIAMETER_SUCCESS | 442 | | EAP-Payload(EAP Success) | 443 | | EAP-Master-Session-Key | 444 | | (authorization AVPs) | 445 |<-------------------------------|<-------------------------------| 447 2.4 Invalid packets 449 While acting as a pass-through, the NAS MUST validate the EAP header 450 fields (Code, Identifier, Length) prior to forwarding an EAP packet 451 to or from the Diameter server. On receiving an EAP packet from the 452 peer, the NAS checks the Code (Code 2=Response) and Length fields, 453 and matches the Identifier value against the current Identifier, 454 supplied by the Diameter server in the most recently validated EAP 455 Request. On receiving an EAP packet from the Diameter server 456 (encapsulated within a Diameter-EAP-Answer), the NAS checks the Code 457 (Code 1=Request) and Length fields, then updates the current 458 Identifier value. Pending EAP Responses that do not match the 459 current Identifier value are silently discarded by the NAS. 461 Since EAP method fields (Type, Type-Data) are typically not validated 462 by a NAS operating as a pass-through, despite these checks it is 463 possible for a NAS to forward an invalid EAP packet to or from the 464 Diameter server. 466 A Diameter server receiving an EAP-Payload AVP it does not understand 467 SHOULD make the determination of whether the error is fatal or 468 non-fatal based on the EAP Type. A Diameter server determining that 469 a fatal error has occurred MUST send a Diameter-EAP-Answer with a 470 failure Result-Code and an EAP-Payload AVP encapsulating an EAP 471 Failure packet. A Diameter server determining that a non-fatal error 472 has occurred MUST send a Diameter-EAP-Answer with 473 DIAMETER_MULTI_ROUND_AUTH Result-Code, but no EAP-Payload AVP. To 474 simplify RADIUS translation, this message MUST also include an 475 EAP-Reissued-Payload AVP encapsulating the previous EAP Request sent 476 by the server. 478 When receiving a Diameter-EAP-Answer without an EAP-Payload AVP (and 479 DIAMETER_MULTI_ROUND_AUTH Result-Code), the NAS SHOULD discard the 480 EAP-Response packet most recently transmitted to the Diameter server 481 and check whether additional EAP Response packets have been received 482 matching the current Identifier value. If so, a new EAP Response 483 packet, if available, MUST be sent to the Diameter server within an 484 Diameter-EAP-Request. If no EAP Response packet is available, then 485 the previous EAP Request is resent to the peer, and the 486 retransmission timer is reset. 488 In order to provide protection against Denial of Service (DoS) 489 attacks, it is advisable for the NAS to allocate a finite buffer for 490 EAP packets received from the peer, and to discard packets according 491 to an appropriate policy once that buffer has been exceeded. Also, 492 the Diameter server is advised to permit only a modest number of 493 invalid EAP packets within a single session, prior to terminating the 494 session with DIAMETER_AUTHENTICATION_REJECTED Result-Code. By 495 default a value of 5 invalid EAP packets is recommended. 497 2.5 Retransmission 499 As noted in [EAP], if an EAP packet is lost in transit between the 500 authenticating peer and the NAS (or vice versa), the NAS will 501 retransmit. 503 It may be necessary to adjust retransmission strategies and 504 authentication timeouts in certain cases. For example, when a token 505 card is used, additional time may be required to allow the user to 506 find the card and enter the token. Since the NAS will typically not 507 have knowledge of the required parameters, these need to be provided 508 by the Diameter server. 510 If a Multi-Round-Time-Out AVP [BASE] is present in an 511 Diameter-EAP-Answer message that also contains an EAP-Payload AVP, 512 that value is used to set the EAP retransmission timer for that EAP 513 Request, and that Request alone. 515 2.6 Fragmentation 517 Using the EAP-Payload AVP, it is possible for the Diameter server to 518 encapsulate an EAP packet that is larger than the MTU on the link 519 between the NAS and the peer. Since it is not possible for the 520 Diameter server to use MTU discovery to ascertain the link MTU, a 521 Framed-MTU AVP may be included in a Diameter-EAP-Request message so 522 as to provide the Diameter server with this information. 524 A Diameter server having received a Framed-MTU AVP in a 525 Diameter-EAP-Request message MUST NOT send any subsequent packet in 526 this EAP conversation containing EAP-Payload AVP whose length exceeds 527 the length specified by the Framed-MTU value, taking the link type 528 (specified by the NAS-Port-Type AVP) into account. For example, as 529 noted in [RFC3580] Section 3.10, for a NAS-Port-Type value of IEEE 530 802.11, the RADIUS server may send an EAP packet as large as 531 Framed-MTU minus four (4) octets, taking into account the additional 532 overhead for the IEEE 802.1X Version (1 octet), Type (1 octet) and 533 Body Length (2 octets) fields. 535 2.7 Accounting 537 When a user is authenticated using EAP, the NAS MAY include an 538 Accounting-Auth-Method AVP [NASREQ] with value 5 (EAP) in 539 Accounting-Request messages. This document specifies one additional 540 AVP for accounting messages: one or more Accounting-EAP-Auth-Method 541 AVPs (see Section 4.1.5) MAY be included in Accounting-Request 542 messages to indicate the EAP method(s) used to authenticate the user. 544 If the NAS has authenticated the user with a locally implemented EAP 545 method, it knows the method used and SHOULD include it in an 546 Accounting-EAP-Auth-Method AVP. 548 If the authentication was done using Diameter-EAP-Request/Answer 549 messages, the Diameter server SHOULD include one or more 550 Accounting-EAP-Auth-Method AVPs in Diameter-EAP-Answer packets with a 551 successful result code. In this case, the NAS SHOULD include these 552 AVPs in Accounting-Request messages. 554 2.8 Usage guidelines 556 2.8.1 User-Name AVP 558 Unless the access device interprets the EAP-Response/Identity packet 559 returned by the authenticating peer, it will not have access to the 560 user's identity. Furthermore, some EAP methods support identity 561 protection where the user's real identity is not included in 562 EAP-Response/Identity. Therefore, the Diameter Server SHOULD return 563 the user's identity by inserting a User-Name AVP to 564 Diameter-EAP-Answer messages that have a Result-Code of 565 DIAMETER_SUCCESS. A separate billing identifier or pseudonym MAY be 566 used for privacy reasons (see Section 8.5). If the user's identity 567 is not available to the NAS, the Session-Id AVP MAY be used for 568 accounting and billing; however operationally this could be very 569 difficult to manage. 571 2.8.2 Conflicting AVPs 573 A Diameter-EAP-Answer message containing an EAP-Payload of type 574 EAP-Success or EAP-Failure MUST NOT have the Result-Code AVP set to 575 DIAMETER_MULTI_ROUND_AUTH. 577 Some lower layers assume that the authorization decision is made by 578 the EAP server, and thus the peer considers EAP Success as an 579 indication that access was granted. In this case, the Result-Code 580 SHOULD match the contained EAP packet: a successful Result-Code for 581 EAP-Success, and a failure Result-Code for EAP-Failure. If the 582 encapsulated EAP packet does not match the result implied by the 583 Result-Code AVP, the combination is likely to cause confusion, 584 because the NAS and peer will arrive at different conclusions as to 585 the outcome of the authentication. For example, if the NAS receives 586 a failure Result-Code with an encapsulated EAP Success, it will not 587 grant access to the peer. However, on receiving the EAP Success, the 588 peer will be lead to believe that access was granted. 590 This situation can be difficult to avoid when Diameter proxy agents 591 make authorization decisions (that is, proxies can change the 592 Result-Code AVP sent by the home server). Since the responsibility 593 for avoiding conflicts lies with the Diameter server, the NAS MUST 594 NOT "manufacture" EAP result packets in order to correct 595 contradictory messages that it receives. This behavior, originally 596 mandated within [IEEE-802.1X], is now deprecated. 598 2.8.3 Displayable messages 600 The Reply-Message AVP [NASREQ] contains text which may be displayed 601 to the user. Note that the NAS does not necessarily have any 602 facility for actually sending these messages to the user. In any 603 case, the NAS MUST NOT manufacture any EAP packets (such as 604 EAP-Request/Notification) from Reply-Message AVPs. 606 2.8.4 Role reversal 608 Some environments where EAP is used, such as PPP, support 609 peer-to-peer operation. That is, both parties act as authenticators 610 and authenticatees at the same time, in two simultaneous and 611 independent EAP conversations. 613 This specification is intended for communication between EAP 614 (passthrough) authenticator and backend authentication server. A 615 Diameter client MUST NOT send a Diameter-EAP-Request encapsulating an 616 EAP Request packet, and a Diameter server receiving such packet MUST 617 respond with a failure Result-Code. 619 2.8.5 Identifier space 621 In EAP, each session has its own unique Identifier space. Diameter 622 server implementations MUST be able to distinguish between EAP 623 packets with the same Identifier existing within distinct EAP 624 sessions, originating on the same NAS. This is done by using the 625 Session-Id AVP. 627 If a Diameter NAS is in the middle of a multi-round authentication 628 exchange, and it detects that the EAP session between the client and 629 the NAS has been terminated for some reason, it MUST select a new 630 Diameter Session-Id for any subsequent EAP sessions. This is 631 necessary in order to distinguish a restarted EAP authentication 632 process from the continuation of an ongoing process (by the same user 633 on the same NAS and port). 635 In RADIUS, the same functionality can be achieved through the 636 inclusion or omission of the State attribute. Translation rules in 637 [NASREQ] ensure that an Access-Request without the State attribute 638 maps to a a new Diameter Session-Id AVP value. Furthermore, a 639 translation agent will always include a State attribute in 640 Access-Challenge messages, making sure that the State attribute is 641 available for a RADIUS NAS. 643 3. Command-Codes 645 This section defines new Command-Code values that MUST be supported 646 by all Diameter implementations conforming to this specification. 647 The following commands are defined in this section: 649 Command-Name Abbrev. Code Reference 650 -------------------------------------------------------- 651 Diameter-EAP-Request DER 268 3.1 652 Diameter-EAP-Answer DEA 268 3.2 654 When the NASREQ AA-Request (AAR) or AA-Answer (AAA) commands are used 655 for AUTHORIZE_ONLY messages in conjunction with EAP (see Section 656 2.3.3), an Application Identifier value of 1 (NASREQ) is used, and 657 the commands follow the rules and ABNF defined in [NASREQ]. 659 When the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), 660 Session-Termination-Request (STR), Session-Termination-Answer (STA), 661 Abort-Session-Request (ASR), Abort-Session-Answer (ASA), 662 Accounting-Request (ACR), and Accounting-Answer (ACA) commands are 663 used together with the Diameter EAP application, they follow the 664 rules in [NASREQ] and [BASE]. The accounting commands use 665 Application Identifier value of 3 (Diameter Base Accounting); the 666 others use 0 (Diameter Common Messages). 668 3.1 Diameter-EAP-Request (DER) Command 670 The Diameter-EAP-Request (DER) command, indicated by the Command-Code 671 field set to 268 and the 'R' bit set in the Command Flags field, is 672 sent by a Diameter client to a Diameter server and conveys an 673 EAP-Response from the EAP client. The Diameter-EAP-Request MUST 674 contain one EAP-Payload AVP, which contains the actual EAP payload. 675 An EAP-Payload AVP with no data MAY be sent to the Diameter server to 676 initiate an EAP authentication session. 678 The DER message MAY be the result of a multi-round authentication 679 exchange, which occurs when the DEA is received with the Result-Code 680 AVP set to DIAMETER_MULTI_ROUND_AUTH [BASE]. A subsequent DER 681 message MUST include any State AVPs [NASREQ] that were present in the 682 DEA. For re-authentication, it is recommended that the Identity 683 request be skipped in order to reduce the number of authentication 684 round trips. This is only possible when the user's identity is 685 already known by the home Diameter server. 687 Message format 689 ::= < Diameter Header: 268, REQ, PXY > 690 < Session-Id > 691 { Auth-Application-Id } 692 { Origin-Host } 693 { Origin-Realm } 694 { Destination-Realm } 695 { Auth-Request-Type } 696 [ Destination-Host ] 697 [ NAS-Identifier ] 698 [ NAS-IP-Address ] 699 [ NAS-IPv6-Address ] 700 [ NAS-Port ] 701 [ NAS-Port-Id ] 702 [ NAS-Port-Type ] 703 [ Origin-State-Id ] 704 [ Port-Limit ] 705 [ User-Name ] 706 { EAP-Payload } 707 [ EAP-Key-Name ] 708 [ Service-Type ] 709 [ State ] 710 [ Authorization-Lifetime ] 711 [ Auth-Grace-Period ] 712 [ Auth-Session-State ] 713 [ Callback-Number ] 714 [ Called-Station-Id ] 715 [ Calling-Station-Id ] 716 [ Originating-Line-Info ] 717 [ Connect-Info ] 718 * [ Framed-Compression ] 719 [ Framed-Interface-Id ] 720 [ Framed-IP-Address ] 721 * [ Framed-IPv6-Prefix ] 722 [ Framed-IP-Netmask ] 723 [ Framed-MTU ] 724 [ Framed-Protocol ] 725 * [ Tunneling ] 726 * [ Proxy-Info ] 727 * [ Route-Record ] 728 * [ AVP ] 730 3.2 Diameter-EAP-Answer (DEA) Command 732 The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code 733 field set to 268 and the 'R' bit cleared in the Command Flags field, 734 is sent by the Diameter server to the client for one of the following 735 reasons: 737 1. The message is part of a multi-round authentication exchange, and 738 the server is expecting a subsequent Diameter-EAP-Request. This 739 is indicated by setting the Result-Code to 740 DIAMETER_MULTI_ROUND_AUTH, and MAY include zero or more State 741 AVPs. 743 2. The EAP client has been successfully authenticated and 744 authorized, in which case the message MUST include the 745 Result-Code AVP indicating success, and SHOULD include an 746 EAP-Payload of type EAP-Success. This event MUST cause the 747 access device to provide service to the EAP client. 749 3. The EAP client has not been successfully authenticated and/or 750 authorized, and the Result-Code AVP is set to indicate failure. 751 This message SHOULD include an EAP-Payload, but this AVP is not 752 used to determine whether service is to be provided. 754 If the message from the Diameter client included a request for 755 authorization, a successful response MUST include the authorization 756 AVPs that are relevant to the service being provided. 758 Message format 760 ::= < Diameter Header: 268, PXY > 761 < Session-Id > 762 { Auth-Application-Id } 763 { Auth-Request-Type } 764 { Result-Code } 765 { Origin-Host } 766 { Origin-Realm } 767 [ User-Name ] 768 [ EAP-Payload ] 769 [ EAP-Reissued-Payload ] 770 [ EAP-Master-Session-Key ] 771 [ EAP-Key-Name ] 772 [ Multi-Round-Time-Out ] 773 [ Accounting-EAP-Auth-Method ] 774 [ Service-Type ] 775 * [ Class ] 776 * [ Configuration-Token ] 777 [ Acct-Interim-Interval ] 778 [ Error-Message ] 779 [ Error-Reporting-Host ] 780 * [ Failed-AVP ] 781 [ Idle-Timeout ] 782 [ Authorization-Lifetime ] 783 [ Auth-Grace-Period ] 785 [ Auth-Session-State ] 786 [ Re-Auth-Request-Type ] 787 [ Session-Timeout ] 788 [ State ] 789 * [ Reply-Message ] 790 [ Origin-State-Id ] 791 * [ Filter-Id ] 792 [ Port-Limit ] 793 [ Callback-Id ] 794 [ Callback-Number ] 795 [ Framed-Appletalk-Link ] 796 * [ Framed-Appletalk-Network ] 797 [ Framed-Appletalk-Zone ] 798 * [ Framed-Compression ] 799 [ Framed-Interface-Id ] 800 [ Framed-IP-Address ] 801 * [ Framed-IPv6-Prefix ] 802 [ Framed-IPv6-Pool ] 803 * [ Framed-IPv6-Route ] 804 [ Framed-IP-Netmask ] 805 * [ Framed-Route ] 806 [ Framed-Pool ] 807 [ Framed-IPX-Network ] 808 [ Framed-MTU ] 809 [ Framed-Protocol ] 810 [ Framed-Routing ] 811 * [ NAS-Filter-Rule ] 812 * [ QoS-Filter-Rule ] 813 * [ Tunneling ] 814 * [ Redirect-Host ] 815 [ Redirect-Host-Usage ] 816 [ Redirect-Max-Cache-Time ] 817 * [ Proxy-Info ] 818 * [ AVP ] 820 4. Attribute-Value Pairs 822 This section both defines new AVPs, unique to the EAP Diameter 823 application and describes the usage of AVPs defined elsewhere if that 824 usage in the EAP application is noteworthy. 826 4.1 New AVPs 828 4.1.1 EAP-Payload AVP 830 The EAP-Payload AVP (AVP Code TBD-BY-IANA) is of type OctetString and 831 is used to encapsulate the actual EAP packet that is being exchanged 832 between the EAP client and the home Diameter server. 834 4.1.2 EAP-Reissued-Payload AVP 836 The EAP-Reissued-Payload AVP (AVP Code TBD-BY-IANA) is of type 837 OctetString. The use of this AVP is described in Section 2.4. 839 4.1.3 EAP-Master-Session-Key AVP 841 The EAP-Master-Session-Key AVP (AVP Code TBD-BY-IANA) is of type 842 OctetString. It contains keying material for protecting the 843 communications between the user and the NAS. Exactly how this keying 844 material is used depends on the link layer in question, and is beyond 845 the scope of this document. 847 4.1.4 EAP-Key-Name AVP 849 The EAP-Key-Name AVP (AVP Code TBD-BY-IANA) is of type OctetString. 850 It contains an opaque key identifier (name) generated by the EAP 851 method. Exactly how this name is used depends on the link layer in 852 question, and is beyond the scope of this document (see [EAPKey] for 853 more discussion). 855 It should be noted that not all link layers use this name, and 856 currently most EAP methods do not generate it. Since the NAS 857 operates in pass-through mode, it cannot know the Key-Name before 858 receiving it from the AAA server. As a result, a Key-Name AVP sent 859 in a Diameter-EAP-Request MUST NOT contain any data. A home Diameter 860 server receiving a Diameter-EAP-Request with a Key-Name AVP with 861 non-empty data MUST silently discard the AVP. In addition, the home 862 Diameter server SHOULD include this AVP in Diameter-EAP-Response only 863 if an empty EAP-Key-Name AVP was present in Diameter-EAP-Request. 865 4.1.5 Accounting-EAP-Auth-Method AVP 867 The Accounting-EAP-Auth-Method AVP (AVP Code TBD-BY-IANA) is of type 868 Unsigned64. In case of expanded types [EAP, Section 5.7], this AVP 869 contains the value ((Vendor-Id * 2^32) + Vendor-Type). 871 The use of this AVP is described in Section 2.7. 873 5. AVP Occurrence Tables 875 The following tables use these symbols: 877 0 The AVP MUST NOT be present in the message 878 0+ Zero or more instances of the AVP MAY be present in the 879 message 880 0-1 Zero or one instance of the AVP MAY be present in the 881 message 882 1 One instance of the AVP MUST be present in the message 884 Note that AVPs that can only be present within a Grouped AVP are not 885 represented in these tables. 887 5.1 EAP Command AVP Table 889 The following table lists the AVPs that may be present in the DER and 890 DEA Commands, defined in this document; however, the AVPs listed are 891 defined both here and in [NASREQ]. 893 +---------------+ 894 | Command-Code | 895 |-------+-------+ 896 Attribute Name | DER | DEA | 897 ------------------------------------|-------+-------| 898 Accounting-EAP-Auth-Method | 0 | 0+ | 899 Acct-Interim-Interval [BASE] | 0 | 0-1 | 900 Auth-Application-Id [BASE] | 1 | 1 | 901 Auth-Grace-Period [BASE] | 0-1 | 0-1 | 902 Auth-Request-Type [BASE] | 1 | 1 | 903 Auth-Session-State [BASE] | 0-1 | 0-1 | 904 Authorization-Lifetime [BASE] | 0-1 | 0-1 | 905 Callback-Id [NASREQ] | 0 | 0-1 | 906 Callback-Number [NASREQ] | 0-1 | 0-1 | 907 Called-Station-Id [NASREQ] | 0-1 | 0 | 908 Calling-Station-Id [NASREQ] | 0-1 | 0 | 909 Class [BASE] | 0 | 0+ | 910 Configuration-Token [NASREQ] | 0 | 0+ | 911 Connect-Info [NASREQ] | 0-1 | 0 | 912 Destination-Host [BASE] | 0-1 | 0 | 913 Destination-Realm [BASE] | 1 | 0 | 914 EAP-Master-Session-Key | 0 | 0-1 | 915 EAP-Key-Name | 0-1 | 0-1 | 916 EAP-Payload | 1 | 0-1 | 917 EAP-Reissued-Payload | 0 | 0-1 | 918 Error-Message [BASE] | 0 | 0-1 | 919 Error-Reporting-Host [BASE] | 0 | 0-1 | 920 Failed-AVP [BASE] | 0 | 0+ | 921 Filter-Id [NASREQ] | 0 | 0+ | 922 Framed-Appletalk-Link [NASREQ] | 0 | 0-1 | 923 Framed-Appletalk-Network [NASREQ] | 0 | 0+ | 924 Framed-Appletalk-Zone [NASREQ] | 0 | 0-1 | 925 Framed-Compression [NASREQ] | 0+ | 0+ | 926 Framed-Interface-Id [NASREQ] | 0-1 | 0-1 | 927 Framed-IP-Address [NASREQ] | 0-1 | 0-1 | 928 Framed-IP-Netmask [NASREQ] | 0-1 | 0-1 | 929 Framed-IPv6-Prefix [NASREQ] | 0+ | 0+ | 930 Framed-IPv6-Pool [NASREQ] | 0 | 0-1 | 931 Framed-IPv6-Route [NASREQ] | 0 | 0+ | 932 Framed-IPX-Network [NASREQ] | 0 | 0-1 | 933 Framed-MTU [NASREQ] | 0-1 | 0-1 | 934 Framed-Pool [NASREQ] | 0 | 0-1 | 935 Framed-Protocol [NASREQ] | 0-1 | 0-1 | 936 Framed-Route [NASREQ] | 0 | 0+ | 937 Framed-Routing [NASREQ] | 0 | 0-1 | 938 Idle-Timeout [NASREQ] | 0 | 0-1 | 939 Multi-Round-Time-Out [BASE] | 0 | 0-1 | 940 NAS-Filter-Rule [NASREQ] | 0 | 0+ | 941 NAS-Identifier [NASREQ] | 0-1 | 0 | 942 NAS-IP-Address [NASREQ] | 0-1 | 0 | 943 NAS-IPv6-Address [NASREQ] | 0-1 | 0 | 944 NAS-Port [NASREQ] | 0-1 | 0 | 945 NAS-Port-Id [NASREQ] | 0-1 | 0 | 946 NAS-Port-Type [NASREQ] | 0-1 | 0 | 947 Originating-Line-Info [NASREQ] | 0-1 | 0 | 948 Origin-Host [BASE] | 1 | 1 | 949 Origin-Realm [BASE] | 1 | 1 | 950 Origin-State-Id [BASE] | 0-1 | 0-1 | 951 Port-Limit [NASREQ] | 0-1 | 0-1 | 952 Proxy-Info [BASE] | 0+ | 0+ | 953 QoS-Filter-Rule [NASREQ] | 0 | 0+ | 954 Re-Auth-Request-Type [BASE] | 0 | 0-1 | 955 Redirect-Host [BASE] | 0 | 0+ | 956 Redirect-Host-Usage [BASE] | 0 | 0-1 | 957 Redirect-Max-Cache-Time [BASE] | 0 | 0-1 | 958 Reply-Message [NASREQ] | 0 | 0+ | 959 Result-Code [BASE] | 0 | 1 | 960 Route-Record [BASE] | 0+ | 0+ | 961 Service-Type [NASREQ] | 0-1 | 0-1 | 962 Session-Id [BASE] | 1 | 1 | 963 Session-Timeout [BASE] | 0 | 0-1 | 964 State [NASREQ] | 0-1 | 0-1 | 965 Tunneling [NASREQ] | 0+ | 0+ | 966 User-Name [BASE] | 0-1 | 0-1 | 968 5.2 Accounting AVP Table 970 The table in this section is used to represent which AVPs defined in 971 this document are to be present in the Accounting messages, defined 972 in [BASE]. 974 +-----------+ 975 | Command | 976 | Code | 977 |-----+-----+ 978 Attribute Name | ACR | ACA | 979 ---------------------------------------|-----+-----+ 980 Accounting-EAP-Auth-Method | 0+ | 0 | 982 6. RADIUS/Diameter interactions 984 Section 9 of [NASREQ] describes basic guidelines for translation 985 agents that translate between RADIUS and Diameter protocols. These 986 guidelines SHOULD be followed for Diameter EAP application as well, 987 with some additional guidelines given in this section. Note that 988 this document does not restrict implementations from creating 989 additional methods, as long as the translation function does not 990 violate the RADIUS or the Diameter protocols. 992 6.1 RADIUS Request forwarded as Diameter Request 994 RADIUS Access-Request to Diameter-EAP-Request: 996 o RADIUS EAP-Message attribute(s) are translated to a Diameter 997 EAP-Payload AVP. If multiple RADIUS EAP-Message attributes are 998 present, they are concatenated and translated to a single Diameter 999 EAP-Payload AVP. 1001 o An empty RADIUS EAP-Message attribute (with length 2) signifies 1002 EAP-Start, and it is translated to an empty EAP-Payload AVP. 1004 Diameter-EAP-Answer to RADIUS Access-Accept/Reject/Challenge: 1006 o Diameter EAP-Payload AVP is translated to RADIUS EAP-Message 1007 attribute(s). If necessary, the value is split into multiple 1008 RADIUS EAP-Message attributes. 1010 o Diameter EAP-Reissued-Payload AVP is translated to a message that 1011 contains RADIUS EAP-Message attribute(s), and a RADIUS Error-Cause 1012 attribute [RFC3576] with value 202 (decimal), "Invalid EAP Packet 1013 (Ignored)" [RFC3579]. 1015 o As described in [NASREQ], if the Result-Code AVP set to 1016 DIAMETER_MULTI_ROUND_AUTH and the Multi-Round-Time-Out AVP is 1017 present, it is translated to the RADIUS Session-Timeout attribute. 1019 o Diameter EAP-Master-Session-Key AVP can be translated to the 1020 vendor-specific RADIUS MS-MPPE-Recv-Key and MS-MPPE-Send-Key 1021 attributes [RFC2548]. The first up to 32 octets of the key is 1022 stored into MS-MPPE-Recv-Key, and the next up to 32 octets (if 1023 present) are stored into MS-MPPE-Send-Key. The encryption of this 1024 attribute is described in [RFC2548]. 1026 o Diameter Accounting-EAP-Auth-Method AVPs, if present, are 1027 discarded. 1029 6.2 Diameter Request forwarded as RADIUS Request 1031 Diameter-EAP-Request to RADIUS Access-Request: 1033 o The Diameter EAP-Payload AVP is translated to RADIUS EAP-Message 1034 attribute(s). 1036 o An empty Diameter EAP-Payload AVP signifies EAP-Start, and it is 1037 translated to an empty RADIUS EAP-Message attribute. 1039 o The type (or expanded type) field from the EAP-Payload AVP can be 1040 saved either in a local state table, or encoded in a RADIUS 1041 Proxy-State attribute. This information is needed to construct an 1042 Accounting-EAP-Auth-Method AVP for the answer message (see below). 1044 RADIUS Access-Accept/Reject/Challenge to Diameter-EAP-Answer: 1046 o If the RADIUS Access-Challenge message does not contain an 1047 Error-Cause attribute [RFC3576] with value 202 (decimal), "Invalid 1048 EAP Packet (Ignored)" [RFC3579], any RADIUS EAP-Message attributes 1049 are translated to a Diameter EAP-Payload AVP, concatenating them 1050 if multiple attributes are present. 1052 o If the Error-Cause attribute with value 202 is present, any RADIUS 1053 EAP-Message attributes are translated to a Diameter 1054 EAP-Reissued-Payload AVP, concatenating them if multiple 1055 attributes are present. 1057 o As described in [NASREQ], if the Session-Timeout attribute is 1058 present in a RADIUS Access-Challenge message, it is translated to 1059 the Diameter Multi-Round-Time-Out AVP. 1061 o If the vendor-specific RADIUS MS-MPPE-Recv-Key and/or 1062 MS-MPPE-Send-Key attributes [RFC2548] are present, they can be 1063 translated to a Diameter EAP-Master-Session-Key AVP. The 1064 attributes have to be decrypted before conversion, and the Salt, 1065 Key-Length and Padding sub-fields are discarded. The Key 1066 sub-fields are concatenated (MS-MPPE-Recv-Key first, 1067 MS-MPPE-Send-Key next), and the concatenated value is stored into 1068 a Diameter EAP-Master-Session-Key AVP. 1070 o If the Diameter-EAP-Answer will have a successful result code, the 1071 saved state (see above) can be used to construct an 1072 Accounting-EAP-Auth-Method AVP. 1074 6.3 Accounting Requests 1076 In Accounting-Requests, the vendor-specific RADIUS MS-Acct-EAP-Type 1077 attribute [RFC2548] can be translated to a Diameter 1078 Accounting-EAP-Auth-Method AVP, and vice versa. 1080 When translating from Diameter to RADIUS, note that the 1081 MS-Acct-EAP-Type attribute does not support expanded EAP types. Type 1082 values greater than 255 should be translated to type 254. 1084 7. IANA Considerations 1086 This document does not create any new namespaces to be maintained by 1087 IANA, but it requires new values in namespaces that have been defined 1088 in the Diameter Base protocol and RADIUS specifications. 1090 o This document defines one new Diameter command (in Section 3) 1091 whose Command Code is to be allocated from the Command Code 1092 namespace defined in [BASE]. The value of 268 is suggested. 1094 o This document defines four new AVPs whose AVP Codes are to be 1095 allocated from the AVP Code namespace defined in [BASE]. These 1096 AVPs are defined in Section 4.1.1 (EAP-Payload), Section 4.1.2 1097 (EAP-Reissued-Payload), Section 4.1.3 (EAP-Master-Session-Key), 1098 and Section 4.1.5 (Accounting-EAP-Auth-Method). 1100 o This document defines one new AVP (attribute) whose AVP Code 1101 (Attribute Type) is to be allocated from the Attribute Type 1102 namespace defined in [RFC2865] and [RFC3575]. This AVP 1103 (EAP-Key-Name) is defined in Section 4.1.4. 1105 o This document defines one new Diameter application (in Section 1106 2.1) whose Application ID is to be allocated from the Application 1107 Identifier namespace defined in [BASE]. 1109 8. Security Considerations 1110 8.1 Overview 1112 Diameter peer-to-peer connections can be protected with IPsec or TLS. 1113 These mechanisms are believed to provide sufficient protection under 1114 the normal Internet threat model--that is, assuming the authorized 1115 nodes engaging in the protocol have not been compromised, but the 1116 attacker has complete control over the communication channels between 1117 them. This includes eavesdropping, message modification, insertion, 1118 man-in-the-middle and replay attacks. The details and related 1119 security considerations are discussed in [BASE]. 1121 In addition to authentication provided by IPsec or TLS, authorization 1122 is also required. Authorization here means the act of determining if 1123 a Diameter message received from an authenticated Diameter peer 1124 should be accepted (and not authorization of users requesting network 1125 access from a NAS). In other words, when a Diameter server receives 1126 a Diameter-EAP-Request, it has to decide if the client is authorized 1127 to act as a NAS for the specific user, service type, and so on. 1128 Correspondingly, when a NAS contacts a server to send a 1129 Diameter-EAP-Request, it has to determine whether the server is 1130 authorized to act as home server for the realm in question. 1132 Authorization can involve local Access Control Lists (ACLs), 1133 information contained in certificates, or some other means. See 1134 [BASE] for more discussion and related security considerations. Note 1135 that authorization issues are particularly relevant when Diameter 1136 redirects are used. While redirection reduces the number of nodes 1137 which have access to the contents of Diameter messages, a compromised 1138 Diameter agent may not supply the right home server's address. If 1139 the Diameter client is unable to tell whether this particular server 1140 is authorized to act as the home server for this particular user, the 1141 security of the communications rests on the redirect agent. 1143 The hop-by-hop security mechanisms (IPsec and TLS) combined with 1144 proper authorization provide good protection against "outside" 1145 attackers, except for denial-of-service attacks. The remaining part 1146 of this section deals with attacks by nodes that have been properly 1147 authorized (to function as a NAS, Diameter agent, or Diameter server) 1148 but abuse their authorization or have been compromised. In general, 1149 it is not possible to completely protect against attacks by 1150 compromised nodes, but this section offers some advice that can be 1151 used to limit the extent of the damage. 1153 Attacks involving eavesdropping or modification of EAP messages are 1154 beyond the scope of these document. See [EAP] for discussion of 1155 these security considerations (including method negotiation, 1156 dictionary attacks, and privacy issues). While these attacks can be 1157 carried out by an attacker between the client and the NAS, 1158 compromised NASes and Diameter agents are naturally also in a good 1159 position to modify and eavesdrop the EAP messages. 1161 Similarly, attacks involving whatever link layer protocol is used 1162 between the client and the NAS, such as PPP or IEEE 802.11, are 1163 beyond the scope of this document. 1165 8.2 AVP editing 1167 Diameter agents can modify, insert, and delete AVPs. Diameter agents 1168 are usually meant to modify AVPs, and the protocol in general cannot 1169 distinguish well-intentioned and malicious modifications (see 1170 [RFC2607] for more discussion). Similarly, a compromised NAS or 1171 server can naturally include different set of AVPs than expected. 1173 The question is thus "what can an attacker who compromises an 1174 authorized NAS, agent, or server do using Diameter EAP messages?" 1175 Some of the consequences are rather obvious--for instance, a Diameter 1176 agent can give access to unauthorized users by changing the 1177 Result-Code to DIAMETER_SUCCESS. Other consequences are less 1178 obvious, and are discussed below (authentication method negotiation 1179 attacks are discussed in the next section). 1181 By including suitable AVPs in an AA-Answer/Diameter-EAP-Answer 1182 messages an attacker (depending on implementation and configuration 1183 details) may be able to: 1185 o Give unauthorized users access, or deny access to authorized users 1186 (Result-Code). 1188 o Give attacker a login session to a host otherwise protected by 1189 firewalls, or redirect an authorized user's login session to a 1190 host controlled by the attacker (Login-Host). 1192 o Route an authorized user's traffic through a host controlled by 1193 the attacker (various tunneling AVPs). 1195 o Redirect an authorized user's DNS requests to a malicious DNS 1196 server (various vendor-specific AVPs). 1198 o Modify routing tables at the NAS and thus redirect packets 1199 destined for someone else (Framed-Route, Framed-Routing). 1201 o Remove packet filters and other restrictions for user (Filter, 1202 Callback, various vendor-specific AVPs). 1204 o Cause the NAS to call some number, possibly expensive toll number 1205 controlled by the attacker (callback AVPs) 1207 o Execute Command Line Interface (CLI) commands on the NAS (various 1208 vendor-specific attributes). 1210 By modifying an AA-Request/Diameter-EAP-Request, an attacker may be 1211 able to: 1213 o Change NAS-Identifier/NAS-Port/Origin-Host (or something) so that 1214 a valid user appears to be accessing the network from a different 1215 NAS than in reality. 1217 o Modify Calling-Station-ID (either to hide the true value, gain 1218 access, or frame someone else). 1220 o Modify password change messages (some vendor-specific attributes) 1222 o Modify usage information in accounting messages. 1224 o Modify contents of Class and State AVPs. 1226 Some of these attacks can be prevented if the NAS or server can be 1227 configured not to accept some particular AVPs, or accepting them only 1228 from some nodes. 1230 8.3 Negotiation attacks 1232 This section deals with attacks where the NAS, any Diameter agents, 1233 or Diameter server attempts to cause the authenticating user to 1234 choose some authentication method other than EAP, such as PAP or CHAP 1235 (negotiation attacks within EAP are discussed in [EAP], Section 7.8). 1237 The vulnerability can be mitigated via implementation of 1238 per-connection policy on the part of the authenticating peer, and 1239 per-user policy on the part of the Diameter server. For the 1240 authenticating peer, authentication policy should be set on a 1241 per-connection basis. 1243 With per-connection policy, an authenticating peer will only attempt 1244 to negotiate EAP for a session in which EAP support is expected. As 1245 a result, there is a presumption that an authenticating peer 1246 selecting EAP requires that level of security. If it cannot be 1247 provided, it is likely that there is some kind of misconfiguration, 1248 or even that the authenticating peer is contacting the wrong server. 1249 In this case, the authenticating peer simply disconnects. 1251 Similarly, with a per-user policy, the home server will not accept 1252 authentication methods other than EAP for users for which EAP support 1253 is expected. 1255 For a NAS, it may not be possible to determine whether a peer is 1256 required to authenticate with EAP until the peer's identity is known. 1257 For example, for shared-uses NASes it is possible for one reseller to 1258 implement EAP while another does not. Alternatively, some peer might 1259 be authenticated locally by the NAS while other peers are 1260 authenticated via Diameter. In such cases, if any peers of the NAS 1261 MUST do EAP, then the NAS MUST attempt to negotiate EAP for every 1262 session. This avoids forcing a peer to support more than one 1263 authentication type, which could weaken security. 1265 8.4 Session key distribution 1267 Since there are currently no end-to-end (NAS-to-home server) security 1268 mechanisms specified for Diameter, any agents that process 1269 Diameter-EAP-Answer messages can see the contents of the 1270 EAP-Master-Session-Key AVP. For this reason, this specification 1271 strongly recommends avoiding Diameter agents when they cannot be 1272 trusted to keep the keys secret. 1274 In environments where agents are present, several factors should be 1275 considered when deciding whether the agents that are authorized (and 1276 considered "trustworthy enough") to grant access to users and specify 1277 various authorization and tunneling AVPs are also "trustworthy 1278 enough" to handle the session keys. These factors include (but are 1279 not limited to) the type of access provided (e.g., public Internet or 1280 corporate internet), security level of the agents, and the 1281 possibilities for attacking user's traffic after it has been 1282 decrypted by the NAS. 1284 Note that the keys communicated in Diameter messages are usually 1285 short-term session keys (or short-term master keys that are used to 1286 derive session keys). To actually cause any damage, those session 1287 keys must end with some malicious party; that party must be able to 1288 eavesdrop, modify, or insert traffic between the user and the NAS 1289 during the lifetime of those keys (e.g., in 802.11i the attacker must 1290 also eavesdrop the "four-way handshake"); and that eavesdropping or 1291 modification must cause some damage. 1293 8.5 Privacy issues 1295 Diameter messages can contain AVPs that can be used to identify the 1296 user (e.g., User-Name) and approximate location of the user (e.g. 1297 Origin-Host for WLAN access points, Calling-Station-Id for fixed 1298 phone lines). Thus, any Diameter nodes that process the messages may 1299 be able to determine the geographic location of users. 1301 Note that in many cases, the user identity is also sent in clear 1302 inside EAP-Payload AVPs, and it may be possible to eavesdrop this 1303 between the user and the NAS. 1305 This can mitigated somewhat by using EAP methods that provide 1306 identity protection (see [EAP], Section 7.3), and using Session-Id or 1307 pseudonyms for accounting. 1309 8.6 Note about EAP and impersonation 1311 If the EAP method used does not provide mutual authentication, 1312 obviously anyone can impersonate as the network to the user. Even 1313 when EAP mutual authentication is used, it occurs between the user 1314 and the Diameter home server. See [EAPKey] for an extensive 1315 discussion about the details and their implications. 1317 However, one issue is worth pointing out here. As described in 1318 [EAPKey], the current EAP architecture does not allow the home server 1319 to restrict what service parameters or identities (such as SSID or 1320 BSSID in 802.11 wireless LANs) are advertised by the NAS to the 1321 client. That is, a compromised NAS can change its BSSID or SSID, 1322 thus appearing to offer a different service than intended. Even if 1323 these parameters are included in Diameter-EAP-Answer messages, the 1324 NAS can tell different values to the client. 1326 Thus, the possession of the session keys by the NAS proves that the 1327 user is talking to *some* authorized NAS, but a compromised NAS can 1328 lie about its exact identity. See [EAPKey] for discussion how 1329 individual EAP methods can provide authentication of NAS service 1330 parameters and identities. 1332 Note that the usefulness of such authentication may be rather limited 1333 in many environments. For instance, in wireless LANs the user does 1334 not usually securely know the identity (such as BSSID) of the "right" 1335 access point--it is simply picked from a beacon message that has the 1336 correct SSID and good signal strength (something that is easy to 1337 spoof). Thus, simply authenticating the identity may not allow the 1338 user to distinguish the "right" access point from all other ones. 1340 9. Acknowledgements 1342 This Diameter application relies heavily on earlier work on Diameter 1343 NASREQ application [NASREQ] and RADIUS EAP support [RFC3579]. Much 1344 of the material in this specification has been copied from these 1345 documents. 1347 The authors would also like to acknowledge the following people for 1348 their contributions to this document: Bernard Aboba, Jari Arkko, 1349 Julien Bournelle, Pat Calhoun, Henry Haverinen, John Loughney, 1350 Yoshihiro Ohba, and Joseph Salowey. 1352 10. References 1354 10.1 Normative References 1356 [BASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 1357 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1359 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1360 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1361 3748, June 2004. 1363 [NASREQ] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 1364 Network Access Server Application", 1365 draft-ietf-aaa-diameter-nasreq-17 (work in progress), July 1366 2004. 1368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1369 Requirement Levels", BCP 14, RFC 2119, March 1997. 1371 10.2 Informative References 1373 [EAPKey] Aboba, B., Simon, D., Arkko, J., Eronen, P. and H. 1374 Levkowetz, "Extensible Authentication Protocol (EAP) Key 1375 Management Framework", draft-ietf-eap-keying-03 (work in 1376 progress), July 2004. 1378 [IEEE-802.1X] 1379 Institute of Electrical and Electronics Engineers, "Local 1380 and Metropolitan Area Networks: Port-Based Network Access 1381 Control", IEEE Standard 802.1X, September 2001. 1383 [IEEE-802.11i] 1384 Institute of Electrical and Electronics Engineers, "IEEE 1385 Standard for Information technology - Telecommunications 1386 and information exchange between systems - Local and 1387 metropolitan area networks - Specific requirements - Part 1388 11: Wireless Medium Access Control (MAC) and Physical 1389 Layer (PHY) Specifications: Amendment 6: Medium Access 1390 Control (MAC) Security Enhancements", IEEE Standard 1391 802.11i-2004, July 2004. 1393 [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 1394 Protocol", draft-ietf-ipsec-ikev2-14 (work in progress), 1395 June 2004. 1397 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1398 RFC 1661, July 1994. 1400 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1401 RFC 2548, March 1999. 1403 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1404 Implementation in Roaming", RFC 2607, June 1999. 1406 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 1407 "Remote Authentication Dial In User Service (RADIUS)", RFC 1408 2865, June 2000. 1410 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1411 Authentication Dial In User Service)", RFC 3575, July 1412 2003. 1414 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. 1415 Aboba, "Dynamic Authorization Extensions to Remote 1416 Authentication Dial In User Service (RADIUS)", RFC 3576, 1417 July 2003. 1419 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1420 Dial In User Service) Support For Extensible 1421 Authentication Protocol (EAP)", RFC 3579, September 2003. 1423 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 1424 "IEEE 802.1X Remote Authentication Dial In User Service 1425 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 1427 Authors' Addresses 1429 Pasi Eronen (editor) 1430 Nokia Research Center 1431 P.O. Box 407 1432 FIN-00045 Nokia Group 1433 Finland 1435 EMail: pasi.eronen@nokia.com 1437 Tom Hiller 1438 Lucent Technologies 1439 1960 Lucent Lane 1440 Naperville, IL 60566 1441 USA 1443 Phone: +1 630 979 7673 1444 EMail: tom.hiller@lucent.com 1445 Glen Zorn 1446 Cisco Systems 1447 500 108th Avenue N.E., Suite 500 1448 Bellevue, WA 98004 1449 USA 1451 Phone: +1 425 344 8113 1452 EMail: gwz@cisco.com 1454 Appendix A. Changelog 1456 (This section should be removed by the RFC editor.) 1458 Changes from -09 to -10: 1460 o Nits from IESG review: 1462 o Section 2.1: clarification, "bidding down attack" -> "downgrade 1463 attack". 1465 o Section 2.8.2: clarified text about manufacturing messages and 1466 802.1X. 1468 o Section 4.1.4: typo, "Diameter-EAP-Response" -> 1469 "Diameter-EAP-Answer". 1471 o Section 4.1.5: clarified text about expanded types and 1472 Accounting-EAP-Auth-Method AVP. 1474 o Section 8.4: typo, "EAP-Session-Key AVP" -> 1475 "EAP-Master-Session-Key AVP". 1477 o Other minor nits from IESG review: 1479 o Section 1: spelled out NASREQ and AVP when mentioned for the first 1480 time. 1482 o Section 2.3, clarified "(1)" -> "(Code 1=Request)" and "(2)" -> 1483 "(Code 2=Response)". 1485 o Section 2.4: typo, "an a" -> "a". 1487 o Section 2.6, clarified "(1)" -> "(1 octet)" and "(2)" -> "(2 1488 octets)". 1490 o Section 2.7: typo, "more more" -> "or more". 1492 o Section 3: clarified "The following Command Codes are defined..." 1493 -> "The following commands are defined...". 1495 o Section 8.1: removed superflous and slightly confusing words "even 1496 if redirects are used" from the last sentence of the third 1497 paragraph. 1499 o Section 8.1, clarification, "(denial-of-service is, of course, 1500 possible)" -> "except for denial-of-service attacks". 1502 o Section 10.2: IEEE 802.11i is no longer "work in progress". 1504 Changes from -08.a to -09.a: 1506 o Updated ABNFs and AVP occurrence tables to match NASREQ -17 (issue 1507 466): Removed Session-Timeout, Idle-Timeout, Class and Failed-AVP 1508 from DER (and reordered ABNF to match NASREQ). Added Failed-AVP 1509 and QoS-Filter-Rule to DEA. 1511 o Clarified that EAP-Key-Name in DER must be empty (issue 465). 1513 o Updated references: NASREQ to -17, EAPKey to -03, removed unused 1514 reference Archie. 1516 Changes from -07.a to -08.a: 1518 o Use application identifier 0/3 for commands defined in BASE. 1520 o draft-ietf-eap-rfc2284bis is now RFC 3748 (hooray!). 1522 Changes from -06.b to -07.a: 1524 o Clarified how NASREQ commands are used together with Diameter EAP 1525 application. 1527 o Clarified that NASREQ text about RADIUS translation applies here 1528 as well. 1530 o Updated references: NASREQ to -15, IKEv2 to -14. 1532 Changes from -06.a to -06.b: 1534 o Added Section 2.8.5 about identifiers and sessions. 1536 Changes from -05 to -06.a: 1538 o Removed Section 2.8.5 about alternative uses and all references to 1539 it (issues 450 and 461). 1541 o Added EAP-Key-Name AVP (issue 460). 1543 o Editorial updates to IANA considerations section. 1545 o Updated references: IEEE-802.11i to D10.0; added references 1546 RFC2865 and RFC3575. 1548 Changes from -04 to -05: 1550 o Clarified User-Name handling in Section 2.8.1 (issue 455). 1552 o Clarified text about conflicting AVPs in Section 2.8.2 (issue 1553 461). 1555 o Added missing AVPs to ABNF and occurrence tables (issues 450 and 1556 458). 1558 o Typos and editorial changes about NASREQ use (issue 450). 1560 o Changed EAPKey reference to informative. 1562 o Updated references: NASREQ to -14, IKEv2 to -13, RFC2284bis to -09 1563 (renamed to EAP), IEEE-802.11i to D9.0. 1565 o Updated I-D boilerplate. 1567 Version -04.a published as -04. 1569 Changes from -03 to -04.a: 1571 o Removed DIAMETER_LIMITED_SUCCESS case from scenario 3 in Section 1572 2.3.3. The remaining example is better in line with Diameter base 1573 document. 1575 o Use DIAMETER_AUTHENTICATION_REJECTED Result-Code when too many 1576 invalid EAP packets are received (Section 2.4). 1578 o Mention that MS-MPPE-Recv/Send-Key attributes are encrypted. 1580 o Several editorial comments from Glen Zorn (WG mailing list 1581 2004-01-11 and 2004-01-14). 1583 o Updated security considerations based on comments from Jari Arkko 1584 (issue 437, WG mailing list 2003-11-04). 1586 o Updated references: RFC2284bis, EAPKey, IEEE-802.11i, IKEv2. 1588 Version -03.a published as -03. 1590 Changes from -02 to -03.a: 1592 o Updated security considerations section. 1594 o Removed the EAP-MTU attribute (use Framed-MTU instead). 1596 o Clarified text about invalid packets and EAP-Reissued-Payload AVP. 1598 o Added reference to Accounting-Auth-Method AVP to Section 2.7. 1600 o Updated ABNFs and AVP occurrence tables to match NASREQ-13. 1602 o Updated the IANA considerations to reflect the new AAA parameters 1603 registry. Changed EAP-Payload and Accounting-EAP-Auth-Method AVP 1604 codes to "TBD" since they collided with NASREQ codes (issue 429). 1606 o Updated references: DynAuth to RFC3576, RFC2869bis to RFC3579, 1607 RADIUS1X to RFC3580, BASE TO RFC3588, NASREQ to -13, IKEv2 to -11, 1608 2284bis to -06. 1610 Version -02.e published as -02. 1612 Changes from -02.d to -02.e: 1614 o Added a section on accounting, and changed how the 1615 Accounting-EAP-Auth-Method is determined. 1617 o Updates to "authorization" and "impersonating as the network" 1618 security considerations. 1620 Changes from -02.c to -02.d: 1622 o Some clarifications to Introduction section. 1624 o Lots of clarifications and added diagrams in protocol overview 1625 section. Moved non-EAP-supporting servers, User-Name AVP 1626 guidelines, and conflicting messages to separate sections. 1628 o Added a new section about sessions and NASREQ interaction. 1630 o Wrote a note about Reply-Message AVP, and added it back to ABNFs 1631 and occurance tables. 1633 o Added EAP-Reissued-Payload AVP for signalling invalid packets, and 1634 RADIUS translation for this. 1636 o Added EAP-Master-Session-Key AVP for keys, and suggestions for 1637 RADIUS translation. 1639 o Attempted to clarify Framed-MTU RADIUS translation. 1641 o Added a first attempt of security considerations section. 1643 o Updated acknowledgements (please notify me if someone's missing). 1645 Changes from -02.b to -02.c: 1647 o Rephrased abstract and introduction sections. 1649 o A couple of minor changes in Sections 2.1 and 2.2. 1651 o Added text about advertising application support and role 1652 reversal. 1654 o Changed type of Accounting-EAP-Auth-Method AVP from Enumerated to 1655 Unsigned64, and explained how it is determined. 1657 o Removed references to EAP-Master-Session-Key AVP added in -02.b. 1659 o Added Diameter-RADIUS translation of accounting AVPs. 1661 o Added IANA Considerations section. 1663 o References section: Updated RFC2284bis, added IEEE-802.11i and 1664 IKEv2, deleted RFC1510 ad RFC1938. 1666 Changes from -02.a to -02.b: 1668 o Added some text to Introduction section. 1670 o Stole text from 2869bis about invalid packets, retransmissions, 1671 and fragmentation. 1673 o In section 2.1, changed one "MAY" to "could" since it was not used 1674 to describe a requirement. 1676 o Updated ABNF's and AVP occurance tables to match the current 1677 NASREQ-11 document. 1679 o Added EAP-MTU and EAP-Master-Session-Key AVPs. 1681 o Removed description of Configuration-Token, Nas-Port, Nas-Port-Id, 1682 and State AVPs (the text didn't add anything to their description 1683 in NASREQ). 1685 o Added a first attempt of a section describing Diameter-RADIUS 1686 translation. 1688 o Added references RFC2284bis, RFC2548, RFC2869bis, RADIUS1X, and 1689 DynAuth. 1691 Changes from -01 to -02.a: 1693 o New editor. 1695 o Added Changelog appendix. 1697 o Converted source to XML format. This will result in many small 1698 formatting changes in the ASCII version. 1700 o Updated BASE and NASREQ references to current versions. 1702 Intellectual Property Statement 1704 The IETF takes no position regarding the validity or scope of any 1705 Intellectual Property Rights or other rights that might be claimed to 1706 pertain to the implementation or use of the technology described in 1707 this document or the extent to which any license under such rights 1708 might or might not be available; nor does it represent that it has 1709 made any independent effort to identify any such rights. Information 1710 on the procedures with respect to rights in RFC documents can be 1711 found in BCP 78 and BCP 79. 1713 Copies of IPR disclosures made to the IETF Secretariat and any 1714 assurances of licenses to be made available, or the result of an 1715 attempt made to obtain a general license or permission for the use of 1716 such proprietary rights by implementers or users of this 1717 specification can be obtained from the IETF on-line IPR repository at 1718 http://www.ietf.org/ipr. 1720 The IETF invites any interested party to bring to its attention any 1721 copyrights, patents or patent applications, or other proprietary 1722 rights that may cover technology that may be required to implement 1723 this standard. Please address the information to the IETF at 1724 ietf-ipr@ietf.org. 1726 Disclaimer of Validity 1728 This document and the information contained herein are provided on an 1729 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1730 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1731 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1732 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1733 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1734 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1736 Copyright Statement 1738 Copyright (C) The Internet Society (2004). This document is subject 1739 to the rights, licenses and restrictions contained in BCP 78, and 1740 except as set forth therein, the authors retain all their rights. 1742 Acknowledgment 1744 Funding for the RFC Editor function is currently provided by the 1745 Internet Society.