Network Working Group Murtaza S. Chiba INTERNET-DRAFT Gopal Dommety Category: Informational Mark Eklund Cisco Systems, Inc. 8 April 2003 David Mitton Circular Logic, UnLtd. Bernard Aboba Microsoft Corporation Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes a currently deployed extension to the 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] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 Table of Contents 1. Introduction .......................................... 3 1.1 Terminology ..................................... 3 1.2 Requirements language ........................... 3 2. Overview ............................................. 4 2.1 Disconnect Messages (DM) ........................ 4 2.2 Change-of-Authorization Messages (CoA) .......... 4 2.3 Packet format ................................... 5 3. Attributes ............................................ 8 3.1 Error-Cause ..................................... 10 3.2 Table of Attributes ............................. 12 4. IANA Considerations ................................... 15 5. Security considerations ............................... 16 5.1 Authorization issues ............................ 16 5.2 Impersonation ................................... 16 5.3 IPsec usage guidelines .......................... 17 5.4 Replay protection ............................... 20 6. Example traces ........................................ 20 7. Normative references .................................. 20 8. Informative references ................................ 21 ACKNOWLEDGMENTS .............................................. 22 AUTHORS' ADDRESSES ........................................... 22 Intellectual property statement .............................. 23 Full Copyright Statement ..................................... 24 Chiba, et al. Informational [Page 2] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 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 Change-of-Authorization messages modify session authorization attributes such as data filters. 1.1. 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. 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 Chiba, et al. Informational [Page 3] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 "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]. 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 TBD, and identifies the NAS as well as the user session to be terminated by inclusion of the identification attributes described in Section 3. +----------+ Disconnect-Request +----------+ | | <-------------------- | | | NAS | | Client | | | Disconnect-Response | | | | ---------------------> | | +----------+ +----------+ A Disconnect-Request packet is followed by a response of either 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 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. Typically this is 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. Chiba, et al. Informational [Page 4] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 +----------+ CoA-Request +----------+ | | <-------------------- | | | NAS | | Client | | | CoA-Response | | | | ---------------------> | | +----------+ +----------+ A CoA-Request is followed by a response of either CoA-ACK if the NAS is able to successfully change the authorizations for the user session or a CoA-NAK if it does not succeed. 2.3. Packet format For either type of request (Disconnect, or Change-of-Authorization), the UDP port TBD 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. When a packet is received with an invalid Code field, it is silently discarded. RADIUS codes (decimal) for this extension are assigned as follows: 40 - Disconnect-Request [RFC2882] Chiba, et al. Informational [Page 5] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 41 - Disconnect-ACK [RFC2882] 42 - Disconnect-NAK [RFC2882] 43 - CoA-Request [RFC2882] 44 - CoA-ACK [RFC2882] 45 - CoA-NAK [RFC2882] 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, and 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 haven't 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. 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 maximum length is 4096. Chiba, et al. Informational [Page 6] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 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 or Change-of-Authorization 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 with a CoA-NAK; a Disconnect-Request containing one or more unsupported attributes 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 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. Chiba, et al. Informational [Page 7] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 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 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. Potential semantic confusion between identification and authorization attributes does not exist within [Diameter] where server-initiated re-authorization messages are used for identification only and are followed by a conventional Access Request/Response exchange. 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 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 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. 3. Attributes In Disconnect and CoA-Request packets, certain attributes are used to uniquely identify the NAS as well as a user session on the NAS. All NAS and session identification attributes SHOULD match in order for a Disconnect or CoA-Request to be successful; otherwise a Disconnect-NAK or CoA-NAK MUST 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 Chiba, et al. Informational [Page 8] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 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. 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 on which the session is terminated. Originating-Line-Info 94 [NASREQ] Provides information on the characteristics of the line from which a call 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 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 or CoA-Request packets; the NAS-Identifier attribute MAY be present in addition. Chiba, et al. Informational [Page 9] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 As enumerated in Section 3.2, CoA-Request messages may also contain attributes representing requested authorization changes. If one or more authorization changes specified in a CoA-Request cannot be carried out, or if one or more attributes is unsupported, a CoA-NAK MUST be sent. 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 and is logged by the RADIUS server. 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 TBD 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 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 Chiba, et al. Informational [Page 10] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 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 501 Administratively Prohibited 502 Request Not Routable (Proxy) 503 Session Context Not Found 504 Session Context Not Removable 505 Other Proxy Processing Error "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 CoA-Request or Disconnect-Request message 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. "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 Disconnect-Request or CoA-Request. "Invalid Request" is a fatal error sent if some other aspect of the message is invalid, such as if one or more attributes (such as EAP- Message attribute(s)) are not formatted properly. "Administratively Prohibited" is a fatal error sent if the NAS is configured to prohibit honoring of Disconnect-Request or CoA-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 Disconnect-Request or CoA-Request message to the NAS. For example, this can occur if the Chiba, et al. Informational [Page 11] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 required entries are not present in the proxy's realm routing table. "Session Context Not Found" is a fatal error sent in response to a CoA-Request or Disconnect-Request 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 Disconnect or CoA-Request that could not be processed by a proxy, for reasons other than routing. 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 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 0 24 State [Note 3] 0+ 0 0 25 Class [Note 3] 0+ 0 0 26 Vendor-Specific [Note 3] Request ACK NAK # Attribute Chiba, et al. Informational [Page 12] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 Request ACK NAK # Attribute 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] 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 Orginating-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+ TBD Error-Cause Request ACK NAK # Attribute Chiba, et al. Informational [Page 13] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 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 8 Framed-IP-Address [Note 1] 0+ 0 0 18 Reply-Message [Note 2] 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 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 Orginating-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+ TBD 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 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. [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). Chiba, et al. Informational [Page 14] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 [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 the Class attribute is ignored. [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). 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 draft uses the RADIUS [RFC2865] namespace, see . 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 This draft also uses the UDP [RFC768] namespace, see . The authors request a port assignment from the Registered ports range. Finally, this specification allocates the Error-Cause attribute (TBD) 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 501 Administratively Prohibited 502 Request Not Routable (Proxy) Chiba, et al. Informational [Page 15] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 503 Session Context Not Found 504 Session Context Not Removable 505 Other Proxy Processing Error 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 or CoA-Requests affecting the sessions of another provider. To prevent this, the RADIUS proxy SHOULD perform a "reverse path forwarding" (RPF) check to verify that a Disconnect or CoA-Request is originating from an authorized RADIUS server. In a network model where a proxy is employed to forward Disconnect or CoA Requests, the NAS MUST accept Disconnect or CoA-Requests from only from proxies that it is configured to trust for those requests. Requests from untrusted sources SHOULD be silently discarded. To perform the RPF check, the proxy uses the session identification attributes included in the Disconnect or CoA-Request to determine the RADIUS server(s) to which an equivalent Access-Request would be routed. If this matches the source address of the Disconnect or CoA-Request, then the Request is forwarded; otherwise it SHOULD 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 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. 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 Chiba, et al. Informational [Page 16] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 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 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 a match is not found, Disconnect or CoA-Request messages SHOULD be silently discarded. However, 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 the security vulnerabilities discussed earlier, the protocol exchanges described are susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is recommended that IPsec be employed to afford better security. Implementations of this specification SHOULD support IPsec [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with non-null transform SHOULD be supported, and per-packet encryption, authentication, integrity and replay protection SHOULD be used, along with IKE for key management. Within RADIUS [RFC2865], a shared secret is used for hiding of attributes such as User-Password, as well as 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 Chiba, et al. Informational [Page 17] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 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, DES-CBC SHOULD NOT be used as the encryption transform, and per-packet authentication, integrity and replay protection MUST be used. A typical IPsec policy for an IPsec- capable RADIUS client is "Initiate IPsec, from me to any destination port UDP 1812". This 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 TBD". 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. 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 TBD". 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 TBD". Where IPsec is used for security, and no RADIUS shared secret is configured, it is important that trust be demonstrated between the RADIUS client and RADIUS server by some means. For example, before Chiba, et al. Informational [Page 18] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 enabling an IKE-authenticated host to act as a RADIUS client, the RADIUS server should check whether the host is authorized to provide network access. Similarly, before enabling an IKE-authenticated 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 CA exists for RADIUS clients, then the RADIUS server can configure this CA as a trusted root 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 trusted root 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 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 Chiba, et al. Informational [Page 19] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 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 is not used, in order to provide replay protection, the Event-Timestamp (55) attribute, described in [RFC2869] SHOULD be included. When this attribute is present, the RADIUS server MUST check that the Event-Timestamp is current within an acceptable time window. 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]. A default time window of 300 seconds is recommended. 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. Normative References [RFC1305] Mills, D. L., "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. Chiba, et al. Informational [Page 20] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 [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", RFC 2119, March 1997.] [RFC2401] Atkinson, R., Kent, S., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998 [RFC2434] Alvestrand, H. and Narten, T., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2486] Aboba, B., Beadles, M., "The Network Access Identifier", RFC 2486, January 1999. [RFC2865] Rigney, C., Rubens, A., Simpson, W., Willens, S., "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., Calhoun P., "RADIUS Extensions", RFC 2869, June 2000. [RFC3162] Aboba, B., Zorn, G., Mitton, D., "RADIUS and IPv6", RFC 3162, August 2001. [RADIANA] Aboba, B., "IANA Considerations for RADIUS", Internet draft (work in progress), draft-aboba-radius-iana-04.txt, April 2003. 8. 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. Chiba, et al. Informational [Page 21] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 [Diameter] Calhoun, P., et al., "Diameter Base Protocol", draft- ietf-aaa-diameter-17.txt, Internet draft (work in progress), December 2002. [NASREQ] Calhoun, P., et al., "Diameter Network Access Server Application", draft-ietf-aaa-diameter-nasreq-11.txt, Internet draft (work in progress), February 2003. [NTPAUTH] Mills, D., "Public Key Cryptography for the Network Time Protocol", Internet draft (work in progress), draft-ietf- stime-ntpauth-03.txt, February 2002. Acknowledgments Funding for the RFC Editor function is currently provided by the Internet Society. 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 , Randy Bush , Glen Zorn , Mark Jones , Claudio Lapidus , Anurag Batta , Kuntal Chowdhury , and Tim Moore . 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 Chiba, et al. Informational [Page 22] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 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 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. Chiba, et al. Informational [Page 23] INTERNET-DRAFT Dynamic Authorization Extensions 8 April 2003 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 assigns. 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." Expiration Date This memo is filed as , and expires October 19, 2003. Chiba, et al. Informational [Page 24]