From ac3dfcb085d165fcff0f1912b590386e1ab2348f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 20 Jul 2021 17:05:34 +0200 Subject: [PATCH 1/4] XEP-0283: grant authorship to Matthew Wild as per Council vote MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Tory Patnoe has been contacted by me (Jonas Schäfer) for consent. A future update to this document will include an appropriate acknowledgement. --- xep-0283.xml | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/xep-0283.xml b/xep-0283.xml index 9fab930c..46869387 100644 --- a/xep-0283.xml +++ b/xep-0283.xml @@ -22,12 +22,7 @@ moved - - Tory - Patnoe - tpatnoe@cisco.com - tpatnoe@cisco.com - + &mwild; 0.1.1 2018-08-06 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 2/4] 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:

    -
  • The methods described here maintain compatibility with &xmppcore; and RFC 6121.
    • +
  • Users should be able to notify their contacts of a change of address.
    • +
  • Contacts should be able to verify that such a notification is legitimate, to prevent malicious actors from spoofing notifications.
    • +
  • It should be possible for a contact's server to automatically update the contact's roster for seamless migrations.
    • +
  • In the absence of a contact's support for this protocol, it should fall back to a simple manual subscription approval.
 - -

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.

 From d18029014ca73de1535c9696454c5a63f02bd4c7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 10 Aug 2021 19:07:44 +0200 Subject: [PATCH 3/4] XEP-0283: Fix incorrect XML --- xep-0283.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0283.xml b/xep-0283.xml index f3df9589..f2ede255 100644 --- a/xep-0283.xml +++ b/xep-0283.xml @@ -466,7 +466,7 @@ - To be done upon advancement to Draft. +

To be done upon advancement to Draft.

 From ceb49bf5222c4028d95a269e6cdca3838a9e25d6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 20 Jul 2021 17:06:51 +0200 Subject: [PATCH 4/4] XEP-0283: add revision block --- xep-0283.xml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/xep-0283.xml b/xep-0283.xml index f2ede255..0bf37198 100644 --- a/xep-0283.xml +++ b/xep-0283.xml @@ -11,7 +11,7 @@ This document defines an XMPP protocol extension that enables a user to inform its contacts about a change in JID. &LEGALNOTICE; 0283 - Deferred + Experimental Standards Track Standards Council @@ -23,6 +23,12 @@ moved &mwild; + + 0.2.0 + 2021-07-20 + mw +

Re-write the flow with a more focused approach.

 + 0.1.1 2018-08-06