[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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


   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.

              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.

              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

   Phone: +1 410 290 6169
   Email: rbarnes@bbn.com

   Peter Saint-Andre
   Cisco Systems, Inc.
   1899 Wyknoop Street, Suite 600
   Denver, CO  80202

   Phone: +1-303-308-3282
   Email: psaintan@cisco.com

Barnes & Saint-Andre     Expires January 3, 2011                [Page 5]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/