ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Category: Standards Track John R. Vollbrecht Merit Networks, Inc. 13 October 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 mate- rial 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 ftp.ietf.org (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 , and expires May 1, 1999. Please send com- ments to the authors. 2. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. 3. Abstract This document describes the use of proxy chaining in roaming and how policy may be implemented concurrently with end-to-end security. 4. 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 Aboba & Vollbrecht Standards Track [Page 1] INTERNET-DRAFT Proxy Chaining and Policy in Roaming 13 October 1998 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 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. The NAI is defined in [6]. Roaming relationships Roaming relationships include relationships between compa- nies and ISPs, relationships among peer ISPs within a roam- ing 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. 5. 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 [5]. 6. 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 Capabilities adjustment Policy implementation Accounting reliability improvement Atomic operation It should be noted that while a number of these functions can be pro- vided within a new protocol, thus reducing the need to use proxies to Aboba & Vollbrecht Standards Track [Page 2] INTERNET-DRAFT Proxy Chaining and Policy in Roaming 13 October 1998 perform these functions, the policy implementation function is funda- mental and therefore is likely to remain, regardless of the protocol chosen. Scalability improvement Proxy chaining enables implementation of hierarchical for- warding 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 authentication requests through a central proxy, only 100 shared secrets would be needed, one for each partner. Authentication forwarding Since roaming partners typically do not communicate directly due to scalability concerns, in order for a NAS and home server to communicate, authentication and accounting packets are forwarded by one or more proxies. The path travelled by these packets, known as the roaming relationship path, is determined from the Network Access Identifier (NAI), described in [6]. 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 map- ping exists in the proxy. Capabilities adjustment 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. Such editing may include addition, deletion, or modification of attributes. In addition, in some cases it may be desirable for a proxy to edit attributes within an Access-Request. Note that if the proxy edits attributes within the Access-Accept, then it is possi- ble that the service provided to the user may not be the same as that requested by the home server. Policy implementation RADIUS proxies can be used to implement policy. For example, a given partner may only be entitled to use of a given NAS during certain times of the day. Accounting reliability improvement The RADIUS accounting protocol, described in [4] is not Aboba & Vollbrecht Standards Track [Page 3] INTERNET-DRAFT Proxy Chaining and Policy in Roaming 13 October 1998 designed for use on an Internet scale. This is a significant issue in roaming, which is inherently an interdomain appli- cation. 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 sys- tem 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 persistent storage of accounting records and long duration retry. Atomic operation In order to ensure consistency among all parties required to process accounting data, it can be desirable to assure that transmission of accounting data is handled as an atomic operation. This implies that all parties on the roaming relationship path will receive and acknowledge the receipt of the accounting data for the operation to complete. 7. 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 agram, the NAS generates a request and sends it to 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 section 7.1 and when the proxy is acting as an accounting store (as in store and forward), as described in section 7.2. 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 [7]. 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 Aboba & Vollbrecht Standards Track [Page 4] INTERNET-DRAFT Proxy Chaining and Policy in Roaming 13 October 1998 included, as necessary, in order to prevent disclosure of passwords or keys to untrusted proxies. 7.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 receiv- ing an Access-Reject from a proxy or from the home server. (Access-Req) (Access-Req) (Access-Req) NAS ----------> Proxy1 ----------> Proxy2 ----------> Home (Access-Reject) (Access-Accept) (Access-Accept) Server <--------- <--------- <--------- (AcctPxStop) (AcctPxStop) ----------> ----------> 7.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 Aboba & Vollbrecht Standards Track [Page 5] INTERNET-DRAFT Proxy Chaining and Policy in Roaming 13 October 1998 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: 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 it 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. Note that in the former arrangement, atmoic operation can be supported, while in the latter case it typically cannot. 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 Aboba & Vollbrecht Standards Track [Page 6] INTERNET-DRAFT Proxy Chaining and Policy in Roaming 13 October 1998 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. 8. 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 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 implementa- tion-specific. However, using the end-to-end security attributes defined in [7], 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 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. 9. References [1] Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, "Review of Roam- ing Implementations", RFC 2194, September 1997. [2] Aboba, B., and G. Zorn, "Roaming Requirements", Internet draft (work in progress), draft-ietf-roamops-roamreq-10.txt, May 1998. [3] Rigney C., Rubens A., Simpson W., and S. Willens, "Remote Authen- tication Dial In User Service (RADIUS)", RFC 2138, April 1997. Aboba & Vollbrecht Standards Track [Page 7] INTERNET-DRAFT Proxy Chaining and Policy in Roaming 13 October 1998 [4] Rigney C., "RADIUS Accounting", RFC 2139, April 1997. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Aboba, B., and M. Beadles, "The Network Access Identifier", Internet draft (work in progress), draft-ietf-roamops-nai-10.txt, May 1998. [7] Calhoun, P., and B. Aboba, "End-to-End Security in Roaming", Internet draft (work in progress), draft-ietf-roamops-roamsec-01.txt, July 1998. 10. Security Considerations The following security threats have been identified in roaming sys- tems: Rogue proxies Theft of passwords Theft of accounting data Replay attacks Connection hijacking Fraudulent accounting 10.1. Rogue proxies In conventional ISP application, the NAS, proxy, and home server exist within a single administrative entity. As a result, the proxy may be considered a trusted component. However, in a roaming system implemented with proxy chaining, the NAS, proxies, and home server may be managed by different administrative entities. Through the use of shared secrets it is possible for proxies operating in different domains to establish a trust relationship. How- ever, if packets are only authenticated on a hop-by-hop basis, then untrusted proxies are capable of perpetrating a number of man-in-the- middle attacks. These attacks typically involve the editing of attributes, or the mod- ification or insertion of messages, such as the substitution of an Access-Accept for an Access-Reject. For example, a proxy may modify an Access-Accept sent by the home server so as to lessen the security obtained by the client. For example, EAP attributes might be removed or modified so as to cause a client to authenticate with EAP MD5 or PAP, instead of a stronger authentication method. Alternatively, tun- nel attributes might be removed or modified so as to remove encryp- tion, redirect the tunnel to a rogue tunnel server, or otherwise lessen the security provided to the client. Through implementation of the End-to-End-Signature attribute, it is possible to detect unauthorized addition, deletion, or modification of Aboba & Vollbrecht Standards Track [Page 8] INTERNET-DRAFT Proxy Chaining and Policy in Roaming 13 October 1998 protected attributes. Note that it is still possible for a rogue proxy to add, delete or modify unprotected attributes. While a proxy MUST NOT send an Access-Accept to the NAS after receiv- ing an Access-Reject from the home server, a proxy MAY send an Access- Reject to the NAS after receiving an Access-Accept from the home server. Note that in the latter case, a Security-Parameter-Index attribute should be used denoting the security association between the proxy and the NAS, rather than that between the home server and the NAS, since the proxy has originated the packet. This will allow the NAS to verify the End-to-End-Signature attribute within the packet, and decide whether to silently discard the packet. As noted earlier, an Access-Accept originated by a proxy MUST be silently discarded by the NAS, even if the End-to-End-Signature attribute can be verified. The determination of whether end-to-end security is to be used in a conversation is made using out-of-band mechanisms. Typically this is based either on static configuration or on the outcome of a key exchange conversation between the two endpoints. However, once it is determined that the end systems wish to use end-to-end security, all packets sent MUST include an End-to-End-Signature attribute and pack- ets received without an End-to-End-Signature attribute MUST be silently discarded. Note that policy determination using an out-of- band mechanism rather than a proxied conversation limits the ability of a rogue proxy to interfere with the security negotiation between the two end systems. 10.2. Theft of passwords or keys Unless the Hidden attribute is used, where clients authenticate using PAP, or where the Tunnel-Password attribute is included with the Access-Accept, each proxy along the path between the local NAS and the home server will have access to the cleartext password or key. In many circumstances, this represents an unacceptable security risk. As a result, the Hidden attribute SHOULD be used to provide end-to-end con- fidentiality for User-Password or Tunnel-Password attributes. 10.3. Integrity and confidentiality of accounting data Typically in roaming systems, accounting packets are provided to all the participants along the roaming relationship path, in order to allow them to audit subsequent invoices. In order to prevent modifica- tion of accounting packets by untrusted proxies, the End-to-End-Signa- ture attribute MAY be used. If it is desired that accounting data be kept confidential from a proxy, the Hidden attribute MAY be used. If the objective is to prevent snooping of accounting data on the wire, then IPSEC ESP MAY be used. Aboba & Vollbrecht Standards Track [Page 9] INTERNET-DRAFT Proxy Chaining and Policy in Roaming 13 October 1998 10.4. Replay attacks In this attack, a man in the middle or rogue proxy collects CHAP-Chal- lenge and CHAP-Response attributes, and later replays them. If this attack is performed in collaboration with an unscrupulous ISP, it can be used to subsequently submit fraudulent accounting records for pay- ment. The system performing the replay need not necessarily be the one that initially captured the CHAP Challenge/Response pair. While RADIUS as described in [3] is vulnerable to replay attacks, without roaming the threat is restricted to proxies operating in the home server's domain. With roaming, such an attack can be mounted by any proxy capable of reaching the home server. In order to protect against replay attacks, CHAP-Challenge and CHAP- Response attributes MAY be protected using the Hidden attribute. CHAP replay attacks can also be defeated by means of an end-to-end chal- lenge-response exchange. For example, if the home server returns an Access-Challenge packet containing a CHAP-Challenge attribute and maintains state with respect to outstanding challenges, replay attacks cannot succeed. However, it should also be noted that end-to-end challenges (as prac- ticed within the EAP MD5 authentication method, or in the CHAP-Chal- lenge method described above) are also subject to attacks by rogue proxies. In such an attack a proxy substitutes a static challenge for the challenge sent by the home server, and on receiving the response, checks it against a databases of hashes applied against a dictionary. This attack may be prevented through use of the End-to-End-Signature attribute. 10.5. Connection hijacking In this form of attack, the attacker attempts to inject packets into the conversation between the NAS and the home server. RADIUS as described in [3] is vulnerable to such attacks since only Access-Reply and Access-Challenge packets are authenticated. This attack may be defeated via use of an End-to-End-Signature attribute as described in [7]. 10.6. Fraudulent accounting In this form of attack, a local proxy transmits fraudulent accounting packets or session records in an effort to collect fees to which they are not entitled. This includes submission of packets or session records for non-existent sessions.. In order to detect submissions of accounting packets or session records for non-existent sessions, parties receiving accounting pack- ets or session records will typically wish to reconcile them with the authentication logs. Such reconciliation is only typically possible when the party acts as an authentication proxy for all sessions for Aboba & Vollbrecht Standards Track [Page 10] INTERNET-DRAFT Proxy Chaining and Policy in Roaming 13 October 1998 which an accounting record will subsequently be submitted. In order to make reconciliation easier, home servers involved in roam- ing SHOULD include a Class attribute in the Access-Accept. The Class attribute SHOULD uniquely identify a session, so as to allow an authentication log entry to be matched with a corresponding accounting packet or session record. Note that in order to prevent submission of accounting packets or ses- sion records for non-existent sessions, it is necessary to prevent replay. 11. 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. 12. 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: 313-763-1206 EMail: jrv@merit.edu 13. Full Copyright Statement Copyright (C) The Internet Society (1997). 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 Aboba & Vollbrecht Standards Track [Page 11] INTERNET-DRAFT Proxy Chaining and Policy in Roaming 13 October 1998 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." 14. Expiration Date This memo is filed as , and expires May 1, 1999. Aboba & Vollbrecht Standards Track [Page 12]