Network Working Group R. Barnes Internet-Draft BBN Technologies Intended status: Informational P. Saint-Andre Expires: January 3, 2011 Cisco Systems, Inc. July 2, 2010 High Assurance Re-Direction (HARD) Problem Statement draft-barnes-hard-problem-00 Abstract This document describes several security challenges involved with the increasingly common practice of third-party hosting of applications, in particular the inability to know with a high level of assurance that the hosting provider is authorized to offer an application on behalf of an organization or individual. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 3, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Barnes & Saint-Andre Expires January 3, 2011 [Page 1] Internet-Draft HARD Problem July 2010 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security Challenges of Hosted Applications . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. Informative References . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Barnes & Saint-Andre Expires January 3, 2011 [Page 2] Internet-Draft HARD Problem July 2010 1. Introduction Internet applications such as websites, email services, and instant messaging (IM) services are increasingly offered by third-party hosting providers (e.g., "apps.example.net"). However, an organization that contracts with such a hosting provider typically wants its applications to be associated with its DNS domain name (e.g., "example.com") instead of the hosting provider's name. This introduces a problem that we call "High Assurance Re-Direction" (HARD): how can a user or peer of the application securely know that the hosting provider is authorized to offer that application on behalf of the organization? This is indeed a HARD problem, to which no good solutions currently exist. To help technologists find such solutions, this document describes the problem and suggests some possible paths to solutions. 2. Security Challenges of Hosted Applications Let us assume that a company called Example.com wishes to offload responsibility for its corporate instant messaging service ("im.example.com") to a hosting provider called Apps.Example.Net using the Extensible Messaging and Presence Protocol [XMPP]. The company sets up DNS service location records [DNS-SRV] that point im.example.com at apps.example.net: _xmpp-client._tcp.im.example.com. 90 IN SRV 0 0 5222 apps.example.net _xmpp-server._tcp.im.example.com. 90 IN SRV 0 0 5269 apps.example.net When a user juliet@example.com attempts to log in to the IM service at im.example.com, her client discovers apps.example.net and resolves that name to an IP address and port. However, Juliet wants to be sure that the connection is encrypted using Transport Layer Security [TLS] so her client checks the certificate offered by the XMPP service at the resolved IP address and port. Her client expects the server identity in the certificate to be "im.example.com" (or perhaps "*.example.com"). But what if the identity is, instead, "apps.example.net" or "*.example.net"? Now her client will need to prompt Juliet to accept this certificate mismatch either temporarily or permanently. Because such security warnings are unnerving to end users, the owners of the company would prefer that the IM service offer a certificate with an identity of "im.example.com". Unfortunately, the IM server software used by the hosting provider probably needs runtime access to the private key associated with the certificate. This makes both the security personnel at Example.com and the lawyers at Apps.Hosting.Net Barnes & Saint-Andre Expires January 3, 2011 [Page 3] Internet-Draft HARD Problem July 2010 uncomfortable. There are several possible solutions (see for instance [XMPP-DNA]: o Terminate the hosting agreement. However, this is unpalatable to the company (IM is not their core competence) and the hosting provider (less revenue). o Deploy DNS security extensions [DNSSEC] so that users can be sure that the redirect has not been tampered with. However, DNSSEC is not yet widely deployed, so the Example.com admins discover that this option is not available. o Deploy the IM service using attribute certificates (ACs) instead of public key certificates (PKCs). However, the hosting provider's software does not support ACs and there are no tools available that would enable Example.com to generate such ACs. The same problem exists in a number of other technologies, including the Hypertext Transport Protocol [HTTP], the Internet Message Access Protocol [IMAP], the Location-to-Service Translation Protocol [LOST], and the discovery of Location Information Servers [LIS]. 3. Security Considerations This entire memo is about security. 4. IANA Considerations This document has no actions for the IANA. 5. Informative References [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. Barnes & Saint-Andre Expires January 3, 2011 [Page 4] Internet-Draft HARD Problem July 2010 [LIS] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", draft-ietf-geopriv-lis-discovery-15 (work in progress), March 2010. [LOST] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008. [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004. [XMPP-DNA] Lindberg, J. and S. Farrell, "Domain Name Assertions", draft-ietf-xmpp-dna-00 (work in progress), January 2010. Authors' Addresses Richard Barnes BBN Technologies 9861 Broken Land Parkway Columbia, MD 21046 USA Phone: +1 410 290 6169 Email: rbarnes@bbn.com Peter Saint-Andre Cisco Systems, Inc. 1899 Wyknoop Street, Suite 600 Denver, CO 80202 USA Phone: +1-303-308-3282 Email: psaintan@cisco.com Barnes & Saint-Andre Expires January 3, 2011 [Page 5]