idnits 2.17.1 draft-barnes-hard-problem-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2010) is 5047 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) == Outdated reference: A later version (-11) exists of draft-ietf-xmpp-dna-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Barnes 3 Internet-Draft BBN Technologies 4 Intended status: Informational P. Saint-Andre 5 Expires: January 3, 2011 Cisco Systems, Inc. 6 July 2, 2010 8 High Assurance Re-Direction (HARD) Problem Statement 9 draft-barnes-hard-problem-00 11 Abstract 13 This document describes several security challenges involved with the 14 increasingly common practice of third-party hosting of applications, 15 in particular the inability to know with a high level of assurance 16 that the hosting provider is authorized to offer an application on 17 behalf of an organization or individual. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 3, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Security Challenges of Hosted Applications . . . . . . . . . . 3 55 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Informative References . . . . . . . . . . . . . . . . . . . . 4 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1. Introduction 62 Internet applications such as websites, email services, and instant 63 messaging (IM) services are increasingly offered by third-party 64 hosting providers (e.g., "apps.example.net"). However, an 65 organization that contracts with such a hosting provider typically 66 wants its applications to be associated with its DNS domain name 67 (e.g., "example.com") instead of the hosting provider's name. This 68 introduces a problem that we call "High Assurance Re-Direction" 69 (HARD): how can a user or peer of the application securely know that 70 the hosting provider is authorized to offer that application on 71 behalf of the organization? 73 This is indeed a HARD problem, to which no good solutions currently 74 exist. To help technologists find such solutions, this document 75 describes the problem and suggests some possible paths to solutions. 77 2. Security Challenges of Hosted Applications 79 Let us assume that a company called Example.com wishes to offload 80 responsibility for its corporate instant messaging service 81 ("im.example.com") to a hosting provider called Apps.Example.Net 82 using the Extensible Messaging and Presence Protocol [XMPP]. The 83 company sets up DNS service location records [DNS-SRV] that point 84 im.example.com at apps.example.net: 86 _xmpp-client._tcp.im.example.com. 90 IN SRV 0 0 5222 apps.example.net 87 _xmpp-server._tcp.im.example.com. 90 IN SRV 0 0 5269 apps.example.net 89 When a user juliet@example.com attempts to log in to the IM service 90 at im.example.com, her client discovers apps.example.net and resolves 91 that name to an IP address and port. However, Juliet wants to be 92 sure that the connection is encrypted using Transport Layer Security 93 [TLS] so her client checks the certificate offered by the XMPP 94 service at the resolved IP address and port. 96 Her client expects the server identity in the certificate to be 97 "im.example.com" (or perhaps "*.example.com"). But what if the 98 identity is, instead, "apps.example.net" or "*.example.net"? Now her 99 client will need to prompt Juliet to accept this certificate mismatch 100 either temporarily or permanently. Because such security warnings 101 are unnerving to end users, the owners of the company would prefer 102 that the IM service offer a certificate with an identity of 103 "im.example.com". Unfortunately, the IM server software used by the 104 hosting provider probably needs runtime access to the private key 105 associated with the certificate. This makes both the security 106 personnel at Example.com and the lawyers at Apps.Hosting.Net 107 uncomfortable. There are several possible solutions (see for 108 instance [XMPP-DNA]: 110 o Terminate the hosting agreement. However, this is unpalatable to 111 the company (IM is not their core competence) and the hosting 112 provider (less revenue). 113 o Deploy DNS security extensions [DNSSEC] so that users can be sure 114 that the redirect has not been tampered with. However, DNSSEC is 115 not yet widely deployed, so the Example.com admins discover that 116 this option is not available. 117 o Deploy the IM service using attribute certificates (ACs) instead 118 of public key certificates (PKCs). However, the hosting 119 provider's software does not support ACs and there are no tools 120 available that would enable Example.com to generate such ACs. 122 The same problem exists in a number of other technologies, including 123 the Hypertext Transport Protocol [HTTP], the Internet Message Access 124 Protocol [IMAP], the Location-to-Service Translation Protocol [LOST], 125 and the discovery of Location Information Servers [LIS]. 127 3. Security Considerations 129 This entire memo is about security. 131 4. IANA Considerations 133 This document has no actions for the IANA. 135 5. Informative References 137 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 138 specifying the location of services (DNS SRV)", RFC 2782, 139 February 2000. 141 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 142 Rose, "DNS Security Introduction and Requirements", 143 RFC 4033, March 2005. 145 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 146 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 147 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 149 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 150 4rev1", RFC 3501, March 2003. 152 [LIS] Thomson, M. and J. Winterbottom, "Discovering the Local 153 Location Information Server (LIS)", 154 draft-ietf-geopriv-lis-discovery-15 (work in progress), 155 March 2010. 157 [LOST] Hardie, T., Newton, A., Schulzrinne, H., and H. 158 Tschofenig, "LoST: A Location-to-Service Translation 159 Protocol", RFC 5222, August 2008. 161 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 162 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 164 [XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence 165 Protocol (XMPP): Core", RFC 3920, October 2004. 167 [XMPP-DNA] 168 Lindberg, J. and S. Farrell, "Domain Name Assertions", 169 draft-ietf-xmpp-dna-00 (work in progress), January 2010. 171 Authors' Addresses 173 Richard Barnes 174 BBN Technologies 175 9861 Broken Land Parkway 176 Columbia, MD 21046 177 USA 179 Phone: +1 410 290 6169 180 Email: rbarnes@bbn.com 182 Peter Saint-Andre 183 Cisco Systems, Inc. 184 1899 Wyknoop Street, Suite 600 185 Denver, CO 80202 186 USA 188 Phone: +1-303-308-3282 189 Email: psaintan@cisco.com