idnits 2.17.1 draft-ietf-aaa-eap-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 (October 24, 2003) is 7489 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 246, but not defined == Unused Reference: 'Archie' is defined on line 1344, 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 (-22) exists of draft-ietf-eap-keying-00 == Outdated reference: A later version (-17) exists of draft-ietf-aaa-diameter-nasreq-13 == Outdated reference: A later version (-09) exists of draft-ietf-eap-rfc2284bis-06 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-11 -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Eronen, Ed. 3 Internet-Draft Nokia 4 Expires: April 23, 2004 T. Hiller 5 Lucent Technologies 6 G. Zorn 7 Cisco Systems 8 October 24, 2003 10 Diameter Extensible Authentication Protocol (EAP) Application 11 draft-ietf-aaa-eap-03.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 23, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 The Extensible Authentication Protocol (EAP) provides a standard 42 mechanism for support of various authentication methods. This 43 document defines the Command-Codes and AVPs necessary to carry EAP 44 packets between a Network Access Server (NAS) and a back-end 45 authentication server. 47 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 . . . . . . . . . . . . . . . . . . 12 64 2.4 Invalid packets . . . . . . . . . . . . . . . . . . . . . . 12 65 2.5 Retransmission . . . . . . . . . . . . . . . . . . . . . . . 13 66 2.6 Fragmentation . . . . . . . . . . . . . . . . . . . . . . . 14 67 2.7 Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 2.8 Usage guidelines . . . . . . . . . . . . . . . . . . . . . . 14 69 2.8.1 User-Name AVP . . . . . . . . . . . . . . . . . . . . . . . 14 70 2.8.2 Conflicting AVPs . . . . . . . . . . . . . . . . . . . . . . 15 71 2.8.3 Displayable messages . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . . 28 97 8.6 Note about EAP and impersonation . . . . . . . . . . . . . . 29 98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 99 Normative References . . . . . . . . . . . . . . . . . . . . 30 100 Informative References . . . . . . . . . . . . . . . . . . . 30 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 102 A. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . 32 103 Intellectual Property and Copyright Statements . . . . . . . 35 105 1. Introduction 107 The Extensible Authentication Protocol (EAP), defined in 108 [RFC2284bis], is an authentication framework which supports multiple 109 authentication mechanisms. EAP may be used on dedicated links as 110 well as switched circuits, and wired as well as wireless links. 112 To date, EAP has been implemented with hosts and routers that connect 113 via switched circuits or dial-up lines using PPP [RFC1661], IEEE 802 114 wired switches [IEEE-802.1X], and IEEE 802.11 wireless access points 115 [IEEE-802.11i]. EAP has also been adopted for IPsec remote access in 116 IKEv2 [IKEv2]. 118 This document specifies the Diameter EAP application that carries EAP 119 packets between a Network Access Server (NAS) working as an EAP 120 Authenticator and a back-end authentication server. The Diameter EAP 121 application is based on NASREQ and is intended for similar 122 environments as NASREQ. 124 In Diameter EAP application, authentication occurs between the EAP 125 client and its home Diameter server. This end-to-end authentication 126 reduces the possibility for fraudulent authentication, such as replay 127 and man-in-the-middle attacks. End-to-end authentication also 128 provides a possibility for mutual authentication, which is not 129 possible with PAP and CHAP in a roaming PPP environment. 131 Diameter EAP application relies heavily on [NASREQ], and in earlier 132 drafts was part of the Diameter NASREQ application. It can also be 133 used in conjunction with NASREQ, selecting the application based on 134 the used authentication mechanism (EAP or PAP/CHAP). Diameter EAP 135 application defines new Command-Codes and new AVPs, and can work 136 together with RADIUS EAP support [RFC3579]. 138 2. Extensible Authentication Protocol Support in Diameter 140 2.1 Advertising application support 142 Diameter nodes conforming to this specification MAY advertise support 143 by including the value of TBD in the Auth-Application-Id AVP of the 144 Capabilities-Exchange-Request and Capabilities-Exchange-Answer 145 command [BASE]. 147 If the NAS receives a response with the Result-Code set to 148 DIAMETER_APPLICATION_UNSUPPORTED [BASE], it is an indication that the 149 Diameter server in the home realm does not support EAP. If possible, 150 the access device MAY attempt to negotiate another authentication 151 protocol, such as PAP or CHAP. An access device SHOULD be cautious 152 when determining whether a less secure authentication protocol will 153 be used, since this could be a result of a bidding down attack (see 154 Section 8.3). 156 2.2 Protocol Overview 158 The EAP conversation between the authenticating peer and the access 159 device begins with the initiation of EAP within a link layer, such as 160 PPP [RFC1661] or IEEE 802.1X [IEEE-802.1X]. Once EAP has been 161 initiated, the access device will typically send to the Diameter 162 server a Diameter-EAP-Request message with an empty EAP-Payload AVP, 163 signifying an EAP-Start. 165 If the Diameter home server is willing to do EAP authentication, it 166 respons with a Diameter-EAP-Answer message containing an EAP-Payload 167 AVP that includes an encapsulated EAP packet. The Result-Code AVP 168 set to DIAMETER_MULTI_ROUND_AUTH, signifying that a subsequent 169 request is expected. The EAP payload is forwarded by the access 170 device to the EAP client. This is illustrated in the diagram below. 172 User NAS Server 173 | | | 174 | (initiate EAP) | | 175 |<------------------------------>| | 176 | | Diameter-EAP-Request | 177 | | EAP-Payload(EAP Start) | 178 | |------------------------------->| 179 | | | 180 | | Diameter-EAP-Answer | 181 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 182 | | EAP-Payload(EAP Request #1) | 183 | |<-------------------------------| 184 | EAP Request #1 | | 185 |<-------------------------------| | 186 : : : 187 : ...continues... : 189 The initial Diameter-EAP-Answer in a multi-round exchange normally 190 includes an EAP-Request/Identity, requesting the EAP client to 191 identify itself. Upon receipt of the EAP client's EAP-Response, the 192 access device will then issue a second Diameter-EAP-Request message, 193 with the client's EAP payload encapsulated within the EAP-Payload 194 AVP. 196 A preferred approach is for the access device to issue the 197 EAP-Request/Identity message to the EAP client, and forward the 198 EAP-Response/Identity packet, encapsulated within the EAP-Payload 199 AVP, as a Diameter-EAP-Request to the Diameter server (see the 200 diagram below). This alternative reduces the number of Diameter 201 message round trips. When the EAP-Request/Identity message is issued 202 by the access device, it SHOULD interpret the EAP-Response/Identity 203 packet returned by the authenticating peer, and copy its value to a 204 User-Name AVP in Diameter-EAP-Request. This is useful in roaming 205 environments, since the Destination-Realm is needed for routing 206 purposes. Note that this alternative cannot be universally employed, 207 as there are circumstances where a user's identity is not needed 208 (such as when authorization occurs based on a calling or called phone 209 number). 211 User NAS Server 212 | | | 213 | (initiate EAP) | | 214 |<------------------------------>| | 215 | | | 216 | EAP Request(Identity) | | 217 |<-------------------------------| | 218 | | | 219 | EAP Response(Identity) | | 220 |------------------------------->| | 221 | | Diameter-EAP-Request | 222 | | EAP-Payload(EAP Response) | 223 | |------------------------------->| 224 : : : 225 : ...continues... : 227 The conversation continues until the Diameter server sends a 228 Diameter-EAP-Answer with a Result-Code AVP indicating success or 229 failure, and an optional EAP-Payload. The Result-Code AVP is used by 230 the access device to determine whether service is to be provided to 231 the EAP client. The access device MUST NOT rely on the contents of 232 the optional EAP-Payload to determine whether service is to be 233 provided. 235 : ...continued... : 236 : : : 237 | EAP Response #N | | 238 |------------------------------->| | 239 | | Diameter-EAP-Request | 240 | | EAP-Payload(EAP Response #N) | 241 | |------------------------------->| 242 | | | 243 | | Diameter-EAP-Answer | 244 | | Result-Code=DIAMETER_SUCCESS | 245 | | EAP-Payload(EAP Success) | 246 | | [EAP-Master-Session-Key] | 247 | | (authorization AVPs) | 248 | |<-------------------------------| 249 | | | 250 | EAP Success | | 251 |<-------------------------------| | 253 If authorization was requested, a Diameter-EAP-Answer with 254 Result-Code set to DIAMETER_SUCCESS MUST also include the appropriate 255 authorization AVPs required for the service requested (see Section 5 256 and [NASREQ]). If the Result-Code DIAMETER_LIMITED_SUCCESS is 257 returned, this means that the NAS has to get additional authorization 258 AVPs using a separate NASREQ request. This case is described in 259 Section TBD below. Diameter-EAP-Answer messages whose Result-Code 260 AVP is set to DIAMETER_MULTI_ROUND_AUTH MAY include authorization 261 AVPs. 263 A Diameter-EAP-Answer with succesful Result-Code MAY also include an 264 EAP-Master-Session-Key AVP that contains keying material for 265 protecting the communication between the user and the NAS. Exactly 266 how this keying material is used depends on the link layer in 267 question, is beyond the scope of this document. 269 A home Diameter server MAY request EAP re-authentication by issuing 270 the Re-Auth-Request [BASE] message to the Diameter client. 272 Should an EAP authentication session be interrupted due to a home 273 server failure, the session MAY be directed to an alternate server, 274 but the authentication session will have to be restarted from the 275 beginning. 277 2.3 Sessions and NASREQ interaction 279 (NOTE: This section has not received sufficient WG discussion yet, 280 and is likely to be changed in the future.) 282 The previous section introduced the basic protocol between the NAS 283 and the home server. Since the Diameter-EAP-Answer message may 284 include a Master Session Key (MSK) for protecting the communication 285 between the user and the NAS, care must be taken to ensure that this 286 key does not fall into wrong hands. 288 Basic Diameter security mechanisms (IPsec and TLS) protect Diameter 289 messages hop-by-hop. Since there are currently no end-to-end 290 (NAS-to-home server) security mechanisms defined for Diameter, this 291 section describes some possible scenarios how the messages could be 292 transported protected using these hop-by-hop mechanisms. 294 The list of scenarios is not intended to be exhaustive, and it is 295 possible to combine them. For instance, the first proxy agent after 296 the NAS could use redirects as in scenario 2 to bypass any additional 297 proxy agents. 299 2.3.1 Scenario 1: Direct connection 301 The simplest case is when the NAS contacts the home server directly. 302 All the authorization AVPs are delivered by the home server, as is 303 EAP keying material. 305 NAS home server 306 | | 307 | Diameter-EAP-Request | 308 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 309 | EAP-Payload(EAP Start) | 310 |---------------------------------------------------------------->| 311 | | 312 | Diameter-EAP-Answer | 313 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 314 | EAP-Payload(EAP Request) | 315 |<----------------------------------------------------------------| 316 | | 317 : ...more EAP Request/Response pairs... : 318 | | 319 | Diameter-EAP-Request | 320 | EAP-Payload(EAP Response) | 321 |---------------------------------------------------------------->| 322 | | 323 | Diameter-EAP-Answer | 324 | Result-Code=DIAMETER_SUCCESS | 325 | EAP-Payload(EAP Success) | 326 | EAP-Master-Session-Key | 327 | (authorization AVPs) | 328 |<----------------------------------------------------------------| 330 This scenario is the most likely to be used in small networks, or in 331 cases where Diameter agents are not needed to provide routing or 332 additional authorization AVPs. 334 2.3.2 Scenario 2: Direct connection with redirects 336 In this scenario the NAS uses a redirect agent to locate the home 337 server, and the rest of the session proceeds as before. 339 NAS Local redirect agent Home server 340 | | | 341 | Diameter-EAP-Request | | 342 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 343 | EAP-Payload(EAP Start) | | 344 |------------------------------->| | 345 | | | 346 | Diameter-EAP-Answer | 347 | Redirect-Host=homeserver.example.com | 348 | Redirect-Host-Usage=REALM_AND_APPLICATION | 349 |<-------------------------------| | 350 | : | 351 | Diameter-EAP-Request : | 352 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 353 | EAP-Payload(EAP Start) : | 354 |---------------------------------------------------------------->| 355 | : | 356 : ...rest of the session continues as in first case... : 357 : : : 359 The advantage of this scenario is that knowledge of realms and home 360 servers is centralized to a redirect agent, and it is not necessary 361 to modify the NAS configuration when, e.g., a new roaming agreement 362 is done. 364 2.3.3 Scenario 3: Direct EAP, authorization via agents 366 In this scenario the EAP authentication is done directly with the 367 home server (with Auth-Request-Type set to AUTHENTICATE_ONLY), and 368 the authorization AVPs are retrieved from the local proxy agents. 369 This scenario is intended for environments where the home server 370 cannot provide all the necessary authorization AVPs to the NAS. 372 NAS Local proxy agent Home server 373 | : | 374 | Diameter-EAP-Request : | 375 | Auth-Request-Type=AUTHENTICATE_ONLY | 376 | EAP-Payload(EAP Start) : | 377 |---------------------------------------------------------------->| 378 | : | 379 | : Diameter-EAP-Answer | 380 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 381 | : EAP-Payload(EAP Request) | 382 |<----------------------------------------------------------------| 383 | : | 384 : ...more EAP Request/Response pairs... : 385 | : | 386 | Diameter-EAP-Request : | 387 | EAP-Payload(EAP Response) : | 388 |---------------------------------------------------------------->| 389 | : | 390 | : Diameter-EAP-Answer | 391 | : Result-Code=DIAMETER_SUCCESS | 392 | : EAP-Payload(EAP Success) | 393 | : EAP-Master-Session-Key | 394 | : (authorization AVPs) | 395 |<----------------------------------------------------------------| 396 | | | 397 | AA-Request | | 398 | Auth-Request-Type=AUTHORIZE_ONLY | 399 | (some AVPs from first session) | | 400 |------------------------------->| | 401 | | | 402 | AA-Answer | | 403 | Result-Code=DIAMETER_SUCCESS | | 404 | (authorization AVPs) | | 405 |<-------------------------------| | 407 The NASREQ application is used here for authorization because the 408 realm-specific routing table does support routing based on 409 application, but not more...TO BE CLARIFIED. 411 A second possibility is that the home server signals the NAS to 412 perform a separate authorization step. In this case, the NAS begins 413 the Diameter EAP session with 414 Auth-Request-Type=AUTHORIZE_AUTHENTICATE. The last 415 Diameter-EAP-Answer from the home server contains 416 Result-Code=DIAMETER_LIMITED_SUCCESS, so the NAS does additional 417 AUTHORIZE_ONLY NASREQ step. 419 NAS Local proxy agent Home server 420 | : | 421 | Diameter-EAP-Request : | 422 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 423 | EAP-Payload(EAP Start) : | 424 |---------------------------------------------------------------->| 425 | : | 426 | : Diameter-EAP-Answer | 427 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 428 | : EAP-Payload(EAP Request) | 429 |<----------------------------------------------------------------| 430 | : | 431 : ...more EAP Request/Response pairs... : 432 | : | 433 | Diameter-EAP-Request : | 434 | EAP-Payload(EAP Response) : | 435 |---------------------------------------------------------------->| 436 | : | 437 | : Diameter-EAP-Answer | 438 | Result-Code=DIAMETER_LIMITED_SUCCESS | 439 | : EAP-Payload(EAP Success) | 440 | : EAP-Master-Session-Key | 441 | : (authorization AVPs) | 442 |<----------------------------------------------------------------| 443 | | | 444 | AA-Request | | 445 | Auth-Request-Type=AUTHORIZE_ONLY | 446 | (some AVPs from first session) | | 447 |------------------------------->| | 448 | | | 449 | AA-Answer | | 450 | Result-Code=DIAMETER_SUCCESS | | 451 | (authorization AVPs) | | 452 |<-------------------------------| | 454 2.3.4 Scenario 4: Proxy agents 456 Same as scenario 1, but through proxies. Note that in this case the 457 proxies can see the EAP session keys, so this is not suitable for 458 environments where proxies can't be trusted for this. 460 NAS Local proxy/relay agent Home server 461 | | | 462 | Diameter-EAP-Request | | 463 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 464 | EAP-Payload(EAP Start) | | 465 |------------------------------->|------------------------------->| 466 | | | 467 | | Diameter-EAP-Answer | 468 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 469 | | EAP-Payload(EAP Request) | 470 |<-------------------------------|<-------------------------------| 471 | : | 472 : ...more EAP Request/Response pairs... : 473 | : | 474 | Diameter-EAP-Request | | 475 | EAP-Payload(EAP Response) | | 476 |------------------------------->|------------------------------->| 477 | | | 478 | | Diameter-EAP-Answer | 479 | | Result-Code=DIAMETER_SUCCESS | 480 | | EAP-Payload(EAP Success) | 481 | | EAP-Master-Session-Key | 482 | | (authorization AVPs) | 483 |<-------------------------------|<-------------------------------| 485 2.4 Invalid packets 487 While acting as a pass-through, the NAS MUST validate the EAP header 488 fields (Code, Identifier, Length) prior to forwarding an EAP packet 489 to or from the Diameter server. On receiving an EAP packet from the 490 peer, the NAS checks the Code (2) and Length fields, and matches the 491 Identifier value against the current Identifier, supplied by the 492 Diameter server in the most recently validated EAP Request. On 493 receiving an EAP packet from the Diameter server (encapsulated within 494 a Diameter-EAP-Answer), the NAS checks the Code (1) and Length 495 fields, then updates the current Identifier value. Pending EAP 496 Responses that do not match the current Identifier value are silently 497 discarded by the NAS. 499 Since EAP method fields (Type, Type-Data) are typically not validated 500 by a NAS operating as a pass-through, despite these checks it is 501 possible for a NAS to forward an invalid EAP packet to or from the 502 Diameter server. 504 A Diameter server receiving an EAP-Payload AVP it does not understand 505 SHOULD make the determination of whether the error is fatal or 506 non-fatal based on the EAP Type. A Diameter server determining that 507 a fatal error has occurred MUST send an a Diameter-EAP-Answer with a 508 failure Result-Code and an EAP-Payload AVP encapsulating an EAP 509 Failure packet. A Diameter server determining that a non-fatal error 510 has occurred MUST send a Diameter-EAP-Answer with 511 DIAMETER_MULTI_ROUND_AUTH Result-Code, but no EAP-Payload AVP. To 512 simplify RADIUS translation, this message MUST also include an 513 EAP-Reissued-Payload AVP encapsulating the previous EAP Request sent 514 by the server. 516 When receiving a Diameter-EAP-Answer without an EAP-Payload AVP (and 517 DIAMETER_MULTI_ROUND_AUTH Result-Code), the NAS SHOULD discard the 518 EAP-Response packet most recently transmitted to the Diameter server 519 and check whether additional EAP Response packets have been received 520 matching the current Identifier value. If so, a new EAP Response 521 packet, if available, MUST be sent to the Diameter server within an 522 Diameter-EAP-Request. If no EAP Response packet is available, then 523 the previous EAP Request is resent to the peer, and the 524 retransmission timer is reset. 526 In order to provide protection against Denial of Service (DoS) 527 attacks, it is advisable for the NAS to allocate a finite buffer for 528 EAP packets received from the peer, and to discard packets according 529 to an appropriate policy once that buffer has been exceeded. Also, 530 the Diameter server is advised to permit only a modest number of 531 invalid EAP packets within a single session, prior to terminating the 532 session with TBD. By default a value of 5 invalid EAP packets is 533 recommended. 535 2.5 Retransmission 537 As noted in [RFC2284bis], if an EAP packet is lost in transit between 538 the authenticating peer and the NAS (or vice versa), the NAS will 539 retransmit. 541 It may be necessary to adjust retransmission strategies and 542 authentication timeouts in certain cases. For example, when a token 543 card is used, additional time may be required to allow the user to 544 find the card and enter the token. Since the NAS will typically not 545 have knowledge of the required parameters, these need to be provided 546 by the Diameter server. 548 If a Multi-Round-Time-Out AVP [BASE] is present in an 549 Diameter-EAP-Answer message that also contains an EAP-Payload AVP, 550 that value is used to set the EAP retransmission timer for that EAP 551 Request, and that Request alone. 553 2.6 Fragmentation 555 Using the EAP-Payload AVP, it is possible for the Diameter server to 556 encapsulate an EAP packet that is larger than the MTU on the link 557 between the NAS and the peer. Since it is not possible for the 558 Diameter server to use MTU discovery to ascertain the link MTU, a 559 Framed-MTU AVP may be included in a Diameter-EAP-Request message so 560 as to provide the Diameter server with this information. 562 A Diameter server having received a Framed-MTU AVP in a 563 Diameter-EAP-Request message MUST NOT send any subsequent packet in 564 this EAP conversation containing EAP-Payload AVP whose length exceeds 565 the length specified by the Framed-MTU value, taking the link type 566 (specified by the NAS-Port-Type AVP) into account. For example, as 567 noted in [RFC3580] Section 3.10, for a NAS-Port-Type value of IEEE 568 802.11, the RADIUS server may send an EAP packet as large as 569 Framed-MTU minus four (4) octets, taking into account the additional 570 overhead for the IEEE 802.1X Version (1), Type (1) and Body Length 571 (2) fields. 573 2.7 Accounting 575 When a user is authenticated using EAP, the NAS MAY include an 576 Accounting-Auth-Method AVP [NASREQ] with value 5 (EAP) in 577 Accounting-Request messages. This document specifies one additional 578 AVP for accounting messages: one or more Accounting-EAP-Auth-Method 579 AVPs (see Section 4.1.4) MAY be included in Accounting-Request 580 messages to indicate the EAP method(s) used to authenticate the user. 582 If the NAS has authenticated the user with a locally implemented EAP 583 method, it knows the method used and SHOULD include it in an 584 Accounting-EAP-Auth-Method AVP. 586 If the authentication was done using Diameter-EAP-Request/Answer 587 messages, the Diameter server SHOULD include one more more 588 Accounting-EAP-Auth-Method AVPs in Diameter-EAP-Answer packets with a 589 successful result code. In this case, the NAS SHOULD include these 590 AVPs in Accounting-Request messages. 592 2.8 Usage guidelines 594 2.8.1 User-Name AVP 596 Unless the access device interprets the EAP-Response/Identity packet 597 returned by the authenticating peer, it will not have access to the 598 user's identity. Furthermore, some EAP methods support identity 599 protection where the user's real identity is not included in 600 EAP-Response/Identity. Therefore, the Diameter Server SHOULD return 601 the user's identity by inserting it in the User-Name AVP of 602 subsequent Diameter-EAP-Answer packets. Without the user's identity, 603 the Session-Id AVP MAY be used for accounting and billing, however 604 operationally this could be very difficult to manage. 606 2.8.2 Conflicting AVPs 608 A Diameter-EAP-Answer message containing an EAP-Payload of type 609 EAP-Success or EAP-Failure MUST NOT have the Result-Code AVP set to 610 DIAMETER_MULTI_ROUND_AUTH. Also, the Result-Code SHOULD match the 611 contained EAP packet (successful Result-Code if EAP-Success, and a 612 failure Result-Code for EAP-Failure). TO BE WRITTEN: clarify this. 614 2.8.3 Displayable messages 616 The Reply-Message AVP [NASREQ] contains text which may be displayed 617 to the user. Note that the NAS does not necessarily have any 618 facility for actually sending these messages to the user. In any 619 case, the NAS MUST NOT manufacture any EAP packets (such as 620 EAP-Request/Notification) from Reply-Message AVPs. 622 2.8.4 Role reversal 624 Some environments where EAP is used, such as PPP, support 625 peer-to-peer operation. That is, both parties act as authenticators 626 and authenticatees at the same time, in two simultaneous and 627 independent EAP conversations. 629 This specification is intended for communication between EAP 630 (passthrough) authenticator and backend authentication server. A 631 Diameter client MUST NOT send a Diameter-EAP-Request encapsulating an 632 EAP Request packet, and a Diameter server receiving such packet MUST 633 respond with a failure Result-Code.. 635 2.8.5 Alternative Uses 637 Currently the conversation between the backend authentication server 638 and the Diameter server is proprietary because of lack of 639 standardization. In order to increase standardization and provide 640 interoperability between Diameter vendors and backend security 641 vendors, it is recommended that Diameter-encapsulated EAP be used for 642 this conversation. 644 This has the advantage of allowing the Diameter server to support EAP 645 without the need for authentication-specific code within the Diameter 646 server. Authentication-specific code can then reside on a back-end 647 authentication server instead. 649 In the case where Diameter-encapsulated EAP is used in a conversation 650 between a Diameter server and a backend authentication server, the 651 latter will typically return an Diameter-EAP-Answer/EAP-Payload/ 652 EAP-Success message without inclusion of the expected authorization 653 AVPs required in a successful response. This means that the Diameter 654 server MUST add these attributes prior to sending an 655 Diameter-EAP-Answer/EAP-Payload/EAP-Success message to the access 656 device. 658 3. Command-Codes 660 This section defines new Command-Code values that MUST be supported 661 by all Diameter implementations conforming to this specification. 662 The following Command Codes are defined in this section: 664 Command-Name Abbrev. Code Reference 665 -------------------------------------------------------- 666 Diameter-EAP-Request DER 268 3.1 667 Diameter-EAP-Answer DEA 268 3.2 669 3.1 Diameter-EAP-Request (DER) Command 671 The Diameter-EAP-Request (DER) command, indicated by the Command-Code 672 field set to 268 and the 'R' bit set in the Command Flags field, is 673 sent by a Diameter client to a Diameter server and conveys an 674 EAP-Response from the EAP client. The Diameter-EAP-Request MUST 675 contain one EAP-Payload AVP, which contains the actual EAP payload. 676 An EAP-Payload AVP with no data MAY be sent to the Diameter server to 677 initiate an EAP authentication session. 679 The DER message MAY be the result of a multi-round authentication 680 exchange, which occurs when the DEA is received with the Result-Code 681 AVP set to DIAMETER_MULTI_ROUND_AUTH [BASE]. A subsequent DER 682 message MUST include any State AVPs [NASREQ] that were present in the 683 DEA. For re-authentication, it is recommended that the Identity 684 request be skipped in order to reduce the number of authentication 685 round trips. This is only possible when the user's identity is 686 already known by the home Diameter server. 688 Message format 690 ::= < Diameter Header: 268, REQ, PXY > 691 < Session-Id > 692 { Auth-Application-Id } 693 { Origin-Host } 694 { Origin-Realm } 695 { Destination-Realm } 696 { Auth-Request-Type } 697 [ NAS-Port ] 698 [ NAS-Port-Id ] 699 [ Origin-State-Id ] 700 [ Destination-Host ] 701 [ NAS-Identifier ] 702 [ NAS-IP-Address ] 703 [ NAS-IPv6-Address ] 704 [ NAS-Port-Type ] 705 [ Port-Limit ] 706 [ User-Name ] 707 { EAP-Payload } 708 [ Service-Type ] 709 [ Idle-Timeout ] 710 [ State ] 711 [ Authorization-Lifetime ] 712 [ Auth-Grace-Period ] 713 [ Auth-Session-State ] 714 [ Session-Timeout ] 715 [ Callback-Number ] 716 [ Called-Station-Id ] 717 [ Calling-Station-Id ] 718 * [ Class ] 719 [ Originating-Line-Info ] 720 [ Connect-Info ] 721 * [ Framed-Compression ] 722 [ Framed-Interface-Id ] 723 [ Framed-IP-Address ] 724 * [ Framed-IPv6-Prefix ] 725 [ Framed-IP-Netmask ] 726 [ Framed-MTU ] 727 [ Framed-Protocol ] 728 * [ Tunneling ] 729 * [ Proxy-Info ] 730 * [ Route-Record ] 731 * [ AVP ] 733 3.2 Diameter-EAP-Answer (DEA) Command 735 The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code 736 field set to 268 and the 'R' bit cleared in the Command Flags field, 737 is sent by the Diameter server to the client for one of the following 738 reasons: 740 1. The message is part of a multi-round authentication exchange, and 741 the server is expecting a subsequent Diameter-EAP-Request. This 742 is indicated by setting the Result-Code to 743 DIAMETER_MULTI_ROUND_AUTH, and MAY include zero or more State 744 AVPs. 746 2. the EAP client has been successfully authenticated and 747 authorized, in which case the message MUST include the 748 Result-Code AVP indicating success, and SHOULD include an 749 EAP-Payload of type EAP-Success. This event MUST cause the 750 access device to provide service to the EAP client. 752 3. The EAP client has not been successfully authenticated and/or 753 authorized, and the Result-Code AVP is set to indicate failure. 754 This message SHOULD include an EAP-Payload, but this AVP is not 755 used to determine whether service is to be provided. 757 If the message from the Diameter client included a request for 758 authorization, a successful response MUST include the authorization 759 AVPs that are relevant to the service being provided. 761 Message format 763 ::= < Diameter Header: 268, PXY > 764 < Session-Id > 765 { Auth-Application-Id } 766 { Auth-Request-Type } 767 { Result-Code } 768 { Origin-Host } 769 { Origin-Realm } 770 [ User-Name ] 771 [ EAP-Payload ] 772 [ Multi-Round-Time-Out ] 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 ] 781 [ Auth-Grace-Period ] 782 [ Auth-Session-State ] 783 [ Re-Auth-Request-Type ] 784 [ Session-Timeout ] 785 [ State ] 786 * [ 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) is of type OctetString and is used 828 to encapsulate the actual EAP packet that is being exchanged between 829 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) is of type OctetString. 834 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) is of type OctetString. 839 It is used by the Diameter server...TBD 841 4.1.4 Accounting-EAP-Auth-Method AVP 843 The Accounting-EAP-Auth-Method AVP (AVP Code TBD) is of type 844 Unsigned64. In case of expanded types [RFC2284bis, Section 5.7], the 845 least significant 32 bits contain the Vendor-Type field, and the next 846 24 bits contain the Vendor-Id field. 848 The use of this AVP is described in Section 2.7. 850 5. AVP Occurrence Tables 852 The following tables use these symbols: 854 0 The AVP MUST NOT be present in the message 855 0+ Zero or more instances of the AVP MAY be present in the 856 message 857 0-1 Zero or one instance of the AVP MAY be present in the 858 message 859 1 One instance of the AVP MUST be present in the message 861 Note that AVPs that can only be present within a Grouped AVP are not 862 represented in these tables. 864 5.1 EAP Command AVP Table 866 The following table lists the AVPs that may be present in the DER and 867 DEA Commands, defined in this document; however, the AVPs listed are 868 defined both here and in [NASREQ]. 870 +---------------+ 871 | Command-Code | 872 |-------+-------+ 873 Attribute Name | DER | DEA | 874 ------------------------------------|-------+-------| 875 Accounting-EAP-Auth-Method | 0 | 0+ | 876 Acct-Interim-Interval [BASE] | 0 | 0-1 | 877 Auth-Application-Id [BASE] | 1 | 1 | 878 Auth-Grace-Period [BASE] | 0-1 | 0-1 | 879 Auth-Request-Type [BASE] | 1 | 1 | 880 Auth-Session-State [BASE] | 0-1 | 0-1 | 881 Authorization-Lifetime [BASE] | 0-1 | 0-1 | 882 Callback-Id [NASREQ] | 0 | 0-1 | 883 Callback-Number [NASREQ] | 0-1 | 0-1 | 884 Called-Station-Id [NASREQ] | 0-1 | 0 | 885 Calling-Station-Id [NASREQ] | 0-1 | 0 | 886 Class [BASE] | 0+ | 0+ | 887 Configuration-Token [NASREQ] | 0 | 0+ | 888 Connect-Info [NASREQ] | 0-1 | 0 | 889 Destination-Host [BASE] | 0-1 | 0 | 890 Destination-Realm [BASE] | 1 | 0 | 891 EAP-Payload | 1 | 0-1 | 892 Error-Message [BASE] | 0 | 0-1 | 893 Error-Reporting-Host [BASE] | 0 | 0-1 | 894 Failed-AVP [BASE] | 0+ | 0+ | 895 Filter-Id [NASREQ] | 0 | 0+ | 896 Framed-Appletalk-Link [NASREQ] | 0 | 0-1 | 897 Framed-Appletalk-Network [NASREQ] | 0 | 0+ | 898 Framed-Appletalk-Zone [NASREQ] | 0 | 0-1 | 899 Framed-Compression [NASREQ] | 0+ | 0+ | 900 Framed-Interface-Id [NASREQ] | 0-1 | 0-1 | 901 Framed-IP-Address [NASREQ] | 0-1 | 0-1 | 902 Framed-IP-Netmask [NASREQ] | 0-1 | 0-1 | 903 Framed-IPv6-Prefix [NASREQ] | 0+ | 0+ | 904 Framed-IPv6-Pool [NASREQ] | 0 | 0-1 | 905 Framed-IPv6-Route [NASREQ] | 0 | 0+ | 906 Framed-IPX-Network [NASREQ] | 0 | 0-1 | 907 Framed-MTU [NASREQ] | 0-1 | 0-1 | 908 Framed-Pool [NASREQ] | 0 | 0-1 | 909 Framed-Protocol [NASREQ] | 0-1 | 0-1 | 910 Framed-Route [NASREQ] | 0 | 0+ | 911 Framed-Routing [NASREQ] | 0 | 0-1 | 912 Idle-Timeout [NASREQ] | 0-1 | 0-1 | 913 Multi-Round-Time-Out [BASE] | 0 | 0-1 | 914 NAS-Filter-Rule [NASREQ] | 0 | 0+ | 915 NAS-Identifier [NASREQ] | 0-1 | 0 | 916 NAS-IP-Address [NASREQ] | 0-1 | 0 | 917 NAS-IPv6-Address [NASREQ] | 0-1 | 0 | 918 NAS-Port [NASREQ] | 0-1 | 0 | 919 NAS-Port-Id [NASREQ] | 0-1 | 0 | 920 NAS-Port-Type [NASREQ] | 0-1 | 0 | 921 Originating-Line-Info [NASREQ] | 0-1 | 0 | 922 Origin-Host [BASE] | 1 | 1 | 923 Origin-Realm [BASE] | 1 | 1 | 924 Origin-State-Id [BASE] | 0-1 | 0-1 | 925 Port-Limit [NASREQ] | 0-1 | 0-1 | 926 Proxy-Info [BASE] | 0+ | 0+ | 927 Re-Auth-Request-Type [BASE] | 0 | 0-1 | 928 Redirect-Host [BASE] | 0 | 0+ | 929 Redirect-Host-Usage [BASE] | 0 | 0-1 | 930 Redirect-Max-Cache-Time [BASE] | 0 | 0-1 | 931 Reply-Message [NASREQ] | 0 | 0+ | 932 Result-Code [BASE] | 0 | 1 | 933 Route-Record [BASE] | 0+ | 0+ | 934 Service-Type [NASREQ] | 0-1 | 0-1 | 935 Session-Id [BASE] | 1 | 1 | 936 Session-Timeout [BASE] | 0-1 | 0-1 | 937 State [NASREQ] | 0-1 | 0-1 | 938 Tunneling [NASREQ] | 0+ | 0+ | 939 User-Name [BASE] | 0-1 | 0-1 | 941 5.2 Accounting AVP Table 943 The table in this section is used to represent which AVPs defined in 944 this document are to be present in the Accounting messages, defined 945 in [BASE]. 947 +-----------+ 948 | Command | 949 | Code | 950 |-----+-----+ 951 Attribute Name | ACR | ACA | 952 ---------------------------------------|-----+-----+ 953 Accounting-EAP-Auth-Method | 0+ | 0 | 955 6. RADIUS/Diameter interactions 957 Section 9 of [NASREQ] describes basic guidelines that translation 958 agents may follow when translating between RADIUS and Diameter 959 protocols. This section gives additional guidelines for the Diameter 960 EAP application. Note that this document does not restrict 961 implementations from creating additional methods, as long as the 962 translation function doesn't violate the RADIUS or the Diameter 963 protocols. 965 6.1 RADIUS Request forwarded as Diameter Request 967 RADIUS Access-Request to Diameter-EAP-Request: 969 o RADIUS EAP-Message attribute(s) are translated to a Diameter 970 EAP-Payload AVP. If multiple RADIUS EAP-Message attributes are 971 present, they are concatenated and translated to a single Diameter 972 EAP-Payload AVP. 974 o An empty RADIUS EAP-Message attribute (with length 2) signifies 975 EAP-Start, and it is translated to an empty EAP-Payload AVP. 977 Diameter-EAP-Answer to RADIUS Access-Accept/Reject/Challenge: 979 o Diameter EAP-Payload AVP is translated to RADIUS EAP-Message 980 attribute(s). If necessary, the value is split into multiple 981 RADIUS EAP-Message attributes. 983 o Diameter EAP-Reissued-Payload AVP is translated to a message that 984 contains RADIUS EAP-Message attribute(s), and a RADIUS Error-Cause 985 attribute [RFC3576] with value 202 (decimal), "Invalid EAP Packet 986 (Ignored)" [RFC3579]. 988 o As described in [NASREQ], if the Result-Code AVP set to 989 DIAMETER_MULTI_ROUND_AUTH and the Multi-Round-Time-Out AVP is 990 present, it is translated to the RADIUS Session-Timeout attribute. 992 o Diameter EAP-Master-Session-Key AVP can be translated to the 993 vendor-specific RADIUS MS-MPPE-Recv-Key and MS-MPPE-Send-Key 994 attributes [RFC2548]. The first up to 32 octets of the key is 995 stored into MS-MPPE-Recv-Key, and the next up to 32 octets (if 996 present) are stored into MS-MPPE-Send-Key. 998 o Diameter Accounting-EAP-Auth-Method AVPs, if present, are 999 discarded. 1001 6.2 Diameter Request forwarded as RADIUS Request 1003 Diameter-EAP-Request to RADIUS Access-Request: 1005 o The Diameter EAP-Payload AVP is translated to RADIUS EAP-Message 1006 attribute(s). 1008 o An empty Diameter EAP-Payload AVP signifies EAP-Start, and it is 1009 translated to an empty RADIUS EAP-Message attribute. 1011 o The type (or expanded type) field from the EAP-Payload AVP can be 1012 saved either in a local state table, or encoded in a RADIUS 1013 Proxy-State attribute. This information is needed to construct an 1014 Accounting-EAP-Auth-Method AVP for the answer message (see below). 1016 RADIUS Access-Accept/Reject/Challenge to Diameter-EAP-Answer: 1018 o If the RADIUS Access-Challenge message does not contain an 1019 Error-Cause attribute [RFC3576] with value 202 (decimal), "Invalid 1020 EAP Packet (Ignored)" [RFC3579], any RADIUS EAP-Message attributes 1021 are translated to a Diameter EAP-Payload AVP, concatenating them 1022 if multiple attributes are present. 1024 o If the Error-Cause attribute with value 202 is present, any RADIUS 1025 EAP-Message attributes are translated to a Diameter 1026 EAP-Reissued-Payload AVP, concatenating them if multiple 1027 attributes are present. 1029 o As described in [NASREQ], if the Session-Timeout attribute is 1030 present in a RADIUS Access-Challenge message, it is translated to 1031 the Diameter Multi-Round-Time-Out AVP. 1033 o If the vendor-specific RADIUS MS-MPPE-Recv-Key and/or 1034 MS-MPPE-Send-Key attributes [RFC2548] are present, they can be 1035 translated to a Diameter EAP-Master-Session-Key AVP. Their values 1036 are concatenated (MS-MPPE-Recv-Key first, MS-MPPE-Send-Key next), 1037 and the concatenated value is stored into a Diameter 1038 EAP-Master-Session-Key AVP. 1040 o If the Diameter-EAP-Answer will have a successful result code, the 1041 saved state (see above) can be used to construct an 1042 Accounting-EAP-Auth-Method AVP. 1044 6.3 Accounting Requests 1046 In Accounting-Requests, the vendor-specific RADIUS MS-Acct-EAP-Type 1047 attribute [RFC2548] can be translated to a Diameter 1048 Accounting-EAP-Auth-Method AVP, and vice versa. 1050 When translating from Diameter to RADIUS, note that the 1051 MS-Acct-EAP-Type attribute does not support expanded EAP types. Type 1052 values greater than 255 should be translated to type 254. 1054 7. IANA Considerations 1056 This document does not create any new namespaces to be maintained by 1057 IANA, but it requires new values in namespaces that have been defined 1058 in the Diameter Base protocol [BASE]. 1060 o IANA has assigned a Command Code value of TBD-BY-IANA (suggested 1061 value: 268) for the Diameter-EAP-Request/Diameter-EAP-Answer 1062 command (in the Command Code namespace defined in [BASE]). 1064 o IANA has assigned the following AVP Code values for the new AVPs 1065 defined in this document (in the AVP Code namespace defined in 1066 [BASE]). 1068 AVP name Code 1069 ----------------------------------- 1070 EAP-Payload TBD 1071 EAP-Reissued-Payload TBD 1072 EAP-Master-Session-Key TBD 1073 Accounting-EAP-Auth-Method TBD 1075 o IANA has assigned an Application Identifier value of TBD-BY-IANA 1076 for this specification (in the Application Identifier namespace 1077 defined in [BASE]). 1079 8. Security Considerations 1081 8.1 Overview 1083 Diameter peer-to-peer connections can be protected with IPsec or TLS. 1084 These mechanisms are believed to provide sufficient protection under 1085 the normal Internet threat model--that is, assuming the authorized 1086 nodes engaging in the protocol have not been compromised, but the 1087 attacker has complete control over the communication channels between 1088 them. This includes eavesdropping, message modification, insertion, 1089 man-in-the-middle and replay attacks. The details and related 1090 security considerations are discussed in [BASE]. 1092 In addition to authentication provided by IPsec or TLS, authorization 1093 is also required. Authorization here means the act of determining if 1094 a Diameter message received from an authenticated Diameter peer 1095 should be accepted (and not authorization of users requesting network 1096 access from a NAS). In other words, when a Diameter server receives 1097 a Diameter-EAP-Request, it has to decide if the client is authorized 1098 to act as a NAS for the specific user, service type, and so on. 1099 Correspondingly, when a NAS contacts a server to send a 1100 Diameter-EAP-Request, it has to determine whether the server is 1101 authorized to act as home server for the realm in question. 1103 Authorization can involve local Access Control Lists (ACLs), 1104 information contained in certificates, or some other means. See 1105 [BASE] for more discussion and related security considerations. 1107 The hop-by-hop security mechanisms (IPsec and TLS) combined with 1108 proper authorization provide good protection against "outside" 1109 attackers (denial-of-service is, of course, possible). The remaining 1110 part of this section deals with attacks by nodes that have been 1111 properly authorized (to function as a NAS, Diameter agent, or 1112 Diameter server) but abuse their authorization or have been 1113 compromised. In general, it is not possible to completely protect 1114 against attacks by compromised nodes, but this section offers some 1115 advice that can be used to limit the extent of the damage. 1117 Attacks involving eavesdropping or modification of EAP messages are 1118 beyond the scope of these document. See [RFC2284bis] for discussion 1119 of these security considerations (including method negotation, 1120 dictionary attacks, and privacy issues). While these attacks can be 1121 carried out by an attacker between the client and the NAS, 1122 compromised NASes and Diameter agents are naturally also in a good 1123 position to modify and eavesdrop the EAP messages. 1125 Similarly, attacks involving whatever link layer protocol is used 1126 between the client and the NAS, such as PPP or IEEE 802.11, are 1127 beyond the scope of this document. 1129 8.2 AVP editing 1131 Diameter agents can modify, insert, and delete AVPs. Diameter agents 1132 are usually meant to modify AVPs, and the protocol in general cannot 1133 distinguish well-intentioned and malicious modifications (see 1134 [RFC2607] for more discussion). Similarly, a compromised NAS or 1135 server can naturally include different set of AVPs than expected. 1137 The question is thus "what can an attacker who compromises an 1138 authorized NAS, agent, or server do using Diameter EAP messages?" 1139 Some of the consequences are rather obvious--for instance, a Diameter 1140 agent can give access to unauthorized users by changing the 1141 Result-Code to DIAMETER_SUCCESS. Other consequences are less obvious, 1142 and are discussed below (authentication method negotiation attacks 1143 are discussed in the next section). 1145 By including suitable AVPs in an AA-Answer/Diameter-EAP-Answer 1146 messages an attacker (depending on implementation and configuration 1147 details) may be able to: 1149 o Give unauthorized users access, or deny access to authorized users 1150 (Result-Code). 1152 o Give attacker a login session to a host otherwise protected by 1153 firewalls, or redirect an authorized user's login session to a 1154 host controlled by the attacker (Login-Host). 1156 o Route an authorized user's traffic through a host controlled by 1157 the attacker (various tunneling AVPs). 1159 o Redirect an authorized user's DNS requests to a malicious DNS 1160 server (various vendor-specific AVPs). 1162 o Modify routing tables at the NAS and thus redirect packets 1163 destined for someone else (Framed-Route, Framed-Routing). 1165 o Remove packet filters and other restrictions for user (Filter, 1166 Callback, various vendor-specific AVPs). 1168 o Cause the NAS to call some number, possibly expensive toll number 1169 controlled by the attacker (callback AVPs) 1171 o Execute Command Line Interface (CLI) commands on the NAS (various 1172 vendor-specific attributes). 1174 By modifying an AA-Request/Diameter-EAP-Request, an attacker may be 1175 able to: 1177 o Change NAS-Identifier/NAS-Port/Origin-Host (or something) so that 1178 a valid user appears to be accessing the network from a different 1179 NAS than in reality. 1181 o Modify Calling-Station-ID (either to hide the true value, gain 1182 access, or frame someone else). 1184 o Modify password change messages (some vendor-specific attributes) 1186 o Modify usage information in accounting messages. 1188 o Modify contents of Class and State AVPs. 1190 Some of these attacks can be prevented if the NAS or server can be 1191 configured not to accept some particular AVPs, or accepting them only 1192 from some nodes. 1194 8.3 Negotiation attacks 1196 This section deals with attacks where the NAS, any Diameter agents, 1197 or Diameter server attempts to cause the authenticating user to 1198 choose some authentication method other than EAP, such as PAP or CHAP 1199 (negotiation attacks within EAP are discussed in [RFC2284bis], 1200 Section 7.8). 1202 The vulnerability can be mitigated via implementation of 1203 per-connection policy on the part of the authenticating peer, and 1204 per-peer policy on the part of the Diameter server. For the 1205 authenticating peer, authentication policy should be set on a 1206 per-connection basis. 1208 With per-connection policy, an authenticating peer will only attempt 1209 to negotiate EAP for a session in which EAP support is expected. As 1210 a result, there is a presumption that an authenticating peer 1211 selecting EAP requires that level of security. If it cannot be 1212 provided, it is likely that there is some kind of misconfiguration, 1213 or even that the authenticating peer is contacting the wrong server. 1215 In this case, the authenticating peer simply disconnects. 1217 Similarly, with a per-user policy, the home server will not accept 1218 authentication methods other than EAP for users for which EAP support 1219 is expected. 1221 For a NAS, it may not be possible to determine whether a peer is 1222 required to authenticate with EAP until the peer's identity is known. 1223 For example, for shared-uses NASes it is possible for one reseller to 1224 implement EAP while another does not. Alternatively, some peer might 1225 be authenticated locally by the NAS while other peers are 1226 authenticated via Diameter. In such cases, if any peers of the NAS 1227 MUST do EAP, then the NAS MUST attempt to negotiate EAP for every 1228 session. This avoids forcing a peer to support more than one 1229 authentication type, which could weaken security. 1231 8.4 Session key distribution 1233 Since there are currently no end-to-end (NAS-to-home server) security 1234 mechanisms specified for Diameter, any agents that process 1235 Diameter-EAP-Answer messages can see the contents of the 1236 EAP-Session-Key AVP. For this reason, this specification strongly 1237 recommends avoiding Diameter agents when they cannot be trusted to 1238 keep the keys secret. 1240 In environments where agents are present, several factors should be 1241 considered when deciding whether the agents that are authorized (and 1242 considered "trustworthy enough") to grant access to users and specify 1243 various authorization and tunneling AVPs are also "trustworthy 1244 enough" to handle the session keys. These factors include (but are 1245 not limited to) the type of access provided (e.g., public Internet or 1246 corporate internet), security level of the agents, and the 1247 possibilities for attacking user's traffic after it has been 1248 decrypted by the NAS. 1250 Note that the keys communicated in Diameter messages are usually 1251 short-term session keys (or short-term master keys that are used to 1252 derive session keys). To actually cause any damage, those session 1253 keys must end with some malicious party; that party must be able to 1254 eavesdrop, modify, or insert traffic between the user and the NAS 1255 during the lifetime of those keys (e.g., in 802.11i the attacker must 1256 also eavesdrop the "four-way handshake"); and that eavesdropping or 1257 modification must cause some damage. 1259 8.5 Privacy issues 1261 Diameter messages can contain AVPs that can be used to identify the 1262 user (e.g., User-Name) and approximate location of the user (e.g. 1264 Origin-Host for WLAN access points, Calling-Station-Id for fixed 1265 phone lines). Thus, any Diameter nodes that process the messages may 1266 be able to determine the geographic location of users. 1268 Note that in many cases, the user identity is also sent in clear 1269 inside EAP-Payload AVPs, and it may be possible to eavesdrop this 1270 between the user and the NAS. 1272 This can mitigated somewhat by using EAP methods that provide 1273 identity protection (see [RFC2284bis], Section 7.3), and using 1274 Session-Id or pseudonyms for accounting. 1276 8.6 Note about EAP and impersonation 1278 If the EAP method used does not provide mutual authentication, 1279 obviously anyone can impersonate as the network to the user. Even 1280 when EAP mutual authentication is used, it occurs between the user 1281 and the Diameter home server. See [EAPKey] for an extensive 1282 discussion about the details and their implications. 1284 However, one issue is worth pointing out here. As described in 1285 [EAPKey], the current EAP architecture does not allow the home server 1286 to restrict what service parameters or identities (such as SSID or 1287 BSSID in 802.11 wireless LANs) are advertised by the NAS to the 1288 client. That is, a compromised NAS can change its BSSID or SSID, thus 1289 appearing to offer a different service than intended. Even if these 1290 parameters are included in Diameter-EAP-Request messages, the NAS can 1291 tell different values to the client. 1293 Thus, the possession of the session keys by the NAS proves that the 1294 user is talking to *some* authorized NAS, but a compromised NAS can 1295 lie about its exact identity. See [EAPKey] for discussion how 1296 individual EAP methods can provide authentication of NAS service 1297 parameters and identities. 1299 Note that the usefulness of such authentication may be rather limited 1300 in many environments. For instance, in wireless LANs the user does 1301 not usually securely know the identity (such as BSSID) of the "right" 1302 access point--it's simply picked from a beacon message that has the 1303 correct SSID and good signal strength (something that's easy to 1304 spoof). Thus, simply authenticating the identity may not allow the 1305 user to distinguish the "right" access point from all other ones. 1307 9. Acknowledgements 1309 This Diameter application relies heavily on earlier work on Diameter 1310 NASREQ application [NASREQ] and RADIUS EAP support [RFC3579]. Much 1311 of the material in this specification has been copied from these 1312 documents. 1314 The authors would also like to acknowledge the following people for 1315 their contributions to this document: Bernard Aboba, Jari Arkko, Pat 1316 Calhoun, Henry Haverinen, and John Loughney. (TBD: Who's missing from 1317 this list?) 1319 Normative References 1321 [BASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 1322 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1324 [EAPKey] Aboba, B., Simon, D., Arkko, J. and H. Levkowetz, "EAP Key 1325 Management Framework", draft-ietf-eap-keying-00 (work in 1326 progress), October 2003. 1328 [NASREQ] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 1329 Network Access Server Application", 1330 draft-ietf-aaa-diameter-nasreq-13 (work in progress), 1331 October 2003. 1333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1334 Requirement Levels", BCP 14, RFC 2119, March 1997. 1336 [RFC2284bis] 1337 Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J. and H. 1338 Levkowetz, "Extensible Authentication Protocol (EAP)", 1339 draft-ietf-eap-rfc2284bis-06 (work in progress), September 1340 2003. 1342 Informative References 1344 [Archie] Walker, J. and R. Housley, "The EAP Archie Protocol", 1345 draft-jwalker-eap-archie-01 (work in progress), June 2003. 1347 [IEEE-802.1X] 1348 Institute of Electrical and Electronics Engineers, "Local 1349 and Metropolitan Area Networks: Port-Based Network Access 1350 Control", IEEE Standard 802.1X, September 2001. 1352 [IEEE-802.11i] 1353 Institute of Electrical and Electronics Engineers, 1354 "Unapproved Draft Supplement to Standard for 1355 Telecommunications and Information Exchange Between 1356 Systems - LAN/MAN Specific Requirements - Part 11: 1357 Wireless LAN Medium Access Control (MAC) and Physical 1358 Layer (PHY) Specifications: Specification for Enhanced 1359 Security", IEEE Draft 802.11i (work in progress), 2003. 1361 [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 1362 Protocol", draft-ietf-ipsec-ikev2-11 (work in progress), 1363 October 2003. 1365 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1366 RFC 1661, July 1994. 1368 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1369 RFC 2548, March 1999. 1371 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1372 Implementation in Roaming", RFC 2607, June 1999. 1374 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. 1375 Aboba, "Dynamic Authorization Extensions to Remote 1376 Authentication Dial In User Service (RADIUS)", RFC 3576, 1377 July 2003. 1379 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1380 Dial In User Service) Support For Extensible 1381 Authentication Protocol (EAP)", RFC 3579, September 2003. 1383 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 1384 "IEEE 802.1X Remote Authentication Dial In User Service 1385 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 1387 Authors' Addresses 1389 Pasi Eronen (editor) 1390 Nokia Research Center 1391 P.O. Box 407 1392 FIN-00045 Nokia Group 1393 Finland 1395 EMail: pasi.eronen@nokia.com 1397 Tom Hiller 1398 Lucent Technologies 1399 1960 Lucent Lane 1400 Naperville, IL 60566 1401 USA 1403 Phone: +1 630 979 7673 1404 EMail: tom.hiller@lucent.com 1405 Glen Zorn 1406 Cisco Systems 1407 500 108th Avenue N.E., Suite 500 1408 Bellevue, WA 98004 1409 USA 1411 Phone: +1 425 344 8113 1412 EMail: gwz@cisco.com 1414 Appendix A. Changelog 1416 (This section will not appear in the final version submitted to RFC 1417 editor.) 1419 Changes from -02 to -03.a: 1421 o Updated security considerations section. 1423 o Removed the EAP-MTU attribute (use Framed-MTU instead). 1425 o Clarified text about invalid packets and EAP-Reissued-Payload AVP. 1427 o Added reference to Accounting-Auth-Method AVP to Section 2.7. 1429 o Updated ABNFs and AVP occurrence tables to match NASREQ-13. 1431 o Updated the IANA considerations to reflect the new AAA parameters 1432 registry. Changed EAP-Payload and Accounting-EAP-Auth-Method AVP 1433 codes to "TBD" since they collided with NASREQ codes (issue 429). 1435 o Updated references: DynAuth to RFC3576, RFC2869bis to RFC3579, 1436 RADIUS1X to RFC3580, BASE TO RFC3588, NASREQ to -13, IKEv2 to -11, 1437 2284bis to -06. 1439 Version -02.e published as -02. 1441 Changes from -02.d to -02.e: 1443 o Added a section on accounting, and changed how the 1444 Accounting-EAP-Auth-Method is determined. 1446 o Updates to "authorization" and "impersonating as the network" 1447 security considerations. 1449 Changes from -02.c to -02.d: 1451 o Some clarifications to Introduction section. 1453 o Lots of clarifications and added diagrams in protocol overview 1454 section. Moved non-EAP-supporting servers, User-Name AVP 1455 guidelines, and conflicting messages to separate sections. 1457 o Added a new section about sessions and NASREQ interaction. 1459 o Wrote a note about Reply-Message AVP, and added it back to ABNFs 1460 and occurance tables. 1462 o Added EAP-Reissued-Payload AVP for signalling invalid packets, and 1463 RADIUS translation for this. 1465 o Added EAP-Master-Session-Key AVP for keys, and suggestions for 1466 RADIUS translation. 1468 o Attempted to clarify Framed-MTU RADIUS translation. 1470 o Added a first attempt of security considerations section. 1472 o Updated acknowledgements (please notify me if someone's missing). 1474 Changes from -02.b to -02.c: 1476 o Rephrased abstract and introduction sections. 1478 o A couple of minor changes in Sections 2.1 and 2.2. 1480 o Added text about advertising application support and role 1481 reversal. 1483 o Changed type of Accounting-EAP-Auth-Method AVP from Enumerated to 1484 Unsigned64, and explained how it is determined. 1486 o Removed references to EAP-Master-Session-Key AVP added in -02.b. 1488 o Added Diameter-RADIUS translation of accounting AVPs. 1490 o Added IANA Considerations section. 1492 o References section: Updated RFC2284bis, added IEEE-802.11i and 1493 IKEv2, deleted RFC1510 ad RFC1938. 1495 Changes from -02.a to -02.b: 1497 o Added some text to Introduction section. 1499 o Stole text from 2869bis about invalid packets, retransmissions, 1500 and fragmentation. 1502 o In section 2.1, changed one "MAY" to "could" since it was not used 1503 to describe a requirement. 1505 o Updated ABNF's and AVP occurance tables to match the current 1506 NASREQ-11 document. 1508 o Added EAP-MTU and EAP-Master-Session-Key AVPs. 1510 o Removed description of Configuration-Token, Nas-Port, Nas-Port-Id, 1511 and State AVPs (the text didn't add anything to their description 1512 in NASREQ). 1514 o Added a first attempt of a section describing Diameter-RADIUS 1515 translation. 1517 o Added references RFC2284bis, RFC2548, RFC2869bis, RADIUS1X, and 1518 DynAuth. 1520 Changes from -01 to -02.a: 1522 o New editor. 1524 o Added Changelog appendix. 1526 o Converted source to XML format. This will result in many small 1527 formatting changes in the ASCII version. 1529 o Updated BASE and NASREQ references to current versions. 1531 Intellectual Property Statement 1533 The IETF takes no position regarding the validity or scope of any 1534 intellectual property or other rights that might be claimed to 1535 pertain to the implementation or use of the technology described in 1536 this document or the extent to which any license under such rights 1537 might or might not be available; neither does it represent that it 1538 has made any effort to identify any such rights. Information on the 1539 IETF's procedures with respect to rights in standards-track and 1540 standards-related documentation can be found in BCP-11. Copies of 1541 claims of rights made available for publication and any assurances of 1542 licenses to be made available, or the result of an attempt made to 1543 obtain a general license or permission for the use of such 1544 proprietary rights by implementors or users of this specification can 1545 be obtained from the IETF Secretariat. 1547 The IETF invites any interested party to bring to its attention any 1548 copyrights, patents or patent applications, or other proprietary 1549 rights which may cover technology that may be required to practice 1550 this standard. Please address the information to the IETF Executive 1551 Director. 1553 Full Copyright Statement 1555 Copyright (C) The Internet Society (2003). All Rights Reserved. 1557 This document and translations of it may be copied and furnished to 1558 others, and derivative works that comment on or otherwise explain it 1559 or assist in its implementation may be prepared, copied, published 1560 and distributed, in whole or in part, without restriction of any 1561 kind, provided that the above copyright notice and this paragraph are 1562 included on all such copies and derivative works. However, this 1563 document itself may not be modified in any way, such as by removing 1564 the copyright notice or references to the Internet Society or other 1565 Internet organizations, except as needed for the purpose of 1566 developing Internet standards in which case the procedures for 1567 copyrights defined in the Internet Standards process must be 1568 followed, or as required to translate it into languages other than 1569 English. 1571 The limited permissions granted above are perpetual and will not be 1572 revoked by the Internet Society or its successors or assignees. 1574 This document and the information contained herein is provided on an 1575 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1576 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1577 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1578 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1579 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1581 Acknowledgement 1583 Funding for the RFC Editor function is currently provided by the 1584 Internet Society.