idnits 2.17.1 draft-ietf-radext-rfc3576bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1652. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3576, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Where RADIUS is run over IPsec ESP with a non-null transform, the secret shared between the Dynamic Authorization Server and the Dynamic Authorization Client MAY NOT be configured. In this case, a shared secret of zero length MUST be assumed. However, a Dynamic Authorization Client that cannot know whether incoming traffic is IPsec-protected MUST be configured with a non-null RADIUS shared secret. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Note 1' is mentioned on line 956, but not defined == Missing Reference: 'Note 3' is mentioned on line 970, but not defined == Missing Reference: 'Notes 1' is mentioned on line 908, but not defined -- Looks like a reference, but probably isn't: '6' on line 908 == Missing Reference: 'Note 2' is mentioned on line 962, but not defined == Missing Reference: 'Note 7' is mentioned on line 998, but not defined == Missing Reference: 'Note 5' is mentioned on line 982, but not defined == Missing Reference: 'Note 4' is mentioned on line 976, but not defined == Missing Reference: 'Note 6' is mentioned on line 987, but not defined ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 4330 (Obsoleted by RFC 5905) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Murtaza S. Chiba 3 INTERNET-DRAFT Gopal Dommety 4 Obsoletes: 3576 Mark Eklund 5 Category: Informational Cisco Systems, Inc. 6 David Mitton 7 4 June 2007 RSA Security, Inc. 8 Bernard Aboba 9 Microsoft Corporation 11 Dynamic Authorization Extensions to Remote Authentication Dial In User 12 Service (RADIUS) 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 25, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). All Rights Reserved. 41 Abstract 43 This document describes a currently deployed extension to the Remote 44 Authentication Dial In User Service (RADIUS) protocol, allowing 45 dynamic changes to a user session, as implemented by network access 46 server products. This includes support for disconnecting users and 47 changing authorizations applicable to a user session. 49 Table of Contents 51 1. Introduction .......................................... 3 52 1.1 Applicability ................................... 3 53 1.2 Requirements Language ........................... 4 54 1.3 Terminology ..................................... 4 55 2. Overview ............................................. 5 56 2.1 Disconnect Messages (DM) ........................ 5 57 2.2 Change-of-Authorization Messages (CoA) .......... 5 58 2.3 Packet Format ................................... 6 59 3. Attributes ............................................ 10 60 3.1 Proxy State ..................................... 12 61 3.2 Authorize Only .................................. 13 62 3.3 State ........................................... 13 63 3.4 Message-Authenticator ........................... 14 64 3.5 Error-Cause ..................................... 15 65 3.6 Table of Attributes ............................. 18 66 4. Diameter Considerations ............................... 22 67 5. IANA Considerations ................................... 24 68 6. Security Considerations ............................... 25 69 6.1 Authorization Issues ............................ 25 70 6.2 Impersonation ................................... 26 71 6.3 IPsec Usage Guidelines .......................... 26 72 6.4 Replay Protection ............................... 29 73 7. Example Traces ........................................ 30 74 8. References ............................................ 30 75 8.1 Normative References ............................ 30 76 8.2 Informative References .......................... 31 77 ACKNOWLEDGMENTS .............................................. 32 78 AUTHORS' ADDRESSES ........................................... 33 79 Appendix A - Changes from RFC 3576 ........................... 34 80 Full Copyright Statement ..................................... 36 81 Intellectual Property ........................................ 36 82 1. Introduction 84 The RADIUS protocol, defined in [RFC2865], does not support 85 unsolicited messages sent from the RADIUS server to the Network 86 Access Server (NAS). 88 However, there are many instances in which it is desirable for 89 changes to be made to session characteristics, without requiring the 90 NAS to initiate the exchange. For example, it may be desirable for 91 administrators to be able to terminate user session(s) in progress. 92 Alternatively, if the user changes authorization level, this may 93 require that authorization attributes be added/deleted from user 94 session(s). 96 To overcome these limitations, several vendors have implemented 97 additional RADIUS commands in order to be able to support unsolicited 98 messages to be sent to the NAS. These extended commands provide 99 support for Disconnect and Change-of-Authorization (CoA) packets. 100 Disconnect packets cause user session(s) to be terminated 101 immediately, whereas CoA packets modify session authorization 102 attributes such as data filters. 104 1.1. Applicability 106 This protocol is being recommended for publication as an 107 Informational RFC rather than as a standards-track RFC because of 108 problems that cannot be fixed without creating incompatibilities with 109 deployed implementations. This includes security vulnerabilities, as 110 well as semantic ambiguities resulting from the design of the Change- 111 of-Authorization (CoA) commands. While fixes are recommended, they 112 cannot be made mandatory since this would be incompatible with 113 existing implementations. 115 Existing implementations of this protocol do not support 116 authorization checks, so that an ISP sharing a NAS with another ISP 117 could disconnect or change authorizations for another ISP's users. 118 In order to remedy this problem, a "Reverse Path Forwarding" check is 119 described; see Section 6.1. for details. 121 Existing implementations utilize per-packet authentication and 122 integrity protection algorithms with known weaknesses [MD5Attack]. 123 To provide stronger per-packet authentication and integrity 124 protection, the use of IPsec is recommended. See Section 6.3 for 125 details. 127 Existing implementations lack replay protection. In order to support 128 replay detection, it is recommended that an Event-Timestamp Attribute 129 be added to all packets in situations where IPsec replay protection 130 is not employed. See Section 6.4 for details. 132 The approach taken with CoA commands in existing implementations 133 results in a semantic ambiguity. Existing implementations of the 134 CoA-Request identify the affected session, as well as supply the 135 authorization changes. Since RADIUS Attributes included within 136 existing implementations of the CoA-Request can be used for session 137 identification or authorization change, it may not be clear which 138 function a given attribute is serving. 140 The problem does not exist within the Diameter protocol [RFC3588], in 141 which server-initiated authorization change is initiated using a Re- 142 Auth-Request (RAR) command identifying the session via User-Name and 143 Session-Id AVPs and containing a Re-Auth-Request-Type AVP with value 144 "AUTHORIZE_ONLY". This results in initiation of a standard 145 Request/Response sequence where authorization changes are supplied. 146 As a result, in no command can Diameter AVPs have multiple potential 147 meanings. 149 1.2. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 1.3. Terminology 157 This document frequently uses the following terms: 159 Dynamic Authorization Client (DAC) 160 The entity originating Change of Authorization (CoA) Requests or 161 Disconnect-Requests. While it is possible that the DAC is co- 162 resident with a RADIUS authentication or accounting server, this 163 need not necessarily be the case. 165 Dynamic Authorization Server (DAS) 166 The entity receiving CoA-Request or Disconnect-Request packets. 167 The DAS may be a NAS or a RADIUS proxy. 169 Network Access Server (NAS) 170 The device providing access to the network. 172 service 173 The NAS provides a service to the user, such as IEEE 802 or Point- 174 to-Point Protocol (PPP). 176 session 177 Each service provided by the NAS to a user constitutes a session, 178 with the beginning of the session defined as the point where 179 service is first provided and the end of the session defined as the 180 point where service is ended. A user may have multiple sessions in 181 parallel or series if the NAS supports that. 183 silently discard 184 This means the implementation discards the packet without further 185 processing. The implementation SHOULD provide the capability of 186 logging the error, including the contents of the silently discarded 187 packet, and SHOULD record the event in a statistics counter. 189 2. Overview 191 This section describes the most commonly implemented features of 192 Disconnect and Change-of-Authorization (CoA) packets. 194 2.1. Disconnect Messages (DM) 196 A Disconnect-Request packet is sent by the Dynamic Authorization 197 Client in order to terminate user session(s) on a NAS and discard all 198 associated session context. The Disconnect-Request packet is sent to 199 UDP port 3799, and identifies the NAS as well as the user session(s) 200 to be terminated by inclusion of the identification attributes 201 described in Section 3. 203 +----------+ +----------+ 204 | | Disconnect-Request | | 205 | | <-------------------- | Dynamic | 206 | NAS | | Authz | 207 | | Disconnect-Response | Client | 208 | | ---------------------> | | 209 +----------+ +----------+ 211 The NAS responds to a Disconnect-Request packet sent by a Dynamic 212 Authorization Client with a Disconnect-ACK if all associated session 213 context is discarded and the user session(s) are no longer connected, 214 or a Disconnect-NAK, if the NAS was unable to disconnect one or more 215 sessions and discard all associated session context. A Disconnect- 216 ACK MAY contain the Attribute Acct-Terminate-Cause (49) [RFC2866] 217 with the value set to 6 for Admin-Reset. 219 2.2. Change-of-Authorization Messages (CoA) 221 CoA-Request packets contain information for dynamically changing 222 session authorizations. Typically this is used to change data 223 filters. The data filters can be of either the ingress or egress 224 kind, and are sent in addition to the identification attributes as 225 described in section 3. The port used, and packet format (described 226 in Section 2.3), are the same as that for Disconnect-Request packets. 228 The following attributes MAY be sent in a CoA-Request: 230 Filter-ID (11) - Indicates the name of a data filter list 231 to be applied for the session(s) that the 232 identification attributes map to. 234 NAS-Filter-Rule (92) - Provides a filter list to be applied 235 for the session(s) that the identification 236 attributes map to [RFC4849]. 238 +----------+ +----------+ 239 | | CoA-Request | | 240 | | <-------------------- | Dynamic | 241 | NAS | | Authz | 242 | | CoA-Response | Client | 243 | | ---------------------> | | 244 +----------+ +----------+ 246 The NAS responds to a CoA-Request sent by a Dynamic Authorization 247 Client with a CoA-ACK if the NAS is able to successfully change the 248 authorizations for the user session(s), or a CoA-NAK if the CoA- 249 Request is unsuccessful. A NAS MUST respond to a CoA-Request 250 including a Service-Type Attribute with an unsupported value with a 251 CoA-NAK; an Error-Cause Attribute with value "Unsupported Service" 252 SHOULD be included. 254 2.3. Packet Format 256 For either Disconnect-Request or CoA-Request packets UDP port 3799 is 257 used as the destination port. For responses, the source and 258 destination ports are reversed. Exactly one RADIUS packet is 259 encapsulated in the UDP Data field. 261 A summary of the data format is shown below. The fields are 262 transmitted from left to right. 264 The packet format consists of the fields: Code, Identifier, Length, 265 Authenticator, and Attributes in Type:Length:Value (TLV) format. All 266 fields hold the same meaning as those described in RADIUS [RFC2865]. 267 The Authenticator field MUST be calculated in the same way as is 268 specified for an Accounting-Request in [RFC2866]. 270 0 1 2 3 271 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Code | Identifier | Length | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | | 276 | Authenticator | 277 | | 278 | | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Attributes ... 281 +-+-+-+-+-+-+-+-+-+-+-+-+- 283 Code 285 The Code field is one octet, and identifies the type of RADIUS 286 packet. Packets received with an invalid Code field MUST be 287 silently discarded. RADIUS codes (decimal) for this extension are 288 assigned as follows: 290 40 - Disconnect-Request [RFC3575] 291 41 - Disconnect-ACK [RFC3575] 292 42 - Disconnect-NAK [RFC3575] 293 43 - CoA-Request [RFC3575] 294 44 - CoA-ACK [RFC3575] 295 45 - CoA-NAK [RFC3575] 297 Identifier 299 The Identifier field is one octet, and aids in matching requests 300 and replies. A Dynamic Authorization Server implementing this 301 specification MUST be capable of detecting a duplicate request if 302 it has the same source IP address, source UDP port and Identifier 303 within a short span of time. 305 The responsibility for retransmission of Disconnect-Request and 306 CoA-Request packets lies with the Dynamic Authorization Client. 307 If after sending these packets, the Dynamic Authorization Client 308 does not receive a response, it will retransmit. 310 The Identifier field MUST be changed whenever the content of the 311 Attributes field changes, or whenever a valid reply has been 312 received for a previous request. For retransmissions where the 313 contents are identical, the Identifier MUST remain unchanged. 315 If the Dynamic Authorization Client is retransmitting a 316 Disconnect-Request or CoA-Request to the same Dynamic 317 Authorization Server as before, and the Attributes haven't 318 changed, the same Request Authenticator, Identifier and source 319 port MUST be used. If any Attributes have changed, a new 320 Authenticator and Identifier MUST be used. 322 If the Request to a primary Dynamic Authorization Server fails, a 323 secondary Dynamic Authorization Server must be queried, if 324 available; issues relating to failover algorithms are described in 325 [RFC3539]. Since this represents a new request, a new Request 326 Authenticator and Identifier MUST be used. However, where the 327 Dynamic Authorization Client is sending directly to the NAS, 328 failover typically does not make sense, since CoA-Request or 329 Disconnect-Request packets need to be delivered to the NAS where 330 the session resides. 332 Length 334 The Length field is two octets. It indicates the length of the 335 packet including the Code, Identifier, Length, Authenticator and 336 Attribute fields. Octets outside the range of the Length field 337 MUST be treated as padding and ignored on reception. If the 338 packet is shorter than the Length field indicates, it MUST be 339 silently discarded. The minimum length is 20 and maximum length 340 is 4096. 342 Authenticator 344 The Authenticator field is sixteen (16) octets. The most 345 significant octet is transmitted first. This value is used to 346 authenticate packets between the Dynamic Authorization Client and 347 the Dynamic Authorization Server. 349 Request Authenticator 351 In Request packets, the Authenticator value is a 16 octet MD5 352 [RFC1321] checksum, called the Request Authenticator. The 353 Request Authenticator is calculated the same way as for an 354 Accounting-Request, specified in [RFC2866]. 356 Note that the Request Authenticator of a CoA-Request or 357 Disconnect-Request cannot be computed the same way as the 358 Request Authenticator of a RADIUS Access-Request, because there 359 is no User-Password Attribute in a CoA-Request or Disconnect- 360 Request. 362 Response Authenticator 364 The Authenticator field in a Response packet (e.g. Disconnect- 365 ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the 366 Response Authenticator, and contains a one-way MD5 hash 367 calculated over a stream of octets consisting of the Code, 368 Identifier, Length, the Request Authenticator field from the 369 packet being replied to, and the response Attributes if any, 370 followed by the shared secret. The resulting 16 octet MD5 hash 371 value is stored in the Authenticator field of the Response 372 packet. 374 Administrative note: As noted in [RFC2865] Section 3, the secret 375 (password shared between the Dynamic Authorization Client and the 376 Dynamic Authorization Server) SHOULD be at least as large and 377 unguessable as a well-chosen password. The Dynamic Authorization 378 Server MUST use the source IP address of the RADIUS UDP packet to 379 decide which shared secret to use, so that requests can be 380 proxied. 382 Attributes 384 In CoA-Request and Disconnect-Request packets, all attributes MUST 385 be treated as mandatory. If one or more authorization changes 386 specified in a CoA-Request cannot be carried out, the NAS MUST 387 send a CoA-NAK. A NAS MUST respond to a CoA-Request containing 388 one or more unsupported Attributes or Attribute values with a CoA- 389 NAK; an Error-Cause Attribute with value 401 (Unsupported 390 Attribute) or 407 (Invalid Attribute Value) MAY be included. A 391 NAS MUST respond to a Disconnect-Request containing one or more 392 unsupported Attributes or Attribute values with a Disconnect-NAK; 393 an Error-Cause Attribute with value 401 (Unsupported Attribute) or 394 407 (Invalid Attribute Value) MAY be included. 396 State changes resulting from a CoA-Request MUST be atomic: if the 397 CoA-Request is successful for all matching sessions, the NAS MUST 398 send a CoA-ACK in reply, and all requested authorization changes 399 MUST be made. If the CoA-Request is unsuccessful for any matching 400 sessions, the NAS MUST send as CoA-NAK in reply, and the requested 401 authorization changes MUST NOT be made for any of the matching 402 sessions. Similarly, a state change MUST NOT occur as a result of 403 a Disconnect-Request that is unsuccessful with respect to any of 404 the matching sessions; a NAS MUST send a Disconnect-NAK in reply 405 if any of the matching sessions cannot be successfully terminated. 406 A NAS which does not support dynamic authorization changes 407 applying to multiple sessions MUST send a CoA-NAK or Disconnect- 408 NAK in reply; an Error-Cause Attribute with value 508 (Multiple 409 Session Selection Unsupported) SHOULD be included. 411 Within this specification attributes can be used for 412 identification, authorization or other purposes. RADIUS Attribute 413 specifications created after publication of this document SHOULD 414 state whether an attribute can be included in CoA or Disconnect 415 messages and if so, which messages it can be included in and 416 whether it serves as an identification or authorization attribute. 418 Even if a NAS implements an attribute for use with RADIUS 419 authentication and accounting, it is possible that it will not 420 support inclusion of that attribute within CoA-Request and 421 Disconnect-Request packets, given the difference in attribute 422 semantics. This is true even for attributes specified as 423 allowable within Access-Accept packets (such as those defined 424 within [RFC2865], [RFC2868], [RFC2869], [RFC3162], [RFC3579], 425 [RFC4372], [RFC4675], [RFC4818] and [RFC4849]). 427 3. Attributes 429 In Disconnect-Request and CoA-Request packets, certain attributes are 430 used to uniquely identify the NAS as well as user session(s) on the 431 NAS. All NAS and session identification attributes included in a 432 CoA-Request or Disconnect-Request packet MUST match at least one 433 session in order for a Request to be successful; otherwise a 434 Disconnect-NAK or CoA-NAK MUST be sent. If all NAS identification 435 attributes match, and more than one session matches all of the 436 session identification attributes, then a CoA-Request or Disconnect- 437 Request MUST apply to all matching sessions. 439 Identification attributes include NAS and session identification 440 attributes, as described below. 442 NAS identification attributes 444 Attribute # Reference Description 445 --------- --- --------- ----------- 446 NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS. 447 NAS-Identifier 32 [RFC2865] String identifying the NAS. 448 NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS. 450 Session identification attributes 452 Attribute # Reference Description 453 --------- --- --------- ----------- 454 User-Name 1 [RFC2865] The name of the user 455 associated with one or 456 more sessions. 457 NAS-Port 5 [RFC2865] The port on which a 458 session is terminated. 459 Framed-IP-Address 8 [RFC2865] The IPv4 address associated 460 with a session. 461 Vendor-Specific 26 [RFC2865] One or more vendor-specific 462 identification attributes. 463 Called-Station-Id 30 [RFC2865] The link address to which 464 a session is connected. 465 Calling-Station-Id 31 [RFC2865] The link address from which 466 one or more sessions are 467 connected. 468 Acct-Session-Id 44 [RFC2866] The identifier uniquely 469 identifying a session 470 on the NAS. 471 Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely 472 identifying related sessions. 473 NAS-Port-Id 87 [RFC2869] String identifying the port 474 where a session is. 475 Chargeable-User- 89 [RFC4372] The CUI associated with one 476 Identity or more sessions. Needed 477 where a privacy NAI is used, 478 since in this case the 479 User-Name (e.g. "anonymous") 480 may not identify sessions 481 belonging to a given user. 482 Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier 483 associated with a session; 484 always sent with 485 Framed-IPv6-Prefix. 486 Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated 487 with a session, always sent 488 with Framed-Interface-Id. 490 To address security concerns described in Section 6.1, either the 491 User-Name or Chargeable-User-Identity attribute SHOULD be present in 492 Disconnect-Request and CoA-Request packets. 494 Where a Diameter client utilizes the same Session-Id for both 495 authorization and accounting, inclusion of an Acct-Session-Id 496 Attribute in a Disconnect-Request or CoA-Request can assist with 497 Diameter/RADIUS translation, since Diameter RAR and ASR commands 498 include a Session-Id AVP. An Acct-Session-Id Attribute SHOULD be 499 included in Disconnect-Request and CoA-Request packets. 501 A NAS implementing this specification SHOULD send an Acct-Session-Id 502 or Acct-Multi-Session-Id Attribute within an Access-Request. Where 503 an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not included 504 within an Access-Request, the Dynamic Authorization Client will not 505 know the Acct-Session-Id or Acct-Multi-Session-Id of the session it 506 is attempting to target, unless it also has access to the accounting 507 data for that session. 509 Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not 510 present in a CoA-Request or Disconnect-Request, it is possible that 511 the the User-Name or Chargeable-User-Identity attributes will not be 512 sufficient to uniquely identify a single session (e.g. if the same 513 user has multiple sessions on the NAS, or if the privacy NAI is 514 used). In this case if it is desired to identify a single session, 515 session identification MAY be performed by using one or more of the 516 Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called- 517 Station-Id, Calling-Station-Id, NAS-Port and NAS-Port-Id attributes. 519 To address security concerns described in Section 6.2, one or more of 520 the NAS-IP-Address or NAS-IPv6-Address Attributes SHOULD be present 521 in CoA-Request and Disconnect-Request packets; the NAS-Identifier 522 Attribute MAY be present. 524 A Disconnect-Request MUST contain only NAS and session identification 525 attributes. If other attributes are included in a Disconnect- 526 Request, implementations MUST send a Disconnect-NAK; an Error-Cause 527 Attribute with value "Unsupported Attribute" MAY be included. 529 3.1. Proxy State 531 If there are any Proxy-State attributes in a Disconnect-Request or 532 CoA-Request received from the Dynamic Authorization Client, the 533 Dynamic Authorization Server MUST include those Proxy-State 534 attributes in its response to the Dynamic Authorization Client. 536 A forwarding proxy or NAS MUST NOT modify existing Proxy-State, 537 State, or Class attributes present in the packet. The forwarding 538 proxy or NAS MUST treat any Proxy-State attributes already in the 539 packet as opaque data. Its operation MUST NOT depend on the content 540 of Proxy-State attributes added by previous proxies. The forwarding 541 proxy MUST NOT modify any other Proxy-State attributes that were in 542 the packet; it may choose not to forward them, but it MUST NOT change 543 their contents. If the forwarding proxy omits the Proxy-State 544 attributes in the request, it MUST attach them to the response before 545 sending it. 547 When the proxy forwards a Disconnect or CoA-Request, it MAY add a 548 Proxy-State Attribute, but it MUST NOT add more than one. If a 549 Proxy-State Attribute is added to a packet when forwarding the 550 packet, the Proxy-State Attribute MUST be added after any existing 551 Proxy-State attributes. The forwarding proxy MUST NOT change the 552 order of any attributes of the same type, including Proxy-State. 553 Other attributes can be placed before, after or even between the 554 Proxy-State attributes. 556 When the proxy receives a response to a CoA-Request or Disconnect- 557 Request, it MUST remove its own Proxy-State (the last Proxy- State in 558 the packet) Attribute before forwarding the response. Since 559 Disconnect and CoA responses are authenticated on the entire packet 560 contents, the stripping of the Proxy-State Attribute invalidates the 561 integrity check - so the proxy needs to recompute it. 563 3.2. Authorize Only 565 Support for a CoA-Request including a Service-Type Attribute with 566 value "Authorize Only" is OPTIONAL on the NAS and Dynamic 567 Authorization Client. A Service-Type Attribute MUST NOT be included 568 within a Disconnect-Request. 570 A NAS MUST respond to a CoA-Request including a Service-Type 571 Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST 572 NOT be sent. If the NAS does not support a Service-Type value of 573 "Authorize Only" then it MUST respond with a CoA-NAK; an Error-Cause 574 value of 405 (Unsupported Service) SHOULD be included. 576 A CoA-Request containing a Service-Type Attribute with value 577 "Authorize Only" MUST in addition contain only NAS or session 578 identification attributes, as well as a State Attribute. If other 579 attributes are included in such a CoA-Request, a CoA-NAK MUST be 580 sent; an Error-Cause Attribute with value 401 (Unsupported Attribute) 581 SHOULD be included. 583 If a CoA-Request packet including a Service-Type value of "Authorize 584 Only" is successfully processed, the NAS MUST respond with a CoA-NAK 585 containing a Service-Type Attribute with value "Authorize Only", and 586 an Error-Cause Attribute with value 507 (Request Initiated). The NAS 587 then MUST send an Access-Request to the RADIUS server including a 588 Service-Type Attribute with value "Authorize Only", along with a 589 State Attribute. This Access-Request SHOULD contain the NAS 590 identification attributes from the CoA-Request, as well as the 591 session identification attributes from the CoA-Request permitted in 592 an Access-Request; it also MAY contain other attributes permitted in 593 an Access-Request. 595 As noted in [RFC2869] Section 5.19, a Message-Authenticator attribute 596 SHOULD be included in an Access-Request that does not contain a User- 597 Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. The 598 RADIUS server then will respond to the Access-Request with an Access- 599 Accept to (re-)authorize the session or an Access-Reject to refuse to 600 (re-)authorize it. 602 3.3. State 604 The State Attribute is available to be sent by the Dynamic 605 Authorization Client to the NAS in a CoA-Request packet and MUST be 606 sent unmodified from the NAS to the Dynamic Authorization Client in a 607 subsequent ACK or NAK packet. 609 [RFC2865] Section 5.44 states: 611 An Access-Request MUST contain either a User-Password or a CHAP- 612 Password or State. An Access-Request MUST NOT contain both a 613 User-Password and a CHAP-Password. If future extensions allow 614 other kinds of authentication information to be conveyed, the 615 attribute for that can be used in an Access-Request instead of 616 User-Password or CHAP-Password. 618 In order to satisfy the requirements of [RFC2865] Section 5.44, an 619 Access-Request with Service-Type="Authorize-Only" MUST contain a 620 State attribute. 622 In order to provide a State attribute to the NAS, a Dynamic 623 Authorization Client sending a CoA-Request with a Service-Type value 624 of "Authorize-Only" MUST include a State Attribute, and the NAS MUST 625 send the State Attribute unmodified to the RADIUS server in the 626 resulting Access-Request, if any. A NAS receiving a CoA-Request 627 containing a Service-Type value of "Authorize-Only" but lacking a 628 State attribute MUST send a CoA-NAK and SHOULD include an Error-Cause 629 attribute with value 402 (Missing Attribute). 631 The State Attribute is also available to be sent by the Dynamic 632 Authorization Client to the NAS in a CoA-Request that also includes a 633 Termination-Action Attribute with the value of RADIUS-Request. If 634 the NAS performs the Termination-Action by sending a new Access- 635 Request upon termination of the current session, it MUST include the 636 State Attribute unchanged in that Access-Request. In either usage, 637 the Dynamic Authorization Server MUST NOT interpret the Attribute 638 locally. A CoA-Request packet MUST have only zero or one State 639 Attribute. Usage of the State Attribute is implementation dependent. 641 3.4. Message-Authenticator 643 The Message-Authenticator Attribute MAY be used to authenticate and 644 integrity-protect CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request, 645 Disconnect-ACK and Disconnect-NAK packets order to prevent spoofing. 647 A Dynamic Authorization Server receiving a CoA-Request or Disconnect- 648 Request with a Message-Authenticator Attribute present MUST calculate 649 the correct value of the Message-Authenticator and silently discard 650 the packet if it does not match the value sent. A Dynamic 651 Authorization Client receiving a CoA/Disconnect-ACK or 652 CoA/Disconnect-NAK with a Message-Authenticator Attribute present 653 MUST calculate the correct value of the Message-Authenticator and 654 silently discard the packet if it does not match the value sent. 656 When a Message-Authenticator Attribute is included within a CoA- 657 Request or Disconnect-Request, it is calculated as follows: 659 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, 660 Request Authenticator, Attributes) 662 When the HMAC-MD5 message integrity check is calculated the 663 Request Authenticator field and Message-Authenticator Attribute 664 should be considered to be sixteen octets of zero. The Message- 665 Authenticator Attribute is calculated and inserted in the packet 666 before the Request Authenticator is calculated. 668 When a Message-Authenticator Attribute is included within a CoA- 669 ACK, CoA-NAK, Disconnect-ACK or Disconnect-NAK, it is calculated 670 as follows: 672 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, 673 Request Authenticator, Attributes) 675 When the HMAC-MD5 message integrity check is calculated the 676 Message-Authenticator Attribute should be considered to be sixteen 677 octets of zero. The Request Authenticator is taken from the 678 corresponding CoA/Disconnect-Request. The Message-Authenticator 679 is calculated and inserted in the packet before the Response 680 Authenticator is calculated. 682 3.5. Error-Cause 684 Description 686 It is possible that a Dynamic Authorization Server cannot honor 687 Disconnect-Request or CoA-Request packets for some reason. The 688 Error-Cause Attribute provides more detail on the cause of the 689 problem. It MAY be included within CoA-NAK and Disconnect-NAK 690 packets. 692 A summary of the Error-Cause Attribute format is shown below. The 693 fields are transmitted from left to right. 695 0 1 2 3 696 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Type | Length | Value 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 Value (cont) | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 Type 705 101 for Error-Cause 707 Length 709 6 711 Value 713 The Value field is four octets, containing an integer specifying 714 the cause of the error. Values 0-199 and 300-399 are reserved. 715 Values 200-299 represent successful completion, so that these 716 values may only be sent within CoA-ACK or Disconnect-ACK packets 717 and MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet. 718 Values 400-499 represent fatal errors committed by the Dynamic 719 Authorization Client, so that they MAY be sent within CoA-NAK or 720 Disconnect-NAK packets, and MUST NOT be sent within CoA-ACK or 721 Disconnect-ACK packets. Values 500-599 represent fatal errors 722 occurring on a Dynamic Authorization Server, so that they MAY be 723 sent within CoA-NAK and Disconnect-NAK packets, and MUST NOT be 724 sent within CoA-ACK or Disconnect-ACK packets. Error-Cause values 725 SHOULD be logged by the Dynamic Authorization Client. Error-Code 726 values (expressed in decimal) include: 728 # Value 729 --- ----- 730 201 Residual Session Context Removed 731 202 Invalid EAP Packet (Ignored) 732 401 Unsupported Attribute 733 402 Missing Attribute 734 403 NAS Identification Mismatch 735 404 Invalid Request 736 405 Unsupported Service 737 406 Unsupported Extension 738 407 Invalid Attribute Value 739 501 Administratively Prohibited 740 502 Request Not Routable (Proxy) 741 503 Session Context Not Found 742 504 Session Context Not Removable 743 505 Other Proxy Processing Error 744 506 Resources Unavailable 745 507 Request Initiated 746 508 Multiple Session Selection Unsupported 748 "Residual Session Context Removed" is sent in response to a 749 Disconnect-Request if one or more user session(s) are no longer 750 active, but residual session context was found and successfully 751 removed. This value is only sent within a Disconnect-ACK and MUST 752 NOT be sent within a CoA-ACK, Disconnect-NAK or CoA-NAK. 754 "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT 755 be sent by implementations of this specification. 757 "Unsupported Attribute" is a fatal error sent if a Request 758 contains an attribute (such as a Vendor-Specific or EAP-Message 759 Attribute) that is not supported. 761 "Missing Attribute" is a fatal error sent if critical attributes 762 (such as NAS or session identification attributes) are missing 763 from a Request. 765 "NAS Identification Mismatch" is a fatal error sent if one or more 766 NAS identification attributes (see Section 3) do not match the 767 identity of the NAS receiving the Request. 769 "Invalid Request" is a fatal error sent if some other aspect of 770 the Request is invalid, such as if one or more attributes (such as 771 EAP- Message Attribute(s)) are not formatted properly. 773 "Unsupported Service" is a fatal error sent if a Service-Type 774 Attribute included with the Request is sent with an invalid or 775 unsupported value. This error cannot be sent in response to a 776 Disconnect-Request. 778 "Unsupported Extension" is a fatal error sent due to lack of 779 support for an extension such as Disconnect and/or CoA packets. 780 This will typically be sent by a proxy receiving an ICMP port 781 unreachable message after attempting to forward a CoA-Request or 782 Disconnect-Request to the NAS. 784 "Invalid Attribute Value" is a fatal error sent if a CoA-Request 785 or Disconnect-Request contains an attribute with an unsupported 786 value. 788 "Administratively Prohibited" is a fatal error sent if the NAS is 789 configured to prohibit honoring of CoA-Request or Disconnect- 790 Request packets for the specified session. 792 "Request Not Routable" is a fatal error which MAY be sent by a 793 proxy and MUST NOT be sent by a NAS. It indicates that the proxy 794 was unable to determine how to route a CoA-Request or Disconnect- 795 Request to the NAS. For example, this can occur if the required 796 entries are not present in the proxy's realm routing table. 798 "Session Context Not Found" is a fatal error sent if the session 799 context identified in the CoA-Request or Disconnect-Request does 800 not exist on the NAS. 802 "Session Context Not Removable" is a fatal error sent in response 803 to a Disconnect-Request if the NAS was able to locate the session 804 context, but could not remove it for some reason. It MUST NOT be 805 sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a 806 Disconnect-NAK. 808 "Other Proxy Processing Error" is a fatal error sent in response 809 to a CoA or Disconnect-Request that could not be processed by a 810 proxy, for reasons other than routing. 812 "Resources Unavailable" is a fatal error sent when a CoA or 813 Disconnect-Request could not be honored due to lack of available 814 NAS resources (memory, non- volatile storage, etc.). 816 "Request Initiated" is a fatal error sent by a NAS in response to 817 a CoA-Request including a Service-Type Attribute with a value of 818 "Authorize Only". It indicates that the CoA-Request has not been 819 honored, but that the NAS is sending one or more RADIUS Access- 820 Request(s) including a Service-Type Attribute with value 821 "Authorize Only" to the RADIUS server. 823 "Multiple Session Selection Unsupported" is a fatal error sent by 824 a NAS in response to a CoA-Request or Disconnect-Request whose 825 session identification attributes match multiple sessions, where 826 the NAS does not support Requests applying to multiple sessions. 828 3.6. Table of Attributes 830 The following table provides a guide to which attributes may be found 831 in which packets, and in what quantity. 833 Change-of-Authorization Messages 835 Request ACK NAK # Attribute 836 0-1 0 0 1 User-Name [Note 1] 837 0-1 0 0 4 NAS-IP-Address [Note 1] 838 0-1 0 0 5 NAS-Port [Note 1] 839 0-1 0 0-1 6 Service-Type 840 0-1 0 0 7 Framed-Protocol [Note 3] 841 0-1 0 0 8 Framed-IP-Address [Notes 1,6] 842 0-1 0 0 9 Framed-IP-Netmask [Note 3] 843 0-1 0 0 10 Framed-Routing [Note 3] 844 0+ 0 0 11 Filter-ID [Note 3] 845 0-1 0 0 12 Framed-MTU [Note 3] 846 Request ACK NAK # Attribute 847 Request ACK NAK # Attribute 848 0+ 0 0 13 Framed-Compression [Note 3] 849 0+ 0 0 14 Login-IP-Host [Note 3] 850 0-1 0 0 15 Login-Service [Note 3] 851 0-1 0 0 16 Login-TCP-Port [Note 3] 852 0+ 0 0 18 Reply-Message [Note 2] 853 0-1 0 0 19 Callback-Number [Note 3] 854 0-1 0 0 20 Callback-Id [Note 3] 855 0+ 0 0 22 Framed-Route [Note 3] 856 0-1 0 0 23 Framed-IPX-Network [Note 3] 857 0-1 0-1 0-1 24 State 858 0+ 0 0 25 Class [Note 3] 859 0+ 0 0 26 Vendor-Specific [Note 7] 860 0-1 0 0 27 Session-Timeout [Note 3] 861 0-1 0 0 28 Idle-Timeout [Note 3] 862 0-1 0 0 29 Termination-Action [Note 3] 863 0-1 0 0 30 Called-Station-Id [Note 1] 864 0-1 0 0 31 Calling-Station-Id [Note 1] 865 0-1 0 0 32 NAS-Identifier [Note 1] 866 0+ 0+ 0+ 33 Proxy-State 867 0-1 0 0 34 Login-LAT-Service [Note 3] 868 0-1 0 0 35 Login-LAT-Node [Note 3] 869 0-1 0 0 36 Login-LAT-Group [Note 3] 870 0-1 0 0 37 Framed-AppleTalk-Link [Note 3] 871 0+ 0 0 38 Framed-AppleTalk-Network [Note 3] 872 0-1 0 0 39 Framed-AppleTalk-Zone [Note 3] 873 0-1 0 0 44 Acct-Session-Id [Note 1] 874 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] 875 0-1 0-1 0-1 55 Event-Timestamp 876 0+ 0 0 56 Egress-VLANID [Note 3] 877 0-1 0 0 57 Ingress-Filters [Note 3] 878 0+ 0 0 58 Egress-VLAN-Name [Note 3] 879 0-1 0 0 59 User-Priority-Table [Note 3] 880 0-1 0 0 61 NAS-Port-Type [Note 3] 881 0-1 0 0 62 Port-Limit [Note 3] 882 0-1 0 0 63 Login-LAT-Port [Note 3] 883 0+ 0 0 64 Tunnel-Type [Note 5] 884 0+ 0 0 65 Tunnel-Medium-Type [Note 5] 885 0+ 0 0 66 Tunnel-Client-Endpoint [Note 5] 886 0+ 0 0 67 Tunnel-Server-Endpoint [Note 5] 887 0+ 0 0 69 Tunnel-Password [Note 5] 888 0-1 0 0 71 ARAP-Features [Note 3] 889 0-1 0 0 72 ARAP-Zone-Access [Note 3] 890 0+ 0 0 78 Configuration-Token [Note 3] 891 Request ACK NAK # Attribute 892 Request ACK NAK # Attribute 893 0+ 0-1 0 79 EAP-Message [Note 2] 894 0-1 0-1 0-1 80 Message-Authenticator 895 0+ 0 0 81 Tunnel-Private-Group-ID [Note 5] 896 0+ 0 0 82 Tunnel-Assignment-ID [Note 5] 897 0+ 0 0 83 Tunnel-Preference [Note 5] 898 0-1 0 0 85 Acct-Interim-Interval [Note 3] 899 0-1 0 0 87 NAS-Port-Id [Note 1] 900 0-1 0 0 88 Framed-Pool [Note 3] 901 0-1 0 0 89 Chargeable-User-Identity [Note 1] 902 0+ 0 0 90 Tunnel-Client-Auth-ID [Note 5] 903 0+ 0 0 91 Tunnel-Server-Auth-ID [Note 5] 904 0-1 0 0 92 NAS-Filter-Rule [Note 3] 905 0 0 0 94 Originating-Line-Info 906 0-1 0 0 95 NAS-IPv6-Address [Note 1] 907 0-1 0 0 96 Framed-Interface-Id [Notes 1,6] 908 0+ 0 0 97 Framed-IPv6-Prefix [Notes 1,6] 909 0+ 0 0 98 Login-IPv6-Host [Note 3] 910 0+ 0 0 99 Framed-IPv6-Route [Note 3] 911 0-1 0 0 100 Framed-IPv6-Pool [Note 3] 912 0 0 0+ 101 Error-Cause 913 0+ 0 0 123 Delegated-IPv6-Prefix [Note 3] 914 Request ACK NAK # Attribute 916 Disconnect Messages 918 Request ACK NAK # Attribute 919 0-1 0 0 1 User-Name [Note 1] 920 0-1 0 0 4 NAS-IP-Address [Note 1] 921 0-1 0 0 5 NAS-Port [Note 1] 922 0 0 0 6 Service-Type 923 0 0 0 8 Framed-IP-Address [Note 1] 924 0+ 0 0 18 Reply-Message [Note 2] 925 0 0 0 24 State 926 0+ 0 0 25 Class [Note 4] 927 0+ 0 0 26 Vendor-Specific [Note 1] 928 0-1 0 0 30 Called-Station-Id [Note 1] 929 0-1 0 0 31 Calling-Station-Id [Note 1] 930 0-1 0 0 32 NAS-Identifier [Note 1] 931 0+ 0+ 0+ 33 Proxy-State 932 0-1 0 0 44 Acct-Session-Id [Note 1] 933 0-1 0-1 0 49 Acct-Terminate-Cause 934 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] 935 0-1 0-1 0-1 55 Event-Timestamp 936 0 0 0 61 NAS-Port-Type 937 0+ 0-1 0 79 EAP-Message [Note 2] 938 Request ACK NAK # Attribute 939 Request ACK NAK # Attribute 940 0-1 0-1 0-1 80 Message-Authenticator 941 0-1 0 0 87 NAS-Port-Id [Note 1] 942 0-1 0 0 89 Chargeable-User-Identity [Note 1] 943 0-1 0 0 95 NAS-IPv6-Address [Note 1] 944 0 0 0 96 Framed-Interface-Id [Note 1] 945 0 0 0 97 Framed-IPv6-Prefix [Note 1] 946 0 0 0+ 101 Error-Cause 947 Request ACK NAK # Attribute 949 The following table defines the meaning of the above table entries. 951 0 This attribute MUST NOT be present in packet. 952 0+ Zero or more instances of this attribute MAY be present in packet. 953 0-1 Zero or one instance of this attribute MAY be present in packet. 954 1 Exactly one instance of this attribute MUST be present in packet. 956 [Note 1] Where NAS or session identification attributes are included 957 in Disconnect-Request or CoA-Request packets, they are used for 958 identification purposes only. These attributes MUST NOT be used for 959 purposes other than identification (e.g. within CoA-Request packets 960 to request authorization changes). 962 [Note 2] The Reply-Message Attribute is used to present a displayable 963 message to the user. The message is only displayed as a result of a 964 successful Disconnect-Request or CoA-Request (where a Disconnect-ACK 965 or CoA-ACK is subsequently sent). Where EAP is used for 966 authentication, an EAP-Message/Notification-Request Attribute is sent 967 instead, and Disconnect-ACK or CoA-ACK packets contain an EAP- 968 Message/Notification-Response Attribute. 970 [Note 3] When included within a CoA-Request, these attributes 971 represent an authorization change request. When one of these 972 attributes is omitted from a CoA-Request, the NAS assumes that the 973 attribute value is to remain unchanged. Attributes included in a 974 CoA-Request replace all existing value(s) of the same attribute(s). 976 [Note 4] When included within a successful Disconnect-Request (where 977 a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be 978 sent unmodified by the NAS to the RADIUS accounting server in the 979 Accounting Stop packet. If the Disconnect-Request is unsuccessful, 980 then the Class Attribute is not processed. 982 [Note 5] When included within a CoA-Request, these attributes 983 represent an authorization change request. Where tunnel attribute(s) 984 are included within a successful CoA-Request, all existing tunnel 985 attributes are removed and replaced by the new attribute(s). 987 [Note 6] Since the Framed-IP-Address, Framed-IPv6-Prefix and Framed- 988 Interface-Id attributes are used for session identification, 989 renumbering cannot be accomplished by including values of these 990 attributes within a CoA-Request. Instead, a CoA-Request including a 991 Service-Type Attribute with a value of "Authorize Only" is sent; new 992 values can be supplied in an Access-Accept sent in response to the 993 ensuing Access-Request. Note that renumbering will not be possible 994 in all situations. For example, in order to change an IP address, 995 IPCP or IPv6CP re-negotiation could be required, which is not 996 supported by all PPP implementations. 998 [Note 7] Within CoA-Request packets, Vendor-Specific Attributes 999 (VSAs) MAY be used for either session identification or authorization 1000 change. However, the same Attribute MUST NOT be used for both 1001 purposes simultaneously. 1003 4. Diameter Considerations 1005 Due to differences in handling change-of-authorization requests in 1006 RADIUS and Diameter, it may be difficult or impossible for a 1007 Diameter/RADIUS gateway to successfully translate a Diameter Re-Auth- 1008 Request (RAR) to a CoA-Request and vice versa. For example, since a 1009 CoA-Request only initiates an authorization change but does not 1010 initiate re-authentication, a RAR command containing a Re-Auth- 1011 Request-Type AVP with value "AUTHORIZE_AUTHENTICATE" cannot be 1012 directly translated to a CoA-Request. A Diameter/RADIUS gateway 1013 receiving a CoA-Request containing authorization changes will need to 1014 translate this into two Diameter exchanges. First, the 1015 Diameter/RADIUS gateway will issue a RAR command including a Session- 1016 Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". 1017 Then the Diameter/RADIUS gateway will respond to the ensuing access 1018 request with a response including the authorization attributes 1019 gleaned from the CoA-Request. To enable translation, the CoA-Request 1020 SHOULD include a Acct-Session-Id Attribute. If the Diameter client 1021 uses the same Session-Id for both authorization and accounting, then 1022 the Diameter/RADIUS gateway can copy the contents of the Acct- 1023 Session-Id Attribute into the Session-Id AVP; otherwise, it will 1024 need to map the Acct-Session-Id value to an equivalent Session-Id for 1025 use within a RAR command. 1027 Where an Acct-Session-Id attribute is not present in a CoA-Request or 1028 Disconnect-Request, a Diameter/RADIUS gateway will either need to 1029 determine the appropriate Acct-Session-Id, or if it cannot do so, it 1030 can send a CoA-NAK or Disconnect-NAK in reply, possibly including an 1031 Error-Cause Attribute with value 508 (Multiple Session Identification 1032 Unsupported). 1034 To simplify translation between RADIUS and Diameter, Dynamic 1035 Authorization Clients can include a Service-Type Attribute with value 1036 "Authorize Only" within a CoA-Request, as described in Section 3.2. 1037 A Diameter/RADIUS gateway receiving a CoA-Request containing a 1038 Service-Type with value "Authorize Only" translates this to a RAR 1039 with Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". The 1040 received RAA is then translated to a CoA-NAK with a Service-Type 1041 value of "Authorize Only". If the Result-Code AVP in the RAA has a 1042 value in the success category, then an Error-Cause Attribute with 1043 value "Request Initiated" is included in the CoA-NAK. If the 1044 Result-Code AVP in the RAA has a value indicating a Protocol Error or 1045 a Transient or Permanent Failure, then an alternate Error-Cause 1046 Attribute is returned as suggested below. 1048 Within Diameter, a server can request that a session be aborted by 1049 sending an Abort-Session-Request (ASR), identifying the session to be 1050 terminated using Session-ID and User-Name AVPs. The ASR command is 1051 translated to a Disconnect-Request containing Acct-Session-Id and 1052 User-Name attributes. If the Diameter client utilizes the same 1053 Session-Id in both authorization and accounting, then the value of 1054 the Session-ID AVP may be placed in the Acct-Session-Id attribute; 1055 otherwise the value of the Session-ID AVP will need to be mapped to 1056 an appropriate Acct-Session-Id value. To enable translation of a 1057 Disconnect-Request to an ASR, an Acct-Session-Id attribute SHOULD be 1058 present. 1060 If the Diameter client utilizes the same Session-Id in both 1061 authorization and accounting, then the value of the Acct-Session-Id 1062 may be placed into the Session-ID AVP within the ASR; otherwise the 1063 value of the Acct-Session-Id will need to be mapped to an appropriate 1064 Session-ID value. 1066 An Abort-Session-Answer (ASA) command is sent in response to an ASR 1067 in order to indicate the disposition of the request. A 1068 Diameter/RADIUS gateway receiving a Disconnect-ACK translates this to 1069 an ASA command with a Result-Code AVP of "DIAMETER_SUCCESS". A 1070 Disconnect-NAK received from the NAS is translated to an ASA command 1071 with a Result-Code AVP which depends on the value of the Error-Cause 1072 Attribute. Suggested translations between Error-Cause Attribute 1073 values and Result-Code AVP values are included below: 1075 # Error-Cause Attribute Value Result-Code AVP 1076 --- --------------------------- ------------------------ 1077 201 Residual Session Context DIAMETER_SUCCESS 1078 Removed 1079 202 Invalid EAP Packet DIAMETER_LIMITED_SUCCESS 1080 (Ignored) 1081 401 Unsupported Attribute DIAMETER_AVP_UNSUPPORTED 1082 402 Missing Attribute DIAMETER_MISSING_AVP 1083 403 NAS Identification DIAMETER_REALM_NOT_SERVED 1084 Mismatch 1085 404 Invalid Request DIAMETER_UNABLE_TO_COMPLY 1086 405 Unsupported Service DIAMETER_COMMAND_UNSUPPORTED 1087 406 Unsupported Extension DIAMETER_APPLICATION_UNSUPPORTED 1088 407 Invalid Attribute Value DIAMETER_INVALID_AVP_VALUE 1089 501 Administratively DIAMETER_AUTHORIZATION_REJECTED 1090 Prohibited 1091 502 Request Not Routable (Proxy) DIAMETER_UNABLE_TO_DELIVER 1092 503 Session Context Not Found DIAMETER_UNKNOWN_SESSION_ID 1093 504 Session Context Not DIAMETER_AUTHORIZATION_REJECTED 1094 Removable 1095 505 Other Proxy Processing DIAMETER_UNABLE_TO_COMPLY 1096 Error 1097 506 Resources Unavailable DIAMETER_RESOURCES_EXCEEDED 1098 507 Request Initiated DIAMETER_SUCCESS 1100 Since both the ASR/ASA and Disconnect-Request/Disconnect- 1101 NAK/Disconnect-ACK exchanges involve just a request and response, 1102 inclusion of an "Authorize Only" Service-Type within a Disconnect- 1103 Request is not needed to assist in Diameter/RADIUS translation, and 1104 may make translation more difficult. As a result, as noted in 1105 Section 3.2, the Service-Type Attribute MUST NOT be used within a 1106 Disconnect-Request. 1108 5. IANA Considerations 1110 This document uses the RADIUS [RFC2865] namespace, see 1111 . In addition to the 1112 allocations already made in [RFC3575] and [RFC3576], this 1113 specification requests allocation of additional values of the Error- 1114 Cause Attribute (101): 1116 # Value 1117 --- ----- 1118 407 Invalid Attribute Value 1119 508 Multiple Session Selection Unsupported 1121 6. Security Considerations 1123 6.1. Authorization Issues 1125 Where a NAS is shared by multiple providers, it is undesirable for 1126 one provider to be able to send Disconnect-Request or CoA-Requests 1127 affecting the sessions of another provider. 1129 A Dynamic Authorization Server MUST silently discard Disconnect- 1130 Request or CoA-Request packets from untrusted sources. In situations 1131 where the Dynamic Authorization Client is co-resident with a RADIUS 1132 authentication or accounting server, a proxy MAY perform a "reverse 1133 path forwarding" (RPF) check to verify that a Disconnect-Request or 1134 CoA-Request originates from an authorized Dynamic Authorization 1135 Client. In addition, it SHOULD be possible to explicitly authorize 1136 additional sources of Disconnect-Request or CoA-Request packets 1137 relating to certain classes of sessions. For example, a particular 1138 source can be explicitly authorized to send CoA-Request packets 1139 relating to users within a set of realms. 1141 To perform the RPF check, the Dynamic Authorization Server uses the 1142 session identification attributes included in Disconnect-Request or 1143 CoA-Request packets, in order to determine the RADIUS server(s) to 1144 which an equivalent Access-Request could be routed. If the source 1145 address of the Disconnect-Request or CoA-Request is within this set, 1146 then the CoA-Request or Disconnect-Request is forwarded; otherwise it 1147 MUST be silently discarded. 1149 Typically the Dynamic Authorization Server will extract the realm 1150 from the Network Access Identifier [RFC4282] included within the 1151 User-Name or Chargeable-User-Identity Attribute, and determine the 1152 corresponding RADIUS servers in the realm routing tables. If the 1153 Dynamic Authorization Server maintains long-term session state, it 1154 MAY perform the authorization check based on the session 1155 identification attributes in the CoA-Request. The session 1156 identification attributes can be used to tie a session to a 1157 particular proxy or set of proxies, as with the NAI realm. 1159 Where no proxy is present, the RPF check can only be performed by the 1160 NAS if it maintains its own a realm routing table. If the NAS does 1161 not maintain a realm routing table (e.g. it selects forwarding 1162 proxies based on primary/secondary configuration and/or liveness 1163 checks), then an RPF check cannot be performed. 1165 Since authorization to send a Disconnect-Request or CoA-Request is 1166 determined based on the source address and the corresponding shared 1167 secret, the Dynamic Authorization Server SHOULD configure a different 1168 shared secret for each Dynamic Authorization Client. 1170 6.2. Impersonation 1172 [RFC2865] Section 3 states: 1174 A RADIUS server MUST use the source IP address of the RADIUS 1175 UDP packet to decide which shared secret to use, so that 1176 RADIUS requests can be proxied. 1178 When RADIUS Access-Requests are forwarded by a proxy, the NAS-IP- 1179 Address or NAS-IPv6-Address Attributes will typically not match the 1180 source address observed by the RADIUS server. Since the NAS- 1181 Identifier Attribute need not contain an FQDN, this Attribute may not 1182 be resolvable to the source address observed by the RADIUS server, 1183 even when no proxy is present. 1185 As a result, the authenticity check performed by a RADIUS server or 1186 proxy does not verify the correctness of NAS identification 1187 attributes. This makes it possible for a rogue NAS to forge NAS-IP- 1188 Address, NAS-IPv6-Address or NAS-Identifier Attributes within a 1189 RADIUS Access-Request in order to impersonate another NAS. It is 1190 also possible for a rogue NAS to forge attributes such as the Called- 1191 Station-Id, Calling-Station-Id, or Originating-Line-Info [RFC4005]. 1192 This could fool the Dynamic Authorization Client into sending CoA- 1193 Request or Disconnect-Request packets containing forged session 1194 identification attributes to a NAS targeted by an attacker. 1196 To address these vulnerabilities RADIUS proxies one hop from the NAS 1197 SHOULD check whether NAS identification attributes (see Section 3) 1198 match the packet source address. Where one or more attributes do not 1199 match, Access-Request packets SHOULD be silently discarded. 1201 Such a check may not always be possible. Since the NAS-Identifier 1202 Attribute need not correspond to an FQDN, it may not be resolvable to 1203 an IP address to be matched against the source address. Also, where 1204 a NAT exists between the RADIUS client and proxy, checking the NAS- 1205 IP-Address or NAS-IPv6-Address Attributes may not be feasible. 1207 6.3. IPsec Usage Guidelines 1209 In addition to security vulnerabilities unique to Disconnect or CoA 1210 packets, the protocol exchanges described in this document are 1211 susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is 1212 RECOMMENDED that IPsec be employed to afford better security. 1214 Implementations of this specification SHOULD support IPsec [RFC4301] 1215 along with IKEv1 [RFC2409] for key management. IPsec ESP [RFC4303] 1216 with non-null transform SHOULD be supported, and IPsec ESP with a 1217 non-null encryption transform and authentication support SHOULD be 1218 used to provide per-packet confidentiality, authentication, integrity 1219 and replay protection. IKE SHOULD be used for key management. 1221 Within RADIUS [RFC2865], a shared secret is used for hiding of 1222 Attributes such as User-Password, as well as in computation of the 1223 Response Authenticator. In RADIUS accounting [RFC2866], the shared 1224 secret is used in computation of both the Request Authenticator and 1225 the Response Authenticator. 1227 Since in RADIUS a shared secret is used to provide confidentiality as 1228 well as integrity protection and authentication, only use of IPsec 1229 ESP with a non-null transform can provide security services 1230 sufficient to substitute for RADIUS application-layer security. 1231 Therefore, where IPsec AH or ESP null is used, it will typically 1232 still be necessary to configure a RADIUS shared secret. 1234 Where RADIUS is run over IPsec ESP with a non-null transform, the 1235 secret shared between the Dynamic Authorization Server and the 1236 Dynamic Authorization Client MAY NOT be configured. In this case, a 1237 shared secret of zero length MUST be assumed. However, a Dynamic 1238 Authorization Client that cannot know whether incoming traffic is 1239 IPsec-protected MUST be configured with a non-null RADIUS shared 1240 secret. 1242 When IPsec ESP is used with RADIUS, per-packet authentication, 1243 integrity and replay protection MUST be used. 3DES-CBC MUST be 1244 supported as an encryption transform and AES-CBC SHOULD be supported. 1245 AES-CBC SHOULD be offered as a preferred encryption transform if 1246 supported. HMAC-SHA1-96 MUST be supported as an authentication 1247 transform. DES-CBC SHOULD NOT be used as the encryption transform. 1249 A typical IPsec policy for an IPsec-capable RADIUS client is 1250 "Initiate IPsec, from me to any destination port UDP 1812". This 1251 IPsec policy causes an IPsec SA to be set up by the RADIUS client 1252 prior to sending a RADIUS Access-Request to a RADIUS server. If some 1253 RADIUS servers contacted by the RADIUS client do not support IPsec, 1254 then a more granular policy will be required: "Initiate IPsec, from 1255 me to IPsec-Capable-RADIUS-Server, destination port UDP 1812." 1257 For a Dynamic Authorization Server implementing this specification 1258 the policy would be "Accept IPsec, from any to me, destination port 1259 UDP 3799". This causes the Dynamic Authorization Server to accept 1260 (but not require) use of IPsec. It may not be appropriate to require 1261 IPsec for all Dynamic Authorization Clients connecting to an IPsec- 1262 enabled Dynamic Authorization Server, since some Dynamic 1263 Authorization Clients may not support IPsec. 1265 For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept 1266 IPsec, from any to me, destination port 1812". This causes the 1267 RADIUS server to accept (but not require) use of IPsec. It may not 1268 be appropriate to require IPsec for all RADIUS clients connecting to 1269 an IPsec-enabled RADIUS server, since some RADIUS clients may not 1270 support IPsec. 1272 For Dynamic Authorization Clients implementing this specification, 1273 the policy would be "Initiate IPsec, from me to any, destination port 1274 UDP 3799". This causes the Dynamic Authorization Client to initiate 1275 IPsec when sending Dynamic Authorization traffic to any Dynamic 1276 Authorization Server. If some Dynamic Authorization Servers 1277 contacted by the Dynamic Authorization Client do not support IPsec, 1278 then a more granular policy will be required, such as "Initiate 1279 IPsec, from me to IPsec-capable-Dynamic-Authorization-Server, 1280 destination port UDP 3799". 1282 Where IPsec is used for security, and no RADIUS shared secret is 1283 configured, it is important that the Dynamic Authorization Server and 1284 Dynamic Authorization Client perform an authorization check. Before 1285 enabling a host to act as a Dynamic Authorization Server, the Dynamic 1286 Authorization Client SHOULD check whether the host is authorized to 1287 act in that role. Similarly, before enabling a host to act as a 1288 Dynamic Authorization Client, the Dynamic Authorization Server SHOULD 1289 check whether the host is authorized for that role. 1291 Dynamic Authorization Clients can be configured with the IP addresses 1292 (for IKEv1 Aggressive Mode with pre-shared keys) or FQDNs (for 1293 certificate authentication) of Dynamic Authorization Servers. 1294 Alternatively, if a separate Certification Authority (CA) exists for 1295 Dynamic Authorization Servers, then the Dynamic Authorization Client 1296 can configure this CA as a trust anchor [RFC3280] for use with IKEv1. 1298 Similarly, Dynamic Authorization Servers can be configured with the 1299 IP addresses (for IKEv1 Aggressive Mode with pre-shared keys) or 1300 FQDNs (for certificate authentication) of Dynamic Authorization 1301 Clients. Alternatively, if a separate CA exists for Dynamic 1302 Authorization Clients, then the Dynamic Authorization Server can 1303 configure this CA as a trust anchor for use with IKEv1. 1305 Since unlike SSL/TLS, IKEv1 does not permit certificate policies to 1306 be set on a per-port basis, certificate policies need to apply to all 1307 uses of IKEv1 on Dynamic Authorization Servers and Dynamic 1308 Authorization Clients. In a deployment supporting only certificate 1309 authentication, a management station initiating an IPsec-protected 1310 telnet session to the Dynamic Authorization Client would need to 1311 obtain a certificate chaining to the Dynamic Authorization Server CA. 1312 Issuing such a certificate might not be appropriate if the management 1313 station was not authorized as a Dynamic Authorization Server. 1315 Where Dynamic Authorization Servers obtain their IP address 1316 dynamically (such as an Access Point supporting DHCP), IKEv1 Main 1317 Mode with pre-shared keys [RFC2409] SHOULD NOT be used, since this 1318 requires use of a group pre-shared key; instead, Aggressive Mode 1319 SHOULD be used. Where Dynamic Authorization Server addresses are 1320 statically assigned either IKEv1 Aggressive Mode or Main Mode MAY be 1321 used. With certificate authentication, IKEv1 Main Mode SHOULD be 1322 used. 1324 Care needs to be taken with IKEv1 Phase 1 Identity Payload selection 1325 in order to enable mapping of identities to pre-shared keys even with 1326 Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity 1327 Payloads are used and addresses are dynamically assigned, mapping of 1328 identities to keys is not possible, so that group pre-shared keys are 1329 still a practical necessity. As a result, the ID_FQDN identity 1330 payload SHOULD be employed in situations where Aggressive mode is 1331 utilized along with pre-shared keys and IP addresses are dynamically 1332 assigned. This approach also has other advantages, since it allows 1333 the Dynamic Authorization Client and Dynamic Authorization Server to 1334 configure themselves based on the fully qualified domain name of 1335 their peers. 1337 Note that with IPsec, security services are negotiated at the 1338 granularity of an IPsec SA, so that exchanges requiring a set of 1339 security services different from those negotiated with existing IPsec 1340 SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are 1341 also advisable where quality of service considerations dictate 1342 different handling RADIUS conversations. Attempting to apply 1343 different quality of service to connections handled by the same IPsec 1344 SA can result in reordering, and falling outside the replay window. 1345 For a discussion of the issues, see [RFC2983]. 1347 6.4. Replay Protection 1349 Where IPsec replay protection is not used, an Event-Timestamp (55) 1350 [RFC2869] Attribute SHOULD be included within CoA-Request and 1351 Disconnect-Request packets, and MAY be included within CoA-ACK, CoA- 1352 NAK, Disconnect-ACK and Disconnect-NAK packets. 1354 When the Event-Timestamp attribute is present, both the Dynamic 1355 Authorization Server and the Dynamic Authorization Client MUST check 1356 that the Event-Timestamp Attribute is current within an acceptable 1357 time window. If the Event-Timestamp Attribute is not current, then 1358 the packet MUST be silently discarded. This implies the need for 1359 loose time synchronization within the network, which can be achieved 1360 by a variety of means, including SNTP, as described in [RFC4330]. 1361 Implementations SHOULD be configurable to discard CoA-Request or 1362 Disconnect-Request packets not containing an Event-Timestamp 1363 attribute. 1365 If the Event-Timestamp Attribute is included, it represents the time 1366 at which the original packet was sent, and therefore it SHOULD NOT be 1367 updated when the packet is retransmitted. If the Event-Timestamp 1368 attribute is not updated, this implies that the Identifier is not 1369 changed in retransmitted packets. As a result, the ability to detect 1370 replay within the time window is dependent on support for duplicate 1371 detection within that same window. As noted in Section 2.3, 1372 duplicate detection is REQUIRED for Dynamic Authorization Servers 1373 implementing this specification. 1375 The time window used for duplicate detection MUST be the same as the 1376 window used to detect stale Event-Timestamp Attributes. Since the 1377 RADIUS Identifier cannot be repeated within the selected time window, 1378 no more than 256 Requests can be accepted within the time window. As 1379 a result, the chosen time window will depend on the expected maximum 1380 volume of CoA/Disconnect-Requests, so that unnecessary discards can 1381 be avoided. A default time window of 300 seconds should be adequate 1382 in many circumstances. 1384 7. Example Traces 1386 Disconnect Request with User-Name: 1388 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....# 1389 16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^.. 1390 32: 6d63 6869 6261 1392 Disconnect Request with Acct-Session-ID: 1394 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(..... 1395 16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,. 1396 32: 3930 3233 3435 3637 90234567 1398 Disconnect Request with Framed-IP-Address: 1400 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(..... 1401 16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ... 1402 32: 0a00 0203 1404 8. References 1406 8.1. Normative References 1408 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1409 April 1992. 1411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1412 Requirement Levels", RFC 2119, March 1997. 1414 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1415 RFC 2409, November 1998. 1417 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 1418 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1419 2000. 1421 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1423 [RFC2869] Rigney, C., Willats W. and P. Calhoun, "RADIUS Extensions", 1424 RFC 2869, June 2000. 1426 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 1427 3162, August 2001. 1429 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 1430 Public Key Infrastructure Certificate and Certificate 1431 Revocation List (CRL) Profile", RFC 3280, April 2002. 1433 [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July 1434 2003. 1436 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 1437 Authentication Protocol (EAP)", RFC 3579, September 2003. 1439 [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network 1440 Access Identifier", RFC 4282, December 2005. 1442 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet 1443 Protocol", RFC 4301, December 2005. 1445 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 1446 December 2005. 1448 8.2. Informative References 1450 [MD5Attack] 1451 Dobbertin, H., "The Status of MD5 After a Recent Attack", 1452 CryptoBytes Vol.2 No.2, Summer 1996. 1454 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. 1455 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1456 Support", RFC 2868, June 2000. 1458 [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, 1459 October 2000. 1461 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 1462 Accounting Transport Profile", RFC 3539, June 2003. 1464 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 1465 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1467 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 1468 "Dynamic Authorization Extensions to Remote Authentication 1469 Dial In User Service (RADIUS)", RFC 3576, July 2003. 1471 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 1472 Network Access Server Application", RFC 4005, August 2005. 1474 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for 1475 IPv4, IPv6 and OSI", RFC 4330, January 2006. 1477 [RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, 1478 "Chargeable User Identity", RFC 4372, January 2006. 1480 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for 1481 Virtual LAN and Priority Support", RFC 4675, September 2006. 1483 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1484 Attribute", RFC 4818, April 2007. 1486 [RFC4849] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Filter Rule 1487 Attribute", RFC 4849, April 2007. 1489 Acknowledgments 1491 This protocol was first developed and distributed by Ascend 1492 Communications. Example code was distributed in their free server 1493 kit. 1495 The authors would like to acknowledge valuable suggestions and 1496 feedback from Avi Lior, Randy Bush, Steve Bellovin, Glen Zorn, Mark 1497 Jones, Claudio Lapidus, Anurag Batta, Kuntal Chowdhury, Tim Moore, 1498 Russ Housley, Joe Salowey, Alan DeKok and David Nelson. 1500 Authors' Addresses 1502 Murtaza Chiba 1503 Cisco Systems, Inc. 1504 170 West Tasman Dr. 1505 San Jose CA, 95134 1507 EMail: mchiba@cisco.com 1508 Phone: +1 408 525 7198 1510 Gopal Dommety 1511 Cisco Systems, Inc. 1512 170 West Tasman Dr. 1513 San Jose, CA 95134 1515 EMail: gdommety@cisco.com 1516 Phone: +1 408 525 1404 1518 Mark Eklund 1519 Cisco Systems, Inc. 1520 170 West Tasman Dr. 1521 San Jose, CA 95134 1523 EMail: meklund@cisco.com 1524 Phone: +1 865 671 6255 1526 David Mitton 1527 RSA Security, Inc. 1528 174 Middlesex Turnpike 1529 Bedford, MA 01730 1531 EMail: dmitton@circularnetworks.com 1533 Bernard Aboba 1534 Microsoft Corporation 1535 One Microsoft Way 1536 Redmond, WA 98052 1538 EMail: bernarda@microsoft.com 1539 Phone: +1 425 706 6605 1540 Fax: +1 425 936 7329 1542 Appendix A - Changes from RFC 3576 1544 This Appendix lists the major changes between [RFC3576] and this 1545 document. Minor changes, including style, grammar, spelling, and 1546 editorial changes are not mentioned here. 1548 o The term "Dynamic Authorization Client" is used instead of RADIUS 1549 server where it applies to the originator of CoA and Disconnect- 1550 Request packets. Similarly, the term "Dynamic Authorizatin Server" 1551 is used instead of NAS where it applies to the receiver of CoA and 1552 Disconnect-Request packets. Definitions of these terms have been 1553 added (Section 1.3). 1555 o Added requirement for duplicate detection on the Dynamic 1556 Authorization Server (Section 2.3). 1558 o Clarified expected behavior when session identification attributes 1559 match more than one session (Sections 2.3, 3, 3.5, 4). 1561 o Added Chargeable-User-Identity as a session identification 1562 attribute. Removed Framed-IP-Address, Framed-IPv6-Prefix, Framed- 1563 Interface-Id and NAS-Port-Type attributes as session identification 1564 attributes. Recommended inclusion of Acct-Session-Id or Acct-Multi- 1565 Session-Id attributes in an Access-Request (Section 3). 1567 o Added recommendation that an Acct-Session-Id or Acct-Mult-Session- 1568 Id Attribute be included in an Access-Request (Section 3). 1570 o Added details relating to handling of the Proxy-State Attribute 1571 (Section 3.1). 1573 o Added clarification that support for a Service-Type Attribute with 1574 value "Authorize Only" is optional on both the NAS and Dynamic 1575 Authorization Client (Section 3.2). 1577 o Added requirement for inclusion of the State Attribute in CoA- 1578 Request packets including a Service-Type Attribute with a value of 1579 "Authorize Only" (Section 3.3). 1581 o Added clarification on the calculation of the Message-Authenticator 1582 Attribute (Section 3.4). 1584 o Additional Error-Cause Attribute values are allocated for Invalid 1585 Attribute Value (407) and Multiple Session Identification Unsupported 1586 (508) (Sections 3.5, 4). 1588 o Updated the CoA-Request Attribute Table to include Filter-Rule, 1589 Delegated-IPv6-Prefix, Egress-VLANID, Ingress-Filters, Egress-VLAN- 1590 Name and User-Priority attributes (Section 3.6). 1592 o Added the Chargeable-User-Identity Attribute to both the CoA- 1593 Request and Disconnect-Request Attribute table (Section 3.6). 1595 o The use of Vendor-Specific Attributes (VSAs) for session 1596 identification and authorization change has been clarified (Section 1597 3.6). 1599 o Added Note 6 on the use of the CoA-Request for renumbering (Section 1600 3.6). 1602 o Use of the Service-Type Attribute within a Disconnect-Request is 1603 prohibited (Sections 3.2, 3.6). 1605 o Added Diameter Considerations (Section 4). 1607 o Changed the text to indicate that the Event-Timestamp Attribute 1608 should not be recalculated on retransmission. The implications for 1609 replay and duplicate detection are discussed (Section 6.4). 1611 o Operation of the RPF check has been clarified. Use of the RPF 1612 check is optional rather than recommended by default (Section 6.1). 1614 Full Copyright Statement 1616 Copyright (C) The IETF Trust (2007). 1618 This document is subject to the rights, licenses and restrictions 1619 contained in BCP 78, and except as set forth therein, the authors 1620 retain all their rights. 1622 This document and the information contained herein are provided on an 1623 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1624 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1625 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1626 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1627 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1628 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1630 Intellectual Property 1632 The IETF takes no position regarding the validity or scope of any 1633 Intellectual Property Rights or other rights that might be claimed to 1634 pertain to the implementation or use of the technology described in 1635 this document or the extent to which any license under such rights 1636 might or might not be available; nor does it represent that it has 1637 made any independent effort to identify any such rights. Information 1638 on the procedures with respect to rights in RFC documents can be 1639 found in BCP 78 and BCP 79. 1641 Copies of IPR disclosures made to the IETF Secretariat and any 1642 assurances of licenses to be made available, or the result of an 1643 attempt made to obtain a general license or permission for the use of 1644 such proprietary rights by implementers or users of this 1645 specification can be obtained from the IETF on-line IPR repository at 1646 http://www.ietf.org/ipr. 1648 The IETF invites any interested party to bring to its attention any 1649 copyrights, patents or patent applications, or other proprietary 1650 rights that may cover technology that may be required to implement 1651 this standard. Please address the information to the IETF at ietf- 1652 ipr@ietf.org. 1654 Acknowledgment 1656 Funding for the RFC Editor function is provided by the IETF 1657 Administrative Support Activity (IASA). 1659 Open issues 1661 Open issues relating to this specification are tracked on the 1662 following web site: 1664 http://www.drizzle.com/~aboba/RADEXT/