mirror of
https://github.com/moparisthebest/xeps
synced 2024-10-31 15:35:07 -04:00
259 lines
9.4 KiB
XML
259 lines
9.4 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Burner JIDs</title>
|
|
<abstract>
|
|
A mechanism by which users may request anonymous, ephemeral "burner" JIDs.
|
|
</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0383</number>
|
|
<status>Deferred</status>
|
|
<type>Standards Track</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
<spec>RFC 4422</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>burner</shortname>
|
|
&sam;
|
|
<revision>
|
|
<version>0.1.1</version>
|
|
<date>2017-01-28</date>
|
|
<initials>ssw</initials>
|
|
<remark><p>Improve security considerations.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1</version>
|
|
<date>2016-12-07</date>
|
|
<initials>XEP Editor: ssw</initials>
|
|
<remark><p>Initial version approved by the council.</p></remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<p>
|
|
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 &xep0175;, however, the ANONYMOUS
|
|
mechanism is in reality an authorization mechanism and does not provide
|
|
authentication of users.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Glossary' anchor='glossary'>
|
|
<dl>
|
|
<di>
|
|
<dt>Burner JID</dt>
|
|
<dd>
|
|
A temporary JID that is not valid for the purpose of authentication but
|
|
which may be authorized by an existing pre-authenticated session.
|
|
</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Ephemeral identity</dt>
|
|
<dd>
|
|
The identity of a user on the server comprising a burner JID and any
|
|
other associated data.
|
|
</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Authentication identity</dt>
|
|
<dd>
|
|
The users normal identity and JID which they use to authenticate with
|
|
the server and create new XMPP sessions.
|
|
</dd>
|
|
</di>
|
|
</dl>
|
|
</section1>
|
|
<section1 topic='Use Cases' anchor='usecases'>
|
|
<ul>
|
|
<li>
|
|
As a user concerned about spam I want to join a public chat room
|
|
anonymously to prevent JID harvesting.
|
|
</li>
|
|
<li>
|
|
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.
|
|
</li>
|
|
<li>
|
|
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.
|
|
</li>
|
|
</ul>
|
|
</section1>
|
|
<section1 topic='Business Rules' anchor='rules'>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<example caption='User requests ephemeral identity'><![CDATA[
|
|
<iq from='caiusmarcius@example.net/corioli'
|
|
id='h7ns81g'
|
|
to='example.net'
|
|
type='get'>
|
|
<identity xmlns='urn:xmpp:burner:0'/>
|
|
</iq>]]></example>
|
|
<p>
|
|
If the service wishes to issue an ephemeral identity to the user it replies
|
|
with a new burner JID:
|
|
</p>
|
|
<example caption='Server issues burner JID'><![CDATA[
|
|
<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>]]></example>
|
|
<p>
|
|
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 &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.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Determining Support' anchor='support'>
|
|
<p>
|
|
Services that support issuing burner JIDs MUST advertise the fact in
|
|
responses to &xep0030; "disco#info" requests by returning an identity of
|
|
"authz/ephemeral":
|
|
</p>
|
|
<example caption='Service responds to disco#info query'><![CDATA[
|
|
<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'/>
|
|
…]]></example>
|
|
</section1>
|
|
<section1 topic='Implementation Notes' anchor='impl'>
|
|
<p>
|
|
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
|
|
&nistfips198-1; 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.
|
|
</p>
|
|
<p>
|
|
As with persistent JIDs, the client MUST NOT assign any meaning to the
|
|
localpart or resourcepart of a burner JID.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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 &rfc5929; §3.
|
|
Note that unless the master-secret fix from &rfc7627; has been implemented
|
|
channel binding information does not include enough context to successfully
|
|
verify the binding when resuming a TLS session.
|
|
</p>
|
|
<p>
|
|
Implementations that choose to encode information in the localpart of burner
|
|
JIDs should take care when choosing a hash function.
|
|
For current recommendations see &xep0300;.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>This docment requires no interaction with the &IANA;.</p>
|
|
</section1>
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
<section2 topic='Service Discovery Category/Type' anchor='registrar-disco'>
|
|
<p>
|
|
Upon advancement of this proposal from experimental to draft status the
|
|
®ISTRAR; will include a category of "authz" in its registry at
|
|
&DISCOCATEGORIES;.
|
|
The registrar will also add a value of "ephemeral" to that category.
|
|
The registry submission is as follows:
|
|
</p>
|
|
<code><![CDATA[
|
|
<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>
|
|
]]></code>
|
|
<p>
|
|
Future submissions to the XMPP Registrar may register additional types.
|
|
</p>
|
|
</section2>
|
|
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
|
|
<p>This specification defines the following XML namespaces:</p>
|
|
<ul>
|
|
<li>urn:xmpp:burner:0</li>
|
|
</ul>
|
|
<p>
|
|
Upon advancement of this proposal from experimental to draft status the
|
|
registrar will include the foregoing namespaces in its registry at
|
|
&NAMESPACES; as governed by &xep0053;.
|
|
</p>
|
|
<p></p>
|
|
</section2>
|
|
<section2 topic='Namespace Versioning' anchor='registrar-versioning'>
|
|
&NSVER;
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='XML Schema' anchor='schema'>
|
|
<p>TODO.</p>
|
|
</section1>
|
|
<section1 topic='Acknowledgements' anchor='ack'>
|
|
<p>The author wishes to thank Philipp Hancke for his feedback.</p>
|
|
</section1>
|
|
</xep>
|