ROAMOPS Working Group Pat Calhoun INTERNET-DRAFT Sun Microsystems Category: Standards Track Bernard Aboba Microsoft 20 July 1998 End-to-End Security 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 January 15, 1999. Please send comments to the authors. 2. Abstract As noted in Roaming Requirements, there is a need for end-to-end secu- rity in roaming, including end-to-end integrity protection, and confi- dentiality. In roaming implementations based on proxy chaining, pack- ets are routed between the NAS and home server through a series of proxies. Current roaming implementations provide only hop-by-hop security, guarding only against modification of packets in transit between hops. This makes it possible for untrusted proxies to modify packets sent between a NAS and a home server without detection, as well as to decrypt PAP passwords, Tunnel passwords, and other hidden attributes which are available to it in cleartext. This document provides a framework for end-to-end security in roaming, making it possible to provide end-to-end message integrity and attribute hiding through addition of three new attributes. 3. Introduction As noted in [2], there is a need for end-to-end security in roaming, including end-to-end integrity protection, and confidentiality. In Calhoun & Aboba [Page 1] INTERNET-DRAFT 20 July 1998 roaming implementations based on proxy chaining, packets are routed between the NAS and home server through a series of proxies. Current roaming implementations, as described in [1] provide only hop-by-hop security, guarding only against modification of packets in transit between hops. This makes it possible for untrusted proxies to modify packets sent between a NAS and a home server without detection, as well as to decrypt PAP passwords, Tunnel passwords, and other hidden attributes which are available to proxies in cleartext. This document provides a framework for end-to-end security in roaming, making it possible to provide end-to-end message integrity and attribute hiding through addition of three new attributes, Security- Parameter-Index, Hidden and End-to-End-Signature. In this document, it is assumed that a key has previously been established between the two endpoints. It is this key which is used in calculation of the mes- sage integrity check, as well as in end-to-end encryption of attributes. Future documents will discuss key exchange issues. The Security-Parameters-Index attribute is used to identify the secu- rity association within which the End-to-End-Signature and Hidden attributes are to be evaluated. Note that in the case where an inter- mediate proxy implements policy, it is possible for a security associ- ation to be established between the intermediate proxy and the home server, NAS, or local proxy. For example, an intermediate proxy may immediately send an Access-Reject to the NAS in response to an Access- Request, without having first forwarded it to the home server. In this case, the intermediate proxy and NAS would need to establish a secu- rity association in order to permit verification of the authenticity of the Access-Reject. Using the Hidden attribute, it is possible for the client or server to protect an attribute end-to-end. This is accomplished by encapsulating and then encrypting another attribute within the Hidden attribute. Using the End-to-End-Signature attribute, it is possible for a client or server to provide a keyed MAC which will allow end-to-end integrity protection. The keyed MAC is calculated over the immutable portions of the packet header, as well as all of the attributes preceeding the End-to-End-Signature attribute. This makes it possible for some or all of the attributes in the packet to be protected, at the sender's dis- cretion. While a proxy may add, delete or modify unprotected attributes, it MUST NOT add, delete or modify protected attributes so that the valid- ity of the keyed MAC can be maintained. A proxy also MUST NOT modify an End-to-End-Signature or Hidden attribute. On receiving a packet including an End-to-End-Signature attribute, an end system implement- ing end-to-end security MUST check the validity of the message integrity check and MUST silently discard the packet if the message integrity check cannot be verified. By allowing the message integrity check to be applied to a subset of attributes selected by the sender, and by allowing attributes to be hidden individually, these extensions enable end-to-end security Calhoun & Aboba [Page 2] INTERNET-DRAFT 20 July 1998 functionality while at the same time enabling proxies to continue to implement policy. As described in [8], policy function is a central part of the roaming architecture since roaming is inherently an inter- domain activity. 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 [7]. 5. Transition Since NAS devices will not initially implement the End-to-End-Signa- ture and Hidden attributes, it is envisaged that these attributes will initially be deployed on local proxies and home servers. In this sce- nario, the local proxy will be configured to employ end-to-end secu- rity for those NAS devices that do not support this. In this case, the local proxy would add End-to-End security attributes to Access- Requests destined for the home server and would process End-to-End security attributes in an Access-Accept, Access-Reject or Access-Chal- lenge originated by the home server. Note that if a NAS is end-to-end security enabled, then the local proxy will receive an Access-Request from the NAS with an End-to-End- Signature and will not need to add its own. As a result, a packet should include at most one End-to-End-Signature attribute. A packet may contain more than one Hidden attribute. 6. Proposed attributes 6.1. Security-Parameter-Index Description The purpose of the Security-Parameter-Index attribute is to iden- tify the security association within which the End-to-End-Signature and Hidden attributes should be evaluated. A summary of the Security-Parameter-Index attribute 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun & Aboba [Page 3] INTERNET-DRAFT 20 July 1998 Type ? for Security-Parameter-Index Length 6 Value The Value field is four octets. This serves as an index identifying the security association established between the two end-points. 6.2. End-to-End-Signature Description This attribute provides for the use of a keyed-MAC to be verified end-to-end. A summary of the End-to-End Signature attribute 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 | String +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type ? for End-to-End-Signature Length 19 (protocol 1) Protocol The protocol field specifies the authentication algorithm to be used in computing the message authentication code (MAC) which is placed in the string field. If the protocol field is 1, the HMAC protocol, described in [6] is used, along with the MD5 algorithm described in [5]. All implementations MUST support HMAC-MD5. No other protocol values are defined. String The End-to-End-Signature is an calculated using the algorithm Calhoun & Aboba [Page 4] INTERNET-DRAFT 20 July 1998 specified in the protocol field. The MAC is computed over the portion of the RADIUS packet from the beginning until the end of the End-to-End-Signature attribute, including Type, ID, Length and authenticator. In calculating the End-to-End-Signature, the authenticator should be considered to be filled with zeroes, and the End-to-End-Signature string should be considered to be six- teen octets of zero. The portion of the RADIUS packet after the End-to-End-Signature attribute is not included in the calculation of the MAC. This makes it possible for a proxy to add, modify, or delete attributes placed after the End-to-End-Signature attribute. As a result, attributes placed prior to the End-to-End-Signature attribute can be considered "protected" and those placed after the attribute can be considered to be "unprotected." Note that in order for the End-to-End-Signature to be verified, the proxy MUST maintain attribute order. 6.3. Hidden Description The purpose of the Hidden attribute is to make possible end-to-end encryption of individual attributes. This would make it possible for attributes such as User-Password or Tunnel-Password to be sent securely between a RADIUS client and a server, without risk of com- promise by an untrusted proxy. A summary of the Hidden attribute 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 | String +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type ? for Hidden Length >=4 String The String field includes the encapsulated ciphertext of the attribute which is to be hidden end-to-end. The hidden attribute is encrypted using a key and encryption algorithm which had pre- viously been established between the two endstations. Note that Calhoun & Aboba [Page 5] INTERNET-DRAFT 20 July 1998 due to the 253 octet limitation on the size of RADIUS attributes, the encapsulated attribute may be a maximum of 251 octets in length. 7. Table of Attributes The following table provides a guide to which attributes may be found in which kind of packets. Request Accept Reject Challenge # Attribute 0-1 0-1 0-1 0-1 ? End-to-End-Signature 0+ 0+ 0 0+ ? Hidden 0-1 0-1 0-1 0-1 ? SPI 8. Security issues 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 8.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. Calhoun & Aboba [Page 6] INTERNET-DRAFT 20 July 1998 Through implementation of the End-to-End-Signature attribute, it is possible to detect unauthorized addition, deletion, or modification of 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. 8.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. 8.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. Calhoun & Aboba [Page 7] INTERNET-DRAFT 20 July 1998 8.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 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 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. 8.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. 8.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, or submission of exaggerated ses- sion times for actual sessions. Such behavior will only be easily detectable in the event that roaming users are making use of voluntary or compulsory tunneling, in which case the tunnel server will generate its own accounting record, which may be compared to that generated by the local ISP. However, tunneling Calhoun & Aboba [Page 8] INTERNET-DRAFT 20 July 1998 is expected to represent only a small percentage of roaming use. In order to detect submisson of fraudulent accounting packets or ses- sion records, the the accounting gateway SHOULD send copies of session records to all parties with a financial interest in the session. Par- ties receiving copies of these session records SHOULD reconcile them with logs of proxied authentications. In order to make it easier to match authentication logs with account- ing records, home 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 log. In order to be able to match accounting logs with logs of proxied authentications, accounting agents SHOULD require that they act as an authentication proxy for all sessions for which an accounting record will subsequently be submitted. 9. Acknowledgments Thanks to Glen Zorn of Microsoft for useful discussions of this prob- lem space. 10. References [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming Implementations." RFC 2194, Microsoft, Aimnet, i-Pass Alliance, Asi- ainfo, Merit, September 1997. [2] B. Aboba, G. Zorn. "Roaming Requirements." Internet-Draft (work in progress) draft-ietf-roamops-romreq-09.txt, Microsoft, April 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] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., April 1992. [6] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication," Internet Draft (work in progress), draft- ietf-ipsec-hmac-md5-01.txt, August 1996. [7] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, Harvard University, March, 1997. [8] B. Aboba, J.R. Vollbrecht, "Proxy Chaining and Policy Calhoun & Aboba [Page 9] INTERNET-DRAFT 20 July 1998 Implementation in Roaming," Internet Draft (work in progress), draft- ietf-roamops-auth-05.txt, Microsoft, MERIT, July 1998. 11. Authors' Addresses Pat R. Calhoun Technology Development Sun Microsystems, Inc. 15 Network Circle Menlo Park, CA 94025 Phone: 650-786-7733 Fax: 650-786-6445 EMail: pcalhoun@eng.sun.com Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com Calhoun & Aboba [Page 10]