idnits 2.17.1 draft-paasch-mptcp-application-authentication-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 abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 27, 2016) is 2889 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 316, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 319, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (ref. '1') (Obsoleted by RFC 9293) == Outdated reference: A later version (-18) exists of draft-ietf-mptcp-rfc6824bis-05 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Paasch 3 Internet-Draft Apple, Inc. 4 Intended status: Experimental A. Ford 5 Expires: November 28, 2016 Pexip 6 May 27, 2016 8 Application Layer Authentication for MPTCP 9 draft-paasch-mptcp-application-authentication-00 11 Abstract 13 Multipath TCP (MPTCP), described in [3], is an extension to TCP to 14 provide the ability to simultaneously use multiple paths between 15 hosts. 17 MPTCP currently specifies a single authentication mechanism, using 18 keys that are initially exchanged in the clear. There are 19 application-layer protocols that may have better information as to 20 the identity of the parties and so is able to better provide keying 21 material that could be used for the authentication of future 22 subflows. 24 This document specifies "application layer authentication" for 25 Multipath TCP, an alternatively negotiated keying mechanism for 26 MPTCP. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 28, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Key in plaintext . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Token generation . . . . . . . . . . . . . . . . . . . . 3 65 1.2.1. Hash collision . . . . . . . . . . . . . . . . . . . 3 66 1.2.2. Derive information from the token . . . . . . . . . . 3 67 2. Proposed Technical Changes . . . . . . . . . . . . . . . . . 4 68 2.1. MP_CAPABLE Changes . . . . . . . . . . . . . . . . . . . 4 69 2.2. MP_JOIN Changes . . . . . . . . . . . . . . . . . . . . . 6 70 2.3. Data Sequence Number Changes . . . . . . . . . . . . . . 6 71 2.4. MP_FASTCLOSE Changes . . . . . . . . . . . . . . . . . . 7 72 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 5.2. Informative References . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 The MPTCP handshake serves multiple purposes. First, hosts discover 81 their peer's support of MPTCP. Second, each host announces a key 82 that will be tied to this MPTCP session. The key also serves 83 multiple purposes. First, the derivate of the key is being used as a 84 token-identifier for the MPTCP connection. This derivate is a 85 truncated hash of the key. Second, another truncated hash of the key 86 serves as the initial data sequence number. And third, the key 87 itself is used as an authenticator to prove that the host behind the 88 IP-address used to establish new subflows is indeed the one that 89 participated in the handshake of the initial subflow. 91 In the following we explain the shortcomings of this exchange and how 92 they impact the deployment of MPTCP. 94 1.1. Key in plaintext 96 The key-exchange happens during the handshake of the initial subflow. 97 RFC 6824 specifies that this exchange happens in plaintext. As has 98 been noted in RFC 7430, an eavesdropper on the initial handshake is 99 thus able to learn the keys used in this MPTCP session. This allows 100 him to generate the session's tokens and data sequence numbers, 101 enabling him to effectively hijack the MPTCP session by creating a 102 subflow with a different IP-address. The attacker will be able to 103 generate a valid HMAC as he has full knowledge of the keys of this 104 MPTCP session. 106 To enhance MPTCP's security, it would be beneficial to not reveal 107 MPTCP's keys in plaintext on the wire. 109 1.2. Token generation 111 The token is a truncation of the 32 most significant bits of the 112 SHA-1 of the key. The key must be a random number of sufficient 113 entropy to be used as part of the authentication mechanism, and thus 114 a host has no control over the token as it is generating the key for 115 the MPTCP-session. This has some implications on the deployability 116 of MPTCP, outlined hereafter. 118 1.2.1. Hash collision 120 Due to the nature of the token-generation, the 32-bit token might 121 collide with another already existing MPTCP session. While a 32-bit 122 token collision should be very rare on client devices, a busy server 123 (with potentially tens of millions of active MPTCP connections) will 124 have a very high probability of a token collision. 126 Upon such a collision, the server needs to generate a new 127 cryptographically secure 64-bit key, and derive the token through a 128 SHA-1 computation upon which he finally can verify the uniqueness of 129 the token. If a collision happened again, the server has to start 130 anew. This process imposes a computation overhead and complexity 131 upon the server and impacts the scalability compared to regular TCP. 132 Allowing a server to generate a token in such a way that uniqueness 133 can be achieved easily would be beneficial for the scalability and 134 deployment of MPTCP. 136 1.2.2. Derive information from the token 138 As the token is a truncated hash of the key, it is entirely of a 139 random nature. As has been shown in [5], this brings several 140 deployment challenges in large server farms. In particular, the 141 layer-4 load balancers in front of this server farm need to maintain 142 MPTCP-specific state in order to map a token to the server. 144 The token can be looked at as a route-identifier, as it allows the 145 server to associate the incoming SYN+MP_JOIN with an existing MPTCP- 146 session. However, the random nature of the token does not allow a 147 load balancer in the middle to do the same without having to maintain 148 MPTCP-specific state. 150 If the token can be generated in such a way that it carries the 151 required routing information in such a way that it can be deciphered 152 by all the trusted parties in the server farm deployment, large-scale 153 deployment of MPTCP would be simplified. 155 In the following we suggest an alternative handshake that allows 156 MPTCP to increase its security by leveraging an external key-exchange 157 and thus benefit from the security provided by protocols like TLS. 158 As a side-effect of this approach, the token also can be exchanged in 159 a more flexible way, addressing the above identified issues with the 160 token generation. 162 2. Proposed Technical Changes 164 2.1. MP_CAPABLE Changes 166 To resolve the issues identified in the previous section, this 167 proposal separates the key handling for security (i.e. the method for 168 protecting new subflow exchanges) from the token exchange. This 169 means that: 171 o Key exchange is handled in the application layer 173 o Meaning can be exchanged in the token, and a custom generation 174 method can be used, as it is decoupled from keying material 176 This specification allocates the 'G' bit from the flags of MP_CAPABLE 177 as an alternative security mechanism - "handled by application 178 layer". In this case, the MP_CAPABLE exchange will send and receive 179 tokens rather than keys. 181 When the 'G' bit is set to 1, this implies support for this new 182 mechanism, and the MP_CAPABLE exchange will operate as follows. The 183 tokens take the place of the keys in the MP_CAPABLE exchange, but 184 otherwise the exchange remains very similar. This exchange still 185 maintains support for stateless servers. Note that this now means 186 that tokens are 64 bits in length. 188 1 2 3 189 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 190 +---------------+---------------+-------+-------+---------------+ 191 | Kind | Length |Subtype|Version|A|B|C|D|E|F|G|H| 192 +---------------+---------------+-------+-------+---------------+ 193 | Option Sender's Token (64 bits) | 194 | (if option Length > 4) | 195 | | 196 +---------------------------------------------------------------+ 197 | Option Receiver's Token (64 bits) | 198 | (if option Length > 12) | 199 | | 200 +-------------------------------+-------------------------------+ 201 | Data-Level Length (16 bits) | Checksum (16 bits, optional) | 202 +-------------------------------+-------------------------------+ 204 Figure 1: Proposed Multipath Capable (MP_CAPABLE) Option 206 The MP_CAPABLE option is carried on the SYN, SYN/ACK, and ACK packets 207 that start the first subflow of an MPTCP connection, as well as the 208 first packet that carries data, if the initiator wishes to send 209 first. The data carried by each option is as follows, where A = 210 initiator and B = listener. 212 o SYN (A->B): only the first four octets (Length = 4). 214 o SYN/ACK (B->A): B's token for this connection (Length = 12). 216 o ACK (no data) (A->B): A's token followed by B's token (Length = 217 20). 219 o ACK (with first data) (A->B): A's key followed by B's key followed 220 by Data-Level Length, and optional Checksum (Length = 22 or 24). 222 The contents of the option is determined by the SYN and ACK flags of 223 the packet, along with the option's length field. For the diagram 224 shown in Figure 1, "sender" and "receiver" refer to the sender or 225 receiver of the TCP packet (which can be either host). 227 If the sender of the initial SYN supports both SHA-1 (as specified in 228 [3]) and application-layer, it can set both G and H bits to "1". The 229 sender of the SYN/ACK can then make a decision as to which mode to 230 support, and selects only one of those bits in the SYN/ACK. 232 2.2. MP_JOIN Changes 234 The MP_JOIN exchange remains almost the same: 236 Host A Host B 237 ------------------------ ---------- 238 Address A1 Address A2 Address B1 239 ---------- ---------- ---------- 240 | | | 241 | | SYN + MP_JOIN(Token-B, R-A) | 242 | |------------------------------->| 243 | |<-------------------------------| 244 | | SYN/ACK + MP_JOIN(HMAC-B, R-B) | 245 | | | 246 | | ACK + MP_JOIN(HMAC-A) | 247 | |------------------------------->| 248 | |<-------------------------------| 249 | | ACK | 251 HMAC-A = HMAC(Key=(Key-A+Key-B), Msg=(R-A+R-B)) 252 HMAC-B = HMAC(Key=(Key-B+Key-A), Msg=(R-B+R-A)) 254 Figure 2: Example Use of MP_JOIN 256 However, the token presented is now 64 bits. The key used in the 257 HMAC exchange here is provided by the application layer. Otherwise, 258 there are no other changes to the handshake. Note, however, that an 259 MP_JOIN message cannot be sent until the application layer protocol 260 has determined that the key exchange has completed. 262 Depending on the key-exchange protocol that is in use at the 263 application layer, it may be that the client already knows the key, 264 while the server is not yet aware of it. In that case the server 265 might receive SYN+MP_JOIN with a valid token, but the MPTCP-state on 266 the server has not yet been populated with the key. The server must 267 silently drop in that case the SYN+MP_JOIN. The client will 268 retransmit its SYN+MP_JOIN and eventually the application on the 269 server will have populated the MPTCP-state with the key. 271 2.3. Data Sequence Number Changes 273 The Initial Data Sequence Number for each host involved in an MPTCP 274 connection is, by [3], derived from the SHA-1 hash of the key. If 275 application-layer authentication is selected, the IDSN MUST instead 276 be derived from the most-significant 64 bits of the SHA-1 hash of the 277 token. 279 2.4. MP_FASTCLOSE Changes 281 MP_FASTCLOSE is the other method that uses the key in [3]. Given 282 there is no knowledge as to a potential key's sensitivity, it can no 283 longer be said that a key should be sent here. Instead, a truncation 284 of the 64 most-significant bits of the SHA-1 hash [4] of the key 285 should be used. 287 3. Security Considerations 289 This draft is proposing a mechanism that would allow an application- 290 layer protocol to provide security, rather than relying on a 291 cleartext exchange of the keys. As such, this document itself does 292 not introduce any additional security concerns, but provides a 293 mechanism by which additional security could be added to the MPTCP 294 handshake, depending on the authentication method used at the 295 application layer. 297 4. IANA Considerations 299 This document would update the "MPTCP Handshake Algorithms" sub- 300 registry under the "Transmission Control Protocol (TCP) Parameters" 301 registry, based on the flags in MP_CAPABLE, to add the following 302 algorithm: 304 +----------+----------------------------------+---------------+ 305 | Flag Bit | Meaning | Reference | 306 +----------+----------------------------------+---------------+ 307 | G | Application-layer Authentication | This document | 308 +----------+----------------------------------+---------------+ 310 Table 1: MPTCP Handshake Algorithms 312 5. References 314 5.1. Normative References 316 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 317 793, September 1981. 319 [2] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, March 1997. 322 [3] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 323 Paasch, "TCP Extensions for Multipath Operation with 324 Multiple Addresses", draft-ietf-mptcp-rfc6824bis-05 (work 325 in progress), January 2016. 327 [4] National Institute of Science and Technology, "Secure Hash 328 Standard", Federal Information Processing Standard (FIPS) 329 180-3, October 2008, 330 . 333 5.2. Informative References 335 [5] Paasch, C., Greenway, G., and A. Ford, "Multipath TCP 336 behind Layer-4 loadbalancers", draft-paasch-mptcp- 337 loadbalancer-00 (work in progress), September 2015. 339 Authors' Addresses 341 Christoph Paasch 342 Apple, Inc. 343 Cupertino 344 US 346 EMail: cpaasch@apple.com 348 Alan Ford 349 Pexip 351 EMail: alan.ford@gmail.com