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 described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Security Challenges of Hosted Applications
3.  Security Considerations
4.  IANA Considerations
5.  Informative References
§  Authors' Addresses

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] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.). The company sets up DNS service location records [DNS‑SRV] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.) 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] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) 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 uncomfortable. There are several possible solutions (see for instance [XMPP‑DNA] (Lindberg, J. and S. Farrell, “Domain Name Assertions,” January 2010.):

• Terminate the hosting agreement. However, this is unpalatable to the company (IM is not their core competence) and the hosting provider (less revenue).
• Deploy DNS security extensions [DNSSEC] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.) 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.
• 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] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.), the Internet Message Access Protocol [IMAP] (Crispin, M., “INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1,” March 2003.), the Location-to-Service Translation Protocol [LOST] (Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, “LoST: A Location-to-Service Translation Protocol,” August 2008.), and the discovery of Location Information Servers [LIS] (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.).

3.  Security Considerations

This entire memo is about security.

4.  IANA Considerations

This document has no actions for the IANA.

5. Informative References

Authors' Addresses