XEP-0379: Pre-Authenticated Roster Subscription

1. Introduction
2. Requirements
3. Pre-Authenticated Roster Subscription
    3.1. General Idea
    3.2. Generation of Invitation Link
    3.3. Out-of-band Transmission and Presentation of the Link
    3.4. Subcription Request to the User by the Link Receiver (New Contact)
    3.5. Approval by the User and Mutual Subscription Request
    3.6. Approval by the New Contact
4. Business Rules
    4.1. Fallback to Manual Process
    4.2. No Expectaion of Immediate Approval
5. Security Considerations
    5.1. Token Generation
    5.2. Checking Token Validity
    5.3. Interception of Links
    5.4. Display Names
6. Usability Considerations
    6.1. Use of Multiple Clients
    6.2. Opening the Landing Page in an App
    6.3. Invitation Link Volatility
    6.4. Tagging of Auto-Added Contacts
7. IANA Considerations
8. XMPP Registrar Considerations
9. XML Schema

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

3.1 General Idea

As Romeo doesn't know Juliet's JID, he needs to send an out-of-band invitation. Later, his client needs to match an incoming subscription request to this invitation, so it can perform a secure automatic roster addition and subscription approval. This matching is accomplished by means of an authentication token, which is generated by Romeo's client, added to the invitation link and then carried over into the subscription request eventually made by Juliet's client. Romeo's client can then compare the token received in a subscription request to the list of issued tokens, and automatically approve the subscription.

Successful PARS Protocol Flow

Romeo          mongatague.net  capulet.net     Juliet
   |              |               |               |
   | Send out-of-band invitation link             |
   | xmpp:romeo@montague.net?roster;preauth=token |
   |- - - - - - - - - - - - - - - - - - - - - - ->|
   |              |               |    roster add |
   |              |               |<--------------|
   |       presence subscription request w/ token |
   |  <presence><preauth token="..."/></presence> |
   |<---------------------------------------------|
   | (token validation check)     |               |
   | presence subscribed          |               |
   |--------------------------------------------->|
   | roster add   |               |               |
   |------------->|               |               |
   | presence subscription request|               |
   |--------------------------------------------->|
   |              |               (auto approval) |
   |              |           presence subscribed |
   |<---------------------------------------------|

3.2 Generation of Invitation Link

Whenever Romeo wishes to invite somebody to his roster, his client will generate an invitation link that contains a new authentication token. This document extends the "roster" URI action defined in XEP-0147 with a new key-value parameter named "preauth" to store the generated token. Romeo's client will create an xmpp: link containing Romeo's JID, the "roster" action, the "preauth" parameter with the token value, and optionally a "name" parameter with the suggested display name.

Example 1. Invitation Link with Roster Action and Authentication Token

xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;name=Romeo+Montague

If the "preauth" parameter is present, the processing client is supposed not only to add the user to the roster, but also to automatically send a subscription request containing the authentication token.

Server-side implementation: it is possible (but out-of-scope for this document), to let the user's server handle generation of links as well as automatic approval of qualified subscription requests. One such approach is documented in Easy User Onboarding (XEP-0401) [3].

3.3 Out-of-band Transmission and Presentation of the Link

As Romeo doesn't know Juliet's JID in advance, he needs to use an out-of-band method (like e-mail, QR codes or NFC) to transmit the invitation link to Juliet. While these methods allow transmission of xmpp: URIs, there is no mechanism to ensure that Juliet actually has a client installed that can open the URI.

One way to solve this problem is to present Juliet with a web-based landing page that contains the following elements:

• A short text that this is an XMPP invitation from Romeo.
• A client recommendation (based on the detected web browser/OS) with download links.
• A prominent button that activates the actual xmpp: link.

There are multiple options where such a landing page could be hosted:

1. XSF: a central place would provide a common ground for a curated client list and ensure long-term availability. However, the operator would be able to collect meta-data and abuse authentication tokens.
2. Client developer: the developer of Romeo's client can provide a landing page for invitation requests created with this client. This is a feasible short-term solution and allows to recommend the same client as used by the link sender. However, it shares the privacy objections of the XSF solution and can not guarantee long-term availability of the service. If the client development shuts down, invitation links created with the client will cease working.
3. User's server: this is the optimal long-term solution, as the user's server is already entrusted with the relevant meta-data and will exist at least as long as the user's account on that server. However, this requires an additional server component to query for invitation URIs and a web server hosting the landing page. Furthermore, the server operator needs to maintain the list of recommended clients.

Example 2. Developer-Hosted Landing Page Generated with Fictitious JuicyXMPP Client

https://juicyxmpp.example/i/#romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;name=Romeo+Montague

A possible screen representation of the landing page would be:

3.4 Subcription Request to the User by the Link Receiver (New Contact)

When Juliet opens the xmpp: URI (or the according client-supported landing page URI) in her client, the client should perform the usual roster addition action, i.e. display a dialog allowing to edit the entry or to cancel the process. If Juliet completes the roster addition, the client SHOULD also send a subscription request to Romeo. This request SHOULD contain a 'preauth' element containing the authentication token from the invitation link.

Example 3. Subscription Request with Pre-Authenticated Roster Subscription Element

<presence to='romeo@montague.net' type='subscribe'>
  <preauth xmlns='urn:xmpp:pars:0' token='1tMFqYDdKhfe2pwp' />
</presence>

If Juliet's server supports subscription pre-approval, the client SHOULD additionally pre-approve Romeo:

Example 4. Juliet Pre-approves Romeo

<presence to='romeo@montague.net' type='subscribed' />

If Juliet's server does not indicate pre-approval support, her client SHOULD store Romeo's JID in a local auto-approval whitelist, together with an appropriate expiration time.

3.5 Approval by the User and Mutual Subscription Request

When Romeo's client receives a subscription request containing a 'preauth' element, it needs to extract the authentication token and check if the token is a valid one and was previously issued by the client (see security considerations below).

Example 5. Subscription Request With Tokens Received by Romeo

<presence to='romeo@montague.net' from='juliet@capulet.net' type='subscribe'>
  <preauth xmlns='urn:xmpp:pars:0' token='1tMFqYDdKhfe2pwp' />
</presence>

If the token is considered valid, the client SHOULD automatically approve the subscription request, add the sender of the subscription request to the roster and send a subscription request of its own.

Example 6. Automatic Approval and Response Subscription Request

<presence to='juliet@capulet.net' type='subscribed' />
<presence to='juliet@capulet.net' type='subscribe' />

3.6 Approval by the New Contact

If Juliet's server supports pre-approval, it will automatically handle the incoming subscription request and issue a roster push. Otherwise, Juliet's client will receive the subscription request:

Example 7. Mutual Subscription Request

<presence from='romeo@montague.net' to='juliet@capulet.net' type='subscribe' />

Juliet's client MUST ensure that the sender JID is contained in the auto-approval whitelist before automatically approving the request. Otherwise, it has to fallback to the normal subscription approval process.

4.1 Fallback to Manual Process

An implementation of this protocol MUST allow for a "graceful degradation" to the manual subscription approval process. If a client receives a malformed or unknown 'preauth' token, it MUST ignore it and act as if no preauth token was contained.

4.2 No Expectaion of Immediate Approval

When sending a pre-authenticated subscription request, the contact's client MUST NOT expect an immediate successful approval. If the user's issuing client is currently offline, or if the token has expired, a manual approval will be performed. Therefore, the contact's client should use the same mechanism as before to indicate an unidirectional subscription.

5.1 Token Generation

As the authentication token grants automatic addition to Romeo's roster and automatic approval of presence subscription, the token SHOULD be created with a cryptographically secure random number generator [4] and provide sufficient entropy to make brute-force attacks infeasible. It is suggested to generate at least 80 bits of entropy, and to use an encoding that can be easily encoded as part of an URI (e.g. Base-32).

It is possible to use a different token generation scheme like Security Assertion Markup Language [6] or JWT (RFC 7519 [7]). In such a case, the issuer must ensure a comparable security level and limit token reuse.

5.2 Checking Token Validity

To limit the potential for abuse, the token SHOULD be limited in as follows:

• Usage: in the typical scenario, each token may only be used once. While it is possible for a client to generate a token for multiple uses (like for embedding it in a contact card), the conventional manual roster management should be used for public invitation links.
• Time: each token MUST have a limited validity time. As the token is transmitted out-of-band, it should provide sufficient reaction time, e.g. one week. This time limit also allows the issuer to delete expired tokens.
• Identity: if the JID of the token receiver is known in advance, the token sender MUST NOT allow a different JID to redeem this token.

If a token is considered invalid (due to failing any of the above conditions, or for other reasons), a client MUST fall back to manual roster addition and manual subscription approval.

5.3 Interception of Links

A Monkey-in-the-Middle attacker who gains access to the invitation link can manipulate its fields or redeem the link themselves. However, this is true for all communication performed using the chosen medium and is out of scope for this document.

Ideally, Romeo's client should highlight automatically-added roster items and provide an easy mechanism to remove them and cancel their subscription.

5.4 Display Names

An attacker can lure the user by providing an invitation link with a 'name' parameter that does not match the JID. Therefore, a client SHOULD always display both the JID and the proposed display name when adding a roster item.

When the user's client automatically approves a subscription, it SHOULD add the new contact to the roster without a 'name' or with the 'name' equal to the JID, to prevent impersonation attacks.

6.1 Use of Multiple Clients

If a user is logged in with multiple clients, some of their clients will receive a subscription request with an unknown token. In this case, a client MAY delay the user notification for a short time, to allow another logged-in client to automatically handle the subscription request.

6.2 Opening the Landing Page in an App

Some mobile device platforms allow an app to register itself as a handler for cetain URIs. This allows an XMPP client to register for xmpp: URIs, but also to redirect handling of cetain HTTP/HTTPS URIs. A mobile client SHOULD register for the associated landing page URIs and properly handle the contained invitations. For example, the JuicyXMPP client should register a handler for https://juicyxmpp.example/i/*, and present the "Add to roster" dialog if such a link is opened. A client MAY register for the landing page URIs of other providers after obtaining the operators' approval.

6.3 Invitation Link Volatility

By default, Romeo's client should generate personal invitation links that can only be redeemed once, and only for a limited time. This fact SHOULD be indicated by the client UI to Romeo.

If a client allows customization of the validity time or the number of uses for a given invitation token, it SHOULD provide clear language to inidcate that.

6.4 Tagging of Auto-Added Contacts

When a new contact is added automatically by the client, it SHOULD indicate this fact to the user, and allow the user to rename / group the contact appropriately. One possible way to achieve this is by putting all auto-added contacts into a special roster group, and by automatically removing this group on the first manual edit of the contact.

In this case, the roster group should be named by the client according to the user's locale settings. However, this approach might lead to different clients using different group names, resulting in multiple roster groups with the same goal.

<querytype>
  <name>roster</name>
    ...
    <key>
      <name>preauth</name>
      <desc>the token used to obtain an automatic approval from the target JID</desc>
    </key>
</querytype>

Georg Lukas

Email: georg@op-co.de
JabberID: georg@yax.im

Copyright

Permissions

Disclaimer of Warranty

Limitation of Liability

IPR Conformance

1. RFC 5122: Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) <http://tools.ietf.org/html/rfc5122>.

2. XEP-0147: XMPP URI Query Components <https://xmpp.org/extensions/xep-0147.html>.

3. XEP-0401: Easy User Onboarding <https://xmpp.org/extensions/xep-0401.html>.

4. See for example getrandom(2), SecureRandom or /dev/urandom. More information about the randomness requirements for security can be found in RFC 4086 [5]

5. RFC 4086: Randomness Requirements for Security <http://tools.ietf.org/html/rfc4086>.

6. Security Assertion Markup Language <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security>.

7. RFC 7519: JSON Web Token (JWT) <http://tools.ietf.org/html/rfc7519>.

8. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

Version 0.2.0 (2017-03-06)

Version 0.1.2 (2017-02-16)

Version 0.1.1 (2017-01-01)

Version 0.1.0 (2016-07-20)