diff options
Diffstat (limited to 'doc/rfc3576.txt')
| -rw-r--r-- | doc/rfc3576.txt | 1683 |
1 files changed, 0 insertions, 1683 deletions
diff --git a/doc/rfc3576.txt b/doc/rfc3576.txt deleted file mode 100644 index 89fd9eb9..00000000 --- a/doc/rfc3576.txt +++ /dev/null @@ -1,1683 +0,0 @@ - - - - - - -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] - |