HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:12:35 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 18 Jun 1997 07:37:00 GMT ETag: "304f75-6c89-33a7901c" Accept-Ranges: bytes Content-Length: 27785 Connection: close Content-Type: text/plain ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Category: Standards Track Glen Zorn Microsoft 17 June 1997 Guidelines for the Secure Operation of RADIUS Proxies 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 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 , and expires January 1, 1998. Please send comments to the authors. 2. Abstract Today, RADIUS proxy chaining is widely deployed for the purposes of providing roaming services. This document provides guidelines for the secure operation of RADIUS proxies within roaming systems. 2.1. 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/autho- rization via the protocol described in [3], and for account- ing as described in [4]. RADIUS proxy In order to provide for the routing of RADIUS authentication Aboba & Zorn [Page 1] INTERNET-DRAFT 17 June 1997 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 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. 3. Introduction Today, as described in [1], RADIUS proxy chaining is widely deployed for the purposes of providing roaming services. In such systems, RADIUS authentication and accounting packets are routed between a NAS device and a home RADIUS server through a series of RADIUS proxies. The purpose of this document is to provide guidelines for the secure operation of such systems. An example of such a proxy chaining system is shown below. In the example, BIGCO has contracted with ISPA to provide roaming services. In turn ISPA has joined a roaming consortia ISPGROUP. User Fred then travels to another part of the world and dials into a NAS device oper- ated by ISPB, who has also joined roaming consortia ISPGROUP. Fred attempts to authenticate to the NAS device as fred@bigco.com, using the PPP protocol and an authentication protocol such as PAP, CHAP, or EAP. +------------+ +------------+ +------------+ | | | | | | | ISPB | | BIGCO | | ISPA | | Router | | RADIUS |<---------| RADIUS | | | | Server | | Proxy | | | | | | | +------------+ +------------+ +------------+ | ^ | | RADIUS | | Protocol | Inter-organizational | | RADIUS Events | Aboba & Zorn [Page 2] INTERNET-DRAFT 17 June 1997 | | | | V V +------------+ +------------+ | | | | | ISPB | Inter-organizational | ISPGROUP | | RADIUS |<----------------------------->| RADIUS | | Proxy |\ RADIUS Events | Proxy | | | \ | | | | \ | | +------------+ \ +------------+ ^ \ | \ Intra-organizational RADIUS | \ RADIUS Events Protocol | \ | \ | \ | \ | \ +------------+ +------------+ | | | | | ISPB | | ISPB | | NAS | | RADIUS | | | | Server | | | | | +------------+ +------------+ ^ | PPP | Protocol | | V +------------+ | | | | | Fred | | | | | +------------+ In the system shown above, Fred connects to the NAS of ISPB, and authenticates using PPP. ISPB's NAS then sends a RADIUS Access-Request packet to ISBP's RADIUS proxy, which routes the authentication based on the domain included in the user name fred@bigco.com. Either via use of configuration files or some other method, ISPB will forward the RADIUS Access-Request to the ISPGROUP RADIUS proxy, which will in turn forward it to the ISPA proxy, who will forward it on to BIGCO's RADIUS server. While the RADIUS protocol, described in [3] does not provide even hop-by-hop authentication of Access-Requests, such authentication is possible using the Signature attribute described in [6]. Aboba & Zorn [Page 3] INTERNET-DRAFT 17 June 1997 BIGCO's RADIUS server will then respond with a RADIUS Access-Reply, which will in turn be forwarded to the ISPA proxy, who will forward it to the ISPGROUP proxy, where it will be forwarded to ISPB's proxy who will pass it on to the NAS. The RADIUS protocol, described in [3], does provide for authentication of Access-Replies, and thus it is not required to add a Signature attribute to Access-Reply packets. If RADIUS accounting is used, a similar sequence of events will occur, with a RADIUS Accounting-Request being forwarded from the NAS to the BIGCO RADIUS serer, and an Accounting-Reply being forwarded from BIGCO's RADIUS server to the NAS. 4. Trust models In conventional ISP application, the NAS, RADIUS proxy, and RADIUS server typically exist within a single administrative entity. As a result, the RADUS proxy and RADIUS server may be considered to be trusted components. However, in a roaming system implemented with proxy chaining, the NAS, RADIUS proxies, and RADIUS server may be managed by different adminis- trative entities. Through the use of shared secrets it is possible for RADIUS proxies operating in different domains to establish a trust relationship. However, since RADIUS packets are only authenticated on a hop-by-hop basis, proxy chaining systems deployed in roaming operate without end-to-end authentication. This means that in such systems security is only as strong as the weakest link in the proxy chain. Among other things, this implies that it is advisable to keep the chain as short as possible. To date, as described in [1], existing roaming implementations have been limited in scale, forwarding RADIUS packets over a maximum of two hops, or implementing star configura- tions with all systems connecting to a single trusted entity. Such configurations minimize trust issues. 5. Security issues Since current roaming implementations operate in more than 150 coun- tries and service millions of users, it is critical that RADIUS proxy chaining implementations be secure. In particular, protection must be provided against the following attacks: Theft of passwords Replay attacks Attribute editing Connection hijacking Authentication routing attacks Fraudulent accounting records Aboba & Zorn [Page 4] INTERNET-DRAFT 17 June 1997 5.1. Theft of passwords In the case where clients authenticate using PAP, each RADIUS proxy along the path between the local NAS and the home RADIUS server will have access to the cleartext password. In many circumstances, this represents an unacceptable security risk, and as a result, it is rec- ommended that PAP SHOULD NOT be used in roaming. A possible exception to this recommendation occurs in situations where PAP is used in order to pass a one time password or token. It should also be noted that the EAP MD5 authentication method is also subject to attacks by rogue RADIUS proxies. In such an attack a RADIUS proxy substitutes a static challenge for the EAP MD5 challenge sent by the RADIUS server, and on receiving the EAP Response, checks it against a databases of hashes applied against a dictionary. As a result, it is recommended that the EAP MD5 authentication method SHOULD NOT be used in roaming. Use of EAP MD5 and PAP authentication methods can be avoided by instrucing the PPP authenticating peer to refuse these authentication methods if offered. 5.2. Replay attacks In this attack, a man in the middle or rogue RADIUS proxy collects CHAP-Challenge 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 to the accounting agent for payment. The system performing the replay need not necessarily be the one that initially captured the CHAP Chal- lenge/Response pair. While such an attack has always been possible, without roaming the threat is restricted to RADIUS proxies operating in the home server's domain. With roaming, such an attack can be mounted by any RADIUS proxy capable of reaching the home RADIUS server. In order to detect replay attacks, RADIUS servers used in roaming SHOULD keep a log of CHAP challenges, so as to allow the log to be checked for replays. 5.3. Attribute editing In this attack, a RADIUS proxy modifies RADIUS Access-Accepts coming back from the RADIUS 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, tunnel attributes might be removed or modified so as to remove encryption, redirect the tunnel to a rogue tunnel server, or otherwise lessen the security pro- vided to the client. Aboba & Zorn [Page 5] INTERNET-DRAFT 17 June 1997 In order to prevent inappropriate modification of RADIUS attributes in transit, intermediate RADIUS proxies MUST NOT edit, add, or delete attributes, except to provide the functions required in this document e.g. hop-by-hop authentication using the Signature attribute, or trace route functionality provided via the Route attribute. Editing of Access-Accepts MAY be performed by the local RADIUS proxy. However, the local RADIUS proxy MUST NOT edit attributes relating to EAP or tunneling. In addition, RADIUS proxies MUST NOT change the fundamental meaning of a RADIUS message, i.e. substitute a RADIUS Access-Accept for a RADIUS Access-Reject. Inappropriate attribute editing need not occur due to acts of malice. The vast majority of such problems are likely to result from miscon- figuration of RADIUS proxies. In fact, it is expected that as roaming grows in popularity, attribute editing problems will become widespread. This is likely since 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 network. Since RADIUS only provides for hop-by-hop authentication, it is not possible to provide end-to-end integrity checks within proxy chaining systems. However, in order to provide for detection of inappropriate attribute editing, local RADIUS proxies and home RADIUS servers SHOULD implement auditing functionality. For example, the local RADIUS proxy SHOULD include RADIUS attributes received in the Access-Accept within the session record or Accounting- Start meesage for the session. Similarly, operators of home RADIUS servers SHOULD log the contents of RADIUS Access-Replies sent, and SHOULD periodically check for discrepancies between attributes sent in RADIUS Access-Replies, and attributes received by local proxies. In order to prevent intermediate proxies from modifying accounting records, accounting records SHOULD NOT travel the same path taken by RADIUS authentication. Instead, accounting records SHOULD be sent directly between the local proxy and the systems requiring copies of the accounting records. 5.4. Connection hijacking In this form of attack, the attacker attempts to inject packets into the conversation between the NAS and the home RADIUS server. RADIUS as described in [3] is vulnerable to such attacks since only Access-Reply and Access-Challenge packets are authenticated. In order to provide for authentication of Access-Request packets, RADIUS proxies operating in roaming systems MUST support the Signature attribute, as decribed in [9]. RADIUS proxies used in roaming imple- mentations MUST check for the presence of the Signature attribute in Access-Requests forwarded to them from other proxies, and MUST silently discard Access-Request packets missing the Signature attribute or failing authentication. RADIUS proxies operating in Aboba & Zorn [Page 6] INTERNET-DRAFT 17 June 1997 roaming systems also MUST include a Signature attribute in all for- warded Access-Request packets. 5.5. Authentication routing attacks In roaming, one of the functions of the RADIUS proxy is to route authentications between domains. Authentication routing attacks affect the core of a roaming system by modifying authentication rout- ing information, thus disabling the system or causing RADIUS packets to be routed inappropriately. Since to date roaming has been implemented on a relatively small scale, existing implementations perform authentication routing based on local knowledge expressed in proxy configuration files. To date implementations have not found a need for dynamic routing protocols, or propagation of global routing information. Since authentication routing information is fundamental to the opera- tional of a roaming system, routing information SHOULD be propagated using an transfer method supporting mutual authentication, such as such as Kerberized rcp, SSH or TLS. Since all RADIUS packets used in roaming are secured by a shared secret, such attacks will not rsult in more than a denial of service, as long as the attacker did not also obtain the shared secrets. As with attribute editing, it is expected that most problems of this type will result from misconfiguration of RADIUS proxies. In order to detect such misconfigurations, RADIUS proxies participating in roaming MUST implement the Route attribute described below. The Route attribute provides trace route and/or source route capabilities. This allows a local RADIUS proxy to specify a route through which an Access-Request must travel, or for a home RADIUS server to determine whether to authorize Access-Requests routed on a given roaming rela- tionship path. A RADIUS proxy receiving a Route attribute with the Trace option set MUST append the domain of the system from which it received the packet to the end of the Route attribute prior to forwarding it. 5.6. Fraudulent accounting records In this form of attack, a local RADIUS proxy transmits fraudulent accounting packets or session records to the accounting agent in an effort to collect fees to which they are not entitled. In order to detect submission of fraudulent accounting records by an unscrupulous ISP, the the accounting gateway SHOULD send copies of session records to all parties with a financial interest in the ses- sion. Parties receiving copies of these session records SHOULD recon- cile them with logs of proxied authentications. Aboba & Zorn [Page 7] INTERNET-DRAFT 17 June 1997 In order to make it easier to match RADIUS authentication logs with accounting records, RADIUS servers involved in roaming 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 record. In order to be able to match accounting records with logs of proxied RADIUS authentications, accounting agents SHOULD require that they act as an authentication proxy for all sessions for which an accounting record will subsequently be submitted. 6. Proposed RADIUS attributes for use in roaming 6.1. Route Description In a roaming implementation based on proxy chaining, RADIUS packets are routed between the NAS and RADIUS server through a series of RADIUS proxies. This attribute allows for the authentication route taken by a RADIUS Access-Request, Access-Challenge, or Access-Reply packet to be recorded within the packet, or alternatively, for a source-route to be specified. RADIUS proxies receiving an Access- Request message with a Source-Route attribute MUST either honor the attribute or return an Access-Reject. A summary of the Route 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 | Flags | String +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type ? for Route Length >=3 Flags The Flags field indicates the intended purpose of the Route attribute: 0 0 1 2 3 4 5 6 7 8 Aboba & Zorn [Page 8] INTERNET-DRAFT 17 June 1997 +-+-+-+-+-+-+-+-+ |T S L D R R R R| +-+-+-+-+-+-+-+-+ T = Trace. If T=1, then the string represents a trace route request, and a RADIUS proxy receiving a Route option set MUST append the doma in of system from which it received the packet to the end of the Route prior to forwarding it. S = Source route. If S=1 then the string field represents a source r oute. L = Loose. If L=1 and S=1, then the string field represents a loose source route. If L=0 and S=1, then the route represents a strict source route. The combinations S=0, L=1 and T=1, S=1 are not permitted. R = Reserved. D = Direction. If D=1, the Route attribute is relevant to an Access- Request or Accounting-Request packet; if D=0, the Route attribute is releva nt to an Access-Reply, Access-Challenge or Accounting-Reply packet. String The String field includes the route, which is represented as a series of domains separated by the "/" character. For example, a valid source route is ispb.com/ispgroup.com/ispa.com/bigco.com/. If trace routing is used, then a RADIUS proxy receiving a packet from another proxy MUST append the domain of the sender onto the end of the Route attribute, prior to forwarding it. Note that the Route attribute is represented as a domain path, NOT a path comprised of the IP addresses or fully qualified domain names of the RADIUS proxies themselves. Thus, it is expected that RADIUS proxies implementing the Route attribute will be able to trans- late the IP address of the sending proxy into the appropriate domain for use in the Route attribute. This is typically accom- plished through proxy configuration files. Since a single RADIUS attribute may only be 253 octets in length, if the Route attribute is larger than this, it may be necessary to split the contents across multiple Route attributes. In order to permit Route attributes to exceed 253 octets, Route attributes with identical values of the Flags field are to be concatenated prior to interpretation. However, Route attributes with different values of the Flags field MUST NOT be concatenated, since it is possible for multi- ple Route attributes to be required within a packet. For exam- ple, it is possible for a packet to contain one Route attribute with T=1,S=0 indicating a trace request, and another Route attribute with T=0, S=1, L=1, indicating the presence of a Loose Source route. In this case, a Loose Source Route is presented at the same time that it is requested that the actual route be recorded and returned. Aboba & Zorn [Page 9] INTERNET-DRAFT 17 June 1997 7. Acknowledgments Thanks to Pat Calhoun of USR for useful discussions of this problem space. 8. References [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming Implementations." Internet draft (work in progress), draft-ietf- roamops-imprev-04.txt, Microsoft, Aimnet, i-Pass Alliance, Asiainfo, Merit, June, 1997. [2] B. Aboba, G. Zorn. "Dialing Roaming Requirements." Internet draft (work in progress), draft-ietf-roamops-roamreq-04.txt, Microsoft, June, 1997. [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, Daydreamer, January, 1997. [4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 1997. [5] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1." RFC 2068, UC Irvine, January, 1997. [6] C. Rigney, W. Willats. "RADIUS Extensions." Internet draft (work in progress), draft-ietf-radius-ext-00.txt, Livingston, 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. [8] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, Harvard University, March, 1997. 9. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com Glen Zorn Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-703-1559 Aboba & Zorn [Page 10] INTERNET-DRAFT 17 June 1997 EMail: glennz@microsoft.com Aboba & Zorn [Page 11]