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

ProtoXEP: XMPP over RELOAD 

IPR statement was confirmed via email to editor@.
This commit is contained in:
Jonas Schäfer 2019-02-04 20:16:09 +01:00
parent b28208e3aa
commit c8e9cebc6b
1 changed files with 244 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

244
inbox/xor.xml Normal file
View File

@ -0,0 +1,244 @@
<?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>XMPP Over RELOAD (XOR)</title>
<abstract>This specification defines an XMPP Usage of REsource LOcation And Discovery (RELOAD). The XMPP usage provides an ability for XMPP clients to discover other peers' location through the peer-to-peer overlay. Once a peer location is determined, the RELOAD AppAttach method is used to establish a direct connection between peers through which XMPP streams are exchanged.</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0001</spec>
<spec>RFC 6940</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<author>
<firstname>Evgeny</firstname>
<surname>Khramtsov</surname>
<email>ekhramtsov@process-one.net</email>
<jid>xram@zinid.ru</jid>
</author>
<revision>
<version>0.0.1</version>
<date>2019-02-04</date>
<initials>evk</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>REsource LOcation And Discovery (RELOAD) [RFC6940] specifies a peer-to-peer (P2P) signaling protocol for general use on the Internet. This document defines an XMPP Usage of RELOAD that allows XMPP clients to establish peer-to-peer XMPP streams without routing them through XMPP servers. The document also suggests a possible way for managing distributed certficate authorities (CA) issuing X.509 certficates for XMPP accounts in the "Jabber" network.</p>
<p>The XMPP Usage involves two basic functions:</p>
<ol>
<li><strong>Address Location</strong>: XMPP clients can use the RELOAD data storage functionality to store a mapping from their XMPP address to their Node-ID in the overlay and to retrieve the Node-ID of other clients.</li>
<li><strong>Rendezvous</strong>: Once an XMPP client has identified the Node-ID for an XMPP address it wishes to contact, it can use the RELOAD message routing system to set up a direct connection for exchanging XMPP streams.</li>
</ol>
<p>Mappings are stored in the XmppLocation Resource Record defined in this document. All operations required to perform an XMPP address location or rendezvous are standard RELOAD protocol methods.</p>
<p class='box'>Note: XMPP stanzas are not routed through the overlay and are not stored therein.</p>
<p>For example, Romeo registers location of his XMPP address, "romeo@montague.lit", for his Node-ID "1234". When Juliet wants to contact Romeo, she queries the overlay for "romeo@montague.lit" and receives Node-ID "1234" in return. She then uses the overlay routing to establish a direct connection with Romeo and can directly start a standard XMPP stream. In detail, this works along the following steps:</p>
<code><![CDATA[
Overlay
Juliet Peer1 ... PeerN Romeo
(5678) (1234)
-------------------------------------------------
AppAttach ->
AppAttach ->
AppAttach ->
AppAttach ->
<- AppAttach
<- AppAttach
<- AppAttach
<- AppAttach
<------------------ ICE Checks ----------------->
---------------- XMPP stream start ------------->
<--------------- XMPP stream start --------------
...
---------------- XMPP stream end --------------->
<--------------- XMPP stream end ----------------
]]></code>
<p>Direct XMPP streams exchange will be documented in follow-up extensions. So far, a possible way is described in &xep0174;, although this method interacts badly with the ordinary XMPP client-to-server connection and message replication accross user devices.</p>
<p>It is important to note that the XMPP Usage of RELOAD is not intended to replace the existing XMPP servers infrastructure as it currently looks unrealistic. Instead, the overlay connection is designed to be working along with the ordinary XMPP client-to-server connection in order to provide backward compatibility and reliable offline message delivery. However, some clients MAY decide to maintain the overlay connection only. As an example, such scenario is possible in the video game industry where all clients are stationary (e.g. desktop) clients with persistent broadband Internet connection, without battery restrictions and no need to receive offline messages.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>TBD</p>
</section1>
<section1 topic='Glossary' anchor='glossary'>
<dl>
<di><dt>RELOAD</dt><dd>REsource LOcation And Discovery [RFC6940] - a P2P signaling protocol for general use on the Internet. The terminology and definitions from this protocol are used extensively in this document.</dd></di>
<di><dt>Address Location</dt><dd>One or many RELOAD Node-IDs to which a peer-to-peer connection can be established in order to contact an owner of the XMPP address.</dd></di>
</dl>
</section1>
<section1 topic='Storing an Address Location' anchor='addr-loc'>
<section2 topic='Overview' anchor='addr-loc-overview'>
<p>In XMPP Core &rfc6120;, a client fully relies on servers for its XMPP address location. In XMPP Usage of RELOAD, this location function is provided by the overlay as a whole. To register its location, a RELOAD peer stores an XmppLocation Resource Record for its own XMPP address using the XMPP-LOCATION Kind, which is formally defined below. Note that if a client wishes to set the location lifetime it MUST use lifetime of the basic RELOAD StoredData structure (see Section 7 in [RFC6940]).</p>
<p>As a simple example, consider Juliet with an XMPP address "juliet@capulet.lit" at Node-ID "1234". She might store the mapping "juliet@capulet.lit -> 1234" telling anyone who wants to contact her to establish a direct XMPP stream with node "1234".</p>
<p>RELOAD peers can store two kinds of XMPP mappings,</p>
<ul>
<li>from an XMPP address to a destination list (a single Node-ID is just a trivial destination list), or</li>
<li>from one XMPP address to another.</li>
</ul>
<p>The meaning of the first kind of mapping is "in order to contact me, form a connection with this Peer". The meaning of the second kind of mapping is "in order to contact me, dereference this XMPP address". The latter allows for forwarding. For instance, if Juliet wants her messages to be forwarded to Romeo, she might insert the following mapping: "juliet@capulet.lit -> romeo@montague.lit".</p>
</section2>
<section2 topic='Data Structure' anchor='data-struct'>
<p>The XmppLocation Resource Record is defined as follows:</p>
<code><![CDATA[
enum {
xmpp_location_address(1),
xmpp_location_route(2),
(255)
} XmppLocationType;
select (XmppLocation.type) {
case xmpp_location_address:
opaque address<0..2^16-1>;
case xmpp_location_route:
uint8 priority;
Destination destination_list<0..2^16-1>;
/* This type can be extended */
} XmppLocationData;
struct {
XmppLocationType type;
uint16 length;
XmppLocationData data;
} XmppLocation;
]]></code>
<p>The contents of the XmppLocation Resource Record are:</p>
<dl>
<di><dt>type</dt><dd>the type of the location</dd></di>
<di><dt>length</dt><dd>the length of the rest of the PDU</dd></di>
<di><dt>data</dt><dd>the location data</dd></di>
</dl>
<ul>
<li>If the location is of type "xmpp_location_address", then the contents are an opaque string containing the XMPP address. The address MUST be bare (i.e. without a resource part) and MUST be prepared for comparison using PRECIS rules from &rfc7622;.</li>
<li>If the location is of type "xmpp_location_route", then the contents are an integer representing a route priority and an opaque string containing a destination list for the Peer. The meaning of a priority is described below in this document.</li>
</ul>
</section2>
<section2 topic='Multiple Locations' anchor='multi-loc'>
<p>The XMPP Usage explicitly supports multiple locations for a single XMPP address. The locations are stored in a dictionary with Node-IDs as the dictionary keys. Consider, for instance, the case where Juliet has two Peers:</p>
<ul>
<li>her desktop client (1234)</li>
<li>her cell phone (5678)</li>
</ul>
<p>Juliet might store the following in the overlay at resource "juliet@capulet.lit":</p>
<ul>
<li>an XmppLocation of type "xmpp_location_route" with dictionary key "1234" and value "1234", both referring to Node-IDs</li>
<li>an XmppLocation of type "xmpp_location_route" with dictionary key "5678" and value "5678"</li>
</ul>
</section2>
<section2 topic='Access Control' anchor='access-control'>
<p>In order to prevent hijacking or other misuse, locations are subject to access control rules. Two kinds of restrictions apply:</p>
<ul>
<li>A Store is permitted for the owner of this XMPP address, e.g. its certificate is signed by the trusted CA.</li>
<li>Storing requests are performed according to the USER-NODE-MATCH access control policy of RELOAD.</li>
</ul>
<p>Before a Store is permitted, the Storing Peer MUST check that:</p>
<ul>
<li>The XMPP address of the request is a valid Resource Name, e.g. the corresponding certificate is signed by the trusted CA.</li>
<li>The certificate contains a username that is an XMPP address that hashes to the Resource-ID it is being stored at.</li>
<li>The certificate contains a Node-ID that is the same as the dictionary key it is being stored at.</li>
</ul>
<p>If any of these checks fail, the request MUST be rejected with an Error_Forbidden error.</p>
<p>The Storing Peer MUST NOT apply the PRECIS profile to any XMPP addresses. It is the responsibility of the Peer issuing the Store request. This allows to join XMPP agnostic RELOAD nodes to the overlay and protects intermediate peers from excessive computations, as well as possible bugs related to XMPP addresses comparison.</p>
<!-- <p>Note that these rules permit Juliet to forward messages to Romeo without his permission. However, they do not permit Juliet to forward Romeo's messages to her. See Section ??? for additional details.</p> -->
</section2>
</section1>
<section1 topic='Looking Up an Address Location'>
<p>In order to locate a peer in the current overlay, a RELOAD Peer MUST execute the following steps:</p>
<ol>
<li>MUST remove the resource part of the XMPP address and prepare it for comparison using PRECIS rules defined in &rfc7622;.</li>
<li>MUST perform a Fetch for Kind XMPP-LOCATION at the Resource-ID corresponding to this prepared bare XMPP address. This Fetch SHOULD NOT indicate any dictionary keys, so that it will fetch all the stored values.</li>
<li>MUST remove duplicate destination lists and MUST initiate direct connections to all Peers as described in the following sections. It is RECOMMENDED to perform connection attempts in parallel. If the Peer chooses sequential connection attemps, it is RECOMMENDED to sort the destination lists by priority in ascending order and perform the attempts in this order (i.e. from the destination list with the smallest priority to the biggest, assuming standard integer comparison).</li>
</ol>
</section1>
<section1 topic='Forming a Direct Connection' anchor='direct-conn'>
<section2 topic='Setting Up a Connection' anchor='conn-setup'>
<p>Once the Peer has translated the XMPP address into a set of destination lists, it then uses the overlay to route AppAttach messages to each of those Peers. The "application" field of AppAttach message MUST be 5222. The responding Peer MUST present a certificate with a Node-ID matching the terminal entry in the destination list. Otherwise, the connection MUST NOT be used and MUST be closed.</p>
<p>Once the AppAttach succeeds, the Peer MUST start TLS-encrypted XMPP connection. A STARTTLS procedure MUST NOT be used.</p>
<p>A peer (device) of an XMPP user at any time MAY close connections to some peers (devices) of another user while keeping the rest of connections to this user's peers opened. However, only connections corresponding to the destination lists with higher priorities (biggest integer values) MUST be considered for closing as redundant.</p>
<p>At startup, the peer MUST establish connections to all its user's peers. The Peer MUST strive to maintain connections to all its user's peers. It MUST NOT voluntary close some of them.</p>
</section2>
<section2 topic='Stanza Routing' anchor='stanza-routing'>
<p>A stanza to an XMPP user MUST be sent to all connected peers (devices) of this user. Upon reception of a stanza, the peer MUST forward it to all its user's peers. An XMPP peer MUST be prepared to deal with duplicates and forwards. The follow-up extensions are supposed to clarify this.</p>
</section2>
</section1>
<section1 topic='Interaction with XMPP Core' anchor='c2s-interact'>
<p>The XMPP Usage of RELOAD is designed to work along with standard XMPP client-to-server (C2S) connection defined in &rfc6120;. Depending on the user preferences or application usage, a peer MAY treat either C2S or RELOAD connection as primary. If the C2S connection is primary, the Peer MAY use the overlay in the case when its XMPP server is unavailable. If the RELOAD connection is considered as primary, a client MAY use the C2S connection to send stanzas when it has failed to locate the destination XMPP address in the overlay or when all connection attempts to the destination peer have failed.</p>
</section1>
<section1 topic='Authentication' anchor='auth'>
<p class='box'>TODO: This section suggests some XSF actions and most likely should be moved into a separate document. The section is also far from completeness and basically only introduces some ideas.</p>
<p>Sybil attacks are the major threat of any peer-to-peer system. A successful Sybil attack may degrade or completely paralyze the overlay. It is asserted that under realistic assumptions, without a logically centralized authority, Sybil attacks are always possible in peer-to-peer systems [J. Douceur, 2002]. To address this, the RELOAD specification relies on certificate-based authentication with a central authority. The authority's ability to ensure attackers cannot get a large number of certificates for the overlay is one of the cornerstones of RELOAD's security.</p>
<p>This section suggests how this authority can be built within existing network of XMPP servers (so called "Jabber" network). In order to create an isolated XMPP overlay the reader is suggested to follow the approach described in the RELOAD document itself.</p>
<section2 topic='Enrollment' anchor='enrollment'>
<p>RELOAD suggests an existence of a central enrollment server which a joining peer contacts in order to retrive the Overlay Configuration document. The document defines root certificates, bootstrapping nodes, mandatory extensions and so on. The enrollment server is suggested to be maintained by the XSF. Since this is a matter of maintaining of an HTTP server holding a single static file, the operational costs are expected to be low.</p>
</section2>
<section2 topic='Certificate Authority' anchor='ca'>
<p>The root certificate of the overlay MUST be created by the XSF. All intermediate authority's certificates MUST be signed by this root certficate.</p>
<p>A server operator who wishes to run the RELOAD node (either separately or along with an XMPP server) and who also wants to issue X.509 certificates to the XMPP accounts of the domain being managed (and thus, becoming an "intermediate" CA), MUST create a certificate request and ask the XSF to sign it using the root certificate of the overlay. This operation will typically require some effort from the XSF. This is because signing a certificate of a server operator who doesn't control account creation (or even creates them massively on purpose) may lead to a Sybil attack on the overlay. The XSF should be extremely careful in this regard.</p>
<p>The XSF takes responsibility on revocation of any intermediate certificate. The rules for this MUST be very clear. Since the idea of the XSF central authority is to protect the overlay from Sybil attacks, the only reason for revocation SHOULD be massive account creation by the intermediate authority in question. The XSF MUST NOT perform any kind of censorship.</p>
<p>The XSF maintains a list of "bad nodes" in the Overlay Configuration document. It's not very easy to define the "bad" behaviour of a node. As a rule of thumb the peer is considered for a ban if it exploits vulnerabilites of other peers of the overlay, especially when the vulnerability may lead to significant degradation of the overlay.</p>
</section2>
</section1>
<section1 topic='XMPP-LOCATION Kind Definition' anchor='kind-def'>
<p>This section defines the XMPP-LOCATION Kind.</p>
<dl>
<di><dt>Name</dt><dd>XMPP-LOCATION</dd></di>
<di><dt>Kind IDs</dt><dd>The Resource Name for the XMPP-LOCATION Kind-ID is the bare XMPP address of the user prepared for comparison using PRECIS. The data stored is an XmppLocation, which can contain either another XMPP address or a destination list to the Peer that is acting for the user.</dd></di>
<di><dt>Data Model</dt><dd>The data model for the XMPP-LOCATION Kind-ID is a dictionary. The dictionary key is the Node-ID of the Storing Peer. This allows each Peer (presumably corresponding to a single device) to store a single route mapping.</dd></di>
<di><dt>Access Control</dt><dd>USER-NODE-MATCH. Note that this matches the XMPP address against the "id-on-xmppAddr" Object Identifier (as defined in &rfc6120;) in the X.509 v3 certificate.</dd></di>
</dl>
<p>Data stored under the XMPP-LOCATION Kind is of type XmppLocation, containing one of two data types:</p>
<dl>
<di><dt>xmpp_location_address</dt><dd>An XMPP address that the user can be reached at.</dd></di>
<di><dt>xmpp_location_route</dt><dd>A destination list that can be used to reach the user's Peer.</dd></di>
</dl>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<section2 topic='RELOAD Security' anchor='reload-security'>
<p>This Usage for RELOAD does not define new protocol elements or operations. Hence, no new threats arrive from message exchanges in RELOAD.</p>
</section2>
<section2 topic='SPAM' anchor='spam'>
<p>Successful SPAM dissemination is possible as long as the malicious entity is able to create a lot of accounts in the overlay. In other words, SPAM is a derivative of a Sybil attack. Since the overlay is designed to be Sybil resistant, SPAM is expected to be negligible.</p>
</section2>
<section2 topic='Accounts Harvesting' anchor='acc-harvesting'>
<p>TBD</p>
</section2>
<section2 topic='Network Address Disclosure' anchor='net-addr-disclosure'>
<p>TBD</p>
</section2>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<section2 topic='Data Kind-ID' anchor='data-kind-id'>
<p>The specification introduces the following code point in the "RELOAD Data Kind-ID" Registry (cf., [RFC6940]) to represent the XMPP-LOCATION Kind:</p>
<table caption='Code Points'>
<tr>
<th>Kind</th>
<th>Kind-ID</th>
<th>Reference</th>
</tr>
<tr>
<td>XMPP-LOCATION</td>
<td>0x5</td>
<td>XEP-XXXX</td>
</tr>
</table>
</section2>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document defines no new XMPP namespaces.</p>
</section1>
</xep>