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