One document matched: draft-miller-xmpp-dnssec-prooftype-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-miller-xmpp-dnssec-prooftype-03" ipr="trust200902">
<front>
<title abbrev="XMPP DANE Prooftype">Using DNS Security Extensions (DNSSEC) and DNS-based Authentication of Named Entities (DANE) as a Prooftype for XMPP Domain Name Associations</title>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<email>mamille2@cisco.com</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<email>psaintan@cisco.com</email>
</address>
</author>
<date month="January" day="10" year="2013"/>
<area>RAI</area>
<keyword>Internet-Draft</keyword>
<keyword>XMPP</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>Jabber</keyword>
<keyword>DNSSEC</keyword>
<keyword>DANE</keyword>
<abstract>
<t>This document defines a prooftype that uses DNS-based Authentication of Named Entities (DANE) for associating a domain name with an XML stream in the Extensible Messaging and Presence Protocol (XMPP). It also defines a method that uses DNS Security (DNSSEC) for securely delegating a source domain to a derived domain in XMPP.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>The <xref target="XMPP-DNA"/> specification defines a framework for secure delegation and authenticated domain name associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP). This document defines a a secure delegation method that uses DNS Security (DNSSEC) <xref target='RFC4033'/> in conjuction with the standard DNS SRV records <xref target='RFC2782'/> employed in domain name resolution in XMPP, with the result that a client or peer server that inititates an XMPP stream can legitimately treat a derived domain as a reference identifier during stream negotiation. This document also defines a prooftype for DNA that uses DNS-based Authentication of Named Entities <xref target='RFC6698'/> to verify TLS certificates containing source domains or derived domains during stream negotiation.</t>
</section>
<section title="Terminology" anchor="terms">
<t>This document inherits XMPP-related terminology from <xref target="RFC6120"/>, DNS-related terminology from <xref target='RFC1034'/>, <xref target='RFC1035'/>, <xref target='RFC2782'/> and <xref target="RFC4033"/>, and security-related terminology from <xref target='RFC4949'/> and <xref target='RFC5280'/>. The terms "source domain", "derived domain", "reference identifier", and "presented identifier" are used as defined in the "CertID" specification <xref target="RFC6125"/>.</t>
<t>This document is applicable to connections made from an XMPP client to an XMPP server ("_xmpp-client._tcp") or between XMPP servers ("_xmpp-server._tcp"). In both cases, the XMPP initiating entity acts as a TLS client and the XMPP receiving entity acts as a TLS server. Therefore, to simplify discussion this document uses "_xmpp-client._tcp" to describe to both cases, unless otherwise indicated.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target='RFC2119'/>.</t>
</section>
<section title="Requirements" anchor="reqs">
<t>An XMPP initiating entity (TLS client) that wishes to use this prooftype MUST do so before exchanging stanzas addressed to the source domain. In general, this means that the proof MUST be completed before the XMPP stream is restarted following STARTTLS negotiation (as specified in <xref target="RFC6120"/>). However, connections between XMPP servers MAY also use this prooftype to verify the addition of new source domains onto an existing connection, such as multiplexing or "piggybacking" via <xref target="XEP-0220"/>.</t>
</section>
<section title="Secure Delegation" anchor="delegation">
<t>An XMPP initiating entity (TLS client) that wishes to use this prooftype performs the following actions:</t>
<t>
<list style="numbers">
<t>Query for the appropriate SRV resource record for the source domain (e.g. "_xmpp-client._tcp.im.example.com").<vspace blankLines="1"/></t>
<t>If there is no SRV resource record, pursue the fallback methods described in <xref target='RFC6120'/>.<vspace blankLines='1'/></t>
<t>If there is an SRV resource record, validate that the SRV record answer is secure according to <xref target='RFC4033'/>. If the answer is insecure, then delegation to the derived domain(s), as indicated by the "target host" field, is insecure and the TLS client MUST treat only the source domain as a reference identifier during certificate verification, as described in <xref target='RFC6120'/>; if the answer is bogus, the TLS client MUST abort.<vspace blankLines="1"/></t>
<!--
<t>If there is an SRV record, for each derived domain from the SRV record answer (e.g. "hosting.example.net"), query for the "A" and/or "AAAA" resource records as described in <xref target='RFC6120'/>.<vspace blankLines="1"/></t>
<t>For each derived domain, validate that the address record answers are secure according to <xref target='RFC4033'/><vspace blankLines='1'/></t>
<t>If any answer is insecure, then the TLS client MUST NOT consider a connection to that derived domain as securely delegated from the source domain; when verifying the certificate, the TLS client MUST do so against the source domain as described in <xref target='RFC6120'/>.<vspace blankLines="1"/></t>
-->
<t>If the answer is secure, the TLS client SHOULD consider any derived domain(s) in the answer as securely delegated; during certificate verification, the TLS client MUST treat both the source domain and the derived domain to which it has connected as reference identifiers.</t>
</list>
</t>
</section>
<section title="Prooftype" anchor="prooftype">
<t><xref target="RFC6698"/> provides additional tools to verify the keys used in TLS connections. A TLS client MAY use <xref target="RFC6698"/> for TLS certificate verification; its use depends on the delegation status of the source domain, as described in the following sections.</t>
<section title="No Service Records" anchor="prooftype-none">
<t>If no SRV records are found for the source domain, then the TLS client MUST query for a TLSA resource record as described in <xref target='RFC6698'/>, where the prepared domain name MUST contain the source domain and the IANA-registered port 5222 for client-to-server streams (e.g. "_5222._tcp.im.example.com") or the IANA-registered port 5269 for server-to-server streams (e.g. "_5269._tcp.im.example.com").</t>
<t>In this case, the TLS client MUST treat only the source domain as its reference identifier during certificate verification, as described in <xref target='RFC6120'/>.</t>
</section>
<section title="Insecure Delegation" anchor="prooftype-insecure">
<t>If the delegation of a source domain to a derived domain is not secure, then the TLS client MUST NOT make a TLSA record query to the derived domain as described in <xref target="RFC6698"/>. Instead, the TLS client MUST treat only the source domain as its reference identifier during certificate verification, as described in <xref target='RFC6120'/>, and MUST NOT use <xref target="RFC6698"/>.</t>
</section>
<section title="Secure Delegation" anchor="prooftype-secure">
<t>If the source domain has been delegated to a derived domain in a secure manner as described under <xref target='delegation'/>, then the TLS client MUST query for a TLSA resource record as described in <xref target='RFC6698'/>, where the prepared domain name MUST contain the derived domain and a port obtained from the SRV answer (e.g., "_5555._tcp/hosting.example.net" for an SRV record such as "_xmpp-client._tcp.im.example.com IN TLSA 1 1 5555 hosting.example.net").</t>
<t>If no TLSA resource records exist for the specified service, then the TLS client MUST perform certificate verification as described under <xref target='delegation'/>.</t>
<t>If TLSA resource records exist for the specified service, then the TLS client MUST treat the derived domain(s) as its reference identifier during certificate verification, using the information from the TLSA answer as the basis for verification as described in <xref target='RFC6698'/>.</t>
</section>
<!--
<section title="TLSA Certificate Usage 3 Considerations" anchor="prooftype-usage-3">
<t>If a TLSA resource record specifies certificate usage 3 (also known as "domain-issued certificate"), verification MUST NOT consider the source or derived domain. Instead, the target certificate MUST match the TLSA record, as specified in <xref target="RFC6698"/>. If matched, the TLS connection MUST considered valid for the source domain regardless of the target certificate's information.</t>
</section>
-->
</section>
<section title="Internationalization Considerations" anchor="i18n">
<t>If the SRV, A/AAAA, and TLSA record queries are for an internationalized domain name, then they need to use the A-label form as defined in <xref target='RFC5890'/>.</t>
</section>
<section title="Security Considerations" anchor="security">
<t>This document supplements but does not supersede the security considerations provided in <xref target='RFC4033'/>, <xref target='RFC6120'/>, <xref target='RFC6125'/>, and <xref target='RFC6698'/>.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>This document has no actions for the IANA.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='RFC1034'>
<front>
<title abbrev='Domain Concepts and Facilities'>Domain names - concepts and facilities</title>
<author initials='P.' surname='Mockapetris' fullname='P. Mockapetris'>
<organization>Information Sciences Institute (ISI)</organization>
</author>
<date year='1987' day='1' month='November' />
</front>
<seriesInfo name='STD' value='13' />
<seriesInfo name='RFC' value='1034' />
<format type='TXT' octets='129180' target='http://www.rfc-editor.org/rfc/rfc1034.txt' />
</reference>
<reference anchor='RFC1035'>
<front>
<title abbrev='Domain Implementation and Specification'>Domain names - implementation and specification</title>
<author initials='P.' surname='Mockapetris' fullname='P. Mockapetris'>
<organization>USC/ISI</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>
<phone>+1 213 822 1511</phone>
</address>
</author>
<date year='1987' day='1' month='November' />
</front>
<seriesInfo name='STD' value='13' />
<seriesInfo name='RFC' value='1035' />
<format type='TXT' octets='125626' target='http://www.rfc-editor.org/rfc/rfc1035.txt' />
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>-</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
<list><t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.</t></list>
</t>
<t>Note that the force of these words is modified by the requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor='RFC2782'>
<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 year='2000' month='February' />
<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='http://www.rfc-editor.org/rfc/rfc2782.txt' />
</reference>
<reference anchor="RFC4033">
<front>
<title>DNS Security Introduction and Requirements</title>
<author initials="R." surname="Arends" fullname="Roy Arends">
<organization>Telematica Instituut</organization>
<address>
<email>roy.arends@telin.nl</email>
</address>
</author>
<author initials="R." surname="Austein" fullname="Rob Austein">
<organization>Internet Systems Consortium</organization>
<address>
<email>sra@isc.org</email>
</address>
</author>
<author initials="M." surname="Larson" fullname="Matt Larson">
<organization>VeriSign, Inc.</organization>
<address>
<email>mlarson@verisign.com</email>
</address>
</author>
<author initials="D." surname="Massey" fullname="Dan Massey">
<organization>Colorado State University</organization>
<address>
<email>massey@cs.colostate.edu</email>
</address>
</author>
<author initials="S." surname="Rose" fullname="Scott Rose">
<organization>National Institute for Standards and Technology</organization>
<address>
<email>scott.rose@nist.gov</email>
</address>
</author>
<date month="May" year="2005"/>
</front>
<seriesInfo name="RFC" value="4033"/>
<format type="TXT" target="http://tools.ietf.org/rfc/rfc4033.txt"/>
</reference>
<reference anchor="RFC4949">
<front>
<title>Internet Security Glossary, Version 2</title>
<author initials="R." surname="Shirey" fullname="R. Shirey">
<organization/>
</author>
<date year="2007" month="August"/>
<abstract>
<t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4949"/>
<format type="TXT" octets="867626" target="ftp://ftp.isi.edu/in-notes/rfc4949.txt"/>
</reference>
<reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials="D." surname="Cooper" fullname="D. Cooper">
<organization/>
</author>
<author initials="S." surname="Santesson" fullname="S. Santesson">
<organization/>
</author>
<author initials="S." surname="Farrell" fullname="S. Farrell">
<organization/>
</author>
<author initials="S." surname="Boeyen" fullname="S. Boeyen">
<organization/>
</author>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/>
</author>
<author initials="W." surname="Polk" fullname="W. Polk">
<organization/>
</author>
<date year="2008" month="May"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<format type="TXT" octets="352580" target="ftp://ftp.isi.edu/in-notes/rfc5280.txt"/>
</reference>
<reference anchor='RFC5890'>
<front>
<title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization />
</author>
<date year='2010' month='August' />
<abstract>
<t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='5890' />
<format type='TXT' octets='54245' target='http://www.rfc-editor.org/rfc/rfc5890.txt' />
</reference>
<reference anchor="RFC6120">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<date month="March" year="2011"/>
</front>
<seriesInfo name="RFC" value="6120"/>
<format type="TXT" target="http://tools.ietf.org/rfc/rfc6120.txt"/>
</reference>
<reference anchor="RFC6125">
<front>
<title>Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<author initials="J." surname="Hodges" fullname="Jeff Hodges">
<organization>PayPal</organization>
<address>
<email>jeff.hodges@paypal.com</email>
</address>
</author>
<date month="March" year="2011"/>
</front>
<seriesInfo name="RFC" value="6125"/>
<format type="TXT" target="http://tools.ietf.org/rfc/rfc6125.txt"/>
</reference>
<reference anchor='RFC6698'>
<front>
<title>The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization />
</author>
<author initials='J.' surname='Schlyter' fullname='J. Schlyter'>
<organization />
</author>
<date year='2012' month='August' />
<abstract>
<t>Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='6698' />
<format type='TXT' octets='84034' target='http://www.rfc-editor.org/rfc/rfc6698.txt' />
</reference>
<reference anchor="XEP-0220">
<front>
<title>Server Dialback</title>
<author initials="J" surname="Miller" fullname="Jeremie Miller">
<address>
<email>jer@jabber.org</email>
</address>
</author>
<author initials="P" surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<author initials="P" surname="Hancke" fullname="Philipp Hancke">
<address>
<email>fippo@goodadvice.pages.de</email>
</address>
</author>
<date month="August" year="2011"/>
</front>
<seriesInfo name="XSF XEP" value="0220"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0220.html#appendix-authorinfo"/>
</reference>
<reference anchor="XMPP-DNA">
<front>
<title>Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization>Cisco</organization>
<address>
<email>mamille2@cisco.com</email>
</address>
</author>
<date month="June" year="2012"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-saintandre-xmpp-dna-00"/>
<format type="TXT" target="http://tools.ietf.org/html/draft-sainandre-xmpp-dna-00.txt"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:35:11 |