idnits 2.17.1 draft-ietf-radext-rfc3576bis-09.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 1627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1651. 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.) -- The document date (31 July 2007) is 6113 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 958, but not defined == Missing Reference: 'Note 3' is mentioned on line 972, but not defined == Missing Reference: 'Notes 1' is mentioned on line 910, but not defined -- Looks like a reference, but probably isn't: '6' on line 910 == Missing Reference: 'Note 2' is mentioned on line 964, but not defined == Missing Reference: 'Note 7' is mentioned on line 1000, but not defined == Missing Reference: 'Note 5' is mentioned on line 984, but not defined == Missing Reference: 'Note 4' is mentioned on line 978, but not defined == Missing Reference: 'Note 6' is mentioned on line 989, 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 Expires: January 25, 2008 David Mitton 7 RSA Security, Inc. 8 Bernard Aboba 9 Microsoft Corporation 10 31 July 2007 12 Dynamic Authorization Extensions to Remote Authentication Dial In User 13 Service (RADIUS) 14 draft-ietf-radext-rfc3576bis-09.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 January 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 ..................................... 12 63 3.2 Authorize Only .................................. 13 64 3.3 State ........................................... 13 65 3.4 Message-Authenticator ........................... 14 66 3.5 Error-Cause ..................................... 15 67 3.6 Table of Attributes ............................. 18 68 4. Diameter Considerations ............................... 22 69 5. IANA Considerations ................................... 24 70 6. Security Considerations ............................... 25 71 6.1 Authorization Issues ............................ 25 72 6.2 Impersonation ................................... 26 73 6.3 IPsec Usage Guidelines .......................... 26 74 6.4 Replay Protection ............................... 29 75 7. Example Traces ........................................ 30 76 8. References ............................................ 30 77 8.1 Normative References ............................ 30 78 8.2 Informative References .......................... 31 79 ACKNOWLEDGMENTS .............................................. 32 80 AUTHORS' ADDRESSES ........................................... 33 81 Appendix A - Changes from RFC 3576 ........................... 34 82 Full Copyright Statement ..................................... 36 83 Intellectual Property ........................................ 36 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 | | <-------------------- | Dynamic | 208 | NAS | | Authz | 209 | | Disconnect-Response | Client | 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 | | <-------------------- | Dynamic | 243 | NAS | | Authz | 244 | | CoA-Response | Client | 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. All NAS and session identification attributes included in a 434 CoA-Request or Disconnect-Request packet MUST match at least one 435 session in order for a Request to be successful; otherwise a 436 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 3.1. Proxy State 533 If there are any Proxy-State attributes in a Disconnect-Request or 534 CoA-Request received from the Dynamic Authorization Client, the 535 Dynamic Authorization Server MUST include those Proxy-State 536 attributes in its response to the Dynamic Authorization Client. 538 A forwarding proxy or NAS MUST NOT modify existing Proxy-State, 539 State, or Class attributes present in the packet. The forwarding 540 proxy or NAS MUST treat any Proxy-State attributes already in the 541 packet as opaque data. Its operation MUST NOT depend on the content 542 of Proxy-State attributes added by previous proxies. The forwarding 543 proxy MUST NOT modify any other Proxy-State attributes that were in 544 the packet; it may choose not to forward them, but it MUST NOT change 545 their contents. If the forwarding proxy omits the Proxy-State 546 attributes in the request, it MUST attach them to the response before 547 sending it. 549 When the proxy forwards a Disconnect or CoA-Request, it MAY add a 550 Proxy-State Attribute, but it MUST NOT add more than one. If a 551 Proxy-State Attribute is added to a packet when forwarding the 552 packet, the Proxy-State Attribute MUST be added after any existing 553 Proxy-State attributes. The forwarding proxy MUST NOT change the 554 order of any attributes of the same type, including Proxy-State. 555 Other attributes can be placed before, after or even between the 556 Proxy-State attributes. 558 When the proxy receives a response to a CoA-Request or Disconnect- 559 Request, it MUST remove its own Proxy-State (the last Proxy- State in 560 the packet) Attribute before forwarding the response. Since 561 Disconnect and CoA responses are authenticated on the entire packet 562 contents, the stripping of the Proxy-State Attribute invalidates the 563 integrity check - so the proxy needs to recompute it. 565 3.2. Authorize Only 567 Support for a CoA-Request including a Service-Type Attribute with 568 value "Authorize Only" is OPTIONAL on the NAS and Dynamic 569 Authorization Client. A Service-Type Attribute MUST NOT be included 570 within a Disconnect-Request. 572 A NAS MUST respond to a CoA-Request including a Service-Type 573 Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST 574 NOT be sent. If the NAS does not support a Service-Type value of 575 "Authorize Only" then it MUST respond with a CoA-NAK; an Error-Cause 576 value of 405 (Unsupported Service) SHOULD be included. 578 A CoA-Request containing a Service-Type Attribute with value 579 "Authorize Only" MUST in addition contain only NAS or session 580 identification attributes, as well as a State Attribute. If other 581 attributes are included in such a CoA-Request, a CoA-NAK MUST be 582 sent; an Error-Cause Attribute with value 401 (Unsupported Attribute) 583 SHOULD be included. 585 If a CoA-Request packet including a Service-Type value of "Authorize 586 Only" is successfully processed, the NAS MUST respond with a CoA-NAK 587 containing a Service-Type Attribute with value "Authorize Only", and 588 an Error-Cause Attribute with value 507 (Request Initiated). The NAS 589 then MUST send an Access-Request to the RADIUS server including a 590 Service-Type Attribute with value "Authorize Only", along with a 591 State Attribute. This Access-Request SHOULD contain the NAS 592 identification attributes from the CoA-Request, as well as the 593 session identification attributes from the CoA-Request permitted in 594 an Access-Request; it also MAY contain other attributes permitted in 595 an Access-Request. 597 As noted in [RFC2869] Section 5.19, a Message-Authenticator attribute 598 SHOULD be included in an Access-Request that does not contain a User- 599 Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. The 600 RADIUS server then will respond to the Access-Request with an Access- 601 Accept to (re-)authorize the session or an Access-Reject to refuse to 602 (re-)authorize it. 604 3.3. State 606 The State Attribute is available to be sent by the Dynamic 607 Authorization Client to the NAS in a CoA-Request packet and MUST be 608 sent unmodified from the NAS to the Dynamic Authorization Client in a 609 subsequent ACK or NAK packet. 611 [RFC2865] Section 5.44 states: 613 An Access-Request MUST contain either a User-Password or a CHAP- 614 Password or State. An Access-Request MUST NOT contain both a 615 User-Password and a CHAP-Password. If future extensions allow 616 other kinds of authentication information to be conveyed, the 617 attribute for that can be used in an Access-Request instead of 618 User-Password or CHAP-Password. 620 In order to satisfy the requirements of [RFC2865] Section 5.44, an 621 Access-Request with Service-Type="Authorize-Only" MUST contain a 622 State attribute. 624 In order to provide a State attribute to the NAS, a Dynamic 625 Authorization Client sending a CoA-Request with a Service-Type value 626 of "Authorize-Only" MUST include a State Attribute, and the NAS MUST 627 send the State Attribute unmodified to the RADIUS server in the 628 resulting Access-Request, if any. A NAS receiving a CoA-Request 629 containing a Service-Type value of "Authorize-Only" but lacking a 630 State attribute MUST send a CoA-NAK and SHOULD include an Error-Cause 631 attribute with value 402 (Missing Attribute). 633 The State Attribute is also available to be sent by the Dynamic 634 Authorization Client to the NAS in a CoA-Request that also includes a 635 Termination-Action Attribute with the value of RADIUS-Request. If 636 the NAS performs the Termination-Action by sending a new Access- 637 Request upon termination of the current session, it MUST include the 638 State Attribute unchanged in that Access-Request. In either usage, 639 the Dynamic Authorization Server MUST NOT interpret the Attribute 640 locally. A CoA-Request packet MUST have only zero or one State 641 Attribute. Usage of the State Attribute is implementation dependent. 643 3.4. Message-Authenticator 645 The Message-Authenticator Attribute MAY be used to authenticate and 646 integrity-protect CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request, 647 Disconnect-ACK and Disconnect-NAK packets order to prevent spoofing. 649 A Dynamic Authorization Server receiving a CoA-Request or Disconnect- 650 Request with a Message-Authenticator Attribute present MUST calculate 651 the correct value of the Message-Authenticator and silently discard 652 the packet if it does not match the value sent. A Dynamic 653 Authorization Client receiving a CoA/Disconnect-ACK or 654 CoA/Disconnect-NAK with a Message-Authenticator Attribute present 655 MUST calculate the correct value of the Message-Authenticator and 656 silently discard the packet if it does not match the value sent. 658 When a Message-Authenticator Attribute is included within a CoA- 659 Request or Disconnect-Request, it is calculated as follows: 661 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, 662 Request Authenticator, Attributes) 664 When the HMAC-MD5 message integrity check is calculated the 665 Request Authenticator field and Message-Authenticator Attribute 666 should be considered to be sixteen octets of zero. The Message- 667 Authenticator Attribute is calculated and inserted in the packet 668 before the Request Authenticator is calculated. 670 When a Message-Authenticator Attribute is included within a CoA- 671 ACK, CoA-NAK, Disconnect-ACK or Disconnect-NAK, it is calculated 672 as follows: 674 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, 675 Request Authenticator, Attributes) 677 When the HMAC-MD5 message integrity check is calculated the 678 Message-Authenticator Attribute should be considered to be sixteen 679 octets of zero. The Request Authenticator is taken from the 680 corresponding CoA/Disconnect-Request. The Message-Authenticator 681 is calculated and inserted in the packet before the Response 682 Authenticator is calculated. 684 3.5. Error-Cause 686 Description 688 It is possible that a Dynamic Authorization Server cannot honor 689 Disconnect-Request or CoA-Request packets for some reason. The 690 Error-Cause Attribute provides more detail on the cause of the 691 problem. It MAY be included within CoA-NAK and Disconnect-NAK 692 packets. 694 A summary of the Error-Cause Attribute format is shown below. The 695 fields are transmitted from left to right. 697 0 1 2 3 698 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 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Type | Length | Value 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 Value (cont) | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Type 707 101 for Error-Cause 709 Length 711 6 713 Value 715 The Value field is four octets, containing an integer specifying 716 the cause of the error. Values 0-199 and 300-399 are reserved. 717 Values 200-299 represent successful completion, so that these 718 values may only be sent within CoA-ACK or Disconnect-ACK packets 719 and MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet. 720 Values 400-499 represent fatal errors committed by the Dynamic 721 Authorization Client, so that they MAY be sent within CoA-NAK or 722 Disconnect-NAK packets, and MUST NOT be sent within CoA-ACK or 723 Disconnect-ACK packets. Values 500-599 represent fatal errors 724 occurring on a Dynamic Authorization Server, so that they MAY be 725 sent within CoA-NAK and Disconnect-NAK packets, and MUST NOT be 726 sent within CoA-ACK or Disconnect-ACK packets. Error-Cause values 727 SHOULD be logged by the Dynamic Authorization Client. Error-Code 728 values (expressed in decimal) include: 730 # Value 731 --- ----- 732 201 Residual Session Context Removed 733 202 Invalid EAP Packet (Ignored) 734 401 Unsupported Attribute 735 402 Missing Attribute 736 403 NAS Identification Mismatch 737 404 Invalid Request 738 405 Unsupported Service 739 406 Unsupported Extension 740 407 Invalid Attribute Value 741 501 Administratively Prohibited 742 502 Request Not Routable (Proxy) 743 503 Session Context Not Found 744 504 Session Context Not Removable 745 505 Other Proxy Processing Error 746 506 Resources Unavailable 747 507 Request Initiated 748 508 Multiple Session Selection Unsupported 750 "Residual Session Context Removed" is sent in response to a 751 Disconnect-Request if one or more user session(s) are no longer 752 active, but residual session context was found and successfully 753 removed. This value is only sent within a Disconnect-ACK and MUST 754 NOT be sent within a CoA-ACK, Disconnect-NAK or CoA-NAK. 756 "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT 757 be sent by implementations of this specification. 759 "Unsupported Attribute" is a fatal error sent if a Request 760 contains an attribute (such as a Vendor-Specific or EAP-Message 761 Attribute) that is not supported. 763 "Missing Attribute" is a fatal error sent if critical attributes 764 (such as NAS or session identification attributes) are missing 765 from a Request. 767 "NAS Identification Mismatch" is a fatal error sent if one or more 768 NAS identification attributes (see Section 3) do not match the 769 identity of the NAS receiving the Request. 771 "Invalid Request" is a fatal error sent if some other aspect of 772 the Request is invalid, such as if one or more attributes (such as 773 EAP- Message Attribute(s)) are not formatted properly. 775 "Unsupported Service" is a fatal error sent if a Service-Type 776 Attribute included with the Request is sent with an invalid or 777 unsupported value. This error cannot be sent in response to a 778 Disconnect-Request. 780 "Unsupported Extension" is a fatal error sent due to lack of 781 support for an extension such as Disconnect and/or CoA packets. 782 This will typically be sent by a proxy receiving an ICMP port 783 unreachable message after attempting to forward a CoA-Request or 784 Disconnect-Request to the NAS. 786 "Invalid Attribute Value" is a fatal error sent if a CoA-Request 787 or Disconnect-Request contains an attribute with an unsupported 788 value. 790 "Administratively Prohibited" is a fatal error sent if the NAS is 791 configured to prohibit honoring of CoA-Request or Disconnect- 792 Request packets for the specified session. 794 "Request Not Routable" is a fatal error which MAY be sent by a 795 proxy and MUST NOT be sent by a NAS. It indicates that the proxy 796 was unable to determine how to route a CoA-Request or Disconnect- 797 Request to the NAS. For example, this can occur if the required 798 entries are not present in the proxy's realm routing table. 800 "Session Context Not Found" is a fatal error sent if the session 801 context identified in the CoA-Request or Disconnect-Request does 802 not exist on the NAS. 804 "Session Context Not Removable" is a fatal error sent in response 805 to a Disconnect-Request if the NAS was able to locate the session 806 context, but could not remove it for some reason. It MUST NOT be 807 sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a 808 Disconnect-NAK. 810 "Other Proxy Processing Error" is a fatal error sent in response 811 to a CoA or Disconnect-Request that could not be processed by a 812 proxy, for reasons other than routing. 814 "Resources Unavailable" is a fatal error sent when a CoA or 815 Disconnect-Request could not be honored due to lack of available 816 NAS resources (memory, non- volatile storage, etc.). 818 "Request Initiated" is a fatal error sent by a NAS in response to 819 a CoA-Request including a Service-Type Attribute with a value of 820 "Authorize Only". It indicates that the CoA-Request has not been 821 honored, but that the NAS is sending one or more RADIUS Access- 822 Request(s) including a Service-Type Attribute with value 823 "Authorize Only" to the RADIUS server. 825 "Multiple Session Selection Unsupported" is a fatal error sent by 826 a NAS in response to a CoA-Request or Disconnect-Request whose 827 session identification attributes match multiple sessions, where 828 the NAS does not support Requests applying to multiple sessions. 830 3.6. Table of Attributes 832 The following table provides a guide to which attributes may be found 833 in which packets, and in what quantity. 835 Change-of-Authorization Messages 837 Request ACK NAK # Attribute 838 0-1 0 0 1 User-Name [Note 1] 839 0-1 0 0 4 NAS-IP-Address [Note 1] 840 0-1 0 0 5 NAS-Port [Note 1] 841 0-1 0 0-1 6 Service-Type 842 0-1 0 0 7 Framed-Protocol [Note 3] 843 0-1 0 0 8 Framed-IP-Address [Notes 1,6] 844 0-1 0 0 9 Framed-IP-Netmask [Note 3] 845 0-1 0 0 10 Framed-Routing [Note 3] 846 0+ 0 0 11 Filter-ID [Note 3] 847 0-1 0 0 12 Framed-MTU [Note 3] 848 Request ACK NAK # Attribute 849 Request ACK NAK # Attribute 850 0+ 0 0 13 Framed-Compression [Note 3] 851 0+ 0 0 14 Login-IP-Host [Note 3] 852 0-1 0 0 15 Login-Service [Note 3] 853 0-1 0 0 16 Login-TCP-Port [Note 3] 854 0+ 0 0 18 Reply-Message [Note 2] 855 0-1 0 0 19 Callback-Number [Note 3] 856 0-1 0 0 20 Callback-Id [Note 3] 857 0+ 0 0 22 Framed-Route [Note 3] 858 0-1 0 0 23 Framed-IPX-Network [Note 3] 859 0-1 0-1 0-1 24 State 860 0+ 0 0 25 Class [Note 3] 861 0+ 0 0 26 Vendor-Specific [Note 7] 862 0-1 0 0 27 Session-Timeout [Note 3] 863 0-1 0 0 28 Idle-Timeout [Note 3] 864 0-1 0 0 29 Termination-Action [Note 3] 865 0-1 0 0 30 Called-Station-Id [Note 1] 866 0-1 0 0 31 Calling-Station-Id [Note 1] 867 0-1 0 0 32 NAS-Identifier [Note 1] 868 0+ 0+ 0+ 33 Proxy-State 869 0-1 0 0 34 Login-LAT-Service [Note 3] 870 0-1 0 0 35 Login-LAT-Node [Note 3] 871 0-1 0 0 36 Login-LAT-Group [Note 3] 872 0-1 0 0 37 Framed-AppleTalk-Link [Note 3] 873 0+ 0 0 38 Framed-AppleTalk-Network [Note 3] 874 0-1 0 0 39 Framed-AppleTalk-Zone [Note 3] 875 0-1 0 0 44 Acct-Session-Id [Note 1] 876 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] 877 0-1 0-1 0-1 55 Event-Timestamp 878 0+ 0 0 56 Egress-VLANID [Note 3] 879 0-1 0 0 57 Ingress-Filters [Note 3] 880 0+ 0 0 58 Egress-VLAN-Name [Note 3] 881 0-1 0 0 59 User-Priority-Table [Note 3] 882 0-1 0 0 61 NAS-Port-Type [Note 3] 883 0-1 0 0 62 Port-Limit [Note 3] 884 0-1 0 0 63 Login-LAT-Port [Note 3] 885 0+ 0 0 64 Tunnel-Type [Note 5] 886 0+ 0 0 65 Tunnel-Medium-Type [Note 5] 887 0+ 0 0 66 Tunnel-Client-Endpoint [Note 5] 888 0+ 0 0 67 Tunnel-Server-Endpoint [Note 5] 889 0+ 0 0 69 Tunnel-Password [Note 5] 890 0-1 0 0 71 ARAP-Features [Note 3] 891 0-1 0 0 72 ARAP-Zone-Access [Note 3] 892 0+ 0 0 78 Configuration-Token [Note 3] 893 Request ACK NAK # Attribute 894 Request ACK NAK # Attribute 895 0+ 0-1 0 79 EAP-Message [Note 2] 896 0-1 0-1 0-1 80 Message-Authenticator 897 0+ 0 0 81 Tunnel-Private-Group-ID [Note 5] 898 0+ 0 0 82 Tunnel-Assignment-ID [Note 5] 899 0+ 0 0 83 Tunnel-Preference [Note 5] 900 0-1 0 0 85 Acct-Interim-Interval [Note 3] 901 0-1 0 0 87 NAS-Port-Id [Note 1] 902 0-1 0 0 88 Framed-Pool [Note 3] 903 0-1 0 0 89 Chargeable-User-Identity [Note 1] 904 0+ 0 0 90 Tunnel-Client-Auth-ID [Note 5] 905 0+ 0 0 91 Tunnel-Server-Auth-ID [Note 5] 906 0-1 0 0 92 NAS-Filter-Rule [Note 3] 907 0 0 0 94 Originating-Line-Info 908 0-1 0 0 95 NAS-IPv6-Address [Note 1] 909 0-1 0 0 96 Framed-Interface-Id [Notes 1,6] 910 0+ 0 0 97 Framed-IPv6-Prefix [Notes 1,6] 911 0+ 0 0 98 Login-IPv6-Host [Note 3] 912 0+ 0 0 99 Framed-IPv6-Route [Note 3] 913 0-1 0 0 100 Framed-IPv6-Pool [Note 3] 914 0 0 0+ 101 Error-Cause 915 0+ 0 0 123 Delegated-IPv6-Prefix [Note 3] 916 Request ACK NAK # Attribute 918 Disconnect Messages 920 Request ACK NAK # Attribute 921 0-1 0 0 1 User-Name [Note 1] 922 0-1 0 0 4 NAS-IP-Address [Note 1] 923 0-1 0 0 5 NAS-Port [Note 1] 924 0 0 0 6 Service-Type 925 0 0 0 8 Framed-IP-Address [Note 1] 926 0+ 0 0 18 Reply-Message [Note 2] 927 0 0 0 24 State 928 0+ 0 0 25 Class [Note 4] 929 0+ 0 0 26 Vendor-Specific [Note 1] 930 0-1 0 0 30 Called-Station-Id [Note 1] 931 0-1 0 0 31 Calling-Station-Id [Note 1] 932 0-1 0 0 32 NAS-Identifier [Note 1] 933 0+ 0+ 0+ 33 Proxy-State 934 0-1 0 0 44 Acct-Session-Id [Note 1] 935 0-1 0-1 0 49 Acct-Terminate-Cause 936 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] 937 0-1 0-1 0-1 55 Event-Timestamp 938 0 0 0 61 NAS-Port-Type 939 0+ 0-1 0 79 EAP-Message [Note 2] 940 Request ACK NAK # Attribute 941 Request ACK NAK # Attribute 942 0-1 0-1 0-1 80 Message-Authenticator 943 0-1 0 0 87 NAS-Port-Id [Note 1] 944 0-1 0 0 89 Chargeable-User-Identity [Note 1] 945 0-1 0 0 95 NAS-IPv6-Address [Note 1] 946 0 0 0 96 Framed-Interface-Id [Note 1] 947 0 0 0 97 Framed-IPv6-Prefix [Note 1] 948 0 0 0+ 101 Error-Cause 949 Request ACK NAK # Attribute 951 The following table defines the meaning of the above table entries. 953 0 This attribute MUST NOT be present in packet. 954 0+ Zero or more instances of this attribute MAY be present in packet. 955 0-1 Zero or one instance of this attribute MAY be present in packet. 956 1 Exactly one instance of this attribute MUST be present in packet. 958 [Note 1] Where NAS or session identification attributes are included 959 in Disconnect-Request or CoA-Request packets, they are used for 960 identification purposes only. These attributes MUST NOT be used for 961 purposes other than identification (e.g. within CoA-Request packets 962 to request authorization changes). 964 [Note 2] The Reply-Message Attribute is used to present a displayable 965 message to the user. The message is only displayed as a result of a 966 successful Disconnect-Request or CoA-Request (where a Disconnect-ACK 967 or CoA-ACK is subsequently sent). Where EAP is used for 968 authentication, an EAP-Message/Notification-Request Attribute is sent 969 instead, and Disconnect-ACK or CoA-ACK packets contain an EAP- 970 Message/Notification-Response Attribute. 972 [Note 3] When included within a CoA-Request, these attributes 973 represent an authorization change request. When one of these 974 attributes is omitted from a CoA-Request, the NAS assumes that the 975 attribute value is to remain unchanged. Attributes included in a 976 CoA-Request replace all existing value(s) of the same attribute(s). 978 [Note 4] When included within a successful Disconnect-Request (where 979 a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be 980 sent unmodified by the NAS to the RADIUS accounting server in the 981 Accounting Stop packet. If the Disconnect-Request is unsuccessful, 982 then the Class Attribute is not processed. 984 [Note 5] When included within a CoA-Request, these attributes 985 represent an authorization change request. Where tunnel attribute(s) 986 are included within a successful CoA-Request, all existing tunnel 987 attributes are removed and replaced by the new attribute(s). 989 [Note 6] Since the Framed-IP-Address, Framed-IPv6-Prefix and Framed- 990 Interface-Id attributes are used for session identification, 991 renumbering cannot be accomplished by including values of these 992 attributes within a CoA-Request. Instead, a CoA-Request including a 993 Service-Type Attribute with a value of "Authorize Only" is sent; new 994 values can be supplied in an Access-Accept sent in response to the 995 ensuing Access-Request. Note that renumbering will not be possible 996 in all situations. For example, in order to change an IP address, 997 IPCP or IPv6CP re-negotiation could be required, which is not 998 supported by all PPP implementations. 1000 [Note 7] Within CoA-Request packets, Vendor-Specific Attributes 1001 (VSAs) MAY be used for either session identification or authorization 1002 change. However, the same Attribute MUST NOT be used for both 1003 purposes simultaneously. 1005 4. Diameter Considerations 1007 Due to differences in handling change-of-authorization requests in 1008 RADIUS and Diameter, it may be difficult or impossible for a 1009 Diameter/RADIUS gateway to successfully translate a Diameter Re-Auth- 1010 Request (RAR) to a CoA-Request and vice versa. For example, since a 1011 CoA-Request only initiates an authorization change but does not 1012 initiate re-authentication, a RAR command containing a Re-Auth- 1013 Request-Type AVP with value "AUTHORIZE_AUTHENTICATE" cannot be 1014 directly translated to a CoA-Request. A Diameter/RADIUS gateway 1015 receiving a CoA-Request containing authorization changes will need to 1016 translate this into two Diameter exchanges. First, the 1017 Diameter/RADIUS gateway will issue a RAR command including a Session- 1018 Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". 1019 Then the Diameter/RADIUS gateway will respond to the ensuing access 1020 request with a response including the authorization attributes 1021 gleaned from the CoA-Request. To enable translation, the CoA-Request 1022 SHOULD include a Acct-Session-Id Attribute. If the Diameter client 1023 uses the same Session-Id for both authorization and accounting, then 1024 the Diameter/RADIUS gateway can copy the contents of the Acct- 1025 Session-Id Attribute into the Session-Id AVP; otherwise, it will 1026 need to map the Acct-Session-Id value to an equivalent Session-Id for 1027 use within a RAR command. 1029 Where an Acct-Session-Id attribute is not present in a CoA-Request or 1030 Disconnect-Request, a Diameter/RADIUS gateway will either need to 1031 determine the appropriate Acct-Session-Id, or if it cannot do so, it 1032 can send a CoA-NAK or Disconnect-NAK in reply, possibly including an 1033 Error-Cause Attribute with value 508 (Multiple Session Identification 1034 Unsupported). 1036 To simplify translation between RADIUS and Diameter, Dynamic 1037 Authorization Clients can include a Service-Type Attribute with value 1038 "Authorize Only" within a CoA-Request, as described in Section 3.2. 1039 A Diameter/RADIUS gateway receiving a CoA-Request containing a 1040 Service-Type with value "Authorize Only" translates this to a RAR 1041 with Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". The 1042 received RAA is then translated to a CoA-NAK with a Service-Type 1043 value of "Authorize Only". If the Result-Code AVP in the RAA has a 1044 value in the success category, then an Error-Cause Attribute with 1045 value "Request Initiated" is included in the CoA-NAK. If the 1046 Result-Code AVP in the RAA has a value indicating a Protocol Error or 1047 a Transient or Permanent Failure, then an alternate Error-Cause 1048 Attribute is returned as suggested below. 1050 Within Diameter, a server can request that a session be aborted by 1051 sending an Abort-Session-Request (ASR), identifying the session to be 1052 terminated using Session-ID and User-Name AVPs. The ASR command is 1053 translated to a Disconnect-Request containing Acct-Session-Id and 1054 User-Name attributes. If the Diameter client utilizes the same 1055 Session-Id in both authorization and accounting, then the value of 1056 the Session-ID AVP may be placed in the Acct-Session-Id attribute; 1057 otherwise the value of the Session-ID AVP will need to be mapped to 1058 an appropriate Acct-Session-Id value. To enable translation of a 1059 Disconnect-Request to an ASR, an Acct-Session-Id attribute SHOULD be 1060 present. 1062 If the Diameter client utilizes the same Session-Id in both 1063 authorization and accounting, then the value of the Acct-Session-Id 1064 may be placed into the Session-ID AVP within the ASR; otherwise the 1065 value of the Acct-Session-Id will need to be mapped to an appropriate 1066 Session-ID value. 1068 An Abort-Session-Answer (ASA) command is sent in response to an ASR 1069 in order to indicate the disposition of the request. A 1070 Diameter/RADIUS gateway receiving a Disconnect-ACK translates this to 1071 an ASA command with a Result-Code AVP of "DIAMETER_SUCCESS". A 1072 Disconnect-NAK received from the NAS is translated to an ASA command 1073 with a Result-Code AVP which depends on the value of the Error-Cause 1074 Attribute. Suggested translations between Error-Cause Attribute 1075 values and Result-Code AVP values are included below: 1077 # Error-Cause Attribute Value Result-Code AVP 1078 --- --------------------------- ------------------------ 1079 201 Residual Session Context DIAMETER_SUCCESS 1080 Removed 1081 202 Invalid EAP Packet DIAMETER_LIMITED_SUCCESS 1082 (Ignored) 1083 401 Unsupported Attribute DIAMETER_AVP_UNSUPPORTED 1084 402 Missing Attribute DIAMETER_MISSING_AVP 1085 403 NAS Identification DIAMETER_REALM_NOT_SERVED 1086 Mismatch 1087 404 Invalid Request DIAMETER_UNABLE_TO_COMPLY 1088 405 Unsupported Service DIAMETER_COMMAND_UNSUPPORTED 1089 406 Unsupported Extension DIAMETER_APPLICATION_UNSUPPORTED 1090 407 Invalid Attribute Value DIAMETER_INVALID_AVP_VALUE 1091 501 Administratively DIAMETER_AUTHORIZATION_REJECTED 1092 Prohibited 1093 502 Request Not Routable (Proxy) DIAMETER_UNABLE_TO_DELIVER 1094 503 Session Context Not Found DIAMETER_UNKNOWN_SESSION_ID 1095 504 Session Context Not DIAMETER_AUTHORIZATION_REJECTED 1096 Removable 1097 505 Other Proxy Processing DIAMETER_UNABLE_TO_COMPLY 1098 Error 1099 506 Resources Unavailable DIAMETER_RESOURCES_EXCEEDED 1100 507 Request Initiated DIAMETER_SUCCESS 1102 Since both the ASR/ASA and Disconnect-Request/Disconnect- 1103 NAK/Disconnect-ACK exchanges involve just a request and response, 1104 inclusion of an "Authorize Only" Service-Type within a Disconnect- 1105 Request is not needed to assist in Diameter/RADIUS translation, and 1106 may make translation more difficult. As a result, as noted in 1107 Section 3.2, the Service-Type Attribute MUST NOT be used within a 1108 Disconnect-Request. 1110 5. IANA Considerations 1112 This document uses the RADIUS [RFC2865] namespace, see 1113 . In addition to the 1114 allocations already made in [RFC3575] and [RFC3576], this 1115 specification requests allocation of additional values of the Error- 1116 Cause Attribute (101): 1118 # Value 1119 --- ----- 1120 407 Invalid Attribute Value 1121 508 Multiple Session Selection Unsupported 1123 6. Security Considerations 1125 6.1. Authorization Issues 1127 Where a NAS is shared by multiple providers, it is undesirable for 1128 one provider to be able to send Disconnect-Request or CoA-Requests 1129 affecting the sessions of another provider. 1131 A Dynamic Authorization Server MUST silently discard Disconnect- 1132 Request or CoA-Request packets from untrusted sources. In situations 1133 where the Dynamic Authorization Client is co-resident with a RADIUS 1134 authentication or accounting server, a proxy MAY perform a "reverse 1135 path forwarding" (RPF) check to verify that a Disconnect-Request or 1136 CoA-Request originates from an authorized Dynamic Authorization 1137 Client. In addition, it SHOULD be possible to explicitly authorize 1138 additional sources of Disconnect-Request or CoA-Request packets 1139 relating to certain classes of sessions. For example, a particular 1140 source can be explicitly authorized to send CoA-Request packets 1141 relating to users within a set of realms. 1143 To perform the RPF check, the Dynamic Authorization Server uses the 1144 session identification attributes included in Disconnect-Request or 1145 CoA-Request packets, in order to determine the RADIUS server(s) to 1146 which an equivalent Access-Request could be routed. If the source 1147 address of the Disconnect-Request or CoA-Request is within this set, 1148 then the CoA-Request or Disconnect-Request is forwarded; otherwise it 1149 MUST be silently discarded. 1151 Typically the Dynamic Authorization Server will extract the realm 1152 from the Network Access Identifier [RFC4282] included within the 1153 User-Name or Chargeable-User-Identity Attribute, and determine the 1154 corresponding RADIUS servers in the realm routing tables. If the 1155 Dynamic Authorization Server maintains long-term session state, it 1156 MAY perform the authorization check based on the session 1157 identification attributes in the CoA-Request. The session 1158 identification attributes can be used to tie a session to a 1159 particular proxy or set of proxies, as with the NAI realm. 1161 Where no proxy is present, the RPF check can only be performed by the 1162 NAS if it maintains its own a realm routing table. If the NAS does 1163 not maintain a realm routing table (e.g. it selects forwarding 1164 proxies based on primary/secondary configuration and/or liveness 1165 checks), then an RPF check cannot be performed. 1167 Since authorization to send a Disconnect-Request or CoA-Request is 1168 determined based on the source address and the corresponding shared 1169 secret, the Dynamic Authorization Server SHOULD configure a different 1170 shared secret for each Dynamic Authorization Client. 1172 6.2. Impersonation 1174 [RFC2865] Section 3 states: 1176 A RADIUS server MUST use the source IP address of the RADIUS 1177 UDP packet to decide which shared secret to use, so that 1178 RADIUS requests can be proxied. 1180 When RADIUS Access-Requests are forwarded by a proxy, the NAS-IP- 1181 Address or NAS-IPv6-Address Attributes will typically not match the 1182 source address observed by the RADIUS server. Since the NAS- 1183 Identifier Attribute need not contain an FQDN, this Attribute may not 1184 be resolvable to the source address observed by the RADIUS server, 1185 even when no proxy is present. 1187 As a result, the authenticity check performed by a RADIUS server or 1188 proxy does not verify the correctness of NAS identification 1189 attributes. This makes it possible for a rogue NAS to forge NAS-IP- 1190 Address, NAS-IPv6-Address or NAS-Identifier Attributes within a 1191 RADIUS Access-Request in order to impersonate another NAS. It is 1192 also possible for a rogue NAS to forge attributes such as the Called- 1193 Station-Id, Calling-Station-Id, or Originating-Line-Info [RFC4005]. 1194 This could fool the Dynamic Authorization Client into sending CoA- 1195 Request or Disconnect-Request packets containing forged session 1196 identification attributes to a NAS targeted by an attacker. 1198 To address these vulnerabilities RADIUS proxies one hop from the NAS 1199 SHOULD check whether NAS identification attributes (see Section 3) 1200 match the packet source address. Where one or more attributes do not 1201 match, Access-Request packets SHOULD be silently discarded. 1203 Such a check may not always be possible. Since the NAS-Identifier 1204 Attribute need not correspond to an FQDN, it may not be resolvable to 1205 an IP address to be matched against the source address. Also, where 1206 a NAT exists between the RADIUS client and proxy, checking the NAS- 1207 IP-Address or NAS-IPv6-Address Attributes may not be feasible. 1209 6.3. IPsec Usage Guidelines 1211 In addition to security vulnerabilities unique to Disconnect or CoA 1212 packets, the protocol exchanges described in this document are 1213 susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is 1214 RECOMMENDED that IPsec be employed to afford better security. 1216 Implementations of this specification SHOULD support IPsec [RFC4301] 1217 along with IKEv1 [RFC2409] for key management. IPsec ESP [RFC4303] 1218 with non-null transform SHOULD be supported, and IPsec ESP with a 1219 non-null encryption transform and authentication support SHOULD be 1220 used to provide per-packet confidentiality, authentication, integrity 1221 and replay protection. IKE SHOULD be used for key management. 1223 Within RADIUS [RFC2865], a shared secret is used for hiding of 1224 Attributes such as User-Password, as well as in computation of the 1225 Response Authenticator. In RADIUS accounting [RFC2866], the shared 1226 secret is used in computation of both the Request Authenticator and 1227 the Response Authenticator. 1229 Since in RADIUS a shared secret is used to provide confidentiality as 1230 well as integrity protection and authentication, only use of IPsec 1231 ESP with a non-null transform can provide security services 1232 sufficient to substitute for RADIUS application-layer security. 1233 Therefore, where IPsec AH or ESP null is used, it will typically 1234 still be necessary to configure a RADIUS shared secret. 1236 Where RADIUS is run over IPsec ESP with a non-null transform, the 1237 secret shared between the Dynamic Authorization Server and the 1238 Dynamic Authorization Client MAY NOT be configured. In this case, a 1239 shared secret of zero length MUST be assumed. However, a Dynamic 1240 Authorization Client that cannot know whether incoming traffic is 1241 IPsec-protected MUST be configured with a non-null RADIUS shared 1242 secret. 1244 When IPsec ESP is used with RADIUS, per-packet authentication, 1245 integrity and replay protection MUST be used. 3DES-CBC MUST be 1246 supported as an encryption transform and AES-CBC SHOULD be supported. 1247 AES-CBC SHOULD be offered as a preferred encryption transform if 1248 supported. HMAC-SHA1-96 MUST be supported as an authentication 1249 transform. DES-CBC SHOULD NOT be used as the encryption transform. 1251 A typical IPsec policy for an IPsec-capable RADIUS client is 1252 "Initiate IPsec, from me to any destination port UDP 1812". This 1253 IPsec policy causes an IPsec SA to be set up by the RADIUS client 1254 prior to sending a RADIUS Access-Request to a RADIUS server. If some 1255 RADIUS servers contacted by the RADIUS client do not support IPsec, 1256 then a more granular policy will be required: "Initiate IPsec, from 1257 me to IPsec-Capable-RADIUS-Server, destination port UDP 1812." 1259 For a Dynamic Authorization Server implementing this specification 1260 the policy would be "Accept IPsec, from any to me, destination port 1261 UDP 3799". This causes the Dynamic Authorization Server to accept 1262 (but not require) use of IPsec. It may not be appropriate to require 1263 IPsec for all Dynamic Authorization Clients connecting to an IPsec- 1264 enabled Dynamic Authorization Server, since some Dynamic 1265 Authorization Clients may not support IPsec. 1267 For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept 1268 IPsec, from any to me, destination port 1812". This causes the 1269 RADIUS server to accept (but not require) use of IPsec. It may not 1270 be appropriate to require IPsec for all RADIUS clients connecting to 1271 an IPsec-enabled RADIUS server, since some RADIUS clients may not 1272 support IPsec. 1274 For Dynamic Authorization Clients implementing this specification, 1275 the policy would be "Initiate IPsec, from me to any, destination port 1276 UDP 3799". This causes the Dynamic Authorization Client to initiate 1277 IPsec when sending Dynamic Authorization traffic to any Dynamic 1278 Authorization Server. If some Dynamic Authorization Servers 1279 contacted by the Dynamic Authorization Client do not support IPsec, 1280 then a more granular policy will be required, such as "Initiate 1281 IPsec, from me to IPsec-capable-Dynamic-Authorization-Server, 1282 destination port UDP 3799". 1284 Where IPsec is used for security, and no RADIUS shared secret is 1285 configured, it is important that the Dynamic Authorization Server and 1286 Dynamic Authorization Client perform an authorization check. Before 1287 enabling a host to act as a Dynamic Authorization Server, the Dynamic 1288 Authorization Client SHOULD check whether the host is authorized to 1289 act in that role. Similarly, before enabling a host to act as a 1290 Dynamic Authorization Client, the Dynamic Authorization Server SHOULD 1291 check whether the host is authorized for that role. 1293 Dynamic Authorization Clients can be configured with the IP addresses 1294 (for IKEv1 Aggressive Mode with pre-shared keys) or FQDNs (for 1295 certificate authentication) of Dynamic Authorization Servers. 1296 Alternatively, if a separate Certification Authority (CA) exists for 1297 Dynamic Authorization Servers, then the Dynamic Authorization Client 1298 can configure this CA as a trust anchor [RFC3280] for use with IKEv1. 1300 Similarly, Dynamic Authorization Servers can be configured with the 1301 IP addresses (for IKEv1 Aggressive Mode with pre-shared keys) or 1302 FQDNs (for certificate authentication) of Dynamic Authorization 1303 Clients. Alternatively, if a separate CA exists for Dynamic 1304 Authorization Clients, then the Dynamic Authorization Server can 1305 configure this CA as a trust anchor for use with IKEv1. 1307 Since unlike SSL/TLS, IKEv1 does not permit certificate policies to 1308 be set on a per-port basis, certificate policies need to apply to all 1309 uses of IKEv1 on Dynamic Authorization Servers and Dynamic 1310 Authorization Clients. In a deployment supporting only certificate 1311 authentication, a management station initiating an IPsec-protected 1312 telnet session to the Dynamic Authorization Client would need to 1313 obtain a certificate chaining to the Dynamic Authorization Server CA. 1314 Issuing such a certificate might not be appropriate if the management 1315 station was not authorized as a Dynamic Authorization Server. 1317 Where Dynamic Authorization Servers obtain their IP address 1318 dynamically (such as an Access Point supporting DHCP), IKEv1 Main 1319 Mode with pre-shared keys [RFC2409] SHOULD NOT be used, since this 1320 requires use of a group pre-shared key; instead, Aggressive Mode 1321 SHOULD be used. Where Dynamic Authorization Server addresses are 1322 statically assigned either IKEv1 Aggressive Mode or Main Mode MAY be 1323 used. With certificate authentication, IKEv1 Main Mode SHOULD be 1324 used. 1326 Care needs to be taken with IKEv1 Phase 1 Identity Payload selection 1327 in order to enable mapping of identities to pre-shared keys even with 1328 Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity 1329 Payloads are used and addresses are dynamically assigned, mapping of 1330 identities to keys is not possible, so that group pre-shared keys are 1331 still a practical necessity. As a result, the ID_FQDN identity 1332 payload SHOULD be employed in situations where Aggressive mode is 1333 utilized along with pre-shared keys and IP addresses are dynamically 1334 assigned. This approach also has other advantages, since it allows 1335 the Dynamic Authorization Client and Dynamic Authorization Server to 1336 configure themselves based on the fully qualified domain name of 1337 their peers. 1339 Note that with IPsec, security services are negotiated at the 1340 granularity of an IPsec SA, so that exchanges requiring a set of 1341 security services different from those negotiated with existing IPsec 1342 SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are 1343 also advisable where quality of service considerations dictate 1344 different handling RADIUS conversations. Attempting to apply 1345 different quality of service to connections handled by the same IPsec 1346 SA can result in reordering, and falling outside the replay window. 1347 For a discussion of the issues, see [RFC2983]. 1349 6.4. Replay Protection 1351 Where IPsec replay protection is not used, an Event-Timestamp (55) 1352 [RFC2869] Attribute SHOULD be included within CoA-Request and 1353 Disconnect-Request packets, and MAY be included within CoA-ACK, CoA- 1354 NAK, Disconnect-ACK and Disconnect-NAK packets. 1356 When the Event-Timestamp attribute is present, both the Dynamic 1357 Authorization Server and the Dynamic Authorization Client MUST check 1358 that the Event-Timestamp Attribute is current within an acceptable 1359 time window. If the Event-Timestamp Attribute is not current, then 1360 the packet MUST be silently discarded. This implies the need for 1361 loose time synchronization within the network, which can be achieved 1362 by a variety of means, including SNTP, as described in [RFC4330]. 1363 Implementations SHOULD be configurable to discard CoA-Request or 1364 Disconnect-Request packets not containing an Event-Timestamp 1365 attribute. 1367 If the Event-Timestamp Attribute is included, it represents the time 1368 at which the original packet was sent, and therefore it SHOULD NOT be 1369 updated when the packet is retransmitted. If the Event-Timestamp 1370 attribute is not updated, this implies that the Identifier is not 1371 changed in retransmitted packets. As a result, the ability to detect 1372 replay within the time window is dependent on support for duplicate 1373 detection within that same window. As noted in Section 2.3, 1374 duplicate detection is REQUIRED for Dynamic Authorization Servers 1375 implementing this specification. 1377 The time window used for duplicate detection MUST be the same as the 1378 window used to detect stale Event-Timestamp Attributes. Since the 1379 RADIUS Identifier cannot be repeated within the selected time window, 1380 no more than 256 Requests can be accepted within the time window. As 1381 a result, the chosen time window will depend on the expected maximum 1382 volume of CoA/Disconnect-Requests, so that unnecessary discards can 1383 be avoided. A default time window of 300 seconds should be adequate 1384 in many circumstances. 1386 7. Example Traces 1388 Disconnect Request with User-Name: 1390 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....# 1391 16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^.. 1392 32: 6d63 6869 6261 1394 Disconnect Request with Acct-Session-ID: 1396 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(..... 1397 16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,. 1398 32: 3930 3233 3435 3637 90234567 1400 Disconnect Request with Framed-IP-Address: 1402 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(..... 1403 16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ... 1404 32: 0a00 0203 1406 8. References 1408 8.1. Normative References 1410 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1411 April 1992. 1413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1414 Requirement Levels", RFC 2119, March 1997. 1416 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1417 RFC 2409, November 1998. 1419 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 1420 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1421 2000. 1423 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1425 [RFC2869] Rigney, C., Willats W. and P. Calhoun, "RADIUS Extensions", 1426 RFC 2869, June 2000. 1428 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 1429 3162, August 2001. 1431 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 1432 Public Key Infrastructure Certificate and Certificate 1433 Revocation List (CRL) Profile", RFC 3280, April 2002. 1435 [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July 1436 2003. 1438 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 1439 Authentication Protocol (EAP)", RFC 3579, September 2003. 1441 [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network 1442 Access Identifier", RFC 4282, December 2005. 1444 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet 1445 Protocol", RFC 4301, December 2005. 1447 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 1448 December 2005. 1450 8.2. Informative References 1452 [MD5Attack] 1453 Dobbertin, H., "The Status of MD5 After a Recent Attack", 1454 CryptoBytes Vol.2 No.2, Summer 1996. 1456 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. 1457 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1458 Support", RFC 2868, June 2000. 1460 [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, 1461 October 2000. 1463 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 1464 Accounting Transport Profile", RFC 3539, June 2003. 1466 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 1467 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1469 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 1470 "Dynamic Authorization Extensions to Remote Authentication 1471 Dial In User Service (RADIUS)", RFC 3576, July 2003. 1473 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 1474 Network Access Server Application", RFC 4005, August 2005. 1476 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for 1477 IPv4, IPv6 and OSI", RFC 4330, January 2006. 1479 [RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, 1480 "Chargeable User Identity", RFC 4372, January 2006. 1482 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for 1483 Virtual LAN and Priority Support", RFC 4675, September 2006. 1485 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1486 Attribute", RFC 4818, April 2007. 1488 [RFC4849] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Filter Rule 1489 Attribute", RFC 4849, April 2007. 1491 Acknowledgments 1493 This protocol was first developed and distributed by Ascend 1494 Communications. Example code was distributed in their free server 1495 kit. 1497 The authors would like to acknowledge valuable suggestions and 1498 feedback from Avi Lior, Randy Bush, Steve Bellovin, Glen Zorn, Mark 1499 Jones, Claudio Lapidus, Anurag Batta, Kuntal Chowdhury, Tim Moore, 1500 Russ Housley, Joe Salowey, Alan DeKok and David Nelson. 1502 Authors' Addresses 1504 Murtaza Chiba 1505 Cisco Systems, Inc. 1506 170 West Tasman Dr. 1507 San Jose CA, 95134 1509 EMail: mchiba@cisco.com 1510 Phone: +1 408 525 7198 1512 Gopal Dommety 1513 Cisco Systems, Inc. 1514 170 West Tasman Dr. 1515 San Jose, CA 95134 1517 EMail: gdommety@cisco.com 1518 Phone: +1 408 525 1404 1520 Mark Eklund 1521 Cisco Systems, Inc. 1522 170 West Tasman Dr. 1523 San Jose, CA 95134 1525 EMail: meklund@cisco.com 1526 Phone: +1 865 671 6255 1528 David Mitton 1529 RSA Security, Inc. 1530 174 Middlesex Turnpike 1531 Bedford, MA 01730 1533 EMail: dmitton@circularnetworks.com 1535 Bernard Aboba 1536 Microsoft Corporation 1537 One Microsoft Way 1538 Redmond, WA 98052 1540 EMail: bernarda@microsoft.com 1541 Phone: +1 425 706 6605 1542 Fax: +1 425 936 7329 1544 Appendix A - Changes from RFC 3576 1546 This Appendix lists the major changes between [RFC3576] and this 1547 document. Minor changes, including style, grammar, spelling, and 1548 editorial changes are not mentioned here. 1550 o The term "Dynamic Authorization Client" is used instead of RADIUS 1551 server where it applies to the originator of CoA and Disconnect- 1552 Request packets. The term "Dynamic Authorization Server" is used 1553 instead of NAS where it applies to the receiver of CoA and 1554 Disconnect-Request packets. Definitions of these terms have been 1555 added (Section 1.3). 1557 o Added requirement for duplicate detection on the Dynamic 1558 Authorization Server (Section 2.3). 1560 o Clarified expected behavior when session identification attributes 1561 match more than one session (Sections 2.3, 3, 3.5, 4). 1563 o Added Chargeable-User-Identity as a session identification 1564 attribute. Removed NAS-Port-Type as a session identification 1565 attribute (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). Use of the Service-Type 1576 Attribute within a Disconnect-Request is prohibited (Sections 3.2, 1577 3.6). 1579 o Added requirement for inclusion of the State Attribute in CoA- 1580 Request packets including a Service-Type Attribute with a value of 1581 "Authorize Only" (Section 3.3). 1583 o Added clarification on the calculation of the Message-Authenticator 1584 Attribute (Section 3.4). 1586 o Additional Error-Cause Attribute values are allocated for Invalid 1587 Attribute Value (407) and Multiple Session Identification Unsupported 1588 (508) (Sections 3.5, 4). 1590 o Updated the CoA-Request Attribute Table to include Filter-Rule, 1591 Delegated-IPv6-Prefix, Egress-VLANID, Ingress-Filters, Egress-VLAN- 1592 Name and User-Priority attributes (Section 3.6). 1594 o Added the Chargeable-User-Identity Attribute to both the CoA- 1595 Request and Disconnect-Request Attribute table (Section 3.6). 1597 o Use of Vendor-Specific Attributes (VSAs) for session identification 1598 and authorization change has been clarified (Section 3.6). 1600 o Added Note 6 on the use of the CoA-Request for renumbering (Section 1601 3.6). 1603 o Added Diameter Considerations (Section 4). 1605 o Event-Timestamp Attribute should not be recalculated on 1606 retransmission. The implications for replay and duplicate detection 1607 are discussed (Section 6.4). 1609 o Operation of the Reverse Path Forwarding (RPF) check has been 1610 clarified. Use of the RPF check is optional rather than recommended 1611 by default (Section 6.1). 1613 Full Copyright Statement 1615 Copyright (C) The IETF Trust (2007). 1617 This document is subject to the rights, licenses and restrictions 1618 contained in BCP 78, and except as set forth therein, the authors 1619 retain all their rights. 1621 This document and the information contained herein are provided on an 1622 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1623 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1624 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1625 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1626 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1627 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1629 Intellectual Property 1631 The IETF takes no position regarding the validity or scope of any 1632 Intellectual Property Rights or other rights that might be claimed to 1633 pertain to the implementation or use of the technology described in 1634 this document or the extent to which any license under such rights 1635 might or might not be available; nor does it represent that it has 1636 made any independent effort to identify any such rights. Information 1637 on the procedures with respect to rights in RFC documents can be 1638 found in BCP 78 and BCP 79. 1640 Copies of IPR disclosures made to the IETF Secretariat and any 1641 assurances of licenses to be made available, or the result of an 1642 attempt made to obtain a general license or permission for the use of 1643 such proprietary rights by implementers or users of this 1644 specification can be obtained from the IETF on-line IPR repository at 1645 http://www.ietf.org/ipr. 1647 The IETF invites any interested party to bring to its attention any 1648 copyrights, patents or patent applications, or other proprietary 1649 rights that may cover technology that may be required to implement 1650 this standard. Please address the information to the IETF at ietf- 1651 ipr@ietf.org. 1653 Acknowledgment 1655 Funding for the RFC Editor function is provided by the IETF 1656 Administrative Support Activity (IASA). 1658 Open issues 1660 Open issues relating to this specification are tracked on the 1661 following web site: 1663 http://www.drizzle.com/~aboba/RADEXT/