idnits 2.17.1 draft-ietf-aaa-eap-02.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 == Line 1177 has weird spacing: '...tead of arbit...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 30, 2003) is 7605 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 253, but not defined == Unused Reference: 'RADIUS1X' is defined on line 1572, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-ietf-aaa-diameter is -16, but you're referring to -17. == Outdated reference: A later version (-17) exists of draft-ietf-aaa-diameter-nasreq-11 == Outdated reference: A later version (-09) exists of draft-ietf-eap-rfc2284bis-04 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-08 Summary: 1 error (**), 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: December 29, 2003 T. Hiller 5 Lucent Technologies 6 G. Zorn 7 Cisco Systems 8 June 30, 2003 10 Diameter Extensible Authentication Protocol (EAP) Application 11 draft-ietf-aaa-eap-02.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 December 29, 2003. 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-MTU AVP . . . . . . . . . . . . . . . . . . . . . . . . 20 82 4.1.4 EAP-Master-Session-Key AVP . . . . . . . . . . . . . . . . . 20 83 4.1.5 Accounting-EAP-Auth-Method AVP . . . . . . . . . . . . . . . 20 84 5. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . 20 85 5.1 EAP Command AVP Table . . . . . . . . . . . . . . . . . . . 20 86 5.2 Accounting AVP Table . . . . . . . . . . . . . . . . . . . . 22 87 6. RADIUS/Diameter interactions . . . . . . . . . . . . . . . . 22 88 6.1 RADIUS Request forwarded as Diameter Request . . . . . . . . 22 89 6.2 Diameter Request forwarded as RADIUS Request . . . . . . . . 23 90 6.3 Accounting Requests . . . . . . . . . . . . . . . . . . . . 24 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 92 8. Security Considerations . . . . . . . . . . . . . . . . . . 25 93 8.1 Authorization . . . . . . . . . . . . . . . . . . . . . . . 26 94 8.1.1 Direct connection, NAS point of view . . . . . . . . . . . . 27 95 8.1.2 Direct connection, server point of view . . . . . . . . . . 29 96 8.1.3 Diameter agents . . . . . . . . . . . . . . . . . . . . . . 29 97 8.2 Attacks by compromised nodes . . . . . . . . . . . . . . . . 29 98 8.2.1 Impersonating as the user (NAS, agents) . . . . . . . . . . 30 99 8.2.2 Impersonating as the network (NAS, agents) . . . . . . . . . 30 100 8.2.3 Privacy issues (NAS, agents) . . . . . . . . . . . . . . . . 31 101 8.2.4 Offline cryptographic attacks (NAS, agents) . . . . . . . . 31 102 8.2.5 AVP editing (NAS, agents, server) . . . . . . . . . . . . . 31 103 8.2.6 Negotiation attacks (NAS, agents, server) . . . . . . . . . 33 104 8.2.7 Session key distribution (agents, server) . . . . . . . . . 33 105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 106 Normative References . . . . . . . . . . . . . . . . . . . . 34 107 Informative References . . . . . . . . . . . . . . . . . . . 34 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35 109 A. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . 36 110 Intellectual Property and Copyright Statements . . . . . . . 39 112 1. Introduction 114 The Extensible Authentication Protocol (EAP), defined in 115 [RFC2284bis], is an authentication framework which supports multiple 116 authentication mechanisms. EAP may be used on dedicated links as 117 well as switched circuits, and wired as well as wireless links. 119 To date, EAP has been implemented with hosts and routers that connect 120 via switched circuits or dial-up lines using PPP [RFC1661], IEEE 802 121 wired switches [IEEE-802.1X], and IEEE 802.11 wireless access points 122 [IEEE-802.11i]. EAP has also been adopted for IPsec remote access in 123 IKEv2 [IKEv2]. 125 This document specifies the Diameter EAP application that carries EAP 126 packets between a Network Access Server (NAS) working as an EAP 127 Authenticator and a back-end authentication server. The Diameter EAP 128 application is based on NASREQ and is intended for similar 129 environments as NASREQ. 131 In Diameter EAP application, authentication occurs between the EAP 132 client and its home Diameter server. This end-to-end authentication 133 reduces the possibility for fraudulent authentication, such as replay 134 and man-in-the-middle attacks. End-to-end authentication also 135 provides a possibility for mutual authentication, which is not 136 possible with PAP and CHAP in a roaming PPP environment. 138 Diameter EAP application relies heavily on [NASREQ], and in earlier 139 drafts was part of the Diameter NASREQ application. It can also be 140 used in conjunction with NASREQ, selecting the application based on 141 the used authentication mechanism (EAP or PAP/CHAP). Diameter EAP 142 application defines new Command-Codes and new AVPs, and can work 143 together with RADIUS EAP support [RFC2869bis]. 145 2. Extensible Authentication Protocol Support in Diameter 147 2.1 Advertising application support 149 Diameter nodes conforming to this specification MAY advertise support 150 by including the value of TBD in the Auth-Application-Id AVP of the 151 Capabilities-Exchange-Request and Capabilities-Exchange-Answer 152 command [BASE]. 154 If the NAS receives a response with the Result-Code set to 155 DIAMETER_APPLICATION_UNSUPPORTED [BASE], it is an indication that the 156 Diameter server in the home realm does not support EAP. If possible, 157 the access device MAY attempt to negotiate another authentication 158 protocol, such as PAP or CHAP. An access device SHOULD be cautious 159 when determining whether a less secure authentication protocol will 160 be used, since this could be a result of a bidding down attack (see 161 Section 8.2.6). 163 2.2 Protocol Overview 165 The EAP conversation between the authenticating peer and the access 166 device begins with the initiation of EAP within a link layer, such as 167 PPP [RFC1661] or IEEE 802.1X [IEEE-802.1X]. Once EAP has been 168 initiated, the access device will typically send to the Diameter 169 server a Diameter-EAP-Request message with an empty EAP-Payload AVP, 170 signifying an EAP-Start. 172 If the Diameter home server is willing to do EAP authentication, it 173 respons with a Diameter-EAP-Answer message containing an EAP-Payload 174 AVP that includes an encapsulated EAP packet. The Result-Code AVP 175 set to DIAMETER_MULTI_ROUND_AUTH, signifying that a subsequent 176 request is expected. The EAP payload is forwarded by the access 177 device to the EAP client. This is illustrated in the diagram below. 179 User NAS Server 180 | | | 181 | (initiate EAP) | | 182 |<------------------------------>| | 183 | | Diameter-EAP-Request | 184 | | EAP-Payload(EAP Start) | 185 | |------------------------------->| 186 | | | 187 | | Diameter-EAP-Answer | 188 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 189 | | EAP-Payload(EAP Request #1) | 190 | |<-------------------------------| 191 | EAP Request #1 | | 192 |<-------------------------------| | 193 : : : 194 : ...continues... : 196 The initial Diameter-EAP-Answer in a multi-round exchange normally 197 includes an EAP-Request/Identity, requesting the EAP client to 198 identify itself. Upon receipt of the EAP client's EAP-Response, the 199 access device will then issue a second Diameter-EAP-Request message, 200 with the client's EAP payload encapsulated within the EAP-Payload 201 AVP. 203 A preferred approach is for the access device to issue the 204 EAP-Request/Identity message to the EAP client, and forward the 205 EAP-Response/Identity packet, encapsulated within the EAP-Payload 206 AVP, as a Diameter-EAP-Request to the Diameter server (see the 207 diagram below). This alternative reduces the number of Diameter 208 message round trips. When the EAP-Request/Identity message is issued 209 by the access device, it SHOULD interpret the EAP-Response/Identity 210 packet returned by the authenticating peer, and copy its value to a 211 User-Name AVP in Diameter-EAP-Request. This is useful in roaming 212 environments, since the Destination-Realm is needed for routing 213 purposes. Note that this alternative cannot be universally employed, 214 as there are circumstances where a user's identity is not needed 215 (such as when authorization occurs based on a calling or called phone 216 number). 218 User NAS Server 219 | | | 220 | (initiate EAP) | | 221 |<------------------------------>| | 222 | | | 223 | EAP Request(Identity) | | 224 |<-------------------------------| | 225 | | | 226 | EAP Response(Identity) | | 227 |------------------------------->| | 228 | | Diameter-EAP-Request | 229 | | EAP-Payload(EAP Response) | 230 | |------------------------------->| 231 : : : 232 : ...continues... : 234 The conversation continues until the Diameter server sends a 235 Diameter-EAP-Answer with a Result-Code AVP indicating success or 236 failure, and an optional EAP-Payload. The Result-Code AVP is used by 237 the access device to determine whether service is to be provided to 238 the EAP client. The access device MUST NOT rely on the contents of 239 the optional EAP-Payload to determine whether service is to be 240 provided. 242 : ...continued... : 243 : : : 244 | EAP Response #N | | 245 |------------------------------->| | 246 | | Diameter-EAP-Request | 247 | | EAP-Payload(EAP Response #N) | 248 | |------------------------------->| 249 | | | 250 | | Diameter-EAP-Answer | 251 | | Result-Code=DIAMETER_SUCCESS | 252 | | EAP-Payload(EAP Success) | 253 | | [EAP-Master-Session-Key] | 254 | | (authorization AVPs) | 255 | |<-------------------------------| 256 | | | 257 | EAP Success | | 258 |<-------------------------------| | 260 If authorization was requested, a Diameter-EAP-Answer with 261 Result-Code set to DIAMETER_SUCCESS MUST also include the appropriate 262 authorization AVPs required for the service requested (see Section 5 263 and [NASREQ]). If the Result-Code DIAMETER_LIMITED_SUCCESS is 264 returned, this means that the NAS has to get additional authorization 265 AVPs using a separate NASREQ request. This case is described in 266 Section TBD below. Diameter-EAP-Answer messages whose Result-Code 267 AVP is set to DIAMETER_MULTI_ROUND_AUTH MAY include authorization 268 AVPs. 270 A Diameter-EAP-Answer with succesful Result-Code MAY also include an 271 EAP-Master-Session-Key AVP that contains keying material for 272 protecting the communication between the user and the NAS. Exactly 273 how this keying material is used depends on the link layer in 274 question, is beyond the scope of this document. 276 A home Diameter server MAY request EAP re-authentication by issuing 277 the Re-Auth-Request [BASE] message to the Diameter client. 279 Should an EAP authentication session be interrupted due to a home 280 server failure, the session MAY be directed to an alternate server, 281 but the authentication session will have to be restarted from the 282 beginning. 284 2.3 Sessions and NASREQ interaction 286 (NOTE: This section has not received sufficient WG discussion yet, 287 and is likely to be changed in the future.) 289 The previous section introduced the basic protocol between the NAS 290 and the home server. Since the Diameter-EAP-Answer message may 291 include a Master Session Key (MSK) for protecting the communication 292 between the user and the NAS, care must be taken to ensure that this 293 key does not fall into wrong hands. 295 Basic Diameter security mechanisms (IPsec and TLS) protect Diameter 296 messages hop-by-hop. Since there are currently no end-to-end 297 (NAS-to-home server) security mechanisms defined for Diameter, this 298 section describes some possible scenarios how the messages could be 299 transported protected using these hop-by-hop mechanisms. 301 The list of scenarios is not intended to be exhaustive, and it is 302 possible to combine them. For instance, the first proxy agent after 303 the NAS could use redirects as in scenario 2 to bypass any additional 304 proxy agents. 306 2.3.1 Scenario 1: Direct connection 308 The simplest case is when the NAS contacts the home server directly. 309 All the authorization AVPs are delivered by the home server, as is 310 EAP keying material. 312 NAS home server 313 | | 314 | Diameter-EAP-Request | 315 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 316 | EAP-Payload(EAP Start) | 317 |---------------------------------------------------------------->| 318 | | 319 | Diameter-EAP-Answer | 320 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 321 | EAP-Payload(EAP Request) | 322 |<----------------------------------------------------------------| 323 | | 324 : ...more EAP Request/Response pairs... : 325 | | 326 | Diameter-EAP-Request | 327 | EAP-Payload(EAP Response) | 328 |---------------------------------------------------------------->| 329 | | 330 | Diameter-EAP-Answer | 331 | Result-Code=DIAMETER_SUCCESS | 332 | EAP-Payload(EAP Success) | 333 | EAP-Master-Session-Key | 334 | (authorization AVPs) | 335 |<----------------------------------------------------------------| 337 This scenario is the most likely to be used in small networks, or in 338 cases where Diameter agents are not needed to provide routing or 339 additional authorization AVPs. 341 2.3.2 Scenario 2: Direct connection with redirects 343 In this scenario the NAS uses a redirect agent to locate the home 344 server, and the rest of the session proceeds as before. 346 NAS Local redirect agent Home server 347 | | | 348 | Diameter-EAP-Request | | 349 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 350 | EAP-Payload(EAP Start) | | 351 |------------------------------->| | 352 | | | 353 | Diameter-EAP-Answer | 354 | Redirect-Host=homeserver.example.com | 355 | Redirect-Host-Usage=REALM_AND_APPLICATION | 356 |<-------------------------------| | 357 | : | 358 | Diameter-EAP-Request : | 359 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 360 | EAP-Payload(EAP Start) : | 361 |---------------------------------------------------------------->| 362 | : | 363 : ...rest of the session continues as in first case... : 364 : : : 366 The advantage of this scenario is that knowledge of realms and home 367 servers is centralized to a redirect agent, and it is not necessary 368 to modify the NAS configuration when, e.g., a new roaming agreement 369 is done. 371 2.3.3 Scenario 3: Direct EAP, authorization via agents 373 In this scenario the EAP authentication is done directly with the 374 home server (with Auth-Request-Type set to AUTHENTICATE_ONLY), and 375 the authorization AVPs are retrieved from the local proxy agents. 376 This scenario is intended for environments where the home server 377 cannot provide all the necessary authorization AVPs to the NAS. 379 NAS Local proxy agent Home server 380 | : | 381 | Diameter-EAP-Request : | 382 | Auth-Request-Type=AUTHENTICATE_ONLY | 383 | EAP-Payload(EAP Start) : | 384 |---------------------------------------------------------------->| 385 | : | 386 | : Diameter-EAP-Answer | 387 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 388 | : EAP-Payload(EAP Request) | 389 |<----------------------------------------------------------------| 390 | : | 391 : ...more EAP Request/Response pairs... : 392 | : | 393 | Diameter-EAP-Request : | 394 | EAP-Payload(EAP Response) : | 395 |---------------------------------------------------------------->| 396 | : | 397 | : Diameter-EAP-Answer | 398 | : Result-Code=DIAMETER_SUCCESS | 399 | : EAP-Payload(EAP Success) | 400 | : EAP-Master-Session-Key | 401 | : (authorization AVPs) | 402 |<----------------------------------------------------------------| 403 | | | 404 | AA-Request | | 405 | Auth-Request-Type=AUTHORIZE_ONLY | 406 | (some AVPs from first session) | | 407 |------------------------------->| | 408 | | | 409 | AA-Answer | | 410 | Result-Code=DIAMETER_SUCCESS | | 411 | (authorization AVPs) | | 412 |<-------------------------------| | 414 The NASREQ application is used here for authorization because the 415 realm-specific routing table does support routing based on 416 application, but not more...TO BE CLARIFIED. 418 A second possibility is that the home server signals the NAS to 419 perform a separate authorization step. In this case, the NAS begins 420 the Diameter EAP session with 421 Auth-Request-Type=AUTHORIZE_AUTHENTICATE. The last 422 Diameter-EAP-Answer from the home server contains 423 Result-Code=DIAMETER_LIMITED_SUCCESS, so the NAS does additional 424 AUTHORIZE_ONLY NASREQ step. 426 NAS Local proxy agent Home server 427 | : | 428 | Diameter-EAP-Request : | 429 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 430 | EAP-Payload(EAP Start) : | 431 |---------------------------------------------------------------->| 432 | : | 433 | : Diameter-EAP-Answer | 434 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 435 | : EAP-Payload(EAP Request) | 436 |<----------------------------------------------------------------| 437 | : | 438 : ...more EAP Request/Response pairs... : 439 | : | 440 | Diameter-EAP-Request : | 441 | EAP-Payload(EAP Response) : | 442 |---------------------------------------------------------------->| 443 | : | 444 | : Diameter-EAP-Answer | 445 | Result-Code=DIAMETER_LIMITED_SUCCESS | 446 | : EAP-Payload(EAP Success) | 447 | : EAP-Master-Session-Key | 448 | : (authorization AVPs) | 449 |<----------------------------------------------------------------| 450 | | | 451 | AA-Request | | 452 | Auth-Request-Type=AUTHORIZE_ONLY | 453 | (some AVPs from first session) | | 454 |------------------------------->| | 455 | | | 456 | AA-Answer | | 457 | Result-Code=DIAMETER_SUCCESS | | 458 | (authorization AVPs) | | 459 |<-------------------------------| | 461 2.3.4 Scenario 4: Proxy agents 463 Same as scenario 1, but through proxies. Note that in this case the 464 proxies can see the EAP session keys, so this is not suitable for 465 environments where proxies can't be trusted for this. 467 NAS Local proxy/relay agent Home server 468 | | | 469 | Diameter-EAP-Request | | 470 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 471 | EAP-Payload(EAP Start) | | 472 |------------------------------->|------------------------------->| 473 | | | 474 | | Diameter-EAP-Answer | 475 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 476 | | EAP-Payload(EAP Request) | 477 |<-------------------------------|<-------------------------------| 478 | : | 479 : ...more EAP Request/Response pairs... : 480 | : | 481 | Diameter-EAP-Request | | 482 | EAP-Payload(EAP Response) | | 483 |------------------------------->|------------------------------->| 484 | | | 485 | | Diameter-EAP-Answer | 486 | | Result-Code=DIAMETER_SUCCESS | 487 | | EAP-Payload(EAP Success) | 488 | | EAP-Master-Session-Key | 489 | | (authorization AVPs) | 490 |<-------------------------------|<-------------------------------| 492 2.4 Invalid packets 494 While acting as a pass-through, the NAS MUST validate the EAP header 495 fields (Code, Identifier, Length) prior to forwarding an EAP packet 496 to or from the Diameter server. On receiving an EAP packet from the 497 peer, the NAS checks the Code (2) and Length fields, and matches the 498 Identifier value against the current Identifier, supplied by the 499 Diameter server in the most recently validated EAP Request. On 500 receiving an EAP packet from the Diameter server (encapsulated within 501 a Diameter-EAP-Answer), the NAS checks the Code (1) and Length 502 fields, then updates the current Identifier value. Pending EAP 503 Responses that do not match the current Identifier value are silently 504 discarded by the NAS. 506 Since EAP method fields (Type, Type-Data) are typically not validated 507 by a NAS operating as a pass-through, despite these checks it is 508 possible for a NAS to forward an invalid EAP packet to or from the 509 Diameter server. 511 A Diameter server receiving an EAP-Payload AVP it does not understand 512 SHOULD make the determination of whether the error is fatal or 513 non-fatal based on the EAP Type. A Diameter server determining that 514 a fatal error has occurred MUST send an a Diameter-EAP-Answer with a 515 failure Result-Code and an EAP-Payload AVP encapsulating an EAP 516 Failure packet. A Diameter server determining that a non-fatal error 517 has occurred MUST send a Diameter-EAP-Answer with an 518 EAP-Reissued-Payload AVP encapsulating the previous EAP Request sent 519 by the server. 521 When receiving a Diameter-EAP-Answer with an EAP-Reissued-Payload 522 AVP, the NAS SHOULD discard the EAP-Response packet most recently 523 transmitted to the Diameter server and check whether additional EAP 524 Response packets have been received matching the current Identifier 525 value. If so, a new EAP Response packet, if available, MUST be sent 526 to the Diameter server within an Diameter-EAP-Request. If no EAP 527 Response packet is available, then the EAP Request encapsulated 528 within the EAP-Reissued-Payload AVP is sent to the peer, and the 529 retransmission timer is reset. 531 In order to provide protection against Denial of Service (DoS) 532 attacks, it is advisable for the NAS to allocate a finite buffer for 533 EAP packets received from the peer, and to discard packets according 534 to an appropriate policy once that buffer has been exceeded. Also, 535 the Diameter server is advised to permit only a modest number of 536 invalid EAP packets within a single session, prior to terminating the 537 session with TBD. By default a value of 5 invalid EAP packets is 538 recommended. 540 2.5 Retransmission 542 As noted in [RFC2284bis], if an EAP packet is lost in transit between 543 the authenticating peer and the NAS (or vice versa), the NAS will 544 retransmit. 546 It may be necessary to adjust retransmission strategies and 547 authentication timeouts in certain cases. For example, when a token 548 card is used, additional time may be required to allow the user to 549 find the card and enter the token. Since the NAS will typically not 550 have knowledge of the required parameters, these need to be provided 551 by the Diameter server. 553 If a Multi-Round-Time-Out AVP [BASE] is present in an 554 Diameter-EAP-Answer message that also contains an EAP-Payload AVP, 555 that value is used to set the EAP retransmission timer for that EAP 556 Request, and that Request alone. 558 2.6 Fragmentation 560 Using the EAP-Payload AVP, it is possible for the Diameter server to 561 encapsulate an EAP packet that is larger than the MTU on the link 562 between the NAS and the peer. Since it is not possible for the 563 Diameter server to use MTU discovery to ascertain the link MTU, an 564 EAP-MTU attribute may be included in a Diameter-EAP-Request message 565 so as to provide the Diameter server with this information. 567 A Diameter server having received an EAP-MTU attribute in a 568 Diameter-EAP-Request message MUST NOT send any subsequent packet in 569 this EAP conversation containing EAP-Payload attribute whose length 570 exceeds the length specified by the EAP-MTU value. 572 2.7 Accounting 574 This document specifies one additional AVP for accounting messages. 575 One or more Accounting-EAP-Auth-Method AVPs (see Section 4.1.5) MAY 576 be included in Accounting-Request messages to indicate the EAP 577 method(s) used to authenticate the user. 579 If the NAS has authenticated the user with a locally implemented EAP 580 method, it knows the method used and SHOULD include it in an 581 Accounting-EAP-Auth-Method AVP. 583 If the authentication was done using Diameter-EAP-Request/Answer 584 messages, the Diameter server SHOULD include one more more 585 Accounting-EAP-Auth-Method AVPs in Diameter-EAP-Answer packets with a 586 successful result code. In this case, the NAS SHOULD include these 587 AVPs in Accounting-Request messages. 589 2.8 Usage guidelines 591 2.8.1 User-Name AVP 593 Unless the access device interprets the EAP-Response/Identity packet 594 returned by the authenticating peer, it will not have access to the 595 user's identity. Furthermore, some EAP methods support identity 596 protection where the user's real identity is not included in 597 EAP-Response/Identity. Therefore, the Diameter Server SHOULD return 598 the user's identity by inserting it in the User-Name AVP of 599 subsequent Diameter-EAP-Answer packets. Without the user's identity, 600 the Session-Id AVP MAY be used for accounting and billing, however 601 operationally this could be very difficult to manage. 603 2.8.2 Conflicting AVPs 605 A Diameter-EAP-Answer message containing an EAP-Payload of type 606 EAP-Success or EAP-Failure MUST NOT have the Result-Code AVP set to 607 DIAMETER_MULTI_ROUND_AUTH. Also, the Result-Code SHOULD match the 608 contained EAP packet (successful Result-Code if EAP-Success, and a 609 failure Result-Code for EAP-Failure). TO BE WRITTEN: clarify this. 611 2.8.3 Displayable messages 613 The Reply-Message AVP [NASREQ] contains text which may be displayed 614 to the user. Note that the NAS does not necessarily have any 615 facility for actually sending these messages to the user. In any 616 case, the NAS MUST NOT manufacture any EAP packets (such as 617 EAP-Request/Notification) from Reply-Message AVPs. 619 2.8.4 Role reversal 621 Some environments where EAP is used, such as PPP, support 622 peer-to-peer operation. That is, both parties act as authenticators 623 and authenticatees at the same time, in two simultaneous and 624 independent EAP conversations. 626 This specification is intended for communication between EAP 627 (passthrough) authenticator and backend authentication server. A 628 Diameter client MUST NOT send a Diameter-EAP-Request encapsulating an 629 EAP Request packet, and a Diameter server receiving such packet MUST 630 respond with a failure Result-Code.. 632 2.8.5 Alternative Uses 634 Currently the conversation between the backend authentication server 635 and the Diameter server is proprietary because of lack of 636 standardization. In order to increase standardization and provide 637 interoperability between Diameter vendors and backend security 638 vendors, it is recommended that Diameter-encapsulated EAP be used for 639 this conversation. 641 This has the advantage of allowing the Diameter server to support EAP 642 without the need for authentication-specific code within the Diameter 643 server. Authentication-specific code can then reside on a back-end 644 authentication server instead. 646 In the case where Diameter-encapsulated EAP is used in a conversation 647 between a Diameter server and a backend authentication server, the 648 latter will typically return an Diameter-EAP-Answer/EAP-Payload/ 649 EAP-Success message without inclusion of the expected authorization 650 AVPs required in a successful response. This means that the Diameter 651 server MUST add these attributes prior to sending an 652 Diameter-EAP-Answer/EAP-Payload/EAP-Success message to the access 653 device. 655 3. Command-Codes 657 This section defines new Command-Code values that MUST be supported 658 by all Diameter implementations conforming to this specification. 659 The following Command Codes are defined in this section: 661 Command-Name Abbrev. Code Reference 662 -------------------------------------------------------- 663 Diameter-EAP-Request DER 268 3.1 664 Diameter-EAP-Answer DEA 268 3.2 666 3.1 Diameter-EAP-Request (DER) Command 668 The Diameter-EAP-Request (DER) command, indicated by the Command-Code 669 field set to 268 and the 'R' bit set in the Command Flags field, is 670 sent by a Diameter client to a Diameter server and conveys an 671 EAP-Response from the EAP client. The Diameter-EAP-Request MUST 672 contain one EAP-Payload AVP, which contains the actual EAP payload. 673 An EAP-Payload AVP with no data MAY be sent to the Diameter server to 674 initiate an EAP authentication session. 676 The DER message MAY be the result of a multi-round authentication 677 exchange, which occurs when the DEA is received with the Result-Code 678 AVP set to DIAMETER_MULTI_ROUND_AUTH [BASE]. A subsequent DER 679 message MUST include any State AVPs [NASREQ] that were present in the 680 DEA. For re-authentication, it is recommended that the Identity 681 request be skipped in order to reduce the number of authentication 682 round trips. This is only possible when the user's identity is 683 already known by the home Diameter server. 685 Message format 687 ::= < Diameter Header: 268, REQ, PXY > 688 < Session-Id > 689 { Auth-Application-Id } 690 { Origin-Host } 691 { Origin-Realm } 692 { Destination-Realm } 693 { Auth-Request-Type } 694 [ NAS-Port ] 695 [ NAS-Port-Id ] 696 [ Origin-State-Id ] 697 [ Destination-Host ] 699 [ NAS-Identifier ] 700 [ NAS-IP-Address ] 701 [ NAS-IPv6-Address ] 702 [ NAS-Port-Type ] 703 [ Port-Limit ] 704 [ User-Name ] 705 { EAP-Payload } 706 { EAP-MTU } 707 [ Service-Type ] 708 [ Idle-Timeout ] 709 [ State ] 710 [ Authorization-Lifetime ] 711 [ Auth-Grace-Period ] 712 [ Auth-Session-State ] 713 [ Session-Timeout ] 714 [ Callback-Number ] 715 [ Called-Station-Id ] 716 [ Calling-Station-Id ] 717 * [ Class ] 718 [ Originating-Line-Info ] 719 [ Connect-Info ] 720 * [ Framed-Compression ] 721 [ Framed-Interface-Id ] 722 [ Framed-IP-Address ] 723 * [ Framed-IPv6-Prefix ] 724 [ Framed-IP-Netmask ] 725 [ Framed-MTU ] 726 [ Framed-Protocol ] 727 * [ Tunneling ] 728 * [ Proxy-Info ] 729 * [ Route-Record ] 730 * [ AVP ] 732 3.2 Diameter-EAP-Answer (DEA) Command 734 The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code 735 field set to 268 and the 'R' bit cleared in the Command Flags field, 736 is sent by the Diameter server to the client for one of the following 737 reasons: 739 1. The message is part of a multi-round authentication exchange, and 740 the server is expecting a subsequent Diameter-EAP-Request. This 741 is indicated by setting the Result-Code to 742 DIAMETER_MULTI_ROUND_AUTH, and MAY include zero or more State 743 AVPs. 745 2. the EAP client has been successfully authenticated and 746 authorized, in which case the message MUST include the 747 Result-Code AVP indicating success, and SHOULD include an 748 EAP-Payload of type EAP-Success. This event MUST cause the 749 access device to provide service to the EAP client. 751 3. The EAP client has not been successfully authenticated and/or 752 authorized, and the Result-Code AVP is set to indicate failure. 753 This message SHOULD include an EAP-Payload, but this AVP is not 754 used to determine whether service is to be provided. 756 If the message from the Diameter client included a request for 757 authorization, a successful response MUST include the authorization 758 AVPs that are relevant to the service being provided. 760 Message format 762 ::= < Diameter Header: 268, PXY > 763 < Session-Id > 764 { Auth-Application-Id } 765 { Auth-Request-Type } 766 { Result-Code } 767 { Origin-Host } 768 { Origin-Realm } 769 [ User-Name ] 770 [ EAP-Payload ] 771 [ Multi-Round-Time-Out ] 772 [ Service-Type ] 773 * [ Class ] 774 * [ Configuration-Token ] 775 [ Acct-Interim-Interval ] 776 [ Error-Message ] 777 [ Error-Reporting-Host ] 778 [ Idle-Timeout ] 779 [ Authorization-Lifetime ] 780 [ Auth-Grace-Period ] 781 [ Auth-Session-State ] 782 [ Re-Auth-Request-Type ] 783 [ Session-Timeout ] 784 [ State ] 785 * [ Reply-Message ] 786 [ Termination-Action ] 787 [ Origin-State-Id ] 788 * [ Filter-Id ] 789 [ Port-Limit ] 790 [ Callback-Id ] 791 [ Callback-Number ] 792 [ 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 402) 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 This AVP MAY be included in Diameter-EAP-Answer messages to signal 835 the NAS that the EAP packet in it sent was not a satisfactory 836 response (see Section 2.4 for discussion). To ease RADIUS 837 translation, this AVP contains the previous EAP packet sent by the 838 Diameter server. 840 4.1.3 EAP-MTU AVP 842 The EAP-MTU AVP (AVP Code TBD) is of type Unsigned32. Its use is 843 described in Section 2.6. 845 4.1.4 EAP-Master-Session-Key AVP 847 The EAP-Master-Session-Key AVP (AVP Code TBD) is of type OctetString. 848 It is used by the Diameter server...TBD 850 4.1.5 Accounting-EAP-Auth-Method AVP 852 The Accounting-EAP-Auth-Method AVP (AVP Code 401) is of type 853 Unsigned64. In case of expanded types [RFC2284bis, Section 5.7], the 854 least significant 32 bits contain the Vendor-Type field, and the next 855 24 bits contain the Vendor-Id field. 857 The use of this AVP is described in Section 2.7. 859 5. AVP Occurrence Tables 861 The following tables use these symbols: 863 0 The AVP MUST NOT be present in the message 864 0+ Zero or more instances of the AVP MAY be present in the 865 message 866 0-1 Zero or one instance of the AVP MAY be present in the 867 message 868 1 One instance of the AVP MUST be present in the message 870 Note that AVPs that can only be present within a Grouped AVP are not 871 represented in these tables. 873 5.1 EAP Command AVP Table 875 The following table lists the AVPs that may be present in the DER and 876 DEA Commands, defined in this document; however, the AVPs listed are 877 defined both here and in [NASREQ]. 879 +---------------+ 880 | Command-Code | 881 |-------+-------+ 882 Attribute Name | DER | DEA | 883 ------------------------------------|-------+-------| 884 Accounting-EAP-Auth-Method | 0 | 0+ | 885 Acct-Interim-Interval [BASE] | 0 | 0-1 | 886 Auth-Application-Id [BASE] | 1 | 1 | 887 Auth-Grace-Period [BASE] | 0-1 | 0-1 | 888 Auth-Request-Type [BASE] | 1 | 1 | 889 Auth-Session-State [BASE] | 0-1 | 0-1 | 890 Authorization-Lifetime [BASE] | 0-1 | 0-1 | 891 Callback-Id [NASREQ] | 0 | 0-1 | 892 Callback-Number [NASREQ] | 0-1 | 0-1 | 893 Called-Station-Id [NASREQ] | 0-1 | 0 | 894 Calling-Station-Id [NASREQ] | 0-1 | 0 | 895 Class [BASE] | 0+ | 0+ | 896 Configuration-Token [NASREQ] | 0 | 0+ | 897 Connect-Info [NASREQ] | 0-1 | 0 | 898 Destination-Host [BASE] | 0-1 | 0 | 899 Destination-Realm [BASE] | 1 | 0 | 900 EAP-Payload | 1 | 0-1 | 901 EAP-MTU | 0-1 | 0 | 902 Error-Message [BASE] | 0 | 0-1 | 903 Error-Reporting-Host [BASE] | 0 | 0-1 | 904 Failed-AVP [BASE] | 0+ | 0+ | 905 Filter-Id [NASREQ] | 0 | 0+ | 906 Framed-Appletalk-Link [NASREQ] | 0 | 0-1 | 907 Framed-Appletalk-Network [NASREQ] | 0 | 0+ | 908 Framed-Appletalk-Zone [NASREQ] | 0 | 0-1 | 909 Framed-Compression [NASREQ] | 0+ | 0+ | 910 Framed-Interface-Id [NASREQ] | 0-1 | 0-1 | 911 Framed-IP-Address [NASREQ] | 0-1 | 0-1 | 912 Framed-IP-Netmask [NASREQ] | 0-1 | 0-1 | 913 Framed-IPv6-Prefix [NASREQ] | 0+ | 0+ | 914 Framed-IPv6-Pool [NASREQ] | 0 | 0-1 | 915 Framed-IPv6-Route [NASREQ] | 0 | 0+ | 916 Framed-IPX-Network [NASREQ] | 0 | 0-1 | 917 Framed-MTU [NASREQ] | 0-1 | 0-1 | 918 Framed-Pool [NASREQ] | 0 | 0-1 | 919 Framed-Protocol [NASREQ] | 0-1 | 0-1 | 920 Framed-Route [NASREQ] | 0 | 0+ | 921 Framed-Routing [NASREQ] | 0 | 0-1 | 922 Idle-Timeout [NASREQ] | 0-1 | 0-1 | 923 Multi-Round-Time-Out [BASE] | 0 | 0-1 | 924 NAS-Filter-Rule [NASREQ] | 0 | 0+ | 925 NAS-Identifier [NASREQ] | 0-1 | 0 | 926 NAS-IP-Address [NASREQ] | 0-1 | 0 | 927 NAS-IPv6-Address [NASREQ] | 0-1 | 0 | 928 NAS-Port [NASREQ] | 0-1 | 0 | 929 NAS-Port-Id [NASREQ] | 0-1 | 0 | 930 NAS-Port-Type [NASREQ] | 0-1 | 0 | 931 NAS-Session-Key [NASREQ] | 0 | 0+ | 932 Originating-Line-Info [NASREQ] | 0-1 | 0 | 933 Origin-Host [BASE] | 1 | 1 | 934 Origin-Realm [BASE] | 1 | 1 | 935 Origin-State-Id [BASE] | 0-1 | 0-1 | 936 Port-Limit [NASREQ] | 0-1 | 0-1 | 937 Proxy-Info [BASE] | 0+ | 0+ | 938 Re-Auth-Request-Type [BASE] | 0 | 0-1 | 939 Redirect-Host [BASE] | 0 | 0+ | 940 Redirect-Host-Usage [BASE] | 0 | 0-1 | 941 Redirect-Max-Cache-Time [BASE] | 0 | 0-1 | 942 Reply-Message [NASREQ] | 0 | 0+ | 943 Result-Code [BASE] | 0 | 1 | 944 Route-Record [BASE] | 0+ | 0 | 945 Service-Type [NASREQ] | 0-1 | 0-1 | 946 Session-Id [BASE] | 1 | 1 | 947 Session-Timeout [BASE] | 0-1 | 0-1 | 948 State [NASREQ] | 0-1 | 0-1 | 949 Termination-Action [NASREQ] | 0 | 0-1 | 950 Termination-Cause [BASE] | 0 | 0-1 | 951 Tunneling [NASREQ] | 0+ | 0+ | 952 User-Name [BASE] | 0-1 | 0-1 | 954 5.2 Accounting AVP Table 956 The table in this section is used to represent which AVPs defined in 957 this document are to be present in the Accounting messages, defined 958 in [BASE]. 960 +-----------+ 961 | Command | 962 | Code | 963 |-----+-----+ 964 Attribute Name | ACR | ACA | 965 ---------------------------------------|-----+-----+ 966 Accounting-EAP-Auth-Method | 0+ | 0 | 968 6. RADIUS/Diameter interactions 970 Section 9 of [NASREQ] describes basic guidelines that translation 971 agents may follow when translating between RADIUS and Diameter 972 protocols. This section gives additional guidelines for the Diameter 973 EAP application. Note that this document does not restrict 974 implementations from creating additional methods, as long as the 975 translation function doesn't violate the RADIUS or the Diameter 976 protocols. 978 6.1 RADIUS Request forwarded as Diameter Request 980 RADIUS Access-Request to Diameter-EAP-Request: 982 o RADIUS EAP-Message attribute(s) are translated to a Diameter 983 EAP-Payload AVP. If multiple RADIUS EAP-Message attributes are 984 present, they are concatenated and translated to a single Diameter 985 EAP-Payload AVP. 987 o An empty RADIUS EAP-Message attribute (with length 2) signifies 988 EAP-Start, and it is translated to an empty EAP-Payload AVP. 990 o If the RADIUS Framed-MTU attribute is present, it is translated to 991 the Diameter EAP-MTU AVP. 993 Diameter-EAP-Answer to RADIUS Access-Accept/Reject/Challenge: 995 o Diameter EAP-Payload AVP is translated to RADIUS EAP-Message 996 attribute(s). If necessary, the value is split into multiple 997 RADIUS EAP-Message attributes. 999 o Diameter EAP-Reissued-Payload AVP is translated to a message that 1000 contains RADIUS EAP-Message attribute(s), and a RADIUS Error-Cause 1001 attribute [DynAuth] with value 202 (decimal), "Invalid EAP Packet 1002 (Ignored)" [RFC2869bis]. 1004 o As described in [NASREQ], if the Result-Code AVP set to 1005 DIAMETER_MULTI_ROUND_AUTH and the Multi-Round-Time-Out AVP is 1006 present, it is translated to the RADIUS Session-Timeout attribute. 1008 o Diameter EAP-Master-Session-Key AVP can be translated to the 1009 vendor-specific RADIUS MS-MPPE-Recv-Key and MS-MPPE-Send-Key 1010 attributes [RFC2548]. The first up to 32 octets of the key is 1011 stored into MS-MPPE-Recv-Key, and the next up to 32 octets (if 1012 present) are stored into MS-MPPE-Send-Key. 1014 o Diameter Accounting-EAP-Auth-Method AVPs, if present, are 1015 discarded. 1017 6.2 Diameter Request forwarded as RADIUS Request 1019 Diameter-EAP-Request to RADIUS Access-Request: 1021 o The Diameter EAP-Payload AVP is translated to RADIUS EAP-Message 1022 attribute(s). 1024 o An empty Diameter EAP-Payload AVP signifies EAP-Start, and it is 1025 translated to an empty RADIUS EAP-Message attribute. 1027 o If the Diameter EAP-MTU AVP is present, it is translated to the 1028 RADIUS Framed-MTU attribute. If both an EAP-MTU AVP and a 1029 Framed-MTU AVP are present in the Diameter-EAP-Request, the 1030 Framed-MTU AVP is discarded. 1032 o The type (or expanded type) field from the EAP-Payload AVP can be 1033 saved either in a local state table, or encoded in a RADIUS 1034 Proxy-State attribute. This information is needed to construct an 1035 Accounting-EAP-Auth-Method AVP for the answer message (see below). 1037 RADIUS Access-Accept/Reject/Challenge to Diameter-EAP-Answer: 1039 o If the RADIUS Access-Challenge message does not contain an 1040 Error-Cause attribute [DynAuth] with value 202 (decimal), "Invalid 1041 EAP Packet (Ignored)" [RFC2869bis], any RADIUS EAP-Message 1042 attributes are translated to a Diameter EAP-Payload AVP, 1043 concatenating them if multiple attributes are present. 1045 o If the Error-Cause attribute with value 202 is present, any RADIUS 1046 EAP-Message attributes are translated to a Diameter 1047 EAP-Reissued-Payload AVP, concatenating them if multiple 1048 attributes are present. 1050 o As described in [NASREQ], if the Session-Timeout attribute is 1051 present in a RADIUS Access-Challenge message, it is translated to 1052 the Diameter Multi-Round-Time-Out AVP. 1054 o If the vendor-specific RADIUS MS-MPPE-Recv-Key and/or 1055 MS-MPPE-Send-Key attributes [RFC2548] are present, they can be 1056 translated to a Diameter EAP-Master-Session-Key AVP. Their values 1057 are concatenated (MS-MPPE-Recv-Key first, MS-MPPE-Send-Key next), 1058 and the concatenated value is stored into a Diameter 1059 EAP-Master-Session-Key AVP. 1061 o If the Diameter-EAP-Answer will have a succesful result code, the 1062 saved state (see above) can be used to construct an 1063 Accounting-EAP-Auth-Method AVP. 1065 6.3 Accounting Requests 1067 In Accounting-Requests, the vendor-specific RADIUS MS-Acct-EAP-Type 1068 attribute [RFC2548] can be translated to a Diameter 1069 Accounting-EAP-Auth-Method AVP, and vice versa. 1071 When translating from Diameter to RADIUS, note that the 1072 MS-Acct-EAP-Type attribute does not support expanded EAP types. Type 1073 values greater than 255 should be translated to type 254. 1075 7. IANA Considerations 1077 This document does not create any new namespaces to be maintained by 1078 IANA, but it defines new values in namespaces that have been defined 1079 in the Diameter Base protocol [BASE]. 1081 o This specification assigns the value 268 from the Command Code 1082 namespace defined in [BASE]. See Section 3 for more information. 1084 o This specification assigns the values TBD from the AVP Code 1085 namespace defined in [BASE]. See Section 4.1 for the assignment 1086 of the namespace in this specification. 1088 o This specification assigns the value TBD from the Application 1089 Identifier namespace defined in [BASE]. See Section TBD above for 1090 more information. 1092 8. Security Considerations 1094 (NOTE: This section is still very much under construction, and will 1095 be revised in later versions. Comments are welcome!) 1097 Diameter peer-to-peer connections can be protected with IPsec or TLS. 1098 These mechanisms are believed to provide sufficient protection under 1099 the normal Internet threat model--that is, assuming the authorized 1100 nodes engaging in the protocol have not been compromised, but the 1101 attacker has complete control over the communication channels between 1102 them. This includes eavesdropping, message modification, insertion, 1103 man-in-the-middle and replay attacks. The details and related 1104 security considerations are discussed in [BASE]. 1106 The rest of this section deals with two important topics that are not 1107 completely covered by [BASE] and [NASREQ]: authorization and attacks 1108 by compromised nodes. 1110 Authorization here means the act of determining if a Diameter message 1111 received from an authenticated Diameter peer should be accepted (and 1112 not authorization of users requesting network access from a NAS). 1113 The Diameter base protocol gives only overall guidelines and does not 1114 specify any particular mechanisms, and neither does this document. 1115 However, Section 8.1 gives some examples of possible authorization 1116 mechanisms to illustrate the importance of proper authorization, and 1117 to provide concrete examples for discussing authorization-related 1118 security considerations (it might be useful to place some of this 1119 text in a separate "Diameter authentication and authorization" 1120 document--if you're interested in writing that, contact the authors). 1122 The last part of this section deals with attacks by nodes that have 1123 been properly authorized (to function as a NAS, Diameter agent, or 1124 Diameter server) but have been compromised. In general, it is not 1125 possible to completely protect against attacks by compromised nodes, 1126 but this section offers some advice that can be used to limit the 1127 extent of the damage. 1129 Note that much of the discussion in this section is not really 1130 specific to Diameter EAP application, but applies to many other 1131 Diameter applications as well. 1133 8.1 Authorization 1135 When two Diameter nodes communicate, they can authenticate each other 1136 using IPsec or TLS. However, just authentication is not 1137 enough--authorization is also needed. Authorization tries to answer 1138 questions such as the following. 1140 o When a Diameter server receives a Diameter-EAP-Request, is the 1141 node that sent it authorized to act as a NAS for the specific 1142 user, service type, and so on, in question? 1144 o Correspondingly, when the NAS contacts the server to send the 1145 Diameter-EAP-Request, is the server is authorized to act as home 1146 server for the realm in question? 1148 o Similar considerations apply to Accounting-Request/Answer 1149 messages: Is the NAS authorized to send this accounting request?, 1150 Is the server authorized to act as an accounting server for this 1151 session? 1153 o In Re-Auth-Request and Abort-Session-Request, the command is 1154 initiated by the server, but similar considerations apply. 1156 o Session-Termination-Request/Answer (TBW) 1158 o Hop-by-hop messages (Capabilities-Exchange-Request/Answer, 1159 Device-Watchdog-Request/Answer, Disconnect-Peer-Request/Answer) 1160 are not discussed in this section. 1162 Authorization is often left as an implementation issue, and this is 1163 indeed a reasonable approach when authorization is based on local 1164 access control lists (ACLs). In this case, other nodes do not need 1165 to know how ACLs are specified or implemented. It is also possible 1166 to implement complex authorization conditions (for instance, 1167 "ap1788.example.com is authorized to act as a WLAN access point for 1168 users whose name does not contain the letter "a", but only between 1169 8AM and 4PM", to give a rather unlikely example). 1171 However, when authorization can't be based solely on local ACLs, the 1172 issue becomes significantly more complex. First, interoperability 1173 between different vendors requires public specifications, and 1174 authorization can't be left solely as an "implementation issue" 1175 anymore. Second, these specifications are likely to support only 1176 very simple authorizations (such as "authorized to act as Diameter 1177 client"), instead of arbitrarily complex rules like the nonsense 1178 example given above. 1180 The authorization requirements also depend on many issues, such as 1181 the size of the network, the trust relationships between the nodes, 1182 and the Diameter application and commands in question. 1184 8.1.1 Direct connection, NAS point of view 1186 Let's first consider the case where the NAS contacts the home server 1187 directly. There are two somewhat different subcases, depending on 1188 how the NAS finds the home server. 1190 In the simplest case, the NAS has all the home servers statically 1191 configured in its peer table and realm-based routing table (see 1192 [BASE], Sections 2.6 and 2.7). This is likely to occur small 1193 networks. Authentication can be based either on certificates or 1194 pre-shared keys. 1196 In this case authorization is most likely based on the realm-based 1197 routing table (that can be considered to contain an "implicit" local 1198 ACL). To give a concrete example, if "mars.example.com" is 1199 configured as the server for realm "example.com", this can be 1200 considered to imply that mars.example.com is authorized to act as the 1201 home server for that realm. 1203 The situation is a bit different if the NAS finds the home server 1204 using, for instance, DNS queries or redirect messages. In this case, 1205 authentication is probably based on certificates, but how does a NAS 1206 know if the server authenticated as "mars.example.com" is authorized 1207 to act as the home server for the realm "example.com"? A couple of 1208 possibilities follow: 1210 o "Server CA": A certificate issued by some particular Certificate 1211 Authority (CA) implies authorization to act as the home server 1212 (for all realms). This provides rather coarse-grained 1213 authorization, and has obvious problems if the same CA also issues 1214 certificates for other purposes (such as NASes or web servers). 1216 o Certificate name matching: The NAS requires a certificate issued 1217 by some particular CA, and also compares the DNS name in the 1218 certificate with the realm name. Like the previous approach, 1219 there are problems if the same CA issues certificates for other 1220 purposes. There are several possibile comparison rules (these 1221 examples are not meant to be exhaustive): 1223 * "Simple": the server is authorized if the realm name is equal 1224 to the DNS name in the certificate with first component 1225 removed. 1227 * "Suffix": the server is authorized if the realm name is a 1228 suffix of the DNS name in the certificate. 1230 * "Last-2-or-3": the server is authorized if the last two or 1231 three components of the DNS name and realm name are equal. 1232 Whether two or three components are required depends on the 1233 last component. For instance, two is enough for "com", but 1234 three is required for "au", because Australia uses a 1235 second-level domain structure (.com.au, .org.au, etc.). 1237 All of these comparison rules have some problems. For instance, 1238 using the "simple" rule, mars.example.com can't be authorized for 1239 the realm "sales.example.com". With the "suffix" and 1240 "last-2-or-3" rules, "jupiter.sales.example.com" is authorized for 1241 not only the realm "sales.example.com" but also "example.com". 1242 And none of the rules can authorize mars.example.com for the realm 1243 "example.org". 1245 o Authorization using DNS records (probably secured by DNSSEC): For 1246 instance, a DNS SRV record "_diameter._sctp.example.com" pointing 1247 to mars.example.com could imply authorization to act as a home 1248 server for the realm "example.com" (although [BASE], Section 5.2 1249 seems to forbid this). 1251 o Authorization implied by redirect: If the home server was located 1252 as a result of a redirect message, and the redirect agent that 1253 provided the answer is trustworthy, this could be used as 1254 authorization if better information is not available (see also 1255 next section about authorizing redirect agents). 1257 Some future possibilities (not known to be used yet in Diameter) 1258 include the following. 1260 o Certificate name matching combined with an extendedKeyUsage 1261 extension, specifying whether the host is authorized to act as a 1262 home server, NAS, or something else (such as web server). This 1263 avoids the problems involved if the same CA issues certificates 1264 for other purposes as well, but no extendedKeyUsage value has been 1265 defined for Diameter servers yet. 1267 o The server's certificate could contain an authorization extension 1268 with realm name(s). This would avoid many of the problems in 1269 certificate name matching, but no such extensions has been defined 1270 yet. 1272 o Attribute certificates: The server also presents an attribute 1273 certificate that contains the realm name. No attribute 1274 certificate profile has been defined for Diameter, and there is no 1275 standardized way to transport the attribute certificates with IKE 1276 or TLS. 1278 For reasons described in the next section (Attacks by compromised 1279 nodes), a NAS may also perform more fine-grained access control. For 1280 instance, a NAS may want to restrict the ability to initiate callback 1281 to some home servers. How such restricted authorizations would be 1282 specified is beyond the scope of this document. 1284 8.1.2 Direct connection, server point of view 1286 (TO BE WRITTEN) 1288 8.1.3 Diameter agents 1290 (NOTE: This section is very much under construction) 1292 If authorization can be complex even in the case of direct 1293 connections, it gets worse with agents, unless authorization is made 1294 more "coarse-grained". Consider questions such "is this Diameter 1295 proxy authorized to forward my requests to realm example.com?", or 1296 "is this Diameter proxy authorized to forward requests from NAS 1297 ap1788.example.com?" 1299 It is important to remember that authorizing a Diameter agent to work 1300 as a relay, proxy or translation agent involves considerable trust in 1301 the agent. The security mechanisms specified in [BASE] provide only 1302 hop-by-hop security. Diameter agents can eavesdrop and modify AVPs 1303 in the messages they forward, and even with Diameter Path 1304 Authorization (see [BASE] Section 2.10), a Diameter agent that is 1305 authorized to forward messages from party X can also forge messages 1306 that look like they came from X. 1308 Some Diameter agent may be authorized as a redirect agent only (TO BE 1309 WRITTEN) 1311 8.2 Attacks by compromised nodes 1313 The hop-by-hop security mechanisms (IPsec and TLS) combined with 1314 proper authorization provide good protection against "outside" 1315 attackers (denial-of-service is, of course, possible). This section 1316 deals with attacks in which an attacker has compromised an authorized 1317 NAS, Diameter agent, or Diameter server. 1319 (Attacks between the user and the NAS are beyond the scope of this 1320 document, since they do not use Diameter, and depend on the link 1321 layer used.) 1323 Unlike the base protocol security considerations, this section 1324 considers the Diameter NASREQ/EAP messages not just as bit strings, 1325 but as messages with a meaning (that cause some actions to happen). 1326 Thus, the question is not "can the attacker modify this packet" but 1327 "what can an attacker who compromises an authorized NAS, agent, or 1328 server do using Diameter EAP messages?" 1330 8.2.1 Impersonating as the user (NAS, agents) 1332 Unlike CHAP in NASREQ, in EAP the NAS or agents cannot successfully 1333 replay old EAP messages (unless the EAP method is seriously broken). 1335 8.2.2 Impersonating as the network (NAS, agents) 1337 If the EAP method used does not provide mutual authentication, 1338 obviously anyone can impersonate as the network to the user. When 1339 EAP mutual authentication is used, it occurs between the user and the 1340 Diameter home server. This means that it is usually not possible for 1341 the user to validate the identity of the NAS using EAP alone (the 1342 possession of the session keys by the NAS proves that the user is 1343 talking to *some* authorized NAS, but not which). 1345 Some EAP methods, such as EAP Archie [Archie], try to provide a 1346 "binding" where some identity of the NAS (such as MAC address) is 1347 also communicated inside the EAP messages. However, the usefulness 1348 of this binding is rather limited in many environments. 1350 In many networks an attacker who has not compromized any trusted 1351 nodes can still mount a "relay attack" (for the lack of better word). 1352 In this attack, the attacker just forwards messages between the user 1353 and a legitimate NAS (without modifying them), causing the user to 1354 access the network via a different NAS than would have otherwise 1355 happened. This attack might make sense if, for instance, the 1356 attacker can eavesdrop the network near some NASes, but not all, or 1357 if the user is charged more for network access via foreign NASes than 1358 local ones. 1360 It is rather obvious that an attacker who has compromised a NAS can 1361 "impersonate" as the network to the user (until the compromise is 1362 noticed and NAS authorization revoked). The attacker can also use 1363 this "relay attack" to cause the user to access the network via the 1364 compromised NAS instead of other, non-compromised, NASes. 1366 Prevention of this "relay attack" is rather difficult, and is beyond 1367 the scope of this document. Note that validating a NAS identity 1368 (using the "binding" provided by Archie, for instance) does not 1369 usually help. For instance, in WLANs, the user does not usually 1370 securely know the MAC address of the "right" access point--it's 1371 simply picked from a beacon message that has the correct SSID and 1372 good signal strength (something that's easy to spoof). 1374 8.2.3 Privacy issues (NAS, agents) 1376 Diameter messages can contain AVPs that can be used to identify the 1377 user (e.g., User-Name) and approximate location of the user (e.g. 1378 Origin-Host for WLAN access points, Calling-Station-Id for fixed 1379 phone lines). Thus, any Diameter nodes that process the messages may 1380 be able to determine the geographic location of users. 1382 Note that in many cases, the user identity is also sent in clear 1383 inside EAP-Payload AVPs, and it may be possible to eavesdrop this 1384 between the user and the NAS. 1386 This can mitigated somewhat by using EAP methods that provide 1387 identity protection (see [RFC2284bis], Section 7.3), and using 1388 Session-Id or pseudonyms for accounting. 1390 8.2.4 Offline cryptographic attacks (NAS, agents) 1392 Some EAP methods are vulnerable to dictionary attacks or other 1393 methods that try to recover long-term secrets from EAP messages. 1394 Usually the EAP messages can also be eavesdropped between the user 1395 and the NAS, so good EAP methods provide sufficient protection 1396 against this type of attacks. 1398 8.2.5 AVP editing (NAS, agents, server) 1400 Diameter agents can modify, insert, and delete AVPs. Diameter agents 1401 are usually meant to modify AVPs, and the protocol in general cannot 1402 distinguish well-intentioned and malicious modifications (see 1403 [RFC2607] for more discussion). 1405 Authentication method negotiation attacks are discussed in the next 1406 Section. 1408 An attacker who compromises a Diameter agent or server can modify 1409 AA-Answer/Diameter-EAP-Answer messages and.. 1411 o Deny access to authorized users (Result-Code). 1413 o Give unauthorized users access (Result-Code). 1415 o Give attacker a login session to a host otherwise protected by 1416 firewalls (Login-Host). 1418 o Redirect an authorized user's login session to a host controlled 1419 by the attacker (Login-Host). 1421 o Route an authorized user's traffic through a host controlled by 1422 the attacker (various tunneling AVPs). 1424 o Redirect an authorized user's DNS requests to a malicious DNS 1425 server (various vendor-specific AVPs). 1427 o Modify routing tables at the NAS and thus redirect packets 1428 destined for someone else (Framed-Route, Framed-Routing). 1430 o Remove packet filters and other restrictions for user (Filter, 1431 Callback, various vendor-specific AVPs). 1433 o Cause the NAS to call some number, possibly expensive toll number 1434 controlled by the attacker (callback AVPs) 1436 o Execute Command Line Interface (CLI) commands on the NAS (various 1437 vendor-specific attributes). 1439 Some of these attacks can be prevented if the NAS can be configured 1440 not to accept some particular AVPs, or not accept them from all 1441 Diameter servers. For instance, if a particular destination realm 1442 never uses tunneling, answer messages containing tunneling AVPs could 1443 be rejected. 1445 An attacker who compromises a NAS or agent can modify AA-Requests, 1446 and... 1448 o Change NAS-Identifier/NAS-Port/Origin-Host (or something) so that 1449 a valid user appears to be accessing the network from a different 1450 NAS than in reality. 1452 o Modify Calling-Station-ID (either to hide the true value, gain 1453 access, or frame someone else). 1455 o Modify password change messages (some vendor-specific attributes) 1457 o Modify usage information in accounting messages. 1459 o Modify Class/State AVPs? 1461 8.2.6 Negotiation attacks (NAS, agents, server) 1463 This section deals with attacks where the NAS, any Diameter agents, 1464 or Diameter server attempts to cause the authenticating user to 1465 choose a less secure authentication method (either something else 1466 than EAP, or a less secure EAP method). 1468 For example, a session that would normally be authenticated with EAP 1469 would instead authenticated via CHAP or PAP; alternatively, a 1470 connection that would normally be authenticated via a more secure EAP 1471 method such as EAP-TLS might be made to occur via a less secure EAP 1472 method, such as MD5-Challenge. 1474 (TO BE WRITTEN, possibly copy text from 2869bis) 1476 Negotiation attacks within EAP are discussed in [RFC2284bis], Section 1477 7.8. 1479 Negotiation attacks between the user and the NAS are beyond the scope 1480 of this document. 1482 8.2.7 Session key distribution (agents, server) 1484 Since there are currently no end-to-end (NAS-to-home server) security 1485 mechanisms specified for Diameter, any agents that process 1486 Diameter-EAP-Answer messages can see the contents of the 1487 EAP-Session-Key AVP. For this reason, this specification strongly 1488 recommends avoiding Diameter agents when they cannot be trusted to 1489 keep the keys secret. 1491 In environments where agents are present, several factors should be 1492 considered when deciding whether the agents that are authorized (and 1493 considered "trustworthy enough") to grant access to users and specify 1494 various authorization and tunneling AVPs are also "trustworthy 1495 enough" to handle the session keys. These factors include (but are 1496 not limited to) the type of access provided (e.g., public Internet or 1497 corporate internet), security level of the agents, and the 1498 possibilities for attacking user's traffic after it has been 1499 decrypted by the NAS. 1501 Note that the keys communicated in Diameter messages are usually 1502 short-term session keys (or short-term master keys that are used to 1503 derive session keys). To actually cause any damage, those session 1504 keys must end with some malicious party; that party must be able to 1505 eavesdrop, modify, or insert traffic between the user and the NAS 1506 during the lifetime of those keys (e.g., in 802.11i the attacker must 1507 also eavesdrop the "four-way handshake"); and that eavesdropping or 1508 modification must cause some damage. 1510 9. Acknowledgements 1512 This Diameter application relies heavily on earlier work on Diameter 1513 NASREQ application [NASREQ] and RADIUS EAP support [RFC2869bis]. 1514 Much of the material in this specification has been copied from these 1515 documents. 1517 The authors would also like to acknowledge the following people for 1518 their contributions to this document: Bernard Aboba, Jari Arkko, Pat 1519 Calhoun, Henry Haverinen, and John Loughney. (TBD: Who's missing from 1520 this list?) 1522 Normative References 1524 [BASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 1525 Arkko, "Diameter Base Protocol", 1526 draft-ietf-aaa-diameter-17 (work in progress), December 1527 2002. 1529 [NASREQ] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 1530 Network Access Server Application", 1531 draft-ietf-aaa-diameter-nasreq-11 (work in progress), 1532 February 2003. 1534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1535 Requirement Levels", BCP 14, RFC 2119, March 1997. 1537 [RFC2284bis] 1538 Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J. and H. 1539 Levkowetz, "Extensible Authentication Protocol (EAP)", 1540 draft-ietf-eap-rfc2284bis-04 (work in progress), June 1541 2003. 1543 Informative References 1545 [Archie] Walker, J. and R. Housley, "The EAP Archie Protocol", 1546 draft-jwalker-eap-archie-01 (work in progress), June 2003. 1548 [DynAuth] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. 1549 Aboba, "Dynamic Authorization Extensions to Remote 1550 Authentication Dial In User Service (RADIUS)", 1551 draft-chiba-radius-dynamic-authorization-20 (work in 1552 progress), May 2003. 1554 [IEEE-802.1X] 1555 Institute of Electrical and Electronics Engineers, "Local 1556 and Metropolitan Area Networks: Port-Based Network Access 1557 Control", IEEE Standard 802.1X, September 2001. 1559 [IEEE-802.11i] 1560 Institute of Electrical and Electronics Engineers, 1561 "Unapproved Draft Supplement to Standard for 1562 Telecommunications and Information Exchange Between 1563 Systems - LAN/MAN Specific Requirements - Part 11: 1564 Wireless LAN Medium Access Control (MAC) and Physical 1565 Layer (PHY) Specifications: Specification for Enhanced 1566 Security", IEEE Draft 802.11i (work in progress), 2003. 1568 [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 1569 Protocol", draft-ietf-ipsec-ikev2-08 (work in progress), 1570 May 2003. 1572 [RADIUS1X] 1573 Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 1574 "IEEE 802.1X RADIUS Usage Guidelines", 1575 draft-congdon-radius-8021x-29 (work in progress), April 1576 2003. 1578 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1579 RFC 1661, July 1994. 1581 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1582 RFC 2548, March 1999. 1584 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1585 Implementation in Roaming", RFC 2607, June 1999. 1587 [RFC2869bis] 1588 Aboba, B. and P. Calhoun, "RADIUS Support For Extensible 1589 Authentication Protocol (EAP)", 1590 draft-aboba-radius-rfc2869bis-22 (work in progress), May 1591 2003. 1593 Authors' Addresses 1595 Pasi Eronen (editor) 1596 Nokia Research Center 1597 P.O. Box 407 1598 FIN-00045 Nokia Group 1599 Finland 1601 EMail: pasi.eronen@nokia.com 1603 Tom Hiller 1604 Lucent Technologies 1605 1960 Lucent Lane 1606 Naperville, IL 60566 1607 USA 1609 Phone: +1 630 979 7673 1610 EMail: tom.hiller@lucent.com 1612 Glen Zorn 1613 Cisco Systems 1614 500 108th Avenue N.E., Suite 500 1615 Bellevue, WA 98004 1616 USA 1618 Phone: +1 425 344 8113 1619 EMail: gwz@cisco.com 1621 Appendix A. Changelog 1623 (This section will not appear in the final version submitted to RFC 1624 editor.) 1626 Changes from -02.d to -02.e: 1628 o Added a section on accounting, and changed how the 1629 Accounting-EAP-Auth-Method is determined. 1631 o Updates to "authorization" and "impersonating as the network" 1632 security considerations. 1634 Changes from -02.c to -02.d: 1636 o Some clarifications to Introduction section. 1638 o Lots of clarifications and added diagrams in protocol overview 1639 section. Moved non-EAP-supporting servers, User-Name AVP 1640 guidelines, and conflicting messages to separate sections. 1642 o Added a new section about sessions and NASREQ interaction. 1644 o Wrote a note about Reply-Message AVP, and added it back to ABNFs 1645 and occurance tables. 1647 o Added EAP-Reissued-Payload AVP for signalling invalid packets, and 1648 RADIUS translation for this. 1650 o Added EAP-Master-Session-Key AVP for keys, and suggestions for 1651 RADIUS translation. 1653 o Attempted to clarify Framed-MTU RADIUS translation. 1655 o Added a first attempt of security considerations section. 1657 o Updated acknowledgements (please notify me if someone's missing). 1659 Changes from -02.b to -02.c: 1661 o Rephrased abstract and introduction sections. 1663 o A couple of minor changes in Sections 2.1 and 2.2. 1665 o Added text about advertising application support and role 1666 reversal. 1668 o Changed type of Accounting-EAP-Auth-Method AVP from Enumerated to 1669 Unsigned64, and explained how it is determined. 1671 o Removed references to EAP-Master-Session-Key AVP added in -02.b. 1673 o Added Diameter-RADIUS translation of accounting AVPs. 1675 o Added IANA Considerations section. 1677 o References section: Updated RFC2284bis, added IEEE-802.11i and 1678 IKEv2, deleted RFC1510 ad RFC1938. 1680 Changes from -02.a to -02.b: 1682 o Added some text to Introduction section. 1684 o Stole text from 2869bis about invalid packets, retransmissions, 1685 and fragmentation. 1687 o In section 2.1, changed one "MAY" to "could" since it was not used 1688 to describe a requirement. 1690 o Updated ABNF's and AVP occurance tables to match the current 1691 NASREQ-11 document. 1693 o Added EAP-MTU and EAP-Master-Session-Key AVPs. 1695 o Removed description of Configuration-Token, Nas-Port, Nas-Port-Id, 1696 and State AVPs (the text didn't add anything to their description 1697 in NASREQ). 1699 o Added a first attempt of a section describing Diameter-RADIUS 1700 translation. 1702 o Added references RFC2284bis, RFC2548, RFC2869bis, RADIUS1X, and 1703 DynAuth. 1705 Changes from -01 to -02.a: 1707 o New editor. 1709 o Added Changelog appendix. 1711 o Converted source to XML format. This will result in many small 1712 formatting changes in the ASCII version. 1714 o Updated BASE and NASREQ references to current versions. 1716 Intellectual Property Statement 1718 The IETF takes no position regarding the validity or scope of any 1719 intellectual property or other rights that might be claimed to 1720 pertain to the implementation or use of the technology described in 1721 this document or the extent to which any license under such rights 1722 might or might not be available; neither does it represent that it 1723 has made any effort to identify any such rights. Information on the 1724 IETF's procedures with respect to rights in standards-track and 1725 standards-related documentation can be found in BCP-11. Copies of 1726 claims of rights made available for publication and any assurances of 1727 licenses to be made available, or the result of an attempt made to 1728 obtain a general license or permission for the use of such 1729 proprietary rights by implementors or users of this specification can 1730 be obtained from the IETF Secretariat. 1732 The IETF invites any interested party to bring to its attention any 1733 copyrights, patents or patent applications, or other proprietary 1734 rights which may cover technology that may be required to practice 1735 this standard. Please address the information to the IETF Executive 1736 Director. 1738 Full Copyright Statement 1740 Copyright (C) The Internet Society (2003). All Rights Reserved. 1742 This document and translations of it may be copied and furnished to 1743 others, and derivative works that comment on or otherwise explain it 1744 or assist in its implementation may be prepared, copied, published 1745 and distributed, in whole or in part, without restriction of any 1746 kind, provided that the above copyright notice and this paragraph are 1747 included on all such copies and derivative works. However, this 1748 document itself may not be modified in any way, such as by removing 1749 the copyright notice or references to the Internet Society or other 1750 Internet organizations, except as needed for the purpose of 1751 developing Internet standards in which case the procedures for 1752 copyrights defined in the Internet Standards process must be 1753 followed, or as required to translate it into languages other than 1754 English. 1756 The limited permissions granted above are perpetual and will not be 1757 revoked by the Internet Society or its successors or assignees. 1759 This document and the information contained herein is provided on an 1760 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1761 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1762 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1763 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1764 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1766 Acknowledgement 1768 Funding for the RFC Editor function is currently provided by the 1769 Internet Society.