ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Category: Standards Track John R. Vollbrecht <draft-ietf-roamops-auth-07.txt> Merit Network, Inc. October 8, 1998 Proxy Chaining and Policy Implementation in Roaming 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments 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 material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as <draft- ietf-roamops-auth-07.txt>, and expires April 15, 1999. Please send comments to the authors. 2. Abstract This document describes the use of proxy chaining in roaming and how policy may be implemented concurrently with end-to-end security. 3. Terminology This document frequently uses the following terms: Network Access Server The Network Access Server (NAS) is the device that clients contact in order to get access to the network. RADIUS server This is a server which provides for authentication/authorization via the protocol described in [3], and for accounting as described in [4]. RADIUS proxy In order to provide for the routing of RADIUS authentication Aboba & Vollbrecht [Page 1]
INTERNET-DRAFT October 8, 1998 and accounting requests, a RADIUS proxy can be employed. To the NAS, the RADIUS proxy appears to act as a RADIUS server, and to the RADIUS server, the proxy appears to act as a RADIUS client. Network Access Identifier In order to provide for the routing of RADIUS authentication and accounting requests, the userID field used in PPP (known as the Network Access Identifier or NAI) and in the subse- quent RADIUS authentication and accounting requests, can contain structure. This structure provides a means by which the RADIUS proxy will locate the RADIUS server that is to receive the request. Roaming relationships Roaming relationships include relationships between com- panies and ISPs, relationships among peer ISPs within a roaming association, and relationships between an ISP and a roaming consortia. Together, the set of relationships form- ing a path between a local ISP's authentication proxy and the home authentication server is known as the roaming rela- tionship path. 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 [8]. 5. Introduction Today, as described in [1], proxy chaining is widely deployed for the purposes of providing roaming services. In such systems, authentica- tion and accounting packets are routed between a NAS device and a home server through a series of proxies. Proxies serve a number of functions in roaming, including: Scalability improvement Authentication forwarding Network parameter adjustment Policy implementation Accounting reliability improvement Proxy chaining enables implementation of hierarchical forwarding within roaming systems, which significantly improves scalability. Since RADIUS requires a shared secret for each communicating pair of systems, a consortium of 100 roaming partners would require 4950 shared secrets if each partner were to contact each other directly, one for each partner pair. However, were the partners to route authen- tication requests through a central proxy, only 100 shared secrets Aboba & Vollbrecht [Page 2]
INTERNET-DRAFT October 8, 1998 would be needed, one for each partner. Since roaming partners typically do not communicate directly due to scalability concerns, in order for a NAS and home server to communi- cate, authentication and accounting packets are forwarded by one or more proxies. The path travelled by these packets, known as the roam- ing relationship path, is determined from the Network Access Identif- ier (NAI), described in [9]. Since most NAS devices do not implement forwarding logic, a proxy is needed to enable proper routing of authentication and accounting packets. Note: The way a proxy learns the mapping between NAI and end servers is beyond the scope of this document. This mapping can be done by static configuration in the proxy, or by some currently undefined pro- tocol that get the mapping information dynamically. The assumption is that such a mapping exists in the proxy. Since RADIUS does not support capabilities negotiation, it is possible that network parameters sent back from the home server will not match those required by the NAS. Proxies can edit attributes within the Access-Accept in order to ensure compatibility. In addition, in some cases it may be desirable for a proxy to edit attributes within an Access-Request. RADIUS proxies can also be used to implement policy. For example, a given partner may only be entitled to use a given NAS during certain times of the day. The RADIUS accounting protocol, described in [4] is not designed for use on an Internet scale. This is a significant issue in roaming, which is inherently an interdomain application. Given that in roaming accounting packets travel between administrative domains, packets will often pass through network access points (NAPs) where packet loss may be substantial. This can result in unacceptable rates of accounting data loss. For example, in a proxy chaining system involving four systems, a one percent failure rate on each hop can result in loss of 3.9 percent of all accounting transactions. Placement of an accounting proxy near the NAS may improve reliability by enabling enabling per- sistent storage of accounting records and long duration retry. In addition, proxies may serve to implement a "poor man's transaction" capability, ensuring that all entities along the roaming relationship path receive accounting information. 6. Proxy chaining An example of a proxy chaining system is shown below. (request) (request) (request) NAS ----------> Proxy1 ----------> Proxy2 ----------> Home (reply) (reply) (reply) Server <--------- <--------- <--------- In the above diagram, the NAS generates a request and sends it to Aboba & Vollbrecht [Page 3]
INTERNET-DRAFT October 8, 1998 Proxy1. Proxy1 forwards the request to Proxy2 and Proxy2 forwards the request to the Home Server. The Home Server generates a reply and sends it to Proxy2. Proxy2 receives the reply, matches it with the request it had sent, and forwards a reply to Proxy1. Proxy1 matches the reply with the request it sent earlier and forwards a reply to the NAS. This model applies to all requests, including Access Requests and Accounting Requests. Except for the two cases described below, a proxy server such as Proxy2 in the diagram above should not send a Reply packet to Proxy1 without first having received a Reply packet initiated by the Home Server. The two exceptions are when the proxy is enforcing policy as described in the Policy implementation section below and when the proxy is acting as an accounting Store (as in store and forward) point, as described in the Accounting Behavior section below. While the RADIUS protocol described in [3] does not provide for end- to-end security services, this is made possible using the attributes described in [10]. The Security-Parameter-Index and End-to-End- Signature attributes SHOULD be included in packets sent between admin- istrative domains, including Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets. The Hidden attribute MAY be included, as necessary, in order to prevent disclosure of passwords or keys to untrusted proxies. 6.1. Policy implementation Proxies are frequently used to implement policy in roaming situations. Proxies implementing policy MAY reply directly to Access-Requests without forwarding the request. When replying directly to an Access- Request, the proxy MUST reply either with an Access-Reject or an Access-Challenge packet. A proxy MUST NOT reply directly with an Access-Accept. An example of this would be when the proxy refuses all connections from a particular realm during prime time. In this case the home server will never receive the Access-Request. This situation is shown below: (request) (request) NAS ----------> Proxy1 ----------> Proxy2 Home (reply) (reply) Server <--------- <--------- A proxy MAY also decide to Reject a Request that has been accepted by the home server. This could be based on the set of attributes returned by the home server. In this case the Proxy SHOULD send an Access- Reject to the NAS and an Accounting-Request with Acct-Status- Type=Proxy-Stop (6) to the home server. This lets the home server know that the session it approved has been denied downstream by the proxy. However, a proxy MUST NOT send an Access-Accept after receiving an Access-Reject from a proxy or from the home server. Aboba & Vollbrecht [Page 4]
INTERNET-DRAFT October 8, 1998 (Access-Req) (Access-Req) (Access-Req) NAS ----------> Proxy1 ----------> Proxy2 ----------> Home (Access-Reject) (Access-Accept) (Access-Accept) Server <--------- <--------- <--------- (AcctPxStop) (AcctPxStop) ----------> ----------> 6.2. Accounting behavior As described above, a proxy MUST NOT reply directly with an Access- Accept, and MUST NOT reply with an Access-Accept when it has received an Access-Reject from another proxy or Home Server. As a result, in all cases where an accounting record is to be generated (accepted ses- sions), no direct replies have occurred, and the Access-Request and Access-Accept have passed through the same set of systems. In order to allow proxies to match incoming Accounting-Requests with previously handled Access-Requests and Access-Accepts, a proxy SHOULD route the Accounting-Request along the same realm path travelled in authentication/authorization. Note that this does not imply that accounting packets will necessarily travel the identical path, machine by machine, as did authentication/authorization packets. This is because it is conceivable that a proxy may have gone down, and as a result the Accounting-request may need to be forwarded to an alternate server. It is also conceivable that authentication/authorization and accounting may be handled by different servers within a realm. The Class attribute can be used to match accounting requests with prior Access Requests. It can also be used to match session log records between the home Server, proxies, and NAS. This matching can be accomplished either in real-time (in the case that authentication and accounting packets follow the same path, machine by machine), or after the fact. Home servers SHOULD insert a unique session identifier in the Class attribute in an Access-Accept and Access-Challenge. Proxies and NASes MUST forward the unmodified Class attribute. The NAS MUST include the Class attribute in subsequent requests, in particular for Accounting- Requests. The sequence of events is shown below: Aboba & Vollbrecht [Page 5]
INTERNET-DRAFT October 8, 1998 Authentication/Authorization --------> --------> ---------> NAS Proxy1 Proxy2 Home (add class) <-class-- <-class- <-class-- Accounting (Accounting-req) (Accounting-req) (Accounting-req) w/class w/class w/class NAS ----------> Proxy1 ----------> Proxy2 ----------> Home (Accounting-reply) (Accounting-reply)(Accounting-reply) Server <--------- <--------- <--------- Since there is no need to implement policy in accounting, a proxy MUST forward all Accounting Requests to the next server on the path. The proxy MUST guarantee that the Accounting Request is received by the End Server and all intermediate servers. The proxy may do this either by: 1) forarding the Accounting Request and not sending a Reply until iet receives the matching Reply from the upstream server, or 2) acting as a Store point which takes responsibility for reforwarding the Accounting Request until it receives a Reply. This ensures that Accounting Start and Stop messages are received, and can be logged by all servers along the authentication/authorization path. Forwarding of Accounting Requests SHOULD be done as they are received so the downstream servers will receive them in a timely way. Note that there are cases where a proxy may need to forward an Accounting packet to more than one system. For example, in order to allow for proper accounting in the case of a NAS that is shutting down, the proxy may need to send an Accounting-Request with Acct- Status-Type=Accounting-Off (8) to all realms that it forwards to. In turn, these proxies will also flood the packet to their connected realms. 7. Attribute editing One of the biggest obstacles to interoperation of proxies today results from editing behavior. Today several proxy implementations remove attributes that they do not understand, or can be set up to replace attribute sets sent in the Access-Accept from the home server with sets of attributes appropriate for a particular NAS. In practice, it is not possible to define a set of guidelines for attribute editing, since the requirements are very often implementation-specific. However, using the end-to-end security attri- butes defined in [10], it is possible to provide for both "protected" and "unprotected" attributes. Protected attributes preceed an End-to- End-Signature attribute within the packet, and as a result, these attributes are integrity-protected end-to-end. Protected attributes Aboba & Vollbrecht [Page 6]
INTERNET-DRAFT October 8, 1998 MUST NOT be added, deleted, or modified by a proxy. Unprotected attributes follow the End-to-End-Signature attribute, and are not covered by the message integrity check. As a result, these attributes MAY be added, deleted, or modified by a proxy. The choice of which attributes are protected or unprotected is left up to the sender of the packet. For example, if the home server wishes to guarantee that the client will be tunneled to a given destination, then it will integrity protect tunnel attributes by placing them prior to the End-to-End-Signature attribute. In general, home servers SHOULD protect attributes whose modification would compromise security, including tunnel attributes, and EAP-Message attributes. If a proxy is unable to accept a protected attribute within an Access-Request, then it MUST reply to the NAS with an Access-Reject packet. If a proxy is unable to accept a protected attribute within an Access-Accept or Access-Challenge packet, then it SHOULD send an Access-Reject to the NAS, as well as well as an Accounting-Request with Acct-Status-Type=Proxy-Stop (6) to the home server. 8. Acknowledgments Thanks to Pat Calhoun of Sun Microsystems, Mark Beadles of CompuServe, Aydin Edguer of Morningstar, Bill Bulley of Merit, and Steven P. Crain of Shore.Net for useful discussions of this problem space. 9. References [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming Implementations." RFC 2194, Microsoft, Aimnet, i-Pass Alliance, Asiainfo, Merit, September 1997. [2] B. Aboba, G. Zorn. "Roaming Requirements." Internet draft (work in progress), draft-ietf-roamops-roamreq-10.txt, Microsoft, May 1998. [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, Daydreamer, April 1997. [4] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April 1997. [5] C. Rigney, W. Willats. "RADIUS Extensions." Internet draft (work in progress), draft-ietf-radius-ext-01.txt, Livingston, December 1997. [6] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1." RFC 2068, UC Irvine, January 1997. [7] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., April 1992. Aboba & Vollbrecht [Page 7]
INTERNET-DRAFT October 8, 1998 [8] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, Harvard University, March 1997. [9] B. Aboba, M. Beadles. "The Network Access Identifier." Internet draft (work in progress), draft-ietf-roamops-nai-10.txt, Microsoft, CompuServe, May 1998. [10] P. Calhoun and B. Aboba. "End-to-End Security in Roaming." Internet draft (work in progress), draft-ietf-roamops-roamsec-01.txt, Sun Microsystems, Microsoft, July 1998. 10. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 425-936-6605 EMail: bernarda@microsoft.com John R. Vollbrecht Merit Network, Inc. 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 Phone: 734-763-1206 EMail: jrv@merit.edu Aboba & Vollbrecht [Page 8]
