One document matched: draft-paasch-mptcp-application-authentication-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- Convert to HTML and Text with xml2rfc: http://xml2rfc.ietf.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY MPTCP SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mptcp-rfc6824bis-05">
<!ENTITY LOADB SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-paasch-mptcp-loadbalancer-00">
<!ENTITY RFC0793 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc rfcedstyle="yes"?>
<rfc category="exp" docName="draft-paasch-mptcp-application-authentication-00" ipr="trust200902">
<front>
<title abbrev="MPTCP Application Layer Auth">Application Layer Authentication for MPTCP</title>
<author fullname="Christoph Paasch" initials="C." surname="Paasch">
<organization abbrev="Apple, Inc.">Apple, Inc.</organization>
<address>
<postal>
<street></street>
<city>Cupertino</city>
<country>US</country>
</postal>
<email>cpaasch@apple.com</email>
</address>
</author>
<author fullname="Alan Ford" initials="A." surname="Ford">
<organization>Pexip</organization>
<address>
<!-- <postal>
<street>Beech Court</street>
<city>Hurst</city>
<region>Berkshire</region>
<code>RG10 0RQ</code>
<country>UK</country>
</postal> -->
<email>alan.ford@gmail.com</email>
</address>
</author>
<date year="2016" />
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>mptcp authentication</keyword>
<abstract>
<t>Multipath TCP (MPTCP), described in <xref target="I-D.ietf-mptcp-rfc6824bis"/>, is an extension to TCP to provide the ability to simultaneously use multiple paths between hosts.</t>
<t>MPTCP currently specifies a single authentication mechanism, using keys that are initially exchanged in the clear. There are application-layer protocols that may have better information as to the identity of the parties and so is able to better provide keying material that could be used for the authentication of future subflows.</t>
<t>This document specifies "application layer authentication" for Multipath TCP, an alternatively negotiated keying mechanism for MPTCP.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="sec_intro">
<t>The MPTCP handshake serves multiple purposes. First, hosts discover their peer's
support of MPTCP. Second, each host announces a key that will be tied to this
MPTCP session. The key also serves multiple purposes. First, the derivate
of the key is being used as a token-identifier for the MPTCP connection. This
derivate is a truncated hash of the key. Second, another truncated hash of the
key serves as the initial data sequence number. And third, the key itself is used
as an authenticator to prove that the host behind the IP-address used to
establish new subflows is indeed the one that participated in the handshake of
the initial subflow.</t>
<t>In the following we explain the shortcomings of this exchange and how
they impact the deployment of MPTCP.</t>
<section title="Key in plaintext">
<t>The key-exchange happens during the handshake of the initial subflow. RFC 6824
specifies that this exchange happens in plaintext. As has been noted in RFC 7430,
an eavesdropper on the initial handshake is thus able to learn the keys used in
this MPTCP session. This allows him to generate the session's tokens and data
sequence numbers, enabling him to effectively hijack the MPTCP session by creating
a subflow with a different IP-address. The attacker will be able to generate a
valid HMAC as he has full knowledge of the keys of this MPTCP session.</t>
<t>To enhance MPTCP's security, it would be beneficial to not reveal MPTCP's keys
in plaintext on the wire.</t>
</section>
<section title="Token generation">
<t>The token is a truncation of the 32 most significant bits of the SHA-1 of the key.
The key must be a random number of sufficient entropy to be used as part of
the authentication mechanism, and thus a host has no control over the token as
it is generating the key for the MPTCP-session. This has some implications
on the deployability of MPTCP, outlined hereafter.</t>
<section title="Hash collision">
<t>Due to the nature of the token-generation, the 32-bit token might collide with
another already existing MPTCP session. While a 32-bit token collision should be
very rare on client devices, a busy server (with potentially tens of millions
of active MPTCP connections) will have a very high probability of a token collision.</t>
<t>Upon such a collision, the server needs to generate a new cryptographically secure
64-bit key, and derive the token through a SHA-1 computation upon which he finally
can verify the uniqueness of the token. If a collision happened again, the server
has to start anew. This process imposes a computation overhead and complexity
upon the server and impacts the scalability compared to regular TCP.
Allowing a server to generate a token in such a way that uniqueness can be achieved
easily would be beneficial for the scalability and deployment of MPTCP.</t>
</section>
<section title="Derive information from the token">
<t>As the token is a truncated hash of the key, it is entirely of a random nature.
As has been shown in <xref target="I-D.paasch-mptcp-loadbalancer"/>, this brings several
deployment challenges in large server farms. In particular, the layer-4 load balancers
in front of this server farm need to maintain MPTCP-specific state in order
to map a token to the server.</t>
<t>The token can be looked at as a route-identifier, as it allows the server to
associate the incoming SYN+MP_JOIN with an existing MPTCP-session. However, the
random nature of the token does not allow a load balancer in the middle to
do the same without having to maintain MPTCP-specific state.</t>
<t>If the token can be generated in such a way that it carries the required routing
information in such a way that it can be deciphered by all the trusted parties
in the server farm deployment, large-scale deployment of MPTCP would be simplified.</t>
<t>In the following we suggest an alternative handshake that allows MPTCP to increase
its security by leveraging an external key-exchange and thus benefit from
the security provided by protocols like TLS. As a side-effect of this approach,
the token also can be exchanged in a more flexible way, addressing the above identified
issues with the token generation.</t>
</section>
</section>
</section>
<section title="Proposed Technical Changes" anchor="sec_protocol">
<section title="MP_CAPABLE Changes" anchor="sec_capable">
<t>To resolve the issues identified in the previous section, this proposal separates the key handling for security (i.e. the method for protecting new subflow exchanges) from the token exchange. This means that:
<list style="symbols">
<t>Key exchange is handled in the application layer</t>
<t>Meaning can be exchanged in the token, and a custom generation method can be used, as it is decoupled from keying material</t>
</list>
This specification allocates the 'G' bit from the flags of MP_CAPABLE as an alternative security mechanism - "handled by application layer". In this case, the MP_CAPABLE exchange will send and receive tokens rather than keys.</t>
<t>When the 'G' bit is set to 1, this implies support for this new mechanism, and the MP_CAPABLE exchange will operate as follows. The tokens take the place of the keys in the MP_CAPABLE exchange, but otherwise the exchange remains very similar. This exchange still maintains support for stateless servers. Note that this now means that tokens are 64 bits in length.</t>
<?rfc needLines='10'?>
<figure align="center" anchor="tcpm_capable" title="Proposed Multipath Capable (MP_CAPABLE) Option">
<artwork align="left"><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-------+---------------+
| Kind | Length |Subtype|Version|A|B|C|D|E|F|G|H|
+---------------+---------------+-------+-------+---------------+
| Option Sender's Token (64 bits) |
| (if option Length > 4) |
| |
+---------------------------------------------------------------+
| Option Receiver's Token (64 bits) |
| (if option Length > 12) |
| |
+-------------------------------+-------------------------------+
| Data-Level Length (16 bits) | Checksum (16 bits, optional) |
+-------------------------------+-------------------------------+
]]></artwork>
</figure>
<t>The MP_CAPABLE option is carried on the SYN, SYN/ACK, and ACK packets that start the first subflow of an MPTCP connection, as well as the first packet that carries data, if the initiator wishes to send first. The data carried by each option is as follows, where A = initiator and B = listener.
<list style="symbols">
<t>SYN (A->B): only the first four octets (Length = 4).</t>
<t>SYN/ACK (B->A): B's token for this connection (Length = 12).</t>
<t>ACK (no data) (A->B): A's token followed by B's token (Length = 20).</t>
<t>ACK (with first data) (A->B): A's key followed by B's key followed by Data-Level Length, and optional Checksum (Length = 22 or 24).</t>
</list>
The contents of the option is determined by the SYN and ACK flags of the packet, along with the option's length field. For the diagram shown in <xref target="tcpm_capable"/>, "sender" and "receiver" refer to the sender or receiver of the TCP packet (which can be either host).</t>
<t>If the sender of the initial SYN supports both SHA-1 (as specified in <xref target="I-D.ietf-mptcp-rfc6824bis"/>) and application-layer, it can set both G and H bits to "1". The sender of the SYN/ACK can then make a decision as to which mode to support, and selects only one of those bits in the SYN/ACK.</t>
</section>
<section title="MP_JOIN Changes" anchor="sec_join">
<t>The MP_JOIN exchange remains almost the same:</t>
<?rfc needLines='24'?>
<figure align="center" anchor="fig_tokens" title="Example Use of MP_JOIN">
<artwork align="left"><![CDATA[
Host A Host B
------------------------ ----------
Address A1 Address A2 Address B1
---------- ---------- ----------
| | |
| | SYN + MP_JOIN(Token-B, R-A) |
| |------------------------------->|
| |<-------------------------------|
| | SYN/ACK + MP_JOIN(HMAC-B, R-B) |
| | |
| | ACK + MP_JOIN(HMAC-A) |
| |------------------------------->|
| |<-------------------------------|
| | ACK |
HMAC-A = HMAC(Key=(Key-A+Key-B), Msg=(R-A+R-B))
HMAC-B = HMAC(Key=(Key-B+Key-A), Msg=(R-B+R-A))
]]></artwork>
</figure>
<t>However, the token presented is now 64 bits. The key used in the HMAC exchange here is provided by the application layer. Otherwise, there are no other changes to the handshake. Note, however, that an MP_JOIN message cannot be sent until the application layer protocol has determined that the key exchange has completed.</t>
<t>Depending on the key-exchange protocol that is in use at the application layer, it may be that the client already knows the key, while the server is not yet aware of it. In that case the server might receive SYN+MP_JOIN with a valid token, but the MPTCP-state on the server has not yet been populated with the key. The server must silently drop in that case the SYN+MP_JOIN. The client will retransmit its SYN+MP_JOIN and eventually the application on the server will have populated the MPTCP-state with the key.
</t>
</section>
<section title="Data Sequence Number Changes" anchor="sec_dsn">
<t>The Initial Data Sequence Number for each host involved in an MPTCP connection is, by <xref target="I-D.ietf-mptcp-rfc6824bis"/>, derived from the SHA-1 hash of the key. If application-layer authentication is selected, the IDSN MUST instead be derived from the most-significant 64 bits of the SHA-1 hash of the token.</t>
</section>
<section title="MP_FASTCLOSE Changes" anchor="sec_fastclose">
<t>MP_FASTCLOSE is the other method that uses the key in <xref target="I-D.ietf-mptcp-rfc6824bis"/>. Given there is no knowledge as to a potential key's sensitivity, it can no longer be said that a key should be sent here. Instead, a truncation of the 64 most-significant bits of the SHA-1 hash <xref target="sha1"/> of the key should be used.</t>
</section>
</section>
<section title="Security Considerations" anchor="sec_security">
<t>This draft is proposing a mechanism that would allow an application-layer protocol to provide security, rather than relying on a cleartext exchange of the keys. As such, this document itself does not introduce any additional security concerns, but provides a mechanism by which additional security could be added to the MPTCP handshake, depending on the authentication method used at the application layer.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document would update the "MPTCP Handshake Algorithms" sub-registry under the "Transmission Control Protocol (TCP) Parameters" registry, based on the flags in MP_CAPABLE, to add the following algorithm:</t>
<texttable anchor="table_crypto" title="MPTCP Handshake Algorithms">
<ttcol align="center">Flag Bit</ttcol>
<ttcol align="center">Meaning</ttcol>
<ttcol align="center">Reference</ttcol>
<c>G</c>
<c>Application-layer Authentication</c>
<c>This document</c>
</texttable>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC0793;
&RFC2119;
&MPTCP;
<reference anchor='sha1' target="http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf"><front><title abbrev="Secure Hash Standard">Secure Hash Standard</title><author><organization>National Institute of Science and Technology</organization></author><date month="October" year="2008"/></front><seriesInfo name="Federal Information Processing Standard (FIPS)" value="180-3"/></reference>
</references>
<references title="Informative References">
&LOADB;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:55:16 |