ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Category: Standards Track 11 February 1999 Certificate-Based roaming 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. The distribution of this memo is unlimited. It is filed as , and expires August 1, 1999. Please send comments to the authors. 2. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 3. Abstract To date, roaming implementations have been based on the concept of proxy chaining, where packets are routed between the NAS and home server through a series of proxies. While commonly used, proxy chaining introduces difficult security problems that have prevented its implementation on a wide scale. This document describes a new approach to roaming based on certificates that eliminates the need for proxy chaining. As described, this approach provides improved security as well as scalability. Aboba Standards Track [Page 1] INTERNET-DRAFT Certificate-Based Roaming 11 February 1999 4. Introduction As noted in [1], roaming implementations have been based on the concept of proxy chaining, where packets are routed between the NAS and home server through a series of proxies. Current roaming implementations based on proxy chaining as described in [8] 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. These security issues have to date prevented the implementation of roaming on a wide scale. This document describes a new approach to roaming based on certificates that eliminates the need for proxy chaining. As described, this approach provides improved security as well as scalability. 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 [7]. 6. Certificate-based roaming In certificate-based roaming, the user utilizes a public-key based smartcard or other certificate in order to authenticate to the local ISP. This is accomplished through use of an EAP-based certificate authentication protocol such as EAP-TLS, described in [11]. Through use of certificate-based authentication, it is possible for the local ISP authentication server to verify the user's identity without the need to proxy the authentication to the home server. In order to achieve proxy-less authorization, the authorization parameters are derived from the certificate. This can be achieved either by embedding the authorization parameters directly, or by deriving them from certificate parameters such as the Network Access Identifier, described in [3]. In this model, it is necessary for a chain of trust to be established between the user and the local ISP. In the simplest case this can be accomplished by presenting a certificate signed by a trusted third party, such as a roaming association to which the local ISP belongs. Note that in order to verify that the user certificate remains valid, the local authentication server will typically need to check the Aboba Standards Track [Page 2] INTERNET-DRAFT Certificate-Based Roaming 11 February 1999 Certificate Revocation List (CRL). Since certificate-based roaming eliminates the use of proxy authentication and authorization, the home server no longer receives authentication and authorization requests from the local ISP. As a result, a mechanism must be provided for verification of the resulting charges. In particular, it is desirable to be able to prove that the user requested service at the date, time and place claimed by the local ISP. This can be achieved as part of the EAP-based certificate authentication protocol. For example, if the user were to use a smartcard or certificate in order to sign a ticket providing information on the number called, NAI used, time of day, date, etc. then this ticket could be included in the local ISP accounting packet and would represent proof of the user access attempt. Since the time of day and NAI are embedded in the ticket, it would not be possible to replay the ticket in order to commit fraud. 7. Security issues The following security threats have been identified in roaming systems: Rogue proxies Theft of passwords Theft of accounting data Replay attacks Connection hijacking Fraudulent accounting Certificate-based roaming reduces or eliminates each of these threats. 7.1. Rogue proxies In certificate-based roaming, authentication and authorization need not be proxied from the local ISP to the home server. As a result, where the local ISP is operating a dedicated network, the authentication request never leaves the local ISP domain and the risk of rogue authentication proxies is eliminated. The risk of rogue accounting proxies is also reduced, since it is no longer necessary to proxy the accounting packets back to the home server in order to provide proof of usage. Since the user signs a ticket certifying the access attempt as part of authentication, it is only necessary to send the accounting packet to the settlement agent. If audited, the settlement agent can then produce the ticket to provide Aboba Standards Track [Page 3] INTERNET-DRAFT Certificate-Based Roaming 11 February 1999 verification. 7.2. Theft of passwords or keys In certificate-based roaming, no passwords are sent in the clear, and it is not necessary to derive a session key unless PPP encryption is desired. Avoiding key derivation reduces the need to transmit the derived key between the authentication server and the local ISP NAS handling the user, this eliminating the risk of key compromise. 7.3. Integrity and confidentiality of accounting data While certificate-based roaming does not provide for confidentiality in accounting data, it does provide for integrity protection through use of a digital signature. 7.4. Replay attacks By signing a ticket including the time of day, NAI and called phone number, certificate-based roaming eliminates the risk of replay attacks. 7.5. Connection hijacking Since certificate-based roaming avoids proxying of authentication and authorization, the risk of connection hijacking is reduced. This risk can be further minimized via integrity protection during the user authentication process, thereby preventing modification of the packets in transit. 7.6. Fraudulent accounting Through use of a signed ticket, certificate-based roaming prevents accounting for non-existent sessions. It does not however prevent submission of exaggereated session times for actual sessions. 8. References [1] Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997. Aboba Standards Track [Page 4] INTERNET-DRAFT Certificate-Based Roaming 11 February 1999 [2] Aboba, B., and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999. [3] Aboba, B., and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [4] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April, 1997. [5] Rigney, C., "RADIUS Accounting." RFC 2139, April 1997. [6] Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [8] Aboba, B., Vollbrecht, J.R., "Proxy Chaining and Policy Implementation in Roaming", Internet draft (work in progress), draft-ietf-roamops-auth-09.txt, December 1998. [9] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [10] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 2246, November 1998. [11] Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol", draft- ietf-pppext-eaptls-05.txt, Internet Draft (work in progress), January 1999. 9. Acknowledgments Thanks to Glen Zorn of Microsoft for useful discussions of this problem space. Aboba Standards Track [Page 5] INTERNET-DRAFT Certificate-Based Roaming 11 February 1999 10. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com 11. Full Copyright Statement Copyright (C) The Internet Society (1999). 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 document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet 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 translate it into languages other than English. The limited permissions 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 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 12. Expiration Date This memo is filed as , and expires August 1, 1999. Aboba Standards Track [Page 6]