One document matched: draft-paasch-mptcp-ssl-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC5925 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5925.xml">
<!ENTITY RFC6181 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6181.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY I-D.ietf-mptcp-multiaddressed SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mptcp-multiaddressed-10">
<!ENTITY I-D.ietf-mptcp-api SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mptcp-api-05">
<!ENTITY I-D.bittau-tcp-crypt SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-bittau-tcp-crypt-03">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>   
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-paasch-mptcp-ssl-00" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="MPTCP App Security">Securing the MultiPath TCP handshake with external keys</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Christoph Paasch" initials="C.P." role="editor"
            surname="Paasch">
      <organization>UCLouvain</organization>
      <address>
        <postal>
          <street>Place Sainte Barbe, 2</street>
          <city>Louvain-la-Neuve</city>
          <region></region>
          <code>1348</code>
          <country>BE</country>
        </postal>
        <email>christoph.paasch@uclouvain.be</email>
      </address>
    </author>
    <author fullname="Olivier Bonaventure" initials="O.B."
            surname="Bonaventure">
      <organization>UCLouvain</organization>
      <address>
        <postal>
          <street>Place Sainte Barbe, 2</street>
          <city>Louvain-la-Neuve</city>
          <region></region>
          <code>1348</code>
          <country>BE</country>
        </postal>
        <email>olivier.bonaventure@uclouvain.be</email>
      </address>
    </author>

    <date month="October" year="2012" />

    <area>General</area>

    <workgroup>MPTCP</workgroup>

    <keyword></keyword>
    <abstract>
      <t>
      Multipath TCP currently relies on the exchange of keys in clear during
      the initial handshake to authenticate the establishment of 
      additional subflows. This document proposes a variant of the Multipath TCP
      handshake that allows Multipath TCP to reuse keys negotiated by the 
      Application layer protocol above it such as SSL/TLS to authenticate the establishment
      of additional subflows. 
      </t>
    </abstract>
  </front>

  <middle>
<section title="Introduction">
<t>

Multipath TCP is an extension to TCP that enables hosts to use multiple paths to exchange data for
a single connection. <xref target="I-D.ietf-mptcp-multiaddressed"/> describes the current design
of the Multipath TCP protocol. The design of Multipath TCP has been influenced by various factors 
including the backward compatibility with regular TCP, the fallback to TCP when middleboxes interfere 
with the Multipath TCP options, ... The design of Multipath TCP has also been affected by security
requirements. The security threats against Multipath TCP are documented in 
<xref target="RFC6181"/>. Multipath TCP aims at being no worse than TCP from a security viewpoint. 
Other approaches such as <xref target="I-D.bittau-tcp-crypt"/> or <xref target="RFC5925"/> have been proposed 
to reduce the vulnerability of TCP to attacks. 

Multipath TCP currently addresses the security threats identified in <xref target="RFC6181"/> 
by exchanging keys during the handshake for the
initial subflow. These keys are then used to generate HMACs to authenticate the establishment of
subsequent TCP subflows. Exchanging keys in clear during the initial handshake has obvious shortcomings 
from a security viewpoint. 
However, some application-layer protocols like SSL/TLS or ssh already negotiate a shared key
between the end-points. In this document we propose a modification to the handshake used by Multipath TCP
for the initial and subsequent subflows that enables Multipath TCP to rely on an 
application-supplied key to authenticate the establishment of the subflows. 
</t>
<!-- <section title="Requirements Language">
  <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
 </section>-->
</section>

<section anchor="Initial subflow" title="Connection initiation">
<t>
The handshake of the initial subflow is a small variation to the handshake of
<xref target="I-D.ietf-mptcp-multiaddressed"/> or draft-paasch-mptcp-lowoverhead-00.

The header of the MP_CAPABLE option of these two MPTCP-versions has the format
as shown in the below figure.
</t>

<figure align="center" anchor="mp_capable_syn">
<artwork align="center"><![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|
+---------------+---------------+-------+-------+---------------+
]]></artwork>
<postamble>Header of the MP_CAPABLE option</postamble>
</figure>
<t>
We propose to use the B bit in this option to indicate whether the host that sent the
MP_CAPABLE option will use an application supplied key to authenticate
the additional subflows or not. When the B bit is set, it indicates that the authentication
key is supplied by the application.
If the B bit has not been set in both directions, the authentication mechanism is used
as defined by the MPTCP version (<xref target="I-D.ietf-mptcp-multiaddressed"/> or draft-paasch-mptcp-lowoverhead-00).
</t>
<t>
In MPTCP version 0, even if the B bit is set the end-hosts still have to generate a key that fulfills the requirements as defined in MPTCP version 0.
This is necessary to handle the case where the client supports the B bit, but the server not yet. For a more in-depth analysis of this kind of deployment
scenario, have a look at <xref target="Deployment"/>.
</t>
<t>
By using the same handshake as draft-paasch-mptcp-lowoverhead-00, the proposed handshake can also
benefit from the lower overhead for generating the token and thus the faster
establishment of the initial subflow.
</t>
</section>

<section anchor="Application interaction" title="Multipath TCP API">
<t>
The proposed mechanism requires an interaction between the application and the MPTCP layer.
This can be achieved by the means of socket options. Two socket options are necessary:
</t>

<t>
<list style="symbols">
<t>
MPTCP_ENABLE_APP_KEY : This socket option tells the socket layer that an application supplied
key will be used to secure the establishement of additional subflows. 
This socket option MUST be used before establishing the initial subflow,
or before starting to listen on a socket to accept new connections. When this socket option 
is used, the MP_CAPABLE option is sent with the "B"-bit set to 1.
</t>
<t>
MPTCP_KEY : This socket option allows the application to provide a key to the MPTCP
layer. Both end-points MUST use this socket option in order to allow the MPTCP-layer
to create new subflows. It is up to the application to negotiate the key between
the end-points. E.g., in the case of SSL/TLS, the key can be a hash of the shared secret
that has been negotiated with the SSL exchange. Separate documents will describe in details how
applications such as TLS or SSH can pass a shared secret to Multipath TCP by using this option.
</t>
</list>
</t>
</section>

<section anchor="New subflow" title="Starting a new subflow">
<t>
The handshake for the establishment of a new subflow is similar to the one specified in
<xref target="I-D.ietf-mptcp-multiaddressed"/>. There are two important differences.
First, the HMAC is computed by using the keys provided by the application. Second, the token and the
client's random number are included inside the third ack to allow stateless
operation of the passive opener of an additional subflow.
</t>
<figure align="center" anchor="mid_add">
<artwork align="center"><![CDATA[
 Host A                                  Host B
----------                             ----------
Address A2                             Address B2
----------                             ----------
    |                                      |
    |   SYN + MP_JOIN(Token-B, R-A)        |
    |------------------------------------->|
    |                                      |
    |   SYN/ACK + MP_JOIN(HMAC-B, R-B)     |
    |<-------------------------------------|
    |                                      |
    |  ACK + MP_JOIN(Token-B, R-A, HMAC-A) |
    |------------------------------------->|

HMAC-A = HMAC(Key, Msg=(R-A+R-B))
HMAC-B = HMAC(Key, Msg=(R-B+R-A))
]]></artwork>
<postamble>Handshake of a new subflow.</postamble>
</figure>

<t>
In order to allow the Token-B and R-A inside the third ack, the HMAC-A must also
be a truncated version of the 160-bit HMAC-SHA1. Thus, HMAC-A is the truncated
(leftmost 128 bits) of the HMAC as shown in <xref target="mid_add"/>.
</t>

<t>
The message-format of the MP_JOIN-option in the SYN and the SYN/ACK is the same
as in <xref target="I-D.ietf-mptcp-multiaddressed"/>. As the third ACK includes
the Token and the random nonce, the MP_JOIN message format of the
third ack is as show in <xref target="mp_join"/>. The length of the MP_JOIN-option
in the third ACK is 28 bytes. There remains thus enough space to insert 
the timestamp option in the third ACK.
</t>

<figure align="center" anchor="mp_join">
<artwork align="center"><![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|     |B|   Address ID  |
+---------------+---------------+-------+-------+---------------+
|                                                               |
|                Sender's Truncated HMAC (128 bits)             |
|                                                               |
+---------------------------------------------------------------+
|                Sender's Random Number (32 bits)               |
+---------------------------------------------------------------+
|                     Receiver's Token (32 bits)                |
+---------------------------------------------------------------+
]]></artwork>
<postamble>Format of the MP_JOIN-option</postamble>
</figure>

<t>
The semantics of the backup-bit "B" and the Address ID are the same as in
<xref target="I-D.ietf-mptcp-multiaddressed"/>.
</t>
</section>

<section anchor="Deployment" title="Deployment">
<t>
This proposed mechanism assumes that the application uses new socket-options to
provide the key to the MPTCP-layer.
Thus, the first requirement for deploying this MPTCP handshake is that the TLS/SSL-layer has been modified.
There may of course be scenarios, where the client is supporting the proposed solution, but the server not.
Thus, the client sends out the MP_CAPABLE with the B bit set, but the server
replies without enabling the B bit. Upon reception of the SYN/ACK, it is up to
the client's policy how to react. It can either continue with the negotiated version of
MPTCP but without using the key from the application or fallback to regular TCP.
</t>
<t>
The applications will have to pass the shared key to
the MPTCP-layer by the means of a socket-option. It
may be that the client's application has already done
the call to the socket-option but the server's application
not yet. The server will receive a SYN with the
MP_JOIN-option, without knowing the key. In that
case the server should silently drop the SYN. The TCP
retransmission mechanism on the client-side will retransmit
the SYN after the initial RTO expired (after 1 second).
And the server's application potentially will have
finally set the key via the socket-option.
</t>
</section>

<section anchor="Security" title="Security Considerations">
<t>
It is recommended that the applications do not pass the plain shared key to the
MPTCP layer. They should rather pass a hash of their shared secret to the MPTCP
layer. These security considerations will be discussed in documents that describe
how applications such as TLS/SSL or SSH can interact efficiently with 
Multipath TCP.
</t>
</section>
</middle>
  <back>
<!--    <references title="Normative References">
</references>-->
    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      &I-D.ietf-mptcp-multiaddressed;
      &I-D.ietf-mptcp-api;
      &I-D.bittau-tcp-crypt;
      &RFC5925;
      &RFC6181;

    </references>
  </back>
</rfc>