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