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