One document matched: draft-barnes-hard-problem-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<rfc category='info' docName='draft-barnes-hard-problem-00' ipr='trust200902'>
<front>
<title abbrev="HARD Problem">High Assurance Re-Direction (HARD) Problem Statement</title>
<author initials="R." surname="Barnes" fullname="Richard Barnes">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>9861 Broken Land Parkway</street>
<city>Columbia</city>
<region>MD</region>
<code>21046</code>
<country>USA</country>
</postal>
<phone>+1 410 290 6169</phone>
<email>rbarnes@bbn.com</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wyknoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3282</phone>
<email>psaintan@cisco.com</email>
</address>
</author>
<date year="2010" month="July" day="2"/>
<area>Applications</area>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>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?</t>
<t>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.</t>
</section>
<section title="Security Challenges of Hosted Applications" anchor="model">
<t>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 <xref target='XMPP'/>. The company sets up DNS service location records <xref target='DNS-SRV'/> that point im.example.com at apps.example.net:</t>
<figure>
<artwork><![CDATA[
_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
]]></artwork>
</figure>
<t>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 <xref target='TLS'/> so her client checks the certificate offered by the XMPP service at the resolved IP address and port.</t>
<t>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 <xref target='XMPP-DNA'/>:</t>
<t>
<list style='symbols'>
<t>Terminate the hosting agreement. However, this is unpalatable to the company (IM is not their core competence) and the hosting provider (less revenue).</t>
<t>Deploy DNS security extensions <xref target='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.</t>
<t>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.</t>
</list>
</t>
<t>The same problem exists in a number of other technologies, including the Hypertext Transport Protocol <xref target='HTTP'/>, the Internet Message Access Protocol <xref target='IMAP'/>, the Location-to-Service Translation Protocol <xref target='LOST'/>, and the discovery of Location Information Servers <xref target='LIS'/>.</t>
</section>
<section title="Security Considerations" anchor="security">
<t>This entire memo is about security.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>This document has no actions for the IANA.</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor='DNS-SRV'>
<front>
<title abbrev='DNS SRV RR'>A DNS RR for specifying the location of services (DNS SRV)</title>
<author initials='A.' surname='Gulbrandsen' fullname='Arnt Gulbrandsen'>
<organization>Troll Tech</organization>
<address>
<postal>
<street>Waldemar Thranes gate 98B</street>
<city>Oslo</city>
<region />
<code>N-0175</code>
<country>NO</country></postal>
<phone>+47 22 806390</phone>
<facsimile>+47 22 806380</facsimile>
<email>arnt@troll.no</email></address></author>
<author initials='P.' surname='Vixie' fullname='Paul Vixie'>
<organization>Internet Software Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country></postal>
<phone>+1 650 779 7001</phone></address></author>
<author initials='L.' surname='Esibov' fullname='Levon Esibov'>
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country></postal>
<email>levone@microsoft.com</email></address></author>
<date month='February' year='2000' />
<abstract>
<t>This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.</t></abstract></front>
<seriesInfo name='RFC' value='2782' />
<format type='TXT' octets='24013' target='ftp://ftp.isi.edu/in-notes/rfc2782.txt' />
</reference>
<reference anchor='DNSSEC'>
<front>
<title>DNS Security Introduction and Requirements</title>
<author initials='R.' surname='Arends' fullname='R. Arends'>
<organization /></author>
<author initials='R.' surname='Austein' fullname='R. Austein'>
<organization /></author>
<author initials='M.' surname='Larson' fullname='M. Larson'>
<organization /></author>
<author initials='D.' surname='Massey' fullname='D. Massey'>
<organization /></author>
<author initials='S.' surname='Rose' fullname='S. Rose'>
<organization /></author>
<date year='2005' month='March' />
<abstract>
<t>The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS TRACK] </t></abstract></front>
<seriesInfo name='RFC' value='4033' />
<format type='TXT' octets='52445' target='ftp://ftp.isi.edu/in-notes/rfc4033.txt' />
</reference>
<reference anchor='HTTP'>
<front>
<title abbrev='HTTP/1.1'>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='UC Irvine'>Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email></address></author>
<author initials='J.' surname='Gettys' fullname='James Gettys'>
<organization abbrev='Compaq/W3C'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email></address></author>
<author initials='J.' surname='Mogul' fullname='Jeffrey C. Mogul'>
<organization abbrev='Compaq'>Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code></postal>
<email>mogul@wrl.dec.com</email></address></author>
<author initials='H.' surname='Frystyk' fullname='Henrik Frystyk Nielsen'>
<organization abbrev='MIT/LCS'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Xerox'>Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<email>masinter@parc.xerox.com</email></address></author>
<author initials='P.' surname='Leach' fullname='Paul J. Leach'>
<organization abbrev='Microsoft'>Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code></postal>
<email>paulle@microsoft.com</email></address></author>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='MIT/LCS'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email></address></author>
<date month='June' year='1999' />
<abstract>
<t>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers . A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
</t>
<t>
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .
</t></abstract></front>
<seriesInfo name='RFC' value='2616' />
<format type='TXT' octets='422317' target='ftp://ftp.isi.edu/in-notes/rfc2616.txt' />
<format type='PS' octets='5529857' target='ftp://ftp.isi.edu/in-notes/rfc2616.ps' />
<format type='PDF' octets='550558' target='ftp://ftp.isi.edu/in-notes/rfc2616.pdf' />
<format type='HTML' octets='498891' target='http://xml.resource.org/public/rfc/html/rfc2616.html' />
<format type='XML' octets='471630' target='http://xml.resource.org/public/rfc/xml/rfc2616.xml' />
</reference>
<reference anchor='IMAP'>
<front>
<title>INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1</title>
<author initials='M.' surname='Crispin' fullname='M. Crispin'>
<organization /></author>
<date year='2003' month='March' /></front>
<seriesInfo name='RFC' value='3501' />
<format type='TXT' octets='227640' target='ftp://ftp.isi.edu/in-notes/rfc3501.txt' />
</reference>
<reference anchor='LIS'>
<front>
<title>Discovering the Local Location Information Server (LIS)</title>
<author initials='M' surname='Thomson' fullname='Martin Thomson'>
<organization />
</author>
<author initials='J' surname='Winterbottom' fullname='James Winterbottom'>
<organization />
</author>
<date month='March' day='7' year='2010' />
<abstract><t>Discovery of the correct Location Information Server (LIS) in the local access network is necessary for devices that wish to acquire location information from the network. A method is described for the discovery of a LIS in the access network serving a device. Dynamic Host Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name. This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-geopriv-lis-discovery-15' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lis-discovery-15.txt' />
</reference>
<reference anchor='LOST'>
<front>
<title>LoST: A Location-to-Service Translation Protocol</title>
<author initials='T.' surname='Hardie' fullname='T. Hardie'>
<organization /></author>
<author initials='A.' surname='Newton' fullname='A. Newton'>
<organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
<organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'>
<organization /></author>
<date year='2008' month='August' />
<abstract>
<t>This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5222' />
<format type='TXT' octets='123252' target='ftp://ftp.isi.edu/in-notes/rfc5222.txt' />
</reference>
<reference anchor='TLS'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'>
<organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2008' month='August' />
<abstract>
<t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5246' />
<format type='TXT' octets='222395' target='ftp://ftp.isi.edu/in-notes/rfc5246.txt' />
</reference>
<reference anchor="XMPP">
<front>
<title abbrev='XMPP Core'>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P.' surname='Saint-Andre' fullname='Peter Saint-Andre' role='editor'>
<organization>Jabber Software Foundation</organization>
<address>
<email>stpeter@jabber.org</email></address></author>
<date year='2004' month='October' />
<area>Applications</area>
<workgroup>XMPP Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XMPP</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>Jabber</keyword>
<keyword>IM</keyword>
<keyword>Instant Messaging</keyword>
<keyword>Presence</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.</t></abstract></front>
<seriesInfo name='RFC' value='3920' />
<format type='TXT' octets='194313' target='ftp://ftp.isi.edu/in-notes/rfc3920.txt' />
<format type='HTML' octets='237435' target='http://xml.resource.org/public/rfc/html/rfc3920.html' />
<format type='XML' octets='234474' target='http://xml.resource.org/public/rfc/xml/rfc3920.xml' />
</reference>
<reference anchor='XMPP-DNA'>
<front>
<title>Domain Name Assertions</title>
<author initials='J' surname='Lindberg' fullname='Jonas Lindberg'>
<organization />
</author>
<author initials='S' surname='Farrell' fullname='Stephen Farrell'>
<organization />
</author>
<date month='January' day='14' year='2010' />
<abstract><t>An application-level approach to asserting and proving the delegated ownership of a domain name for XMPP.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-xmpp-dna-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-xmpp-dna-00.txt' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:29:58 |