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