Improve security considerations and add listing JIDs.
0.1.12017-01-28ssw
Improve security considerations.
0.12016-12-07XEP Editor: ssw
Initial version approved by the council.
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)XEP-0175: Best Practices for Use of SASL ANONYMOUS <https://xmpp.org/extensions/xep-0175.html>., 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.
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.
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.
Services that support issuing burner JIDs MUST advertise the fact in
responses to Service Discovery (XEP-0030)XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>. "disco#info" requests by returning an identity of
"authz/ephemeral".
…
…]]>
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.
]]>
If the service wishes to issue an ephemeral identity to the user it replies
with a new burner JID:
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 4422RFC 4422: Simple Authentication and Security Layer (SASL) <http://tools.ietf.org/html/rfc4422>. §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 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.
…]]>
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)XEP-0082: XMPP Date and Time Profiles <https://xmpp.org/extensions/xep-0082.html>..
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.
…]]>
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
HMACThe 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>. 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
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.3Channel Bindings for TLS 1.3 <http://tools.ietf.org/html/draft-ietf-kitten-tls-channel-bindings-for-tls13>. be used.
For versions of TLS less than 1.3, tls-unique SHOULD be used as defined
by RFC 5929RFC 5929: Channel Bindings for TLS <http://tools.ietf.org/html/rfc5929>. §3.
Note that unless the master-secret fix from RFC 7627RFC 7627: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension <http://tools.ietf.org/html/rfc7627>. 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)XEP-0300: Use of Cryptographic Hash Functions in XMPP <https://xmpp.org/extensions/xep-0300.html>..
This docment requires no interaction with the the Internet Assigned Numbers Authority (IANA)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/>..
This specification defines the following XML namespace:
urn:xmpp:burner:0
Upon advancement of this specification from a status of Experimental to a
status of Draft, the XMPP RegistrarThe 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/>. 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)XEP-0053: XMPP Registrar Function <https://xmpp.org/extensions/xep-0053.html>..
urn:xmpp:burner:0Support for listing authorization identities and for issuing burner JIDs when paired with an appropriate identity.&xep0383;
]]>
The XMPP RegistrarThe 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/>. 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 RegistrarThe 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/>. shall remove the provisional status from
this registry entry.
urn:xmpp:burner:0&xep0383;provisional
]]>
Upon advancement of this proposal from experimental to draft status the
XMPP RegistrarThe 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/>. 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:
authzServices and nodes that provide authorization identities.ephemeral
An authorization service that provides ephemeral identities.
XEP-0383
]]>
Future submissions to the XMPP Registrar may register additional types.
This specification defines the following XML namespaces:
urn:xmpp:burner:0
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)XEP-0053: XMPP Registrar Function <https://xmpp.org/extensions/xep-0053.html>..
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.
An XML Schema will be added before this document reaches the status of
"draft".
The author wishes to thank Philipp Hancke for his feedback.