ROAMOPS Working Group Pat Calhoun INTERNET-DRAFT Sun Microsystems Category: Standards Track Bernard Aboba Microsoft 10 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 8, 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 10 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 an intermediate proxy may add, delete or edit unpro- tected attributes, it MUST NOT add, delete or modify protected attributes so that the validity of the keyed MAC can be maintained. 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 func- tionality while at the same time enabling proxies to continue to implement policy. The policy function is a central part of the roaming architecture since roaming is inherently an inter-domain activity. Calhoun & Aboba [Page 2] INTERNET-DRAFT 10 July 1998 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type ? for Security-Parameter-Index Length Calhoun & Aboba [Page 3] INTERNET-DRAFT 10 July 1998 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 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 Calhoun & Aboba [Page 4] INTERNET-DRAFT 10 July 1998 sixteen 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 due to the 253 octet limitation on the size of RADIUS attributes, the encapsulated attribute may be a maximum of 251 octets in length. Calhoun & Aboba [Page 5] INTERNET-DRAFT 10 July 1998 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. Acknowledgments Thanks to Glen Zorn of Microsoft for useful discussions of this prob- lem 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, 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" (work in progress), August 1996. [7] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, Harvard University, March, 1997 10. Authors' Addresses Pat R. Calhoun Technology Development Sun Microsystems, Inc. 15 Network Circle Menlo Park, CA 94025 Phone: 650-786-7733 Calhoun & Aboba [Page 6] INTERNET-DRAFT 10 July 1998 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 7]