moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

Add initial draft of burner JID xep to inbox

This commit is contained in:
Sam Whited 2016-10-28 12:44:44 -05:00
parent 7ba53e8bcd
commit 56f5782544
1 changed files with 242 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

242
inbox/burner.xml Normal file
View File

@ -0,0 +1,242 @@
<?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 arbitrary anonymizing "burner" JIDs
for short term use.
</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
&sam;
<revision>
<version>0.0.1</version>
<date>2016-10-28</date>
<initials>ssw</initials>
<remark><p>First draft.</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, ANONYMOUS auth
provides no mechanism for changing identities (requesting a new JID) without
creating a new session, and server operators may not wish to allow anonymous
authentication to prvent abuse.
</p>
<p>
This specification solves these problems by decoupling anonymous identity
management from authentication.
This allows logged in users (anonymous or otherwise at the server operators
disgression) to request a new temporary identifier, a "burner" JID, which
may be used by its owner in any context where they would normally use their
persistent primary JID.
</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<ul>
<li>
A server or service is able to issue a unique ephemeral identity to a user
that supplies the server or service with a public key.
</li>
<li>
A user is able to generate any number of burner JIDs from using their
private key which can be verified against their ephemeral identity on the
server.
</li>
</ul>
</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 used in place of the authentication identity in a
pre-authenticated session.
</dd>
</di>
<di>
<dt>Ephemeral identity</dt>
<dd>
The identity of a user on the server comprising a shared secret and any
associated burner JIDs or other stored information about the user.
</dd>
</di>
<di>
<dt>Authentication identity</dt>
<dd>
The users normal identity and JID which they use to autenticate 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/4db06f06-1ea4-11dc-aca3-000bcd821bfb
</jid>
</identity>
</iq>]]></example>
</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
"":
</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 category='conference' type='text'/>
<identity category='authz' type='ephemeral'/>
…
<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 it is RECOMMENDED that the localpart of a burner JID be an
HMAC-SHA-2 which includes the users JID or another unique identifier, an
expiration or issued time for the burner JID if appropriate, TLS channel
binding information, session information, or any other data 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.
</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>
To prevent burner JIDs from being abused for spamming, implementations
SHOULD rate limit all burner JIDs in use by a given authentication identity
as a single unit.
</p>
<p>
When a users session ends it is RECOMMENDED that any ephemeral identities
associated with their session be purged.
</p>
<p>
If TLS channel binding information is encoded in the burner JID it is
RECOMMENDED that the tls-unique channel binding value be used as defined by
&rfc5929; &sect;3.
However, for resumed sessions the JIDs SHOULD be considered invalid unless
the master-secret fix from &rfc7627; has been implemented because otherwise
resumption does not include enough context to successfully verify the
binding.
</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
&REGISTRAR; 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 "burner" identities.
</desc>
<doc>XEP-XXXX</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>
</xep>