diff options
Diffstat (limited to 'rfc/rfc3576.txt')
| -rw-r--r-- | rfc/rfc3576.txt | 1683 |
1 files changed, 1683 insertions, 0 deletions
diff --git a/rfc/rfc3576.txt b/rfc/rfc3576.txt new file mode 100644 index 0000000..89fd9eb --- /dev/null +++ b/rfc/rfc3576.txt @@ -0,0 +1,1683 @@ + + + + + + +Network Working Group M. Chiba +Request for Comments: 3576 G. Dommety +Category: Informational M. Eklund + Cisco Systems, Inc. + D. Mitton + Circular Logic, UnLtd. + B. Aboba + Microsoft Corporation + July 2003 + + + Dynamic Authorization Extensions to Remote + Authentication Dial In User Service (RADIUS) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document describes a currently deployed extension to the Remote + Authentication Dial In User Service (RADIUS) protocol, allowing + dynamic changes to a user session, as implemented by network access + server products. This includes support for disconnecting users and + changing authorizations applicable to a user session. + + + + + + + + + + + + + + + + + + + + +Chiba, et al. Informational [Page 1] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Applicability. . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Requirements Language . . . . . . . . . . . . . . . . . 5 + 1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Disconnect Messages (DM) . . . . . . . . . . . . . . . . 5 + 2.2. Change-of-Authorization Messages (CoA) . . . . . . . . . 6 + 2.3. Packet Format. . . . . . . . . . . . . . . . . . . . . . 7 + 3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.1. Error-Cause. . . . . . . . . . . . . . . . . . . . . . . 13 + 3.2. Table of Attributes. . . . . . . . . . . . . . . . . . . 16 + 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20 + 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 21 + 5.1. Authorization Issues . . . . . . . . . . . . . . . . . . 21 + 5.2. Impersonation. . . . . . . . . . . . . . . . . . . . . . 22 + 5.3. IPsec Usage Guidelines . . . . . . . . . . . . . . . . . 22 + 5.4. Replay Protection. . . . . . . . . . . . . . . . . . . . 25 + 6. Example Traces . . . . . . . . . . . . . . . . . . . . . . . . 26 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 26 + 7.2. Informative References . . . . . . . . . . . . . . . . . 27 + 8. Intellectual Property Statement. . . . . . . . . . . . . . . . 28 + 9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 28 + 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 + 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30 + + + + + + + + + + + + + + + + + + + + + + + + +Chiba, et al. Informational [Page 2] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +1. Introduction + + The RADIUS protocol, defined in [RFC2865], does not support + unsolicited messages sent from the RADIUS server to the Network + Access Server (NAS). + + However, there are many instances in which it is desirable for + changes to be made to session characteristics, without requiring the + NAS to initiate the exchange. For example, it may be desirable for + administrators to be able to terminate a user session in progress. + Alternatively, if the user changes authorization level, this may + require that authorization attributes be added/deleted from a user + session. + + To overcome these limitations, several vendors have implemented + additional RADIUS commands in order to be able to support unsolicited + messages sent from the RADIUS server to the NAS. These extended + commands provide support for Disconnect and Change-of-Authorization + (CoA) messages. Disconnect messages cause a user session to be + terminated immediately, whereas CoA messages modify session + authorization attributes such as data filters. + +1.1. Applicability + + This protocol is being recommended for publication as an + Informational RFC rather than as a standards-track RFC because of + problems that cannot be fixed without creating incompatibilities with + deployed implementations. This includes security vulnerabilities, as + well as semantic ambiguities resulting from the design of the + Change-of-Authorization (CoA) commands. While fixes are recommended, + they cannot be made mandatory since this would be incompatible with + existing implementations. + + Existing implementations of this protocol do not support + authorization checks, so that an ISP sharing a NAS with another ISP + could disconnect or change authorizations for another ISP's users. + In order to remedy this problem, a "Reverse Path Forwarding" check is + recommended. See Section 5.1. for details. + + Existing implementations utilize per-packet authentication and + integrity protection algorithms with known weaknesses [MD5Attack]. + To provide stronger per-packet authentication and integrity + protection, the use of IPsec is recommended. See Section 5.3. for + details. + + + + + + + +Chiba, et al. Informational [Page 3] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Existing implementations lack replay protection. In order to support + replay detection, it is recommended that the Event-Timestamp + Attribute be added to all messages in situations where IPsec replay + protection is not employed. Implementations should be configurable + to silently discard messages lacking the Event-Timestamp Attribute. + See Section 5.4. for details. + + The approach taken with CoA commands in existing implementations + results in a semantic ambiguity. Existing implementations of the + CoA-Request identify the affected session, as well as supply the + authorization changes. Since RADIUS Attributes included within + existing implementations of the CoA-Request can be used for session + identification or authorization change, it may not be clear which + function a given attribute is serving. + + The problem does not exist within [Diameter], in which authorization + change is requested by a command using Attribute Value Pairs (AVPs) + solely for identification, resulting in initiation of a standard + Request/Response sequence where authorization changes are supplied. + As a result, in no command can Diameter AVPs have multiple potential + meanings. + + Due to differences in handling change-of-authorization requests in + RADIUS and Diameter, it may be difficult or impossible for a + Diameter/RADIUS gateway to successfully translate existing + implementations of this specification to equivalent messages in + Diameter. For example, a Diameter command changing any attribute + used for identification within existing CoA-Request implementations + cannot be translated, since such an authorization change is + impossible to carry out in existing implementations. Similarly, + translation between existing implementations of Disconnect-Request or + CoA-Request messages and Diameter is tricky because a Disconnect- + Request or CoA-Request message will need to be translated to multiple + Diameter commands. + + To simplify translation between RADIUS and Diameter, a Service-Type + Attribute with value "Authorize Only" can (optionally) be included + within a Disconnect-Request or CoA-Request. Such a Request contains + only identification attributes. A NAS supporting the "Authorize + Only" Service-Type within a Disconnect-Request or CoA-Request + responds with a NAK containing a Service-Type Attribute with value + "Authorize Only" and an Error-Cause Attribute with value "Request + Initiated". The NAS will then send an Access-Request containing a + Service-Type Attribute with a value of "Authorize Only". This usage + sequence is akin to what occurs in Diameter and so is more easily + translated by a Diameter/RADIUS gateway. + + + + + +Chiba, et al. Informational [Page 4] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +1.2. Requirements Language + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. The key + words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document + are to be interpreted as described in [RFC2119]. + +1.3. Terminology + + This document frequently uses the following terms: + + Network Access Server (NAS): The device providing access to the + network. + + service: The NAS provides a service to the user, + such as IEEE 802 or PPP. + + session: Each service provided by the NAS to a + user constitutes a session, with the + beginning of the session defined as the + point where service is first provided + and the end of the session defined as + the point where service is ended. A + user may have multiple sessions in + parallel or series if the NAS supports + that. + + silently discard: This means the implementation discards + the packet without further processing. + The implementation SHOULD provide the + capability of logging the error, + including the contents of the silently + discarded packet, and SHOULD record the + event in a statistics counter. + +2. Overview + + This section describes the most commonly implemented features of + Disconnect and Change-of-Authorization messages. + +2.1. Disconnect Messages (DM) + + A Disconnect-Request packet is sent by the RADIUS server in order to + terminate a user session on a NAS and discard all associated session + context. The Disconnect-Request packet is sent to UDP port 3799, and + identifies the NAS as well as the user session to be terminated by + inclusion of the identification attributes described in Section 3. + + + +Chiba, et al. Informational [Page 5] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + +----------+ Disconnect-Request +----------+ + | | <-------------------- | | + | NAS | | RADIUS | + | | Disconnect-Response | Server | + | | ---------------------> | | + +----------+ +----------+ + + The NAS responds to a Disconnect-Request packet sent by a RADIUS + server with a Disconnect-ACK if all associated session context is + discarded and the user session is no longer connected, or a + Disconnect-NAK, if the NAS was unable to disconnect the session and + discard all associated session context. A NAS MUST respond to a + Disconnect-Request including a Service-Type Attribute with value + "Authorize Only" with a Disconnect-NAK; a Disconnect-ACK MUST NOT be + sent. A NAS MUST respond to a Disconnect-Request including a + Service-Type Attribute with an unsupported value with a Disconnect- + NAK; an Error-Cause Attribute with value "Unsupported Service" MAY be + included. A Disconnect-ACK MAY contain the Attribute + Acct-Terminate-Cause (49) [RFC2866] with the value set to 6 for + Admin-Reset. + +2.2. Change-of-Authorization Messages (CoA) + + CoA-Request packets contain information for dynamically changing + session authorizations. This is typically used to change data + filters. The data filters can be of either the ingress or egress + kind, and are sent in addition to the identification attributes as + described in section 3. The port used, and packet format (described + in Section 2.3.), are the same as that for Disconnect-Request + Messages. + + The following attribute MAY be sent in a CoA-Request: + + Filter-ID (11) - Indicates the name of a data filter list to be + applied for the session that the identification + attributes map to. + + +----------+ CoA-Request +----------+ + | | <-------------------- | | + | NAS | | RADIUS | + | | CoA-Response | Server | + | | ---------------------> | | + +----------+ +----------+ + + The NAS responds to a CoA-Request sent by a RADIUS server with a + CoA-ACK if the NAS is able to successfully change the authorizations + for the user session, or a CoA-NAK if the Request is unsuccessful. A + NAS MUST respond to a CoA-Request including a Service-Type Attribute + + + +Chiba, et al. Informational [Page 6] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST NOT be + sent. A NAS MUST respond to a CoA-Request including a Service-Type + Attribute with an unsupported value with a CoA-NAK; an Error-Cause + Attribute with value "Unsupported Service" MAY be included. + +2.3. Packet Format + + For either Disconnect-Request or CoA-Request messages UDP port 3799 + is used as the destination port. For responses, the source and + destination ports are reversed. Exactly one RADIUS packet is + encapsulated in the UDP Data field. + + A summary of the data format is shown below. The fields are + transmitted from left to right. + + The packet format consists of the fields: Code, Identifier, Length, + Authenticator, and Attributes in Type:Length:Value (TLV) format. All + fields hold the same meaning as those described in RADIUS [RFC2865]. + The Authenticator field MUST be calculated in the same way as is + specified for an Accounting-Request in [RFC2866]. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + The Code field is one octet, and identifies the type of RADIUS + packet. Packets received with an invalid Code field MUST be + silently discarded. RADIUS codes (decimal) for this extension are + assigned as follows: + + 40 - Disconnect-Request [RFC2882] + 41 - Disconnect-ACK [RFC2882] + 42 - Disconnect-NAK [RFC2882] + 43 - CoA-Request [RFC2882] + 44 - CoA-ACK [RFC2882] + 45 - CoA-NAK [RFC2882] + + + + +Chiba, et al. Informational [Page 7] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Identifier + + The Identifier field is one octet, and aids in matching requests + and replies. The RADIUS client can detect a duplicate request if + it has the same server source IP address and source UDP port and + Identifier within a short span of time. + + Unlike RADIUS as defined in [RFC2865], the responsibility for + retransmission of Disconnect-Request and CoA-Request messages lies + with the RADIUS server. If after sending these messages, the + RADIUS server does not receive a response, it will retransmit. + + The Identifier field MUST be changed whenever the content of the + Attributes field changes, or whenever a valid reply has been + received for a previous request. For retransmissions where the + contents are identical, the Identifier MUST remain unchanged. + + If the RADIUS server is retransmitting a Disconnect-Request or + CoA-Request to the same client as before, and the Attributes have + not changed, the same Request Authenticator, Identifier and source + port MUST be used. If any Attributes have changed, a new + Authenticator and Identifier MUST be used. + + Note that if the Event-Timestamp Attribute is included, it will be + updated when the packet is retransmitted, changing the content of + the Attributes field and requiring a new Identifier and Request + Authenticator. + + If the Request to a primary proxy fails, a secondary proxy must be + queried, if available. Issues relating to failover algorithms are + described in [AAATransport]. Since this represents a new request, + a new Request Authenticator and Identifier MUST be used. However, + where the RADIUS server is sending directly to the client, + failover typically does not make sense, since Disconnect or CoA + messages need to be delivered to the NAS where the session + resides. + + Length + + The Length field is two octets. It indicates the length of the + packet including the Code, Identifier, Length, Authenticator and + Attribute fields. Octets outside the range of the Length field + MUST be treated as padding and ignored on reception. If the + packet is shorter than the Length field indicates, it MUST be + silently discarded. The minimum length is 20 and the maximum + length is 4096. + + + + + +Chiba, et al. Informational [Page 8] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Authenticator + + The Authenticator field is sixteen (16) octets. The most + significant octet is transmitted first. This value is used to + authenticate the messages between the RADIUS server and client. + + Request Authenticator + + In Request packets, the Authenticator value is a 16 octet MD5 + [RFC1321] checksum, called the Request Authenticator. The Request + Authenticator is calculated the same way as for an Accounting- + Request, specified in [RFC2866]. + + Note that the Request Authenticator of a Disconnect or CoA-Request + cannot be done the same way as the Request Authenticator of a + RADIUS Access-Request, because there is no User-Password Attribute + in a Disconnect-Request or CoA-Request. + + Response Authenticator + + The Authenticator field in a Response packet (e.g. Disconnect-ACK, + Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the Response + Authenticator, and contains a one-way MD5 hash calculated over a + stream of octets consisting of the Code, Identifier, Length, the + Request Authenticator field from the packet being replied to, and + the response Attributes if any, followed by the shared secret. + The resulting 16 octet MD5 hash value is stored in the + Authenticator field of the Response packet. + + Administrative note: As noted in [RFC2865] Section 3, the secret + (password shared between the client and the RADIUS server) SHOULD be + at least as large and unguessable as a well-chosen password. RADIUS + clients MUST use the source IP address of the RADIUS UDP packet to + decide which shared secret to use, so that requests can be proxied. + + Attributes + + In Disconnect and CoA-Request messages, all Attributes are treated + as mandatory. A NAS MUST respond to a CoA-Request containing one + or more unsupported Attributes or Attribute values with a CoA-NAK; + a Disconnect-Request containing one or more unsupported Attributes + or Attribute values MUST be answered with a Disconnect-NAK. State + changes resulting from a CoA-Request MUST be atomic: if the + Request is successful, a CoA-ACK is sent, and all requested + authorization changes MUST be made. If the CoA-Request is + unsuccessful, a CoA-NAK MUST be sent, and the requested + + + + + +Chiba, et al. Informational [Page 9] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + authorization changes MUST NOT be made. Similarly, a state change + MUST NOT occur as a result of an unsuccessful Disconnect-Request; + here a Disconnect-NAK MUST be sent. + + Since within this specification attributes may be used for + identification, authorization or other purposes, even if a NAS + implements an attribute for use with RADIUS authentication and + accounting, it may not support inclusion of that attribute within + Disconnect-Request or CoA-Request messages, given the difference + in attribute semantics. This is true even for attributes + specified within [RFC2865], [RFC2868], [RFC2869] or [RFC3162] as + allowable within Access-Accept messages. + + As a result, attributes beyond those specified in Section 3.2. + SHOULD NOT be included within Disconnect or CoA messages since + this could produce unpredictable results. + + When using a forwarding proxy, the proxy must be able to alter the + packet as it passes through in each direction. When the proxy + forwards a Disconnect or CoA-Request, it MAY add a Proxy-State + Attribute, and when the proxy forwards a response, it MUST remove + its Proxy-State Attribute if it added one. Proxy-State is always + added or removed after any other Proxy-States, but no other + assumptions regarding its location within the list of Attributes + can be made. Since Disconnect and CoA responses are authenticated + on the entire packet contents, the stripping of the Proxy-State + Attribute invalidates the integrity check - so the proxy needs to + recompute it. A forwarding proxy MUST NOT modify existing Proxy- + State, State, or Class Attributes present in the packet. + + If there are any Proxy-State Attributes in a Disconnect-Request or + CoA-Request received from the server, the forwarding proxy MUST + include those Proxy-State Attributes in its response to the + server. The forwarding proxy MAY include the Proxy-State + Attributes in the Disconnect-Request or CoA-Request when it + forwards the request, or it MAY omit them in the forwarded + request. If the forwarding proxy omits the Proxy-State Attributes + in the request, it MUST attach them to the response before sending + it to the server. + + + + + + + + + + + + +Chiba, et al. Informational [Page 10] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +3. Attributes + + In Disconnect-Request and CoA-Request packets, certain attributes are + used to uniquely identify the NAS as well as a user session on the + NAS. All NAS identification attributes included in a Request message + MUST match in order for a Disconnect-Request or CoA-Request to be + successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent. + For session identification attributes, the User-Name and Acct- + Session-Id Attributes, if included, MUST match in order for a + Disconnect-Request or CoA-Request to be successful; other session + identification attributes SHOULD match. Where a mismatch of session + identification attributes is detected, a Disconnect-NAK or CoA-NAK + SHOULD be sent. The ability to use NAS or session identification + attributes to map to unique/multiple sessions is beyond the scope of + this document. Identification attributes include NAS and session + identification attributes, as described below. + + NAS identification attributes + + Attribute # Reference Description + --------- --- --------- ----------- + NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS. + NAS-Identifier 32 [RFC2865] String identifying the NAS. + NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Chiba, et al. Informational [Page 11] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Session identification attributes + + Attribute # Reference Description + --------- --- --------- ----------- + User-Name 1 [RFC2865] The name of the user + associated with the session. + NAS-Port 5 [RFC2865] The port on which the + session is terminated. + Framed-IP-Address 8 [RFC2865] The IPv4 address associated + with the session. + Called-Station-Id 30 [RFC2865] The link address to which + the session is connected. + Calling-Station-Id 31 [RFC2865] The link address from which + the session is connected. + Acct-Session-Id 44 [RFC2866] The identifier uniquely + identifying the session + on the NAS. + Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely + identifying related sessions. + NAS-Port-Type 61 [RFC2865] The type of port used. + NAS-Port-Id 87 [RFC2869] String identifying the port + where the session is. + Originating-Line-Info 94 [NASREQ] Provides information on the + characteristics of the line + from which a session + originated. + Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier + associated with the session; + always sent with + Framed-IPv6-Prefix. + Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated + with the session, always sent + with Framed-Interface-Id. + + To address security concerns described in Section 5.1., the User-Name + Attribute SHOULD be present in Disconnect-Request or CoA-Request + packets; one or more additional session identification attributes MAY + also be present. To address security concerns described in Section + 5.2., one or more of the NAS-IP-Address or NAS-IPv6-Address + Attributes SHOULD be present in Disconnect-Request or CoA-Request + packets; the NAS-Identifier Attribute MAY be present in addition. + + If one or more authorization changes specified in a CoA-Request + cannot be carried out, or if one or more attributes or attribute- + values is unsupported, a CoA-NAK MUST be sent. Similarly, if there + are one or more unsupported attributes or attribute values in a + Disconnect-Request, a Disconnect-NAK MUST be sent. + + + + +Chiba, et al. Informational [Page 12] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Where a Service-Type Attribute with value "Authorize Only" is + included within a CoA-Request or Disconnect-Request, attributes + representing an authorization change MUST NOT be included; only + identification attributes are permitted. If attributes other than + NAS or session identification attributes are included in such a CoA- + Request, implementations MUST send a CoA-NAK; an Error-Cause + Attribute with value "Unsupported Attribute" MAY be included. + Similarly, if attributes other than NAS or session identification + attributes are included in such a Disconnect-Request, implementations + MUST send a Disconnect-NAK; an Error-Cause Attribute with value + "Unsupported Attribute" MAY be included. + +3.1. Error-Cause + + Description + + It is possible that the NAS cannot honor Disconnect-Request or + CoA-Request messages for some reason. The Error-Cause Attribute + provides more detail on the cause of the problem. It MAY be + included within Disconnect-ACK, Disconnect-NAK and CoA-NAK + messages. + + A summary of the Error-Cause Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 101 for Error-Cause + + Length + + 6 + + Value + + The Value field is four octets, containing an integer specifying + the cause of the error. Values 0-199 and 300-399 are reserved. + Values 200-299 represent successful completion, so that these + values may only be sent within Disconnect-ACK or CoA-ACK message + and MUST NOT be sent within a Disconnect-NAK or CoA-NAK. Values + + + +Chiba, et al. Informational [Page 13] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + 400-499 represent fatal errors committed by the RADIUS server, so + that they MAY be sent within CoA-NAK or Disconnect-NAK messages, + and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages. + Values 500-599 represent fatal errors occurring on a NAS or RADIUS + proxy, so that they MAY be sent within CoA-NAK and Disconnect-NAK + messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK + messages. Error-Cause values SHOULD be logged by the RADIUS + server. Error-Code values (expressed in decimal) include: + + # Value + --- ----- + 201 Residual Session Context Removed + 202 Invalid EAP Packet (Ignored) + 401 Unsupported Attribute + 402 Missing Attribute + 403 NAS Identification Mismatch + 404 Invalid Request + 405 Unsupported Service + 406 Unsupported Extension + 501 Administratively Prohibited + 502 Request Not Routable (Proxy) + 503 Session Context Not Found + 504 Session Context Not Removable + 505 Other Proxy Processing Error + 506 Resources Unavailable + 507 Request Initiated + + "Residual Session Context Removed" is sent in response to a + Disconnect-Request if the user session is no longer active, but + residual session context was found and successfully removed. This + value is only sent within a Disconnect-ACK and MUST NOT be sent + within a CoA-ACK, Disconnect-NAK or CoA-NAK. + + "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be + sent by implementations of this specification. + + "Unsupported Attribute" is a fatal error sent if a Request contains + an attribute (such as a Vendor-Specific or EAP-Message Attribute) + that is not supported. + + "Missing Attribute" is a fatal error sent if critical attributes + (such as NAS or session identification attributes) are missing from a + Request. + + "NAS Identification Mismatch" is a fatal error sent if one or more + NAS identification attributes (see Section 3.) do not match the + identity of the NAS receiving the Request. + + + + +Chiba, et al. Informational [Page 14] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + "Invalid Request" is a fatal error sent if some other aspect of the + Request is invalid, such as if one or more attributes (such as EAP- + Message Attribute(s)) are not formatted properly. + + "Unsupported Service" is a fatal error sent if a Service-Type + Attribute included with the Request is sent with an invalid or + unsupported value. + + "Unsupported Extension" is a fatal error sent due to lack of support + for an extension such as Disconnect and/or CoA messages. This will + typically be sent by a proxy receiving an ICMP port unreachable + message after attempting to forward a Request to the NAS. + + "Administratively Prohibited" is a fatal error sent if the NAS is + configured to prohibit honoring of Request messages for the specified + session. + + "Request Not Routable" is a fatal error which MAY be sent by a RADIUS + proxy and MUST NOT be sent by a NAS. It indicates that the RADIUS + proxy was unable to determine how to route the Request to the NAS. + For example, this can occur if the required entries are not present + in the proxy's realm routing table. + + "Session Context Not Found" is a fatal error sent if the session + context identified in the Request does not exist on the NAS. + + "Session Context Not Removable" is a fatal error sent in response to + a Disconnect-Request if the NAS was able to locate the session + context, but could not remove it for some reason. It MUST NOT be + sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a + Disconnect-NAK. + + "Other Proxy Processing Error" is a fatal error sent in response to a + Request that could not be processed by a proxy, for reasons other + than routing. + + "Resources Unavailable" is a fatal error sent when a Request could + not be honored due to lack of available NAS resources (memory, non- + volatile storage, etc.). + + "Request Initiated" is a fatal error sent in response to a Request + including a Service-Type Attribute with a value of "Authorize Only". + It indicates that the Disconnect-Request or CoA-Request has not been + honored, but that a RADIUS Access-Request including a Service-Type + Attribute with value "Authorize Only" is being sent to the RADIUS + server. + + + + + +Chiba, et al. Informational [Page 15] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +3.2. Table of Attributes + + The following table provides a guide to which attributes may be found + in which packets, and in what quantity. + + Change-of-Authorization Messages + + Request ACK NAK # Attribute + 0-1 0 0 1 User-Name [Note 1] + 0-1 0 0 4 NAS-IP-Address [Note 1] + 0-1 0 0 5 NAS-Port [Note 1] + 0-1 0 0-1 6 Service-Type [Note 6] + 0-1 0 0 7 Framed-Protocol [Note 3] + 0-1 0 0 8 Framed-IP-Address [Note 1] + 0-1 0 0 9 Framed-IP-Netmask [Note 3] + 0-1 0 0 10 Framed-Routing [Note 3] + 0+ 0 0 11 Filter-ID [Note 3] + 0-1 0 0 12 Framed-MTU [Note 3] + 0+ 0 0 13 Framed-Compression [Note 3] + 0+ 0 0 14 Login-IP-Host [Note 3] + 0-1 0 0 15 Login-Service [Note 3] + 0-1 0 0 16 Login-TCP-Port [Note 3] + 0+ 0 0 18 Reply-Message [Note 2] + 0-1 0 0 19 Callback-Number [Note 3] + 0-1 0 0 20 Callback-Id [Note 3] + 0+ 0 0 22 Framed-Route [Note 3] + 0-1 0 0 23 Framed-IPX-Network [Note 3] + 0-1 0-1 0-1 24 State [Note 7] + 0+ 0 0 25 Class [Note 3] + 0+ 0 0 26 Vendor-Specific [Note 3] + 0-1 0 0 27 Session-Timeout [Note 3] + 0-1 0 0 28 Idle-Timeout [Note 3] + 0-1 0 0 29 Termination-Action [Note 3] + 0-1 0 0 30 Called-Station-Id [Note 1] + 0-1 0 0 31 Calling-Station-Id [Note 1] + 0-1 0 0 32 NAS-Identifier [Note 1] + 0+ 0+ 0+ 33 Proxy-State + 0-1 0 0 34 Login-LAT-Service [Note 3] + 0-1 0 0 35 Login-LAT-Node [Note 3] + 0-1 0 0 36 Login-LAT-Group [Note 3] + 0-1 0 0 37 Framed-AppleTalk-Link [Note 3] + 0+ 0 0 38 Framed-AppleTalk-Network [Note 3] + 0-1 0 0 39 Framed-AppleTalk-Zone [Note 3] + 0-1 0 0 44 Acct-Session-Id [Note 1] + 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] + 0-1 0-1 0-1 55 Event-Timestamp + 0-1 0 0 61 NAS-Port-Type [Note 1] + Request ACK NAK # Attribute + + + +Chiba, et al. Informational [Page 16] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Request ACK NAK # Attribute + 0-1 0 0 62 Port-Limit [Note 3] + 0-1 0 0 63 Login-LAT-Port [Note 3] + 0+ 0 0 64 Tunnel-Type [Note 5] + 0+ 0 0 65 Tunnel-Medium-Type [Note 5] + 0+ 0 0 66 Tunnel-Client-Endpoint [Note 5] + 0+ 0 0 67 Tunnel-Server-Endpoint [Note 5] + 0+ 0 0 69 Tunnel-Password [Note 5] + 0-1 0 0 71 ARAP-Features [Note 3] + 0-1 0 0 72 ARAP-Zone-Access [Note 3] + 0+ 0 0 78 Configuration-Token [Note 3] + 0+ 0-1 0 79 EAP-Message [Note 2] + 0-1 0-1 0-1 80 Message-Authenticator + 0+ 0 0 81 Tunnel-Private-Group-ID [Note 5] + 0+ 0 0 82 Tunnel-Assignment-ID [Note 5] + 0+ 0 0 83 Tunnel-Preference [Note 5] + 0-1 0 0 85 Acct-Interim-Interval [Note 3] + 0-1 0 0 87 NAS-Port-Id [Note 1] + 0-1 0 0 88 Framed-Pool [Note 3] + 0+ 0 0 90 Tunnel-Client-Auth-ID [Note 5] + 0+ 0 0 91 Tunnel-Server-Auth-ID [Note 5] + 0-1 0 0 94 Originating-Line-Info [Note 1] + 0-1 0 0 95 NAS-IPv6-Address [Note 1] + 0-1 0 0 96 Framed-Interface-Id [Note 1] + 0+ 0 0 97 Framed-IPv6-Prefix [Note 1] + 0+ 0 0 98 Login-IPv6-Host [Note 3] + 0+ 0 0 99 Framed-IPv6-Route [Note 3] + 0-1 0 0 100 Framed-IPv6-Pool [Note 3] + 0 0 0+ 101 Error-Cause + Request ACK NAK # Attribute + + Disconnect Messages + + Request ACK NAK # Attribute + 0-1 0 0 1 User-Name [Note 1] + 0-1 0 0 4 NAS-IP-Address [Note 1] + 0-1 0 0 5 NAS-Port [Note 1] + 0-1 0 0-1 6 Service-Type [Note 6] + 0-1 0 0 8 Framed-IP-Address [Note 1] + 0+ 0 0 18 Reply-Message [Note 2] + 0-1 0-1 0-1 24 State [Note 7] + 0+ 0 0 25 Class [Note 4] + 0+ 0 0 26 Vendor-Specific + 0-1 0 0 30 Called-Station-Id [Note 1] + 0-1 0 0 31 Calling-Station-Id [Note 1] + 0-1 0 0 32 NAS-Identifier [Note 1] + 0+ 0+ 0+ 33 Proxy-State + Request ACK NAK # Attribute + + + +Chiba, et al. Informational [Page 17] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Request ACK NAK # Attribute + 0-1 0 0 44 Acct-Session-Id [Note 1] + 0-1 0-1 0 49 Acct-Terminate-Cause + 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] + 0-1 0-1 0-1 55 Event-Timestamp + 0-1 0 0 61 NAS-Port-Type [Note 1] + 0+ 0-1 0 79 EAP-Message [Note 2] + 0-1 0-1 0-1 80 Message-Authenticator + 0-1 0 0 87 NAS-Port-Id [Note 1] + 0-1 0 0 94 Originating-Line-Info [Note 1] + 0-1 0 0 95 NAS-IPv6-Address [Note 1] + 0-1 0 0 96 Framed-Interface-Id [Note 1] + 0+ 0 0 97 Framed-IPv6-Prefix [Note 1] + 0 0+ 0+ 101 Error-Cause + Request ACK NAK # Attribute + + [Note 1] Where NAS or session identification attributes are included + in Disconnect-Request or CoA-Request messages, they are used for + identification purposes only. These attributes MUST NOT be used for + purposes other than identification (e.g. within CoA-Request messages + to request authorization changes). + + [Note 2] The Reply-Message Attribute is used to present a displayable + message to the user. The message is only displayed as a result of a + successful Disconnect-Request or CoA-Request (where a Disconnect-ACK + or CoA-ACK is subsequently sent). Where EAP is used for + authentication, an EAP-Message/Notification-Request Attribute is sent + instead, and Disconnect-ACK or CoA-ACK messages contain an EAP- + Message/Notification-Response Attribute. + + [Note 3] When included within a CoA-Request, these attributes + represent an authorization change request. When one of these + attributes is omitted from a CoA-Request, the NAS assumes that the + attribute value is to remain unchanged. Attributes included in a + CoA-Request replace all existing value(s) of the same attribute(s). + + [Note 4] When included within a successful Disconnect-Request (where + a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be + sent unmodified by the client to the accounting server in the + Accounting Stop packet. If the Disconnect-Request is unsuccessful, + then the Class Attribute is not processed. + + [Note 5] When included within a CoA-Request, these attributes + represent an authorization change request. Where tunnel attribute(s) + are sent within a successful CoA-Request, all existing tunnel + attributes are removed and replaced by the new attribute(s). + + + + + +Chiba, et al. Informational [Page 18] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + [Note 6] When included within a Disconnect-Request or CoA-Request, a + Service-Type Attribute with value "Authorize Only" indicates that the + Request only contains NAS and session identification attributes, and + that the NAS should attempt reauthorization by sending an Access- + Request with a Service-Type Attribute with value "Authorize Only". + This enables a usage model akin to that supported in Diameter, thus + easing translation between the two protocols. Support for the + Service-Type Attribute is optional within CoA-Request and + Disconnect-Request messages; where it is not included, the Request + message may contain both identification and authorization attributes. + A NAS that does not support the Service-Type Attribute with the value + "Authorize Only" within a Disconnect-Request MUST respond with a + Disconnect-NAK including no Service-Type Attribute; an Error-Cause + Attribute with value "Unsupported Service" MAY be included. A NAS + that does not support the Service-Type Attribute with the value + "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK + including no Service-Type Attribute; an Error-Cause Attribute with + value "Unsupported Service" MAY be included. + + A NAS supporting the "Authorize Only" Service-Type value within + Disconnect-Request or CoA-Request messages MUST respond with a + Disconnect-NAK or CoA-NAK respectively, containing a Service-Type + Attribute with value "Authorize Only", and an Error-Cause Attribute + with value "Request Initiated". The NAS then sends an Access-Request + to the RADIUS server with a Service-Type Attribute with value + "Authorize Only". This Access-Request SHOULD contain the NAS + attributes from the Disconnect or CoA-Request, as well as the session + attributes from the Request legal for inclusion in an Access-Request + as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As + noted in [RFC2869] Section 5.19, a Message-Authenticator attribute + SHOULD be included in an Access-Request that does not contain a + User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. + The RADIUS server should send back an Access-Accept to (re-)authorize + the session or an Access-Reject to refuse to (re-)authorize it. + + [Note 7] The State Attribute is available to be sent by the RADIUS + server to the NAS in a Disconnect-Request or CoA-Request message and + MUST be sent unmodified from the NAS to the RADIUS server in a + subsequent ACK or NAK message. If a Service-Type Attribute with + value "Authorize Only" is included in a Disconnect-Request or CoA- + Request along with a State Attribute, then the State Attribute MUST + be sent unmodified from the NAS to the RADIUS server in the resulting + Access-Request sent to the RADIUS server, if any. The State + Attribute is also available to be sent by the RADIUS server to the + NAS in a CoA-Request that also includes a Termination-Action + Attribute with the value of RADIUS-Request. If the client performs + the Termination-Action by sending a new Access-Request upon + termination of the current session, it MUST include the State + + + +Chiba, et al. Informational [Page 19] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Attribute unchanged in that Access-Request. In either usage, the + client MUST NOT interpret the Attribute locally. A Disconnect- + Request or CoA-Request packet must have only zero or one State + Attribute. Usage of the State Attribute is implementation dependent. + If the RADIUS server does not recognize the State Attribute in the + Access-Request, then it MUST send an Access-Reject. + + The following table defines the meaning of the above table entries. + + 0 This attribute MUST NOT be present in packet. + 0+ Zero or more instances of this attribute MAY be present in + packet. + 0-1 Zero or one instance of this attribute MAY be present in packet. + 1 Exactly one instance of this attribute MUST be present in packet. + +4. IANA Considerations + + This document uses the RADIUS [RFC2865] namespace, see + <http://www.iana.org/assignments/radius-types>. There are six + updates for the section: RADIUS Packet Type Codes. These Packet + Types are allocated in [RADIANA]: + + 40 - Disconnect-Request + 41 - Disconnect-ACK + 42 - Disconnect-NAK + 43 - CoA-Request + 44 - CoA-ACK + 45 - CoA-NAK + + Allocation of a new Service-Type value for "Authorize Only" is + requested. This document also uses the UDP [RFC768] namespace, see + <http://www.iana.org/assignments/port-numbers>. The authors request + a port assignment from the Registered ports range. Finally, this + specification allocates the Error-Cause Attribute (101) with the + following decimal values: + + # Value + --- ----- + 201 Residual Session Context Removed + 202 Invalid EAP Packet (Ignored) + 401 Unsupported Attribute + 402 Missing Attribute + 403 NAS Identification Mismatch + 404 Invalid Request + 405 Unsupported Service + 406 Unsupported Extension + 501 Administratively Prohibited + 502 Request Not Routable (Proxy) + + + +Chiba, et al. Informational [Page 20] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + 503 Session Context Not Found + 504 Session Context Not Removable + 505 Other Proxy Processing Error + 506 Resources Unavailable + 507 Request Initiated + +5. Security Considerations + +5.1. Authorization Issues + + Where a NAS is shared by multiple providers, it is undesirable for + one provider to be able to send Disconnect-Request or CoA-Requests + affecting the sessions of another provider. + + A NAS or RADIUS proxy MUST silently discard Disconnect-Request or + CoA-Request messages from untrusted sources. By default, a RADIUS + proxy SHOULD perform a "reverse path forwarding" (RPF) check to + verify that a Disconnect-Request or CoA-Request originates from an + authorized RADIUS server. In addition, it SHOULD be possible to + explicitly authorize additional sources of Disconnect-Request or + CoA-Request packets relating to certain classes of sessions. For + example, a particular source can be explicitly authorized to send + CoA-Request messages relating to users within a set of realms. + + To perform the RPF check, the proxy uses the session identification + attributes included in Disconnect-Request or CoA-Request messages, in + order to determine the RADIUS server(s) to which an equivalent + Access-Request could be routed. If the source address of the + Disconnect-Request or CoA-Request is within this set, then the + Request is forwarded; otherwise it MUST be silently discarded. + + Typically the proxy will extract the realm from the Network Access + Identifier [RFC2486] included within the User-Name Attribute, and + determine the corresponding RADIUS servers in the proxy routing + tables. The RADIUS servers for that realm are then compared against + the source address of the packet. Where no RADIUS proxy is present, + the RPF check will need to be performed by the NAS itself. + + Since authorization to send a Disconnect-Request or CoA-Request is + determined based on the source address and the corresponding shared + secret, the NASes or proxies SHOULD configure a different shared + secret for each RADIUS server. + + + + + + + + + +Chiba, et al. Informational [Page 21] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +5.2. Impersonation + + [RFC2865] Section 3 states: + + A RADIUS server MUST use the source IP address of the RADIUS UDP + packet to decide which shared secret to use, so that RADIUS + requests can be proxied. + + When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or + NAS-IPv6-Address Attributes will typically not match the source + address observed by the RADIUS server. Since the NAS-Identifier + Attribute need not contain an FQDN, this attribute may not be + resolvable to the source address observed by the RADIUS server, even + when no proxy is present. + + As a result, the authenticity check performed by a RADIUS server or + proxy does not verify the correctness of NAS identification + attributes. This makes it possible for a rogue NAS to forge NAS-IP- + Address, NAS-IPv6-Address or NAS-Identifier Attributes within a + RADIUS Access-Request in order to impersonate another NAS. It is + also possible for a rogue NAS to forge session identification + attributes such as the Called-Station-Id, Calling-Station-Id, or + Originating-Line-Info [NASREQ]. This could fool the RADIUS server + into sending Disconnect-Request or CoA-Request messages containing + forged session identification attributes to a NAS targeted by an + attacker. + + To address these vulnerabilities RADIUS proxies SHOULD check whether + NAS identification attributes (see Section 3.) match the source + address of packets originating from the NAS. Where one or more + attributes do not match, Disconnect-Request or CoA-Request messages + SHOULD be silently discarded. + + Such a check may not always be possible. Since the NAS-Identifier + Attribute need not correspond to an FQDN, it may not be resolvable to + an IP address to be matched against the source address. Also, where + a NAT exists between the RADIUS client and proxy, checking the NAS- + IP-Address or NAS-IPv6-Address Attributes may not be feasible. + +5.3. IPsec Usage Guidelines + + In addition to security vulnerabilities unique to Disconnect or CoA + messages, the protocol exchanges described in this document are + susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is + RECOMMENDED that IPsec be employed to afford better security. + + + + + + +Chiba, et al. Informational [Page 22] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Implementations of this specification SHOULD support IPsec [RFC2401] + along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] + with a non-null transform SHOULD be supported, and IPsec ESP with a + non-null encryption transform and authentication support SHOULD be + used to provide per-packet confidentiality, authentication, integrity + and replay protection. IKE SHOULD be used for key management. + + Within RADIUS [RFC2865], a shared secret is used for hiding + Attributes such as User-Password, as well as used in computation of + the Response Authenticator. In RADIUS accounting [RFC2866], the + shared secret is used in computation of both the Request + Authenticator and the Response Authenticator. + + Since in RADIUS a shared secret is used to provide confidentiality as + well as integrity protection and authentication, only use of IPsec + ESP with a non-null transform can provide security services + sufficient to substitute for RADIUS application-layer security. + Therefore, where IPsec AH or ESP null is used, it will typically + still be necessary to configure a RADIUS shared secret. + + 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. + + When IPsec ESP is used with RADIUS, per-packet authentication, + integrity and replay protection MUST be used. 3DES-CBC MUST be + supported as an encryption transform and AES-CBC SHOULD be supported. + AES-CBC SHOULD be offered as a preferred encryption transform if + supported. HMAC-SHA1-96 MUST be supported as an authentication + transform. DES-CBC SHOULD NOT be used as the encryption transform. + + A typical IPsec policy for an IPsec-capable RADIUS client is + "Initiate IPsec, from me to any destination port UDP 1812". This + IPsec policy causes an IPsec SA to be set up by the RADIUS client + prior to sending RADIUS traffic. If some RADIUS servers contacted by + the client do not support IPsec, then a more granular policy will be + required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, + destination port UDP 1812." + + For a client implementing this specification, the policy would be + "Accept IPsec, from any to me, destination port UDP 3799". This + causes the RADIUS client to accept (but not require) use of IPsec. + It may not be appropriate to require IPsec for all RADIUS servers + connecting to an IPsec-enabled RADIUS client, since some RADIUS + servers may not support IPsec. + + + +Chiba, et al. Informational [Page 23] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept + IPsec, from any to me, destination port 1812". This causes the + RADIUS server to accept (but not require) use of IPsec. It may not + be appropriate to require IPsec for all RADIUS clients connecting to + an IPsec-enabled RADIUS server, since some RADIUS clients may not + support IPsec. + + For servers implementing this specification, the policy would be + "Initiate IPsec, from me to any, destination port UDP 3799". This + causes the RADIUS server to initiate IPsec when sending RADIUS + extension traffic to any RADIUS client. If some RADIUS clients + contacted by the server do not support IPsec, then a more granular + policy will be required, such as "Initiate IPsec, from me to IPsec- + capable-RADIUS-client, destination port UDP 3799". + + Where IPsec is used for security, and no RADIUS shared secret is + configured, it is important that the RADIUS client and server perform + an authorization check. Before enabling a host to act as a RADIUS + client, the RADIUS server SHOULD check whether the host is authorized + to provide network access. Similarly, before enabling a host to act + as a RADIUS server, the RADIUS client SHOULD check whether the host + is authorized for that role. + + RADIUS servers can be configured with the IP addresses (for IKE + Aggressive Mode with pre-shared keys) or FQDNs (for certificate + authentication) of RADIUS clients. Alternatively, if a separate + Certification Authority (CA) exists for RADIUS clients, then the + RADIUS server can configure this CA as a trust anchor [RFC3280] for + use with IPsec. + + Similarly, RADIUS clients can be configured with the IP addresses + (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for + certificate authentication) of RADIUS servers. Alternatively, if a + separate CA exists for RADIUS servers, then the RADIUS client can + configure this CA as a trust anchor for use with IPsec. + + Since unlike SSL/TLS, IKE does not permit certificate policies to be + set on a per-port basis, certificate policies need to apply to all + uses of IPsec on RADIUS clients and servers. In IPsec deployment + supporting only certificate authentication, a management station + initiating an IPsec-protected telnet session to the RADIUS server + would need to obtain a certificate chaining to the RADIUS client CA. + Issuing such a certificate might not be appropriate if the management + station was not authorized as a RADIUS client. + + Where RADIUS clients may obtain their IP address dynamically (such as + an Access Point supporting DHCP), Main Mode with pre-shared keys + [RFC2409] SHOULD NOT be used, since this requires use of a group + + + +Chiba, et al. Informational [Page 24] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + pre-shared key; instead, Aggressive Mode SHOULD be used. Where + RADIUS client addresses are statically assigned, either Aggressive + Mode or Main Mode MAY be used. With certificate authentication, Main + Mode SHOULD be used. + + Care needs to be taken with IKE Phase 1 Identity Payload selection in + order to enable mapping of identities to pre-shared keys, even with + Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity + Payloads are used and addresses are dynamically assigned, mapping of + identities to keys is not possible, so that group pre-shared keys are + still a practical necessity. As a result, the ID_FQDN identity + payload SHOULD be employed in situations where Aggressive mode is + utilized along with pre-shared keys and IP addresses are dynamically + assigned. This approach also has other advantages, since it allows + the RADIUS server and client to configure themselves based on the + fully qualified domain name of their peers. + + Note that with IPsec, security services are negotiated at the + granularity of an IPsec SA, so that RADIUS exchanges requiring a set + of security services different from those negotiated with existing + IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs + are also advisable where quality of service considerations dictate + different handling RADIUS conversations. Attempting to apply + different quality of service to connections handled by the same IPsec + SA can result in reordering, and falling outside the replay window. + For a discussion of the issues, see [RFC2983]. + +5.4. Replay Protection + + Where IPsec replay protection is not used, the Event-Timestamp (55) + Attribute [RFC2869] SHOULD be included within all messages. When + this attribute is present, both the NAS and the RADIUS server MUST + check that the Event-Timestamp Attribute is current within an + acceptable time window. If the Event-Timestamp Attribute is not + current, then the message MUST be silently discarded. This implies + the need for time synchronization within the network, which can be + achieved by a variety of means, including secure NTP, as described in + [NTPAUTH]. + + Both the NAS and the RADIUS server SHOULD be configurable to silently + discard messages lacking an Event-Timestamp Attribute. A default + time window of 300 seconds is recommended. + + + + + + + + + +Chiba, et al. Informational [Page 25] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +6. Example Traces + + Disconnect Request with User-Name: + + 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....# + 16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^.. + 32: 6d63 6869 6261 + + Disconnect Request with Acct-Session-ID: + + 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(..... + 16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,. + 32: 3930 3233 3435 3637 90234567 + + Disconnect Request with Framed-IP-Address: + + 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(..... + 16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ... + 32: 0a00 0203 + +7. References + +7.1. Normative References + + [RFC1305] Mills, D., "Network Time Protocol (version 3) + Specification, Implementation and Analysis", RFC 1305, + March 1992. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC + 1321, April 1992. + + [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for + the Internet Protocol", RFC 2401, November 1998. + + [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security + Payload (ESP)", RFC 2406, November 1998. + + [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + + + + + +Chiba, et al. Informational [Page 26] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, RFC + 2434, October 1998. + + [RFC2486] Aboba, B. and M. Beadles, "The Network Access + Identifier", RFC 2486, January 1999. + + [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000. + + [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. + + [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS + Extensions", RFC 2869, June 2000. + + [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", + RFC 3162, August 2001. + + [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [RADIANA] Aboba, B., "IANA Considerations for RADIUS (Remote + Authentication Dial In User Service)", RFC 3575, July + 2003. + +7.2. Informative References + + [RFC2882] Mitton, D., "Network Access Server Requirements: + Extended RADIUS Practices", RFC 2882, July 2000. + + [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC + 2983, October 2000. + + [AAATransport] Aboba, B. and J. Wood, "Authentication, Authorization + and Accounting (AAA) Transport Profile", RFC 3539, + June 2003. + + [Diameter] Calhoun, P., et al., "Diameter Base Protocol", Work in + Progress. + + [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent + Attack", CryptoBytes Vol.2 No.2, Summer 1996. + + [NASREQ] Calhoun, P., et al., "Diameter Network Access Server + Application", Work in Progress. + + + +Chiba, et al. Informational [Page 27] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + [NTPAUTH] Mills, D., "Public Key Cryptography for the Network + Time Protocol", Work in Progress. + +8. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards- related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementers or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +9. Acknowledgments + + This protocol was first developed and distributed by Ascend + Communications. Example code was distributed in their free server + kit. + + The authors would like to acknowledge the valuable suggestions and + feedback from the following people: + + Avi Lior <avi@bridgewatersystems.com>, + Randy Bush <randy@psg.net>, + Steve Bellovin <smb@research.att.com> + Glen Zorn <gwz@cisco.com>, + Mark Jones <mjones@bridgewatersystems.com>, + Claudio Lapidus <clapidus@hotmail.com>, + Anurag Batta <Anurag_Batta@3com.com>, + Kuntal Chowdhury <chowdury@nortelnetworks.com>, and + Tim Moore <timmoore@microsoft.com>. + Russ Housley <housley@vigilsec.com> + + + + + + + +Chiba, et al. Informational [Page 28] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +10. Authors' Addresses + + Murtaza Chiba + Cisco Systems, Inc. + 170 West Tasman Dr. + San Jose CA, 95134 + + EMail: mchiba@cisco.com + Phone: +1 408 525 7198 + + Gopal Dommety + Cisco Systems, Inc. + 170 West Tasman Dr. + San Jose, CA 95134 + + EMail: gdommety@cisco.com + Phone: +1 408 525 1404 + + Mark Eklund + Cisco Systems, Inc. + 170 West Tasman Dr. + San Jose, CA 95134 + + EMail: meklund@cisco.com + Phone: +1 865 671 6255 + + David Mitton + Circular Logic UnLtd. + 733 Turnpike Street #154 + North Andover, MA 01845 + + EMail: david@mitton.com + Phone: +1 978 683 1814 + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + EMail: bernarda@microsoft.com + Phone: +1 425 706 6605 + Fax: +1 425 936 7329 + + + + + + + + + +Chiba, et al. Informational [Page 29] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Chiba, et al. Informational [Page 30] + |