draft-ietf-xmpp-address-01.txt   draft-ietf-xmpp-address-02.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track July 7, 2010 Intended status: Standards Track July 12, 2010
Expires: January 8, 2011 Expires: January 13, 2011
Extensible Messaging and Presence Protocol (XMPP): Address Format Extensible Messaging and Presence Protocol (XMPP): Address Format
draft-ietf-xmpp-address-01 draft-ietf-xmpp-address-02
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.
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
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 January 8, 2011. This Internet-Draft will expire on January 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 3, line 10 skipping to change at page 3, line 10
B.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 19 B.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 19
Appendix C. Differences From RFC 3920 . . . . . . . . . . . . . . 19 Appendix C. Differences From RFC 3920 . . . . . . . . . . . . . . 19
Appendix D. Copying Conditions . . . . . . . . . . . . . . . . . 19 Appendix D. Copying Conditions . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
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 such 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,
(thus for historical reasons the native address of an XMPP entity is first described by [XEP-0029] in 2002, and defined canonically by
called a Jabber Identifier or JID). In essence, a JID contains up to [RFC3920] in 2004.
three parts, in the arrangement <localpart@domainpart/resourcepart>
(where the localpart and resourcepart are both discretionary and each As specified in RFC 3920, the XMPP address format re-uses the
part can contain nearly any Unicode code point [UNICODE], encoded
according to [UTF-8]). The JID format was first described by
[XEP-0029] in 2002, then defined canonically by [RFC3920] in 2004.
As defined in RFC 3920, the XMPP address format re-uses the
"stringprep" technology for preparation of non-ASCII characters "stringprep" technology for preparation of non-ASCII characters
[STRINGPREP], including the Nameprep profile for internationalized [STRINGPREP], including the Nameprep profile for internationalized
domain names as specified in [NAMEPREP] and [IDNA2003] along with two domain names as specified in [NAMEPREP] and [IDNA2003] along with two
XMPP-specific profiles for the localpart and resourcepart. Since the XMPP-specific profiles for the localpart and resourcepart. However,
publication of RFC 3920, IDNA2003 has been superseded by IDNA2008 since the publication of RFC 3920, IDNA2003 has been superseded by
(see [IDNA-PROTO] and related documents). As a result, other IDNA2008 (see [IDNA-PROTO] and related documents). As a result,
protocols that use stringprep (including XMPP) have begun to migrate other protocols that use stringprep (including XMPP) have begun to
from stringprep toward more "modern" approaches. Because work on migrate from stringprep toward more "modern" approaches.
improved handling of internationalized addresses is currently in
progress, specifying the XMPP address format in the specification Because work on improved handling of internationalized addresses is
that obsoletes RFC 3920 would unacceptably delay the revision currently in progress, specifying the XMPP address format in the
process. Therefore, this specification provides updated specification that obsoletes RFC 3920 would unacceptably delay the
revision process. Therefore, this specification provides updated
documentation of the XMPP address format (essentially copied from RFC documentation of the XMPP address format (essentially copied from RFC
3920), with the intent that it can be superseded once work on a new 3920), with the intent that it can be superseded once work on a new
approach to internationalization is complete. approach to internationalization is complete.
2. Addresses 2. Addresses
2.1. Overview 2.1. Overview
An 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
contains a set of ordered elements formed of an XMPP localpart, is a string of [UNICODE] code points, encoded using [UTF-8], and
domainpart, and resourcepart. structured as an ordered sequence of localpart, domainpart, and
resourcepart (where the first two parts are demarcated by the '@'
character used as a separator, and the last two parts are similarly
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
skipping to change at page 4, line 42 skipping to change at page 4, line 42
service) and a specific occupant of such a room could be addressed as service) and a specific occupant of such a room could be addressed as
<room@service/nick> (where "nick" is the occupant's room nickname). <room@service/nick> (where "nick" is the occupant's room nickname).
Many other JID types are possible (e.g., <domain/resource> could be a Many other JID types are possible (e.g., <domain/resource> could be a
server-side script or service). 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.
Although the format of a JID is roughly consistent with [URI], an An entity's address on an XMPP network MUST be represented as a JID
entity's address on an XMPP network MUST be represented as a JID
(without a URI scheme) and not a [URI] or [IRI] as specified in (without a URI scheme) and not a [URI] or [IRI] as specified in
[XMPP-URI]; the latter specification is provided only for [XMPP-URI]; the latter specification is provided only for
identification and interaction outside the context of the XMPP wire identification and interaction outside the context of XMPP itself.
protocol itself.
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
skipping to change at page 7, line 45 skipping to change at page 7, line 41
o The '@' character is allowed in the resourcepart, and is often o The '@' character is allowed in the resourcepart, and is often
used in the "nick" shown in XMPP chatrooms. For example, the JID used in the "nick" shown in XMPP chatrooms. For example, the JID
<room@chat.example.com/user@host> describes an entity who is an <room@chat.example.com/user@host> describes an entity who is an
occupant of the room <room@chat.example.com> with an (asserted) occupant of the room <room@chat.example.com> with an (asserted)
nick of <user@host>. However, chatroom services do not nick of <user@host>. However, chatroom services do not
necessarily check such an asserted nick against the occupant's necessarily check such an asserted nick against the occupant's
real JID. real JID.
3. Internationalization Considerations 3. Internationalization Considerations
An XMPP server MUST support and enforce [IDNA2003] for domainparts, XMPP servers MUST, and XMPP clients SHOULD, support [IDNA2003] for
the Nodeprep (Appendix A) profile of [STRINGPREP] for localparts, and domainparts (including the [NAMEPREP] profile of [STRINGPREP]), the
the Resourceprep (Appendix B) profile of [STRINGPREP] for Nodeprep (Appendix A) profile of [STRINGPREP] for localparts, and the
resourceparts; this enables XMPP addresses to include a wide variety Resourceprep (Appendix B) profile of [STRINGPREP] for resourceparts;
of characters outside the US-ASCII range. this enables XMPP addresses to include a wide variety of characters
outside the US-ASCII range. Rules for enforcement of the XMPP
address format are provided in [XMPP].
4. Security Considerations 4. Security Considerations
4.1. Reuse of Stringprep 4.1. Reuse of Stringprep
The security considerations described in [STRINGPREP] apply to the The security considerations described in [STRINGPREP] apply to the
Nodeprep (Appendix A) and Resourceprep (Appendix B) profiles defined Nodeprep (Appendix A) and Resourceprep (Appendix B) profiles defined
in this document for XMPP localparts and resourceparts. The security in this document for XMPP localparts and resourceparts. The security
considerations described in [STRINGPREP] and [NAMEPREP] apply to the considerations described in [STRINGPREP] and [NAMEPREP] apply to the
Nameprep profile that is re-used here for XMPP domainparts. Nameprep profile that is re-used here for XMPP domainparts.
skipping to change at page 9, line 5 skipping to change at page 9, line 5
XMPP. One common usage is as the name for an instant messaging 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 a 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 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 of services could be compromised based on different interpretations of
the internationalized resourcepart; for example, a user could attempt the internationalized resourcepart; for example, a user could attempt
to initiate multiple connections with the same name, or a user could to initiate multiple connections with the same name, or a user could
send a message to someone other than the intended recipient in a send a message to someone other than the intended recipient in a
multi-user chat room. multi-user chat room.
Further discussion is provided under Section 4.4.2.
4.4. Address Spoofing 4.4. Address Spoofing
There are two forms of address spoofing: forging and mimicking. There are two forms of address spoofing: forging and mimicking.
4.4.1. Address Forging 4.4.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
skipping to change at page 9, line 39 skipping to change at page 9, line 37
can authenticate only the domainpart of such JIDs with any level of can authenticate only the domainpart of such JIDs with any level of
assurance. This specification does not define methods for assurance. This specification does not define methods for
discovering or counteracting such rogue servers. discovering or counteracting such rogue servers.
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
[DNSSEC] are not used. [DNSSEC] are not used.
4.4.2. Address Mimicking 4.4.2. Address Mimicking
Address mimicking occus when an entity provides legitimate Address mimicking occurs when an entity provides legitimate
authentication credentials for and sends XML stanzas from an account authentication credentials for and sends XML stanzas from an account
whose JID appears to a human user to be the same as another JID. For whose JID appears to a human user to be the same as another JID. For
example, in some XMPP clients the address "paypa1@example.org" example, in some XMPP clients the address "paypa1@example.org"
(spelled with the number one as the final character of the localpart) (spelled with the number one as the final character of the localpart)
might appear to be the same as "paypal@example.org (spelled with the might appear to be the same as "paypal@example.org (spelled with the
lower-case version of the letter "L"), especially on casual visual lower-case version of the letter "L"), especially on casual visual
inspection; this phenomenon is sometimes called "typejacking". A inspection; this phenomenon is sometimes called "typejacking". A
more sophisticated example of address mimicking might involve the use more sophisticated example of address mimicking might involve the use
of characters from outside the US-ASCII range, such as the Cherokee of characters from outside the US-ASCII range, such as the Cherokee
characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 instead characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 instead
skipping to change at page 14, line 6 skipping to change at page 14, line 6
(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-09 (work Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-10 (work
in progress), June 2010. in progress), July 2010.
7.2. Informative References 7.2. Informative References
[DNS] Mockapetris, P., "Domain names - implementation and [DNS] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. 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.
 End of changes. 13 change blocks. 
41 lines changed or deleted 39 lines changed or added

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