idnits 2.17.1 draft-kim-mptcp-semptcp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (October 24, 2016) is 2738 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) == Outdated reference: A later version (-18) exists of draft-ietf-mptcp-rfc6824bis-05 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Multipath TCP D. Kim 3 Internet-Draft Sungkyunkwan University 4 Intended status: Standards Track October 24, 2016 5 Expires: April 27, 2017 7 Efficient Design for Secure Multipath TCP against Eavesdropper in 8 Initial Handshake 9 draft-kim-mptcp-semptcp-00 11 Abstract 13 Multipath TCP has become the transmission technique of choice for the 14 multi-homed environment. Recently, there have been multiple attempts 15 to verify the security of Multipath TCP; but an eavesdropper in the 16 initial handshake breaches the primary security goal of Multipath 17 TCP. In this paper, we introduce a secure scheme against an initial 18 eavesdropper, using asymmetric key exchange. 20 We optimize the public parameters to overcome two challenges to the 21 use of asymmetric cryptography. Then we show that compared to 22 previously proposed methods, our scheme has low overhead, and is more 23 secure. Our approach applies to many weak authentication-based 24 protocols that seek to use asymmetric cryptography. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119] 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 27, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 1. Introduction 66 TCP is currently restricted to a single path per connection, yet most 67 state-of-the-art devices often support multiple network interfaces. 68 Multipath TCP (MPTCP) [RFC6824] is a major extension of TCP that 69 enables hosts to use multiple paths to concurrently transfer data for 70 a single connection. Concurrent transfer through multiple subflows 71 for a single TCP session could improve the throughput and overall 72 usage of the network resource. 74 The primary security goal of MPTCP aims at being no worse than TCP 75 security. MPTCP currently provides security by exchanging keys 76 during the initial handshake. These keys are used to create HMACs to 77 authenticate other hosts. Exchanging keys in plaintext during the 78 initial handshake is vulnerable at the viewpoint of security. An 79 eavesdropper in the initial handshake can hijack the MPTCP session 80 using exchanged keys even after leaving the on-path location. An 81 active attacker can hijack the session by dropping the request for 82 adding subflow, and can then initiate the subflow using received 83 values within the request. 85 These threats are considered acceptable. The root cause of the 86 threats is that the attacker could exploit the authentication values, 87 whether the shared keys are exposed or not. After establishing the 88 subflow, the attacker can launch the attack [RFC6181]. 90 Asymmetric key exchange allows hosts to share the key without 91 exposure. Adopting SSL, an MPTCP session can negotiate shared keys 92 between the end-points. However, the overhead of SSL handshake is 93 too high, considering that it occurs at every establishment of MPTCP. 94 The overhead of the initial handshake affects the overall TCP 95 throughput. 97 Moreover, a short connection in MPTCP maximizes the reduction of 98 throughput. Our priority design goal is to minimize the initial 99 handshake. However, low-overhead design using asymmetric 100 cryptography is difficult, since public information needs a large- 101 sized space. MPTCP uses the TCP option, and the maximum size of the 102 option header is 40 byte, excluding the MPTCP header. If public 103 information could not be inserted in the option header, additional 104 packets are required for an exchange, since SYN packets cannot 105 involve TCP payload. Additional packets cause time and space 106 overhead. 108 We solve these limitations to optimize the public parameters 109 considering the characteristics of MPTCP. We propose a secure design 110 against an eavesdropper in the initial handshake. The proposed 111 design is low overhead, and more secure compared to other schemes 112 that use asymmetric cryptography. 114 2. Terminology 116 This document makes use of the following terms: 118 o Multipath TCP, MPTCP: refers to [RFC6824]. And every operation in 119 MPTCP follows [RFC6824] 121 o Eavesdropper in initial handshake: refers to an eavesdropper 122 present in the inital handshake where the keys are exchanged can 123 hijack the MPTCP session at any time in the future. This is 124 partial-time on-path eavesdropper and is decribed in [RFC7430] 126 o Off-path attacker in subflows: refers to an attacker not present 127 in any subflows. This type of attacker could be present in 128 initial handshake. 130 o On-path eavesdropper in subflows: refers to an eavesdropper 131 present in one or more subflows. This type of attacker could be 132 present in initial handshake. This attacker can acquire 133 information from the subflows, however, cannot change or drop the 134 message between the legitimate parties. 136 o On-path active attacker in subflows: refers to an active attacker 137 present in one or more subflows. This type of attacker could be 138 present in initial handshake, and this type of attacker can 139 acquire, change and drop the message between the legitimate 140 parties. 142 o ADD_ADDR Attack: refers to an attack using ADD_ADDR option. 143 Detail explanation is described in [I-D.ietf-mptcp-rfc6824bis]. 145 o Data encryption: refers to the possibility of data encryption 146 using any encryption algorithms without key exposure. It simply 147 means secure key exchange. 149 3. Security Threats in Multipath TCP 151 The fundamental goal of MPTCP is to provide security that is no worse 152 than TCP. IETF documentation does not concern itself with threats 153 that are applied to both TCP and MPTCP. Of course, threats on TCP 154 can influence MPTCP, the extension of TCP. IETF documentation 155 considers only the threats that are specific to MPTCP and are 156 impossible with TCP. To guarantee security, MPTCP adopts the HMAC- 157 based handshake described in Sections II.A and II.B. Researches that 158 analyze the possible threats of current MPTCP implementation are 159 investigated to verify the security provided to at least TCP level 160 [RFC7430][SecEval-MPTCP]. They classified the attackers depending on 161 location as follows: 163 o An off-path attacker does not need to be located in any of the 164 subflows of the MPTCP session. The off-path attacker cannot 165 eavesdrop any of the packets of the MPTCP session. 167 o An on-path attacker needs to be on at least one of the paths 168 during the whole lifetime of the MPTCP session. 170 The off-path attacker is the most restricted model to attack since 171 she doesn't know any information for an attack. Vulnerabilities in 172 conditions of the off-path attacker have great impact, because they 173 are vulnerable to any attacker model. It is most difficult to 174 provide security against an on-path attacker who can eavesdrop every 175 packet of information used for an attack. [RFC7430] describes the 176 major and minor threats to MPTCP. Due to the limitations of space, 177 we explain only three of them. 179 3.1. Eavesdropper in Initial Handshake 181 The attacker could eavesdrop both MPTCP keys in an initial three-way 182 handshake. This threat is mentioned in [RFC7430], and is considered 183 acceptable. In MPTCP, the valid user is the one who has a shared key 184 from an initial handshake. An eavesdropper to the initial handshake 185 also has the same authority. Reference [I-D.ietf-paasch-mptcp-ssl][I 186 -D.ietf-bagnulo-mptcp-secure][I-D.ietf-bittau-tcp-crypt][Sec-MPTCP-co 187 n-approach] describe possible solutions. 189 An eavesdropper in initial handshake is the most powerful attacker 190 model in MPTCP. An active attacker in the initial handshake is out 191 of the scope of this paper. The initial handshake is a three or 192 four-way handshake in TCP. Modifying this connection is a problem of 193 TCP, not MPTCP. Threats in MPTCP should arise due to the additional 194 operations of MPTCP which are secure in TCP. The integrity of the 195 initial handshake should be guaranteed. 197 3.2. DoS Attack on MP_JOIN 199 A valid token in SYN+MP_JOIN makes the host turn into a receiving 200 state. The host stores two 32-bit random nonces for verifying HMAC. 201 If the attacker does not respond to the third ACK of a three-way 202 handshake, the host maintains the half-open state until the third ACK 203 is received. The number of half-open connections per MPTCP session 204 is limited. 206 The attacker simply sends multiple MP_JOINs with different four- 207 tuples, evading the limitation of half-open connections to exhaust 208 the resource. The attacker only needs the valid token which is 209 easily achieved, as the token is sent as plaintext, because the token 210 is not to provide security, but to specify the MPTCP session. A 211 partial-time on-path eavesdropper inspecting any one of a MP_JOIN 212 three-way handshake can perform a DoS Attack on MP_JOIN with a valid 213 token. 215 3.3. ADD_ADDR Attack 217 The ADD_ADDR attack is a MPTCP session hijacking using a man-in-the- 218 middle (MitM) attack. An off-path active attacker can perform an 219 ADD_ADDR attack. The attacker creates MitM configuration using the 220 ADD_ADDR option, even if she is not in the middle of the path between 221 the hosts. To prevent this, ADD_ADDR format is modified to include 222 HMAC. However, it is still vulnerable to an eavesdropper in the 223 initial handshake. First, we describe the attack for the previous 224 ADD_ADDR format. We then look at the threats of the modified format. 226 Assume that hosts-A and -B have the secure MPTCP session. The 227 attacker wants to add a subflow to host-A. The attacker sends her IP 228 address and Address ID to host-B, using the ADD_ADDR option. Host-B 229 considers it as the advertisement of a redundant IP address from 230 host-A, and tries to begin an MP_JOIN handshake to the attacker's IP 231 address. 233 Host-B is a valid user who can make the valid token for A, Token-A. 234 Host-B sends Token-A and a random value, R-B to the attacker and she 235 relay these values to host-A. Host-A verifies Token_A then sends 236 HMAC-B and R-A to the attacker. The attacker delivers these values 237 to host-B. Finally, host-B sends HMAC-A to the attacker. The 238 attacker could finalize the authentication using HMAC-A. 240 The ADD_ADDR attack is a typical MitM attack except that the attacker 241 could launch the attack whenever she wants. The connection requests 242 could be refused when Address ID in the received ADD_ADDR collides 243 with that already assigned in the subflows. However, the collision 244 could be ignored, considering that the default number of the subflow 245 in the current kernel is two, and that subflows are finite due to the 246 lack of network interfaces in the normal network configuration. 248 The root cause of an ADD_ADDR attack is that there are no 249 authentication values for ADD_ADDR operation allowing the attacker to 250 masquerade as hosts-A or -B. [I-D.ietf-mptcp-rfc6824bis] modifies 251 this to only legitimate users being able to advertise their IP 252 address using truncated HMAC. The parameters for HMAC are defined in 253 Section II.C. However, an eavesdropper in the initial handshake 254 generates a truncated HMAC using both keys and still launches an 255 ADD_ADDR attack. Even then, that attacker could calculate the valid 256 token and HMAC. Using these values, she constructs the MitM 257 configuration or adds a subflow to the victims. 259 3.4. Design Consideration 261 Considering the widespread nature of TCP, it is hard to use PKIX 262 [RFC5280], which has scalability issues. Even though it is possible, 263 it has limited advantages because not all users have trusted 264 certificates. It is not practical to use trusted third parties. 265 MPTCP is based on weak authentication [Weak-auth]. The weak 266 authentication is cryptographically strong authentication among 267 unknown parties without trusted third parties. It does not authorize 268 the hosts' real identity such as X. 509 certificates, since there is 269 no trusted third party, and pre-shared secrets cannot be used. 271 The other host is unknown before establishing a connection. MPTCP 272 should exchange the secrets in the initial handshake. Due to the 273 leap of faith, which is one of the techniques supporting weak 274 authentication, it cannot validate the actual credentials of 275 entities, but ensures that entities are those who communicate from 276 the beginning. For example, hosts-A and -B are valid users who have 277 a MPTCP session. When host-B want to create a new subflow, hosts-A 278 and -B authenticate each other with Key-A and Key-B, not using the 279 real information of the hosts. Assuming that the key exchange is 280 secure, the entities who have both keys are the valid users. The 281 hosts cannot know if the other entities are hosts-A or -B, but they 282 ensure that the other hosts are legitimate entities. However, the 283 key exchange proceeds in plaintext. An eavesdropper in the initial 284 subflow knows both keys, and this means that she is a valid user. 285 Before the initial handshake, hosts-A and -B don't know each other. 286 It is difficult to send the key securely between unknown parties. 288 3.4.1. Asymmetric Key Exchange 290 If using the asymmetric property, the key exchange could occur 291 without key exposure between the unknown parties. There are two 292 challenges to adopting an asymmetric key in MPTCP. The former is the 293 space limitation of the TCP option and the latter is the cost of 294 asymmetric computation. MPTCP is over the TCP option. The maximum 295 length of TCP option is 40 bytes and the MPTCP header uses four 296 bytes. Asymmetric key exchange is hard to implement only using the 297 TCP option without using TCP payload. It generally needs a large 298 space for trading cryptographic parameters. However, a SYN flagged 299 packet typically does not include the data for negotiating the 300 initial sequence number. At least two packets in TCP handshake could 301 not be used for sending data, which results in extra packets for 302 trading public parameters. Despite space and time overheads, this 303 concept was used in the prototypes of securing MPTCP [SecEval-MPTCP] 304 and SMPTCP [I-D.ietf-bagnulo-mptcp-secure] to cover an eavesdropper 305 in initial handshake. They deal with additional packets in an 306 initial handshake for key exchange. 308 3.4.2. Minimizing Initial Handshake 310 The short connection of MPTCP subflow degrades the overall TCP 311 performance [Shortflow]. Not every MPTCP session transfers a large 312 amount of data. Some of them are terminated right after or before 313 subflow is established. When a short connection occurs, the 314 operation of adding subflow reduces the TCP performance since it 315 makes an unnecessary connection. However, a transport layer cannot 316 estimate the volume of application data. It is difficult to predict 317 the necessity of subflow before making the connection. Delaying the 318 point of creating subflow reduces the damage of short connection 319 problem. Only the connection with long lifetime wants to make a new 320 subflow. But an initial handshake is inevitable. The overhead of 321 the initial handshake has a critical impact on the whole network 322 since it occurs each connection. To minimize the handshake, the 323 current implementation exchanges keys in plaintext, even though these 324 are vulnerable to an eavesdropper in initial handshake. 326 4. The Proposed Design 328 Previous methods using an asymmetric key increase the overhead of the 329 initial handshake resulting from the additional packet. This 330 breaches the latter design consideration. We minimize public 331 parameters for an asymmetric key. Optimized parameters are able to 332 be embedded in the TCP option, and don't require additional packets, 333 except for a four-way handshake. Considering SSL/TLS, the public 334 information is too large to be in the TCP option. MPTCP relies on 335 weak authentication, which doesn't care about other host's real 336 identity. Our scheme skips the exchange of certificates. It cannot 337 guarantee publicity of the asymmetric key, but authenticates the 338 subflows that originate from the owner of the MPTCP session. Another 339 challenge is the size of the public key. To reduce the key size, we 340 apply the Elliptic Curve and Elliptic Curve Diffie-Hellman [RFC4492]. 342 Host A Host B 343 ------------------------ ------------- 344 Address A1 | Address A2 Address B1 345 ------------------------ ------------- 346 | | | 347 | | | 348 | SYN + MP_CAPABLE(A's x point) | 349 -----|------------------------------------------------>| 350 | | ACK + MP_CAPABLE(B's x point) | 351 | |------------------------------------------------>| 352 A | SYN + MP_CAPABLE(A's y point) | 353 | |------------------------------------------------>| 354 | | SYN + MP_CAPABLE(B's y point) | 355 -----|------------------------------------------------>| 356 | | | 357 | SYN + MP_JOIN(Token-B, HMAC-token, R-A) 358 | |-------------------------------->|----- 359 | | SYN/ACK + MP_JOIN(Auth-B, R-B) | | 360 | |<--------------------------------| | 361 | | ACK + MP_JOIN(Auth-A) | B 362 | |-------------------------------->| | 363 | | ACK | | 364 | |<--------------------------------|----- 365 | | | 367 Figure 1: Basic operation of the proposed Multipath TCP 369 ----------------------------------------------------------- 370 Notations | Value 371 ----------------------------------------------------------- 372 K | Hash(X_AB||Y_AB) 373 Token_B | lsb_32(Hash(X_B||Y_B)) 374 HMAC_Token | lsb_32(HMAC(K, Token_B||Address ID||R_A)) 375 Auth_B | msb_64(HMAC(K, R_B||R_A)) 376 Auth_A | HMAC(K, R_A||R_B) 377 ----------------------------------------------------------- 379 Figure 2: Parameter Notations and Thier Values for the Proposed MPTCP 380 Scheme 382 4.1. New MP_CAPABLE handshake 384 Fig.1.A describes the sequence of a modified handshake. Parameters 385 of the Elliptic Curve use the named curve defined in [SEC2]. The 386 length of the x point and y point relates to the type of elliptic 387 curve. The modified MP_CAPABLE needs a four-way handshake. First, 388 Host-A sends SYN with A's x point and stuffing the one of unused bits 389 in MP_CAPABLE option. Host-B responds with ACK including B's x 390 point. Host-B sends SYN containing B's y point. Finally, Host-A 391 responds with ACK with A's y point. 393 1 2 3 394 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 395 +---------------+---------------+-------+-------+---------------+ 396 | Kind | Length |Subtype|Version|A|B|C|D|E|F|G|H| 397 +---------------+---------------+-------+-------+---------------+ 398 | EC type | | 399 +---------------+ | 400 | Sender or Receiver's x or y point in E | 401 | (Length is depending on EC type) | 402 +---------------------------------------------------------------+ 404 Figure 3: New MP_CAPABLE option 406 Fig.3. shows the format of the new MP_CAPABLE. The current 407 implementation uses "A" and "H" flags and reserves "B" flag for an 408 extension. "C"-"G" flags remain for cryptographic negotiation. Our 409 design selects the flag among them. The proposed design supports 410 backward compatibility. It requests a connection initiation set to 411 an unused flag. Receivers who do not support our scheme reject the 412 connection, since our request uses an unused flag. It simply returns 413 to current implementation, which uses "H" flags. Receivers who 414 support our scheme but do not want to use asymmetric key exchange 415 reply that "H" flag will be used with their key, Key-B. Receivers do 416 not drop the request packet, to avoid repetition of connection 417 initiation. Key-A is the least significant 64-bits of sender's x 418 point in the request packet. The randomness of Key-A is ensured, 419 because x point is also arbitrary value. 421 ---------------------------------------------------------- 422 EC type | Named Curved | RSA/DSA 423 ---------------------------------------------------------- 424 0 | secp160k1 | 1024 425 1 | secp160r1 | 1024 426 2 | secp160r2 | 1024 427 3 | secp192k1 | 1024 428 4 | secp192r1 | 1024 429 5 | secp224k1 | 2048 430 6 | secp224r1 | 2048 431 7 | secp256k1 | 3072 432 8 | secp256r1 | 3072 433 Reserved | Reserved | Reserved 434 ---------------------------------------------------------- 436 Figure 4: Supported Elliptic Curve Type and Security Level Compared 437 to RSA/DSA 439 4.2. New MP_JOIN handshake 441 A 32-bit token identifies an MPTCP session where a new subflow wants 442 to join in. Assume that a sender inserts a random value in a token 443 to defend against reuse of the token. It is problematic for a 444 receiver to distinguish the requested MPTCP session. The receiver 445 generates hash values of all stored MPTCP identifiers with a random 446 value to compare with the token. This degrades overall TCP 447 performance in proportion to the currently existed MPTCP sessions. 448 To solve this problem, the proposed design sends the token in 449 plaintext for clarity. It protects the token using HMAC whose 450 messages are the token, Address ID, and random value. Although an 451 attacker knows the valid token, she could not launch the attack, 452 since calculating HMAC for a different Address ID is impossible. In 453 the case of reusing a previously delivered HMAC, the connection 454 requests are refused, due to the collision of Address IDs. 456 Fig.1.B describes the sequence of the new MP_JOIN handshake. Fig.2 457 describes details of the parameters. Using (X-A, Y-A) and (X-B, 458 Y-B), both hosts calculate (X-AB, Y-AB) with Elliptic Curve Diffie- 459 Hellman key exchange. Then, they calculate the Token-B and K. These 460 computations could be pre-processed. Host-A sends SYN with Token-B, 461 HMAC-Token, and a random value, R-A, in MP_JOIN. Host-B verifies 462 HMAC-Token, and checks that Address ID has no collision. Host-B 463 sends SYN/ACK with Auth-B, which originates from R-B, R-A, X-AB, and 464 Y-AB. Only a legitimate user who has the pre-shared secret, (X-AB, 465 Y-AB), can make the right authentication values. The responses ACK 466 with Auth-A are made by R-A, R-B, X-AB, and Y-AB. 468 4.3. ADD_ADDR 470 Assuming the ADD_ADDR operation is vulnerable, even in the proposed 471 design, the attacker creates a subflow using the same method 472 described in Section III.B without knowing the shared key. The 473 current MPTCP denies the requests when the sender's IP address is 474 different from the IP address, a component of HMAC. But, an 475 eavesdropper in initial handshake who knows both keys still derives a 476 new HMAC with her IP address as an input. In the proposed design, 477 the attacker could not acquire the shared key. Maintaining current 478 ADD_ADDR format mitigates against ADD_ADDR attack. 480 5. Evaluation 482 This section evaluates the proposed design compared to the previous 483 defense technique described in Section VI. MPTLS and SMPTCP 484 calculate the shared key for authentication right after a key 485 exchange over the initial handshake. Calculating the shared key 486 occurs whenever an MPTCP session is established, causing the increase 487 of overall overhead. This calculation violates our design 488 consideration, of minimizing the initial handshake. The proposed 489 design exchanges public keys in the initial handshake, but derives a 490 shared key in adding subflows, to decrease the computational overhead 491 of the whole network. In the case of a short connection, it does not 492 calculate a shared key, since MP_JOIN does not arise. Our scheme 493 optimizes not only the computational but also the space and time 494 overheads, through MPTCP specific design. 496 ----------------------------------------------------------------- 497 |Proposed| SMPTCP | MPTLS | Hash | MPTCP 498 |Design | | | Chain | 499 ----------------------------------------------------------------- 500 MP_CAPABLE 501 - Key exchange(bytes) | 148 | 202 | 7468 | 52 | 32 502 - Number of RTT/2 | 3 | 4 | 7 | 3 | 3 503 ----------------------------------------------------------------- 504 MP_JOIN 505 - Identify MPTCP | 16 | 12 | 12 | 24 | 12 506 session(bytes) | | | | | 507 - Authentication(bytes)| 40 | 40 | 40 | 28 | 40 508 ----------------------------------------------------------------- 509 Eavesdropper in initial handshake 510 & Off-path attacker | O | O | O | O | X 511 in subflows | | | | | 512 & On-path eavesdropper | O | O | O | O | X 513 in subflows | | | | | 514 & On-path active | O | O | O | X | X 515 attacker in subflows | | | | | 516 ----------------------------------------------------------------- 517 DoS Attack on MP_JOIN | O | X | X | X | X 518 ----------------------------------------------------------------- 519 ADD_ADDR Attack 520 & Eavesdropper | O | O | O | X | X 521 in initial handshake | | | | | 522 & On-path any attacker | O | O | O | X | O 523 in subflows | | | | | 524 ----------------------------------------------------------------- 525 Data encryption | O | O | O | X | X 526 ----------------------------------------------------------------- 528 Figure 5: Comparison of the proposed design and previous MPTCP 529 schemes in terms of space overhead(bytes), time overhead(RTT), 530 security, and data encryption 532 Fig.5 outlines our evaluation. We explain the overhead of the 533 proposed design and then discuss the security aspect. Asymmetric 534 methods have a high space overhead represented by bytes, due to the 535 size of public information. Each method has a different handshake of 536 packets for key exchange. We adopt an expression as a notation, 537 rather than using total bytes to declare this characteristic. The 538 operands of addition are the size of each packet, except the TCP 539 header. The proposed scheme has the lowest space overhead in 540 MP_CAPABLE among asymmetric schemes. To cover DoS attack on MP_JOIN, 541 it includes HMAC of token causing a relatively big overhead caused by 542 identifying the MPTCP session. The time overhead represents the 543 number of RTT/2 which means the one-way message latency. Although it 544 needs a four-way handshake on MP_CAPABLE, the number of RTT/2 is 545 three, since the second ACK packet and third SYN packet can pass 546 concurrently. MPTLS has a large overhead of space and time depending 547 on the TLS handshake. The number of RTT/2 of MP_JOIN is the same as 548 three in every scheme, so we intentionally omit this outcome in 549 Fig.5. 551 Asymmetric methods are secure against an eavesdropper in initial 552 handshake. Key exchange without key exposure makes data encryption 553 possible. Hash Chain is also a research into the same security 554 threats, but that scheme is insecure to the on-path active attacker 555 in subflow. She drops the MP_JOIN requests of legitimate users and 556 then makes her MP_JOIN request using the hash value received from the 557 legitimate user. Hash Chain has no mitigation for an ADD_ADDR 558 attack. It authenticates hosts using a hash chain, so there are no 559 comments about the HMAC and its keys. If it simply uses a stored 560 hash as a key of HMAC, the exchange of hash values has the same 561 meaning as the exchange of keys in plaintext. It is still insecure 562 to ADD_ADDR attack towards an eavesdropper in initial handshake. But 563 if it uses the ADD_ADDR format of the current MPTCP with the 564 assumption that the hash value is a key, it would be changed to 565 "secure" towards an on-path active attacker in Fig.5. A notable 566 difference is DoS Attack on MP_JOIN. In other methods, the attacker 567 can undertake a DoS attack using a valid token. However, in the 568 proposed design, the attacker knows a valid token but she could not 569 make HMAC due to ignorance of the shared key. If the attacker reuses 570 HMAC, rather than making a new one, the receiver denies the 571 connection, by checking the collision of address IDs. 573 6. Related Work 575 We discuss previous work for the secure schemes on security threats 576 mentioned in Section III. MPTLS [I-D.ietf-paasch-mptcp-ssl] uses an 577 asymmetric key to avoid the key exposure caused by key exchange in 578 plaintext. Hosts negotiate the shared key for HMAC using TLS. TLS 579 authenticates both hosts with certificates and operates the key 580 exchange algorithm to create the shared key. MPTCP operations are 581 performed with this key. However, MPTLS inherit the overhead of TLS 582 handshake. 584 SMPTCP is another method that uses an asymmetric key. It uses 585 tcpcrypt [I-D.ietf-bittau-tcp-crypt] to secure an MPTCP session. 586 Using tcpcrypt, both hosts negotiate a cryptographic protocol that 587 protects the TCP payload. A shared key calculated by the negotiated 588 cryptographic protocol is used for authentication for MP_JOIN. 589 Tcpcrypt uses the TCP option for implementation so it is easy to 590 integrate with MPTCP. Due to restrictions of the TCP option size, 591 tcpcrypt requires one additional message to perform the key exchange. 592 Despite one-way message latency, tcpcrypt is much more efficient than 593 TLS, since it focuses on the key exchange. Likewise MPTLS, 594 operations in SMPTCP perform the same as MPTCP, except the key for 595 HMAC is determined by tcpcrypt. Tcpcrypt is vulnerable in MitM 596 attack, but MitM in the initial handshake is out of the scope of this 597 paper. 599 The Hash Chain-based solution [Sec-MPTCP-con-approach] makes a list 600 consisting of chained hash values generated by recursively executing 601 a hash function. The host makes the key list, H0-Hn by repeating the 602 hash function with the initial random value as a message until pre- 603 defined length, n, of the hash chain. During the initial handshake 604 of the MPTCP session, both hosts exchange their last hash values Hn. 605 During adding subflow, each host sends the next value of their 606 previous hash values, i.e., Hn-1. The one-way property of the hash 607 function blocks the attacker from gaining the previous hash values. 608 Only legitimate hosts know the full hash chain. Next adding subflow 609 authenticates both hosts using the hash chain in reverse order. Once 610 the subflow is established, the host replaces the stored hash with 611 the last received hash. However, an active attacker could drop the 612 SYN+MP_JOIN from the legitimate host, and establish a new subflow 613 using a hash value in that SYN packet, without knowing the hash 614 chain. 616 7. IANA Considerations 618 This document requests an MPTCP unused flag for this option: 620 o Asymmetric Key Exchange Option 622 NOTE: Implementations may use "e" flag among unused flags 624 8. References 626 8.1. Normative References 628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, 630 DOI 10.17487/RFC2119, March 1997, 631 . 633 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 634 Moelier, "Elliptic Curve Cryptography (ECC) Cipher Suites 635 for Transport Layer Security (TLS)", RFC 4492, 636 DOI 10.17487/RFC4492, May 2006, 637 . 639 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 640 Housley, R., and W. Polk, "Internet X.509 Public Key 641 Infrastructure Certificate and Certificate Revocation 642 List(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 643 2008, . 645 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 646 "TCP Extensions for Multipath Operation with Multiple 647 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 648 . 650 8.2. Informative References 652 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 653 Multipath Operation with Multiple Addresses", RFC 6181, 654 DOI 10.17487/RFC6181, March 2021, 655 . 657 [RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. 658 Raiciu, "Analysis Residual Threats and Possible Fixes for 659 Multipath TCP (MPTCP)", RFC 7430, DOI 10.17487/RFC7430, 660 July 2015, . 662 [I-D.ietf-mptcp-rfc6824bis] 663 Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 664 Paasch, "TCP Extensions for Multipath Operation with 665 Multiple Addresses", draft-ietf-mptcp-rfc6824bis-05 (work 666 in progress), January 2016. 668 [I-D.ietf-paasch-mptcp-ssl] 669 Paasch, C. and O. Bonaventure, "Securing the Multipath TCP 670 handshake with external keys draft-paasch-mptcp-ssl-00", 671 I-D.ietf-paasch-mptcp-ssl-00 (work in progress), October 672 2012, . 675 [I-D.ietf-bagnulo-mptcp-secure] 676 Bagnulo, M., "Secure MPTCP draft-bagnulo-mptcp-secure-00", 677 I-D.ietf-bagnulo-mptcp-secure-00 (work in progress), 678 February 2014, . 681 [I-D.ietf-bittau-tcp-crypt] 682 Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres, 683 D., and Q. Slack, "Cryptographic protection of TCP Streams 684 (tcpcrypt) draft-bittau-tcp-crypt-04.txt", I-D.ietf- 685 bittau-tcp-crypt-04 (work in progress), February 2014, 686 . 689 [SecEval-MPTCP] 690 Demaria, F., "Security Evaluation of Multipath TCP", M.S. 691 thesis Computer Engineering, KTH Royal Institute of 692 Technology, March 2016. 694 [Sec-MPTCP-con-approach] 695 Diez, J., Bagnulo, M., Valera, F., and I. Vidal, "Security 696 for multipath TCP: a constructive approach", International 697 Journal of Internet Protocol Technology Vol. 6. No. 3., 698 2011. 700 [Weak-auth] 701 Arkko, J. and P. Nikander, "Weak Authentication: How to 702 Authentication Unknown Principals without Trusted 703 Parties", International Workship on Security 704 Protocols Springer Berlin Heidelberg, April 2002. 706 [Shortflow] 707 Kheirkhah, M., Wakeman, I., and G. Parisis, "Short vs. 708 Long Flows: A Battle That Both Can Win", ACM SIGCOMM 709 Computer Communication Review Vol. 45. No. 4., August 710 2015. 712 [SEC2] Certicom Research, , "SEC 2: Recommended Elliptic Curve 713 Domain Parameters", SEC2 Version 1.0, September 2000, 714 . 716 Author's Address 718 Dongyong Kim 719 Sungkyunkwan University 720 Suwon 16419 721 South Korea 723 Email: kdysk93@skku.edu