xep-0383.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>Experimental</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.2.0</version>
    <date>2021-07-10</date>
    <initials>ssw</initials>
    <remark><p>Improve security considerations and add listing JIDs.</p></remark>
  </revision>
  <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='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='Requesting a JID' 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; &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='Listing JIDs' anchor='listing'>
  <p>
    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.
  </p>
  <example caption='Service responds to disco#info query indicating listing support'><![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='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'/>
    <feature var='urn:xmpp:burner:0'/>
    …]]></example>
  <p>
    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.
  </p>
  <p>
    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 &xep0082;.
    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.
  </p>
  <example caption='Service responds to disco#items query'><![CDATA[
<iq type='result'
    from='muc.example.net'
    to='caiusmarcius@example.net/corioli'
    id='k3hs5174'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='burner1@muc.example.net'/>
    <item jid='burner2@muc.example.net'/>
    <item jid='burner3@muc.example.net' expires='1969-07-21T02:56:15Z'/>
    …]]></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
    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.
  </p>
  <p>
    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 &cbtls13; be used.
    For versions of TLS less than 1.3, tls-unique SHOULD be used as defined
    by &rfc5929; &sect;3.
    Note that unless the master-secret fix from &rfc7627; has been implemented
    tls-unique 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='Protocol Namespaces' anchor='registrar-ns'>
    <p>This specification defines the following XML namespace:</p>
    <ul>
      <li>urn:xmpp:burner:0</li>
    </ul>
    <p>
      Upon advancement of this specification from a status of Experimental to a
      status of Draft, the &REGISTRAR; shall add the foregoing namespace to the
      registry located at &DISCOFEATURES; as described in Section 4 of
      &xep0053;.
    </p>
    <code caption='Service Discovery Features Registry Submission'><![CDATA[
<var>
  <name>urn:xmpp:burner:0</name>
  <desc>Support for listing authorization identities and for issuing burner JIDs when paired with an appropriate identity.</desc>
  <doc>&xep0383;</doc>
</var>]]></code>
    <p>
      The &REGISTRAR; shall also add the foregoing namespace to the Jabber/XMPP
      Protocol Namespaces Registry located at &NAMESPACES;.
      Upon advancement of this specification from a status of Experimental to a
      status of Draft, the &REGISTRAR; shall remove the provisional status from
      this registry entry.
    </p>
    <code caption='Jabber/XMPP Protocol Namespaces Registry Submission'><![CDATA[
<ns>
  <name>urn:xmpp:burner:0</name>
  <doc>&xep0383;</doc>
  <status>provisional</status>
</ns>]]></code>
  </section2>
  <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 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>
    An XML Schema will be added before this document reaches the status of
    "draft".
  </p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
  <p>The author wishes to thank Philipp Hancke for his feedback.</p>
</section1>
</xep>