draft-ietf-xmpp-dna-07.txt   draft-ietf-xmpp-dna-08.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft &yet Internet-Draft &yet
Intended status: Standards Track M. Miller Intended status: Standards Track M. Miller
Expires: April 14, 2015 Cisco Systems, Inc. Expires: April 26, 2015 Cisco Systems, Inc.
October 11, 2014 October 23, 2014
Domain Name Associations (DNA) in the Extensible Messaging and Presence Domain Name Associations (DNA) in the Extensible Messaging and Presence
Protocol (XMPP) Protocol (XMPP)
draft-ietf-xmpp-dna-07 draft-ietf-xmpp-dna-08
Abstract Abstract
This document improves the security of the Extensible Messaging and This document improves the security of the Extensible Messaging and
Presence Protocol (XMPP) in two ways. First, it specifies how to Presence Protocol (XMPP) in two ways. First, it specifies how to
establish a strong association between a domain name and an XML establish a strong association between a domain name and an XML
stream, using the concept of "prooftypes". Second, it describes how stream, using the concept of "prooftypes". Second, it describes how
to securely delegate a service domain name (e.g., example.com) to a to securely delegate a service domain name (e.g., example.com) to a
target server host name (e.g., hosting.example.net), which is target server host name (e.g., hosting.example.net), which is
especially important in multi-tenanted environments where the same especially important in multi-tenanted environments where the same
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 April 14, 2015. This Internet-Draft will expire on April 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4.2. A Simple S2S Scenario . . . . . . . . . . . . . . . . . . 7 4.2. A Simple S2S Scenario . . . . . . . . . . . . . . . . . . 7
4.3. One-Way Authentication . . . . . . . . . . . . . . . . . 8 4.3. One-Way Authentication . . . . . . . . . . . . . . . . . 8
4.4. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 9
4.4.1. Assertion . . . . . . . . . . . . . . . . . . . . . . 9 4.4.1. Assertion . . . . . . . . . . . . . . . . . . . . . . 9
4.4.2. Supposition . . . . . . . . . . . . . . . . . . . . . 11 4.4.2. Supposition . . . . . . . . . . . . . . . . . . . . . 11
5. Alternative Prooftypes . . . . . . . . . . . . . . . . . . . 12 5. Alternative Prooftypes . . . . . . . . . . . . . . . . . . . 12
5.1. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. POSH . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. POSH . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Secure Delegation and Multi-Tenancy . . . . . . . . . . . . . 13 6. Secure Delegation and Multi-Tenancy . . . . . . . . . . . . . 13
7. Prooftype Model . . . . . . . . . . . . . . . . . . . . . . . 14 7. Prooftype Model . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. Well-Known URI for xmpp-client Service . . . . . . . . . 14 8.1. Well-Known URI for xmpp-client Service . . . . . . . . . 15
8.2. Well-Known URI for xmpp-server Service . . . . . . . . . 15 8.2. Well-Known URI for xmpp-server Service . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
In systems that use the Extensible Messaging and Presence Protocol In systems that use the Extensible Messaging and Presence Protocol
(XMPP) [RFC6120], it is important to establish a strong association (XMPP) [RFC6120], it is important to establish a strong association
between the DNS domain name of an XMPP service (e.g., example.com) between the DNS domain name of an XMPP service (e.g., example.com)
and the XML stream that a client or peer server initiates with that and the XML stream that a client or peer server initiates with that
service. In other words, the client or peer server needs to verify service. In other words, the client or peer server needs to verify
the identity of the server to which it connects. the identity of the server to which it connects.
skipping to change at page 13, line 21 skipping to change at page 13, line 21
In the POSH prooftype, the server's proof consists of a PKIX In the POSH prooftype, the server's proof consists of a PKIX
certificate that is checked according to the rules from [RFC6120] and certificate that is checked according to the rules from [RFC6120] and
[RFC6125], the client's verification material is obtained by [RFC6125], the client's verification material is obtained by
retrieving the PKIX certificate over HTTPS at a well-known URI retrieving the PKIX certificate over HTTPS at a well-known URI
[RFC5785], and secure DNS is not necessary since the HTTPS retrieval [RFC5785], and secure DNS is not necessary since the HTTPS retrieval
mechanism relies on the chain of trust from the public key mechanism relies on the chain of trust from the public key
infrastructure. infrastructure.
POSH is defined in [I-D.ietf-xmpp-posh]. For XMPP purposes, the POSH is defined in [I-D.ietf-xmpp-posh]. For XMPP purposes, the
well-known URIs [RFC5785] to be used are: following rules apply:
o If no verification materials are found via POSH, pursue the
fallback methods described in [RFC6120].
o Use the 'to' address of the initial stream header to determine the
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]).
The well-known URIs [RFC5785] to be used for POSH are:
o "/.well-known/posh._xmpp-client._tcp.json" for client-to-server o "/.well-known/posh._xmpp-client._tcp.json" for client-to-server
connections connections
o "/.well-known/posh._xmpp-server._tcp.json" for server-to-server o "/.well-known/posh._xmpp-server._tcp.json" for server-to-server
connections connections
6. Secure Delegation and Multi-Tenancy 6. Secure Delegation and Multi-Tenancy
One common method for deploying XMPP services is multi-tenancy: e.g., One common method for deploying XMPP services is multi-tenancy: e.g.,
skipping to change at page 14, line 31 skipping to change at page 14, line 41
In general, a domain name association (DNA) prooftype conforms to the In general, a domain name association (DNA) prooftype conforms to the
following definition: following definition:
prooftype: A mechanism for proving an association between a domain prooftype: A mechanism for proving an association between a domain
name and an XML stream, where the mechanism defines (1) the nature name and an XML stream, where the mechanism defines (1) the nature
of the server's proof, (2) the matching rules for comparing the of the server's proof, (2) the matching rules for comparing the
client's verification material against the server's proof, (3) how client's verification material against the server's proof, (3) how
the client obtains its verification material, and (4) whether the the client obtains its verification material, and (4) whether the
mechanism depends on secure DNS. mechanism depends on secure DNS.
The PKIX, DANE, and POSH prooftypes adhere to this model. In The PKIX, DANE, and POSH prooftypes adhere to this model. (Some
addition, other prooftypes are possible (examples might include PGP prooftypes depend on, or are enhanced by, secure DNS and thus also
keys rather than PKIX certificates, or a token mechanism such as need to describe how they ensure secure delegation.)
Kerberos or OAuth).
Some prooftypes depend on (or are enhanced by) secure DNS and thus Other prooftypes are possible; examples might include TLS with PGP
also need to describe how they ensure secure delegation. keys [RFC6091], a token mechanism such as Kerberos [RFC4120] or OAuth
[RFC6749], and Server Dialback keys [XEP-0220].
Although the PKIX prooftype reuses the syntax of the XMPP Server
Dialback protocol [XEP-0220] for signalling between servers, this
framework document does not define how the generation and validation
of Server Dialback keys (also specified in [XEP-0220]) is a DNA
prooftype. However, nothing in this document prevents the continued
use of server dialback, and a future specification (or an updated
version of [XEP-0220]) might define a DNA prooftype for dialback in a
way that is consistent with this framework. However, nothing in this
document prevents the continued use of Server Dialback on the XMPP
network.
8. IANA Considerations 8. IANA Considerations
The POSH specification [I-D.ietf-xmpp-posh] provides guidelines for The POSH specification [I-D.ietf-xmpp-posh] provides guidelines for
registering the well-known URIs [RFC5785] of protocols that make use registering the well-known URIs [RFC5785] of protocols that make use
of POSH. This specification registers two such URIs, for which the of POSH. This specification registers two such URIs, for which the
completed registration templates follow. completed registration templates follow.
8.1. Well-Known URI for xmpp-client Service 8.1. Well-Known URI for xmpp-client Service
skipping to change at page 15, line 37 skipping to change at page 16, line 12
considerations can also be found in [I-D.ietf-dane-srv] and considerations can also be found in [I-D.ietf-dane-srv] and
[I-D.ietf-xmpp-posh]. [I-D.ietf-xmpp-posh].
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-dane-srv] [I-D.ietf-dane-srv]
Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
Based Authentication of Named Entities (DANE) TLSA records Based Authentication of Named Entities (DANE) TLSA records
with SRV and MX records.", draft-ietf-dane-srv-07 (work in with SRV and MX records.", draft-ietf-dane-srv-08 (work in
progress), July 2014. progress), October 2014.
[I-D.ietf-xmpp-posh] [I-D.ietf-xmpp-posh]
Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP
(POSH)", draft-ietf-xmpp-posh-02 (work in progress), (POSH)", draft-ietf-xmpp-posh-02 (work in progress),
October 2014. October 2014.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
skipping to change at page 17, line 5 skipping to change at page 17, line 31
Dialback", XSF XEP 0220, September 2013. Dialback", XSF XEP 0220, September 2013.
10.2. Informative References 10.2. Informative References
[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
FUNCTIONS", RFC 2142, May 1997. FUNCTIONS", RFC 2142, May 1997.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys
for Transport Layer Security (TLS) Authentication", RFC
6091, February 2011.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
6749, October 2012.
[XEP-0045] [XEP-0045]
Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February
2012. 2012.
[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, September 2013. Server Connections", XSF XEP 0288, September 2013.
Appendix A. Acknowledgements Appendix A. Acknowledgements
 End of changes. 10 change blocks. 
20 lines changed or deleted 52 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/