XEP-0383: Burner JIDs

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.

Table of Contents

1. Introduction

In many XMPP applications it is desirable to be able to act anonymously to prevent leaking personally identifiable information (PII) to a third party. Traditionally this is accomplished using SASL authentication and the ANONYMOUS mechanism as detailed in Best Practices for Use of SASL ANONYMOUS (XEP-0175) [1], however, the ANONYMOUS mechanism is in reality an authorization mechanism and does not provide authentication of users.

This specification solves these problems by decoupling anonymous identity management from authentication (auth) and authorization (authz). This allows logged in users (authenticated or anonymous at the server operators disgression) to request a new temporary identifier, a "burner" JID, which may be used by its owner to construct a new session with the server that is authorized to communicate anonymously with third parties and is (optionally) locally authenticated.

2. Glossary

3. Use Cases

• As a user concerned about spam I want to join a public chat room anonymously to prevent JID harvesting.
• As the author of a social website I want to allow users to create ephemeral identities which can be used to contact them even if they have not granted access to their personal information.
• As a server operator I want to allow users to act anonymously, but also want a way to rate limit the creation of ephemeral identities associated with a given authentication identity.

4. Business Rules

The user requests an ephemeral identity from the server or another XMPP service by sending an IQ containing an "identity" payload qualified by the urn:xmpp:burner:0 namespace.

Example 1. User requests ephemeral identity

<iq from='caiusmarcius@example.net/corioli'
    id='h7ns81g'
    to='example.net'
    type='get'>
  <identity xmlns='urn:xmpp:burner:0'/>
</iq>

If the service wishes to issue an ephemeral identity to the user it replies with a new burner JID:

Example 2. Server issues burner JID

<iq from='example.net'
    id='h7ns81g'
    to='caiusmarcius@example.net/corioli'
    type='result'>
  <identity xmlns='urn:xmpp:burner:0'>
    <jid>
      hfgnINTSA-ciCLz6NhTtCD5Jr0k:1477672278884j@example.net
    </jid>
  </identity>
</iq>

The burner JID MUST be a bare JID. Burner JIDs are not valid for the purpose of authentication, but may be authorized to perform actions. To use the burner JID the client then attempts to establish a new session with the server using the account that requested the burner JID as the authentication identity and the burner JID as the authorization identity as defined in RFC 4422 [2] §2. If the server does not support SASL, or does not support any SASL mechanisms that support authorization identities, burner JIDs cannot be used.

5. Determining Support

Services that support issuing burner JIDs MUST advertise the fact in responses to Service Discovery (XEP-0030) [3] "disco#info" requests by returning an identity of "authz/ephemeral":

Example 3. Service responds to disco#info query

<iq type='result'
    from='muc.example.net'
    to='caiusmarcius@example.net/corioli'
    id='k3hs5174'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity type='im' name='MyServer' category='server'/>
    <identity type='pep' name='MyServer' category='pubsub'/>
    <identity type='ephemeral' category='authz'/>
    …
    <feature var='http://jabber.org/protocol/disco#info'/>
    <feature var='http://jabber.org/protocol/disco#items'/>
    <feature var='http://jabber.org/protocol/muc'/>
    …

6. Implementation Notes

It may be impractical to store verification information for every burner JID issued by the system. To this end servers that implement this specification MAY choose to encode information into the localpart of issued burner JIDs which can be verified when a user attempts to authorize a new session to use the burner JID. If an implementation chooses to do this it is RECOMMENDED that an HMAC [4] be used. This HMAC MAY include the JID of the associated authentication identity, an expiration or issued time for the burner JID, session information, TLS channel binding data, or any other information the server wishes to verify. The format of this key or its input values is left as an implementation decision.

As with persistent JIDs, the client MUST NOT assign any meaning to the localpart or resourcepart of a burner JID.

7. Security Considerations

To prevent burner JIDs from being abused for spamming, implementations SHOULD rate limit all burner JIDs in use by an authentication identity as a single unit.

If TLS channel binding information is encoded in the burner JID it is RECOMMENDED that the tls-unique channel binding value be used as defined by RFC 5929 [5] §3. However, for resumed sessions the JIDs SHOULD be considered invalid unless the master-secret fix from RFC 7627 [6] has been implemented because otherwise resumption does not include enough context to successfully verify the binding.

Implementations that choose to encode information in the localpart of burner JIDs should take care when choosing a hash function. For current recommendations see Use of Cryptographic Hash Functions in XMPP (XEP-0300) [7].

8. IANA Considerations

This docment requires no interaction with the the Internet Assigned Numbers Authority (IANA) [8].

9. XMPP Registrar Considerations

<category>
  <name>authz</name>
  <desc>Services and nodes that provide authorization identities.</desc>
  <type>
    <name>ephemeral</name>
    <desc>
      An authorization service that provides ephemeral identities.
    </desc>
    <doc>XEP-0383</doc>
  </type>
</category>

10. XML Schema

TODO.

11. Acknowledgements

The author wishes to thank Philipp Hancke for his feedback.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0383
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.1
Last Updated: 2016-12-07
Approving Body: XMPP Council
Dependencies: XMPP Core, RFC 4422
Supersedes: None
Superseded By: None
Short Name: burner
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Appendix C: Legal Notices

Appendix D: Relation to XMPP

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.

Appendix E: Discussion Venue

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

Appendix F: Requirements Conformance

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

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

END