INTERNET-DRAFT Murtaza S. Chiba Title: Cisco Systems, Inc. draft-chiba-radius-dynamic-authorization-00.txt Expires April 2001 Mark Eklund Cisco Systems, Inc. November 2000 Dynamic Authorization 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/ietf/1id-abstracts.txt 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). Abstract This document describes the current practices for dynamically changing a users authorization information on the NAS and it also proposes extensions to allow for all RADIUS[1] attributes to be used. The current practices and the proposed extensions use a reverse RADIUS protocol, in which the NAS listens on a UDP port for RADIUS-like messages initiated from a client. These reverse RADIUS messages contain authorization information and could also request the disconnect of a user. 1.0 Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. M. Chiba Expires April 2001 [Page 1]
Internet Draft Dynamic Authorization October 2000 SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 1.1 Introduction The RADIUS protocol sends all the authorization information for a particular user in the Access-Response packet and there are no further authorization exchanges between the NAS and the RADIUS server for the entire duration of the user session. To overcome this limitation, various vendors have implemented a reverse RADIUS protocol in which the NAS listens on a port for messages initiated from a client. These messages currently belong to two groups: 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 packet filters for the user session. The packet format consists of the fields: Code, Identifier, Length, Authenticator and the Attributes in the Type, Length and Value (TLV) formats. All the fields hold the same meaning as those described in RADIUS. 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+- M. Chiba Expires April 2001 [Page 2]
Internet Draft Dynamic Authorization October 2000 1.2 Current Practices 1.2.1 Disconnect Request (DR) As mentioned earlier, the packet of disconnect is used to dynamically end a user session on a NAS. The response packets do not contain any attributes, but the request message contains either of the following identification attributes: Username(1): This 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 Note:The numbers in parenthesis denote the attribute number in RADIUS ---------- Disconnect Request ---------- | | <-------------------- | | | NAS | | Client | | | Disconnect Response | | | | ---------------------> | | ---------- ---------- Codes used: 40 - Disconnect Request 41 - Disconnect ACK 42 - Disconnect NAK 1.2.2 Change of Filters (CoF) The request packets contain information for dynamically changing filters of a user's session. The filters can be of either ingress, or egress kind and are in addition to the identification attributes as described in the section for DR. ---------- CoF Request ---------- | | <-------------------- | | | NAS | | Client | | | CoF Response | | | | ---------------------> | | ---------- ---------- Codes used: 43 - CoF Request 44 - CoF ACK 45 - CoF NAK M. Chiba Expires April 2001 [Page 3]
Internet Draft Dynamic Authorization October 2000 1.3 Dynamic Authorization Extension 1.3.1 Justification As noticed above, each kind of request requires three distinct code types, one for request and two for responses. In addition, every new kind of request (DR, CoF) requires additional three code types. This is clearly not scalable. 1.3.2 Requests The extensions approach re-uses the three code types for Disconnect Requests and allows all possible RADIUS attributes to be sent in the requests and responses. The attributes sent in a request fall into two categories: 1) Identification - to identify the user session, and 2) Authorization - for changing the authorization of the user session If Authorization attributes are not present, then the request is considered to be a Disconnect Request. 1.3.2.1 Identification Attributes These attributes have the same format as that of standard RADIUS attributes and are in the TLV format. The following three attributes, that fit into this category, SHOULD be supported: Username(1): This 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 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 +-+-+-+-+-+-+-+-+-+-+-+ 1.3.2.2 Authorization Attributes Any RADIUS authorization attribute can be sent in a dynamic authorization request packet. The format for these attribute is as shown below and consists of two additional fields, the Attribute Character(AC) field and the Value Interpretation(VI) field. 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 | AC | VI | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+ M. Chiba Expires April 2001 [Page 4]
Internet Draft Dynamic Authorization October 2000 1.3.2.2.1 Attribute Character Field The attribute character field MUST carry a value of either optional (0) or, mandatory (1). Since, this field is in the same place where the current length field occurs, the two values chosen suggest extension as they are considered invalid otherwise. Attributes are considered mandatory if failure to apply them MUST result in a NAK response and in an ACK response on success. Optional attributes MUST have no effect on the ACK or NAK response type. 1.3.2.2.2 Value Interpretation Field The VI field consists of information on how the NAS is supposed to interpret the value portion. Currently three flags are defined and one more is for Vendor Extension, while the rest are reserved. Starting from the LSB: Bit 0 - Additive: The value is to be added to the one currently in use Bit 1 - Replacement: The value replaces the currently applied one Bit 2 - Relative: The value is relative to the received epoch Bit 3 - Reserved for future use Bit 4 - Reserved for future use Bit 5 - Reserved for future use Bit 6 - Reserved for future use Bit 7 - Vendor Extension bit When the Vendor Extension bit is set it indicates that the next byte is still a VI field. The interpretation of the byte is the discretion of each Vendor. Having additional bytes is the discretion of each Vendor as well, although this draft only specifies one byte. The reserved bits MUST NOT be used unless specified by a later revision of this draft. An implementation that does not understand any bit must MUST NAK the entire packet. 1.3.3 ACK Response The ACK Response MUST be sent when all the mandatory attributes are applied successfully. It MAY contain all the optional attributes that failed to be applied. These attributes SHOULD be as they appear in the Request packet. 1.3.4 NAK Response A NAK MUST be sent when any of the following conditions are true. 1) The NAS failed to apply any of the mandatory attributes 2) The NAS received Identification Attributes that are not supported 3) No current user matches the Identification Attributes 4) Failed Authenticator Check The NAK Response SHOULD contain both, the mandatory and optional, attributes that failed. In addition, the failure of any M. Chiba Expires April 2001 [Page 5]
Internet Draft Dynamic Authorization October 2000 mandatory attribute SHOULD result in undoing all attributes upto the attribute that failed, so that the session has no implicit dependancies left in an incomplete state. 1.4 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 0018 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 1.4 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., Beadles, M., "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000. 1.5 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. M. Chiba Expires April 2001 [Page 6]
Internet Draft Dynamic Authorization October 2000 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. 1.6 Acknowledgements Funding for the RFC Editor function is currently provided by the Internet Society. 1.7 Author's Address Murtaza Chiba Mark Eklund Cisco Systems, Inc. Cisco Systems, Inc. 170 West Tasman Drive 170 West Tasman Drive San Jose, CA 95134 San Jose, CA 95134 Tel: (408) 525-7198 Tel: (865) 671-6255 mchiba@cisco.com meklund@cisco.com