Abstract: | This document defines a protocol and URI scheme for pre-authenticated roster links that allow a third party to automatically obtain the user's presence subscription. The goal of this is to make onboarding of new XMPP IM contacts as easy as possible. |
Author: | Georg Lukas |
Copyright: | © 1999 - 2016 XMPP Standards Foundation. SEE LEGAL NOTICES. |
Status: | ProtoXEP |
Type: | Standards Track |
Version: | 0.0.2 |
Last Updated: | 2016-06-14 |
WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.
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
4.3. Use of multiple clients
4.4. Opening the landing page in an app
5. Security Considerations
5.1. Token Generation
5.2. Checking Token Validity
5.3. Invitation Link Validity
5.4. Interception of Links
5.5. Display Names
6. IANA Considerations
7. XMPP Registrar Considerations
8. 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
Romeo is an active XMPP IM (Instant Messaging) user. He convinces Juliet (who doesn't have an XMPP account yet) to install a client and register with some server. Now, Romeo only needs to create a mutual presence subscription with her, without yet knowing her JID.
This specification allows Romeo to create an out-of-band link (URI) which, when opened in Juilet's (or another user's) client, will:
The perceivable effect is that with a single click, Romeo and Juliet become "friends" in terms of XMPP presence subscription.
This specification makes use of XMPP URIs. The basic URI scheme for XMPP is defined in RFC 5122 [1] and extended in XMPP URI Query Components (XEP-0147) [2] to support different actions like "roster" for roster addition and "subscribe" for presence subscription.
The process of mutual roster addition and subscription involves multiple steps:
The general idea of the protocol and the details of the individual steps are outlined in the following.
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.
Romeo mongatague.net capulet.net Juliet | | | | | Send out-of-band invitation link | | (xmpp:romeo@montague.net?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 | |<---------------------------------------------|
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.
xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;name=Romeo%20Montague
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. This requires an additional mechanism to query the server for new (and possibly also for pending) invitation links.
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:
There are multiple options where such a landing page could be hosted:
https://yax.im/i/romeo/montague.net/1tMFqYDdKhfe2pwp/Romeo+Montague
A possible screen representation of the landing page would be:
Romeo Montague has invited you to chat
If this link does not work, you need to install and configure an XMPP client. Please visit this page again afterwards. Choose one of these for your Tomato OS:
Check the full list of XMPP clients.
No further action is required if you do not know Romeo Montague or do not want to chat with them.
XMPP is a provider-independent form of instant messaging. That means you can pick from many different clients and have a free choice of server operators to communicate with Romeo Montague.
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.
<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:
<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.
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).
<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.
<presence to='juliet@capulet.net' type='subscribed' /> <presence to='juliet@capulet.net' type='subscribe' />
If Juliet's server support pre-approval, it will automatically handle the incoming subscription request and issue a roster push. Otherwise, Juliet's client will receive the subscription request:
<presence from='romeo@montague.net' to='juliet@capulet.net' type='subscribe' />
Juliet's client SHOULD check the subscription request sender JID against the whitelist, and either automatically approve the request or display an according notification to Juliet.
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.
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.
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.
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 yaxim client should register a handler for https://yax.im/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.
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 [3] 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 SAML [5] or JWT (RFC 7519 [6]). In such a case, the issuer must ensure a comparable security level and limit token reuse.
To limit the potential for abuse, the token SHOULD be limited in as follows:
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.
The invitation link that is generated by Romeo's client is considered a personal invitation link for a single person. This, and the fact that the link can only be used once, should be indicated by the client to Romeo.
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.
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.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [7].
Include the "urn:xmpp:pars:0" namespace in the registry of protocol namespaces. Include "preauth" as an additional key-value parameter to the roster query action.
<querytype> <name>roster</name> ... <key> <name>preauth</name> <desc>the token used to obtain an automatic approval from the target JID</desc> </key> </querytype>
REQUIRED for protocol specifications.
Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status:
ProtoXEP
Type:
Standards Track
Version: 0.0.2
Last Updated: 2016-06-14
Approving Body: XMPP Council
Dependencies: XMPP Core, RFC 5122, XEP-0147
Supersedes: None
Superseded By: None
Short Name: pars
This document in other formats:
XML
PDF
Email:
georg@op-co.de
JabberID:
georg@yax.im
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.
Given that this XMPP Extension Protocol normatively references IETF technologies, discussion on the <xsf-ietf@xmpp.org> list might also be appropriate.
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
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 <http://xmpp.org/extensions/xep-0147.html>.
3. See for example getrandom(2), SecureRandom or /dev/urandom. More information about the randomness requirements for security can be found in RFC 4086 [4]
4. RFC 4086: Randomness Requirements for Security <http://tools.ietf.org/html/rfc4086>.
5. Security Assertion Markup Language (SAML) <https://www.oasis-open.org/standards#samlv2.0>
6. RFC 7519: JSON Web Token (JWT) <http://tools.ietf.org/html/rfc7519>
7. 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/>.
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
First draft.
(gl)END