No Description
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

xep-0283.xml 16KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466
  1. <?xml version='1.0' encoding='UTF-8'?>
  2. <!DOCTYPE xep SYSTEM 'xep.dtd' [
  3. <!ENTITY % ents SYSTEM 'xep.ent'>
  4. <!ENTITY MOVED "&lt;moved/&gt;">
  5. %ents;
  6. ]>
  7. <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
  8. <xep>
  9. <header>
  10. <title>Moved</title>
  11. <abstract>This document defines an XMPP protocol extension that enables a user to inform its contacts about a change in JID.</abstract>
  12. &LEGALNOTICE;
  13. <number>0283</number>
  14. <status>Deferred</status>
  15. <type>Standards Track</type>
  16. <sig>Standards</sig>
  17. <approver>Council</approver>
  18. <dependencies>
  19. <spec>XMPP Core</spec>
  20. </dependencies>
  21. <supersedes>
  22. </supersedes>
  23. <supersededby/>
  24. <shortname>moved</shortname>
  25. <author>
  26. <firstname>Tory</firstname>
  27. <surname>Patnoe</surname>
  28. <email>tpatnoe@cisco.com</email>
  29. <jid>tpatnoe@cisco.com</jid>
  30. </author>
  31. <revision>
  32. <version>0.1</version>
  33. <date>2010-06-16</date>
  34. <initials>psa</initials>
  35. <remark><p>Initial published version.</p></remark>
  36. </revision>
  37. <revision>
  38. <version>0.0.7</version>
  39. <date>2010-06-09</date>
  40. <initials>tp</initials>
  41. <remark>
  42. <p>Modified syntax to use 'old' and 'new' attributes.</p>
  43. </remark>
  44. </revision>
  45. <revision>
  46. <version>0.0.6</version>
  47. <date>2010-06-07</date>
  48. <initials>tp</initials>
  49. <remark>
  50. <ul>
  51. <li>Update ordering so that it recommends sending the unsubscribe/unsubscribed, before, sending the subscribe</li>
  52. <li>Add section documenting what happens when a contact is offline when the unsubscribe/unsubscribed/subscribe stanzas are sent.</li>
  53. <li>Added an example about a hacker sending an unsolicited subscribe by guessing a roster entry.</li>
  54. </ul>
  55. </remark>
  56. </revision>
  57. <revision>
  58. <version>0.0.5</version>
  59. <date>2010-06-02</date>
  60. <initials>tp</initials>
  61. <remark>
  62. <p>Added one-way subscription section</p>
  63. </remark>
  64. </revision>
  65. <revision>
  66. <version>0.0.4</version>
  67. <date>2010-05-30</date>
  68. <initials>tp</initials>
  69. <remark>
  70. <p>Change MUST NOT to SHOULD NOT for clients auto-subscribing back; differentiate between inbound and outbound subscriptions.</p>
  71. </remark>
  72. </revision>
  73. <revision>
  74. <version>0.0.3</version>
  75. <date>2010-06-02</date>
  76. <initials>tp</initials>
  77. <remark><p>Add one-way subscription comments.</p></remark>
  78. </revision>
  79. <revision>
  80. <version>0.0.2</version>
  81. <date>2010-05-25</date>
  82. <initials>tp</initials>
  83. <remark><p>Minor tweaks.</p></remark>
  84. </revision>
  85. <revision>
  86. <version>0.0.1</version>
  87. <date>2010-05-22</date>
  88. <initials>tp</initials>
  89. <remark><p>First draft.</p></remark>
  90. </revision>
  91. </header>
  92. <section1 topic='Introduction' anchor='intro'>
  93. <p>There are a variety of reasons why a user may wish to change
  94. their JID. For example, a surname change because of marriage or simply
  95. an easier JID to remember.
  96. </p>
  97. <p>This XEP defines an approach for communicating that your JID has
  98. moved to a new JID, extending the existing subscription protocol documented
  99. in &xmppim;. The steps outlined here may be done either through a client
  100. or automated by a server.
  101. </p>
  102. </section1>
  103. <section1 topic='Requirements' anchor='reqs'>
  104. <ul>
  105. <li>The methods described here maintain compatibility with &xmppcore; and <cite>RFC 6121</cite>.</li>
  106. </ul>
  107. </section1>
  108. <section1 topic='The Move'>
  109. <p>In this scenario user@example.com moves to user2@example2.com.
  110. Both the user@example.com and user2@example2.com accounts have been
  111. created and still exist. The roster for user@example2.com is empty
  112. and the user wants to populate it with their entries from
  113. user@example.com.</p>
  114. <dl>
  115. <di>
  116. <dt>original JID</dt>
  117. <dd>user@example.com</dd>
  118. </di>
  119. <di>
  120. <dt>new JID</dt>
  121. <dd>user2@example2.com</dd>
  122. </di>
  123. </dl>
  124. <section2 topic='Unsubscribing the original JID from outbound subscriptions'
  125. anchor='unsubscribe'>
  126. <p>Because the original JID is no longer going to be used, the user SHOULD
  127. unsubscribe from all the outbound subscriptions user@example.com had.
  128. These can be identified as those in the 'to' or 'ask' states as
  129. defined in the 'jabber:iq:roster' protocol in <cite>RFC 6121</cite>.</p>
  130. <p>To unsubscribe all outbound subscriptions for the original JID send an
  131. unsubscribe &PRESENCE; stanza to all the old contacts with a &MOVED;
  132. element containing the new JID.</p>
  133. <p>There is the potential for other users to send a malicious unsubscribe
  134. containing a spoofed &MOVED; JID. Therefore, clients SHOULD NOT
  135. automatically subscribe to the JID contained in the &MOVED; stanza when
  136. receiving a subscribe &PRESENCE; stanza without displaying the &MOVED;
  137. JID to the user. See the Security Considerations section for
  138. details.</p>
  139. <example caption='Client unsubscribes outbound subscriptions from original JID'><![CDATA[
  140. <presence from='user@example.com' to='contact@example.com' type='unsubscribe'>
  141. <status>I've changed JIDs from user@example.com to user2@example2.com</status>
  142. <moved xmlns='urn:xmpp:moved:0' new='user2@example2.com'/>
  143. </presence>
  144. ]]></example>
  145. </section2>
  146. <section2 topic='Unsubscribing the original JID from inbound subscriptions'
  147. anchor='unsubscribed'>
  148. <p>Because the original JID is no longer going to be used, the user SHOULD
  149. unsubscribe from all contacts the user@example.com had an inbound
  150. subscription from. These can be identified as those in the 'from'
  151. subscription state as defined in in the 'jabber:iq:roster' protocol
  152. in <cite>RFC 6121</cite>.</p>
  153. <p>To unsubscribe all inbound subscriptions send an unsubscribed
  154. &PRESENCE; stanza to all the old contacts with a &MOVED; element
  155. containing the new JID.</p>
  156. <p>There is the potential for other users to send a malicious unsubscribed
  157. containing a spoofed &MOVED; JID. Therefore, clients SHOULD NOT
  158. automatically subscribe to the JID contained in the &MOVED; stanza
  159. without displaying the &MOVED; JID to the user. See the Security
  160. Considerations section for details.</p>
  161. <example caption='Client unsubscribes inbound subscriptions from original JID'>
  162. <![CDATA[
  163. <presence from='user@example.com' to='contact@example.com' type='unsubscribed'>
  164. <status>I've changed JIDs from user@example.com to user2@example2.com</status>
  165. <moved xmlns='urn:xmpp:moved:0' new='user2@example2.com'/>
  166. </presence>
  167. ]]>
  168. </example>
  169. </section2>
  170. <section2 topic='Subscribing the new JID to all your existing contacts'
  171. anchor='subscribe'>
  172. <p>Once the new JID has been created on a server it is possible for the
  173. new JID to subscribe to the contacts they had on the original JID's
  174. roster. This is done by sending a new subscription request with a
  175. &MOVED; element containing the new JID.
  176. </p>
  177. <p>The new subscription MUST come from the new JID's server.</p>
  178. <p>There is the potential for other users to send a malicious subscribe
  179. request and spoof the content of the &MOVED; element identifying an
  180. original JID. Therefore, clients SHOULD NOT automatically unsubscribe
  181. an existing roster entry if is listed as the target in the &MOVED;
  182. element when a subscribe is received. See the Security
  183. Consideration section for details.</p>
  184. <p>Clients accepting the moved subscription SHOULD indicate to the
  185. user that that this subscription request was the result of a move
  186. operation and because of potential malicious behavior SHOULD NOT
  187. auto-accept the subscription without displaying the &MOVED; JID to the
  188. user.</p>
  189. <example caption='Client requests subscription from new JID'>
  190. <![CDATA[
  191. <presence from='user2@example2.com' to='contact@example.com' type='subscribe'>
  192. <status>I've changed JIDs from user@example.com to user2@example2.com</status>
  193. <moved xmlns='urn:xmpp:moved:0' old='user@example.com'/>
  194. </presence>
  195. ]]>
  196. </example>
  197. </section2>
  198. <section2 topic='Contacts Offline at the Time the Rename Occurs'
  199. anchor='offline'>
  200. <p><cite>RFC 6120</cite> clarifies that an incoming subscribe &PRESENCE; stanza
  201. MUST be preserved by the server and &PRESENCE; stanzas of type
  202. unsubscribe and unsubscribed are not preserved on the server.
  203. Therefore, for a contact who is offline, their servers MAY have
  204. automatically removed the original roster entry when seeing the
  205. unsubscribe and unsubscribed stanzas. At the time of writing this XEP,
  206. NOT saving and forwarding the presence stanzas will be the default
  207. behavior of most servers.
  208. </p>
  209. <p>What this means is that a contact coming online after the rename
  210. outlined above MAY only see the &PRESENCE; of type 'subscribe' with
  211. the &MOVED; element. Clients should be aware of this behavior.
  212. </p>
  213. </section2>
  214. <section2 topic='Presence Ordering' anchor='ordering'>
  215. <p>In following the principle of least surprise, it is considered good
  216. practice to send the subscribe stanza after the unsubscribe and unsubscribed
  217. stanzas.
  218. </p>
  219. </section2>
  220. <section2 topic='Preservation of Groups' anchor='grouping'>
  221. <p>One of the side effects of this scheme is the potential for a contact
  222. to lose the groups to which it had organized the original JID. Clients
  223. aware of the &MOVED; element can mitigate this with the following rules.
  224. </p>
  225. <ul>
  226. <li>If the contacts client receives an unsubscribed with a &MOVED;
  227. element, remove the subscription but initiate a roster push for the
  228. original JID with the subscription set to 'none'. When the new
  229. subscription is received the new JID MAY be placed into the roster
  230. in the same groups as the original JID and the original JID can then be
  231. removed from the roster.
  232. </li>
  233. <li>If a subscribe is received with a &MOVED; element, the client MAY
  234. automatically place the new JID into the same groups as the original JID.
  235. </li>
  236. </ul>
  237. <p>As discussed in 'Contacts Offline at the Time the Rename Occurs', a
  238. server MAY automatically handle the unsubscribe and unsubscribed stanzas.
  239. If this occurs it will be impossible to preserve the original groups.
  240. </p>
  241. </section2>
  242. <section2 topic='One-way subcriptions and full roster state' anchor='one-way'>
  243. <section3 topic='One-way Inbound subscription' anchor='from_subs'>
  244. <p>If the original JID, user@example.com, had only an inbound subscription
  245. (from or pending in), then the contact will only receive an
  246. unsubscribed &PRESENCE; stanza. The contact's client, knowing the
  247. state of the subscription (which is 'to' or 'none' with 'ask='subscribe'
  248. from the contact's perspective), at that point MAY choose to prompt the
  249. user to subscribe to the new JID listed in the &MOVED; element.</p>
  250. <p>Because of the ability to spoof the &MOVED; element, the client SHOULD
  251. NOT automatically subscribe to the &MOVED; element target, but SHOULD
  252. present the new JID to the contact before sending out a subscription
  253. request.</p>
  254. </section3>
  255. <section3 topic='One-way Outbound subscription' anchor='to_subs'>
  256. <p>If the original JID, user@example.com, had only an outbound
  257. subscription (to or ask), then the contact SHOULD only receive an
  258. unsubscribe &PRESENCE; stanza. The contact's client, knowing the
  259. state of the subscription (which is 'from' from the contact's perspective),
  260. at that point MAY choose to prompt
  261. the user to subscribe to the new JID listed in the &MOVED; element.</p>
  262. <p>Because of the ability to spoof the &MOVED; element, the client SHOULD
  263. NOT automatically subscribe to the &MOVED; element target.</p>
  264. </section3>
  265. <section3 topic='Roster state and action table' anchor='actions'>
  266. <table caption="Roster states and actios from the renamed user's perspective">
  267. <tr>
  268. <td>Server state</td>
  269. <td>Client state (jabber:iq:roster)</td>
  270. <td>Send unsubscribe from original JID</td>
  271. <td>Send unsubscribed from original JID</td>
  272. <td>Send subscribe from new JID</td>
  273. </tr>
  274. <tr>
  275. <td>none</td>
  276. <td>none</td>
  277. <td></td>
  278. <td></td>
  279. <td></td>
  280. </tr>
  281. <tr>
  282. <td>none + pending out</td>
  283. <td>none + ask='subscribe'</td>
  284. <td>yes</td>
  285. <td></td>
  286. <td>yes</td>
  287. </tr>
  288. <tr>
  289. <td>none + pending in</td>
  290. <td>n/a</td>
  291. <td></td>
  292. <td>yes - server only</td>
  293. <td></td>
  294. </tr>
  295. <tr>
  296. <td>none + pending in/out</td>
  297. <td>none + ask='subscribe'</td>
  298. <td>yes</td>
  299. <td>yes - server only</td>
  300. <td>yes</td>
  301. </tr>
  302. <tr>
  303. <td>to</td>
  304. <td>to</td>
  305. <td>yes</td>
  306. <td></td>
  307. <td>yes</td>
  308. </tr>
  309. <tr>
  310. <td>to + pending in</td>
  311. <td>to</td>
  312. <td>yes</td>
  313. <td>yes - server only</td>
  314. <td>yes</td>
  315. </tr>
  316. <tr>
  317. <td>from</td>
  318. <td>from</td>
  319. <td></td>
  320. <td>yes</td>
  321. <td></td>
  322. </tr>
  323. <tr>
  324. <td>from + pending out</td>
  325. <td>from/none + ask='subscribe'</td>
  326. <td>yes</td>
  327. <td>yes</td>
  328. <td>yes</td>
  329. </tr>
  330. <tr>
  331. <td>both</td>
  332. <td>both</td>
  333. <td>yes</td>
  334. <td>yes</td>
  335. <td>yes</td>
  336. </tr>
  337. </table>
  338. </section3>
  339. </section2>
  340. </section1>
  341. <section1 topic='Security Considerations' anchor='security'>
  342. <p>It is not intended for servers to strip any &MOVED; elements from
  343. &PRESENCE; stanzas sent in from a client. This allows clients as well as
  344. servers to implement these same procedures.</p>
  345. <p>In order to prevent other users from maliciously altering contacts
  346. the client SHOULD NOT automatically subscribe to a &MOVED; JID when it
  347. receives an unsubscribe and SHOULD NOT automatically unsubscribe to
  348. a &MOVED; JID when it receives a subscribe.</p>
  349. <p>The following illustrates an example malicious attack.</p>
  350. <ol>
  351. <li>userA@example.com subscribes to userB@example.com</li>
  352. <li>The userB@example.com automatically accepts the subscription from
  353. userA@example.com. (Automatically done by the client using a simple
  354. domain trust).</li>
  355. <li>userA@example.com unsubscribes with the &MOVED; 'new' JID set to
  356. companyCEO@example.com.</li>
  357. <li>The previous steps can be repeated and have userB@example.com subscribe
  358. to a large number of people.</li>
  359. </ol>
  360. <p>A similar attack can be done with a new subscribe request causing users
  361. by guessing which users are subscribed to a contact.</p>
  362. <ol>
  363. <li>hacker@example.com subscribes to userB@example.com guessing that
  364. userA@example.com is on userB's roster.
  365. <![CDATA[
  366. <presence from='hacker@example.com' to='userB@example.com' type='subscribe'>
  367. <status>Subscribe to me!</status>
  368. <moved xmlns='urn:xmpp:moved:0' old='userA@example.com'/>
  369. </presence>
  370. ]]>
  371. </li>
  372. <li>If userB's client automatically accepted the subscription without
  373. displaying at prompt to userB showing the new JID to be hacker@example.com,
  374. then the user has no idea that hacker@example.com was just added to
  375. the roster.
  376. </li>
  377. </ol>
  378. </section1>
  379. <section1 topic='IANA Considerations' anchor='iana'>
  380. <p>This document requires no interaction with &IANA;.</p>
  381. </section1>
  382. <section1 topic='XMPP Registrar Considerations' anchor='reg'>
  383. <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
  384. <p>This specification defines the following XML namespace:</p>
  385. <ul>
  386. <li>urn:xmpp:moved:0</li>
  387. </ul>
  388. <p>Upon advancement of this specification from a status of Experimental
  389. to a status of Draft, the &REGISTRAR; shall add the foregoing namespace
  390. to the registry located at &NAMESPACES;, as described in Section 4 of
  391. &xep0053;.
  392. </p>
  393. </section2>
  394. <section2 topic='Protocol Versioning' anchor='registrar-versioning'>
  395. &NSVER;
  396. </section2>
  397. </section1>
  398. <section1 topic='XML Schema' anchor='schema'>
  399. <code><![CDATA[
  400. <?xml version='1.0' encoding='UTF-8'?>
  401. <xs:schema
  402. xmlns:xs='http://www.w3.org/2001/XMLSchema'
  403. targetNamespace='urn:xmpp:moved:0'
  404. xmlns='urn:xmpp:moved:0'
  405. elementFormDefault='qualified'>
  406. <xs:element name='moved'>
  407. <xs:complexType>
  408. <xs:simpleContent>
  409. <xs:extension base='xs:string'>
  410. <xs:attribute name='new' type='xs:string' use='optional'/>
  411. <xs:attribute name='old' type='xs:string' use='optional'/>
  412. </xs:extension>
  413. </xs:simpleContent>
  414. </xs:complexType>
  415. </xs:element>
  416. </xs:schema>
  417. ]]></code>
  418. </section1>
  419. <section1 topic='Acknowledgements' anchor='ack'>
  420. <p>The author wishes to thank Doug Abbink, Mikhail Belov, Peter Saint-Andre, and Peter Sheu for their feedback.</p>
  421. </section1>
  422. </xep>