Network Working Group M. Beadles INTERNET-DRAFT UUNET Technologies Category: Standards Track 24 June 1999 AAA Referral 1. 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 doc- uments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing 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 mate- rial 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. The distribution of this draft is unlimited. It is filed as and expires December 24, 1999. Please send comments to the author. 2. Copyright Statement Copyright (C) The Internet Society 1999. All Rights Reserved. 3. Abstract This document describes a mechanism whereby, in response to a AAA request, a AAA server may refer a client to another server, which will then directly handle requests from that client. This is in contrast to a proxy mechanism, where one AAA server acts as an intermediary, communicating with another AAA server on behalf of the AAA client. An implementation of this mechanism for Dial Access AAA is presented using the RADIUS protocol. Beadles Category: Informational [Page 1] INTERNET-DRAFT AAA Referral 24 June 1999 4. Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [KEYWORDS]. 5. Description of General Mechanism This document describes a mechanism whereby, in response to a AAA request, a AAA server may refer a client to another server, which will then directly handle requests from that client. This is in contrast to a proxy mechanism, where one AAA server acts as an intermediary, communicating with another AAA server on behalf of the AAA client. It is envisioned that this mechanism would be of general utility as a means of directing AAA services from a home server to an external server. However, this document concentrates on using AAA referral for dial access, keyed off of dialed number identification. One scenario for using this mechanism is described as follows. A user dials an Internet Service Provider Point of Presence (ISP POP), which results in a telephony signal (ring) being sent to a modem attached to the ISP's Network Access Server (NAS). On receipt of the ring signal, but before going off hook, the NAS makes a request to its home AAA server, identifying the dialed number where the ring is arriving. The AAA server examines its database and determines to which AAA server further requests for this session should be directed. It returns the address of this server, called the Referred Server, to the NAS. The NAS then answers the ring and begins PPP negotiation as normal. During the authentication phase of PPP, when AAA requests are originated by that NAS, they are directed not to the first AAA server, but to the Referred Server, which acts as if it were the home server for all AAA services. This relationship between the NAS and the Referred Server is dynamic and short-lived, is tied to a single user session context, and ends when the user session ends. Concurrent or future user sessions through that NAS will have their own AAA server relationships, possi- bly including AAA Referral. Referral for Accounting may occur sepa- rately from referral for Authentication/Authorization. The Referred Server information may also include attributes directing the NAS to make future AAA reequests using a different AAA protocol than the initial request. For example, the first (default) AAA request could be made using the RADIUS protocol, but the home server could direct the NAS to communicate with the Referred Server using the TACACS+ protocol. Motivations for this mechanism includes the desire to avoid AAA prox- ies, the desire to enable multiple AAA protocols through a single dial access network, and the desire to be able to upgrade a AAA Beadles Category: Informational [Page 2] INTERNET-DRAFT AAA Referral 24 June 1999 infrastructure incrementally. 6. Sample Implementation Using RADIUS This mechanism can be implemented in RADIUS, using the attributes defined below, in the following manner. A user dials an ISP POP, which results in a ring being sent to a modem attached to the ISP's NAS. On receipt of the ring signal, but before going off hook, the NAS sends a RADIUS Access-Request to its home RADIUS server. This Access Request contains the dialed number in the RADIUS Called-Station-Id Attribute, but it does NOT contain any user authentication attributes such as User-Name or User-Password. The RADIUS server examines its database and determines to which RADIUS server further requests for this session should be directed. It returns the IP address of this server to the NAS using the Referred- Server-Address Attribute defined below. The NAS then answers the ring and begins PPP negotiation as normal. During the authentication phase of PPP, when RADIUS Access-Requests are originated by that NAS, they are directed not to the first RADIUS server, but to the designated Referred Server. 7. RADIUS Attribute Definitions 7.1. Referred-Server-Address Attribute Description This Attribute contains the IP address of the Referred RADIUS Server. It MAY be included in Access-Accept packets. A summary of the Referred-Server-Address 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type ? for Referred-Server-Address Length 6 Address Beadles Category: Informational [Page 3] INTERNET-DRAFT AAA Referral 24 June 1999 The Address field is four octets. This field MUST contain the IP Address of the Referred RADIUS Server. Discussion To enable RADIUS Referral, the home RADIUS server MUST include at least one Referred-Server-Address. In the absence of this attribute, normal RADIUS packet flows would occur by default. Multiple Referred-Server-Address attributes MAY be returned in order to provide a fail-over mechanism. If the first Referred Server is unavailable, the NAS can fail over to the next Referred-Server-Address returned. Note that if failover is used, failover times SHOULD be quick and the list of servers SHOULD be short. Referral takes place after ring but before PPP negotation begins, so there is limited time to perform Referral before a user believes that a ring-no-answer has occured. 7.2. Referred-Acct-Server-Address Attribute Description This Attribute contains the IP address of the Referred RADIUS Accounting Server. It MAY be included in Access-Accept packets. A summary of the Referred-Acct-Server-Address 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type ? for Referred-Acct-Server-Address Length 6 Address The Address field is four octets. This field MUST contain the IP Address of the Referred RADIUS Accounting Server. Discussion To enable RADIUS Accounting Referral, the home RADIUS server MUST include at least one Referred-Acct-Server-Address. In the absence of this attribute, normal RADIUS Accounting packet flows would occur by default. Multiple Referred-Acct-Server-Address attributes MAY be returned in order to provide a fail-over mecha- nism. If the first Referred Server is unavailable, the NAS can fail over to the next Referred-Acct-Server-Address returned. Beadles Category: Informational [Page 4] INTERNET-DRAFT AAA Referral 24 June 1999 Note that if failover is used, failover times SHOULD be quick and the list of servers SHOULD be short. Referral takes place after ring but before PPP negotation begins, so there is limited time to perform Referral before a user believes that a ring-no-answer has occured. RADIUS Accounting referral MAY take place sepa- rately from RADIUS Referral for authentication. 7.3. Referred-Server-Protocol Attribute Description This Attribute indicates the AAA protocol used by the Referred RADIUS Server. It MAY be included in Access-Accept packets. A summary of the Referred-Server-Protocol 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Protocol +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol(cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type ? for Referred-Server-Protocol Length 6 Address The Protocol field is four octets. This field MUST contain the Protocol used by the Referred RADIUS Server, as defined by the following enumeration: Code Protocol ------ -------- 0 RADIUS (default) 1 TACACS+ 2 Diameter Discussion This attribute is used when the Referred Server uses an AAA pro- tocol other than RADIUS. It directs the RADIUS client to use a different protocol for subsequent AAA conversations. Note that use of this attribute assumes that the Home AAA Server must "know" that the RADIUS Client is capable of supporting the speci- fied protocol. If the RADIUS Client does not support the speci- fied protocol, then the RADIUS Client MUST ignore the attribute and continue with normal AAA processing. In the absence of a Beadles Category: Informational [Page 5] INTERNET-DRAFT AAA Referral 24 June 1999 Referred-Server-Protocol attribute, the protocol is assumed to be the default value (RADIUS) 8. Table of Attributes The following table provides a guide to which of the above attributes may be found in which kinds of packets, and in what quan- tity. Request Accept Reject Challenge Acct-Request # Attribute 0 0+ 0 0 0 ? Referred-Server-Address 0 0+ 0 0 0 ? Referred-Acct-Server-Address 0 0+ 0 0 0 ? Referred-Server-Protocol 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. 9. IANA Considerations IANA should allocate 3 numbers from the RADIUS attribute name space for the attributes listed above. IANA should create a new name space for Referred-Server-Protocol. This name space should initially be populated with the values described above. The size of this name space is four octets; since it is unlikely that there will ever be this many different AAA protocols, the name space is in no danger of exhaustion. IANA can assign numbers from this name space directly. Following the policies outlined in [IANA-CONSIDERATIONS], the criteria for allocation from the space is "specification required". The requestor must document their use of the Referred-Server-Protocol value in an RFC or other permanent refer- ence. Review is not required, as there is little danger of the name space becoming polluted. 10. References [KEYWORDS] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, Harvard University, March 1997. [RADIUS] C. Rigney, et. al. "Remote Access Dial In User Service", RFC 2138, Livingston, Merit, Daydreamer, April 1997. [RADIUS-ACCT] C. Rigney. "RADIUS Accounting", RFC 2139, Livingston, April 1997. Beadles Category: Informational [Page 6] INTERNET-DRAFT AAA Referral 24 June 1999 [IANA-CONSIDERATIONS] T. Narten, H. Alvestrand. "Guidelines for Writ- ing an IANA Considerations Section in RFCs." BCP 26, RFC 2434, IBM, Maxware, October 1998. 11. Author's Address Mark Anthony Beadles UUNET, an MCI WorldCom Company 5000 Britton Rd. Hilliard, OH 43026 Phone: 614-723-1941 EMail: mbeadles@wcom.net 12. Full Copyright Statement Copyright (C) The Internet Society (1999). 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 implmentation 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 docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Inter- net 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 permis- sions 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 WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 13. Expiration Date This document is filed as , and expires December 24, 1999. Beadles Category: Informational [Page 7]