idnits 2.17.1 draft-chiba-radext-rfc3576bis-01.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 1582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1572. 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 are 9 instances of too long lines in the document, the longest one being 3 characters 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 == Line 528 has weird spacing: '...uded in a Dis...' == Line 671 has weird spacing: '... of the error...' == Line 1159 has weird spacing: '...t realm are t...' == Line 1305 has weird spacing: '...e might not b...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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: 'RFC2868' is mentioned on line 951, but not defined == Missing Reference: 'Note 1' is mentioned on line 892, but not defined == Missing Reference: 'Note 6' is mentioned on line 923, but not defined == Missing Reference: 'Note 3' is mentioned on line 906, but not defined == Missing Reference: 'Note 2' is mentioned on line 898, but not defined == Missing Reference: 'Note 7' is mentioned on line 958, but not defined == Missing Reference: 'Note 5' is mentioned on line 918, but not defined == Missing Reference: 'Note 8' is mentioned on line 978, but not defined == Missing Reference: 'Note 4' is mentioned on line 912, but not defined == Missing Reference: 'RFC768' is mentioned on line 1107, but not defined == Unused Reference: 'RFC1305' is defined on line 1381, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1388, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 1403, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** 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: 9 errors (**), 0 flaws (~~), 20 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 3 January 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 July 1, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). All Rights Reserved. 41 Abstract 43 This document describes a currently deployed extension to the Remote 44 Authentication Dial In User Service (RADIUS) protocol, allowing 45 dynamic changes to a user session, as implemented by network access 46 server products. This includes support for disconnecting users and 47 changing authorizations applicable to a user session. 49 Table of Contents 51 1. Introduction .......................................... 3 52 1.1 Applicability ................................... 3 53 1.2 Requirements Language ........................... 4 54 1.3 Terminology ..................................... 4 55 2. Overview ............................................. 5 56 2.1 Disconnect Messages (DM) ........................ 5 57 2.2 Change-of-Authorization Messages (CoA) .......... 5 58 2.3 Packet Format ................................... 6 59 3. Attributes ............................................ 10 60 3.1 State ........................................... 12 61 3.2 Message-Authenticator ........................... 13 62 3.3 Nonce ........................................... 14 63 3.4 Error-Cause ..................................... 14 64 3.5 Table of Attributes ............................. 17 65 4. Diameter Considerations ............................... 22 66 5. IANA Considerations ................................... 24 67 6. Security Considerations ............................... 25 68 6.1 Authorization Issues ............................ 25 69 6.2 Impersonation ................................... 25 70 6.3 IPsec Usage Guidelines .......................... 26 71 6.4 Replay Protection ............................... 29 72 7. Example Traces ........................................ 29 73 8. References ............................................ 30 74 8.1 Normative References ............................ 30 75 8.2 Informative References .......................... 31 76 ACKNOWLEDGMENTS .............................................. 32 77 AUTHORS' ADDRESSES ........................................... 33 78 Appendix A - Changes from RFC 3576 ........................... 34 79 Intellectual Property Statement .............................. 35 80 Disclaimer of Validity ....................................... 35 81 Copyright Statement .......................................... 35 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) messages. Disconnect messages cause a user session to be 101 terminated immediately, whereas CoA messages 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 a Nonce or Event-Timestamp 129 Attribute be added to all messages in situations where IPsec replay 130 protection 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 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 152 "REQUIRED", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be 153 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 messages. 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 NAS MUST respond to a 203 Disconnect-Request including a Service-Type Attribute with an 204 unsupported value with a Disconnect-NAK; an Error-Cause Attribute 205 with value "Unsupported Service" MAY be included. A Disconnect-ACK 206 MAY contain the Attribute Acct-Terminate-Cause (49) [RFC2866] with 207 the value set to 6 for Admin-Reset. 209 A NAS supporting the "Authorize Only" Service-Type within a 210 Disconnect-Request responds with a Disconnect-NAK containing a 211 Service-Type Attribute with value "Authorize Only" and an Error-Cause 212 Attribute with value "Request Initiated". The NAS will then send an 213 Access-Request containing a Service-Type Attribute with a value of 214 "Authorize Only", along with a State Attribute. The RADIUS server 215 MUST reply to this Access-Request with an Access-Reject. 217 2.2. Change-of-Authorization Messages (CoA) 219 CoA-Request packets contain information for dynamically changing 220 session authorizations. Typically this is used to change data 221 filters. The data filters can be of either the ingress or egress 222 kind, and are sent in addition to the identification attributes as 223 described in section 3. The port used, and packet format (described 224 in Section 2.3), are the same as that for Disconnect-Request 225 Messages. 227 The following attributes MAY be sent in a CoA-Request: 229 Filter-ID (11) - Indicates the name of a data filter list 230 to be applied for the session that the 231 identification attributes map to. 233 NAS-Filter-Rule (TBD) - Provides a filter list to be applied 234 for the session that the identification 235 attributes map to. 237 +----------+ CoA-Request +----------+ 238 | | <-------------------- | | 239 | NAS | | RADIUS | 240 | | CoA-Response | Server | 241 | | ---------------------> | | 242 +----------+ +----------+ 244 The NAS responds to a CoA-Request sent by a RADIUS server with a CoA- 245 ACK if the NAS is able to successfully change the authorizations for 246 the user session, or a CoA-NAK if the Request is unsuccessful. A NAS 247 MUST respond to a CoA-Request including a Service-Type Attribute with 248 value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST NOT be sent. A 249 NAS MUST respond to a CoA-Request including a Service-Type Attribute 250 with an unsupported value with a CoA-NAK; an Error-Cause Attribute 251 with value "Unsupported Service" MAY be included. 253 2.3. Packet Format 255 For either Disconnect-Request or CoA-Request messages UDP port 3799 256 is used as the destination port. For responses, the source and 257 destination ports are reversed. Exactly one RADIUS packet is 258 encapsulated in the UDP Data field. 260 A summary of the data format is shown below. The fields are 261 transmitted from left to right. 263 The packet format consists of the fields: Code, Identifier, Length, 264 Authenticator, and Attributes in Type:Length:Value (TLV) format. All 265 fields hold the same meaning as those described in RADIUS [RFC2865]. 266 The Authenticator field MUST be calculated in the same way as is 267 specified for an Accounting-Request in [RFC2866]. 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Code | Identifier | Length | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | | 275 | Authenticator | 276 | | 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Attributes ... 280 +-+-+-+-+-+-+-+-+-+-+-+-+- 282 Code 284 The Code field is one octet, and identifies the type of RADIUS 285 packet. Packets received with an invalid Code field MUST be 286 silently discarded. RADIUS codes (decimal) for this extension are 287 assigned as follows: 289 40 - Disconnect-Request [RFC2882] 290 41 - Disconnect-ACK [RFC2882] 291 42 - Disconnect-NAK [RFC2882] 292 43 - CoA-Request [RFC2882] 293 44 - CoA-ACK [RFC2882] 294 45 - CoA-NAK [RFC2882] 296 Identifier 298 The Identifier field is one octet, and aids in matching requests 299 and replies. The RADIUS client can detect a duplicate request if 300 it has the same server source IP address and source UDP port and 301 Identifier within a short span of time. 303 Unlike RADIUS as defined in [RFC2865], the responsibility for 304 retransmission of Disconnect-Request and CoA-Request messages lies 305 with the RADIUS server. If after sending these messages, the 306 RADIUS server does not receive a response, it will retransmit. 308 The Identifier field MUST be changed whenever the content of the 309 Attributes field changes, or whenever a valid reply has been 310 received for a previous request. For retransmissions where the 311 contents are identical, the Identifier MUST remain unchanged. 313 If the RADIUS server is retransmitting a Disconnect-Request or 314 CoA-Request to the same client as before, and the Attributes 315 haven't changed, the same Request Authenticator, Identifier and 316 source port MUST be used. If any Attributes have changed, a new 317 Authenticator and Identifier MUST be used. 319 Note that if the Event-Timestamp Attribute is included, it will be 320 updated when the packet is retransmitted, changing the content of 321 the Attributes field and requiring a new Identifier and Request 322 Authenticator. 324 If the Request to a primary proxy fails, a secondary proxy must be 325 queried, if available. Issues relating to failover algorithms are 326 described in [RFC3539]. Since this represents a new request, a 327 new Request Authenticator and Identifier MUST be used. However, 328 where the RADIUS server is sending directly to the client, 329 failover typically does not make sense, since Disconnect or CoA 330 messages need to be delivered to the NAS where the session 331 resides. 333 Length 335 The Length field is two octets. It indicates the length of the 336 packet including the Code, Identifier, Length, Authenticator and 337 Attribute fields. Octets outside the range of the Length field 338 MUST be treated as padding and ignored on reception. If the 339 packet is shorter than the Length field indicates, it MUST be 340 silently discarded. The minimum length is 20 and maximum length 341 is 4096. 343 Authenticator 345 The Authenticator field is sixteen (16) octets. The most 346 significant octet is transmitted first. This value is used to 347 authenticate the messages between the RADIUS server and client. 349 Request Authenticator 351 In Request packets, the Authenticator value is a 16 octet MD5 352 [RFC1321] checksum, called the Request Authenticator. The 353 Request Authenticator is calculated the same way as for an 354 Accounting-Request, specified in [RFC2866]. 356 Note that the Request Authenticator of a Disconnect or CoA- 357 Request cannot be done the same way as the Request 358 Authenticator of a RADIUS Access-Request, because there is no 359 User-Password Attribute in a Disconnect-Request or CoA-Request. 361 Response Authenticator 363 The Authenticator field in a Response packet (e.g. Disconnect- 364 ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the 365 Response Authenticator, and contains a one-way MD5 hash 366 calculated over a stream of octets consisting of the Code, 367 Identifier, Length, the Request Authenticator field from the 368 packet being replied to, and the response Attributes if any, 369 followed by the shared secret. The resulting 16 octet MD5 hash 370 value is stored in the Authenticator field of the Response 371 packet. 373 Administrative note: As noted in [RFC2865] Section 3, the secret 374 (password shared between the client and the RADIUS server) SHOULD 375 be at least as large and unguessable as a well-chosen password. 376 RADIUS clients MUST use the source IP address of the RADIUS UDP 377 packet to decide which shared secret to use, so that requests can 378 be proxied. 380 Attributes 382 In Disconnect and CoA-Request messages, all Attributes are treated 383 as mandatory. A NAS MUST respond to a CoA-Request containing one 384 or more unsupported Attributes or Attribute values with a CoA-NAK; 385 a Disconnect-Request containing one or more unsupported Attributes 386 or Attribute values MUST be answered with a Disconnect-NAK. State 387 changes resulting from a CoA-Request MUST be atomic: if the 388 Request is successful, a CoA-ACK is sent, and all requested 389 authorization changes MUST be made. If the CoA-Request is 390 unsuccessful, a CoA-NAK MUST be sent, and the requested 391 authorization changes MUST NOT be made. Similarly, a state change 392 MUST NOT occur as a result of an unsuccessful Disconnect-Request; 393 here a Disconnect-NAK MUST be sent. 395 Since within this specification attributes may be used for 396 identification, authorization or other purposes, even if a NAS 397 implements an attribute for use with RADIUS authentication and 398 accounting, it may not support inclusion of that attribute within 399 Disconnect-Request or CoA-Request messages, given the difference 400 in attribute semantics. This is true even for attributes 401 specified within [RFC2865], [RFC2868], [RFC2869], [RFC3162] or 402 [RFC3579] as allowable within Access-Accept messages. As a 403 result, attributes beyond those specified in Section 3.5 SHOULD 404 NOT be included within Disconnect or CoA messages, since this 405 could produce unpredictable results. 407 If there are any Proxy-State Attributes in a Disconnect-Request or 408 CoA-Request received from the server, the forwarding proxy or NAS 409 MUST include those Proxy-State Attributes in its response to the 410 server. 412 A forwarding proxy or NAS MUST NOT modify existing Proxy-State, 413 State, or Class Attributes present in the packet. The forwarding 414 proxy or NAS MUST treat any Proxy-State attributes already in the 415 packet as opaque data. Its operation MUST NOT depend on the 416 content of Proxy-State attributes added by previous proxies. The 417 forwarding proxy MUST NOT modify any other Proxy-State Attributes 418 that were in the packet; it may choose not to forward them, but it 419 MUST NOT change their contents. If the forwarding proxy omits the 420 Proxy-State Attributes in the request, it MUST attach them to the 421 response before sending it. 423 When the proxy forwards a Disconnect or CoA-Request, it MAY add a 424 Proxy-State Attribute, but it MUST NOT add more than one. If a 425 Proxy-State Attribute is added to a packet when forwarding the 426 packet, the Proxy-State Attribute MUST be added after any existing 427 Proxy-State attributes. The forwarding proxy MUST NOT change the 428 order of any attributes of the same type, including Proxy-State. 429 Other Attributes can be placed before, after or even between the 430 Proxy-State Attributes. 432 When the proxy receives a response to a CoA-Request or Disconnect- 433 Request, it MUST remove its own Proxy-State (the last Proxy- State 434 in the packet) before forwarding the response. Since Disconnect 435 and CoA responses are authenticated on the entire packet contents, 436 the stripping of the Proxy-State Attribute invalidates the 437 integrity check - so the proxy needs to recompute it. 439 3. Attributes 441 In Disconnect-Request and CoA-Request packets, certain attributes are 442 used to uniquely identify the NAS as well as a user session on the 443 NAS. All NAS identification attributes included in a Request message 444 MUST match in order for a Disconnect-Request or CoA-Request to be 445 successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent. 446 For session identification attributes, the User-Name and Acct- 447 Session-Id Attributes, if included, MUST match in order for a 448 Disconnect-Request or CoA-Request to be successful; other session 449 identification attributes SHOULD match. Where a mismatch of session 450 identification attributes is detected, a Disconnect-NAK or CoA-NAK 451 SHOULD be sent. The ability to use NAS or session identification 452 attributes to map to unique/multiple sessions is beyond the scope of 453 this document. Identification attributes include NAS and session 454 identification attributes, as described below. 456 NAS identification attributes 458 Attribute # Reference Description 459 --------- --- --------- ----------- 460 NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS. 461 NAS-Identifier 32 [RFC2865] String identifying the NAS. 462 NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS. 464 Session identification attributes 466 Attribute # Reference Description 467 --------- --- --------- ----------- 468 User-Name 1 [RFC2865] The name of the user 469 associated with the session. 470 NAS-Port 5 [RFC2865] The port on which the 471 session is terminated. 472 Framed-IP-Address 8 [RFC2865] The IPv4 address associated 473 with the session. 474 Called-Station-Id 30 [RFC2865] The link address to which 475 the session is connected. 476 Calling-Station-Id 31 [RFC2865] The link address from which 477 the session is connected. 478 Acct-Session-Id 44 [RFC2866] The identifier uniquely 479 identifying the session 480 on the NAS. 481 Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely 482 identifying related sessions. 483 NAS-Port-Type 61 [RFC2865] The type of port used. 484 NAS-Port-Id 87 [RFC2869] String identifying the port 485 where the session is. 486 Originating-Line-Info 94 [RFC4005] Provides information on the 487 characteristics of the line 488 from which a session 489 originated. 490 Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier 491 associated with the session; 492 always sent with 493 Framed-IPv6-Prefix. 494 Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated 495 with the session, always sent 496 with Framed-Interface-Id. 498 To address security concerns described in Section 6.1, and to enable 499 Diameter/RADIUS translation, the User-Name Attribute SHOULD be 500 present in Disconnect-Request or CoA-Request packets; one or more 501 additional session identification attributes MAY also be present. 502 For example, where a Diameter client utilizes the same Session-Id for 503 both authorization and accounting, inclusion of an Acct-Session-Id 504 Attribute in a Disconnect-Request or CoA-Request can assist with 505 Diameter/RADIUS translation, since Diameter RAR and ASR commands 506 include a Session-Id AVP. 508 To address security concerns described in Section 6.2, one or more of 509 the NAS-IP-Address or NAS-IPv6-Address Attributes SHOULD be present 510 in Disconnect-Request or CoA-Request packets; the NAS-Identifier 511 Attribute MAY be present in addition. 513 If one or more authorization changes specified in a CoA-Request 514 cannot be carried out, or if one or more attributes or attribute- 515 values is unsupported, a CoA-NAK MUST be sent. Similarly, if there 516 are one or more unsupported attributes or attribute values in a 517 Disconnect-Request, a Disconnect-NAK MUST be sent. 519 Where a Service-Type Attribute with value "Authorize Only" is 520 included within a CoA-Request, only NAS or session identification 521 attributes are permitted, as well as Service-Type, Nonce and State 522 attributes. If other attributes are included in such a CoA-Request, 523 implementations MUST send a CoA-NAK; an Error-Cause Attribute with 524 value "Unsupported Attribute" MAY be included. 526 A Disconnect-Request MUST contain only NAS and session identification 527 attributes (see Section 3), as well as Service-Type, Nonce and State 528 attributes. If other attributes are included in a Disconnect- 529 Request, implementations MUST send a Disconnect-NAK; an Error-Cause 530 Attribute with value "Unsupported Attribute" MAY be included. 532 3.1. State 534 [RFC2865] Section 5.44 states: 536 An Access-Request MUST contain either a User-Password or a CHAP- 537 Password or State. An Access-Request MUST NOT contain both a 538 User-Password and a CHAP-Password. If future extensions allow 539 other kinds of authentication information to be conveyed, the 540 attribute for that can be used in an Access-Request instead of 541 User-Password or CHAP-Password. 543 In order to satisfy the requirements of [RFC2865] Section 5.44, an 544 Access-Request with Service-Type="Authorize-Only" MUST contain a 545 State attribute. 547 In order to provide a State attribute to the NAS, a server sending a 548 CoA-Request or Disconnect-Request with a Service-Type value of 549 "Authorize-Only" MUST include a State Attribute, and the NAS MUST 550 include the State Attribute unchanged in the Access-Request. A NAS 551 receiving a CoA-Request or Disconnect-Request containing a Service- 552 Type value of "Authorize-Only" but lacking a State attribute MUST 553 send a CoA-NAK or Disconnect-NAK and SHOULD include an Error-Cause 554 attribute with value 402 (Missing Attribute). 556 3.2. Message-Authenticator 558 The Message-Authenticator Attribute MAY be used to authenticate and 559 integrity-protect CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request, 560 Disconnect-ACK and Disconnect-NAK packets order to prevent spoofing. 562 A RADIUS client receiving a CoA-Request or Disconnect-Request with a 563 Message-Authenticator Attribute present MUST calculate the correct 564 value of the Message-Authenticator and silently discard the packet if 565 it does not match the value sent. A RADIUS server receiving a 566 CoA/Disconnect-ACK or CoA/Disconnect-NAK with a Message-Authenticator 567 Attribute present MUST calculate the correct value of the Message- 568 Authenticator and silently discard the packet if it does not match 569 the value sent. 571 When a Message-Authenticator Attribute is included within a CoA- 572 Request or Disconnect-Request, it is calculated as follows: 574 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, 575 Request Authenticator, Attributes) 577 When the HMAC-MD5 message integrity check is calculated the 578 Request Authenticator field and Message-Authenticator Attribute 579 should be considered to be sixteen octets of zero. The Message- 580 Authenticator Attribute is calculated and inserted in the packet 581 before the Request Authenticator is calculated. 583 When a Message-Authenticator Attribute is included within a CoA- 584 ACK, CoA-NAK, Disconnect-ACK or Disconnect-NAK, it is calculated 585 as follows: 587 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, 588 Request Authenticator, Attributes) 590 When the HMAC-MD5 message integrity check is calculated the 591 Message-Authenticator Attribute should be considered to be sixteen 592 octets of zero. The Request Authenticator is taken from the 593 corresponding CoA/Disconnect-Request. The Message-Authenticator 594 is calculated and inserted in the packet before the Response 595 Authenticator is calculated. 597 3.3. Nonce 599 Description 601 Since the Request Authenticator field within CoA-Request and 602 Disconnect-Request packets does not contain a nonce within the 603 Request Authenticator field, these packets are vulnerable to 604 replay attack without the countermeasures described in Section 605 6.4. As noted in Section 6.4, replay attacks can be addressed by 606 using IPsec to protect RADIUS or by adding an Event-Timestamp 607 attribute to CoA-Request and Disconnect-Request packets. Since 608 use of the Event-Timestamp Attribute requires loose time 609 synchronization, where this is not possible an alternative replay 610 protection mechanism is required. For this purpose, a Nonce 611 Attribute MAY be included within CoA-Request, CoA-ACK, CoA-NAK, 612 Disconnect-Request, Disconnect-ACK, Disconnect-NAK and Accounting- 613 Request packets. 615 A summary of the Nonce Attribute format is shown below. The 616 fields are transmitted from left to right. 618 0 1 2 3 619 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 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Type | Length | Value 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 Value (cont) | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Type 628 TBD for Nonce 630 Length 632 6 634 Value 636 The Value field is four octets, containing a randomly chosen value 637 [RFC4086]. 639 3.4. Error-Cause 641 Description 643 It is possible that the NAS cannot honor Disconnect-Request or 644 CoA-Request messages for some reason. The Error-Cause Attribute 645 provides more detail on the cause of the problem. It MAY be 646 included within Disconnect-ACK, Disconnect-NAK and CoA-NAK 647 messages. 649 A summary of the Error-Cause Attribute format is shown below. The 650 fields are transmitted from left to right. 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Type | Length | Value 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Value (cont) | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 Type 662 101 for Error-Cause 664 Length 666 6 668 Value 670 The Value field is four octets, containing an integer specifying 671 the cause of the error. Values 0-199 and 300-399 are reserved. 672 Values 200-299 represent successful completion, so that these 673 values may only be sent within Disconnect-ACK or CoA-ACK message 674 and MUST NOT be sent within a Disconnect-NAK or CoA-NAK. Values 675 400-499 represent fatal errors committed by the RADIUS server, so 676 that they MAY be sent within CoA-NAK or Disconnect-NAK messages, 677 and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages. 678 Values 500-599 represent fatal errors occurring on a NAS or RADIUS 679 proxy, so that they MAY be sent within CoA-NAK and Disconnect-NAK 680 messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK 681 messages. Error-Cause values SHOULD be logged by the RADIUS 682 server. Error-Code values (expressed in decimal) include: 684 # Value 685 --- ----- 686 201 Residual Session Context Removed 687 202 Invalid EAP Packet (Ignored) 688 401 Unsupported Attribute 689 402 Missing Attribute 690 403 NAS Identification Mismatch 691 404 Invalid Request 692 405 Unsupported Service 693 406 Unsupported Extension 694 501 Administratively Prohibited 695 502 Request Not Routable (Proxy) 696 503 Session Context Not Found 697 504 Session Context Not Removable 698 505 Other Proxy Processing Error 699 506 Resources Unavailable 700 507 Request Initiated 702 "Residual Session Context Removed" is sent in response to a 703 Disconnect-Request if the user session is no longer active, but 704 residual session context was found and successfully removed. This 705 value is only sent within a Disconnect-ACK and MUST NOT be sent 706 within a CoA-ACK, Disconnect-NAK or CoA-NAK. 708 "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT 709 be sent by implementations of this specification. 711 "Unsupported Attribute" is a fatal error sent if a Request 712 contains an attribute (such as a Vendor-Specific or EAP-Message 713 Attribute) that is not supported. 715 "Missing Attribute" is a fatal error sent if critical attributes 716 (such as NAS or session identification attributes) are missing 717 from a Request. 719 "NAS Identification Mismatch" is a fatal error sent if one or more 720 NAS identification attributes (see Section 3) do not match the 721 identity of the NAS receiving the Request. 723 "Invalid Request" is a fatal error sent if some other aspect of 724 the Request is invalid, such as if one or more attributes (such as 725 EAP- Message Attribute(s)) are not formatted properly. 727 "Unsupported Service" is a fatal error sent if a Service-Type 728 Attribute included with the Request is sent with an invalid or 729 unsupported value. 731 "Unsupported Extension" is a fatal error sent due to lack of 732 support for an extension such as Disconnect and/or CoA messages. 733 This will typically be sent by a proxy receiving an ICMP port 734 unreachable message after attempting to forward a Request to the 735 NAS. 737 "Administratively Prohibited" is a fatal error sent if the NAS is 738 configured to prohibit honoring of Request messages for the 739 specified session. 741 "Request Not Routable" is a fatal error which MAY be sent by a 742 RADIUS proxy and MUST NOT be sent by a NAS. It indicates that the 743 RADIUS proxy was unable to determine how to route the Request to 744 the NAS. For example, this can occur if the required entries are 745 not present in the proxy's realm routing table. 747 "Session Context Not Found" is a fatal error sent if the session 748 context identified in the Request does not exist on the NAS. 750 "Session Context Not Removable" is a fatal error sent in response 751 to a Disconnect-Request if the NAS was able to locate the session 752 context, but could not remove it for some reason. It MUST NOT be 753 sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a 754 Disconnect-NAK. 756 "Other Proxy Processing Error" is a fatal error sent in response 757 to a Request that could not be processed by a proxy, for reasons 758 other than routing. 760 "Resources Unavailable" is a fatal error sent when a Request could 761 not be honored due to lack of available NAS resources (memory, 762 non- volatile storage, etc.). 764 "Request Initiated" is a fatal error sent in response to a Request 765 including a Service-Type Attribute with a value of "Authorize 766 Only". It indicates that the Disconnect-Request or CoA-Request 767 has not been honored, but that a RADIUS Access-Request including a 768 Service-Type Attribute with value "Authorize Only" is being sent 769 to the RADIUS server. 771 3.5. Table of Attributes 773 The following table provides a guide to which attributes may be found 774 in which packets, and in what quantity. 776 Change-of-Authorization Messages 778 Request ACK NAK # Attribute 779 0-1 0 0 1 User-Name [Note 1] 780 0-1 0 0 4 NAS-IP-Address [Note 1] 781 0-1 0 0 5 NAS-Port [Note 1] 782 0-1 0 0-1 6 Service-Type [Note 6] 783 0-1 0 0 7 Framed-Protocol [Note 3] 784 0-1 0 0 8 Framed-IP-Address [Note 1] 785 0-1 0 0 9 Framed-IP-Netmask [Note 3] 786 0-1 0 0 10 Framed-Routing [Note 3] 787 0+ 0 0 11 Filter-ID [Note 3] 788 Request ACK NAK # Attribute 789 Request ACK NAK # Attribute 790 0-1 0 0 12 Framed-MTU [Note 3] 791 0+ 0 0 13 Framed-Compression [Note 3] 792 0+ 0 0 14 Login-IP-Host [Note 3] 793 0-1 0 0 15 Login-Service [Note 3] 794 0-1 0 0 16 Login-TCP-Port [Note 3] 795 0+ 0 0 18 Reply-Message [Note 2] 796 0-1 0 0 19 Callback-Number [Note 3] 797 0-1 0 0 20 Callback-Id [Note 3] 798 0+ 0 0 22 Framed-Route [Note 3] 799 0-1 0 0 23 Framed-IPX-Network [Note 3] 800 0-1 0-1 0-1 24 State [Note 7] 801 0+ 0 0 25 Class [Note 3] 802 0+ 0 0 26 Vendor-Specific [Note 3] 803 0-1 0 0 27 Session-Timeout [Note 3] 804 0-1 0 0 28 Idle-Timeout [Note 3] 805 0-1 0 0 29 Termination-Action [Note 3] 806 0-1 0 0 30 Called-Station-Id [Note 1] 807 0-1 0 0 31 Calling-Station-Id [Note 1] 808 0-1 0 0 32 NAS-Identifier [Note 1] 809 0+ 0+ 0+ 33 Proxy-State 810 0-1 0 0 34 Login-LAT-Service [Note 3] 811 0-1 0 0 35 Login-LAT-Node [Note 3] 812 0-1 0 0 36 Login-LAT-Group [Note 3] 813 0-1 0 0 37 Framed-AppleTalk-Link [Note 3] 814 0+ 0 0 38 Framed-AppleTalk-Network [Note 3] 815 0-1 0 0 39 Framed-AppleTalk-Zone [Note 3] 816 0-1 0 0 44 Acct-Session-Id [Note 1] 817 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] 818 0-1 0-1 0-1 55 Event-Timestamp 819 0-1 0 0 61 NAS-Port-Type [Note 1] 820 0-1 0 0 62 Port-Limit [Note 3] 821 0-1 0 0 63 Login-LAT-Port [Note 3] 822 0+ 0 0 64 Tunnel-Type [Note 5] 823 0+ 0 0 65 Tunnel-Medium-Type [Note 5] 824 0+ 0 0 66 Tunnel-Client-Endpoint [Note 5] 825 0+ 0 0 67 Tunnel-Server-Endpoint [Note 5] 826 0+ 0 0 69 Tunnel-Password [Note 5] 827 0-1 0 0 71 ARAP-Features [Note 3] 828 0-1 0 0 72 ARAP-Zone-Access [Note 3] 829 0+ 0 0 78 Configuration-Token [Note 3] 830 0+ 0-1 0 79 EAP-Message [Note 2] 831 0-1 0-1 0-1 80 Message-Authenticator 832 0+ 0 0 81 Tunnel-Private-Group-ID [Note 5] 833 0+ 0 0 82 Tunnel-Assignment-ID [Note 5] 834 0+ 0 0 83 Tunnel-Preference [Note 5] 835 0-1 0 0 85 Acct-Interim-Interval [Note 3] 836 Request ACK NAK # Attribute 837 Request ACK NAK # Attribute 838 0-1 0 0 87 NAS-Port-Id [Note 1] 839 0-1 0 0 88 Framed-Pool [Note 3] 840 0+ 0 0 90 Tunnel-Client-Auth-ID [Note 5] 841 0+ 0 0 91 Tunnel-Server-Auth-ID [Note 5] 842 0-1 0 0 94 Originating-Line-Info [Note 1] 843 0-1 0 0 95 NAS-IPv6-Address [Note 1] 844 0-1 0 0 96 Framed-Interface-Id [Note 1] 845 0+ 0 0 97 Framed-IPv6-Prefix [Note 1] 846 0+ 0 0 98 Login-IPv6-Host [Note 3] 847 0+ 0 0 99 Framed-IPv6-Route [Note 3] 848 0-1 0 0 100 Framed-IPv6-Pool [Note 3] 849 0 0 0+ 101 Error-Cause 850 0-1 0 0 TBD NAS-Filter-Rule 851 0-1 0-1 0-1 TBD Nonce [Note 8] 852 Request ACK NAK # Attribute 854 Disconnect Messages 856 Request ACK NAK # Attribute 857 0-1 0 0 1 User-Name [Note 1] 858 0-1 0 0 4 NAS-IP-Address [Note 1] 859 0-1 0 0 5 NAS-Port [Note 1] 860 0-1 0 0-1 6 Service-Type [Note 6] 861 0-1 0 0 8 Framed-IP-Address [Note 1] 862 0+ 0 0 18 Reply-Message [Note 2] 863 0-1 0-1 0-1 24 State [Note 7] 864 0+ 0 0 25 Class [Note 4] 865 0+ 0 0 26 Vendor-Specific 866 0-1 0 0 30 Called-Station-Id [Note 1] 867 0-1 0 0 31 Calling-Station-Id [Note 1] 868 0-1 0 0 32 NAS-Identifier [Note 1] 869 0+ 0+ 0+ 33 Proxy-State 870 0-1 0 0 44 Acct-Session-Id [Note 1] 871 0-1 0-1 0 49 Acct-Terminate-Cause 872 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] 873 0-1 0-1 0-1 55 Event-Timestamp 874 0-1 0 0 61 NAS-Port-Type [Note 1] 875 0+ 0-1 0 79 EAP-Message [Note 2] 876 0-1 0-1 0-1 80 Message-Authenticator 877 0-1 0 0 87 NAS-Port-Id [Note 1] 878 0-1 0 0 94 Orginating-Line-Info [Note 1] 879 0-1 0 0 95 NAS-IPv6-Address [Note 1] 880 0-1 0 0 96 Framed-Interface-Id [Note 1] 881 0+ 0 0 97 Framed-IPv6-Prefix [Note 1] 882 0 0+ 0+ 101 Error-Cause 883 0-1 0-1 0-1 TBD Nonce [Note 8] 884 Request ACK NAK # Attribute 885 The following table defines the meaning of the above table entries. 887 0 This attribute MUST NOT be present in packet. 888 0+ Zero or more instances of this attribute MAY be present in packet. 889 0-1 Zero or one instance of this attribute MAY be present in packet. 890 1 Exactly one instance of this attribute MUST be present in packet. 892 [Note 1] Where NAS or session identification attributes are included 893 in Disconnect-Request or CoA-Request messages, they are used for 894 identification purposes only. These attributes MUST NOT be used for 895 purposes other than identification (e.g. within CoA-Request messages 896 to request authorization changes). 898 [Note 2] The Reply-Message Attribute is used to present a displayable 899 message to the user. The message is only displayed as a result of a 900 successful Disconnect-Request or CoA-Request (where a Disconnect-ACK 901 or CoA-ACK is subsequently sent). Where EAP is used for 902 authentication, an EAP-Message/Notification-Request Attribute is sent 903 instead, and Disconnect-ACK or CoA-ACK messages contain an EAP- 904 Message/Notification-Response Attribute. 906 [Note 3] When included within a CoA-Request, these attributes 907 represent an authorization change request. When one of these 908 attributes is omitted from a CoA-Request, the NAS assumes that the 909 attribute value is to remain unchanged. Attributes included in a 910 CoA-Request replace all existing value(s) of the same attribute(s). 912 [Note 4] When included within a successful Disconnect-Request (where 913 a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be 914 sent unmodified by the client to the accounting server in the 915 Accounting Stop packet. If the Disconnect-Request is unsuccessful, 916 then the Class Attribute is not processed. 918 [Note 5] When included within a CoA-Request, these attributes 919 represent an authorization change request. Where tunnel attribute(s) 920 are sent within a successful CoA-Request, all existing tunnel 921 attributes are removed and replaced by the new attribute(s). 923 [Note 6] When included within a Disconnect-Request or CoA-Request, a 924 Service-Type Attribute with value "Authorize Only" indicates that the 925 Request only contains NAS and session identification attributes, and 926 that the NAS should attempt reauthorization by sending an Access- 927 Request with a Service-Type Attribute with value "Authorize Only". 928 This enables a usage model akin to that supported in Diameter, thus 929 easing translation between the two protocols. Support for the 930 Service-Type Attribute is optional within CoA-Request and Disconnect- 931 Request messages; where it is not included, the Request message may 932 contain both identification and authorization attributes. A NAS that 933 does not support the Service-Type Attribute with the value "Authorize 934 Only" within a Disconnect-Request MUST respond with a Disconnect-NAK 935 including no Service-Type Attribute; an Error-Cause Attribute with 936 value "Unsupported Service" MAY be included. A NAS that does not 937 support the Service-Type Attribute with the value "Authorize Only" 938 within a CoA-Request MUST respond with a CoA-NAK including no 939 Service-Type Attribute; an Error-Cause Attribute with value 940 "Unsupported Service" MAY be included. 942 A NAS supporting the "Authorize Only" Service-Type value within 943 Disconnect-Request or CoA-Request messages MUST respond with a 944 Disconnect-NAK or CoA-NAK respectively, containing a Service-Type 945 Attribute with value "Authorize Only", and an Error-Cause Attribute 946 with value "Request Initiated". The NAS then sends an Access-Request 947 to the RADIUS server with a Service-Type Attribute with value 948 "Authorize Only". This Access-Request SHOULD contain the NAS 949 attributes from the Disconnect or CoA-Request, as well as the session 950 attributes from the Request legal for inclusion in an Access-Request 951 as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As 952 noted in [RFC2869] Section 5.19, a Message-Authenticator attribute 953 SHOULD be included in an Access-Request that does not contain a User- 954 Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. The 955 RADIUS server should send back an Access-Accept to (re-)authorize the 956 session or an Access-Reject to refuse to (re-)authorize it. 958 [Note 7] The State Attribute is available to be sent by the RADIUS 959 server to the NAS in a Disconnect-Request or CoA-Request message and 960 MUST be sent unmodified from the NAS to the RADIUS server in a 961 subsequent ACK or NAK message. If a Service-Type Attribute with 962 value "Authorize Only" is included in a Disconnect-Request or CoA- 963 Request then a State Attribute MUST be present, and MUST be sent 964 unmodified from the NAS to the RADIUS server in the resulting Access- 965 Request sent to the RADIUS server, if any. The State Attribute is 966 also available to be sent by the RADIUS server to the NAS in a CoA- 967 Request that also includes a Termination-Action Attribute with the 968 value of RADIUS-Request. If the client performs the Termination- 969 Action by sending a new Access-Request upon termination of the 970 current session, it MUST include the State Attribute unchanged in 971 that Access-Request. In either usage, the client MUST NOT interpret 972 the Attribute locally. A Disconnect- Request or CoA-Request packet 973 must have only zero or one State Attribute. Usage of the State 974 Attribute is implementation dependent. If the RADIUS server does not 975 recognize the State Attribute in the Access-Request, then it MUST 976 send an Access-Reject. 978 [Note 8] A Nonce Attribute SHOULD be included in a CoA-Request or 979 Disconnect-Request packet that is not protected by IPsec or does not 980 contain an Event-Timestamp Attribute, so as to prevent replay 981 attacks. A Nonce Attribute MAY also be included in CoA-ACK, CoA-NAK, 982 Disconnect-ACK, Disconnect-NAK, or Accounting-Request packets. 984 4. Diameter Considerations 986 Due to differences in handling change-of-authorization requests in 987 RADIUS and Diameter, it may be difficult or impossible for a 988 Diameter/RADIUS gateway to successfully translate a Diameter Re-Auth- 989 Request (RAR) to a CoA-Request and vice versa. For example, since a 990 CoA-Request only initiates an authorization change but does not 991 initiate re-authentication, a RAR command containing a Re-Auth- 992 Request-Type AVP with value "AUTHORIZE_AUTHENTICATE" cannot be 993 directly translated to a CoA-Request. A Diameter/RADIUS gateway 994 receiving a CoA-Request containing authorization changes will need to 995 translate this into two Diameter exchange. First, the 996 Diameter/RADIUS gateway will issue a RAR command including a Session- 997 Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". 998 Then the Diameter/RADIUS gateway will respond to the ensuing access 999 request with a response including the authorization attributes 1000 gleaned from the CoA-Request. For the translation to be possible, 1001 the CoA-Request MUST include a Acct-Session-Id Attribute. If the 1002 Diameter client uses the same Session-Id for both authorization and 1003 accounting, then the Diameter/RADIUS gateway can copy the contents of 1004 the Acct-Session-Id Attribute into the Session-Id AVP; otherwise, it 1005 will need to map the Acct-Session-Id value to an equivalent Session- 1006 Id for use within a RAR command. 1008 To simplify translation between RADIUS and Diameter, a server 1009 compliant with this specification MAY include a Service-Type 1010 Attribute with value "Authorize Only" within a CoA-Request. Such a 1011 CoA-Request MUST contain a State Attribute. A NAS supporting the 1012 "Authorize Only" Service-Type within a CoA-Request responds with a 1013 CoA-NAK containing a Service-Type Attribute with value "Authorize 1014 Only", and an Error-Cause Attribute with value "Request Initiated". 1015 The NAS will then send an Access-Request containing a Service-Type 1016 Attribute with a value of "Authorize Only", along with a State 1017 Attribute. A Diameter/RADIUS gateway receiving a CoA-Request 1018 containing a Service-Type with value "Authorize Only" translates this 1019 to a RAR with Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". 1020 The received RAA is then translated to a CoA-NAK with a Service-Type 1021 value of "Authorize Only". If the Result-Code AVP in the RAA has a 1022 value in the success category, then an Error-Cause Attribute with 1023 value "Request Initiated" is included in the CoA-NAK. If the 1024 Result-Code AVP in the RAA has a value indicating a Protocol Error or 1025 a Transient or Permanent Failure, then an alternate Error-Cause 1026 Attribute is returned as suggested below. 1028 Within Diameter, a server can request that a session be aborted by 1029 sending an Abort-Session-Request (ASR), identifying the session to be 1030 terminated using Session-ID and User-Name AVPs. The ASR command is 1031 translated to a Disconnect-Request containing an Acct-Session-Id and 1032 User-Name attribute. If the Diameter client utilizes the same 1033 Session-Id in both authorization and accounting, then the value of 1034 the Session-ID AVP may be placed in the Acct-Session-Id attribute; 1035 otherwise the value of the Session-ID AVP will need to be mapped to 1036 an appropriate Acct-Session-Id value. For a Disconnect-Request to 1037 be translatable to an ASR, an Acct-Session-Id attribute MUST be 1038 present. If the Diameter client utilizes the same Session-Id in both 1039 authorization and accounting, then the value of the Acct-Session-Id 1040 may be placed into the Session-ID AVP within the ASR; otherwise the 1041 value of the Acct-Session-Id will need to be mapped to an appropriate 1042 Session-ID value. 1044 An Abort-Session-Answer (ASA) command is sent in response to an ASR 1045 in order to indicate the disposition of the request. A 1046 Diameter/RADIUS gateway receiving a Disconnect-ACK translates this to 1047 an ASA command with a Result-Code AVP of "DIAMETER_SUCCESS". A 1048 Disconnect-NAK received from the server is translated to an ASA 1049 command with a Result-Code AVP which depends on the value of the 1050 Error-Cause Attribute. Suggested translations between Error-Cause 1051 Attribute values and Result-Code AVP values are included below: 1053 # Error-Cause Attribute Value Result-Code AVP 1054 --- --------------------------- ------------------------ 1055 201 Residual Session Context DIAMETER_SUCCESS 1056 Removed 1057 202 Invalid EAP Packet DIAMETER_LIMITED_SUCCESS 1058 (Ignored) 1059 401 Unsupported Attribute DIAMETER_AVP_UNSUPPORTED 1060 402 Missing Attribute DIAMETER_MISSING_AVP 1061 403 NAS Identification DIAMETER_REALM_NOT_SERVED 1062 Mismatch 1063 404 Invalid Request DIAMETER_UNABLE_TO_COMPLY 1064 405 Unsupported Service DIAMETER_COMMAND_UNSUPPORTED 1065 406 Unsupported Extension DIAMETER_APPLICATION_UNSUPPORTED 1066 501 Administratively DIAMETER_AUTHORIZATION_REJECTED 1067 Prohibited 1068 502 Request Not Routable DIAMETER_UNABLE_TO_DELIVER 1069 (Proxy) 1070 503 Session Context Not Found DIAMETER_UNKNOWN_SESSION_ID 1071 504 Session Context Not DIAMETER_AUTHORIZATION_REJECTED 1072 Removable 1073 505 Other Proxy Processing DIAMETER_UNABLE_TO_COMPLY 1074 Error 1075 506 Resources Unavailable DIAMETER_RESOURCES_EXCEEDED 1076 507 Request Initiated DIAMETER_SUCCESS 1077 Since both the ASR/ASA and Disconnect-Request/Disconnect- 1078 NAK/Disconnect-ACK exchanges involve just a request and response, 1079 inclusion of an "Authorize Only" Service-Type within a Disconnect- 1080 Request is not needed to assist in Diameter/RADIUS translation, and 1081 may make translation more difficult. As a result, inclusion of a 1082 Service-Type of "Authorize Only" within a Disconnect-Request is NOT 1083 RECOMMENDED. 1085 5. IANA Considerations 1087 This specification does not create any new registries. 1089 This document uses the RADIUS [RFC2865] namespace, see 1090 . Allocation of one 1091 update for the section "RADIUS Attribute Types" is requested. The 1092 RADIUS attribute for which a value is requested is: 1094 TBD - Nonce 1096 There are six updates for the section: RADIUS Packet Type Codes. 1097 These Packet Types are allocated in [RFC3575]: 1099 40 - Disconnect-Request 1100 41 - Disconnect-ACK 1101 42 - Disconnect-NAK 1102 43 - CoA-Request 1103 44 - CoA-ACK 1104 45 - CoA-NAK 1106 A new Service-Type value for "Authorize Only" (17) is allocated in 1107 [RFC3576]. This draft also uses the UDP [RFC768] namespace, see 1108 . UDP port 3799 has 1109 been assigned [RFC3576]. This specification also utilizes the Error- 1110 Cause Attribute (101) allocated in [RFC3576], with the following 1111 decimal values: 1113 # Value 1114 --- ----- 1115 201 Residual Session Context Removed 1116 202 Invalid EAP Packet (Ignored) 1117 401 Unsupported Attribute 1118 402 Missing Attribute 1119 403 NAS Identification Mismatch 1120 404 Invalid Request 1121 405 Unsupported Service 1122 406 Unsupported Extension 1123 501 Administratively Prohibited 1124 502 Request Not Routable (Proxy) 1125 503 Session Context Not Found 1126 504 Session Context Not Removable 1127 505 Other Proxy Processing Error 1128 506 Resources Unavailable 1129 507 Request Initiated 1131 6. Security Considerations 1133 6.1. Authorization Issues 1135 Where a NAS is shared by multiple providers, it is undesirable for 1136 one provider to be able to send Disconnect-Request or CoA-Requests 1137 affecting the sessions of another provider. 1139 A NAS or RADIUS proxy MUST silently discard Disconnect-Request or 1140 CoA-Request messages from untrusted sources. By default, a RADIUS 1141 proxy SHOULD perform a "reverse path forwarding" (RPF) check to 1142 verify that a Disconnect-Request or CoA-Request originates from an 1143 authorized RADIUS server. In addition, it SHOULD be possible to 1144 explicitly authorize additional sources of Disconnect-Request or CoA- 1145 Request packets relating to certain classes of sessions. For 1146 example, a particular source can be explicitly authorized to send 1147 CoA-Request messages relating to users within a set of realms. 1149 To perform the RPF check, the proxy uses the session identification 1150 attributes included in Disconnect-Request or CoA-Request messages, in 1151 order to determine the RADIUS server(s) to which an equivalent 1152 Access-Request could be routed. If the source address of the 1153 Disconnect-Request or CoA-Request is within this set, then the 1154 Request is forwarded; otherwise it MUST be silently discarded. 1156 Typically the proxy will extract the realm from the Network Access 1157 Identifier [RFC4282] included within the User-Name Attribute, and 1158 determine the corresponding RADIUS servers in the proxy routing 1159 tables. The RADIUS servers for that realm are then compared against 1160 the source address of the packet. Where no RADIUS proxy is present, 1161 the RPF check will need to be performed by the NAS itself. 1163 Since authorization to send a Disconnect-Request or CoA-Request is 1164 determined based on the source address and the corresponding shared 1165 secret, the NASes or proxies SHOULD configure a different shared 1166 secret for each RADIUS server. 1168 6.2. Impersonation 1170 [RFC2865] Section 3 states: 1172 A RADIUS server MUST use the source IP address of the RADIUS 1173 UDP packet to decide which shared secret to use, so that 1174 RADIUS requests can be proxied. 1176 When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or 1177 NAS-IPv6-Address Attributes will typically not match the source 1178 address observed by the RADIUS server. Since the NAS-Identifier 1179 Attribute need not contain an FQDN, this attribute may not be 1180 resolvable to the source address observed by the RADIUS server, even 1181 when no proxy is present. 1183 As a result, the authenticity check performed by a RADIUS server or 1184 proxy does not verify the correctness of NAS identification 1185 attributes. This makes it possible for a rogue NAS to forge NAS-IP- 1186 Address, NAS-IPv6-Address or NAS-Identifier Attributes within a 1187 RADIUS Access-Request in order to impersonate another NAS. It is 1188 also possible for a rogue NAS to forge session identification 1189 attributes such as the Called-Station-Id, Calling-Station-Id, or 1190 Originating-Line-Info [RFC4005]. This could fool the RADIUS server 1191 into sending Disconnect-Request or CoA-Request messages containing 1192 forged session identification attributes to a NAS targeted by an 1193 attacker. 1195 To address these vulnerabilities RADIUS proxies SHOULD check whether 1196 NAS identification attributes (see Section 3) match the source 1197 address of packets originating from the NAS. Where one or more 1198 attributes do not match, Disconnect-Request or CoA-Request messages 1199 SHOULD be silently discarded. 1201 Such a check may not always be possible. Since the NAS-Identifier 1202 Attribute need not correspond to an FQDN, it may not be resolvable to 1203 an IP address to be matched against the source address. Also, where 1204 a NAT exists between the RADIUS client and proxy, checking the NAS- 1205 IP-Address or NAS-IPv6-Address Attributes may not be feasible. 1207 6.3. IPsec Usage Guidelines 1209 In addition to security vulnerabilities unique to Disconnect or CoA 1210 messages, the protocol exchanges described in this document are 1211 susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is 1212 RECOMMENDED that IPsec be employed to afford better security. 1214 Implementations of this specification SHOULD support IPsec [RFC2401] 1215 along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] 1216 with non-null transform SHOULD be supported, and IPsec ESP with a 1217 non-null encryption transform and authentication support SHOULD be 1218 used to provide per-packet confidentiality, authentication, integrity 1219 and replay protection. IKE SHOULD be used for key management. 1221 Within RADIUS [RFC2865], a shared secret is used for hiding of 1222 Attributes such as User-Password, as well as in computation of the 1223 Response Authenticator. In RADIUS accounting [RFC2866], the shared 1224 secret is used in computation of both the Request Authenticator and 1225 the Response Authenticator. 1227 Since in RADIUS a shared secret is used to provide confidentiality as 1228 well as integrity protection and authentication, only use of IPsec 1229 ESP with a non-null transform can provide security services 1230 sufficient to substitute for RADIUS application-layer security. 1231 Therefore, where IPsec AH or ESP null is used, it will typically 1232 still be necessary to configure a RADIUS shared secret. 1234 Where RADIUS is run over IPsec ESP with a non-null transform, the 1235 secret shared between the NAS and the RADIUS server MAY NOT be 1236 configured. In this case, a shared secret of zero length MUST be 1237 assumed. However, a RADIUS server that cannot know whether incoming 1238 traffic is IPsec-protected MUST be configured with a non-null RADIUS 1239 shared secret. 1241 When IPsec ESP is used with RADIUS, per-packet authentication, 1242 integrity and replay protection MUST be used. 3DES-CBC MUST be 1243 supported as an encryption transform and AES-CBC SHOULD be supported. 1244 AES-CBC SHOULD be offered as a preferred encryption transform if 1245 supported. HMAC-SHA1-96 MUST be supported as an authentication 1246 transform. DES-CBC SHOULD NOT be used as the encryption transform. 1248 A typical IPsec policy for an IPsec-capable RADIUS client is 1249 "Initiate IPsec, from me to any destination port UDP 1812". This 1250 IPsec policy causes an IPsec SA to be set up by the RADIUS client 1251 prior to sending RADIUS traffic. If some RADIUS servers contacted by 1252 the client do not support IPsec, then a more granular policy will be 1253 required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, 1254 destination port UDP 1812." 1256 For a client implementing this specification the policy would be 1257 "Accept IPsec, from any to me, destination port UDP 3799". This 1258 causes the RADIUS client to accept (but not require) use of IPsec. 1259 It may not be appropriate to require IPsec for all RADIUS servers 1260 connecting to an IPsec-enabled RADIUS client, since some RADIUS 1261 servers may not support IPsec. 1263 For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept 1264 IPsec, from any to me, destination port 1812". This causes the 1265 RADIUS server to accept (but not require) use of IPsec. It may not 1266 be appropriate to require IPsec for all RADIUS clients connecting to 1267 an IPsec-enabled RADIUS server, since some RADIUS clients may not 1268 support IPsec. 1270 For servers implementing this specification, the policy would be 1271 "Initiate IPsec, from me to any, destination port UDP 3799". This 1272 causes the RADIUS server to initiate IPsec when sending RADIUS 1273 extension traffic to any RADIUS client. If some RADIUS clients 1274 contacted by the server do not support IPsec, then a more granular 1275 policy will be required, such as "Initiate IPsec, from me to IPsec- 1276 capable-RADIUS-client, destination port UDP 3799". 1278 Where IPsec is used for security, and no RADIUS shared secret is 1279 configured, it is important that the RADIUS client and server perform 1280 an authorization check. Before enabling a host to act as a RADIUS 1281 client, the RADIUS server SHOULD check whether the host is authorized 1282 to provide network access. Similarly, before enabling a host to act 1283 as a RADIUS server, the RADIUS client SHOULD check whether the host 1284 is authorized for that role. 1286 RADIUS servers can be configured with the IP addresses (for IKE 1287 Aggressive Mode with pre-shared keys) or FQDNs (for certificate 1288 authentication) of RADIUS clients. Alternatively, if a separate 1289 Certification Authority (CA) exists for RADIUS clients, then the 1290 RADIUS server can configure this CA as a trust anchor [RFC3280] for 1291 use with IPsec. 1293 Similarly, RADIUS clients can be configured with the IP addresses 1294 (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for 1295 certificate authentication) of RADIUS servers. Alternatively, if a 1296 separate CA exists for RADIUS servers, then the RADIUS client can 1297 configure this CA as a trust anchor for use with IPsec. 1299 Since unlike SSL/TLS, IKE does not permit certificate policies to be 1300 set on a per-port basis, certificate policies need to apply to all 1301 uses of IPsec on RADIUS clients and servers. In IPsec deployment 1302 supporting only certificate authentication, a management station 1303 initiating an IPsec-protected telnet session to the RADIUS server 1304 would need to obtain a certificate chaining to the RADIUS client CA. 1305 Issuing such a certificate might not be appropriate if the 1306 management station was not authorized as a RADIUS client. 1308 Where RADIUS clients may obtain their IP address dynamically (such as 1309 an Access Point supporting DHCP), Main Mode with pre-shared keys 1310 [RFC2409] SHOULD NOT be used, since this requires use of a group pre- 1311 shared key; instead, Aggressive Mode SHOULD be used. Where RADIUS 1312 client addresses are statically assigned either Aggressive Mode or 1313 Main Mode MAY be used. With certificate authentication, Main Mode 1314 SHOULD be used. 1316 Care needs to be taken with IKE Phase 1 Identity Payload selection in 1317 order to enable mapping of identities to pre-shared keys even with 1318 Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity 1319 Payloads are used and addresses are dynamically assigned, mapping of 1320 identities to keys is not possible, so that group pre-shared keys are 1321 still a practical necessity. As a result, the ID_FQDN identity 1322 payload SHOULD be employed in situations where Aggressive mode is 1323 utilized along with pre-shared keys and IP addresses are dynamically 1324 assigned. This approach also has other advantages, since it allows 1325 the RADIUS server and client to configure themselves based on the 1326 fully qualified domain name of their peers. 1328 Note that with IPsec, security services are negotiated at the 1329 granularity of an IPsec SA, so that RADIUS exchanges requiring a set 1330 of security services different from those negotiated with existing 1331 IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs 1332 are also advisable where quality of service considerations dictate 1333 different handling RADIUS conversations. Attempting to apply 1334 different quality of service to connections handled by the same IPsec 1335 SA can result in reordering, and falling outside the replay window. 1336 For a discussion of the issues, see [RFC2983]. 1338 6.4. Replay Protection 1340 Where IPsec replay protection is not used, a Nonce or Event-Timestamp 1341 (55) [RFC2869] Attribute SHOULD be included within CoA-Request and 1342 Disconnect-Request packets, and MAY be included within CoA-ACK, CoA- 1343 NAK, Disconnect-ACK and Disconnect-NAK packets. When the Event- 1344 Timestamp attribute is present, both the NAS and the RADIUS server 1345 MUST check that the Event-Timestamp Attribute is current within an 1346 acceptable time window. If the Event-Timestamp Attribute is not 1347 current, then the message MUST be silently discarded. This implies 1348 the need for loose time synchronization within the network, which can 1349 be achieved by a variety of means, including SNTP, as described in 1350 [RFC4330]. 1352 Implementations SHOULD be configurable to discard CoA-Request or 1353 Disconnect-Request packets containing neither a Nonce nor an Event- 1354 Timestamp attribute. A default time window of 300 seconds is 1355 recommended. 1357 7. Example Traces 1359 Disconnect Request with User-Name: 1361 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....# 1362 16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^.. 1363 32: 6d63 6869 6261 1365 Disconnect Request with Acct-Session-ID: 1367 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(..... 1368 16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,. 1369 32: 3930 3233 3435 3637 90234567 1371 Disconnect Request with Framed-IP-Address: 1373 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(..... 1374 16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ... 1375 32: 0a00 0203 1377 8. References 1379 8.1. Normative References 1381 [RFC1305] Mills, D. L., "Network Time Protocol (version 3) 1382 Specification, Implementation and Analysis, RFC 1305 March, 1383 1992. 1385 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1386 April 1992. 1388 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 1389 for Message Authentication", RFC 2104, February 1997. 1391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1392 Requirement Levels", RFC 2119, March 1997. 1394 [RFC2401] Atkinson, R. and S. Kent, "Security Architecture for the 1395 Internet Protocol", RFC 2401, November 1998. 1397 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1398 (ESP)", RFC 2406, November 1998 1400 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1401 RFC 2409, November 1998 1403 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 1404 Considerations Section in RFCs", BCP 26, RFC 2434, October 1405 1998. 1407 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 1408 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1409 2000. 1411 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1413 [RFC2869] Rigney, C., Willats W. and P. Calhoun, "RADIUS Extensions", 1414 RFC 2869, June 2000. 1416 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 1417 3162, August 2001. 1419 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 1420 Public Key Infrastructure Certificate and Certificate 1421 Revocation List (CRL) Profile", RFC 3280, April 2002. 1423 [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July 1424 2003. 1426 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 1427 Authentication Protocol (EAP)", RFC 3579, September 2003. 1429 [RFC4086] Eastlake, D., Schiller, J. and S. Crocker, "Randomness 1430 Requirements for Security", RFc 4086, June 2005. 1432 [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network 1433 Access Identifier", RFC 4282, December 2005. 1435 8.2. Informative References 1437 [RFC2882] Mitton, D., "Network Access Server Requirements: Extended 1438 RADIUS Practices", RFC 2882, July 2000. 1440 [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, 1441 October 2000. 1443 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 1444 Accounting Transport Profile", RFC 3539, June 2003. 1446 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 1447 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1449 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 1450 "Dynamic Authorization Extensions to Remote Authentication 1451 Dial In User Service (RADIUS)", RFC 3576, July 2003. 1453 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 1454 Network Access Server Application", RFC 4005, August 2005. 1456 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for 1457 IPv4, IPv6 and OSI", RFC 4330, January 2006. 1459 [MD5Attack] 1460 Dobbertin, H., "The Status of MD5 After a Recent Attack", 1461 CryptoBytes Vol.2 No.2, Summer 1996. 1463 Acknowledgments 1465 This protocol was first developed and distributed by Ascend 1466 Communications. Example code was distributed in their free server 1467 kit. 1469 The authors would like to acknowledge the valuable suggestions and 1470 feedback from the following people: 1472 Avi Lior , 1473 Randy Bush , 1474 Steve Bellovin 1475 Glen Zorn , 1476 Mark Jones , 1477 Claudio Lapidus , 1478 Anurag Batta , 1479 Kuntal Chowdhury , and 1480 Tim Moore . 1481 Russ Housley 1483 Authors' Addresses 1485 Murtaza Chiba 1486 Cisco Systems, Inc. 1487 170 West Tasman Dr. 1488 San Jose CA, 95134 1490 EMail: mchiba@cisco.com 1491 Phone: +1 408 525 7198 1493 Gopal Dommety 1494 Cisco Systems, Inc. 1495 170 West Tasman Dr. 1496 San Jose, CA 95134 1498 EMail: gdommety@cisco.com 1499 Phone: +1 408 525 1404 1501 Mark Eklund 1502 Cisco Systems, Inc. 1503 170 West Tasman Dr. 1504 San Jose, CA 95134 1506 EMail: meklund@cisco.com 1507 Phone: +1 865 671 6255 1509 David Mitton 1510 RSA Security, Inc. 1511 174 Middlesex Turnpike 1512 Bedford, MA 01730 1514 EMail: dmitton@circularnetworks.com 1516 Bernard Aboba 1517 Microsoft Corporation 1518 One Microsoft Way 1519 Redmond, WA 98052 1521 EMail: bernarda@microsoft.com 1522 Phone: +1 425 706 6605 1523 Fax: +1 425 936 7329 1525 Appendix A - Changes from RFC 3576 1527 This Appendix lists the major changes between [RFC3576] and this 1528 document. Minor changes, including style, grammar, spelling, and 1529 editorial changes are not mentioned here. 1531 o Defined the Nonce Attribute for replay protection when IPsec is not 1532 used and the Event-Timestamp Attribute is not present (Sections 1, 1533 3.3, 6.4). 1535 o Added details relating to handling of the Proxy-State Attribute 1536 (Section 2.3). 1538 o Added requirements for inclusion of the State Attribute in CoA- 1539 Request or Disconnect-Request packets with a Service-Type of 1540 "Authorize Only" (Section 3.1). 1542 o Use of a Service-Type value of "Authorize Only" within a 1543 Disconnect-Request (Section 3.1) is not recommended. 1545 o Added clarification on the calculation of the Message-Authenticator 1546 Attribute (Section 3.2) 1548 o Added Diameter Considerations (Section 5). 1550 Intellectual Property Statement 1552 The IETF takes no position regarding the validity or scope of any 1553 Intellectual Property Rights or other rights that might be claimed to 1554 pertain to the implementation or use of the technology described in 1555 this document or the extent to which any license under such rights 1556 might or might not be available; nor does it represent that it has 1557 made any independent effort to identify any such rights. Information 1558 on the procedures with respect to rights in RFC documents can be 1559 found in BCP 78 and BCP 79. 1561 Copies of IPR disclosures made to the IETF Secretariat and any 1562 assurances of licenses to be made available, or the result of an 1563 attempt made to obtain a general license or permission for the use of 1564 such proprietary rights by implementers or users of this 1565 specification can be obtained from the IETF on-line IPR repository at 1566 http://www.ietf.org/ipr. 1568 The IETF invites any interested party to bring to its attention any 1569 copyrights, patents or patent applications, or other proprietary 1570 rights that may cover technology that may be required to implement 1571 this standard. Please address the information to the IETF at ietf- 1572 ipr@ietf.org. 1574 Disclaimer of Validity 1576 This document and the information contained herein are provided on an 1577 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1578 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1579 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1580 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1581 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1582 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1584 Copyright Statement 1586 Copyright (C) The IETF Trust (2007). This document is subject to the 1587 rights, licenses and restrictions contained in BCP 78, and except as 1588 set forth therein, the authors retain all their rights. 1590 Acknowledgment 1592 Funding for the RFC Editor function is currently provided by the 1593 Internet Society. 1595 Open issues 1597 Open issues relating to this specification are tracked on the 1598 following web site: 1600 http://www.drizzle.com/~aboba/RADEXT/