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