Internet DRAFT - draft-bagnulo-mptcp-secure
draft-bagnulo-mptcp-secure
Network Working Group M. Bagnulo
Internet-Draft UC3M
Intended status: Standards Track February 12, 2014
Expires: September 3, 2014
Secure MPTCP
draft-bagnulo-mptcp-secure-00
Abstract
This memo contains some initial thoughts about how to secure MPTCP.
As currently defined, MPTCP provides basic security features to
protect the MPTCP signaling and the data flows unprotected. In this
note, we explore the possible use to tcpcrypt to provide enhanced
security to 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 August 3, 2014.
Copyright Notice
Copyright (c) 2014 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.
Bagnulo Expires August 3, 2014 [Page 1]
Internet-Draft SMTCP January 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Initial SMTCP connection . . . . . . . . . . . . . . . . . . 3
3. Adding new subflows . . . . . . . . . . . . . . . . . . . . . 4
4. Exchanging data . . . . . . . . . . . . . . . . . . . . . . . 5
5. Backward compatibility . . . . . . . . . . . . . . . . . . . 6
6. Concluding remarks . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Multi-path TCP (MPTCP) [RFC6824] defines the extensions to TCP that
allow transmitting data over multiple paths in a single TCP
connection. This is achieved by opening multiple subflows within the
same TCP connection. Each subflow is associated to a different
address/port pair. As currently defined, MPTCP provides basic
security for the signaling used to establish the subflows. A threat
analysis for MPTCP is presented in [RFC6181] and a residual threat
analysis is presented in [I-D.bagnulo-mptcp-attacks]. From these
analysis we can extract that MPTCP as currently defined is vulnerable
to attackers that can eavesdrop the initial connection establishment
exchange and also to attackers that can intercept any subflow
establishment exchange. In addition, MPTCP does not provide any
protection to the data stream (other than splitting the data stream
over multiple paths), as this was a non goal of the MPTCP design. In
[I-D.bagnulo-mptcp-attacks] it is concluded that if a more secure
version of MPTCP should be pursued, the path to follow would be to
protect the data stream rather than trying to provide additional
security to the signaling. The reader is referred to the
aforementioned reference for additional insight why this is the case.
The goal of this document is provide initial considerations about how
to provide enhanced security to MPTCP by securing the data stream.
In this note, we analyze the use of tcpcryp [I-D.bittau-tcp-crypt] to
secure MPTCP. tcpcrypt defines extensions to TCP so opportunistically
encrypt the data stream of a TCP connection. By using tcpcrypt in
MPTCP, we would be able to provide enhanced security to MPTCP. We
note however, that the resulting solution would still be vulnerable
to Man-in-the-Middle attacks during the initial key negotiation.
However, the attacker in this case must be active and must remain
located along the path during the whole lifetime of the connection.
Bagnulo Expires August 3, 2014 [Page 2]
Internet-Draft SMTCP January 2014
We call SMTCP to the integration of MPTCP with tcpcryp. This would
provide stronger security of MPTCP, both for the signaling and for
the data. Since all the MPTCP signaling will be protected by
tcpcrypt (i.e. encrypted and its integrity protected) there is no
need for the existent MPTCP security mechanisms when used with
tcpcrypt. This means that there is no need to negotiate a the
current MPTCP key and that the HMAC protection provided by the MPTCP
protocol is not needed (except for backward compatibility issues).
All the protection will be achieved with the tcpcrypt extensions.
2. Initial SMTCP connection
Suppose both A and B are SMTCP capable. Suppose A has both IPA1 and
IPA2. Suppose A initiates a SMTCP connection with B. The exchange
would look like as follows:
A -> B: SYN + MP_CAPABLE (including A's key (ka) and C bit set) +
CRYPT/Hello This contains 15 bytes of options (the motivation for
including both the MP_CAPABLE and the CRYPT option is for backward
compatibility, see Section 5 ). SYN packets usually carry as well
MSS (4 bytes), SACK (2 bytes) and Window-Scale (3 bytes).
Negotiating timestamps would be 10 more bytes. As options has a
maximum length of 40 bytes, this would be compatible with all the
mentioned options.
B -> A: SYN/ACK + MP_CAPABLE (including B's key (kb) and the C bit
set) + CRYPT/PKCONF (with pub-cipher-list) Assuming we have 2
algorithms in the list, this is 10 bytes, making a total of 22
bytes. This packet also usually carries the same options than the
SYN packet, so in this case, not all the mentioned additional
options would fit.
A -> B: INIT (3 bytes of options) plus crypto data in the payload
(The MP_CAPABLE option is needed since the keys are generated by
tcpcrypt)
B -> A: INIT (3 bytes of options) plus crypto data in the payload
During the 3-way handshake MPTCP generates the following values:
The key: session to key to protect the signaling (one per each
side)
The Token: used as connection identifier (one per each side)
The IDSN: Initial Data Seq Number (one per each side)
The idea would be to derive them from the tcpcrypt values.
Bagnulo Expires August 3, 2014 [Page 3]
Internet-Draft SMTCP January 2014
o The keys: tcpcrypt generates 4 keys, kec, kac, kes and kas. These
will be used to secure MPTCP, as discussed later on. for the
purposes of MPTCP signaling, the keys that will be used are the
authentication keys, so the keys for MPTCP are kac and kas.
o The tokens: tcpcrypt generates a Session ID, which is the full
length of a hash output. The thing is that tcpcrypt generates a
single SID for both endpoints, while MPTCP generates one per
endpoint. In addition, MPTCP needed to generate a pair of ISDNs.
We could then generate the MPTCP values out of the tcpcrypt values as
follows
Key A= kac
Key B= Kas
Token A= 32 most significant bits of (hash(ka))
Token B= 32 most significant bits of (hash(kb))
IDSN A= 64 least significant bits of (hash(kac + SID))
IDSN B= 64 least significant bits of (hash(kas + SID))
DISCUSSION: We need to exchange ka in the MP_CAPABLE message because
of backwards compatibility issues (see Section 5), so there is no
easy way around it. However, the reason to exchange kb in the
MP_CAPABLE is because we need to be able to generate Token B in a way
that is unique in host B. This seems an overkill (exchanging a 64 bit
key to achieve a 32 bit unique token). It could be possible to
define a new MP_CAPABLE option that would exchange a 32 bit long
token directly. We also need to understand the security implications
of exchanging the token in the clear. Another alternative would be
to generate the token as a hash of kas and the SID and if it happens
to clash, restart the connection. Tis may make sense depending how
likely is this to happen. TODO: work out the other flavors of
tcpcrypt connection initiation, including the use of cached keys
3. Adding new subflows
The options for this is whether to treat a new subflow as a new
tcpcrypt connection or not, the implication being that a new tcpcrypt
connection uses a different shared secret and hence different keys
(even though not new public key operations are needed). Probably
this is not the way to go. All the flows of a MPTCP connection
should be part of the same tcpcrypt session. (the other option would
Bagnulo Expires August 3, 2014 [Page 4]
Internet-Draft SMTCP January 2014
imply that there are different keys for the same MPTCP session, which
may be cumbersome?)
So, one simple way of doing this would be to simply use the existent
MPTCP exchange to add a new subflow with the MPTCP security measures.
This implies sending an MP_JOIN containing the receiver's token and a
random number which will be responded with another MP_JOIN and the
final JOIN message. The tcpcrypt keys are used instead of the
regular MPTCP keys.
(similar approach can be used for the ADD_ADDR option, which is
secure using an HMAC using the tcpcryp derived key)
A alternative approach would be to drop completely the MPTCP security
mechanisms and use the tcpcryp MAC option to secure the MPTCP
signaling. This implies that the tcpcryp MAC option would need also
to protect the MPTCP MP_JOIN option
4. Exchanging data
Once the keys and the other values have been negotiated, data can
flow. All data in the MPTCP connection will be encrypted with
tcpcrypt keys and its integrity protected using the tcpcrypt MAC
option. This adds 22 bytes of options (assuming 160 bits long hash).
Question: do we need to have a 160 bit long hash or can we live with
less?
Now, MPTCP includes the DSS option in order to synchronize the data
sequence number with the sequence numbers of the subflows. The DSS
option max length is 28 bytes. The results it that the MAC option
plus the DSS option are 50 bytes, which is a problem.
The good news is that the DSS does not need to be sent in every
segment and that 28 bytes is the maximum length.
Currently the DSS option includes information both about DSN mapping
to subflow seq number and data ack. In order to limit the size of
the option, one option is to prevent that both Data Ack and DSN to
subflow seq numbers mappings are sent in the same option. This would
result that when Data acks are sent, the DSS option has a maximum of
12 bytes and when DSN to subflow seq number mapping are sent, the max
length is 20 bytes. This is still 2 bytes too long. There are two
ways we can shrink this. One option is to prevent the use of
Checksum when tcpcrypt is used. checksum is optional, so this could
be done. Moreover, it makes sense to do this, because all the
information protected in this checksum is protected by the tcpcrypt
MAC option. this results that the DSS option is now 18 bytes, which
Bagnulo Expires August 3, 2014 [Page 5]
Internet-Draft SMTCP January 2014
with the tcpcrypt MAC option will make up to 40 bytes of tcp options.
The other possible way to shrink this is to use the 4 bytes seq
numbers rather than the 8 ones. This would reduce the DSS option to
14 bytes for the DSN to subflow seq number mapping and to 8 bytes in
the case of Data acks.
The DSS option will be sent in the clear i.e. not encrypted by
tcpcrypt. The MAC option must cover the DSS option (correct?). This
implies that we need to add to the MAC data structure the DSS option.
Question: how often the DSS needs to be sent? I mean, if we send the
DSS and the MAC options, we will be using all the TCP option room,
so, not SACK can be sent, which is bad.
5. Backward compatibility
There will be the following 5 types of node:
MPTCP nodes: supports MPTCP as defined in RFC6824 or RFC6824bis
but does not support tcpcrypt,
tcpcryp nodes: supports tcpcrypt but does not support MPTCP,
SMTCP capable nodes: support MPTCP and tcpcrypt and the use of
tcpcrypt to secure MPTCP,
legacy nodes: dont support neither tcpcrypt nor MPTCP,
MPTCP/tcpcrypt nodes: supports both tcpcrypt and MPTCP but does
not support the use of tcpcrypt to protect MPTCP.
The expected behavior is as following:
a. SMTCP contacts a SMTCP node, SMTCP should be used
b. SMTCP contacts a MPTCP node, MPTCP should be used
c. SMTCP contacts a tcpcrypt node, tcpcrypt should be used
d. SMTCP contacts a MPTCP/tcpcrypt node, not sure what should
happen... should MPTCP and tcpcrypt be used in a non integrated
fashion? (not sure if there is enough space in the TCP options
for this...)
e. SMTCP contacts a legacy node, TCP should be used.
In order to achieve, we use the following approach. In the initial
SYN of the initial 3-way handshake, both the CRYPT/Hello option (3
Bagnulo Expires August 3, 2014 [Page 6]
Internet-Draft SMTCP January 2014
bytes) plus the MP_CAPABLE option including the initiator's key (12
bytes) should be sent. This allows supporting b), c) and e) i.e.
the receiver can discard either of the two options or both of them
resulting in each of the mentioned cases.
In order to support case a) (and to distinguish it from case d), we
need to signal it in an explicit way. I guess the easiest way is to
use one of the flags C to H in the MP_CAPABLE message. Let's assume
it is the C(rypt) flag. If the C flag is set and the CRYPT/Hello
option is present, this means SMTCP (i.e. use tcpcrypt to protect
MPTCP signaling and data).
6. Concluding remarks
One main challenge in order to use tcpcrypt to secure MPTCP is the
option space. There is little room for TCP options and this approach
would consume most of it, which would prevent the use of other
options like SACK. One way to address this would be that tcpcrypt is
changed to send the MAC as part of the data stream rather than an
option. As tcpcrypt is being discussed, this can be an option.
A second issue to consider is how this would work with TSO.
Currently MPTCP is compatible with TSO and it would be important that
SMPTCP is also compatible.
Another comment is that it would be possible to secure MPTCP using
something like TLS opportunistically and transparently to the
application. This is TBD as an alternative approach.
7. Security Considerations
This whole document is about securing MPTCP. In future versions of
the document, this section could include a residual threat analysis.
8. IANA Considerations
TBD
9. Acknowledgements
The authors thank ...
10. References
Bagnulo Expires August 3, 2014 [Page 7]
Internet-Draft SMTCP January 2014
10.1. Normative References
[I-D.bittau-tcp-crypt]
Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres,
D., and Q. Slack, "Cryptographic protection of TCP Streams
(tcpcrypt)", draft-bittau-tcp-crypt-03 (work in progress),
September 2012.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013.
10.2. Informative References
[I-D.bagnulo-mptcp-attacks]
Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C.
Raiciu, "Analysis of MPTCP residual threats and possible
fixes", draft-bagnulo-mptcp-attacks-01 (work in progress),
October 2013.
[RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for
Multipath Operation with Multiple Addresses", RFC 6181,
March 2011.
Author's Address
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: 34 91 6249500
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Bagnulo Expires August 3, 2014 [Page 8]
