draft-ietf-xmpp-address-07.txt   draft-ietf-xmpp-address-08.txt 
XMPP P. Saint-Andre XMPP P. Saint-Andre
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track November 17, 2010 Updates: 3920 (if approved) December 10, 2010
Expires: May 21, 2011 Intended status: Standards Track
Expires: June 13, 2011
Extensible Messaging and Presence Protocol (XMPP): Address Format Extensible Messaging and Presence Protocol (XMPP): Address Format
draft-ietf-xmpp-address-07 draft-ietf-xmpp-address-08
Abstract Abstract
This document defines the format for addresses used in the Extensible This document defines the format for addresses used in the Extensible
Messaging and Presence Protocol (XMPP), including support for non- Messaging and Presence Protocol (XMPP), including support for non-
ASCII characters. ASCII characters. This document updates RFC 3920.
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 May 21, 2011. This Internet-Draft will expire on June 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 10 skipping to change at page 2, line 10
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 4
2. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Domainpart . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Domainpart . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Localpart . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Localpart . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Resourcepart . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Resourcepart . . . . . . . . . . . . . . . . . . . . . . . 8
3. Internationalization Considerations . . . . . . . . . . . . . 9 3. Internationalization Considerations . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4.1. Reuse of Stringprep . . . . . . . . . . . . . . . . . . . 9 4.1. Reuse of Stringprep . . . . . . . . . . . . . . . . . . . 9
4.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . . 9 4.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . . 9
4.3. Address Spoofing . . . . . . . . . . . . . . . . . . . . . 9 4.3. Address Spoofing . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Address Forging . . . . . . . . . . . . . . . . . . . 9 4.3.1. Address Forging . . . . . . . . . . . . . . . . . . . 10
4.3.2. Address Mimicking . . . . . . . . . . . . . . . . . . 10 4.3.2. Address Mimicking . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5.1. Nodeprep Profile of Stringprep . . . . . . . . . . . . . . 13 5.1. Nodeprep Profile of Stringprep . . . . . . . . . . . . . . 13
5.2. Resourceprep Profile of Stringprep . . . . . . . . . . . . 13 5.2. Resourceprep Profile of Stringprep . . . . . . . . . . . . 13
6. Conformance Requirements . . . . . . . . . . . . . . . . . . . 13 6. Conformance Requirements . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 18
A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 18 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 18
A.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 18 A.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 19
A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 18 A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 19 A.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 19
A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 19 A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 19
A.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 19 A.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 20
A.7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 19 A.7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 20
B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 20 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 21
B.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 21 B.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 21
B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 21 B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 21
B.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 21 B.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 21
B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 21 B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 21
B.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 21 B.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 22
Appendix C. Differences From RFC 3920 . . . . . . . . . . . . . . 21 Appendix C. Differences From RFC 3920 . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
The Extensible Messaging and Presence Protocol (XMPP) is an The Extensible Messaging and Presence Protocol (XMPP) is an
application profile of the Extensible Markup Language [XML] for application profile of the Extensible Markup Language [XML] for
streaming XML data in close to real time between any two or more streaming XML data in close to real time between any two or more
network-aware entities. The address format for XMPP entities was network-aware entities. The address format for XMPP entities was
originally developed in the Jabber open-source community in 1999, originally developed in the Jabber open-source community in 1999,
skipping to change at page 4, line 5 skipping to change at page 4, line 5
this specification will be superseded as soon as work on a new this specification will be superseded as soon as work on a new
approach to preparation and comparison of internationalized strings approach to preparation and comparison of internationalized strings
has been defined by the PRECIS Working Group and applied to the has been defined by the PRECIS Working Group and applied to the
specific cases of XMPP localparts and resourceparts. In the specific cases of XMPP localparts and resourceparts. In the
meantime, this document normatively references [IDNA2003] and meantime, this document normatively references [IDNA2003] and
[NAMEPREP]; XMPP software implementations are encouraged to begin [NAMEPREP]; XMPP software implementations are encouraged to begin
migrating to IDNA2008 (see [IDNA-PROTO] and related documents) migrating to IDNA2008 (see [IDNA-PROTO] and related documents)
because it is nearly certain that the specification superseding this because it is nearly certain that the specification superseding this
one will re-use IDNA2008. one will re-use IDNA2008.
This document updates RFC 3920.
1.2. Terminology 1.2. Terminology
Many important terms used in this document are defined in [IDNA2003], Many important terms used in this document are defined in [IDNA2003],
[STRINGPREP], [UNICODE], and [XMPP]. [STRINGPREP], [UNICODE], and [XMPP].
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[KEYWORDS]. [KEYWORDS].
1.3. Acknowledgements
Thanks to Ben Campbell, Waqas Hussain, Jehan Pages and Florian Zeitz
for their feedback. Thanks also to Richard Barnes for his review on
behalf of the Security Directorate.
The Working Group chairs were Ben Campbell and Joe Hildebrand.
The responsible Area Director was Gonzalo Camarillo.
Some text in this document was borrowed or adapted from [IDNA-DEFS],
[IDNA-PROTO], [IDNA-RATIONALE], and [XEP-0165].
2. Addresses 2. Addresses
2.1. Fundamentals 2.1. Fundamentals
An XMPP entity is anything that is network-addressable and that can An XMPP entity is anything that is network-addressable and that can
communicate using XMPP. For historical reasons, the native address communicate using XMPP. For historical reasons, the native address
of an XMPP entity is called a Jabber Identifier or JID. A valid JID of an XMPP entity is called a Jabber Identifier or JID. A valid JID
is a string of [UNICODE] code points, encoded using [UTF-8], and is a string of [UNICODE] code points, encoded using [UTF-8], and
structured as an ordered sequence of localpart, domainpart, and structured as an ordered sequence of localpart, domainpart, and
resourcepart (where the first two parts are demarcated by the '@' resourcepart (where the first two parts are demarcated by the '@'
character used as a separator, and the last two parts are similarly character used as a separator, and the last two parts are similarly
demarcated by the '/' character). demarcated by the '/' character).
The syntax for a JID is defined as follows using the Augmented The syntax for a JID is defined as follows using the Augmented
Backus-Naur Form as specified in [ABNF]. Backus-Naur Form as specified in [ABNF].
jid = [ localpart "@" ] domainpart [ "/" resourcepart ] jid = [ localpart "@" ] domainpart [ "/" resourcepart ]
localpart = 1*(nodepoint) localpart = 1*(nodepoint)
;
; a "nodepoint" is a UTF-8 encoded Unicode code ; a "nodepoint" is a UTF-8 encoded Unicode code
; point that satisfies the Nodeprep profile of ; point that satisfies the Nodeprep profile of
; stringprep ; stringprep
;
domainpart = IP-literal / IPv4address / ifqdn domainpart = IP-literal / IPv4address / ifqdn
;
; the "IPv4address" and "IP-literal" rules are ; the "IPv4address" and "IP-literal" rules are
; defined in RFC 3986, and the first-match-wins ; defined in RFC 3986, and the first-match-wins
; (a.k.a. "greedy") algorithm described in RFC ; (a.k.a. "greedy") algorithm described in RFC
; 3986 applies to the matching process ; 3986 applies to the matching process
;
; note well that re-use of the IP-literal rule
; from RFC 3986 implies that IPv6 addresses are
; enclosed in square brackets (i.e., beginning
; with '[' and ending with ']'), which was not
; the case in RFC 3920
;
ifqdn = 1*(namepoint) ifqdn = 1*(namepoint)
;
; a "namepoint" is a UTF-8 encoded Unicode ; a "namepoint" is a UTF-8 encoded Unicode
; code point that satisfies the Nameprep ; code point that satisfies the Nameprep
; profile of stringprep ; profile of stringprep
;
resourcepart = 1*(resourcepoint) resourcepart = 1*(resourcepoint)
;
; a "resourcepoint" is a UTF-8 encoded Unicode ; a "resourcepoint" is a UTF-8 encoded Unicode
; code point that satisfies the Resourceprep ; code point that satisfies the Resourceprep
; profile of stringprep ; profile of stringprep
;
All JIDs are based on the foregoing structure. One common use of All JIDs are based on the foregoing structure.
this structure is to identify a messaging and presence account, the
server that hosts the account, and a connected resource (e.g., a
specific device) in the form of <localpart@domainpart/resourcepart>.
However, localparts other than clients are possible; for example, a
specific chat room offered by a multi-user chat service (see
[XEP-0045]) is addressed as <room@service> (where "room" is the name
of the chat room and "service" is the hostname of the multi-user chat
service) and a specific occupant of such a room could be addressed as
<room@service/nick> (where "nick" is the occupant's room nickname).
Many other JID types are possible (e.g., <domainpart/resourcepart>
could be a server-side script or service).
Each allowable portion of a JID (localpart, domainpart, and Each allowable portion of a JID (localpart, domainpart, and
resourcepart) MUST NOT be zero bytes in length and MUST NOT be more resourcepart) MUST NOT be zero bytes in length and MUST NOT be more
than 1023 bytes in length, resulting in a maximum total size than 1023 bytes in length, resulting in a maximum total size
(including the '@' and '/' separators) of 3071 bytes. (including the '@' and '/' separators) of 3071 bytes.
For the purpose of communication over an XMPP network (e.g., in the For the purpose of communication over an XMPP network (e.g., in the
'to' or 'from' address of an XMPP stanza), an entity's address MUST 'to' or 'from' address of an XMPP stanza), an entity's address MUST
be represented as a JID, not as a Uniform Resource Identifier [URI] be represented as a JID, not as a Uniform Resource Identifier [URI]
or Internationalized Resource Identifier [IRI]. An XMPP URI or IRI or Internationalized Resource Identifier [IRI]. An XMPP IRI
[XMPP-URI] is in essence a JID prepended with 'xmpp:', but the native [XMPP-URI] is in essence a JID prepended with 'xmpp:'; however, the
addressing format used in XMPP is that of a mere JID without a URI native addressing format used in XMPP is that of a mere JID without a
scheme. [XMPP-URI] is provided only for identification and URI scheme. [XMPP-URI] is provided only for identification and
interaction outside the context of XMPP itself, for example when interaction outside the context of XMPP itself, for example when
linking to a JID from a web page. See [XMPP-URI] for a description linking to a JID from a web page. See [XMPP-URI] for a description
of the process for securely extracting a JID from an XMPP URI or IRI. of the process for securely extracting a JID from an XMPP URI or IRI.
Implementation Note: When dividing a JID into its component parts, Implementation Note: When dividing a JID into its component parts,
an implementation needs to match the separator characters '@' and an implementation needs to match the separator characters '@' and
'/' before applying any transformation algorithms, which might '/' before applying any transformation algorithms, which might
decompose certain Unicode code points to the separator characters decompose certain Unicode code points to the separator characters
(e.g., U+FE6B SMALL COMMERCIAL AT might decompose into U+0040 (e.g., U+FE6B SMALL COMMERCIAL AT might decompose into U+0040
COMMERCIAL AT). COMMERCIAL AT).
2.2. Domainpart 2.2. Domainpart
The DOMAINPART of a JID is that portion after the '@' character (if The domainpart of a JID is that portion after the '@' character (if
any) and before the '/' character (if any); it is the primary any) and before the '/' character (if any); it is the primary
identifier and is the only REQUIRED element of a JID (a mere identifier and is the only REQUIRED element of a JID (a mere
domainpart is a valid JID). Typically a domainpart identifies the domainpart is a valid JID). Typically a domainpart identifies the
"home" server to which clients connect for XML routing and data "home" server to which clients connect for XML routing and data
management functionality. However, it is not necessary for an XMPP management functionality. However, it is not necessary for an XMPP
domainpart to identify an entity that provides core XMPP server domainpart to identify an entity that provides core XMPP server
functionality (e.g., a domainpart can identify an entity such as a functionality (e.g., a domainpart can identify an entity such as a
multi-user chat service, a publish-subscribe service, or a user multi-user chat service, a publish-subscribe service, or a user
directory). directory).
skipping to change at page 6, line 36 skipping to change at page 6, line 38
domain name ("FQDN"; see [DNS]), IPv4 address, IPv6 address, or domain name ("FQDN"; see [DNS]), IPv4 address, IPv6 address, or
unqualifed hostname (i.e., a text label that is resolvable on a local unqualifed hostname (i.e., a text label that is resolvable on a local
network). network).
Interoperability Note: Domainparts that are IP addresses might not Interoperability Note: Domainparts that are IP addresses might not
be accepted by other services for the sake of server-to-server be accepted by other services for the sake of server-to-server
communication, and domainparts that are unqualified hostnames communication, and domainparts that are unqualified hostnames
cannot be used on public networks because they are resolvable only cannot be used on public networks because they are resolvable only
on a local network. on a local network.
A domainpart MUST NOT be zero bytes in length and MUST NOT be more
than 1023 bytes in length.
If the domainpart includes a final character considered to be a label If the domainpart includes a final character considered to be a label
separator (dot) by [IDNA2003] or [DNS], this character MUST be separator (dot) by [IDNA2003] or [DNS], this character MUST be
stripped from the domainpart before the JID of which it is a part is stripped from the domainpart before the JID of which it is a part is
used for the purpose of routing an XML stanza, comparing against used for the purpose of routing an XML stanza, comparing against
another JID, or constructing an [XMPP-URI]; in particular, the another JID, or constructing an [XMPP-URI]; in particular, the
character MUST be stripped before any other canonicalization steps character MUST be stripped before any other canonicalization steps
are taken, such as application of the [NAMEPREP] profile of are taken, such as application of the [NAMEPREP] profile of
[STRINGPREP] or completion of the ToASCII operation as described in [STRINGPREP] or completion of the ToASCII operation as described in
[IDNA2003]. [IDNA2003].
skipping to change at page 7, line 28 skipping to change at page 7, line 28
"ACE label") over the wire, it MUST be possible to apply that "ACE label") over the wire, it MUST be possible to apply that
operation without failing to each internationalized label. If an operation without failing to each internationalized label. If an
XMPP application receives as input an ACE label, it SHOULD convert XMPP application receives as input an ACE label, it SHOULD convert
that ACE label to an internationalized label using the ToUnicode that ACE label to an internationalized label using the ToUnicode
operation (see [IDNA2003]) before including the label in an XMPP operation (see [IDNA2003]) before including the label in an XMPP
domainpart that will be communicated over the wire on an XMPP network domainpart that will be communicated over the wire on an XMPP network
(however, instead of converting the label, there are legitimate (however, instead of converting the label, there are legitimate
reasons why an application might instead refuse the input altogether reasons why an application might instead refuse the input altogether
and return an error to the entity that provided the offending data). and return an error to the entity that provided the offending data).
A domainpart MUST NOT be zero bytes in length and MUST NOT be more
than 1023 bytes in length. This rule is to be enforced after any
mapping or normalization resulting from application of the Nameprep
profile of stringprep (e.g., in Nameprep some characters can be
mapped to nothing, which might result in a string of zero length).
Naturally, the length limits of [DNS] apply, and nothing in this
document is to be interpreted as overriding those more fundamental
limits.
In the terms of IDNA2008 [IDNA-DEFS], the domainpart of a JID is a In the terms of IDNA2008 [IDNA-DEFS], the domainpart of a JID is a
"domain name slot". "domain name slot".
2.3. Localpart 2.3. Localpart
The LOCALPART of a JID is an optional identifier placed before the The localpart of a JID is an optional identifier placed before the
domainpart and separated from the latter by the '@' character. domainpart and separated from the latter by the '@' character.
Typically a localpart uniquely identifies the entity requesting and Typically a localpart uniquely identifies the entity requesting and
using network access provided by a server (i.e., a local account), using network access provided by a server (i.e., a local account),
although it can also represent other kinds of entities (e.g., a chat although it can also represent other kinds of entities (e.g., a chat
room associated with a multi-user chat service). The entity room associated with a multi-user chat service). The entity
represented by an XMPP localpart is addressed within the context of a represented by an XMPP localpart is addressed within the context of a
specific domain. specific domain (i.e., <localpart@domainpart>).
A localpart MUST NOT be zero bytes in length and MUST NOT be more
than 1023 bytes in length.
A localpart MUST be formatted such that the Nodeprep profile of A localpart MUST be formatted such that the Nodeprep profile of
[STRINGPREP] can be applied without failing (see Appendix A). Before [STRINGPREP] can be applied without failing (see Appendix A). Before
comparing two localparts, an application MUST first ensure that the comparing two localparts, an application MUST first ensure that the
Nodeprep profile has been applied to each identifier (the profile Nodeprep profile has been applied to each identifier (the profile
need not be applied each time a comparison is made, as long as it has need not be applied each time a comparison is made, as long as it has
been applied before comparison). been applied before comparison).
A localpart MUST NOT be zero bytes in length and MUST NOT be more
than 1023 bytes in length. This rule is to be enforced after any
mapping or normalization resulting from application of the Nodeprep
profile of stringprep (e.g., in Nodeprep some characters can be
mapped to nothing, which might result in a string of zero length).
2.4. Resourcepart 2.4. Resourcepart
The resourcepart of a JID is an optional identifier placed after the The resourcepart of a JID is an optional identifier placed after the
domainpart and separated from the latter by the '/' character. A domainpart and separated from the latter by the '/' character. A
resourcepart can modify either a <localpart@domainpart> address or a resourcepart can modify either a <localpart@domainpart> address or a
mere <domainpart> address. Typically a resourcepart uniquely mere <domainpart> address. Typically a resourcepart uniquely
identifies a specific connection (e.g., a device or location) or identifies a specific connection (e.g., a device or location) or
object (e.g., an occupant in a multi-user chat room) belonging to the object (e.g., an occupant in a multi-user chat room) belonging to the
entity associated with an XMPP localpart at a local domain. entity associated with an XMPP localpart at a domain (i.e.,
<localpart@domainpart/resourcepart>).
When an XMPP address does not include a resourcepart (i.e., when it
is of the form <domainpart> or <localpart@domainpart>), it is
referred to as a BARE JID. When an XMPP address includes a
resourcepart (i.e., when it is of the form <domainpart/resourcepart>
or <localpart@domainpart/resourcepart>), is referred to as a FULL
JID.
A resourcepart MUST NOT be zero bytes in length and MUST NOT be more
than 1023 bytes in length.
A resourcepart MUST be formatted such that the Resourceprep profile A resourcepart MUST be formatted such that the Resourceprep profile
of [STRINGPREP] can be applied without failing (see Appendix B). of [STRINGPREP] can be applied without failing (see Appendix B).
Before comparing two resourceparts, an application MUST first ensure Before comparing two resourceparts, an application MUST first ensure
that the Resourceprep profile has been applied to each identifier that the Resourceprep profile has been applied to each identifier
(the profile need not be applied each time a comparison is made, as (the profile need not be applied each time a comparison is made, as
long as it has been applied before comparison). long as it has been applied before comparison).
A resourcepart MUST NOT be zero bytes in length and MUST NOT be more
than 1023 bytes in length. This rule is to be enforced after any
mapping or normalization resulting from application of the
Resourceprep profile of stringprep (e.g., in Resourceprep some
characters can be mapped to nothing, which might result in a string
of zero length).
Informational Note: For historical reasons, the term "resource Informational Note: For historical reasons, the term "resource
identifier" is often used in XMPP to refer to the optional portion identifier" is often used in XMPP to refer to the optional portion
of an XMPP address that follows the domainpart and the "/" of an XMPP address that follows the domainpart and the "/"
separator character; to help prevent confusion between an XMPP separator character; to help prevent confusion between an XMPP
"resource identifier" and the meanings of "resource" and "resource identifier" and the meanings of "resource" and
"identifier" provided in Section 1.1 of [URI], this specification "identifier" provided in Section 1.1 of [URI], this specification
uses the term "resourcepart" instead of "resource identifier" (as uses the term "resourcepart" instead of "resource identifier" (as
in RFC 3920). in RFC 3920).
XMPP entities SHOULD consider resourceparts to be opaque strings and XMPP entities SHOULD consider resourceparts to be opaque strings and
skipping to change at page 9, line 48 skipping to change at page 10, line 11
4.3. Address Spoofing 4.3. Address Spoofing
There are two forms of address spoofing: forging and mimicking. There are two forms of address spoofing: forging and mimicking.
4.3.1. Address Forging 4.3.1. Address Forging
In the context of XMPP technologies, address forging occurs when an In the context of XMPP technologies, address forging occurs when an
entity is able to generate an XML stanza whose 'from' address does entity is able to generate an XML stanza whose 'from' address does
not correspond to the account credentials with which the entity not correspond to the account credentials with which the entity
authenticated onto the network (or an authorization identity provided authenticated onto the network (or an authorization identity provided
during SASL negotiation). For example, address forging occurs if an during negotiation of SASL authentication [SASL] as described in
entity that authenticated as "juliet@im.example.com" is able to send [XMPP]). For example, address forging occurs if an entity that
XML stanzas from "nurse@im.example.com" or "romeo@example.net". authenticated as "juliet@im.example.com" is able to send XML stanzas
from "nurse@im.example.com" or "romeo@example.net".
Address forging is difficult in XMPP systems, given the requirement Address forging is difficult in XMPP systems, given the requirement
for sending servers to stamp 'from' addresses and for receiving for sending servers to stamp 'from' addresses and for receiving
servers to verify sending domains via server-to-server authentication servers to verify sending domains via server-to-server authentication
(see [XMPP]). However, address forging is possible if: (see [XMPP]). However, address forging is possible if:
o A poorly implemented server ignores the requirement for stamping o A poorly implemented server ignores the requirement for stamping
the 'from' address. This would enable any entity that the 'from' address. This would enable any entity that
authenticated with the server to send stanzas from any authenticated with the server to send stanzas from any
localpart@domainpart as long as the domainpart matches the sending localpart@domainpart as long as the domainpart matches the sending
domain of the server. domain of the server.
o An actively malicious server generates stanzas on behalf of any o An actively malicious server generates stanzas on behalf of any
registered account. registered account.
Therefore, an entity outside the security perimeter of a particular Therefore, an entity outside the security perimeter of a particular
server cannot reliably distinguish between bare JIDs of the form server cannot reliably distinguish between JIDs of the form
<localpart@domainpart> at that server and thus can authenticate only <localpart@domainpart> at that server and thus can authenticate only
the domainpart of such JIDs with any level of assurance. This the domainpart of such JIDs with any level of assurance. This
specification does not define methods for discovering or specification does not define methods for discovering or
counteracting such poorly implemented or rogue servers. However, the counteracting such poorly implemented or rogue servers. However, the
end-to-end authentication or signing of XMPP stanzas could help to end-to-end authentication or signing of XMPP stanzas could help to
mitigate this risk, since it would require the rogue server to mitigate this risk, since it would require the rogue server to
generate false credentials in addition to modifying 'from' addresses. generate false credentials in addition to modifying 'from' addresses.
Furthermore, it is possible for an attacker to forge JIDs at other Furthermore, it is possible for an attacker to forge JIDs at other
domains by means of a DNS poisoning attack if DNS security extensions domains by means of a DNS poisoning attack if DNS security extensions
skipping to change at page 11, line 44 skipping to change at page 12, line 7
localpart could access another user's account information, or a localpart could access another user's account information, or a
user could gain access to a hidden or otherwise restricted chat user could gain access to a hidden or otherwise restricted chat
room or service. room or service.
o A resourcepart can be employed as one part of an entity's address o A resourcepart can be employed as one part of an entity's address
in XMPP. One common usage is as the name for an instant messaging in XMPP. One common usage is as the name for an instant messaging
user's connected resource; another is as the nickname of a user in user's connected resource; another is as the nickname of a user in
a multi-user chat room; and many other kinds of entities could use a multi-user chat room; and many other kinds of entities could use
resourceparts as part of their addresses. The security of such resourceparts as part of their addresses. The security of such
services could be compromised based on different interpretations services could be compromised based on different interpretations
of the internationalized resourcepart; for example, a user could of the internationalized resourcepart; for example, two or more
attempt to bind multiple resources with the same name, or a user confusable resources could be bound at the same time to the same
could send a message to someone other than the intended recipient account (resulting in inconsistent authorization decisions in an
in a multi-user chat room. XMPP application that uses full JIDs), or a user could send a
message to someone other than the intended recipient in a multi-
user chat room.
Despite the fact that some specific suggestions about identification Despite the fact that some specific suggestions about identification
and handling of confusable characters appear in the Unicode Security and handling of confusable characters appear in the Unicode Security
Considerations [UNICODE-SEC], it is also true (as noted in Considerations [UNICODE-SEC], it is also true (as noted in
[IDNA-DEFS]) that "there are no comprehensive technical solutions to [IDNA-DEFS]) that "there are no comprehensive technical solutions to
the problems of confusable characters". Mimicked JIDs that involve the problems of confusable characters". Mimicked JIDs that involve
characters from only one script, or from the script typically characters from only one script, or from the script typically
employed by a particular user or community of language users, are not employed by a particular user or community of language users, are not
easy to combat (e.g., the simple typejacking attack previously easy to combat (e.g., the simple typejacking attack previously
described, which relies on a surface similarity between the described, which relies on a surface similarity between the
characters "1" and "l" in some presentations). However, mimicked characters "1" and "l" in some presentations). However, mimicked
addresses that involve characters from more than one script, or from addresses that involve characters from more than one script, or from
a script not typically employed by a particular user or community of a script not typically employed by a particular user or community of
language users, can be mitigated somewhat through the application of language users, can be mitigated somewhat through the application of
skipping to change at page 13, line 23 skipping to change at page 13, line 38
The Nodeprep profile of stringprep is defined under Nodeprep The Nodeprep profile of stringprep is defined under Nodeprep
(Appendix A). The IANA has registered Nodeprep in the stringprep (Appendix A). The IANA has registered Nodeprep in the stringprep
profile registry. profile registry.
Name of this profile: Name of this profile:
Nodeprep Nodeprep
RFC in which the profile is defined: RFC in which the profile is defined:
XXXX RFC XXXX
Indicator whether or not this is the newest version of the profile: Indicator whether or not this is the newest version of the profile:
This is the first version of Nodeprep This is the first version of Nodeprep
5.2. Resourceprep Profile of Stringprep 5.2. Resourceprep Profile of Stringprep
The Resourceprep profile of stringprep is defined under Resourceprep The Resourceprep profile of stringprep is defined under Resourceprep
(Appendix B). The IANA has registered Resourceprep in the stringprep (Appendix B). The IANA has registered Resourceprep in the stringprep
profile registry. profile registry.
Name of this profile: Name of this profile:
Resourceprep Resourceprep
RFC in which the profile is defined: RFC in which the profile is defined:
XXXX RFC XXXX
Indicator whether or not this is the newest version of the profile: Indicator whether or not this is the newest version of the profile:
This is the first version of Resourceprep This is the first version of Resourceprep
6. Conformance Requirements 6. Conformance Requirements
This section describes a protocol feature set that summarizes the This section describes a protocol feature set that summarizes the
conformance requirements of this specification. This feature set is conformance requirements of this specification. This feature set is
appropriate for use in software certification, interoperability appropriate for use in software certification, interoperability
skipping to change at page 14, line 33 skipping to change at page 14, line 47
The feature set specified here attempts to adhere to the concepts and The feature set specified here attempts to adhere to the concepts and
formats proposed by Larry Masinter within the IETF's NEWTRK Working formats proposed by Larry Masinter within the IETF's NEWTRK Working
Group in 2005, as captured in [INTEROP]. Although this feature set Group in 2005, as captured in [INTEROP]. Although this feature set
is more detailed than called for by [REPORTS], it provides a suitable is more detailed than called for by [REPORTS], it provides a suitable
basis for the generation of implementation reports to be submitted in basis for the generation of implementation reports to be submitted in
support of advancing this specification from Proposed Standard to support of advancing this specification from Proposed Standard to
Draft Standard in accordance with [PROCESS]. Draft Standard in accordance with [PROCESS].
Feature: address-domain-length Feature: address-domain-length
Description: Ensure that the domainpart of an XMPP address is at Description: Ensure that the domainpart of an XMPP address is at
least one byte in length and at most 1023 bytes in length. least one byte in length and at most 1023 bytes in length, and
conforms to the underlying length limits of the DNS.
Section: Section 2.2 Section: Section 2.2
Roles: Both MUST. Roles: Both MUST.
Feature: address-domain-prep Feature: address-domain-prep
Description: Ensure that the domainpart of an XMPP address conforms Description: Ensure that the domainpart of an XMPP address conforms
to the Nameprep profile of Stringprep. to the Nameprep profile of Stringprep.
Section: Section 2.2 Section: Section 2.2
Roles: Client SHOULD, Server MUST. Roles: Client SHOULD, Server MUST.
Feature: address-localpart-length Feature: address-localpart-length
skipping to change at page 15, line 30 skipping to change at page 15, line 45
Section: Section 2.2 Section: Section 2.2
Roles: Client SHOULD, Server MUST. Roles: Client SHOULD, Server MUST.
7. References 7. References
7.1. Normative References 7.1. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[DNS] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[IDNA2003] [IDNA2003]
Faltstrom, P., Hoffman, P., and A. Costello, Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
See Section 1 for an explanation of why the normative See Section 1 for an explanation of why the normative
reference to an obsoleted specification is needed. reference to an obsoleted specification is needed.
[KEYWORDS] [KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 16, line 26 skipping to change at page 16, line 44
(http://www.unicode.org/reports/tr28/). (http://www.unicode.org/reports/tr28/).
[UNICODE-SEC] [UNICODE-SEC]
The Unicode Consortium, "Unicode Technical Report #36: The Unicode Consortium, "Unicode Technical Report #36:
Unicode Security Considerations", 2008. Unicode Security Considerations", 2008.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[XMPP] Saint-Andre, P., "Extensible Messaging and Presence [XMPP] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-19 (work Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-20 (work
in progress), November 2010. in progress), December 2010.
7.2. Informative References 7.2. Informative References
[DNS] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[IDNA-DEFS] [IDNA-DEFS]
Klensin, J., "Internationalized Domain Names for Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[IDNA-PROTO] [IDNA-PROTO]
skipping to change at page 17, line 27 skipping to change at page 17, line 41
for Internationalized Domain Names in Applications for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, March 2003. (IDNA)", RFC 3492, March 2003.
[REPORTS] Dusseault, L. and R. Sparks, "Guidance on Interoperation [REPORTS] Dusseault, L. and R. Sparks, "Guidance on Interoperation
and Implementation Reports for Advancement to Draft and Implementation Reports for Advancement to Draft
Standard", BCP 9, RFC 5657, September 2009. Standard", BCP 9, RFC 5657, September 2009.
[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.
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[XEP-0029] [XEP-0029]
Kaes, C., "Definition of Jabber Identifiers (JIDs)", XSF Kaes, C., "Definition of Jabber Identifiers (JIDs)", XSF
XEP 0029, October 2003. XEP 0029, October 2003.
[XEP-0030] [XEP-0030]
Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-
skipping to change at page 22, line 6 skipping to change at page 22, line 27
This profile specifies checking bidirectional strings, as described This profile specifies checking bidirectional strings, as described
in Section 6 of [STRINGPREP]. in Section 6 of [STRINGPREP].
Appendix C. Differences From RFC 3920 Appendix C. Differences From RFC 3920
Based on consensus derived from implementation and deployment Based on consensus derived from implementation and deployment
experience as well as formal interoperability testing, the following experience as well as formal interoperability testing, the following
substantive modifications were made from RFC 3920. substantive modifications were made from RFC 3920.
o Corrected the ABNF syntax to (1) ensure consistency with [URI] and o Corrected the ABNF syntax to ensure consistency with [URI] and
[IRI], and (2) prevent zero-length localparts, domainparts, and [IRI], including consistency with RFC 3986 and RFC 5952 with
resourceparts. regard to IPv6 addresses (e.g., enclosing the IPv6 address in
square brackets '[' and ']').
o Corrected the ABNF syntax to prevent zero-length localparts,
domainparts, and resourceparts (and also noted that the underlying
length limits from the DNS apply to domainparts).
o To avoid confusion with the term "node" as used in [XEP-0030] and o To avoid confusion with the term "node" as used in [XEP-0030] and
[XEP-0060], changed the term "node identifier" to "localpart" (but [XEP-0060], changed the term "node identifier" to "localpart" (but
retained the name "Nodeprep" for backward compatibility). retained the name "Nodeprep" for backward compatibility).
o To avoid confusion with the terms "resource" and "identifier" as o To avoid confusion with the terms "resource" and "identifier" as
used in [URI], changed the term "resource identifier" to used in [URI], changed the term "resource identifier" to
"resourcepart". "resourcepart".
o Corrected the nameprep processing rules to require use of the o Corrected the nameprep processing rules to require use of the
UseSTD3ASCIIRules flag. UseSTD3ASCIIRules flag.
Appendix D. Acknowledgements
Thanks to Ben Campbell, Waqas Hussain, Jehan Pages and Florian Zeitz
for their feedback. Thanks also to Richard Barnes and Elwyn Davies
for their reviews on behalf of the Security Directorate and the
General Area Review Team, respectively.
The Working Group chairs were Ben Campbell and Joe Hildebrand. The
responsible Area Director was Gonzalo Camarillo.
Some text in this document was borrowed or adapted from [IDNA-DEFS],
[IDNA-PROTO], [IDNA-RATIONALE], and [XEP-0165].
Author's Address Author's Address
Peter Saint-Andre Peter Saint-Andre
Cisco Cisco
1899 Wyknoop Street, Suite 600 1899 Wyknoop Street, Suite 600
Denver, CO 80202 Denver, CO 80202
USA USA
Phone: +1-303-308-3282 Phone: +1-303-308-3282
Email: psaintan@cisco.com Email: psaintan@cisco.com
 End of changes. 45 change blocks. 
85 lines changed or deleted 110 lines changed or added

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