Network Working Group Farid Adrangi INTERNET DRAFT Intel Corporation Category: Informational Avi Lior Expires: Nov 10, 2004 Bridgewater Systems Jouni Korhonen Teliasonera May 10, 2004 RADIUS Attributes Extension draft-adrangi-radius-attributes-extension-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document describes additional Remote Authentication Dial In User Service (RADIUS) [1] attributes for use of RADIUS AAA (Authentication, Authorization, Accounting) in both Wireless and wired networks. Some of these attributes are already implemented as Vendor Specific Attributes (VSA) in networks today, but their consistent use is essential to promote multi-vendor interoperability where RADIUS NAS and sever are from two different vendors. Adrangi, et al. Expires April 13, 2004 [Page 1] Internet Draft RADIUS Attributes Extension 10 May 2004 Table of Contents 1. Introduction....................................................2 1.1 Requirements language..........................................2 2. Operation.......................................................2 2.1 RADIUS Support for Specifying User Alias Identity..............2 2.2 RADIUS Support for Advertising Application-based capabilities..4 2.3 RADIUS Support for Specifying a Mobile IP Home Agent...........6 2.4 RADIUS Support for Specifying IP Address Type Options..........7 3. IANA Considerations.............................................8 4. Security Considerations.........................................8 5. Acknowledgements................................................8 6. References......................................................8 Authors’ Addresses.................................................9 1. Introduction Remote Access Dial In User Service (RADIUS) [1],[2],[3] is the dominant Authentication, Authorization, and Accounting (AAA) protocol in use across broadband wireless and wired networks globally. This document describes a number of additional attributes that are needed to enable use of RADIUS AAA in various types of access network in an interoperable manner. 1.1 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]. 2. Operation Operation is identical to that defined in [1] and [2]. 2.1 RADIUS Support for Specifying User Alias Identity Rationale Adrangi, et al. Expires November 13, 2004 [Page 2] Internet Draft RADIUS Attributes Extension 10 May 2004 In certain authentication methods such as, EAP-PEAP or EAP- TTLS, the true identity of the subscriber is hidden from the RADIUS AAA infrastructure. In these methods the User-name(1) attribute contains an anonymous identity sufficient to route the RADIUS packets to the home network but otherwise insufficient to identify the subscriber. While this mechanism is good practice there are situations where this creates problems. For example, in certain roaming situations intermediaries and visited network require to be able to correlate an authentication session with a user identity; A broker may require to implement a policy where by only session is allowed per user entity. Third party billing brokers may require to match accounting records to a user identity. The User Identity Alias provides a solution to the above problem. When the home network assigns a value to the User Identity Alias it asserts that this value represents a user in the home network. The assertion should be temporary. Long enough to be useful for the external applications and not too long to such that it can be used to identify the user. Attribute This attribute indicates user’s identity alias. It is assigned by the home RADIUS server and MAY be sent in Access-Accept message. The NAS MUST include this attribute in the Accounting Requests (Start, Interim, and Stop) messages if it was included in the Access Accept message. If the RADIUS server includes this attribute in an Access- Accept message it MAY also use this attribute as one of the identity attributes in a Disconnect Message and Change of Authorization message defined by RFC 3576. A summary of the User Identity Alias Attribute is shown below. 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 | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name User Identity Alias Type To be assigned by IANA Length >= 6 Adrangi, et al. Expires November 13, 2004 [Page 3] Internet Draft RADIUS Attributes Extension 10 May 2004 String The string field is six or more octets. This non-NULL terminated string consists of two colon separated parts. The first part is the Charging Type identifier and the second part is the Charging identifier. The Charging Type identifier is a two octet hexadecimal string, which defines explicitly the interpretation of the following Charging identity. The Charging identity part must be at least one octet. Following Charging Type identities have been defined: 00 – reserved 01 – IMSI 02 – NAI 03 – E.164 number 04 – SIP URL (as defined in [13]) 05 – Opaque string Below are examples of User Identity Alias Strings with NAI and E.164 Charging Types: “02:user@realm.org” “03:+4689761234” Additional Charging Type identifiers may be assigned in revised versions of this RFC. 2.2 RADIUS Support for Advertising Application-based capabilities Rationale There is a need for a home RADIUS server to discover capabilities of a NAS that has initiated a connection to it. The capabilities indicate standard-based applications (e.g., existing dynamic authorization Extension to Remote [5], future prepaid accounting model, etc.) that a NAS supports. This enables the home RADIUS server to decide which application services it can use for the connection, or whether or not it should accept the connection. For example, if the subscriber is a prepaid subscriber, and the NAS does not support the prepaid capability, the RADIUS server may want to reject the connection. Attribute Adrangi, et al. Expires November 13, 2004 [Page 4] Internet Draft RADIUS Attributes Extension 10 May 2004 This attribute describes standard-based capabilities that a NAS supports. Zero or more of these attribute are available to be sent in Access-Request. A summary of the capability Attribute is shown below. 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 | Integer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Generic Capability Type To be assigned by IANA Length = 6 Integer The format of this Integer is as follows: 0xCCCTSSSS Where: CCC is a 12-bit indicator that identifies the capability ID. CCC = 0x000 and 0xFFF is reserved. T is a 4-bit indicator used for extending the sub-capability space. T = 0xF is reserved. SSSS is 16-bit indicator that identifies the sub-capabilities ID. These are determined by the application writer and may represent a number of mutually exclusive sub-capabilities or mutually inclusive sub-capabilities codes as bits. Extension of sub-capabilities. T=0x0 represents the first 16 bits of sub-capabilities T=0x1 represents the next 16 bits of sub-capabilities T=0xF represents the last 16 bits of sub-capabilities The following Capability Identities are assigned by this RFC. Additional capability ids may be assigned later. See the IANA section. Adrangi, et al. Expires November 13, 2004 [Page 5] Internet Draft RADIUS Attributes Extension 10 May 2004 Editor’s note: we have to assign some capabilities from radius and also sub-capabilities. Candidates would be from RFCs 2865, 2869, 2867, 3162, 3576, 3580. 2.3 RADIUS Support for Specifying a Mobile IP Home Agent Rationale In Mobile IP [7], a Mobile-IP enabled client registers with its home agent when it attaches to the network for the first time, or when it changes its network point of attachment. In typical service provider deployments, networks are geographically dispersed within a single large administrative domain. In such networks, it is possible to deploy the home agents in each geographical area. When a client authenticates to its home network through a NAS, the home RADIUS server may want to specify the home agent for that client based on the NAS location information. There is a need for an interoperable method by which the home RADIUS server can indicate the Mobile IP home agent that MUST used by the client to the NAS. The home agent address can later be indicated to the client through several means – for example, it can be relayed in the “home agent address” field of a DHCP reply if the client acquires its IP address through DHCP [8]. Attribute (IPv4 version) This attribute indicates the home agent IPv4 Address that can be used by a Mobile-IP enabled client. This attribute is available to be sent in Access-Accept. A summary of the Mobile IPv4 home agent Attribute is shown below. 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 | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Adrangi, et al. Expires November 13, 2004 [Page 6] Internet Draft RADIUS Attributes Extension 10 May 2004 Mobile IPv4 Home Agent Type To be assigned by IANA Length 6 Address The Address filed is four octets. It contains a Mobile IP home agent address. 2.4 RADIUS Support for Specifying IP Address Type Options Rationale An access network may have an option of assigning a layer 3 public (i.e., routable) or private (i.e., non-routable) address to the authorized clients. If the option is available, the home network may also want to influence which address type (i.e., public or private) should be assigned to the client depending on the client’s subscription profile. There is a need for an interoperable method by which a NAS can indicate its currently available IP address type options to a home network for a given client. And then, the home network can specify the desired IP address type option to be used for assigning an IP address to the client. Attribute This attribute indicates IPv4 address type options. It can be present in Access-Request, Access-Accept, and Accounting- Request records where the Acc-Status-Type is set to Start or Stop. When it is used in an Access-Accept and Accounting- Request packets, the Address Type value MUST be 1 or 2. A NAS includes this attribute in the AR to advertise its supported IP address type options. A RADIUS server includes this attribute in the Access-Accept to specify an IP address type option for the PWLAN client. A RADIUS server MUST NOT include this attribute in the Access- Accept if the IP Address Type options were not advertised in the Access-Request. If an invalid IP Address Type option is received in the Access-Accept, then the AN MUST use its default IP Address Type option for the client. Otherwise, the AN MUST Adrangi, et al. Expires November 13, 2004 [Page 7] Internet Draft RADIUS Attributes Extension 10 May 2004 assign an IP address according to the specified type option. In either case it MUST include this attribute in Accounting- Request packets to indicate the used IP address type option. If an IP address type option is not specified in the Access- Accept, the NAS MUST NOT include this attribute in Accounting- Request packets. A summary of the home-agent Attribute is shown below. 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 |IP Address Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name IP Address Type Options Type To be assigned by IANA Length 1 Address Type 1 : Public Address Type 2 : Private Address Type 3 : Public and Private Type 3. IANA Considerations This draft introduces new RADIUS Attributes. Therefore, there is a need for obtaining new attribute TYPE numbers from IANA. 4. Security Considerations The attributes in this document have no additional security considerations beyond those already identified in [?]. 5. Acknowledgements TBD 6. References Adrangi, et al. Expires November 13, 2004 [Page 8] Internet Draft RADIUS Attributes Extension 10 May 2004 [1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Server (RADIUS)", RFC 2865, June 2000. [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [3] Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions", RFC 2869, June 2000. Authors’ Addresses Farid Adrangi Email: farid.adrangi@intel.com Phone:+1 503-712-1791 Avi Lior Email: avi@bridgewatersystems.com Jouni Korhonen Email: jouni.korhonen@teliasonera.com Full Copyright Statement Copyright (C) The Internet Society (2002). 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. Adrangi, et al. Expires November 13, 2004 [Page 9] Internet Draft RADIUS Attributes Extension 10 May 2004 Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Adrangi, et al. Expires November 13, 2004 [Page 10]