draft-ietf-xmpp-dna-00.txt   draft-ietf-xmpp-dna-01.txt 
Network Working Group J. Lindberg Network Working Group R. Barnes
Internet-Draft Google Internet-Draft BBN Technologies
Intended status: Standards Track S. Farrell Intended status: Standards Track J. Lindberg
Expires: July 18, 2010 NewBay Software Expires: September 15, 2011 Google
January 14, 2010 March 14, 2011
Domain Name Assertions Domain Name Assertions
draft-ietf-xmpp-dna-00 draft-ietf-xmpp-dna-01
Abstract Abstract
An application-level approach to asserting and proving the delegated The current authentication process in XMPP requires the XMPP server
ownership of a domain name for XMPP. for a domain to present a certificate that contains that domain's
name. This requirement causes several problems in scenarios where
XMPP services have been delegated from one domain to another,
especially when one domain provides XMPP services for many domains.
This document describes an extension to the XMPP authentication
process that allows domains to be securely delegated, simplifying
authorization in delegation scenarios.
Requirements Language
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 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on September 15, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 18, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Connection Model . . . . . . . . . . . . . . . . . . . . . . . 8
5. Generic Use Cases . . . . . . . . . . . . . . . . . . . . . . 5 5. Channel Establishment and Authentication . . . . . . . . . . . 9
5.1. Assertions . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Authorizing XMPP Stanzas . . . . . . . . . . . . . . . . . . . 13
5.2. Validation . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 15
5.3. Invalidation . . . . . . . . . . . . . . . . . . . . . . . 5 8. Operational Considerations . . . . . . . . . . . . . . . . . . 16
5.4. Requesting proof with a challenge . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5.5. No proof possible . . . . . . . . . . . . . . . . . . . . 6 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.6. Proving a challenge . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
6. Attribute Certificate Proof . . . . . . . . . . . . . . . . . 7 12. Normative References . . . . . . . . . . . . . . . . . . . . . 17
6.1. Attribute Certificate Issuer Profile . . . . . . . . . . . 8
6.2. Attribute Certificate Profile . . . . . . . . . . . . . . 8
6.3. Access Identity Values . . . . . . . . . . . . . . . . . . 8
6.3.1. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.4. Attribute Certificate Signature Algorithms . . . . . . . . 9
6.5. Proof Encoding . . . . . . . . . . . . . . . . . . . . . . 9
7. DNA for XMPP Federation . . . . . . . . . . . . . . . . . . . 9
7.1. DNS SRV lookups . . . . . . . . . . . . . . . . . . . . . 10
7.2. Certificates during Start-TLS . . . . . . . . . . . . . . 10
7.3. Discovering Support . . . . . . . . . . . . . . . . . . . 11
7.4. Turning on DNA . . . . . . . . . . . . . . . . . . . . . . 11
7.5. Asserting new domains . . . . . . . . . . . . . . . . . . 12
7.6. Proactive challenges . . . . . . . . . . . . . . . . . . . 12
7.7. Proactive validation . . . . . . . . . . . . . . . . . . . 12
7.8. Reusing streams . . . . . . . . . . . . . . . . . . . . . 13
7.9. Implementation notes . . . . . . . . . . . . . . . . . . . 13
8. DNA for XMPP client connections . . . . . . . . . . . . . . . 13
8.1. Announcing Support . . . . . . . . . . . . . . . . . . . . 14
8.2. Client challenges for proof . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. XML Namespace Name for DNA . . . . . . . . . . . . . . . . 14
9.2. URN space for standard DNA Proof Types . . . . . . . . . . 14
9.3. DNA Proof Registry . . . . . . . . . . . . . . . . . . . . 15
9.4. Object Identifiers . . . . . . . . . . . . . . . . . . . . 15
10. Internationalization Considerations . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. RELAX NG XML Schema . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
As large hosting providers begin providing XMPP services for multiple When connecting two XMPP services to provide inter-domain
domains, several issues with previous mechanisms for server-to-server communication, it is important for a service to be able to determine
federation have become apparent. the identity of a peer service to prevent traffic spoofing. The
Jabber communities first approach to identity verification was the
A large number of sockets are currently required between hosting Server Dialback protocol. When the Jabber protocols were formalized
providers. Although servers may attempt to piggyback whenever by the XMPP working group of the IETF 2002-04, support for strong
possible, the possibility exists that 2*N*M sockets will be created identity verification using TLS + SASL was added.
(where N is the number of domains on one hosting provider, and M is
the number of domains on another hosting provider). The goal would
be that the number of sockets was dependent on load or deployment
considerations.
In order to enable or require encryption, the hosting provider must Server Dialback [XEP-0220] provides weak identity verification and
create a separate socket for each hostname pair and have access to a makes it more difficult to spoof hostnames of servers XMPP network.
X.509 certificate that is signed by a widely-trusted CA and includes However, it does not provide authentication between servers and is
both the public and private keys. Customers of hosting providers not a security mechanism. It is susceptible to DNS poisoning attacks
might be uncomfortable with the level of trust this requires. (unless DNSSEC is used) and cannot protect against attackers capable
of hijacking the IP address of a remote service.
This document lays out an approach known as Domain Name Assertions TLS + SASL provides strong identity verification but requires a
(DNA) that allows providers to effectively host XMPP services on obtaining a digital certificate by a trusted CA (or the XMPP
behalf of other companies, and might be expanded later to support Intermediate Certification Authority) and using it in the XMPP
other protocols. service, which may be hosted by a 3rd party. This solution does not
allow for multiplexing traffic for multiple domain pairs over a
connection, possibly requiring a large number of connections between
two hosting providers.
2. Acknowledgements Server Dialback can be used with TLS. When STARTTLS negotiation
succeeds with a peer service but the peer's certificate cannot be
used to establish the peer's identity, the remote domain may use on
Server Dialback for (weak) identity verification. One use case can
be an originating server that wish to use TLS for encryption, but
only can present a self signed certificate.
The original version of this specification was written by Joe In practice, many XMPP server deployments rely on Server Dialback and
Hildebrand and Sean Turner. either do not support XMPP 1.0 or do not offer negotiation of TLS +
SASL.
3. Glossary This goal of this document is to describe secure authentication using
a hosting provide TLS certificate from a trusted CA, combined with a
dialback mechanism providing secure delegation based on DNS record
delgation verified using DNSSEC.
Hosted domain An XMPP domain whose network services are delegated to 2. Terminology
a third party.
Hosting provider A business entity that provides services for one or
more domains that it does not directly and fully control.
Self-hosted domain A domain whose owner acts as its hosting
provider.
Delegation A ceremony that acts as proof of the intent of the owner
of a hosted domain to cede control to a hosting provider for a
given protocol.
Widely-trusted CA For open communities, a Certificate Authority
whose certificate that is trusted by multiple web browsers by
default. For closed communities, a Certificate Authority that is
trusted by all members of that community.
Sender Domain The domain associated with the 'from' address on a The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
stanza to be sent across a federation boundary. "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
Target Domain The domain associated with the 'to' address on a "OPTIONAL" in this document are to be interpreted as described in RFC
stanza to be sent across a federation boundary. 2119 [RFC2119].
Originating Server The machine that wants to send a message from an
entity at the Sender Domain to an entity at the Target Domain and
thus is attempting to establish a connection between the two
servers.
Receiving Server The machine to which the Originating Server has
opened a connection for the purpose of sending a message from the
Sender Domain to the Target Domain.
Asserting Entity A system element (such as a server) asserting a
given domain name as an identity.
Validating Entity A system element (such as a client or server) that
checks a given identity asserted by an asserting entity.
Asserted Domain A domain name asserted by either side of a
conversation. validating entities may require assertions to be
backed up with proof.
Proof A secure mechanism through which a validating entity can
ascertain that an asserting entity has authority for the asserted
domain, either directly or indirectly (by delegation).
4. Requirements We will refer to four different types of domains in this document:
1. A hosting provider MUST be able to service domains for which it o Sender domain: The domain that initially sends out an XMPP message
cannot obtain certificates signed by a widely-trusted CA.
2. All network traffic (except for initial handshakes) MUST be
encrypted in a manner not subject to man-in-the-middle attacks.
3. The number of socket connections between hosting providers MUST
NOT be a function of the number of domains hosted by either
provider.
4. Connections MUST be usable in either direction, if allowed by
policy and deployment considerations.
5. The owners of the hosted domain MUST NOT be required to give out
private keying material associated with any certificate they own
that has been signed by a widely-trusted CA.
6. The owners of the hosted domain MUST be allowed to choose the
frequency with which they wish to perform the delegation
ceremony.
7. The owners of the hosted domain MUST be allowed to revoke their
delegation at any time.
8. Multiple mechanisms for proving delegation MUST be possible.
9. It MUST be possible for new assertions to be added to a stream at
any point after the stream is fully established, but before the
stream is closed
5. Generic Use Cases o Target domain: The ultimate destination of an XMPP message
The DNA mechanism can be used for multiple different protocols. In o Originating domain: The originating domain of a particular server-
particular, client-to-server XMPP and server-to-server XMPP are to-server connection
discussed herein, but the general approach could be used for non-XMPP
protocols such as SMTP or IMAP. As such, the protocol syntax offered
here is normative for XMPP, but merely illustrative for other
protocols, which will need their own protocol bindings.
The following domain names are used in the examples in this section: o Receiving domain: The receiving domain of a particular server-to-
asserted.tld The domain name being asserted. server connection
5.1. Assertions In outsourcing scenarios, the sending and receiving domains are
outsourced to the originating and receiving domains, respectively.
The asserting entity asserts a domain name through the use of an 3. Protocol Overview
"assert" element. Assertions MUST contain a "from" attribute naming
the domain name that is being asserted.
<assert xmlns='urn:ietf:params:xml:ns:dna' from='asserted.tld'/>
5.2. Validation Consider a scenario in which the domain sender.tld has outsourced
XMPP services to originating.tld, and target.tld has outsourced to
receiving.tld. The particular hosts providing services are
xmpp1.originating.tld and xmpp1.receiving.tld. Users
romeo@sender.tld and juliet@target.tld maintain client-to-server
connections to these servers.
romeo@sender.tld -- xmpp1.originating.tld
.
.
xmpp1.receiving.tld -- juliet@target.tld
When the validating entity has been satisified that the asserting When Romeo wants to send a message to Juliet, Provider A's server
entity is authoritative for the domain name asserted, it MUST send a will have to establish a server-to-server connection to Provider B's
"valid" element. At this point, the asserting entity MAY send server. Since they are both acting on behalf of other domains,
stanzas to the validating entity containing from addresses in the however, each side will have to verify that the other is authorized
asserted and validated domain. to act in that role.
Validating entities SHOULD respond to a domain name assertion without The first step is to provision records that can be used to verify
asking for further proof when the domain name asserted is represented these delegations. In order for XMPP to work, when the hosting
in the certificate offered by the asserting entity according to the relationships are set up, sender.tld and target.tld have to provision
rules set out in [rfc3920bis]. SRV records pointing to their providers' servers. To make this
delegation secure, they sign these records using DNSSEC [RFC4033].
On the XMPP servers themselves, the originating and receiving domains
provision certificates that can be used to authenticate the names
xmpp1.originating.tld and xmpp1.receiving.tld.
Validating entities MAY respond to a domain name assertion without When Romeo wants to send a stanza to Juliet, he will first send it to
asking for further proof when the domain name asserted is known to be his server, xmpp1.originating.tld. Seeing that the 'to' domain of
associated with the asserting entity through some other secure means the stanza is target.tld, the server will retrieve the SRV records
such as DNSSEC, caching, or local knowledge. In the DNSSEC case, the for _xmpp-server._tcp.target.tld, plus any associated DNSSEC records
server hostname in the SRV record used to connect SHOULD be looked
for in the certificate offered by the asserting entity, according to
the rules set out in [rfc3920bis].
<valid xmlns='urn:ietf:params:xml:ns:dna' to='asserted.tld'/>
5.3. Invalidation [RFC4034].
_xmpp-server._tcp.target.tld. 400 IN SRV
20 0 5269 xmpp1.receiving.tld
When the validating entity does not accept proof offered by the _xmpp-server._tcp.target.tld. 400 IN RRSIG
asserting entity, or it no longer trusts the proof (for example due SRV 5 3 400 20030322173103 (
to the proof timing out or being revoked), it sends the asserting 20030220173103 2642 _tcp.target.tld.
entity an "invalid" element. The asserting entity MUST NOT send any oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
stanzas to the validating entity containing from addresses in the PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
invalidated domain without performing another validation. B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
Invalid responses MAY be given in direct response to an assertion if If there are no DNSSEC records, or if the DNSSEC records do not
the validating entity has reason to believe that no proof is validate, then there is nothing new to do; the server simply connects
possible. Examples that would cause this response include a blocking to the remote domain using normal XMPP procedures. If there is a
list or a negative cache. valid DNSSEC signature on the SRV record, then the server knows that
<invalid xmlns='urn:ietf:params:xml:ns:dna' to='asserted.tld'/> he can allow the remote server to authenticate as either target.tld
or xmpp1.receiving.tld.
5.4. Requesting proof with a challenge Once the TLS connection is established, the two sides negotiate a
single bidirectional stream to run over it, using their own names:
I: <?xml version='1.0'?>
<stream:stream
from='xmpp1.originating.tld'
to='xmpp1.receiving.tld'
version='1.0'
xml:lang='en'
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'>
If an assertion cannot be validated immediately, the validating R: <?xml version='1.0'?>
entity may ask for further proof. Inside the "challenge" element, at <stream:stream
least one form of proof that will be acceptable MUST be given to the from='xmpp1.receiving.tld'
asserting entity. If an acceptable proof format is not available for id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
the asserted domain, the validating entity MUST return an invalid to='xmpp1.originating.tld'
response proactively. version='1.0'
xml:lang='en'
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'>
A "proof" element designates a type of proof that would be acceptable R: <stream:features>
to the verifying entity. The "type" attribute of the "proof" element <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
MUST be a valid URI. A registry of proof types will be created with <bidi xmlns='urn:xmpp:bidi'/>
the IANA (see Section 9). Standard proof types will begin with </stream:features>
"urn:ietf:params:dna:proof:". Custom proofs should be signaled with
a "type" attribute value containing a full URI under the control of
the defining party. Proof types MUST be compared for equality using
the rules for comparing URIs.
Some proof types MAY require information or nonces from the When this stream is created, it can immediately carry stanzas
validating entity. If so, the specification for that proof type MUST directly between the two servers. In order to send messages to and
specify extensions to the "proof" element in a new namespace. from other domains, the servers have to authenticate and request
permission. So to send Romeo's stanza to Juliet,
xmpp1.originating.tld requests permission to send from sender.tld to
target.tld.
In some protocols, a challenge MAY be sent without an assertion, if The originating server uses STARTTLS to set up a TLS connection. In
the validating entity has reason to believe that the entity with the ClientHello message initiating the connection, the
which it is talking is authoritative for a given domain. xmpp1.originating.tld includes a Server Name Indication extension set
<challenge xmlns='urn:ietf:params:xml:ns:dna' to='asserted.tld'> to xmpp1.receiving.tld [RFC4366]. The remote server
<proof xmlns='urn:ietf:params:dna:proof:attribute-cert'/> xmpp1.receiving.tld responds to this request with a certificate for
< type='http://example.com/proof/custom'/> its own name, xmpp1.receiving.tld and requests a client certificate
</challenge> from the originating server. The originating server presents a
certificate for its own name, xmpp1.originating.tld.
5.5. No proof possible At this point, the server xmpp1.originating.tld knows that
xmpp1.receiving.tld is authorized to represent either
xmpp1.receiving.tld (via the certificate) or target.tld (via DNSSEC).
The other server, xmpp1.receiving.tld knows only that the other
server repressents xmpp1.originating.tld.
If the validating entity requires proof, but will not accept proof by Once the two servers have authenticated their own names over TLS,
a means that the asserting entity has available for the asserted they can request permission to send stanzas:
domain, the asserting entity MUST respond with an "impossible" I: <db:result from='sender.tld' to='target.tld' />
element. The validating entity MUST NOT send a "valid" or "invalid"
element in response, and MUST NOT accept stanzas from the asserted
domain on this connection unless some other assertion works in the
future.
The "impossible" element MAY be sent after full validation, if the Since xmpp1.receiving.tld doesn't yet know whether
asserting entity would like to retract the assertion. xmpp1.originating.tld is authorized to represent sender.tld, it has
<impossible xmlns='urn:ietf:params:xml:ns:dna' from='asserted.tld'/> to check, using an abbreviated form of dialback. Just as the
Provider A server did earlier for target.tld, the Provider B server
looks up the SRV records for _xmpp-server._tcp.sender.tld and any
associated DNSSEC records. If there are no DNSSEC records or the
signature is not valid, then the server rejects the request to send
stanzas from that domain. If the record is DNSSEC-signed, then the
server checks that the server name in the SRV record is one of the
names authenticated for the remote side.
R: <db:result type='invalid' from='sender.tld' to='target.tld' />
5.6. Proving a challenge On the other hand, if the DNSSEC signature is valid, then the server
can accept the request to send stanzas, and the two servers can
exchange stanzas for those domains.
R: <db:result type='valid' from'sender.tld' to='target.tld' />
If an asserting entity thinks it can prove a given assertion when I: <!-- stanza -->
challenged, it sends that proof in a "proof" element. The REQUIRED
"type" attribute specifies the chosen proof type, and the REQUIRED
"from" attribute specifies the domain being proved. Each proof type
MUST specify the format of the contents of the "proof" element.
Suggestions for formats include Base64-encoded binary as character
data or structured XML in a new namespace.
<proof xmlns='urn:ietf:params:xml:ns:dna'
from='asserted.tld'
type='urn:ietf:params:dna:proof:attribute-cert'>
(Base64-encoded attribute certificate)
</proof>
6. Attribute Certificate Proof Now that the two servers have established this connection, they can
re-used it for other stanzas and other domains. If either server
finds another domain that is delegated to the other server, it can
send a <db:result> requesting permission to send stanzas for that
domain, and the other server will grant or deny permission after
checking the delegation.
When an asserting entity has been delegated responsibility for The following figure summarizes the overal process:
hosting a given domain, an Attribute Certificate MUST be used to Originating DNS Receiving
prove the delegation. The proof type URI associated with attribute Server Server Server
certificates SHALL be 'urn:ietf:params:dna:proof:attribute-cert' ----------- --------- --------
(EDITOR'S NOTE: We will work with IANA to come up with a good URN. | | |
This is just a placeholder.) | Lookup _xmpp-server | |
| DNS SRV record for | |
| target.tld to find | |
| delegation of service | |
| to Receiving Server. | |
| Verify zone signature | |
| -----------------------> | |
| | |
| 'Receiving Server' | |
| <----------------------- | |
| | |
| |
| |
| <stream from='originating.tld' to='receiving.tld'> |
| --------------------------------------------------> |
| |
| <stream from='receiving.tld' to='originating.tld'> |
| <-------------------------------------------------- |
| |
| <features><starttls></features> |
| <-------------------------------------------------- |
| |
| <starttls/> |
| --------------------------------------------------> |
| |
| <proceed/> |
| <-------------------------------------------------- |
| |
| |
| <====================== TLS ======================> |
| |
| |
| <stream from='originating.tld' to='receiving.tld'> |
| --------------------------------------------------> |
| |
| <stream from='receiving.tld' to='originating.tld'> |
| <-------------------------------------------------- |
| |
| <features><bidi></features> |
| <-------------------------------------------------- |
| |
| <db:result from='sender.tld' to='target.tld'/> |
| --------------------------------------------------> |
| |
| ... |
The certificate that signed the attribute certificate MUST have been 4. Connection Model
acceptable as proof of ownership of a given domain for the protocol
in question, according to the rules in [rfc3920bis]. Validating
entities SHOULD try prepending the asserted domain with "www." and
re-checking for name matches before rejecting the signing
certificate, in order to allow for easier deployments using existing
web certificates as proof.
Each protocol that is delegated will be assigned its own OID to The core challenge for managing inter-server connections is the
identify a service and whether the entity can act as a server or multiplexing of stanzas for multiple domains onto a single transport-
client. These values will be included in the Access Identifier layer connection. There are two key pieces of state associated with
attribute, from [I-D.ietf-pkix-3281update]. This document defines this multiplexing: A list of domain names that have been
the OIDs for XMPP. Other documents may specify additional OIDs. authenticated for use on a connection, and a table binding pairs of
domains that are authorized for a connection.
The remaining paragraphs in this section profile the attribute First table that a server maintains is a connection table. Each
certificate issuers public key certificate and the attribute entry in this table contains a connection and a set of domain names.
certificate. The domain names represent the set of names for which the remote
server has been authenticated, according to the procedures described
in Section Section 5. This set of domain names constrains the set of
domain pairs that can be bound to this channel; the remote server
cannot ask to transmit stanzas for an unauthenticated domain name.
6.1. Attribute Certificate Issuer Profile +------------+---------------------+------------------------+
| Connection | Server Domain Names | Delegated Domain Names |
+------------+---------------------+------------------------+
| XXX | xmpp1.provider.com | capulet.example |
| YYY | xmpp2.provider.com | capulet.example |
| AAA | paris.example | paris.example |
+------------+---------------------+------------------------+
The following is a profile of the attribute certificate issuer's To determine how to handle incoming and outgoing stanzas, each server
public key certificate, which is as per [I-D.ietf-pkix-3281update]: maintains a channel binding table. Each row in the binding table
o The issuer's certificate MUST conform to [RFC5280]. contains a "local" domain name, a "remote" domain name, and an
o The issuer's certificate MUST have a keyUsage extension with the ordered list of connections. The identifier for a connection is the
digitalSignature bit set. stream ID for the single XMPP stream that it carries.
o The issuer's certificate MUST NOT have a basicConstraints
extension with the cA BOOLEAN set to TRUE.
In addition to the [I-D.ietf-pkix-3281update] requirements, the +------------------+-----------------+---------------+
subject name MUST be non-NULL in the attribute certificate issuer's | Local | Remote | Connections |
public key certificate. +------------------+-----------------+---------------+
| montague.example | capulet.example | XXX, YYY |
| laurence.example | capulet.example | AAA |
| laurence.example | paris.example | YYY, AAA |
+------------------+-----------------+---------------+
The binding table acts as a routing table for outgoing stanzas and a
filter for incoming stanzas. When the server wishes to send a
stanza, it looks in the binding table for a row that has the 'from'
domain as the local domain and the 'to' domain as the remote domain.
If there is such a in the binding table, then the server MUST
transmit the on the first connection in the connection list. Thus,
in the above example, a stanza from montague.example to
capulet.example would be routed on channel XXX.
6.2. Attribute Certificate Profile In the same way, when a server receives a stanza over a connection
from a remote server, it looks up the relevant entry in the binding
table, this time using the 'to' domain as the local domain and the
'from' domain as the remote domain. If the server finds a binding
table entry and the connection over which the stanza arrived is
listed in the entry, then it accepts the stanza. Otherwise, it MUST
discard the stanza and return a stanza error <invalid-connection/>.
In the above example, a stanza from capulet.example to
escalus.example would be accepted on connections AAA and BBB, but no
others.
The attribute certificate issued MUST conform to When a connection is opened (and at some points thereafter), entries
[I-D.ietf-pkix-3281update]. There are options in that profile and in the name table are established using the processes in Section
the following profiles those options: Section 5. Once a connection is open, binding table entries are
o The holder field MUST be the baseCertificateID. added or removed using the processes in Section Section 6. When a
o The attributes field MUST include the Access Identity attribute, connection is closed, both servers MUST delete its entry in the name
as specified in Section 4.4.2 of [I-D.ietf-pkix-3281update]. Both table and remove it from all entries in the binding table.
the service and ident fields' GeneralName choice MUST be
registeredID. The service and ident fields MUST be as defined in
Section 5.3. Other attributes MAY be included.
o The extensions field MUST include the non-critical noRevAvail
extension, as defined in Section 4.3.6 of
[I-D.ietf-pkix-3281update], to indicate that no revocation
information is available from the attribute certificate issuer.
o The extensions field MAY include:
* The authorityKeyIdentifier extension if the issuer has more
than one key pair.
* The issuerAltName extension if the issuer's certificate
includes the subjectAltName extension. If included
issuerAltName MUST be marked non-critical.
6.3. Access Identity Values 5. Channel Establishment and Authentication
The following paragraphs define the service and ident values for the When a server wants to send a stanza and doesn't have an entry in the
delegated protocols. Currently, only values for XMPP are defined. A connection table for the destination domain, it sets one up. The
later version of this document or another document may specify first step is to establish a connection to a server for the
additional values for other protocols. destination domain, and validate that the server is authorized to
represent the destination domain.
6.3.1. XMPP The originating server MUST take the following steps to establish a
secure connection to the server for example.com:
When XMPP is delegated the following procedures MUST be followed. 1. Retrieve SRV records for XMPP services for example.com
[I-D.ietf-xmpp-3920bis].
The service field MUST be id-xmpp. The following object identifier 2. Verify that the SRV records have been signed using DNSSEC
identifies that the AC holder supports XMPP: [RFC4033]. The originating server may either retrieve DNSSEC
id-xmpp OBJECT IDENTIFIER ::= { TBD } records directly or rely on a validating resolver. If the SRV
records are not secured with DNSSEC, then the connection fails.
The ident field MUST be either id-xmpp-client or id-xmpp-server. 3. If there is already a connection in the connection table that has
Both id-xmpp-client and id-xmpp-server MAY appear in the same the target of any SRV record in its "server names" list, then
attribute certificate. Note that the Access Identity attribute will this process terminates and the server attempts to use that
be multi-valued when both id-xmpp-client and id-xmpp-server are connection (See Section Section 6)
present.
The following object identifier identifies the AC holder as the XMPP 4. If there is no existing connection that matches, establish a TCP
client: connection to any of the servers listed in an SRV record and
id-xmpp-client OBJECT IDENTIFIER ::= { id-xmpp 0 } negotiate an XMPP stream with the following parameters:
The following object identifier identifies the AC holder as the XMPP * 'from' domain: The originating server's name
server:
id-xmpp-server OBJECT IDENTIFIER ::= { id-xmpp 1 }
6.4. Attribute Certificate Signature Algorithms * 'to' domain: The receiving server's name from the SRV record
The issuer MUST support signing attribute certificate with the PKCS * [[ TODO: Add a stream feature to indicate support for this
#1 version 1.5 signature algorithm with SHA-256, as specified in extension ]]
[RFC4055].
6.5. Proof Encoding 5. Upgrade the connection to TLS using STARTTLS, using a cipher
suite that requires the server to present an X.509 certificate.
The attribute certificate, the issuer's certificate, and all of the 6. Verify that the certificate is valid and chains to a local trust
CA certificates in the trust chain of the signing certificate back to anchor. If the certificate is invalid, the connection fails.
the trust anchor are encoded as a "certs-only" SMIME message, as per
[I-D.ietf-smime-3851bis] (i.e, a degenerate SignedData with no
content just certificates). The resulting message is then Base64
encoded, as per Section 6.8 of [RFC2045]. The end result is then
transmitted as the character data of a "proof" element.
7. DNA for XMPP Federation 7. Construct a list of all names that the certificate presents
[I-D.saintandre-tls-server-id-check].
Two XMPP servers, each of which hosts multiple domains that they do 8. Verify that the target name in the SRV record is one of the names
not directly control, desire to connect in order to exchange traffic in the certificate. If the target name is not found in the list
for at least two of those domains (one on either side). of names from the certificate, then the connection fails.
The following domain names are used in the examples: A server receiving such a connection MUST perform the following
target.tld The domain portion of the JID in the to address of the steps:
stanza that caused this connection to be initiated.
othertarget.tld The domain portion of the JID in the to address of a
stanza being sent across a stream that was originally started to
talk to target.tld.
targetprovider.tld The hosting provider for target.tld. 1. Accept the TCP connection from the remote side and accept the
server.targetprovider.tld A server with XMPP federation services at stream negotiation using server names.
the target's hosting provider.
originator.tld The domain portion of the JID in the from address of
the stanza that caused this connection to be initiated.
originatingprovider.tld The hosting provider for target.tld.
server.originatingprovider.tld A server with XMPP federation
services at the originator's hosting provider.
7.1. DNS SRV lookups 2. In the TLS negotiation, require a client certificate from the
remote side.
In a delegated hosting scenario, DNS SRV records are REQUIRED, since 3. Verify that the remote server name in the stream matches the
otherwise the hosting provider will never be contacted for the target client certificate [I-D.saintandre-tls-server-id-check]. If the
domain. As specified by [rfc3920bis] the originating server looks up certificate does not match, the TLS negotiation fails, and the
the target domain to find a list of receiving servers. If the server MAY terminate the TCP connection.
originating server already has a connection to the IP address
represented by one of these servers (perhaps because it is
communicating with another domain hosted by this provider), it MAY
reuse that stream (see Stream Reuse). If the originating server does
not have a connection it wants to reuse, it performs the SRV
algorithm to select an SRV record and makes a TCP connection to the
server and port specified by the selected SRV record.
Unless assured by a mechanism such as DNSSEC, the originating server If this process establishes a new connection, then the originating
MUST NOT trust the information received from the DNS SRV as proof server knows that it has established a connection to a server that
that the target domain has been delegated to the receiving server. legitimately represents example.com. It should thus initialize a row
% dig +short -t SRV _xmpp-server._tcp.target.tld in the connection table for this connection:
0 1 5269 server.targetprovider.tld
7.2. Certificates during Start-TLS o Server names: The list of names in the server's certificate
The first step during stream negotiation MUST be Start-TLS. The o Delegated names: example.com
receiving server MUST offer a certificate signed by a widely-trusted
CA. The receiving server MUST require a client certificate. The
certificate offered by the originating server MUST be signed be a
widely-trusted CA. Both sides MUST check the certificate offered to
it for validity (e.g. time period, signatures, and trust anchor), but
MUST NOT disconnect when the certificate received does not contain a
name matching its expectations.
The names on these certificates SHOULD be associated with the If the process terminated at Step 3, then the server simply updates
relevant hosting provider, and need not be related to the domains the connection table entry to add example.com to the list of
being hosted. If the certificates have the name of the server delegated names. In either case, the row for a connection is removed
offered in the SRV record, it MAY be possible to use DNSSEC for proof from the connection table when the connection is closed.
in the future.
CN=server.targetprovider.tld
CN=server.originatingprovider.tld
7.3. Discovering Support In order for this process to work, the domain owner and the hosting
provider need to publish information that other XMPP entities can use
to verify the delegation. XMPP services are delegated via SRV
records (see Section 3.2.1 of [I-D.ietf-xmpp-3920bis]), so in order
for the delegation to be secure, the domain owner MUST sign these
records with DNSSEC. In other words, if the delegated domain is
example.com, then the zone _xmpp-server._tcp.example.com MUST be
signed. Each server that acts for a domain MUST be provisioned with
a certificate that contains the target name used by SRV records.
To and from addresses are REQUIRED in the stream:stream tag. These The server on the receiving end of the TLS connection MUST request a
represent the first domain pair associated with this stream, and are client certificate from the originating server during the TLS
the domain names from the stanza that caused this connection to be handshake, and the originating server MUST provide a client
established. certificate. The receiving server can then also initialize an entry
in its connection table to which delegated names can be added later:
To announce its support for DNA, the receiving server asserts its o Server names: The list of names from the client certificate (from
identity in the stream features following TLS negotiation. the originating server), if present. Otherwise, empty.
<stream:features>
<assert xmlns='urn:ietf:params:xml:ns:dna' from='target.tld'/>
</stream:features>
7.4. Turning on DNA o Delgated names: Empty.
If the originating server supports DNA, it looks for an assertion in Once the two servers have established a TLS connection, they MUST set
the stream features. If it finds none, it MAY fall back on another up an XMPP stream that will be used for domains that they represent.
means of verifying the identiy of the target server, if allowed by This process follows the normal stream initiation procedure
local policy. [I-D.ietf-xmpp-3920bis], except that the 'to' and 'from' domains MUST
be set to the names of the servers themselves: The originating server
sends a <stream> stanza with the 'from' domain set to a name for
itself that is contained in its client certificate, and the 'to'
domain set to the server name used in the SRV record for this
connection. If stream negotiation fails, then the connection fails.
If it succeeds, then both sides MUST set the connection identifier in
the connection table to be the stream ID for the negotiated stream.
Originating servers that support DNA talking to target servers that Since server-to-server connections are by default directional, it is
declare support for DNA MUST NOT send protocol other than DNA RECOMMENDED that servers also request the <bidi> stream feature to
negotations until they are able to validate the assertion offered by enable bidirectional flows on this connection [XEP-0288].
the target server in the stream features. The first validation
proves to the originating server that it is talking to a server
authoritative for the target domain, so that it is safe to use this
domain in "to" addresses on this stream.
Once an originating server completes this first validation it signals Originating DNS Receiving
that it is willing and able to participate in bi-directional XMPP Server Server Server
federation traffic, as long as all of the domains required have been ----------- --------- --------
asserted and validated at least once on this stream. | | |
| Lookup _xmpp-server | |
| DNS SRV record for | |
| target.tld to find | |
| delegation of service | |
| to Receiving Server. | |
| Verify zone signature | |
| -----------------------> | |
| | |
| 'Receiving Server' | |
| <----------------------- | |
| | |
| |
| |
| <stream from='originating.tld' to='receiving.tld'> |
| --------------------------------------------------> |
| |
| <stream from='receiving.tld' to='originating.tld'> |
| <-------------------------------------------------- |
| |
| <features><starttls></features> |
| <-------------------------------------------------- |
| |
| <starttls/> |
| --------------------------------------------------> |
| |
| <proceed/> |
| <-------------------------------------------------- |
| |
| |
| <====================== TLS ======================> |
| |
| |
| <stream from='originating.tld' to='receiving.tld'> |
| --------------------------------------------------> |
| |
| <stream from='receiving.tld' to='originating.tld'> |
| <-------------------------------------------------- |
| |
| <features><bidi></features> |
| <-------------------------------------------------- |
If the originating server does not require more proof (due to a 6. Authorizing XMPP Stanzas
certificate match or DNSSEC-verified delegation), it may send a
"valid" element without requesting proof first, as in all DNA
interactions.
<challenge xmlns='urn:ietf:params:xml:ns:dna' to='target.tld'>
<proof type='urn:ietf:params:dna:proof:attribute-cert'/>
</challenge>
<proof xmlns='urn:ietf:params:xml:ns:dna' Before sending traffic from a Sender Domain to a Target Domain using
from='target.tld' an established connection, the originating server MUST request
type='urn:ietf:params:dna:proof:attribute-cert'> permission to do so, and wait until it has received authorization
(Base64-encoded attribute certificate) from the remote service. A service receiving traffic MUST verify
</proof> that the Sender and Target domain pair has been authorized on the
<valid xmlns='urn:ietf:params:xml:ns:dna' to='target.tld'/> connection being used.
7.5. Asserting new domains An originating server MUST go through the following steps to reqeust
authorization to send traffic from a Sender Domain to a Target
Domain:
Before either side sends stanzas on a given stream, it MUST ensure 1. Send a <db:result/> [XEP-0220] element with Sender Domain as
that the other side will accept those stanzas by asserting the domain 'from' and Target Domain as 'to'. The server may also include a
in the "from" attribute of those stanzas, and waiting for a "valid" Dialback Key as part of the element's character data, to support
response before sending the stanzas in question. legacy deployments.
The originating server MUST therefore send its own assertion after 2. Wait for remote service to respond with a <db:result> with Target
accepting the target domain's assertion. Domain as 'from', Sender Domain as 'to' and 'type' attribute that
<assert xmlns='urn:ietf:params:xml:ns:dna' from='originator.tld'/> is either 'valid' or 'invalid'. In case of 'invalid', the
originating server SHOULD examine the error cause and take
appropriate action and MAY retry requesting authorization on the
same connection in the future.
7.6. Proactive challenges 3. If response 'type' was 'valid', the originating server updates
its binding table to indicate that Sender Domain (Local) and
Target Domain (Remote) is authorized in the sending direction for
the connection used.
Before either side sends stanzas on a given stream, it MUST ensure 4. Originating server proceeds with sending traffic from Sender
that the other side is authoriative for the domain in the "to" Domain to Target Domain.
attribute on those stanzas. If the sender has already accepted an
assertion on this stream, and that assertion has not been revoked
with an "impossible" element, no action is required. Otherwise, the
sender can proactively request proof for that domain by sending a
challenge even though the other side has not sent an assertion for
that domain yet.
<challenge xmlns='urn:ietf:params:xml:ns:dna' to='othertarget.tld'>
<proof type='urn:ietf:params:dna:proof:attribute-cert'/>
</challenge>
7.7. Proactive validation Upon receiving a <db:result/> stanza, the receiving server MUST take
following steps:
When two hosting providers connect, they may have previous knowledge 1. Verify that the receiving direction is supported for this
(perhaps from a cache) of which domains they will trust on the new connection. If not, fail by disconnecting the stream. (By
connection. If so, either side MAY send as many "valid" elements as default, connections are one-way)
desired, even though the other side has not sent assertions for those
domain.
The server receiving these proactive validations MUST NOT change its 2. Verify that domain in to-attribute is hosted by the service. If
self-image (which domains it thinks it is authoritative for), but not, fail and respond with an <item-not-found/> error.
SHOULD NOT send assertions for these domains on this stream. If the
server receiving a proactive validation is no long authoritative for
a given domain, it MUST send an "impossible" element, at which point
the sender MUST remove the receiver from any cache and not send any
stanzas on this stream to the given domain.
Any cache of DNA information SHOULD be associated with the 3. Verify that domain in from-attribute delegates hosting of their
certificate offerred by the relevant server, and SHOULD be checked XMPP to the remote Server Domain Name by looking up SRV and
for revocation if possible, according to local policy. verifying that the zone is signed. If not, fail with a <not-
<valid xmlns='urn:ietf:params:xml:ns:dna' to='target1.tld'/> authorized/> error. Note: a service MAY accept a less secure
<valid xmlns='urn:ietf:params:xml:ns:dna' to='target2.tld'/> delegation mechanism such a SRV records in a non signed zone,
<valid xmlns='urn:ietf:params:xml:ns:dna' to='target3.tld'/> subject to local policy.
7.8. Reusing streams 4. Once secure delegation from Sending Domain to remote Server
Domain name has been verified, service adds Sending Domain to
list of Delegated Domain Names in the Connection Table, and
updates the Binding Table indicating that the Sending Domain
(remote) is allowed to send traffic to Target Domain (local) on
the connection.
DNA streams are bi-directional, and may have an aribtrary number of 5. Respond to remote service with a <db:result/> stanza with 'type'
domains validated in either direction, at any point in the lifetime set to 'valid'.
of the stream. Before sending a stanza on a given stream, the sender
MUST ensure that "valid" elements have been exchanged according to
the above rules for both the "to" and "from" address, and that no
"invalid" or "impossible" element has revoked an assertion.
An "impossible" or "invalid" element SHOULD NOT cause the rest of the A service may revoke authorization for a domain pair at any time by
stream to become invalidated in either directions. When these sending a <db:result> with 'type' set to invalid. Once authorization
elements are seen, they SHOULD merely change the list of domains that has been revoked, the remote side MUST re-aquire authorization before
are valid on that stream. If no domains are valid on the stream, the sending any futher traffic for the domain pair.
stream MAY be closed immediately, or MAY be left open if desired. If
left open, the stream MUST NOT be used for stanza traffic until
domains are asserted as needed for the desired domains.
Domains that are marked as "invalid" or "impossible" SHOULD NOT be If a server receives a stanza for a to/from pair that it does not
retried on the same stream unless new information has become consider authorized, then it MUST return a <not-authorized/> error
available, in order to prevent assertion storms. and MAY terminate the TCP connection.
7.9. Implementation notes Originating Receiving DNS
Server Server Server
----------- --------- --------
| | |
| <db:result | |
| from='sender.tld' | |
| to='target.tld'/> | |
| -----------------------> | |
| | Lookup _xmpp-server |
| | DNS SRV record for |
| | sender.tld to verify |
| | signed delegation of |
| | delegation of service |
| | to Originating Server |
| | -----------------------> |
| | |
| | Result |
| | <----------------------- |
| |
| <db:result |
| from='target.tld' |
| to='sender.tld' |
| type='valid'/> |
| <----------------------- |
| |
| (Traffic authorized |
| from sender.tld to |
| target.tld, in one |
| direction.) |
| |
| <message |
| from='r@sender.tld' |
| to='j@target.tld'> |
| <body>hi</body> |
| </message> |
| -----------------------> |
If the first server-to-server validation exchange fails, the parties 7. Backward Compatibility
MAY keep the connection open (perhaps for a shorter than is usual) in
case another domain pair would need a connection between these
servers.
Ensure that only one challenge is outstanding on a given connection Using Server Domain Names as to/from attributes in <stream> stanzas
for a given domain. Ensure that only one assertion or one proof is is incompatible with XMPP services that do not support this protocol,
outstanding on a given connection for a given domain. because it was previously assumed that when receiving a connection
the stream to attibute will contains an XMPP domain hosted by the
receiving service. It is RECOMMENDED that if the connection fails,
the service tries again using the Remote Domain as stream to-
attribute.
8. DNA for XMPP client connections Presenting a certificate for the Server Domain Name is incompatible
with XMPP services that do not support this protocol, because those
will expect the Remote Domain in the certificate. It is RECOMMENDED
that if the authorization fails, the service tries again presenting
the certificate for the Remote Domain. A service may also choose to
fall back on a weaker identification mechanism such as Server
Dialback, subject to local policy.
Hosting providers have a similar problem for client to server 8. Operational Considerations
connections. Clients need to ensure that they are talking to an
authoritative server for the domain they intend to log in to.
Typically, this is done by examining the certificate offered by the
server during TLS negotiation, according to the rules in
[rfc3920bis]. However, hosting providers will typically not have
access to a valid certificate for the target domain and its
associated private key. DNA can be used for the hosting provider to
prove that hosting services have been delegated to it.
8.1. Announcing Support [[ What names to put in certs for servers in a cluster, i.e., all of
them. ]]
To announce its support for DNA, the server asserts its identity in [[ Do TLS clients support multiple names in certs? ]]
the stream features following TLS negotiation. The server MUST offer
the identity of the domain specified in the client's stream header
"to" attribute.
<stream:features>
<assert xmlns='urn:ietf:params:xml:ns:dna' from='target.tld'/>
</stream:features>
8.2. Client challenges for proof [[ How DNSSEC validation is done can vary depending on deployment
scenario. ]]
To utilize the server's DNA assertion, the client performs Start-TLS [[ Since SNI is used to signal support for this extension,
per [rfc3920bis], however, if the client does not find a name match recommended not to serve end users on the same domain as hosting
on the offered certificate, it does not disconnect immediately. services. ]]
Instead, if the server offers an assertion, it can use the name from
that assertion to ask the server for proof of delegation.
Subsequent protocol follows the generic use cases above, with the [[ Load balancing thoughts, since each connection will handle a lot
exception that alternate or additional domain names MUST NOT be more traffic? ]]
asserted. If the server returns an "impossible" element, the server
MUST terminate the stream. If the client sends an "invalid" element,
the client MUST terminate the stream.
<challenge xmlns='urn:ietf:params:xml:ns:dna' to='asserted.tld'>
<proof type='urn:ietf:params:dna:proof:attribute-cert'/>
</challenge>
9. IANA Considerations 9. IANA Considerations
9.1. XML Namespace Name for DNA [[ Register XML schema for assertions, if necessary ]]
A URN sub-namespace for Domain Name Assertion (DNA) negotiation data
in the Extensible Messaging and Presence Protocol (XMPP) is defined
as follows. (This namespace name adheres to the format defined in .)
URI: urn:ietf:params:xml:ns:dna
Specification: XXXX
Description: This is the XML namespace name for Domain Name
Assertion (DNA) negotiation data in the Extensible Messaging and
Presence Protocol (XMPP) as defined by XXXX.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@xmpp.org>
9.2. URN space for standard DNA Proof Types
A URN sub-namespace for DNA is defined as follows. (This namespace
name adheres to the format defined in .)
URI: urn:ietf:params:dna:proof
Specification: XXXX
Description: This is the sub-namespace for standardized Domain Name
Assertion (DNA) proof types as defined by XXXX.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@xmpp.org>
9.3. DNA Proof Registry
The URNs inside urn:ietf:params:dna:proof
9.4. Object Identifiers [[ Define invalid-connection error element ]]
The following OIDs are defined in Section 5.3 of this document: 10. Security Considerations
o id-xmpp
o id-xmpp-client
o id-xmpp-server
10. Internationalization Considerations [[ This document simplifies authentication and authorization of XMPP
servers in certain scenarios. When used together with DNSSEC-
protected delegations, it does not introduce any new security risks.
]]
The domains offered MUST conform to all of the rules for "Domain [[ If a provider chooses to omit DNSSEC checks or ]]
Identitifiers", as specified in &rfc3920bis;, including (but not
limited to) the rules for syntax, cannonicalization and comparison.
11. Security Considerations 11. Acknowledgements
TBD. Thanks to Joe Hildebrand and Sean Turner for prompting the original
work on this problem, and to Stephen Farrell for his work on initial
versions of this draft.
12. Normative References 12. Normative References
[rfc3920bis] [I-D.ietf-xmpp-3920bis]
Saint-Andre, P., "Extensible Messaging and Presence Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-02 (work Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-22 (work
in progress), September 2009. in progress), December 2010.
[I-D.ietf-pkix-3281update]
Housley, R., Farrell, S., and S. Turner, "An Internet
Attribute Certificate Profile for Authorization",
draft-ietf-pkix-3281update-05 (work in progress),
April 2009.
[I-D.ietf-smime-3851bis]
Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", draft-ietf-smime-3851bis-11 (work in
progress), May 2009.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055,
June 2005.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
Appendix A. RELAX NG XML Schema [I-D.saintandre-tls-server-id-check]
Saint-Andre, P. and J. Hodges, "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)", draft-saintandre-tls-server-id-check-14
(work in progress), January 2011.
default namespace = "urn:ietf:params:xml:ns:dna" [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
# Intent: Internationalized Domain Name (simplisitic view) [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
domain = xsd:string { pattern = "(\p{L}|\p{N})(\p{L}|\p{N}|\p{M}|-)*" Rose, "DNS Security Introduction and Requirements",
"(\.(\p{L}|\p{N})(\p{L}|\p{N}|\p{M}|-)*)*"} RFC 4033, March 2005.
assert = element assert { [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
attribute from { domain } Rose, "Resource Records for the DNS Security Extensions",
} RFC 4034, March 2005.
valid = element valid { [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
attribute to { domain } and T. Wright, "Transport Layer Security (TLS)
} Extensions", RFC 4366, April 2006.
invalid = element valid { [XEP-0220]
attribute to { domain } Miller, J., Saint-Andre, P., and P. Hancke, "Server
} Dialback", XSF XEP 0220, March 2010.
proof = element proof { [XEP-0288]
attribute type { xsd:anyURI }, Hancke, P. and D. Cridland, "Bidirectional Server-to-
attribute from { domain }?, Server Connections", XSF XEP 0288, October 2010.
text?
}
challenge = element challenge { Authors' Addresses
proof+
}
start = assert | valid | invalid | proof | challenge Richard L. Barnes
BBN Technologies
Authors' Addresses Email: rbarnes@bbn.com
Jonas Lindberg Jonas Lindberg
Google Google
Email: jonasl@google.com Email: jonasl@google.com
Stephen Farrell
NewBay Software
Email: sfarrell@newbay.com
 End of changes. 125 change blocks. 
596 lines changed or deleted 592 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/