INTERNET-DRAFT Murtaza S. Chiba Title: Cisco Systems, Inc. draft-chiba-radius-dynamic-authorization-06.txt Expires July 2003 Gopal Dommety Cisco Systems, Inc. Mark Eklund Cisco Systems, Inc. David Mitton Circular Logic, UnLtd. Aboba B. Microsoft January 2003 Dynamic Authorization Extensions to Remote Authentication Dial-In User Service (RADIUS) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Distribution of this memo is unlimited. This document is an Internet-Draft. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html To view the entire list of current Internet-Drafts, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). M. Chiba Expires July 2003 [Page 1]
Internet Draft Dynamic Authorization Extensions January 2003 Abstract This document describes the current practices for allowing dynamic changes to a user session as implemented by network access server products providing the Remote Authentication Dial-In User Service. Namely it documents the current methods for disconnecting and changing data filters applicable to a user session. Table of Contents 1.0 Introduction........................................... 2 1.1 Specification of Requirements...................... 2 1.2 Calculating Request and Response Authenticator..... 3 1.3 Retransmission Considerations...................... 4 1.4 Proxy Considerations............................... 4 2.0 Current Practices...................................... 4 2.1 Protocol Port Information.......................... 4 2.2 Identification Attributes.......................... 4 2.3 Disconnect Messages (DM)........................... 5 2.4 Change-of-Filters Messages(CoF).................... 5 3.0 Security Considerations................................ 6 4.0 Table of Attributes.................................... 8 5.0 Example Traces of current Disconnect Requests.......... 8 6.0 Normative References................................... 8 7.0 Copyright.............................................. 9 8.0 Acknowledgements....................................... 10 9.0 Authors' Addresses..................................... 10 1.0 Introduction The RADIUS protocol, defined in [RFC2865] does not support unsolicited messages sent from the RADIUS server to the 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 sessions in progress. Alternatively, if the user changes authorization level, this may require that data filters be added/deleted from the session. To overcome these limitations, various 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: 1) Disconnect messages, and 2) Change of Filters messages The disconnect messages cause a user session to be terminated immediately, whereas change of filter messages modify the applicable data filters for the user session. M. Chiba Expires July 2003 [Page 2]
Internet Draft Dynamic Authorization Extensions January 2003 The packet format consists of the fields: Code, Identifier, Length, Authenticator, and Attributes in the Type:Length:Value(TLV) formats. All the fields hold the same meaning as those described in RADIUS[1]. 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+- 1.1 Specification of Requirements 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 RFC 2119. 1.2 Calculating Request and Response Authenticator 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 CoF-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 Change-of=Filters Request . Response Authenticator The Authenticator field in a Response packet (e.g. Disconnect-ACK, Disconnect-NAK, CoF-ACK, or CoF-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. M. Chiba Expires July 2003 [Page 3]
Internet Draft Dynamic Authorization Extensions January 2003 1.3 Retransmission Considerations 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. 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. 1.4 Proxy Considerations In a network model where a proxy is employed to forward the disconnect requests, the NAS MUST accept requests from proxies that it trusts, all other requests from untrusted sources SHOULD be silently discarded. Routing such requests via proxies and creating trust relationships, are considered to be outside the scope of this document. Attribute ordering MUST remain unchanged, although new attributes (e.g. Proxy-State) MAY be added. 2.0 Current Practices This draft outlines the details for Disconnect Messages and Change-of-Filters Messages that are commonly implemented. 2.1 Protocol Port Information For either type of request (Disconnect, or Change of Filters), the UDP port 1700 is used as the destination port. For responses, the source and destination ports are reversed. 2.2 Identification Attributes A number of attributes are used to uniquely identify a user session on the NAS and one, or more, of these SHOULD be present in either type of messages (Disconnect or, Change-of-Filters). The set of attributes includes the following: Username(1): This is the name of the user associated with the session Acct-Session-Id(44): This is derived from a RADIUS Accounting-Start Framed-IP-Address(8): This is the IP Address associated with the session NAS-Port(5): This is the Port on which the user connection is terminated NAS-Port-Type(61): The type of port used Note: The numbers in parenthesis denote the attribute numbers as documented in [1] & [3]. The ability to use all/some of the identifiers to map to unique/multiple session(s) is beyond the scope of this document. M. Chiba Expires July 2003 [Page 4]
Internet Draft Dynamic Authorization Extensions January 2003 2.3 Disconnect Messages (DM) A Disconnect packet is sent by the RADIUS server in order to terminate a user session on a NAS. The Disconnect packet is sent to UDP port 1700, and identifies the session to be terminated by inclusion of one or more identification attributes as described in the section 2.2 above. ---------- Disconnect-Request ---------- | | <-------------------- | | | NAS | | Client | | | Disconnect-Response | | | | ---------------------> | | ---------- ---------- Codes used [2]: 40 - Disconnect-Request 41 - Disconnect-ACK 42 - Disconnect-NAK A Disconnect Request is followed by a response of either, Disconnect-Ack, if the NAS successfully disconnects the user, or a Disconnect-NAK, if it was unable to disconnect the user. A Disconnect-Ack may contain the attribute Acct-Terminate-Cause (49) with the value set to 6 for Admin-Reset. 2.4 Change-of-Filters Messages(CoF) The CoF message packets contain information for dynamically changing data filters of a user's session. The data filters can be of either ingress, or egress kind, and are sent in addition to the identification attributes as described in section 2.2. The port used, and packet format, are the same as that for Disconnect Messages. The following attribute SHOULD be sent in a Change-of-Filters Request: Filter-ID (11) - Indicates the name of a data filter list to be applied for the session that the identification attributes map to. M. Chiba Expires July 2003 [Page 5]
Internet Draft Dynamic Authorization Extensions January 2003 ---------- CoF Request ---------- | | <-------------------- | | | NAS | | Client | | | CoF Response | | | | ---------------------> | | ---------- ---------- Codes used [2]: 43 - CoF-Request 44 - CoF-ACK 45 - CoF-NAK A Change of Filter request is followed by a response of either, CoF-Ack if the NAS is able to successfully change the data filters for the user's session or, a CoF-NAK if it does not succeed. 3.0 Security Considerations The protocol exchanges described are susceptible to the same vulnerabilities as RADIUS and it is recommended that IPSec be employed to afford better security. Within RADIUS, a shared secret is used for hiding of attributes such as User-Password [1]. In addition, the shared secret is used in computation of the Response Authenticator [1], Therefore, in RADIUS a shared secret is used to provide confidentiality as well as integrity protection and authentication. As a result, 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. However, 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 [7]. Additionally, when IPsec is used with RADIUS, DES-CBC SHOULD not be used as the encryption transform, and per-packet replay protection and authentication MUST be used. A typical IPsec policy for an IPsec-capable RADIUS client is "Initiate IPsec, from me to any, destination port UDP 1812", similarly for clients implementing this specification the policy would be "Initiate IPsec, from me to any, destination port UDP 1700". This causes an IPsec SA to be set up by the RADIUS client prior to sending RADIUS traffic to any RADIUS server. If some RADIUS servers contacted by the client do not support IPsec, then a more granular policy will be required. M. Chiba Expires July 2003 [Page 6]
Internet draft Dynamic Authorization Extensions January 2003 For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept IPsec, from any to me, destination port 1812" and for servers implementing this specification the policy would be "Accept IPsec, from any to me, destination port 1700". 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. Where no RADIUS shared secret is configured, and IPsec with ESP and non-null transform is used for security, it is important that trust be demonstrated between the RADIUS client and RADIUS server by some means. For example, it would not be wise to enable any host with a certificate chaining to a trusted root to act as a RADIUS client, unless that host were specifically authorized to provide network access. This can be accomplished by configuring the RADIUS server to expect communication from a RADIUS client, either by configuring it with the machine name of the RADIUS client (expected to be present in the certificate), or its IP address. 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. However, since unlike SSL/TLS, IKE does not permit certificate policies to be set on a per-port basis, such a policy would need to apply to all uses of IPsec on RADIUS clients and servers. Thus, assuming that only certificate authentication is supported in the deployment, 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." Since this specification utilizes the Request Authenticator field for integrity protection and authentication, rather than as a nonce, no liveness or protection against replay is provided by the RADIUS header. Where IPsec is not used, in order to provide replay protection, the Event-Timestamp (55) attribute, described in [4] 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 [6]. A default time window of 300 seconds is recommended. M. Chiba Expires July 2003 [Page 7]
Internet draft Dynamic Authorization Extensions January 2003 4.0 Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Disconnect Messages: Request ACK NAK # Attribute 0-1 0 0 1 User-Name 0-1 0 0 5 NAS-Port 0-1 0 0 8 Framed-IP-Address 0-1 0 0 44 Acct-Session-Id 0-1 0 0 49 Acct-Terminate-Cause 0-1 0 0 55 Event-Timestamp 0-1 0 0 61 NAS-Port-Type 0-1 0 0 4 NAS-IP-Address 0-1 0 0 32 NAS-Identifier 0-1 0 0 33 Proxy-State 0-1 0 0 26 Vendor-Specific Change-of-Filters Messages 0-1 0 0 1 User-Name 0-1 0 0 5 NAS-Port 0-1 0 0 8 Framed-IP-Address 0+ 0 0 11 Filter-ID 0-1 0 0 44 Acct-Session-Id 0-1 0 0 55 Event-Timestamp 0-1 0 0 61 NAS-Port-Type 0-1 0 0 4 NAS-IP-Address 0-1 0 0 32 NAS-Identifier 0-1 0 0 33 Proxy-State 0-1 0 0 26 Vendor-Specific Note: Other attributes SHOULD NOT be included by an implementation 5.0 Example Traces of current Disconnect Requests Disconnect Request with Username: 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 M. Chiba Expires July 2003 [Page 8]
Internet draft Dynamic Authorization Extensions January 2003 6.0 Normative References [1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [2] Mitton, D., "Network Access Server Requirements: Extended RADIUS Practices", RFC 2882, July 2000. [3] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [4] Rigney, C., Willats W., Calhoun P., "RADIUS Extensions", RFC 2869, June 2000. [5] Mills, D. L., "Network Time Protocol (version 3) Specification, Implementation and Analysis, RFC 1305 March, 1992. [6] Mills, D., "Public Key Cryptography for the Network Time Protocol", Internet draft (work in progress), draft-ietf-stime-ntpauth-03.txt, February 2002. [7] Aboba, B., Zorn, G., Mitton, D., "RADIUS and IPv6", RFC 3162, August 2001. 7.0 Copyright Copyright (C) The Internet Society (2000). 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. M. Chiba Expires July 2003 [Page 9]
Internet draft Dynamic Authorization Extensions January 2003 8.0 Acknowledgements Funding for the RFC Editor function is currently provided by the Internet Society. This protocol function was first developed and distributed by Ascend Communications. Example code was distributed in their free server kit. This document removes vendor specific functions and attributes so that it interoperates with other implementations. The authors would like to acknowledge the valuable suggestions and feedback from the following people: Randy Bush<randy@psg.net>, Glen Zorn<gwz@cisco.com>, Mark Jones<mjones@bridgewatersystems.com>, Claudio Lapidus <clapidus@hotmail.com> and Anurag Batta<Anurag_Batta@3com.com>. 9.0 Authors' Addresses Murtaza Chiba Gopal Dommety Mark Eklund Cisco Systems, Inc. Cisco Systems, Inc. Cisco Systems, Inc. 170 West Tasman Dr. 170 West Tasman Dr. 170 West Tasman Dr. San Jose, CA 95134 San Jose, CA 95134 San Jose, CA 95134 Tel: (408) 525-7198 Tel: (408) 525-1404 Tel: (865) 671-6255 mchiba@cisco.com gdommety@cisco.com meklund@cisco.com David Mitton Bernard Aboba Circular Logic UnLtd. Microsoft Corporation 733 Turnpike Street #154 One Microsoft Way North Andover, MA 01845 Redmond, WA 98052 Tel: 978 683-1814 Tel: +1 425 706 6605 david@mitton.com bernarda@microsoft.com