XEP-0383: Burner JIDs

Abstract: A mechanism by which users may request anonymous, ephemeral "burner" JIDs.
Author:Sam Whited
Copyright:© 1999 – 2017 XMPP Standards Foundation. SEE LEGAL NOTICES.
Type:Standards Track
Last Updated:2017-01-28

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
2. Glossary
3. Use Cases
4. Business Rules
5. Determining Support
6. Implementation Notes
7. Security Considerations
8. IANA Considerations
9. XMPP Registrar Considerations
    9.1. Service Discovery Category/Type
    9.2. Protocol Namespaces
    9.3. Namespace Versioning
10. XML Schema
11. Acknowledgements

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

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. 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'
  <identity xmlns='urn:xmpp:burner:0'/>

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'
  <identity xmlns='urn:xmpp:burner:0'>

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'
  <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 MAY 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 it is RECOMMENDED that the tls-unique channel binding value be used as defined by RFC 5929 [5] §3. Note that unless the master-secret fix from RFC 7627 [6] has been implemented 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) [7].

8. IANA Considerations

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

9. XMPP Registrar Considerations

9.1 Service Discovery Category/Type

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

  <desc>Services and nodes that provide authorization identities.</desc>
      An authorization service that provides ephemeral identities.

Future submissions to the XMPP Registrar may register additional types.

9.2 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 <http://xmpp.org/registrar/namespaces.html> as governed by XMPP Registrar Function (XEP-0053) [10].

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

10. XML Schema


11. Acknowledgements

The author wishes to thank Philipp Hancke for his feedback.


Appendix A: Document Information

Series: XEP
Number: 0383
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.1.1
Last Updated: 2017-01-28
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/

Appendix C: Legal Notices


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


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 <http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

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

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

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

3. XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.

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

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

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

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

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

9. 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 <http://xmpp.org/registrar/>.

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

Appendix H: Revision History

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

Version 0.1.1 (2017-01-28)

Improve security considerations.


Version 0.1 (2016-12-07)

Initial version approved by the council.

(XEP Editor: ssw)