draft-ietf-xmpp-dna-01.txt   draft-ietf-xmpp-dna-02.txt 
Network Working Group R. Barnes Network Working Group P. Saint-Andre
Internet-Draft BBN Technologies Internet-Draft M. Miller
Intended status: Standards Track J. Lindberg Intended status: Standards Track Cisco Systems, Inc.
Expires: September 15, 2011 Google Expires: October 17, 2013 April 15, 2013
March 14, 2011
Domain Name Assertions Domain Name Associations (DNA) in the Extensible Messaging and Presence
draft-ietf-xmpp-dna-01 Protocol (XMPP)
draft-ietf-xmpp-dna-02
Abstract Abstract
The current authentication process in XMPP requires the XMPP server This document improves the security of the Extensible Messaging and
for a domain to present a certificate that contains that domain's Presence Protocol (XMPP) in two ways. First, it specifies how
name. This requirement causes several problems in scenarios where "prooftypes" can establish a strong association between a domain name
XMPP services have been delegated from one domain to another, and an XML stream. Second, it describes how to securely delegate a
especially when one domain provides XMPP services for many domains. source domain to a derived domain, which is especially important in
This document describes an extension to the XMPP authentication virtual hosting environments.
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 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on September 15, 2011. This Internet-Draft will expire on October 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2013 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 Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Flow Chart . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Connection Model . . . . . . . . . . . . . . . . . . . . . . . 8 4. A Simple Scenario . . . . . . . . . . . . . . . . . . . . . . 5
5. Channel Establishment and Authentication . . . . . . . . . . . 9 5. One-Way Authentication . . . . . . . . . . . . . . . . . . . 6
6. Authorizing XMPP Stanzas . . . . . . . . . . . . . . . . . . . 13 6. Piggybacking . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 15 6.1. Assertion . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Operational Considerations . . . . . . . . . . . . . . . . . . 16 6.2. Supposition . . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Alternative Prooftypes . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7.1. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. POSH . . . . . . . . . . . . . . . . . . . . . . . . . . 10
12. Normative References . . . . . . . . . . . . . . . . . . . . . 17 8. Secure Delegation and Multi-Tenancy . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Prooftype Model . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
When connecting two XMPP services to provide inter-domain The need to establish a strong association between a domain name and
communication, it is important for a service to be able to determine an XML stream arises in both client-to-server and server-to-server
the identity of a peer service to prevent traffic spoofing. The communication using the Extensible Messaging and Presence Protocol
Jabber communities first approach to identity verification was the (XMPP), because XMPP servers are typically identified by DNS domain
Server Dialback protocol. When the Jabber protocols were formalized names. However, a client or peer server needs to verify the identity
by the XMPP working group of the IETF 2002-04, support for strong of a server to which it connects. To date, such verification has
identity verification using TLS + SASL was added. been established based on information obtained from the Domain Name
System (DNS), the Public Key Infrastructure (PKI), or similar
Server Dialback [XEP-0220] provides weak identity verification and sources. This document (1) generalizes the model currently in use so
makes it more difficult to spoof hostnames of servers XMPP network. that additional prooftypes can be defined, (2) provides a basis for
However, it does not provide authentication between servers and is modernizing some prooftypes to reflect progress in underlying
not a security mechanism. It is susceptible to DNS poisoning attacks technologies such as DNS Security [RFC4033], and (3) describes the
(unless DNSSEC is used) and cannot protect against attackers capable flow of operations for establishing a domain name association.
of hijacking the IP address of a remote service.
TLS + SASL provides strong identity verification but requires a
obtaining a digital certificate by a trusted CA (or the XMPP
Intermediate Certification Authority) and using it in the XMPP
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.
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.
In practice, many XMPP server deployments rely on Server Dialback and
either do not support XMPP 1.0 or do not offer negotiation of TLS +
SASL.
This goal of this document is to describe secure authentication using Furthermore, the process for resolving the domain name of an XMPP
a hosting provide TLS certificate from a trusted CA, combined with a service into the IP address at which an XML stream will be negotiated
dialback mechanism providing secure delegation based on DNS record (defined in [RFC6120]) can involve delegation of a source domain
delgation verified using DNSSEC. (say, example.com) to a derived domain (say, hosting.example.net).
If such delegation is not done in a secure manner, then the domain
name association cannot be authenticated. Therefore, this document
provides guidelines for defining secure delegation methods.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document inherits XMPP terminology from [RFC6120] and
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and [XEP-0220], DNS terminology from [RFC1034], [RFC1035], [RFC2782] and
"OPTIONAL" in this document are to be interpreted as described in RFC [RFC4033], and security terminology from [RFC4949] and [RFC5280].
2119 [RFC2119]. The terms "source domain", "derived domain", "reference identity",
and "presented identity" are used as defined in the "CertID"
specification [RFC6125]. The terms "permissive federation",
"verified federation", and "encrypted federation" are derived from
[XEP-0238], although we substitute the term "authenticated
federation" for the term "trusted federation" from that document.
We will refer to four different types of domains in this document: 3. Flow Chart
o Sender domain: The domain that initially sends out an XMPP message The following flow chart illustrates the protocol flow for
establishing domain name associations between Server A and Server B,
as described in the remaining sections of this document.
o Target domain: The ultimate destination of an XMPP message |
|
(Section 4: A Simple Scenario)
|
|
DNS RESOLUTION ETC.
|
+-------------STREAM HEADERS--------------------+
| |
| A: <stream from='a.example' to='b.example'> |
| |
| B: <stream from='b.example' to='a.example'> |
| |
+-----------------------------------------------+
|
+-------------TLS NEGOTIATION-------------------+
| |
| B: Server Certificate |
| [B: Certificate Request] |
| [A: Client Certificate] |
| |
+-----------------------------------------------+
|
(A establishes DNA for b.example!)
|
+-------------AUTHENTICATION--------------------+
| | |
| {client certificate?} ----+ |
| | | |
| | yes no | |
| v | |
| SASL EXTERNAL | |
| (mutual auth!) | |
+------------------------------------|----------+
|
+----------------+
| B needs to auth A
|
(Section 5: One-Way Authentication)
|
|
DNS RESOLUTION ETC.
|
+-------------STREAM HEADERS--------------------+
| |
| B: <stream from='b.example' to='a.example'> |
| |
| A: <stream from='a.example' to='b.example'> |
| |
+-----------------------------------------------+
|
+-------------TLS NEGOTIATION-------------------+
| |
| A: Server Certificate |
| |
+-----------------------------------------------+
|
(B establishes DNA for a.example!)
|
|
(Section 6.1: Piggybacking Assertion)
|
|
+----------DIALBACK IDENTITY ASSERTION----------+
| |
| B: <db:result from='c.example' |
| to='a.example'/> |
| |
+-----------------------------------------------+
|
+-----------DNA DANCE AS ABOVE------------------+
| |
| DNS RESOLUTION, STREAM HEADERS, |
| TLS NEGOTIATION, AUTHENTICATION |
| |
+-----------------------------------------------+
|
+----------DIALBACK IDENTITY VERIFICATION-------+
| |
| A: <db:result from='a.example' |
| to='c.example' |
| type='valid'/> |
| |
+-----------------------------------------------+
|
|
(Section 6.2: Piggybacking Supposition)
|
|
+-----------SUBSEQUENT CONNECTION---------------+
| |
| B: <stream from='c.example' |
| to='chatrooms.a.example'> |
| |
| A: <stream from='chatrooms.a.example' |
| to='c.example'> |
| |
+-----------------------------------------------+
|
+-----------DNA DANCE AS ABOVE------------------+
| |
| DNS RESOLUTION, STREAM HEADERS, |
| TLS NEGOTIATION, AUTHENTICATION |
| |
+-----------------------------------------------+
|
+-----------DIALBACK OPTIMIZATION---------------+
| |
| B: <db:result from='c.example' |
| to='chatrooms.a.example'/> |
| |
| B: <db:result from='chatrooms.a.example' |
| to='c.example' |
| type='valid'/> |
| |
+-----------------------------------------------+
o Originating domain: The originating domain of a particular server- 4. A Simple Scenario
to-server connection
o Receiving domain: The receiving domain of a particular server-to- To illustrate the problem, consider the simplified order of events
server connection (see [RFC6120] for details) in establishing an XML stream between
Server A (a.example) and Server B (b.example):
In outsourcing scenarios, the sending and receiving domains are 1. Server A resolves the DNS domain name b.example.
outsourced to the originating and receiving domains, respectively.
3. Protocol Overview 2. Server A opens a TCP connection to the resolved IP address.
Consider a scenario in which the domain sender.tld has outsourced 3. Server A sends an initial stream header to Server B, asserting
XMPP services to originating.tld, and target.tld has outsourced to that it is a.example:
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 Romeo wants to send a message to Juliet, Provider A's server <stream:stream from='a.example' to='b.example'>
will have to establish a server-to-server connection to Provider B's
server. Since they are both acting on behalf of other domains,
however, each side will have to verify that the other is authorized
to act in that role.
The first step is to provision records that can be used to verify 4. Server B sends a response stream header to Server A, asserting
these delegations. In order for XMPP to work, when the hosting that it is b.example:
relationships are set up, sender.tld and target.tld have to provision
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.
When Romeo wants to send a stanza to Juliet, he will first send it to <stream:stream from='b.example' to='a.example'>
his server, xmpp1.originating.tld. Seeing that the 'to' domain of
the stanza is target.tld, the server will retrieve the SRV records
for _xmpp-server._tcp.target.tld, plus any associated DNSSEC records
[RFC4034]. 5. The servers attempt TLS negotiation, during which Server B
_xmpp-server._tcp.target.tld. 400 IN SRV (acting as a TLS server) presents a PKIX certificate proving that
20 0 5269 xmpp1.receiving.tld it is b.example and Server A (acting as a TLS client) presents a
PKIX certificate proving that it is a.example.
_xmpp-server._tcp.target.tld. 400 IN RRSIG 6. Server A checks the PKIX certificate that Server B provided and
SRV 5 3 400 20030322173103 ( Server B checks the PKIX certificate that Server A provided; if
20030220173103 2642 _tcp.target.tld. these proofs are consistent with the XMPP profile of the matching
oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr rules from [RFC6125], each server accepts that there is a strong
PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o domain name association between its stream to the other party and
B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t the DNS domain name of the other party.
GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
If there are no DNSSEC records, or if the DNSSEC records do not Several simplifying assumptions underlie the happy scenario just
validate, then there is nothing new to do; the server simply connects outlined:
to the remote domain using normal XMPP procedures. If there is a
valid DNSSEC signature on the SRV record, then the server knows that
he can allow the remote server to authenticate as either target.tld
or xmpp1.receiving.tld.
Once the TLS connection is established, the two sides negotiate a o Server A presents a PKIX certificate during TLS negotiation, which
single bidirectional stream to run over it, using their own names: enables the parties to complete mutual authentication.
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'>
R: <?xml version='1.0'?> o There are no additional domains associated with Server A and
<stream:stream Server B (say, a subdomain chatrooms.a.example on Server A or a
from='xmpp1.receiving.tld' second domain c.example on Server B).
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='xmpp1.originating.tld'
version='1.0'
xml:lang='en'
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'>
R: <stream:features> o The server administrators are able to obtain PKIX certificates in
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> the first place.
<bidi xmlns='urn:xmpp:bidi'/>
</stream:features>
When this stream is created, it can immediately carry stanzas o The server administrators are running their own XMPP servers,
directly between the two servers. In order to send messages to and rather than using hosting services.
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.
The originating server uses STARTTLS to set up a TLS connection. In Let's consider each of these "wrinkles" in turn.
the ClientHello message initiating the connection, the
xmpp1.originating.tld includes a Server Name Indication extension set
to xmpp1.receiving.tld [RFC4366]. The remote server
xmpp1.receiving.tld responds to this request with a certificate for
its own name, xmpp1.receiving.tld and requests a client certificate
from the originating server. The originating server presents a
certificate for its own name, xmpp1.originating.tld.
At this point, the server xmpp1.originating.tld knows that 5. One-Way Authentication
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.
Once the two servers have authenticated their own names over TLS, If Server A does not present its PKIX certificate during TLS
they can request permission to send stanzas: negotiation (perhaps because it wishes to verify the identity of
I: <db:result from='sender.tld' to='target.tld' /> Server B before presenting its own credentials), Server B is unable
to mutually authenticate Server A. Therefore, Server B needs to
negotiate and authenticate a stream to Server A, just as Server A has
done:
Since xmpp1.receiving.tld doesn't yet know whether 1. Server B resolves the DNS domain name a.example.
xmpp1.originating.tld is authorized to represent sender.tld, it has
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' />
On the other hand, if the DNSSEC signature is valid, then the server 2. Server B opens a TCP connection to the resolved IP address.
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' />
I: <!-- stanza --> 3. Server B sends an initial stream header to Server A, asserting
that it is b.example:
Now that the two servers have established this connection, they can <stream:stream from='b.example' to='a.example'>
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.
The following figure summarizes the overal process: 4. Server A sends a response stream header to Server B, asserting
Originating DNS Receiving that it is a.example:
Server Server Server
----------- --------- --------
| | |
| 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'/> |
| --------------------------------------------------> |
| |
| ... |
4. Connection Model <stream:stream from='a.example' to='b.example'>
The core challenge for managing inter-server connections is the 5. The servers attempt TLS negotiation, during which Server A
multiplexing of stanzas for multiple domains onto a single transport- (acting as a TLS server) presents a PKIX certificate proving that
layer connection. There are two key pieces of state associated with it is a.example.
this multiplexing: A list of domain names that have been
authenticated for use on a connection, and a table binding pairs of
domains that are authorized for a connection.
First table that a server maintains is a connection table. Each 6. Server B checks the PKIX certificate that Server A provided; if
entry in this table contains a connection and a set of domain names. it is consistent with the XMPP profile of the matching rules from
The domain names represent the set of names for which the remote [RFC6125], Server B accepts that there is a strong domain name
server has been authenticated, according to the procedures described association between its stream to Server A and the DNS domain
in Section Section 5. This set of domain names constrains the set of name a.example.
domain pairs that can be bound to this channel; the remote server
cannot ask to transmit stanzas for an unauthenticated domain name.
+------------+---------------------+------------------------+ Unfortunately, now the servers are using two TCP connections instead
| Connection | Server Domain Names | Delegated Domain Names | of one, which is somewhat wasteful. However, there are ways to tie
+------------+---------------------+------------------------+ the authentication achieved on the second TCP connection to the first
| XXX | xmpp1.provider.com | capulet.example | TCP connection; see [XEP-0288] for further discussion.
| YYY | xmpp2.provider.com | capulet.example |
| AAA | paris.example | paris.example |
+------------+---------------------+------------------------+
To determine how to handle incoming and outgoing stanzas, each server 6. Piggybacking
maintains a channel binding table. Each row in the binding table
contains a "local" domain name, a "remote" domain name, and an
ordered list of connections. The identifier for a connection is the
stream ID for the single XMPP stream that it carries.
+------------------+-----------------+---------------+ 6.1. Assertion
| Local | Remote | Connections |
+------------------+-----------------+---------------+
| 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.
In the same way, when a server receives a stanza over a connection Consider the common scenario in which Server B hosts not only
from a remote server, it looks up the relevant entry in the binding b.example but also a second domain c.example. If a user of Server B
table, this time using the 'to' domain as the local domain and the associated with c.example wishes to communicate with a friend at
'from' domain as the remote domain. If the server finds a binding a.example, Server B needs to send XMPP stanzas from the domain
table entry and the connection over which the stanza arrived is c.example rather than b.example. Although Server B could open an new
listed in the entry, then it accepts the stanza. Otherwise, it MUST TCP connection and negotiate new XML streams for the domain pair of
discard the stanza and return a stanza error <invalid-connection/>. c.example and a.example, that too is wasteful. Server B already has
In the above example, a stanza from capulet.example to a connection to a.example, so how can it assert that it would like to
escalus.example would be accepted on connections AAA and BBB, but no add a new domain pair to the existing connection?
others.
When a connection is opened (and at some points thereafter), entries The traditional method for doing so is the Server Dialback protocol,
in the name table are established using the processes in Section first specified in [RFC3920] and since moved to [XEP-0220]. Here,
Section 5. Once a connection is open, binding table entries are Server B can send a <db:result/> element for the new domain pair over
added or removed using the processes in Section Section 6. When a the existing stream.
connection is closed, both servers MUST delete its entry in the name
table and remove it from all entries in the binding table.
5. Channel Establishment and Authentication <db:result from='c.example' to='a.example'>
some-dialback-key
</db:result>
When a server wants to send a stanza and doesn't have an entry in the This element functions as Server B's assertion that it is (also)
connection table for the destination domain, it sets one up. The c.example, and thus is functionally equivalent to the 'from' address
first step is to establish a connection to a server for the of an initial stream header as previously described.
destination domain, and validate that the server is authorized to
represent the destination domain.
The originating server MUST take the following steps to establish a In response to this assertion, Server A needs to obtain some kind of
secure connection to the server for example.com: proof that Server B really is also c.example. It can do the same
thing that it did before:
1. Retrieve SRV records for XMPP services for example.com 1. Server A resolves the DNS domain name c.example.
[I-D.ietf-xmpp-3920bis].
2. Verify that the SRV records have been signed using DNSSEC 2. Server A opens a TCP connection to the resolved IP address (which
[RFC4033]. The originating server may either retrieve DNSSEC might be the same IP address as for b.example).
records directly or rely on a validating resolver. If the SRV
records are not secured with DNSSEC, then the connection fails.
3. If there is already a connection in the connection table that has 3. Server A sends an initial stream header to Server B, asserting
the target of any SRV record in its "server names" list, then that it is a.example:
this process terminates and the server attempts to use that
connection (See Section Section 6)
4. If there is no existing connection that matches, establish a TCP <stream:stream from='a.example' to='c.example'>
connection to any of the servers listed in an SRV record and
negotiate an XMPP stream with the following parameters:
* 'from' domain: The originating server's name 4. Server B sends a response stream header to Server A, asserting
that it is c.example:
* 'to' domain: The receiving server's name from the SRV record <stream:stream from='c.example' to='a.example'>
* [[ TODO: Add a stream feature to indicate support for this 5. The servers attempt TLS negotiation, during which Server B
extension ]] (acting as a TLS server) presents a PKIX certificate proving that
it is c.example.
5. Upgrade the connection to TLS using STARTTLS, using a cipher 6. Server A checks the PKIX certificate that Server B provided; if
suite that requires the server to present an X.509 certificate. it is consistent with the XMPP profile of the matching rules from
[RFC6125], Server A accepts that there is a strong domain name
association between its stream to Server B and the DNS domain
name c.example.
6. Verify that the certificate is valid and chains to a local trust Now that Server A accepts the domain name association, it informs
anchor. If the certificate is invalid, the connection fails. Server B of that fact:
7. Construct a list of all names that the certificate presents <db:result from='a.example' to='c.example' type='valid'/>
[I-D.saintandre-tls-server-id-check].
8. Verify that the target name in the SRV record is one of the names The parties can then terminate the second connection, since it was
in the certificate. If the target name is not found in the list used only for Server A to associate a stream over the same IP:port
of names from the certificate, then the connection fails. combination with the domain name c.example (dialback key links the
original stream to the new association).
A server receiving such a connection MUST perform the following 6.2. Supposition
steps:
1. Accept the TCP connection from the remote side and accept the Piggybacking can also occur in the other direction. Consider the
stream negotiation using server names. common scenario in which Server A provides XMPP services not only for
a.example but also for a subdomain such as a groupchat service at
chatrooms.a.example (see [XEP-0045]). If a user from c.example at
Server B wishes to join a room on the groupchat sevice, Server B
needs to send XMPP stanzas from the domain c.example to the domain
chatrooms.a.example rather than a.example. Therefore, Server B needs
to negotiate and authenticate a stream to chatrooms.a.example:
2. In the TLS negotiation, require a client certificate from the 1. Server B resolves the DNS domain name chatrooms.a.example.
remote side.
3. Verify that the remote server name in the stream matches the 2. Server B opens a TCP connection to the resolved IP address.
client certificate [I-D.saintandre-tls-server-id-check]. If the
certificate does not match, the TLS negotiation fails, and the
server MAY terminate the TCP connection.
If this process establishes a new connection, then the originating 3. Server B sends an initial stream header to Server A acting as
server knows that it has established a connection to a server that chatrooms.a.example, asserting that it is b.example:
legitimately represents example.com. It should thus initialize a row
in the connection table for this connection:
o Server names: The list of names in the server's certificate <stream:stream from='b.example' to='chatrooms.a.example'>
o Delegated names: example.com 4. Server A sends a response stream header to Server B, asserting
that it is chatrooms.a.example:
If the process terminated at Step 3, then the server simply updates <stream:stream from='chatrooms.a.example' to='b.example'>
the connection table entry to add example.com to the list of
delegated names. In either case, the row for a connection is removed
from the connection table when the connection is closed.
In order for this process to work, the domain owner and the hosting 5. The servers attempt TLS negotiation, during which Server A
provider need to publish information that other XMPP entities can use (acting as a TLS server) presents a PKIX certificate proving that
to verify the delegation. XMPP services are delegated via SRV it is chatrooms.a.example.
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.
The server on the receiving end of the TLS connection MUST request a 6. Server B checks the PKIX certificate that Server A provided; if
client certificate from the originating server during the TLS it is consistent with the XMPP profile of the matching rules from
handshake, and the originating server MUST provide a client [RFC6125], Server B accepts that there is a strong domain name
certificate. The receiving server can then also initialize an entry association between its stream to Server A and the DNS domain
in its connection table to which delegated names can be added later: name chatrooms.a.example.
o Server names: The list of names from the client certificate (from As before, the parties now have two TCP connections open. So that
the originating server), if present. Otherwise, empty. they can close the now-redundant connection, Server B sends a
dialback key to Server A over the new connection.
o Delgated names: Empty. <db:result from='c.example' to='chatrooms.a.example'>
some-dialback-key
</db:result>
Once the two servers have established a TLS connection, they MUST set Server A then informs Server B that it accepts the domain name
up an XMPP stream that will be used for domains that they represent. association:
This process follows the normal stream initiation procedure
[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.
Since server-to-server connections are by default directional, it is <db:result from='chatrooms.a.example' to='c.example' type='valid'/>
RECOMMENDED that servers also request the <bidi> stream feature to
enable bidirectional flows on this connection [XEP-0288].
Originating DNS Receiving Server B can now close the connection over which it tested the domain
Server Server Server name association for chatrooms.a.example.
----------- --------- --------
| | |
| 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> |
| <-------------------------------------------------- |
6. Authorizing XMPP Stanzas 7. Alternative Prooftypes
Before sending traffic from a Sender Domain to a Target Domain using The foregoing protocol flows assumed that domain name associations
an established connection, the originating server MUST request were proved using the standard PKI prooftype specified in [RFC6120]:
permission to do so, and wait until it has received authorization that is, the server's proof consists of a PKIX certificate that is
from the remote service. A service receiving traffic MUST verify checked according to a profile of the matching rules from [RFC6125],
that the Sender and Target domain pair has been authorized on the the client's verification material is obtained out of band in the
connection being used. form of a trusted root, and secure DNS is not necessary.
An originating server MUST go through the following steps to reqeust However, sometimes XMPP server administrators are unable or unwilling
authorization to send traffic from a Sender Domain to a Target to obtain valid PKIX certificates for their servers (e.g., the
Domain: administrator of im.cs.podunk.example can't receive certification
authority verification messages sent to
mailto:hostmaster@podunk.example, or hosting.example.net does not
want to take on the liability of holding the certificate and private
key for example.com). In these circumstances, prooftypes other than
PKIX are desirable. Two alternatives have been defined so far: DANE
and POSH.
1. Send a <db:result/> [XEP-0220] element with Sender Domain as 7.1. DANE
'from' and Target Domain as 'to'. The server may also include a
Dialback Key as part of the element's character data, to support
legacy deployments.
2. Wait for remote service to respond with a <db:result> with Target In the DANE prooftype, the server's proof consists of a PKIX
Domain as 'from', Sender Domain as 'to' and 'type' attribute that certificate that is compared as an exact match or a hash of either
is either 'valid' or 'invalid'. In case of 'invalid', the the SubjectPublicKeyInfo or the full certificate, and the client's
originating server SHOULD examine the error cause and take verification material is obtained via secure DNS.
appropriate action and MAY retry requesting authorization on the
same connection in the future.
3. If response 'type' was 'valid', the originating server updates The DANE prooftype is based on [I-D.ietf-dane-srv]. For XMPP
its binding table to indicate that Sender Domain (Local) and purposes, the following rules apply:
Target Domain (Remote) is authorized in the sending direction for
the connection used.
4. Originating server proceeds with sending traffic from Sender o If there is no SRV resource record, pursue the fallback methods
Domain to Target Domain. described in [RFC6120].
Upon receiving a <db:result/> stanza, the receiving server MUST take o Use the 'to' address of the initial stream header to determine the
following steps: domain name of the TLS client's reference identifier (since use of
the TLS Server Name Indication is purely discretionary in XMPP, as
mentioned in [RFC6120]).
1. Verify that the receiving direction is supported for this 7.2. POSH
connection. If not, fail by disconnecting the stream. (By In the POSH (PKIX Over Secure HTTP) prooftype, the server's proof
default, connections are one-way) consists of a PKIX certificate that is checked according to the rules
from [RFC6120] and [RFC6125], the client's verification material is
obtained by retrieving the PKIK certificate over HTTPS at a well-
known URI [RFC5785], and secure DNS is not necessary since the HTTPS
retrieval mechanism relies on the chain of trust from the public key
infrastructure.
2. Verify that domain in to-attribute is hosted by the service. If POSH is fully defined in [I-D.miller-xmpp-posh-prooftype].
not, fail and respond with an <item-not-found/> error.
3. Verify that domain in from-attribute delegates hosting of their 8. Secure Delegation and Multi-Tenancy
XMPP to the remote Server Domain Name by looking up SRV and
verifying that the zone is signed. If not, fail with a <not-
authorized/> error. Note: a service MAY accept a less secure
delegation mechanism such a SRV records in a non signed zone,
subject to local policy.
4. Once secure delegation from Sending Domain to remote Server One common method for deploying XMPP services is multi-tenancy or
Domain name has been verified, service adds Sending Domain to virtual hosting: e.g., the XMPP service for example.com is actually
list of Delegated Domain Names in the Connection Table, and hosted at hosting.example.net. Such an arrangement is relatively
updates the Binding Table indicating that the Sending Domain convenient in XMPP given the use of DNS SRV records [RFC2782], such
(remote) is allowed to send traffic to Target Domain (local) on as the following pointer from example.com to hosting.example.net:
the connection.
5. Respond to remote service with a <db:result/> stanza with 'type' _xmpp-server._tcp.example.com. 0 IN SRV 0 0 5269 hosting.example.net
set to 'valid'.
A service may revoke authorization for a domain pair at any time by Secure connections with multi-tenancy can work using the PKIX
sending a <db:result> with 'type' set to invalid. Once authorization prooftype on a small scale if the provider itself wishes to host
has been revoked, the remote side MUST re-aquire authorization before several domains (e.g., several related domains such as jabber-
sending any futher traffic for the domain pair. de.example and jabber-ch.example). However, in practice the security
of multi-tenancy has been found to be unwieldy when the provider
hosts large numbers of XMPP services on behalf of multiple customers.
Typically there are two main reasons for this state of affairs: the
service provider (say, hosting.example.net) wishes to limit its
liability and therefore does not wish to hold the certificate and
private key for the customer (say, example.com) and the customer
wishes to improve the security of the service and therefore does not
wish to share its certificate and private key with service provider.
As a result, server-to-server communications to example.com go
unencrypted or the communications are TLS-encrypted but the
certificates are not checked (which is functionally equivalent to a
connection using an anonymous key exchange). This is also true of
client-to-server communications, forcing end users to override
certificate warnings or configure their clients to accept
certificates for hosting.example.net instead of example.com. The
fundamental problem here is that if DNSSEC is not used then the act
of delegation via DNS SRV records is inherently insecure.
If a server receives a stanza for a to/from pair that it does not [I-D.ietf-dane-srv] explains how to use DNSSEC for secure delegation
consider authorized, then it MUST return a <not-authorized/> error with the DANE prooftype and [I-D.miller-xmpp-posh-prooftype] explains
and MAY terminate the TCP connection. how to use HTTPS redirects for secure delegation with the POSH
prooftype.
Originating Receiving DNS 9. Prooftype Model
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> |
| -----------------------> |
7. Backward Compatibility In general, a DNA prooftype conforms to the following definition:
Using Server Domain Names as to/from attributes in <stream> stanzas prooftype: A mechanism for proving an association between a domain
is incompatible with XMPP services that do not support this protocol, name and an XML stream, where the mechanism defines (1) the nature
because it was previously assumed that when receiving a connection of the server's proof, (2) the matching rules for comparing the
the stream to attibute will contains an XMPP domain hosted by the client's verification material against the server's proof, (3) how
receiving service. It is RECOMMENDED that if the connection fails, the client obtains its verification material, and (4) whether the
the service tries again using the Remote Domain as stream to- mechanism depends on secure DNS.
attribute.
Presenting a certificate for the Server Domain Name is incompatible The PKI, DANE, and POSH prooftypes adhere to this model. In
with XMPP services that do not support this protocol, because those addition, other prooftypes are possible (examples might include PGP
will expect the Remote Domain in the certificate. It is RECOMMENDED keys rather than PKIX certificates, or a token mechanism such as
that if the authorization fails, the service tries again presenting Kerberos or OAuth).
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.
8. Operational Considerations Some prooftypes depend on (or are enhanced by) secure DNS and
therefore also need to describe how secure delegation occurs for that
prooftype.
[[ What names to put in certs for servers in a cluster, i.e., all of 10. Security Considerations
them. ]]
[[ Do TLS clients support multiple names in certs? ]] This document supplements but does not supersede the security
considerations of [RFC6120] and [RFC6125]. Relevant security
considerations can also be found in [I-D.ietf-dane-srv] and
[I-D.miller-xmpp-posh-prooftype].
[[ How DNSSEC validation is done can vary depending on deployment 11. IANA Considerations
scenario. ]]
[[ Since SNI is used to signal support for this extension, This document has no actions for the IANA.
recommended not to serve end users on the same domain as hosting
services. ]]
[[ Load balancing thoughts, since each connection will handle a lot 12. References
more traffic? ]]
9. IANA Considerations 12.1. Normative References
[[ Register XML schema for assertions, if necessary ]] [I-D.ietf-dane-srv]
Finch, T., "Using DNS-Based Authentication of Named
Entities (DANE) TLSA records with SRV and MX records.",
draft-ietf-dane-srv-02 (work in progress), February 2013.
[[ Define invalid-connection error element ]] [I-D.miller-xmpp-posh-prooftype]
Saint-Andre, P., "Using PKIX over Secure HTTP (POSH) as a
Prooftype for XMPP Domain Name Associations", draft-
miller-xmpp-posh-prooftype-03 (work in progress), February
2013.
10. Security Considerations [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[[ This document simplifies authentication and authorization of XMPP [RFC1035] Mockapetris, P., "Domain names - implementation and
servers in certain scenarios. When used together with DNSSEC- specification", STD 13, RFC 1035, November 1987.
protected delegations, it does not introduce any new security risks.
]]
[[ If a provider chooses to omit DNSSEC checks or ]] [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
11. Acknowledgements [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, May 2005.
Thanks to Joe Hildebrand and Sean Turner for prompting the original [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
work on this problem, and to Stephen Farrell for his work on initial 4949, August 2007.
versions of this draft.
12. Normative References [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.
[I-D.ietf-xmpp-3920bis] [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Saint-Andre, P., "Extensible Messaging and Presence Uniform Resource Identifiers (URIs)", RFC 5785, April
Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-22 (work 2010.
in progress), December 2010.
[I-D.saintandre-tls-server-id-check] [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Saint-Andre, P. and J. Hodges, "Representation and Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", draft-saintandre-tls-server-id-check-14 Security (TLS)", RFC 6125, March 2011.
(work in progress), January 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [XEP-0220]
Requirement Levels", BCP 14, RFC 2119, March 1997. Miller, J., Saint-Andre, P., and P. Hancke, "Server
Dialback", XSF XEP 0220, August 2012.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 12.2. Informative References
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Rose, "Resource Records for the DNS Security Extensions", Protocol (XMPP): Core", RFC 3920, October 2004.
RFC 4034, March 2005.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [XEP-0045]
and T. Wright, "Transport Layer Security (TLS) Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February
Extensions", RFC 4366, April 2006. 2012.
[XEP-0220] [XEP-0238]
Miller, J., Saint-Andre, P., and P. Hancke, "Server Saint-Andre, P., "XMPP Protocol Flows for Inter-Domain
Dialback", XSF XEP 0220, March 2010. Federation", XSF XEP 0238, March 2008.
[XEP-0288] [XEP-0288]
Hancke, P. and D. Cridland, "Bidirectional Server-to- Hancke, P. and D. Cridland, "Bidirectional Server-to-
Server Connections", XSF XEP 0288, October 2010. Server Connections", XSF XEP 0288, August 2012.
Authors' Addresses Authors' Addresses
Richard L. Barnes Peter Saint-Andre
BBN Technologies Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO 80202
USA
Email: rbarnes@bbn.com Email: psaintan@cisco.com
Jonas Lindberg Matthew Miller
Google Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO 80202
USA
Email: jonasl@google.com Email: mamille2@cisco.com
 End of changes. 120 change blocks. 
593 lines changed or deleted 480 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/