idnits 2.17.1 draft-ietf-xmpp-6122bis-22.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 11, 2015) is 3273 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-precis-saslprepbis-16 -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTR36' == Outdated reference: A later version (-19) exists of draft-ietf-precis-nickname-17 -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) -- Obsolete informational reference (is this intentional?): RFC 4013 (Obsoleted by RFC 7613) -- Obsolete informational reference (is this intentional?): RFC 6122 (Obsoleted by RFC 7622) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XMPP P. Saint-Andre 3 Internet-Draft &yet 4 Obsoletes: 6122 (if approved) May 11, 2015 5 Intended status: Standards Track 6 Expires: November 12, 2015 8 Extensible Messaging and Presence Protocol (XMPP): Address Format 9 draft-ietf-xmpp-6122bis-22 11 Abstract 13 This document defines the address format for the Extensible Messaging 14 and Presence Protocol (XMPP), including support for code points 15 outside the ASCII range. This document obsoletes RFC 6122. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on November 12, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. Domainpart . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 6 57 3.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 6 58 3.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 7 59 3.3. Localpart . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3.3.1. Further Excluded Characters . . . . . . . . . . . . . 7 61 3.4. Resourcepart . . . . . . . . . . . . . . . . . . . . . . 8 62 3.4.1. Applicability to XMPP Extensions . . . . . . . . . . 9 63 3.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4. Enforcement in JIDs and JID Parts . . . . . . . . . . . . . . 13 65 5. Internationalization Considerations . . . . . . . . . . . . . 15 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 6.1. Stringprep Profiles Registry . . . . . . . . . . . . . . 15 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 69 7.1. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 16 70 7.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 16 71 7.3. Address Spoofing . . . . . . . . . . . . . . . . . . . . 16 72 7.3.1. Address Forging . . . . . . . . . . . . . . . . . . . 16 73 7.3.2. Address Mimicking . . . . . . . . . . . . . . . . . . 17 74 8. Conformance Requirements . . . . . . . . . . . . . . . . . . 18 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 77 9.2. Informative References . . . . . . . . . . . . . . . . . 21 78 Appendix A. Differences from RFC 6122 . . . . . . . . . . . . . 24 79 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 25 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 82 1. Introduction 84 The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] is an 85 application profile of the Extensible Markup Language [XML] for 86 streaming XML data in close to real time between any two or more 87 network-aware entities. The address format for XMPP entities was 88 originally developed in the Jabber open-source community in 1999, 89 first described by [XEP-0029] in 2002, and then defined canonically 90 by [RFC3920] in 2004 and [RFC6122] in 2011. 92 As specified in RFC 3920 and RFC 6122, the XMPP address format used 93 the "stringprep" technology for preparation and comparison of non- 94 ASCII characters [RFC3454]. Following the migration of 95 internationalized domain names away from stringprep, this document 96 defines the XMPP address format in a way that no longer depends on 97 stringprep (see the PRECIS problem statement [RFC6885]). Instead, 98 this document builds upon the internationalization framework defined 99 by the IETF's PRECIS Working Group [I-D.ietf-precis-framework]. 101 Although every attempt has been made to ensure that the characters 102 allowed in Jabber Identifiers (JIDs) under Stringprep are still 103 allowed and handled in the same way under PRECIS, there is no 104 guarantee of strict backward compatibility because of changes in 105 Unicode and the fact that PRECIS handling is based on Unicode 106 properties, not a hardcoded table of characters. Because it is 107 possible that previously-valid JIDs might no longer be valid (or 108 previously-invalid JIDs might now be valid), operators of XMPP 109 services are advised to perform careful testing before migrating 110 accounts and other data. 112 This document obsoletes RFC 6122. 114 2. Terminology 116 Many important terms used in this document are defined in 117 [I-D.ietf-precis-framework], [RFC5890], [RFC6120], [RFC6365], and 118 [Unicode]. 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in 123 [RFC2119]. 125 3. Addresses 127 3.1. Fundamentals 129 An XMPP entity is anything that can communicate using XMPP. For 130 historical reasons, the network address of an XMPP entity is called a 131 Jabber Identifier ("JID"). A valid JID is a string of Unicode code 132 points [Unicode], encoded using UTF-8 [RFC3629], and structured as an 133 ordered sequence of localpart, domainpart, and resourcepart, where 134 the first two parts are demarcated by the '@' character used as a 135 separator and the last two parts are similarly demarcated by the '/' 136 character (e.g., ). 138 The syntax for a JID is defined as follows using the Augmented 139 Backus-Naur Form (ABNF) as specified in [RFC5234]. 141 jid = [ localpart "@" ] domainpart [ "/" resourcepart ] 142 localpart = 1*1023(userbyte) 143 ; 144 ; a "userbyte" is a byte used to represent a 145 ; UTF-8 encoded Unicode code point that can be 146 ; contained in a string that conforms to the 147 ; "UsernameCaseMapped" profile of the PRECIS 148 ; IdentifierClass 149 ; 150 domainpart = IP-literal / IPv4address / ifqdn 151 ; 152 ; the "IPv4address" and "IP-literal" rules are 153 ; defined in RFC 3986, and the first-match-wins 154 ; (a.k.a. "greedy") algorithm described therein 155 ; applies to the matching process 156 ; 157 ; note well that reuse of the IP-literal rule from 158 ; RFC 3986 implies that IPv6 addresses are enclosed 159 ; in square brackets (i.e., beginning with '[' and 160 ; ending with ']') 161 ; 162 ifqdn = 1*1023(domainbyte) 163 ; 164 ; a "domainbyte" is a byte used to represent a 165 ; UTF-8 encoded Unicode code point that can be 166 ; contained in a string that conforms to RFC 5890 167 ; 168 resourcepart = 1*1023(opaquebyte) 169 ; 170 ; an "opaquebyte" is a byte used to represent a 171 ; UTF-8 encoded Unicode code point that can be 172 ; contained in a string that conforms to the 173 ; "OpaqueString" profile of the PRECIS 174 ; FreeformClass 175 ; 177 All JIDs are based on the foregoing structure. However, note that 178 the formal syntax provided above does not capture all of the rules 179 and restrictions that apply to JIDs, which are described below. 181 Each allowable portion of a JID (localpart, domainpart, and 182 resourcepart) MUST NOT be zero octets in length and MUST NOT be more 183 than 1023 octets in length, resulting in a maximum total size 184 (including the '@' and '/' separators) of 3071 octets. 186 Implementation Note: The length limits on JIDs and parts of JIDs 187 are based on octets (bytes), not characters. UTF-8 encoding can 188 result in more than one octet per character. 190 Implementation Note: When dividing a JID into its component parts, 191 an implementation needs to match the separator characters '@' and 192 '/' before applying any transformation algorithms, which might 193 decompose certain Unicode code points to the separator characters. 195 This document defines the native format for JIDs; see [RFC5122] for 196 information about the representation of a JID as a Uniform Resource 197 Identifier (URI) [RFC3986] or Internationalized Resource Identifier 198 (IRI) [RFC3987] and the extraction of a JID from an XMPP URI or IRI. 200 3.2. Domainpart 202 The domainpart of a JID is that portion which remains once any 203 portion from the first '/' character to the end of the string has 204 been removed (if there is a '/' character present), and then any 205 portion from the beginning of the string to the first '@' character 206 (if there is a '@' character present). The domainpart is the primary 207 identifier and is the only REQUIRED element of a JID (a mere 208 domainpart is a valid JID). Typically a domainpart identifies the 209 "home" server to which clients connect for XML routing and data 210 management functionality. However, it is not necessary for an XMPP 211 domainpart to identify an entity that provides core XMPP server 212 functionality (e.g., a domainpart can identify an entity such as a 213 multi-user chat service [XEP-0045], a publish-subscribe service 214 [XEP-0060], or a user directory). 216 The domainpart for every XMPP service MUST be a fully-qualified 217 domain name (FQDN), an IPv4 address, an IPv6 address, or an 218 unqualified hostname (i.e., a text label that is resolvable on a 219 local network). 221 Informational Note: The term "fully-qualified domain name" is not 222 well defined. In [RFC1034] it is also called an absolute domain 223 name, and the two terms are associated in [RFC1535]. The earliest 224 use of the term can be found in [RFC1123]. References to those 225 older specifications ought not to be construed as limiting the 226 characters of a fully-qualified domain name to the ASCII range; 227 for example, [RFC5890] mentions that a fully-qualified domain name 228 can contain one or more U-labels. 230 Interoperability Note: Domainparts that are IP addresses might not 231 be accepted by other services for the purpose of server-to-server 232 communication, and domainparts that are unqualified hostnames 233 cannot be used on public networks because they are resolvable only 234 on a local network. 236 If the domainpart includes a final character considered to be a label 237 separator (dot) by [RFC1034], this character MUST be stripped from 238 the domainpart before the JID of which it is a part is used for the 239 purpose of routing an XML stanza, comparing against another JID, or 240 constructing an XMPP URI or IRI [RFC5122]. In particular, such a 241 character MUST be stripped before any other canonicalization steps 242 are taken. 244 In general, the content of a domainpart is an Internationalized 245 Domain Name ("IDN") as described in the specifications for 246 Internationalized Domain Names in Applications (commonly called 247 "IDNA2008"), and a domainpart is an "IDNA-aware domain name slot" as 248 defined in [RFC5890]. 250 After any and all normalization, conversion, and mapping of code 251 points as well as encoding of the string as UTF-8, a domainpart MUST 252 NOT be zero octets in length and MUST NOT be more than 1023 octets in 253 length. (Naturally, the length limits of [RFC1034] apply, and 254 nothing in this document is to be interpreted as overriding those 255 more fundamental limits.) 257 Detailed rules and considerations for preparation, enforcement, and 258 comparison are provided in the following sections. 260 3.2.1. Preparation 262 An entity that prepares a string for inclusion in an XMPP domainpart 263 slot MUST ensure that the string consists only of Unicode code points 264 that are allowed in NR-LDH labels or U-labels as defined in 265 [RFC5890]. This implies that the string MUST NOT include A-labels as 266 defined in [RFC5890]; each A-label MUST be converted to a U-label 267 during preparation of a string for inclusion in a domainpart slot. 268 In addition, the string MUST be encoded as UTF-8 [RFC3629]. 270 3.2.2. Enforcement 272 An entity that performs enforcement in XMPP domainpart slots MUST 273 prepare a string as described in the previous section and MUST also 274 apply the normalization, case-mapping, and width-mapping rules 275 defined in [RFC5892]. 277 The order in which the rules are applied for IDNA2008 (see 278 [RFC5892] and [RFC5895]) is different from the order for 279 localparts and resourceparts as described under Section 3.3 and 280 Section 3.4. 282 3.2.3. Comparison 284 An entity that performs comparison of two strings before or after 285 their inclusion in XMPP domainpart slots MUST prepare each string and 286 enforce the normalization, case-mapping, and width-mapping rules 287 specified in the previous two sections. The two strings are to be 288 considered equivalent if they are an exact octet-for-octet match 289 (sometimes called "bit-string identity"). 291 3.3. Localpart 293 The localpart of a JID is an optional identifier placed before the 294 domainpart and separated from the latter by the '@' character. 295 Typically a localpart uniquely identifies the entity requesting and 296 using network access provided by a server (i.e., a local account), 297 although it can also represent other kinds of entities (e.g., a chat 298 room associated with a multi-user chat service [XEP-0045]). The 299 entity represented by an XMPP localpart is addressed within the 300 context of a specific domain (i.e., ). 302 The localpart of a JID MUST NOT be zero octets in length and MUST NOT 303 be more than 1023 octets in length. This rule is to be enforced 304 after any normalization and mapping of code points as well as 305 encoding of the string as UTF-8. 307 The localpart of a JID is an instance of the UsernameCaseMapped 308 profile of the PRECIS IdentifierClass, which is specified in 309 [I-D.ietf-precis-saslprepbis]. The rules and considerations provided 310 in that specification MUST be applied to XMPP localparts. 312 Implementation Note: XMPP uses the Simple Authentication and 313 Security Layer (SASL) [RFC4422] for authentication. At the time 314 of this writing, some SASL mechanisms use SASLprep [RFC4013] for 315 handling of usernames and passwords; in the future these SASL 316 mechanisms will likely transition to the use of PRECIS-based 317 handling rules as specified in [I-D.ietf-precis-saslprepbis]. For 318 a detailed discussion about the implications of that transition 319 (including the potential need to modify or remove certain 320 characters in the underlying account database), see both 321 Section 6.1 and Appendix A of [I-D.ietf-precis-saslprepbis]. 323 3.3.1. Further Excluded Characters 325 In XMPP, the following characters are explicitly disallowed in XMPP 326 localparts even though they are allowed by the IdentifierClass base 327 class and the UsernameCaseMapped profile: 329 U+0022 (QUOTATION MARK), i.e., " 330 U+0026 (AMPERSAND), i.e., & 332 U+0027 (APOSTROPHE), i.e., ' 334 U+002F (SOLIDUS), i.e., / 336 U+003A (COLON), i.e., : 338 U+003C (LESS-THAN SIGN), i.e., < 340 U+003E (GREATER-THAN SIGN), i.e., > 342 U+0040 (COMMERCIAL AT), i.e., @ 344 Implementation Note: An XMPP-specific method for escaping the 345 foregoing characters (along with U+0020, i.e., ASCII SPACE) has 346 been defined in the JID Escaping specification [XEP-0106]. 348 3.4. Resourcepart 350 The resourcepart of a JID is an optional identifier placed after the 351 domainpart and separated from the latter by the '/' character. A 352 resourcepart can modify either a address or a 353 mere address. Typically a resourcepart uniquely 354 identifies a specific connection (e.g., a device or location) or 355 object (e.g., an occupant in a multi-user chat room [XEP-0045]) 356 belonging to the entity associated with an XMPP localpart at a domain 357 (i.e., ). 359 XMPP entities SHOULD consider resourceparts to be opaque strings and 360 SHOULD NOT impute meaning to any given resourcepart. In particular: 362 o Use of the '/' character as a separator between the domainpart and 363 the resourcepart does not imply that XMPP addresses are 364 hierarchical in the way that, say, HTTP URIs are hierarchical (see 365 [RFC3986] for general discussion); thus for example an XMPP 366 address of the form does not 367 identify a resource "bar" that exists below a resource "foo" in a 368 hierarchy of resources associated with the entity 369 "localpart@domainpart". 371 o The '@' character is allowed in the resourcepart and is often used 372 in the "handle" shown in XMPP chatrooms [XEP-0045]. For example, 373 the JID describes an entity who 374 is an occupant of the room with a handle 375 of . However, chatroom services do not necessarily 376 check such an asserted handle against the occupant's real JID. 378 The resourcepart of a JID MUST NOT be zero octets in length and MUST 379 NOT be more than 1023 octets in length. This rule is to be enforced 380 after any normalization and mapping of code points as well as 381 encoding of the string as UTF-8. 383 The resourcepart of a JID is an instance of the OpaqueString profile 384 of the PRECIS FreeformClass, which is specified in 385 [I-D.ietf-precis-saslprepbis]. The rules and considerations provided 386 in that specification MUST be applied to XMPP resourceparts. 388 3.4.1. Applicability to XMPP Extensions 390 In some contexts, it might be appropriate to apply more restrictive 391 rules to the preparation, enforcement, and comparison of XMPP 392 resourceparts. For example, in XMPP Multi-User Chat [XEP-0045] it 393 might be appropriate to apply the rules specified in 394 [I-D.ietf-precis-nickname]. However, the application of more 395 restrictive rules is out of scope for resourceparts in general and is 396 properly defined in specifications for the relevant XMPP extensions. 398 3.5. Examples 400 The following examples illustrate a small number of JIDs that are 401 consistent with the format defined above (note that the characters < 402 and > are used to delineate the actual JIDs and are not part of the 403 JIDs themselves). 405 Table 1: A sample of legal JIDs 407 +----------------------------------+-------------------------------+ 408 | # | JID | Notes | 409 +----------------------------------+-------------------------------+ 410 | 1 | | A "bare JID" | 411 +----------------------------------+-------------------------------+ 412 | 2 | | A "full JID" | 413 +----------------------------------+-------------------------------+ 414 | 3 | | Single space in resourcepart | 415 +----------------------------------+-------------------------------+ 416 | 4 | | At sign in resourcepart | 417 +----------------------------------+-------------------------------+ 418 | 5 | | Single space in localpart, as | 419 | | | optionally escaped using the | 420 | | | XMPP "JID Escaping" extension | 421 +----------------------------------+-------------------------------+ 422 | 6 | | Another bare JID | 423 +----------------------------------+-------------------------------+ 424 | 7 | | The third character is LATIN | 425 | | | SMALL LETTER SHARP S (U+00DF) | 426 +----------------------------------+-------------------------------+ 427 | 8 | <π@example.com> | A localpart of GREEK SMALL | 428 | | | LETTER PI (U+03C0) | 429 +----------------------------------+-------------------------------+ 430 | 9 | <Σ@example.com/foo> | A localpart of GREEK CAPITAL | 431 | | | LETTER SIGMA (U+03A3) | 432 +----------------------------------+-------------------------------+ 433 | 10| <σ@example.com/foo> | A localpart of GREEK SMALL | 434 | | | LETTER SIGMA (U+03C3) | 435 +----------------------------------+-------------------------------+ 436 | 11| <ς@example.com/foo> | A localpart of GREEK SMALL | 437 | | | LETTER FINAL SIGMA (U+03C2) | 438 +----------------------------------+-------------------------------+ 439 | 12| ; | A resourcepart of the Unicode | 440 | | | character BLACK CHESS KING | 441 | | | (U+265A) | 442 +----------------------------------+-------------------------------+ 443 | 13| | A domainpart | 444 +----------------------------------+-------------------------------+ 445 | 14| | A domainpart and resourcepart | 446 +----------------------------------+-------------------------------+ 447 | 15| | A domainpart followed by a | 448 | | | resourcepart that contains an | 449 | | | at sign | 450 +----------------------------------+-------------------------------+ 451 Several points are worth noting. Regarding examples 6 and 7: 452 although in German the character esszett (LATIN SMALL LETTER SHARP S, 453 U+00DF) can mostly be used interchangeably with the two characters 454 "ss", the localparts in these examples are different and (if desired) 455 a server would need to enforce a registration policy that disallows 456 one of them if the other is registered. Regarding examples 9, 10, 457 and 11: case-mapping of GREEK CAPITAL LETTER SIGMA (U+03A3) to 458 lowercase (i.e., to GREEK SMALL LETTER SIGMA, U+03C3) during 459 comparison would result in matching the JIDs in examples 9 and 10; 460 however, because the PRECIS mapping rules do not account for the 461 special status of GREEK SMALL LETTER FINAL SIGMA (U+03C2), the JIDs 462 in examples 9 and 11 or examples 10 and 11 would not be matched. 463 Regarding example 12: symbol characters such as BLACK CHESS KING 464 (U+265A) are allowed by the PRECIS FreeformClass and thus can be used 465 in resourceparts. Regarding examples 14 and 15: JIDs consisting of a 466 domainpart and resourcepart are rarely seen in the wild, but are 467 allowed according to the XMPP address format. Example 15 illustrates 468 the need for careful extraction of the domainpart as described in the 469 first paragraph of Section 3.2. 471 The following examples illustrate strings that are not JIDs because 472 they violate the format defined above. 474 Table 2: A sample of strings that violate the JID rules 476 +----------------------------------+-------------------------------+ 477 | # | Non-JID string | Notes | 478 +----------------------------------+-------------------------------+ 479 | 16| <"juliet"@example.com> | Quotation marks (U+0022) in | 480 | | | localpart | 481 +----------------------------------+-------------------------------+ 482 | 17| | Space (U+0020) in localpart | 483 +----------------------------------+-------------------------------+ 484 | 18| | Leading space in resourcepart | 485 +----------------------------------+-------------------------------+ 486 | 19| <@example.com/> | Zero-length localpart and | 487 | | | resourcepart | 488 +----------------------------------+-------------------------------+ 489 | 20| | The sixth character is ROMAN | 490 | | | NUMERAL FOUR (U+2163) | 491 +----------------------------------+-------------------------------+ 492 | 21| <♚@example.com> | A localpart of BLACK CHESS | 493 | | | KING (U+265A) | 494 +----------------------------------+-------------------------------+ 495 | 22| | A localpart without a | 496 | | | domainpart | 497 +----------------------------------+-------------------------------+ 498 | 23| | A resourcepart without a | 499 | | | domainpart | 500 +----------------------------------+-------------------------------+ 502 Here again, several points are worth noting. Regarding example 17, 503 even though ASCII SPACE (U+0020) is disallowed in the PRECIS 504 IdentifierClass, it can be escaped to "\20" in XMPP localparts by 505 using the JID Escaping rules defined in [XEP-0106], as illustrated by 506 example 4 in Table 1. Regarding example 20, the Unicode character 507 ROMAN NUMERAL FOUR (U+2163) has a compatibility equivalent of the 508 string formed of LATIN CAPITAL LETTER I (U+0049) and LATIN CAPITAL 509 LETTER V (U+0056), but characters with compatibility equivalents are 510 not allowed in the PRECIS IdentiferClass. Regarding example 21: 511 symbol characters such as BLACK CHESS KING (U+265A) are not allowed 512 in the PRECIS IdentifierClass; however, both of the non-ASCII 513 characters in examples 20 and 21 are allowed in the PRECIS Freeform 514 class and therefore in the XMPP resourcepart (as illustrated for 515 U+265A by example 12 in Table 1). Regarding examples 22 and 23: the 516 domainpart is required in a JID. 518 4. Enforcement in JIDs and JID Parts 520 Enforcement entails applying all of the rules specified in this 521 document. Enforcement of the XMPP address format rules is the 522 responsibility of XMPP servers. Although XMPP clients SHOULD prepare 523 complete JIDs and parts of JIDs in accordance with this document 524 before including them in protocol slots within XML streams, XMPP 525 servers MUST enforce the rules wherever possible and reject stanzas 526 and other XML elements that violate the rules (for stanzas, by 527 returning a error to the sender as described in 528 Section 8.3.3.8 of [RFC6120]). 530 Entities that enforce the rules specified in this document are 531 encouraged to be liberal in what they accept by following this 532 procedure: 534 1. Where possible, map characters (e.g, through width mapping, 535 additional mapping, special mapping, case mapping, or 536 normalization) and accept the mapped string. 538 2. If mapping is not possible (e.g., because a character is 539 disallowed in the FreeformClass), reject the string and return a 540 error. 542 Enforcement applies to complete JIDs and to parts of JIDs. To 543 facilitate implementation, this document defines the concepts of "JID 544 slot", "localpart slot", and "resourcepart slot" (similar to the 545 concept of a "domain name slot" for IDNA2008 defined in 546 Section 2.3.2.6 of [RFC5890]): 548 JID Slot: An XML element or attribute explicitly designated in XMPP 549 or in XMPP extensions for carrying a complete JID. 551 Localpart Slot: An XML element or attribute explicitly designated in 552 XMPP or in XMPP extensions for carrying the localpart of a JID. 554 Resourcepart Slot: An XML element or attribute explicitly designated 555 in XMPP or in XMPP extensions for carrying the resourcepart of a 556 JID. 558 A server is responsible for enforcing the address format rules when 559 receiving protocol elements from clients where the server is expected 560 to handle such elements directly or to use them for purposes of 561 routing a stanza to another domain or delivering a stanza to a local 562 entity; two examples from [RFC6120] are the 'to' attribute on XML 563 stanzas (which is a JID slot used by XMPP servers for routing of 564 outbound stanzas) and the child of the element 565 (which is a resourcepart slot used by XMPP servers for binding of a 566 resource to an account for routing of stanzas between the server and 567 a particular client). An example from [RFC6121] is the 'jid' 568 attribute of the roster element. 570 A server is not responsible for enforcing the rules when the protocol 571 elements are intended for communication among other entities, 572 typically within the payload of a stanza that the server is merely 573 routing to another domain or delivering to a local entity. Two 574 examples are the 'initiator' attribute in the Jingle extension 575 [XEP-0166] (which is a JID slot used for client-to-client 576 coordination of multimedia sessions) and the 'nick' attribute in the 577 Multi-User Chat extension [XEP-0045] (which is a resourcepart slot 578 used for administrative purposes in the context of XMPP chatrooms). 579 In such cases, the entities involved SHOULD enforce the rules 580 themselves and not depend on the server to do so, and client 581 implementers need to understand that not enforcing the rules can lead 582 to a degraded user experience or to security vulnerabilities. 583 However, when an add-on service (e.g., a multi-user chat service) 584 handles a stanza directly, it ought to enforce the rules as well, as 585 defined in the relevant specification for that type of service. 587 This document does not provide an exhaustive list of JID slots, 588 localpart slots, or resourcepart slots. However, implementers of 589 core XMPP servers are advised to consider as JID slots at least the 590 following elements and attributes when they are handled directly or 591 used for purposes of routing to another domain or delivering to a 592 local entity: 594 o The 'from' and 'to' stream attributes and the 'from' and 'to' 595 stanza attributes [RFC6120]. 597 o The 'jid' attribute of the roster element for contact list 598 management [RFC6121]. 600 o The 'value' attribute of the element for Privacy Lists 601 [RFC3921] [XEP-0016] when the value of the 'type' attribute is 602 "jid". 604 o The 'jid' attribute of the element for Service Discovery 605 defined in [XEP-0030]. 607 o The element for Data Forms [XEP-0004], when the 'type' 608 attribute is "jid-single" or "jid-multi". 610 o The 'jid' attribute of the element for Bookmark 611 Storage [XEP-0048]. 613 o The of the element for vCard 3.0 [XEP-0054] 614 and the child of the element for vCard 4.0 615 [XEP-0292] when the XML character data identifies an XMPP URI 616 [RFC5122]. 618 o The 'from' attribute of the element for Delayed Delivery 619 [XEP-0203]. 621 o The 'jid' attribute of the element for the Blocking 622 Command [XEP-0191]. 624 o The 'from' and 'to' attributes of the and 625 elements for Server Dialback [RFC3921], [XEP-0220]. 627 o The 'from' and 'to' attributes of the , , and 628 elements for the Jabber Component Protocol [XEP-0114]. 630 Developers of XMPP clients and specialized XMPP add-on services are 631 advised to check the appropriate specifications for JID slots, 632 localpart slots, and resourcepart slots in XMPP protocol extensions 633 such as Service Discovery [XEP-0030], Multi-User Chat [XEP-0045], 634 Publish-Subscribe [XEP-0060], SOCKS5 Bytestreams [XEP-0065], In-Band 635 Registration [XEP-0077], Roster Item Exchange [XEP-0144], and Jingle 636 [XEP-0166]. 638 5. Internationalization Considerations 640 XMPP applications MUST support IDNA2008 for domainparts as described 641 under Section 3.2, the "UsernameCaseMapped" profile for localparts as 642 described under Section 3.3, and the "OpaqueString" profile for 643 resourceparts as described under Section 3.4. This enables XMPP 644 addresses to include a wide variety of characters outside the ASCII 645 range. Rules for enforcement of the XMPP address format are provided 646 in [RFC6120] and specifications for various XMPP extensions. 648 Interoperability Note: For backward compatibility, many existing 649 XMPP implementations and deployments support IDNA2003 [RFC3490] 650 for domainparts, and the stringprep [RFC3454] profiles Nodeprep 651 and Resourceprep [RFC3920] for localparts and resourceparts. 653 6. IANA Considerations 655 6.1. Stringprep Profiles Registry 657 The Stringprep specification [RFC3454] did not provide for entries in 658 the Stringprep Profiles registry to be marked as anything except 659 current or not current. Because this document obsoletes RFC 6122, 660 which registered the "Nodeprep" and "Resourceprep" profiles, IANA is 661 requested at the least to mark those profiles as not current 662 (preferably with a pointer to this document). 664 7. Security Considerations 666 7.1. Reuse of PRECIS 668 The security considerations described in [I-D.ietf-precis-framework] 669 apply to the "IdentifierClass" and "FreeformClass" base string 670 classes used in this document for XMPP localparts and resourceparts, 671 respectively. The security considerations described in [RFC5890] 672 apply to internationalized domain names, which are used here for XMPP 673 domainparts. 675 7.2. Reuse of Unicode 677 The security considerations described in [UTS39] apply to the use of 678 Unicode characters in XMPP addresses. 680 7.3. Address Spoofing 682 There are two forms of address spoofing: forging and mimicking. 684 7.3.1. Address Forging 686 In the context of XMPP technologies, address forging occurs when an 687 entity is able to generate an XML stanza whose 'from' address does 688 not correspond to the account credentials with which the entity 689 authenticated onto the network (or an authorization identity provided 690 during negotiation of SASL authentication [RFC4422] as described in 691 [RFC6120]). For example, address forging occurs if an entity that 692 authenticated as "juliet@im.example.com" is able to send XML stanzas 693 from "nurse@im.example.com" or "romeo@example.net". 695 Address forging is difficult in XMPP systems, given the requirement 696 for sending servers to stamp 'from' addresses and for receiving 697 servers to verify sending domains via server-to-server authentication 698 (see [RFC6120]). However, address forging is possible if: 700 o A poorly implemented server ignores the requirement for stamping 701 the 'from' address. This would enable any entity that 702 authenticated with the server to send stanzas from any 703 localpart@domainpart as long as the domainpart matches the sending 704 domain of the server. 706 o An actively malicious server generates stanzas on behalf of any 707 registered account at the domain or domains hosted at that server. 709 Therefore, an entity outside the security perimeter of a particular 710 server cannot reliably distinguish between JIDs of the form 711 at that server and thus can authenticate only 712 the domainpart of such JIDs with any level of assurance. This 713 specification does not define methods for discovering or 714 counteracting the kind of poorly implemented or rogue servers just 715 described. However, the end-to-end authentication or signing of XMPP 716 stanzas could help to mitigate this risk, since it would require the 717 rogue server to generate false credentials for signing or encryption 718 of each stanza, in addition to modifying 'from' addresses. 720 7.3.2. Address Mimicking 722 Address mimicking occurs when an entity provides legitimate 723 authentication credentials for and sends XML stanzas from an account 724 whose JID appears to a human user to be the same as another JID. 725 Because many characters are visually similar, it is relatively easy 726 to mimic JIDs in XMPP systems. As one simple example, the localpart 727 "ju1iet" (using the Arabic numeral one as the third character) might 728 appear the same as the localpart "juliet" (using lowercase "L" as the 729 third character). 731 As explained in [RFC5890], [I-D.ietf-precis-framework], [UTR36], and 732 [UTS39], there is no straightforward solution to the problem of 733 visually similar characters. Furthermore, IDNA and PRECIS 734 technologies do not attempt to define such a solution. As a result, 735 XMPP domainparts, localparts, and resourceparts could contain such 736 characters, leading to security vulnerabilities such as the 737 following: 739 o A domainpart is always employed as one part of an entity's address 740 in XMPP. One common usage is as the address of a server or 741 server-side service, such as a multi-user chat service [XEP-0045]. 742 The security of such services could be compromised based on 743 different interpretations of the internationalized domainpart; for 744 example, a user might authorize a malicious entity at a fake 745 server to view the user's presence information, or a user could 746 join chatrooms at a fake multi-user chat service. 748 o A localpart can be employed as one part of an entity's address in 749 XMPP. One common usage is as the username of an instant messaging 750 user; another is as the name of a multi-user chat room; and many 751 other kinds of entities could use localparts as part of their 752 addresses. The security of such services could be compromised 753 based on different interpretations of the internationalized 754 localpart; for example, a user entering a single internationalized 755 localpart could access another user's account information, or a 756 user could gain access to a hidden or otherwise restricted chat 757 room or service. 759 o A resourcepart can be employed as one part of an entity's address 760 in XMPP. One common usage is as the name for an instant messaging 761 user's connected resource; another is as the nickname of a user in 762 a multi-user chat room; and many other kinds of entities could use 763 resourceparts as part of their addresses. The security of such 764 services could be compromised based on different interpretations 765 of the internationalized resourcepart; for example, two or more 766 confusable resources could be bound at the same time to the same 767 account (resulting in inconsistent authorization decisions in an 768 XMPP application that uses full JIDs), or a user could send a 769 private message to someone other than the intended recipient in a 770 multi-user chat room. 772 XMPP services and clients are strongly encouraged to define and 773 implement consistent policies regarding the registration, storage, 774 and presentation of visually similar characters in XMPP systems. In 775 particular, service providers and software implementers are strongly 776 encouraged to apply the policies recommended in 777 [I-D.ietf-precis-framework]. 779 8. Conformance Requirements 781 This section describes a protocol feature set that summarizes the 782 conformance requirements of this specification (similar feature sets 783 are provided for XMPP in [RFC6120] and [RFC6121]). The summary is 784 purely informational and the conformance keywords of [RFC2119] as 785 used here are intended only to briefly describe the referenced 786 normative text from the body of this specification. This feature set 787 is appropriate for use in software certification, interoperability 788 testing, and implementation reports. For each feature, this section 789 provides the following information: 791 o A human-readable name 793 o An informational description 795 o A reference to the particular section of this document that 796 normatively defines the feature 798 o Whether the feature applies to the Client role, the Server role, 799 or both (where "N/A" signifies that the feature is not applicable 800 to the specified role) 802 o Whether the feature MUST or SHOULD be implemented, where the 803 capitalized terms are to be understood as described in [RFC2119] 805 The feature set specified here provides a basis for interoperability 806 testing and follows the spirit of a proposal made by Larry Masinter 807 within the IETF's NEWTRK Working Group in 2005 [INTEROP]. 809 Feature: address-domain-length 811 Description: Ensure that the domainpart of an XMPP address is at 812 least one octet in length and at most 1023 octets in length, and 813 that it conforms to the underlying length limits of the DNS. 815 Section: Section 3.2 817 Roles: Server MUST, client SHOULD. 819 Feature: address-domain-prep 821 Description: Ensure that the domainpart of an XMPP address conforms 822 to IDNA2008, that it contains only NR-LDH labels and U-labels (not 823 A-labels), and that all uppercase and titlecase code points are 824 mapped to their lowercase equivalents. 826 Section: Section 3.2 828 Roles: Server MUST, client SHOULD. 830 Feature: address-localpart-length 832 Description: Ensure that the localpart of an XMPP address is at 833 least one octet in length and at most 1023 octets in length. 835 Section: Section 3.3 837 Roles: Server MUST, client SHOULD. 839 Feature: address-localpart-prep 841 Description: Ensure that the localpart of an XMPP address conforms 842 to the "UsernameCaseMapped" profile of the PRECIS IdentifierClass. 844 Section: Section 3.3 846 Roles: Server MUST, client SHOULD. 848 Feature: address-resource-length 850 Description: Ensure that the resourcepart of an XMPP address is at 851 least one octet in length and at most 1023 octets in length. 853 Section: Section 3.4 855 Roles: Server MUST, client SHOULD. 857 Feature: address-resource-prep 859 Description: Ensure that the resourcepart of an XMPP address 860 conforms to the "OpaqueString" profile of the PRECIS 861 FreeformClass. 863 Section: Section 3.4 865 Roles: Server MUST, client SHOULD. 867 9. References 869 9.1. Normative References 871 [I-D.ietf-precis-framework] 872 Saint-Andre, P. and M. Blanchet, "Precis Framework: 873 Handling Internationalized Strings in Protocols", draft- 874 ietf-precis-framework-23 (work in progress), February 875 2015. 877 [I-D.ietf-precis-saslprepbis] 878 Saint-Andre, P. and A. Melnikov, "Username and Password 879 Preparation Algorithms", draft-ietf-precis-saslprepbis-16 880 (work in progress), April 2015. 882 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 883 STD 13, RFC 1034, November 1987. 885 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 886 Requirement Levels", BCP 14, RFC 2119, March 1997. 888 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 889 10646", STD 63, RFC 3629, November 2003. 891 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 892 Specifications: ABNF", STD 68, RFC 5234, January 2008. 894 [RFC5890] Klensin, J., "Internationalized Domain Names for 895 Applications (IDNA): Definitions and Document Framework", 896 RFC 5890, August 2010. 898 [RFC5892] Faltstrom, P., "The Unicode Code Points and 899 Internationalized Domain Names for Applications (IDNA)", 900 RFC 5892, August 2010. 902 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 903 Protocol (XMPP): Core", RFC 6120, March 2011. 905 [Unicode] The Unicode Consortium, "The Unicode Standard", 906 2015-present, . 908 [UTR36] The Unicode Consortium, "Unicode Technical Report #36: 909 Unicode Security Considerations", November 2013, 910 . 912 9.2. Informative References 914 [I-D.ietf-precis-nickname] 915 Saint-Andre, P., "Preparation and Comparison of 916 Nicknames", draft-ietf-precis-nickname-17 (work in 917 progress), April 2015. 919 [INTEROP] Masinter, L., "Formalizing IETF Interoperability 920 Reporting", Work in Progress, October 2005. 922 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 923 and Support", STD 3, RFC 1123, October 1989. 925 [RFC1535] Gavron, E., "A Security Problem and Proposed Correction 926 With Widely Deployed DNS Software", RFC 1535, October 927 1993. 929 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 930 Internationalized Strings ("stringprep")", RFC 3454, 931 December 2002. 933 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 934 "Internationalizing Domain Names in Applications (IDNA)", 935 RFC 3490, March 2003. 937 See Section 1 for an explanation of why the normative 938 reference to an obsoleted specification is needed. 940 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 941 Protocol (XMPP): Core", RFC 3920, October 2004. 943 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 944 Protocol (XMPP): Instant Messaging and Presence", RFC 945 3921, October 2004. 947 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 948 Resource Identifier (URI): Generic Syntax", STD 66, RFC 949 3986, January 2005. 951 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 952 Identifiers (IRIs)", RFC 3987, January 2005. 954 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 955 and Passwords", RFC 4013, February 2005. 957 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 958 Security Layer (SASL)", RFC 4422, June 2006. 960 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 961 (IRIs) and Uniform Resource Identifiers (URIs) for the 962 Extensible Messaging and Presence Protocol (XMPP)", RFC 963 5122, February 2008. 965 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 966 Internationalized Domain Names in Applications (IDNA) 967 2008", RFC 5895, September 2010. 969 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 970 Protocol (XMPP): Instant Messaging and Presence", RFC 971 6121, March 2011. 973 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 974 Protocol (XMPP): Address Format", RFC 6122, March 2011. 976 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 977 Internationalization in the IETF", BCP 166, RFC 6365, 978 September 2011. 980 [RFC6885] Blanchet, M. and A. Sullivan, "Stringprep Revision and 981 Problem Statement for the Preparation and Comparison of 982 Internationalized Strings (PRECIS)", RFC 6885, March 2013. 984 [UTS39] The Unicode Consortium, "Unicode Technical Standard #39: 985 Unicode Security Mechanisms", July 2012, 986 . 988 [XEP-0004] 989 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and 990 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007. 992 [XEP-0016] 993 Millard, P. and P. Saint-Andre, "Privacy Lists", XSF XEP 994 0016, February 2007. 996 [XEP-0029] 997 Kaes, C., "Definition of Jabber Identifiers (JIDs)", XSF 998 XEP 0029, October 2003. 1000 [XEP-0030] 1001 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 1002 Andre, "Service Discovery", XSF XEP 0030, June 2008. 1004 [XEP-0045] 1005 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 1006 2012. 1008 [XEP-0048] 1009 Blackman, R., Millard, P., and P. Saint-Andre, 1010 "Bookmarks", XSF XEP 0048, November 2007. 1012 [XEP-0054] 1013 Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008. 1015 [XEP-0060] 1016 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 1017 Subscribe", XSF XEP 0060, July 2010. 1019 [XEP-0065] 1020 Smith, D., Miller, M., Saint-Andre, P., and J. Karneges, 1021 "SOCKS5 Bytestreams", XSF XEP 0065, April 2011. 1023 [XEP-0077] 1024 Saint-Andre, P., "In-Band Registration", XSF XEP 0077, 1025 January 2012. 1027 [XEP-0106] 1028 Hildebrand, J. and P. Saint-Andre, "JID Escaping", XSF XEP 1029 0106, June 2007. 1031 [XEP-0114] 1032 Saint-Andre, P., "Jabber Component Protocol", XSF XEP 1033 0114, March 2005. 1035 [XEP-0144] 1036 Saint-Andre, P., "Roster Item Exchange", XSF XEP 0144, 1037 August 2005. 1039 [XEP-0166] 1040 Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, 1041 S., and J. Hildebrand, "Jingle", XSF XEP 0166, December 1042 2009. 1044 [XEP-0191] 1045 Saint-Andre, P., "Blocking Command", XSF XEP 0191, July 1046 2012. 1048 [XEP-0203] 1049 Saint-Andre, P., "Delayed Delivery", XSF XEP 0203, 1050 September 2009. 1052 [XEP-0220] 1053 Miller, J., Saint-Andre, P., and P. Hancke, "Server 1054 Dialback", XSF XEP 0220, August 2012. 1056 [XEP-0292] 1057 Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP", XSF XEP 1058 0292, October 2011. 1060 [XML] Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J., 1061 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth 1062 Edition)", World Wide Web Consortium Recommendation REC- 1063 xml-20081126, November 2008, 1064 . 1066 Appendix A. Differences from RFC 6122 1068 Based on consensus derived from working group discussion, 1069 implementation and deployment experience, and formal interoperability 1070 testing, the following substantive modifications were made from RFC 1071 6122. 1073 o Changed domainpart preparation to use IDNA2008 (instead of 1074 IDNA2003). 1076 o Changed localpart preparation to use the UsernameCaseMapped 1077 profile of the PRECIS IdentifierClass (instead of the Nodeprep 1078 profile of Stringprep). 1080 o Changed resourcepart preparation to use the OpaqueString profile 1081 of the PRECIS FreeformClass (instead of the Resourceprep profile 1082 of Stringprep). 1084 o Specified that internationalized labels within domainparts must be 1085 U-labels (instead of "should be" U-labels). 1087 o Specified that fullwidth and halfwidth characters must be mapped 1088 to their decomposition mappings (previously handled through the 1089 use of NFKC). 1091 o Specified the use of Unicode Normalization Form C (instead of 1092 Unicode Normalization Form KC as specified in the Nodeprep and 1093 Resourceprep profiles of Stringprep). 1095 o Specified that servers must enforce the address formatting rules. 1097 Appendix B. Acknowledgements 1099 Thanks to Ben Campbell, Dave Cridland, Miguel Garcia, Joe Hildebrand, 1100 Jonathan Lennox, Matt Miller, Florian Schmaus, Sam Whited, and 1101 Florian Zeitz for their feedback. 1103 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for 1104 employing him during his work on earlier versions of this document. 1106 Author's Address 1108 Peter Saint-Andre 1109 &yet 1111 Email: peter@andyet.com 1112 URI: https://andyet.com/