One document matched: draft-barnes-xmpp-dna-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="no"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-barnes-xmpp-dna-00.txt" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Domain Name Assertions">Domain Name Assertions</title>
<!--add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Richard Barnes" initials="R." surname="Barnes">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>9861 Broken Land Pkwy, Suite 400</street>
<!-- Reorder these if your country does things differently -->
<city>Columbia</city>
<region>MD</region>
<code>21046</code>
<country>USA</country>
</postal>
<phone>+1 410 290 6169</phone>
<email>rbarnes@bbn.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="August" year="2010" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<abstract>
<t>Many Internet applications allow service delegation via the DNS.
However, in the absence of DNSSEC, these delegations are
unauthenticated, so clients have to authenticate the delegate as if he
were the original service. This situation causes several operational
problems. This document describes a mechanism for clients to discover
and validate information that authenticates DNS-based service
delegations, without relying on the global deployment of DNSSEC.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Many Internet applications use the DNS for service discovery and
delegation. The most long-standing example of this usage of the DNS is
of course the use of MX records to discover mail servers <xref
target="RFC0974"></xref>. That pattern has been re-used with modern
services, having been generalized through the introduction of SRV
records and the Dynamic Delegation Discovery System (DDDS) <xref
target="RFC2782"></xref><xref target="RFC3401"></xref>. For example,
XMPP and SIP services are found using SRV records <xref
target="RFC3920"></xref><xref target="RFC3263"></xref>, while LoST and
HELD services use NAPTR records (i.e., they use DDDS) <xref
target="RFC5222"></xref><xref
target="I-D.ietf-geopriv-http-location-delivery"></xref>.</t>
<t>Because these records direct a client from one domain to another (an
"source" name to a "target" name), they can create challenges for server
authentication. When the client ultimately connects to a remote
endpoint, should the client expect it to authenticate as the source or
the target? The answer to this question has important operational
impact, especially in situations where the source and target domains are
operated by different entities.</t>
<t>If the client cannot verify that the DNS records involved in the
delegation are authentic, then these records cannot be trusted. Since
spoofed delegation records could be used to point the client to an
attacker's server (e.g., to insert a man-in-the-middle), the client must
require the server to authenticate as the source domain.</t>
<t>For example: 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
XMPP. The company sets up DNS service location records that point
im.example.com at apps.example.net:</t>
<t></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></t>
<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="RFC5246"></xref> 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.</t>
<t>If the delegation records in question are authenticated, then the
client can verify that the service has indeed been delegated to the
target domain, and can authenticate the server as the target. This
authentication can be provided with DNSSEC <xref
target="RFC4033"></xref>, but only if the signatures on the delegation
records chain back to a key that the client accepts as a trust anchor
(ideally, the root key). In the current DNSSEC deployment environment,
only a few domains have full chains back to the root, and there is no
general agreement on trust anchors other than the root.</t>
<t>This document discusses an intermediate solution for authenticating
DNS delegation records in situations where DNSSEC cannot be used. We
define a general process that clients can use to determine whether to
use the source or target domain as the identifier that a server must
authenticate, then consider some specific techniques for accomplishing
this general procedure and their practical trade-offs.</t>
</section>
<section anchor="term-sec" title="Terminology">
<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 <xref
target="RFC2119"></xref>.</t>
<t>This document uses the word "delegation" to encompass several
different mechanisms for delegating services from one name to another
using the DNS, including MX records, SRV records, and the DDDS. These
mechanisms delegate services from one DNS name to another. We call the
name being delegated the "source name" or "source domain" and the
recipient of the delegation and the recipient of the delegation the
"target" name or domain. We do not distinguish the case where the output
of the delegation may be something other than a domain name (e.g., a
URI), as can happen in DDDS.</t>
<t>We generally consider these delegations in the form of a single
record; in cases where multiple delegations are chained together (as can
happen in DDDS), the techniques here may be repeated.</t>
<t>Delegation records will be authenticated using signed data objects,
which we generally refer to as "authenticators". Clients find these data
objects using an "authenticator discovery" process based on the source
domain whose services they are seeking.</t>
</section>
<section anchor="general-sec" title="General Procedure">
<t>When a client seeks to connect to a service that is located using DNS
delegation records, it needs to be able to authenticate the validity of
these records so that it knows whether to authenticate the located
server as the source or target domain. The general process for
discovering and authenticating a delegation is as follows:</t>
<t><list style="numbers">
<t>The client retrieves the delegation record (e.g., MX, SRV,
NAPTR).</t>
<t>If the delegation record is protected by DNSSEC, chaining back to
one of the client's trust anchors, then the client matches the
server's authenticated identity against the target name for the
delegation.</t>
<t>The client queries for an authenticator for the delegation
record.</t>
<t>If an authenticator is present, the client validates that it
corresponds to the delegation record and that it is issued by a
trusted authority.</t>
<t>If the authenticator is present and valid, the client matches the
server's authenticated identity against the target name for the
delegation.</t>
<t>Otherwise, the client matches against the source name for the
delegation.</t>
</list></t>
<t>The specific procedures for authenticator discovery and validation
are discussed in <xref target="discovery-sec"></xref> and <xref
target="validation-sec"></xref>.</t>
<t>Note that this procedure smoothly degrades as DNSSEC becomes more
widely available. Technically speaking, DNSSEC signatures could be
considered as a form of authenticator, but because of the importance of
transition for this mechanism (and because of some conceptual
differences from other authenticators), the procedure above accommodates
with a specific "short cut".</t>
</section>
<section anchor="discovery-sec" title="Authenticator Discovery">
<t>To allow clients to authenticators delegation records, there needs to
be a way for them to gain access to the signed objects or
"authenticators" that attest to the delegation. There are basically
three points in the connection process where an authenticator can be
provided:</t>
<t><list style="numbers">
<t>Before connection establishment, as part of the DNS</t>
<t>During connection establishment, as part of the security
protocol</t>
<t>After connection establishment, as part of the application</t>
</list></t>
<t>In the below sections, we outline how authenticators can be provided
in each of these cases, and discuss their relative merits.</t>
<t></t>
<section title="DNS-Based Discovery">
<t>Since all of the below authenticator formats are based on digital
certificates, source domain operators can publish them using DNS CERT
records <xref target="RFC4398"></xref> under a well-known name related
to the source name. For example, if im.example.com is delegating its
XMPP services to apps.example.net, and authenticating with an X.509
certificate (to be obtained from a URL), it would provision the
following records:</t>
<figure>
<artwork><![CDATA[_xmpp-client._tcp.im.example.com. 90 IN SRV 0 0 5222 apps.example.net
_dna._xmpp-client._tcp.im.example.com. 90 IN CERT 4 12345 5
http://example.com/im.crt
_xmpp-server._tcp.im.example.com. 90 IN SRV 0 0 5269 apps.example.net
_dna._xmpp-server._tcp.im.example.com. 90 IN CERT 4 12345 5
http://example.com/im.crt]]></artwork>
</figure>
<t></t>
<t>A client can then construct the name for the delegation (the source
name) using any technique defined by the delegation mechanism, then
append the reserved label "_dna" to find the authenticator for the
delegation. (As a simplification, one might also consider simply
provisioning the CERT record under the same name as the delegation
record. The _dna label is useful, however, to distinguish these
certificates from certificates used for other purposes.)</t>
<t>This discovery mechanism has the benefit of directness.
Authenticators have to ultimately originate with the source domain,
since that is the domain that is authoritative for the delegation. In
the other two cases below, the authenticator has to be provided to the
target server, who then provides it to the client, while in this case,
the client can simply receive the authenticator directly from the
source domain.</t>
<t>Likewise, this technique is very general. It is completely agnostic
to the type of security protocol or application protocol being used,
and requires no changes to either protocol. It also applies without
modification to all the different record types that can be used for
delegation.</t>
<t>One challenge for this technique, as for the application-layer
discovery discussed below, is the question of how the source domain
can present a certificate chain to help the client validate the
authenticator. It may be possible to address this challenge by
including multiple CERT records under the same domain name. These
certificate can either be considered as an unordered list, leaving the
client to assemble them together into a certificate chain, or as an
sequence ordered by the preference values in the records.</t>
</section>
<section title="Security-Protocol Discovery">
<t>Security protocols already have syntax for endpoints to provide
authentication credentials of enough different types to cover the
different authenticator formats discussed below. However, providing
these authenticators as part of the establishment of a secure channel
is generally not practical.</t>
<t>For example, at the time of session establishment, a server
typically has to provide authentication credentials before it knows
what identity the client is expecting, so a server that hosts many
domains would need to have a single certificate that covers all
possible delegations pointing to it. In addition to creating very
large credentials, such credentials would need to be re-issued
whenever a delegation changed. A server would thus need effectively
the same credential as if it were simply authenticating the source
domain of the delegation, with the same operational issues, negating
any benefit to authenticating the delegation.</t>
</section>
<section title="Application-Layer Discovery">
<t>Several applications include mechanisms for protocol endpoints to
challenge one another for authentication credentials. In XMPP, for
example, one endpoint can issue a <challenge> stanza indicating
what sort of proof is desired, and the other endpoint can reply with a
<response> stanza containing the required authenticator. HTTP
uses the WWW-Authenticate and Authorization headers in a similar
way.</t>
<t>In order to use this mechanisms to authenticate a delegated
service, the client would need to provisionally accept the credentials
presented by the server in the security protocol. It would also have
to make sure that no other protocol interactions occur before the
authenticator has been received and validated.</t>
<t>The main benefit of handling delegation authentication at the
application layer is that protocol interactions can be very rich.
Applications that incorporate the SASL framework (such as XMPP) can
benefit from the security semantics that it provides <xref
target="RFC4422"></xref>. The obvious challenge, however, is that each
application that wishes to benefit from authenticated delegations will
have to have its own extension to carry authenticators. In addition,
the requirement to provisionally accept a secure connection could
impose additional complexity and resource requirements on the
client.</t>
</section>
</section>
<section anchor="validation-sec"
title="Authenticator Formats and Validation">
<t>An authenticator is a signed object that attests to the validity of a
given delegation by presenting a version of it that is signed by the
source domain. In this section we discuss three possible forms that such
an authenticator can take, and their relative merits.</t>
<t>In evaluating these authenticator formats, it's important to keep in
mind a few requirements. An authenticator must have two basic parts, a
representation of the delegation that is being authenticated, and
signature over that representation that can be verified using a private
key bound to the source domain. It is important that the signature
attesting to the validity be from the source domain, since the source
domain is the entity making the delegation. If another entity were to
attest the delegation by presenting an authenticator under its
signature, then there would be a need to verify that it was authorized
to do so by the source domain.</t>
<t>In addition to these structural requirements, there is a practical
requirement that the issuance and revocation of authenticators should
not be difficult using current certificate management software and
practices. Some particular usability questions that will come up are
whether a single authenticator can be used for multiple services, and
whether an authenticator can be applied to all the different kinds of
delegation records.</t>
<t>The basic security assumption for all of the below formats is that
the source domain operator has a certificate that binds the source
domain name to a public key, and that this certificate chains up to a
trust anchor recognized by the client. We will refer to this certificate
as the source domain's "authentication certificate" below. In general,
when we mention a name in a certificate, we allow for this name to be
provided either as a Common Name or a dNSName Subject Alternative Name
(the latter being preferred, but the former included for backward
compatibility).</t>
<section title="Attribute Certificate">
<t>Format: An attribute certificate using the format specified in
[draft-ietf-xmpp-dna]. The delegation is encoded in the relationship
between the subject and the issuer, and in the service field of the
certificate. The issuer is the source, the subject is the target, and
the OID in the service field specifies the service being delegated.
The signature over the delegation is the signature on the
certificate.</t>
<t>Validation: The client validates the attribute certificate using
the public key in the source domain's authentication certificate, then
validates the authentication certificate.</t>
<t>Revocation: No direct revocation, only expiration of the attribute
cert or revocation of the authentication cert.</t>
<t>Evaluation: This mechanism is fairly straightforward to implement
with current commercially-available domain certificates, since
attribute certs are issued by end-entity certificates from a PKI. With
current libraries, however, support for attribute certificates is
limited relative to public-key certificates and DNSSEC signatures (the
other two cryptographic techniques used in this document); both the
source domain and the client would need to be able to process
attribute certificates.</t>
<t>Using attribute certificates also imposes some limits on the re-use
of certificates. Becase the service being delegated is encoded in the
certificate, each service delegated requires a different certificate.
In addition, while this approach is well-suited for SRV records, it is
not clear how it would work for other types of delegation.</t>
</section>
<section title="DNSSEC External Trust Anchor">
<t>Format: The original domain's authentication certificate and an
RRSIG record over the delegation record or an RR set containing it,
using the private key corresponding to the public key in the
authentication certificate. The delegation is encoded in the
delegation record, and the signature over the delegation is the RRSIG
record.</t>
<t>Validation: The client validates that the RRSIG has a valid DNSSEC
signature over the delegation record or RR set using the public key in
the source domain's authentication certificate, then validates the
authentication certificate.</t>
<t>Revocation: Removal of the RRSIG record (or removal of the
delegation record from the RR set), or revocation of the
authentication certificate.</t>
<t>Evaluation: As with the DNS-based discovery approach described
above, the use of external trust anchors has the benefit of
generality. Because the delegation is not re-encoded in any way (e.g.,
by being transcribed into a certificate), the signature can be applied
to any type of record, and no semantics are added or lost. The same
key and certificate can be used for several different RRSIGs or
delegations. Issusing authenticators of this type only requires the
source domain to have an end-entity certificate, not a CA
certificate.</t>
<t>The major challenge for this approach is figuring out how it
integrates with operational practices, in particular with regard to
certificate management and DNS operations. Using certificates as
DNSSEC external trust anchors requires that the key pair used to
construct the RRSIG also be included in the source domain's public key
certificat. This should not be a problem, since the subject of a
certificate can choose the key that is included. Note that this
requirement doesn't necessarily mean that the key pair needs to be
used for anything other than DNSSEC; the source domain could obtain
separate certificates for other purposes (e.g., HTTPS).</t>
<t>The other operational concern arises with regard to the requirement
that the client be able to validate an RRSIG record, effectively
managing the set of DNSSEC trust anchors. In particular, because of
this need for local trust anchor management, the client cannot make
use of any DNSSEC support in the DNS infrastructure, e.g., validating
resolvers. As long as the client can retrieve the proper RRSIG record,
however, the process should work. (That request can of course be
routed through the normal DNS system, resolvers and all.)</t>
</section>
<section title="PKIX Certificate with SRVName">
<t>Format of the authenticator: X.509 certificate containing an
SRVName Subject Alternative Name <xref target="RFC5280"></xref><xref
target="RFC4985"></xref>, issued by the source domain. The delegation
is encoded in the issuer and SRVName in the certificate. The source
domain is encoded in both the issuer's name and in the SRVName (which
thus must both have the same name), and the target domain is encoded
in the subject's name. The SRVName also contains an indication of the
service being delegated.</t>
<t>Validation: The client verifies that the service and names in the
certificate matche the service and names in the delegation, then
validates the certificate following the normal X.509 validation
algortihm.</t>
<t>Revocation: Normal X.509 revocation.</t>
<t>Evaluation: Using SRVName as a mechanism for authenticating
delegations leads to several deployment challenges. Because the
certificate needs to be issued by the source domain, the source domain
will need to have a CA certificate; CA certificates are commonly much
more costly than end-entity certificates. Certificates can be re-used,
with a different SRVName for each service being delegated, but they
clearly cannot be used for any delegation method that uses a record
type other than SRV.</t>
</section>
</section>
<section anchor="acknowledgements-sec" title="Acknowledgements">
<t>We would like to thank Joe Hildebrand and Sean Turner for first
articulating the problem of authenticating delegated services, in the
context of XMPP, and Peter Saint-Andre for helping generalize that
discussion.</t>
</section>
<section anchor="security-sec" title="Security Considerations">
<t>This document defines a mechanism for authenticating DNS-based
delegations in support of authentication based on domain names. This
functionality can be provided using DNSSEC, but that requires that all
the parents of the delegated domain support DNSSEC as well as the
delegating domain itself. The mechanisms discussed in this document
provide a transitional step that allows the authenticity of DNS records
to be rooted in an alternative hierarchy, namely a hierarchy of X.509
certificates. Since this mechanism is intended to be transitional, it
includes a specific provision that prevents its use when DNSSEC is
available.</t>
</section>
<section anchor="iana-sec" title="IANA Considerations">
<t>This document currently makes no request of IANA. If DNS_based
discovery is used, then this document will register the label "_dna" to
be used for discovering certificates.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3401.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-xmpp-dna.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4398.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4422.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4985.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.0974.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3920.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-http-location-delivery.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:38:38 |