Application Layer Authentication for MPTCP
draft-paasch-mptcp-application-authentication-00

Abstract

Multipath TCP (MPTCP), described in [3], is an extension to TCP to provide the ability to simultaneously use multiple paths between hosts.

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.

This document specifies "application layer authentication" for Multipath TCP, an alternatively negotiated keying mechanism for MPTCP.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 28, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Key in plaintext
• 1.2. Token generation
• 1.2.1. Hash collision
• 1.2.2. Derive information from the token
• 2. Proposed Technical Changes
• 2.1. MP_CAPABLE Changes
• 2.2. MP_JOIN Changes
• 2.3. Data Sequence Number Changes
• 2.4. MP_FASTCLOSE Changes
• 3. Security Considerations
• 4. IANA Considerations
• 5. References
• 5.1. Normative References
• 5.2. Informative References
• Authors' Addresses

1. Introduction

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.

In the following we explain the shortcomings of this exchange and how they impact the deployment of MPTCP.

1.1. Key in plaintext

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.

To enhance MPTCP's security, it would be beneficial to not reveal MPTCP's keys in plaintext on the wire.

1.2. Token generation

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.

1.2.1. Hash collision

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.

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.

1.2.2. Derive information from the token

As the token is a truncated hash of the key, it is entirely of a random nature. As has been shown in [5], 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.

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.

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.

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.

2. Proposed Technical Changes

2.1. MP_CAPABLE Changes

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:

• Key exchange is handled in the application layer
• Meaning can be exchanged in the token, and a custom generation method can be used, as it is decoupled from keying material

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.

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.

                        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) |
   +-------------------------------+-------------------------------+
            

           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))