Network Working Group Farid Adrangi INTERNET DRAFT Intel Corporation Category: Informational Avi Lior Expires: Dec 10, 2004 Bridgewater Systems Jouni Korhonen Teliasonera July 16, 2004 RADIUS Attributes Extension draft-adrangi-radius-attributes-extension-01.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. It contains an IPv4 address type control mechanism, mobile IPv4 home agent discovery mechanism, and a RADIUS capabilities discovery mechanism. Adrangi, et al. Expires Dec 16, 2004 [Page 1] Internet Draft RADIUS Attributes Extension 16 July 2004 Table of Contents 1. Introduction....................................................2 1.1 Requirements language..........................................2 2. Operation.......................................................2 2.1 RADIUS Support for Specifying User Identity Alias..............3 2.2 RADIUS Support for Advertising Application-based capabilities..5 2.3 RADIUS Support for Specifying a Mobile IP Home Agent...........6 2.4 RADIUS Support for Specifying IPv4 Address Type Options........7 3. IANA Considerations.............................................9 4. Security Considerations.........................................9 5. Acknowledgements................................................9 6. References......................................................9 AuthorsĖ Addresses................................................10 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. This document describes a number of additional attributes for the RADIUS and Diameter AAA protocols. These attributes are needed to provide additional AAA functions for wired and wireless access networks. Some of these functions already exist as vendor-specific solutions, but this draft makes these functions interoperable among different vendors. 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 This document assumes that the RADIUS protocol operates as specified in [1, 2] and that the Diameter protocol operates as specified in[RFC 3588, NASREQ]. Adrangi, et al. Expires November 13, 2004 [Page 2] Internet Draft RADIUS Attributes Extension 16 July 2004 2.1 RADIUS Support for Specifying User Identity Alias Rationale In certain authentication methods such as, EAP-PEAP or EAP- TTLS, EAP-SIM, and EAP-AKA, the true identity of the subscriber can be hidden from the RADIUS AAA servers outside the subscriberĖs home network. In these methods the User-name(1) attribute contains an anonymous identity (e.g., anonymous@homerealm.com) 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: - In certain roaming situations intermediaries and visited network require to be able to correlate an authentication session with a user identity known to the userĖs home network ķ for example: 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. - NAS may require to match the user session and accounting records to a user identity known to the userĖs home network. 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 or the access network AAA server MUST include this attribute in the Accounting Requests (Start, Interim, and Stop) messages if it was included in the Access Accept message. Intermediaries MUST NOT modify the User Alias Identity attribute. 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 [4]. A summary of the RADIUS User Identity Alias Attribute is shown below. Adrangi, et al. Expires November 13, 2004 [Page 3] Internet Draft RADIUS Attributes Extension 16 July 2004 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 String The string field is six or more octets. This non-NULL terminated string consists of two colon separated parts. The first part determines the User Identity Alias type and the second part is the actual User Identity Alias value. The User-Identity-Alias type is coded as two octet hexadecimal string,. The User Identity Alias value must be at least one octet. The following User-Identity Alias types have been defined: 00 ķ reserved 01 ķ IMSI 02 ķ NAI 03 ķ E.164 number 04 ķ SIP URL (as defined in [13]) 05 ķ Opaque string Opague string is a value that is assigned to the user by the home network where the home network asserts that this value represents a particular user ķ itĖs a handle to the user. The length of time for which this assertion is valid is unspecified by this specification and typically would be long enough to serve some business needs and short enough such that it minimizes the chance of revealing the true identity of the user (either directly or indirectly). Below are examples of User Identity Alias strings with NAI and E.164 Charging Types: ÷02:charging-id@realm.org÷ ÷03:+4689761234÷ Adrangi, et al. Expires November 13, 2004 [Page 4] Internet Draft RADIUS Attributes Extension 16 July 2004 Ideally, the real user identity should not be revealed through this attribute. However, the operators will have the final word on the used charging type and its identifier. Additional User Identity Alias types 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 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 Adrangi, et al. Expires November 13, 2004 [Page 5] Internet Draft RADIUS Attributes Extension 16 July 2004 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. 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 Adrangi, et al. Expires November 13, 2004 [Page 6] Internet Draft RADIUS Attributes Extension 16 July 2004 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 RADIUS 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 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 IPv4 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 Adrangi, et al. Expires November 13, 2004 [Page 7] Internet Draft RADIUS Attributes Extension 16 July 2004 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 IPv4 address type options to a home network for a given client. And then, the home network can specify the desired IPv4 address type option to be used for assigning an IPv4 address to the client. Attribute This attribute indicates IPv4 address type options. In RADIUS, it can be present in Access-Request, and Access-Accept messages. In Diameter, it can be present in AAR, AAA, and RAR commands. In both protocols, it can be present in Accounting-Request messages 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 RADIUS Access-Accept or Diameter AAR to advertise its supported IPv4 address type options. An AAA server includes this attribute in the RADIUS Access-Accept packet or Diameter AAA and RAR commands to specify an IPv4 address type option for the access network client. An AAA server MUST NOT include this attribute in the RADIUS Access-Accept or Diameter AAA and PAR if the IPv4 Address Type options were not advertised by the NAS. If an invalid IPv4 Address Type option is received, then the NAS MUST treat it as an RADIUS Access-Reject or Diameter AA-Answer with Result-Code AVP set to ???. Otherwise, the access network MUST assign an IPv4 address according to the specified type option, and the NAS MUST include this attribute in Accounting-Request packets to indicate the used IPv4 address type option. If an IPv4 address type option is not specified in the RADIUS Access- Accept or Diameter RAR and AAA commands, the NAS MUST NOT include this attribute in Accounting-Request packets. A summary of the RADIUS IPv4 Address Type Option 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 |IPv4 Addr. Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Adrangi, et al. Expires November 13, 2004 [Page 8] Internet Draft RADIUS Attributes Extension 16 July 2004 IPv4 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. New enumerated values within the attributes defined here can be allocated using the policies defined in RFC 3575, i.e., Designated Expert. 4. Security Considerations The attributes in this document have no additional security considerations beyond those already identified in [?]. 5. Acknowledgements The authors would like to thank Jari Arkko for his extensive contribution and comments in improving the draft. 6. References [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. [4] Chiba, M., Dommety, G., Eklud, M., Mitton, D., Aboba, B., ÷Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)÷, RFC 3576, July 2003. Adrangi, et al. Expires November 13, 2004 [Page 9] Internet Draft RADIUS Attributes Extension 16 July 2004 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Adrangi, et al. Expires November 13, 2004 [Page 10]