diff --git a/xep-0283.xml b/xep-0283.xml new file mode 100644 index 00000000..50158941 --- /dev/null +++ b/xep-0283.xml @@ -0,0 +1,465 @@ + + + +%ents; +]> + + +
+ Moved + This document defines an XMPP protocol extension that enables a user to inform its contacts about a change in JID. + &LEGALNOTICE; + 0283 + Experimental + Standards Track + Standards + Council + + XMPP Core + + + + + moved + + Tory + Patnoe + tpatnoe@cisco.com + tpatnoe@cisco.com + + + 0.1 + 2010-06-11 + psa +

Initial published version.

 + + + 0.0.7 + 2010-06-09 + tp + +

Modified syntax to use 'old' and 'new' attributes.

+ + + + 0.0.6 + 2010-06-07 + tp + +
    +
  • Update ordering so that it recommends sending the unsubscribe/unsubscribed, before, sending the subscribe
    • +
  • Add section documenting what happens when a contact is offline when the unsubscribe/unsubscribed/subscribe stanzas are sent.
    • +
  • Added an example about a hacker sending an unsolicited subscribe by guessing a roster entry.
    • +
+ + + + 0.0.5 + 2010-06-02 + tp + +

Added one-way subscription section

+ + + + 0.0.4 + 2010-05-30 + tp + +

Change MUST NOT to SHOULD NOT for clients auto-subscribing back; differentiate between inbound and outbound subscriptions.

+ + + + 0.0.3 + 2010-06-02 + tp +

Add one-way subscription comments.

 + + + 0.0.2 + 2010-05-25 + tp +

Minor tweaks.

 + + + 0.0.1 + 2010-05-22 + tp +

First draft.

 + +
+ +

There are a variety of reasons why a user may wish to change + their JID. For example, a surname change because of marriage or simply + an easier JID to remember. +

+ +

This XEP defines an approach for communicating that your JID has + moved to a new JID, extending the existing subscription protocol documented + in &rfc3921;. The steps outlined here may be done either through a client + or automated by a server. +

+ + + + + + + +

In this scenario user@example.com moves to user2@example2.com. + Both the user@example.com and user2@example2.com accounts have been + created and still exist. The roster for user@example2.com is empty + and the user wants to populate it with their entries from + user@example.com.

+ +
+
original JID
+
user@example.com
+
new JID
+
user2@example2.com
+
+ + +

Because the original JID is no longer going to be used, the user SHOULD + unsubscribe from all the outbound subscriptions user@example.com had. + These can be identified as those in the 'to' or 'ask' states as + defined in the 'jabber:iq:roster' protocol in &rfc3921;.

+ +

To unsubscribe all outbound subscriptions for the original JID send an + unsubscribe &PRESENCE; stanza to all the old contacts with a &MOVED; + element containing the new JID.

+ +

There is the potential for other users to send a malicious unsubscribe + containing a spoofed &MOVED; JID. Therefore, clients SHOULD NOT + automatically subscribe to the JID contained in the &MOVED; stanza when + receiving a subscribe &PRESENCE; stanza without displaying the &MOVED; + JID to the user. See the Security Considerations section for + details.

+ + + + I've changed JIDs from user@example.com to user2@example2.com + + +]]> + + + + + +

Because the original JID is no longer going to be used, the user SHOULD + unsubscribe from all contacts the user@example.com had an inbound + subscription from. These can be identified as those in the 'from' + subscription state as defined in in the 'jabber:iq:roster' protocol + in &rfc3921;.

+ +

To unsubscribe all inbound subscriptions send an unsubscribed + &PRESENCE; stanza to all the old contacts with a &MOVED; element + containing the new JID.

+ +

There is the potential for other users to send a malicious unsubscribed + containing a spoofed &MOVED; JID. Therefore, clients SHOULD NOT + automatically subscribe to the JID contained in the &MOVED; stanza + without displaying the &MOVED; JID to the user. See the Security + Considerations section for details.

+ + + + I've changed JIDs from user@example.com to user2@example2.com + + +]]> + + + + + +

Once the new JID has been created on a server it is possible for the + new JID to subscribe to the contacts they had on the original JID's + roster. This is done by sending a new subscription request with a + &MOVED; element containing the new JID. +

+ +

The new subscription MUST come from the new JID's server.

+ +

There is the potential for other users to send a malicious subscribe + request and spoof the content of the &MOVED; element identifying an + original JID. Therefore, clients SHOULD NOT automatically unsubscribe + an existing roster entry if is listed as the target in the &MOVED; + element when a subscribe is received. See the Security + Consideration section for details.

+ +

Clients accepting the moved subscription SHOULD indicate to the + user that that this subscription request was the result of a move + operation and because of potential malicious behavior SHOULD NOT + auto-accept the subscription without displaying the &MOVED; JID to the + user.

+ + + + I've changed JIDs from user@example.com to user2@example2.com + + + ]]> + + + + + +

&rfc3920bis; clarifies that an incoming subscribe &PRESENCE; stanza + MUST be preserved by the server and &PRESENCE; stanzas of type + unsubscribe and unsubscribed are not preserved on the server. + Therefore, for a contact who is offline, their servers MAY have + automatically removed the original roster entry when seeing the + unsubscribe and unsubscribed stanzas. At the time of writing this XEP, + NOT saving and forwarding the presence stanzas will be the default + behavior of most servers. +

+ +

What this means is that a contact coming online after the rename + outlined above MAY only see the &PRESENCE; of type 'subscribe' with + the &MOVED; element. Clients should be aware of this behavior. +

+ + + +

In following the principle of least surprise, it is considered good + practice to send the subscribe stanza after the unsubscribe and unsubscribed + stanzas. +

+ + + +

One of the side effects of this scheme is the potential for a contact + to lose the groups to which it had organized the original JID. Clients + aware of the &MOVED; element can mitigate this with the following rules. +

+ +
    +
  • If the contacts client receives an unsubscribed with a &MOVED; + element, remove the subscription but initiate a roster push for the + original JID with the subscription set to 'none'. When the new + subscription is received the new JID MAY be placed into the roster + in the same groups as the original JID and the original JID can then be + removed from the roster. +
    • + +
  • If a subscribe is received with a &MOVED; element, the client MAY + automatically place the new JID into the same groups as the original JID. +
    • +
+ +

As discussed in 'Contacts Offline at the Time the Rename Occurs', a + server MAY automatically handle the unsubscribe and unsubscribed stanzas. + If this occurs it will be impossible to preserve the original groups. +

+ + + + + +

If the original JID, user@example.com, had only an inbound subscription + (from or pending in), then the contact will only receive an + unsubscribed &PRESENCE; stanza. The contact's client, knowing the + state of the subscription (which is 'to' or 'none' with 'ask='subscribe' + from the contact's perspective), at that point MAY choose to prompt the + user to subscribe to the new JID listed in the &MOVED; element.

+ +

Because of the ability to spoof the &MOVED; element, the client SHOULD + NOT automatically subscribe to the &MOVED; element target, but SHOULD + present the new JID to the contact before sending out a subscription + request.

+ + + +

If the original JID, user@example.com, had only an outbound + subscription (to or ask), then the contact SHOULD only receive an + unsubscribe &PRESENCE; stanza. The contact's client, knowing the + state of the subscription (which is 'from' from the contact's perspective), + at that point MAY choose to prompt + the user to subscribe to the new JID listed in the &MOVED; element.

+ +

Because of the ability to spoof the &MOVED; element, the client SHOULD + NOT automatically subscribe to the &MOVED; element target

. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Server stateClient state (jabber:iq:roster)Send unsubscribe from original JIDSend unsubscribed from original JIDSend subscribe from new JID
nonenone
none + pending outnone + ask='subscribe'yesyes
none + pending inn/ayes - server only
none + pending in/outnone + ask='subscribe'yesyes - server onlyyes
totoyesyes
to + pending intoyesyes - server onlyyes
fromfromyes
from + pending outfrom/none + ask='subscribe'yesyesyes
bothbothyesyesyes
+ + + + + +

It is not intended for servers to strip any &MOVED; elements from + &PRESENCE; stanzas sent in from a client. This allows clients as well as + servers to implement these same procedures.

+ +

In order to prevent other users from maliciously altering contacts + the client SHOULD NOT automatically subscribe to a &MOVED; JID when it + receives an unsubscribe and SHOULD NOT automatically unsubscribe to + a &MOVED; JID when it receives a subscribe.

+ +

The following illustrates an example malicious attack.

+ +
    +
  1. userA@example.com subscribes to userB@example.com
    2. +
  2. The userB@example.com automatically accepts the subscription from + userA@example.com. (Automatically done by the client using a simple + domain trust).
    3. +
  3. userA@example.com unsubscribes with the &MOVED; 'new' JID set to + companyCEO@example.com.
    4. +
  4. The previous steps can be repeated and have userB@example.com subscribe + to a large number of people.
    5. +
+ +

A similar attack can be done with a new subscribe request causing users + by guessing which users are subscribed to a contact.

+ +
    +
  1. hacker@example.com subscribes to userB@example.com guessing that + userA@example.com is on userB's roster. + + Subscribe to me! + + +]]> +
    2. +
  2. If userB's client automatically accepted the subscription without + displaying at prompt to userB showing the new JID to be hacker@example.com, + then the user has no idea that hacker@example.com was just added to + the roster. +
    3. +
+ + + + +

This document requires no interaction with &IANA;.

+ + + +

This specification defines the following XML namespace:

+
    +
  • urn:xmpp:moved:0
    • +
+

Upon advancement of this specification from a status of Experimental + to a status of Draft, the ®ISTRAR; shall add the foregoing namespace + to the registry located at &NAMESPACES;, as described in Section 4 of + &xep0053;. +

+ + + &NSVER; + + + + + + + + + + + + + + + + + + + + ]]> + + +

The author wishes to thank Doug Abbink, Mikhail Belov, Peter Saint-Andre, and Peter Sheu for their feedback.

+ +