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

Addressing burner JID ML feedback

This commit is contained in:
Sam Whited 2016-10-29 12:18:48 -05:00
parent 940f640bca
commit 34fc30b2a9
1 changed files with 44 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

69
inbox/burner.xml
View File

@ -8,8 +8,7 @@
<header>
<title>Burner JIDs</title>
<abstract>
A mechanism by which users may request arbitrary anonymizing "burner" JIDs
for short term use.
A mechanism by which users may request anonymous, ephemeral "burner" JIDs.
</abstract>
&LEGALNOTICE;
<number>xxxx</number>
@ -19,6 +18,7 @@
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>RFC 4422</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -38,16 +38,16 @@
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 prevent abuse.
creating a new session, nor does it provide authentication of users.
</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.
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 anonymous to third parties but is (optionally) locally
authenticated.
</p>
</section1>
<section1 topic='Glossary' anchor='glossary'>
@ -56,15 +56,14 @@
<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.
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 shared secret and any
associated burner JIDs or other stored information about the user.
The identity of a user on the server comprising a burner JID and any
other associated data.
</dd>
</di>
<di>
@ -118,10 +117,21 @@
type='result'>
<identity xmlns='urn:xmpp:burner:0'>
<jid>
hfgnINTSA-ciCLz6NhTtCD5Jr0k:1477672278884j@example.net/4db06f06-1ea4-11dc-aca3-000bcd821bfb
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; &sect;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>
@ -147,13 +157,18 @@
<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-256 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.
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>
@ -161,12 +176,8 @@
<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.
SHOULD rate limit all burner JIDs in use by an authentication identity as a
single unit.
</p>
<p>
If TLS channel binding information is encoded in the burner JID it is
@ -177,6 +188,11 @@
resumption does not include enough context to successfully verify the
binding.
</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>
@ -197,7 +213,7 @@
<type>
<name>ephemeral</name>
<desc>
An authorization service that provides ephemeral "burner" identities.
An authorization service that provides ephemeral identities.
</desc>
<doc>XEP-XXXX</doc>
</type>
@ -226,4 +242,7 @@
<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>