XEP-0383: Burner JIDs

Abstract
A mechanism by which users may request anonymous, ephemeral "burner" JIDs.
Author
Sam Whited
Copyright
© 2016 – 2021 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status

Experimental

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.
Type
Standards Track
Version
0.2.0 (2021-07-10)
Document Lifecycle
  1. Experimental
  2. Proposed
  3. Stable
  4. Final

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

Burner JID
A temporary JID that is not valid for the purpose of authentication but which may be authorized by an existing pre-authenticated session.
Ephemeral identity
The identity of a user on the server comprising a burner JID and any other associated data.
Authentication identity
The users normal identity and JID which they use to authenticate with the server and create new XMPP sessions.

3. Use Cases

4. Determining Support

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

Example 1. 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'/>
    …

5. Requesting a JID

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 2. 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 3. 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 [3] §2. If the server does not support SASL, or does not support any SASL mechanisms that support authorization identities, burner JIDs cannot be used.

6. Listing JIDs

Services MAY choose to support listing burner JIDs by responding to "disco#items" requests on the "urn:xmpp:burner:0" node. Such services must advertise a feature of "urn:xmpp:burner:0" in response to disco#info requests.

Example 4. Service responds to disco#info query indicating listing support
<iq type='result'
    from='muc.example.net'
    to='caiusmarcius@example.net/corioli'
    id='k3hs5174'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <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'/>
    <feature var='urn:xmpp:burner:0'/>
    …

This implies that services may choose to only support listing burner JIDs or requesting burner JIDs by advertising the feature or the identity, respectively. Most services will likely wish to advertise both.

The result of a disco#items request is a list of "item" elements with a "jid" attribute containing the burner JID. Burner JIDs that expire MAY include an "expires" attribute containing a timestamp in the UTC timezone conforming to the datetime profile specified in XMPP Date and Time Profiles (XEP-0082) [4]. Note that the lack of an "expires" attribute does not indicate that the JID never expires, just that the expiry date is unknown. Burner JIDs are ephemeral and services MAY remove them at any time.

Example 5. Service responds to disco#items query
<iq type='result'
    from='muc.example.net'
    to='caiusmarcius@example.net/corioli'
    id='k3hs5174'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='burner1@muc.example.net'/>
    <item jid='burner2@muc.example.net'/>
    <item jid='burner3@muc.example.net' expires='1969-07-21T02:56:15Z'/>
    …

7. 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 [5] 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.

8. Security Considerations

To prevent burner JIDs from being abused for spamming, implementations SHOULD rate limit all burner JIDs in use by an authn identity as a single unit. However, be advised that this may provide a third party that can monitor traffic patterns with the ability to determine what burner JIDs belong to the same user. To prevent a burner JIDs authn identity from being discovered the same way, burner JIDs SHOULD NOT share a rate limit with their authn identity.

If TLS channel binding information is encoded in the local part of the burner JID and the TLS version in use is 1.3 or greater, it is RECOMMENDED that the tls-exporter channel binding value defined in Channel Bindings for TLS 1.3 [6] be used. For versions of TLS less than 1.3, tls-unique SHOULD be used as defined by RFC 5929 [7] §3. Note that unless the master-secret fix from RFC 7627 [8] has been implemented tls-unique channel binding information does not include enough context to successfully verify the binding when resuming a TLS session.

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) [9].

9. IANA Considerations

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

10. XMPP Registrar Considerations

10.1 Protocol Namespaces

This specification defines the following XML namespace:

Upon advancement of this specification from a status of Experimental to a status of Draft, the XMPP Registrar [11] shall add the foregoing namespace to the registry located at <https://xmpp.org/registrar/disco-features.html> as described in Section 4 of XMPP Registrar Function (XEP-0053) [12].

Service Discovery Features Registry Submission
<var>
  <name>urn:xmpp:burner:0</name>
  <desc>Support for listing authorization identities and for issuing burner JIDs when paired with an appropriate identity.</desc>
  <doc>&xep0383;</doc>
</var>

The XMPP Registrar [11] shall also add the foregoing namespace to the Jabber/XMPP Protocol Namespaces Registry located at <https://xmpp.org/registrar/namespaces.html>. Upon advancement of this specification from a status of Experimental to a status of Draft, the XMPP Registrar [11] shall remove the provisional status from this registry entry.

Jabber/XMPP Protocol Namespaces Registry Submission
<ns>
  <name>urn:xmpp:burner:0</name>
  <doc>&xep0383;</doc>
  <status>provisional</status>
</ns>

10.2 Service Discovery Category/Type

Upon advancement of this proposal from experimental to draft status the XMPP Registrar [11] will include a category of "authz" in its registry at <https://xmpp.org/registrar/disco-categories.html>. The registrar will also add a value of "ephemeral" to that category. The registry submission is as follows:

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

Future submissions to the XMPP Registrar may register additional types.

10.3 Protocol Namespaces

This specification defines the following XML namespaces:

Upon advancement of this proposal from experimental to draft status the registrar will include the foregoing namespaces in its registry at <https://xmpp.org/registrar/namespaces.html> as governed by XMPP Registrar Function (XEP-0053) [12].

10.4 Namespace Versioning

If the protocol defined in this specification undergoes a revision that is not fully backwards-compatible with an older version, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

11. XML Schema

An XML Schema will be added before this document reaches the status of "draft".

12. 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.2.0
Last Updated
2021-07-10
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

Sam Whited
Email
sam@samwhited.com
JabberID
sam@samwhited.com
URI
https://blog.samwhited.com/

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2024 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

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 <https://xmpp.org/community/> 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

1. XEP-0175: Best Practices for Use of SASL ANONYMOUS <https://xmpp.org/extensions/xep-0175.html>.

2. XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>.

3. RFC 4422: Simple Authentication and Security Layer (SASL) <http://tools.ietf.org/html/rfc4422>.

4. XEP-0082: XMPP Date and Time Profiles <https://xmpp.org/extensions/xep-0082.html>.

5. The Keyed-Hash Message Authentication Code (HMAC): Federal Information Processing Standards Publication 198-1 <http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf>.

6. Channel Bindings for TLS 1.3 <http://tools.ietf.org/html/draft-ietf-kitten-tls-channel-bindings-for-tls13>.

7. RFC 5929: Channel Bindings for TLS <http://tools.ietf.org/html/rfc5929>.

8. RFC 7627: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension <http://tools.ietf.org/html/rfc7627>.

9. XEP-0300: Use of Cryptographic Hash Functions in XMPP <https://xmpp.org/extensions/xep-0300.html>.

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

11. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.

12. XEP-0053: XMPP Registrar Function <https://xmpp.org/extensions/xep-0053.html>.

Appendix H: Revision History

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

  1. Version 0.2.0 (2021-07-10)

    Improve security considerations and add listing JIDs.

    ssw
  2. Version 0.1.1 (2017-01-28)

    Improve security considerations.

    ssw
  3. Version 0.1 (2016-12-07)

    Initial version approved by the council.

    XEP Editor: ssw

Appendix I: Bib(La)TeX Entry

@report{whited2016burner,
  title = {Burner JIDs},
  author = {Whited, Sam},
  type = {XEP},
  number = {0383},
  version = {0.2.0},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-0383.html},
  date = {2016-12-07/2021-07-10},
}

END