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.
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.
<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:
<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.
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":
<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'/>
…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.
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].
This docment requires no interaction with the the Internet Assigned Numbers Authority (IANA) [8].
Upon advancement of this proposal from experimental to draft status the XMPP Registrar [9] 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.
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) [10].
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.
TODO.
The author wishes to thank Philipp Hancke for his feedback.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2020 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.
## 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. ##
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.
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).
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.
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. XEP-0175: Best Practices for Use of SASL ANONYMOUS <https://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 <https://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 <https://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 <https://xmpp.org/registrar/>.
10. XEP-0053: XMPP Registrar Function <https://xmpp.org/extensions/xep-0053.html>.
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
Improve security considerations.
Initial version approved by the council.
END