From 235b876c08cb83a82b8a6f8c48ac178deb9c60ad Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 20 Jul 2021 17:06:26 +0200 Subject: [PATCH] XEP-0283: Transfer content from inbox/moved2.xml This re-introduces the proper acknowledgement of Tory which was removed in the previous commit. --- xep-0283.xml | 661 ++++++++++++++++++++++++++------------------------- 1 file changed, 335 insertions(+), 326 deletions(-) diff --git a/xep-0283.xml b/xep-0283.xml index 46869387..f3df9589 100644 --- a/xep-0283.xml +++ b/xep-0283.xml @@ -93,375 +93,384 @@

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. -

+ an easier JID to remember. Another common reason is that the provider goes + out of service (with a notice).

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

+ or automated by a server.

 +

This document aims to satisfy the following requirements:

 - -

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 user2@example2.com is empty - and the user wants to populate it with their entries from - user@example.com.

- +
-
original JID
-
user@example.com
+
Moved notification
+
An XML <moved/> element sent to a contact to inform them that + the user is moving to a new address. +
-
new JID
-
user2@example2.com
+
Moved statement
+
An XML <moved/> element published by the user on their old + account. It is used by contacts to verify that moved notifications + are genuine. +
+ - -

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 RFC 6121.

+ +

We start with the situation where the user, let's call them Juliet, has two accounts - + her original account juliet@im.example.net and a shiny new account on her personal + domain, juliet@capulet.example.

+

Juliet would like to migrate all her data and contacts to her new account, with minimal + disruption.

+ +

Before notifying contacts of the move, Juliet must connect to her old + account and publish a "statement" that the account is no longer in + use. This statement includes the address of her new account. +

+

The statement should be posted to a PEP node with the name 'urn:xmpp:moved:1'. The + payload should be a <moved/> element in the 'urn:xmpp:moved:1' namespace. This + element should in turn contain a single <new-jid/> element with the user's new JID + as its text content.

-

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.

+ + + + + + juliet@capulet.example + + + + + +]]> + + +

After publishing a moved statement on her old account, Juliet proceeds + to notify her contacts about the move.

-

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.

+

Juliet connects to her new account, and sends a subscription request to + each of her contacts. These subscription requests MUST contain a <moved/> + element in the 'urn:xmpp:moved:1' namespace. This element contains a single + <old-jid/> element with the old JID as its text content.>

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

Juliet's contact, Romeo, receives the subscription request from Juliet's + new JID. At this point Romeo has not verified that the new account + actually belongs to Juliet, and MUST perform such verification before + acting on the request any differently to usual.

+ +

If the value of <old-jid/> is not in the roster with an approved + incoming subscription ('from' or 'both'), the <moved/> element + MUST be ignored entirely.

+ +

To verify the request, Romeo makes a request to the JID specified in + <old-jid/> (which MUST be a bare JID) to fetch a published move + statement.

+ + + + + + + + +]]> + +

On success, Juliet's server will return the moved statement that Juliet published.

+ + + + + + + juliet@capulet.example + + + + + +]]> + +

Romeo MUST now verify that the received subscription request was from + the same bare JID contained in the <new-jid/> element in the moved + statement. If the JIDs do not match, or if there was an error fetching + the moved statement (except for "gone" - see note below), the + <moved/> element in the incoming subscription request MUST be + ignored entirely.

+ +

+ Note: As a special case, if the attempt to retrieve the + moved statement results in an error with the <gone/> condition as + defined in RFC 6120, and that <gone/> element contains a valid + XMPP URI (e.g. xmpp:user@example.com), then the error response + MUST be handled equivalent to a <moved/> statement containing a + <new-jid/> element with the JID provided in the URI (e.g. + user@example.com). +

+ + +

Upon successful verification, Romeo's client may present an appropriate + user interface, informing about Juliet's change of address, and a prompt + to accept the subscription request from the new address. On the user's + approval of such a subscription request, the client will typically want + to also send a subscription request to the contact's new JID to establish + a mutual subscription.

+ +

Due to the potential for races between multiple clients connected to + the same account, it is NOT RECOMMENDED for a client to automatically + act upon migration notifications, but instead await manual interaction + from the user. As with any inbound subscription request it SHOULD pay + attention to roster pushes related to the contact, and update the UI + appropriately if the new contact address is authorized from another + device.

+ + + +

It is not required for Romeo's server to support this specification. + However if Romeo's server does understand this extension, it SHOULD + handle the inbound subscription request on behalf of Romeo's clients. + This improves the user experience for Romeo, especially when he has + multiple devices.

+ +

Broadly the server should follow exactly the same process as a client + would. Specifically: +

+
    +
  1. Receive subscription request with 'moved' payload.
    2. +
  2. Verify that the old JID has an approved subscription to the user (i.e. a subscription of 'both' or 'from').
    3. +
  3. Request moved statement from the old account JID.
    4. +
  4. Verify that the new JID in the moved statement matches the 'from' of the subscription request.
    5. +
+ + + + + + + + +]]> + + + + + + + juliet@capulet.example + + + + + +]]> + +

If verification fails (e.g. due to a missing or incorrect moved + statement), the server MUST ignore the <moved/> element in the + subscription request, and process the stanza as a normal subscription + request. It MUST NOT strip the <moved/> element before forwarding, + even if verification fails.

+ +

Upon successful verification, the server MUST NOT forward the stanza to + Romeo's clients, but instead MUST create a roster entry for the new JID + with a subscription of 'from' (sending out the appropriate roster push), + and then auto-reply to the subscription request with a presence of type + 'subscribed'.

+ + + + + + +]]> + +

After authorizing the new JID, the server should revoke the presence + subscription of the old account.

+ + +]]> + + + + + + +]]> + +

Finally, if the old JID was in the user's roster with a subscription of 'both', the + server MUST also send a presence of type 'subscribe' to the new JID in + order to seek establishment of a mutual subscription.

+ + ]]> - -

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 RFC 6121.

- -

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 - - -]]> - + + + +

The moved statement is required for contacts to automatically verify + the authenticity of moved notifications. After publishing a moved + statement, the user should keep the statement published and the account + active for long enough for contacts to switch to the user's new account.

+

It is not necessary to remain connected to the old account during the + transition period. However the account must not be deleted, and the + server must be available.

+

In the event that the move statement is unpublished, the account is deleted, + or the server becomes unavailable, any contacts that have not yet transitioned + to the user's new JID will be unable to verify the migration. Those contacts + will have to manually approve the subscription from the user's new address.

+

Migration progress of contacts is obervable through subscription revocations to + the old account, and subscription approvals to the new account.

 - - -

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 - - -]]> - - - - - -

RFC 6120 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
- + +

Future revisions of this document, or alternative documents, may define + alternative verification methods. Such methods SHOULD be communicated via + child elements of <moved/> in an appropriate namespace. As is usual + throughout XMPP, entities MUST ignore unknown child elements of + <moved/> in unrecognised namespaces.

 -

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. -
- + +

The following are considerations for the user (exemplified by Juliet in this document):

+
    +
  • A malicious client or other entity with access to the user's account + can perform a migration, potentially against the user's will and/or + without their knowledge. Although this is a concern, any malicious + actor with access to a user's account can abuse that access in many + ways. Servers that support granting restricted access to accounts + should consider blocking attempts to publish to the + 'urn:xmpp:moved:1' PEP node from restricted entities.
    • +
  • To avoid leaking the user's new JID to non-contacts, the PEP node + containing the moved statement SHOULD be configured to use the + "presence" access model (this is the default access model defined + by PEP).
    • +
+ + +

The following are considerations for the contact (exemplified by Romeo in this document), and the contact's server:

+
    +
  • A presence subscription with a <moved/> is trivial for a + malicious third-party to spoof. The verification methods discussed + in this document MUST be followed to prevent accepting rogue + subscription requests.
    • +
  • It is important to verify that the original JID of the migrating + user was already authorized to view presence before processing a + migration.
    • +
  • After successfully processing a migration, the original account + should have its presence subscription revoked. This ensures that + each JID may only be migrated once. Without this precaution the + migration mechanism can be abused to introduce unlimited arbitrary + JIDs to contacts' rosters. This precaution also ensures, if the + old account ends up owned by a new entity, that they will not + unexpectedly inherit a presence subscription.
    • +
+

This document requires no interaction with &IANA;.

 - - -

This specification defines the following XML namespace:

+ + +

This specification defines the following XML namespace:

+
    +
  • urn:xmpp:moved:1
    • +
+ + + + +

There are two general approaches for verification - network-based + verification, or cryptographic verification. Network-based verification + (as described in this document) requests a verification statement from + the user's old account. Cryptographic verification would check a move + notification against a previously-established cryptographic identify of + the user.

+

Network-based verification:

    -
  • urn:xmpp:moved:0
    • +
  • Pro: Simple and easy to implement
    • +
  • Con: depends on the original server being available and supporting PEP
-

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; +

Cryptographic verification:

+
    +
  • Pro: Can work even if the original server goes offline or begins blocking + migration attempts.
    • +
  • Con: More complex implementation.
    • +
  • Con: Requires user and contacts to manage/track cryptographic keys and + identies. It may be possible to piggyback on top of an existing cryptographic + layer, e.g. OMEMO. However this would eliminate the server-side assistance, + and OMEMO support is not universal among clients.
    • +
+ +

Ultimately this document defines a network-based verification method, but + leaves an obvious path to extend the protocol with alternative verification + methods (either in an update to this document, or defined by other + documents).

 + - - - - - - - - - - - - - - - - -]]> + To be done upon advancement to Draft. + -

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

+

This document was formerly driven by Tory Patnoe with the support and feedback provided by Doug Abbink, Mikhail Belov, Peter Saint-Andre, and Peter Sheu.

+

It has since been taken over by the current author who thanks Kim Alvefur, Maxime Buquet and Jonas Schäfer for their input and feedback on this specification.