ROAMOPS Working Group Yuan John Jiang Internet Draft MCI expires in six months October 1997 Secure Radius Server Operation Guidelines for Dial Roaming Status of this Memo This document is an Internet-Draft. 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. To learn the current status of any Internet-Draft, please check the id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), ic.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 in April, 1998. Please send comments to the author. Abstract Authenticating and authorizing roaming dialup users requires messages to be exchanged among facilities managed by two or more service providers, and secure operation of the facilities is of vital importance. This document provides guidelines for operating such facilities when using the Remote Authentication Dial In User Service (RADIUS) protocol and the companion accounting protocol for authentication and accounting message exchange. 1 Y. J. Jiang [1] October, 1997 1 Introduction Internet dial roaming is described in [1] and demonstrated in [2]. Such a service usually requires that user authentication messages be exchanged among facilities administrated by different service providers. It is common practice to use the RADIUS protocol as defined in [3] for authentication and the RADIUS accounting protocol [4] for accounting message exchanges. The protocols have a few weaknesses, which make roaming services particularly prone to security risks. This document does not intend to invent new schemes to overcome difficulties in secure operation but rather defines good practices within the limits of the current RADIUS framework. 1.1 Terminology This document frequently uses the following terms: Network Access Server (NAS) A network device that users dial up in order to obtain access to the network. RADIUS server A network component that receives RADIUS or Accounting Request packets. Home RADIUS server A Radius server that verifies a dialup user's identity. Proxy RADIUS server An intermediate Radius server between a NAS and a home Radius server used to relay and modify RADIUS or Accounting packets. A proxy server acts as a RADIUS client to the downstream Radius server and a server to an upstream server or a NAS. 1.2 Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. Y. J. Jiang [2] October, 1997 MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 1.3 RADIUS and dial roaming The primitive use of RADIUS protocol is for the authentication message exchange between a NAS receiving a user's call and a Radius authentication server maintaining the user database. RADIUS NAS <---------> RADIUS Server Typically, the NAS sends the server an Access-Request packet containing the user's username, authentication data and requested service and resource information, and the server replies with an Access-Reject or Access-Accept packet containing the rejection reason or the information on the service and resources authorized for the user. The accounting Request and response packets are exchanged in a similar fashion. In dial roaming, to authenticate a user, message exchanges are not limited to one client and one server. At least one proxy Radius server is involved between the NAS and the home Radius authentication server containing the user database. RADIUS RADIUS NAS <-------> Proxy RADIUS Server <-------> Home RADIUS Server More complicated operation models described in [2] involve two or more cascading proxy Radius servers or one RADIUS packet branched out to two or more Radius servers. For roaming user authentication, authorization and accounting, the Radius facilities -- the NASs and the proxy and home Radius servers -- are managed by different service providers, and the RADIUS packets are transported over the public network beyond the control of the NAS and the home Radius server operators. Security risks increase because authentication and accounting Y. J. Jiang [3] October, 1997 packets have much higher chance than in a single operator environment to be captured, modified and injected by adversaries. 2 Security weaknesses in RADIUS protocol 2.1 Packet integrity and sender identity checking A Radius client and server maintain between them a shared secret. If a server can derive from a received packet that the sender has the correct IP address and knows the shared secret, it is convinced of the client's identity. The same scheme applies when a client checks a server's identity from a response packet received. RADIUS protocol and the accounting protocol frequently use an Authenticator field in combination with the shared secret to check packet integrity and sender identity. For example, the Authenticator is the MD5 digest of Accounting-Request Code + Identifier + zero-filled Authenticator + Attributes + Shared Secret for an Accounting-Request packet or Response Code + Identifier + Request Authenticator + Attributes + Shared Secret for an Access or Accounting Response packet. RADIUS Access-Request packets, however, contain no packet integrity checking fields, nor have they sender identity checking fields unless User-Password attributes are present. An Authenticator field in an Access-Request packet is a random number and does not offer any packet integrity checking. A User-Password attribute is the plain-text user password encoded with the MD5 digest of the octet stream consisting the shared secret and the Authenticator. A home Radius server has the correct user password in its user database to compare with the one decoded from the User-Password attribute. When the comparison is successful, it can be sure of the NAS's identity; otherwise, it cannot tell whether the sender does not know the shared secret or does not have the correct user password. Further, the User-Password attribute does not help at all a proxy server, which does not have the correct user password at hand, to check the packet sender's identity. Y. J. Jiang [4] October, 1997 2.2 Hop-by-hop vs. end-to-end security In dial roaming, the packet sender identity and message integrity checking mechanism used between a client and server described above is carried over to the checking between the RADIUS components in every hop. This is considered an advantage. For example, an intermediate hop may provide some user services, which require modification of the attributes in the Access-Request and Access-Accept packets to reflect the resources requested and the resources authorized according to the service specifics. On the other hand, for user authentication, this hop-by-hop model is considered to be less secure than full end-to-end authentication if the intermediate hops cannot be fully trusted. This is the case when an adversary can pose as a legitimate RADIUS component in the chain of packet passage, or when some of the intermediate proxy servers may alter the packet content beyond their business contract or legal capacities or even inject fraudulent packets in the passage. The hop-by-hop vs. end-to-end dilemma arises from the facts that RADIUS protocol is used not only for authentication but also for resource authorization purposes and that the intermediate Radius servers in a proxy chain are often needed to play roles in resource authorization rather than simply for packet relay. The attributes a Radius server is interested in depends on the role it plays. However, a Radius server may play more than one role, and more than one server may be interested in the same attributes. Framed-IP-Address attribute in an Access-Accept packet, for example, is assigned sometimes by the NAS operator's Radius server and sometimes by the home Radius server. 2.3 Data confidentiality RADIUS protocol and the companion accounting protocol have no attribute information hiding capability except on authentication credential attributes such as User-Password. The password hiding in CHAP-Password attribute is inherent from CHAP, but the password hiding in a User-Password attribute is limited considering the intermediate RADIUS components not involved in user authentication can decode the password. Y. J. Jiang [5] October, 1997 User password checking is usually the role of the home Radius server. No intermediate Radius servers should have any business in the User-Password attribute, but unfortunately they all can decode and even edit the user password. The lack of data confidentiality leaves exposed - dialup users' usage information, - network operators' facility information, and - service providers' customer bases. It puts users' privacy and service providers and operators' trade secret at risk. It would be desirable if an attribute could be inspected only by the designated RADIUS facility. 2.4 Using IPsec Many have suggested using IPsec to overcome the security problems with RADIUS and the accounting protocols. This may help in packet integrity and sender identity checking, preventing replay attacks and, to some extent, data confidentiality. However, as a lower layer measure, IPsec cannot solve the hop-by-hop vs. end-to-end dilemma in the upper layer and prevent a proxy server from tampering with attributes beyond its intended scope. 2.5 Attribute level security The ultimate solution to the hop-by-hop vs. end-to-end dilemma and the data confidentiality problem lies with attribute level security, with which an attribute can be inspected and edited only by the specified Radius servers in the proxy chain. However, RADIUS, designed as a simple protocol, is not likely ever to be extended to include attribute level security. Without attribute level security, the length of a proxy chain and the complexity of a roaming relation are limited by trust, and proxy servers should not be used only for packet relay without any other benefit. 3 Security risks Because of the above RADIUS protocol weaknesses, the immediate risks in roaming user authentication are - theft of user passwords, Y. J. Jiang [6] October, 1997 - theft of services, - denial of services, and - fraudulent packet injection. For example, lack of Access-Request packet sender identity checking unless a User-Password attribute is used gives an adversary a chance to pose as a legitimate RADIUS client using IP spoofing techniques. This adversary can take advantage of lack of message integrity and sender identity checking - to launch a dictionary attack and obtain a user's CHAP password, - to replay a captured Access-Request packet and exhaust the resources authorized to a user, or - to replay captured Access-Request packets and overload the Radius server. 4 Signature attribute An Internet Draft [5] has proposed adding a Signature attribute to overcome the security weakness in checking sender identity and content integrity of Access-Request packets. The content of the attribute is an MD-5 [3] digest of the shared secret followed by the entire Access-Request packet, including the Code, ID, Length and Authenticator. When the digest is calculated the signature string is filled with sixteen octets of zero. At this writing, a few NAS vendors have planned to implement this feature in their products. In a roaming relation, the Signature attribute MUST be used in any Access-Request packet sent across administrative boundaries. This attribute should be used even when the packet contains a User-Password attribute. A proxy Radius server must strip the Signature attribute, if present, in an Access-Request packet received from a NAS or an up-stream Radius server and must add its own Signature attribute to the packet when sending to the down-stream Radius server. An Access-Request packet MUST not contain more than one Signature attribute. 5 Authenticator The Authenticator field in an Access-Request packet must be used strictly accordingly to [3]. Otherwise, intercepted Y. J. Jiang [7] October, 1997 Access-Request packets can be replayed by an adversary for denial of service attacks, and intercepted Access-Accept packets can be used for theft of services. The RADIUS protocol specification states: In Access-Request Packets, the Authenticator value is a 16 octet random number, called the Request Authenticator. The value SHOULD be unpredictable and unique over the lifetime of a secret (the password shared between the client and the RADIUS server), since repetition of a request value in conjunction with the same secret would permit an attacker to reply with a previously intercepted response. Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the Request Authenticator field SHOULD exhibit global and temporal uniqueness. The Request Authenticator value in an Access-Request packet SHOULD also be unpredictable, lest an attacker trick a server into responding to a predicted future request, and then use the response to masquerade as that server to a future Access-Request. A proxy Radius server typically has many clients and with each maintains a different shared secret. It is possible that more than one Accept-Request packet with the same Authenticator content may come from different clients but destined for the same down-stream Radius server. Therefor, to maintain the uniqueness and unpredictable nature of the Authenticator, the proxy server MUST strip the Authenticator from a received Access-Request packet and insert its own when forwarding the packet to the downstream Radius server. This Authenticator alteration may not be compatible with the practice of many NASs when authenticating using Challenge Handshake Authentication Protocol (CHAP). These NASs fill the Authenticator with the 16-byte CHAP challenges. A Radius server identifies this situation by the presence of a CHAP-Password attribute in a received Access-Request packet and the absence a CHAP-Challenge attribute. In this case, the proxy Radius server MUST copy the Authenticator to a CHAP-Challenge attribute and insert its own Authenticator before forwarding the packet to the down-stream Radius server. Y. J. Jiang [8] October, 1997 6 User-Password attribute In a proxy chain of a roaming authentication, any intermediate hop can decode the user password contained in a User-Password attribute. The revelation or editing of the user password by intermediate parties imposes security risks. Therefore, this User-Password attribute MAY not be used in roaming user authentication unless a one-time user password system is used. This usually means that PAP may not be used. 7 Acknowledgements The author wishes to thank Cesar Cortes of MCI, Sara Lee of Concert and Jill Hacker for insightful comments. 8 References [1] B. Aboba, G. Zorn. "Dialing Roaming Requirements." Internet draft (work in progress), draft-ietf-roamops-roamreq-05.txt, Microsoft, July, 1997. [2] 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. [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-00.txt, Livingston, January, 1997. 9 Author's Addresse Yuan John Jiang MCI Internet Engineering 2100 Reston Parkway Reston, VA 20191 Phone: 703-715-7480 EMail: yjj@mci.net Y. J. Jiang [9]