idnits 2.17.1 draft-paasch-mptcp-tls-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 ([4], [6]), 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 2883 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 156, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 159, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 171, 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 -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. '6') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6824 (ref. '7') (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). 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 TLS Authentication for MPTCP 9 draft-paasch-mptcp-tls-authentication-00 11 Abstract 13 Multipath TCP (MPTCP), described in [4], is an extension to TCP to 14 provide the ability to simultaneously use multiple paths between 15 peers. 17 draft-paasch-mptcp-application-authentication specifies "application 18 layer authentication" for Multipath TCP, an alternatively negotiated 19 keying mechanism for MPTCP. This allows keying material to be 20 sourced from an application layer protocol in order to secure MP_JOIN 21 handshakes. 23 This document explains how to use the proposed application-layer 24 authentication extension with TLS [6], in order to leverage securely 25 exchanged keys for MPTCP security, whilst simultaneously freeing the 26 MPTCP token to be used as a channel for additional information. 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 2. Technical Implementation . . . . . . . . . . . . . . . . . . 3 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 68 5.2. Informative References . . . . . . . . . . . . . . . . . 4 70 1. Introduction 72 As described in draft-paasch-mptcp-application-authentication, the 73 use of "application-layer authentication" allows the Key used in 74 MPTCP authentication to be provided by the application layer, thus 75 permitting the use of existing secure communication channels for 76 exchanging keying material. Furthermore, this decouples the key from 77 the token and thus allows the token to be used for conveying 78 additional semantics, such as helping front-end proxies route traffic 79 to appropriate back-end servers. 81 TLS [6] provides a secure authentication channel between end hosts, 82 where keys are not transmitted in the clear. The protocol generates 83 a master secret for a connection, and a method is described in [3] 84 for exporting a key generated from this and other properties which 85 can then be used by the application layer. This document shows how 86 to use this exported key, along with the method in draft-paasch- 87 mptcp-application-authentication, for providing alternative keying 88 mechanisms for MPTCP. 90 2. Technical Implementation 92 As described in draft-paasch-mptcp-application-authentication, the 93 initial MP_CAPABLE handshake will exchange an arbitrary token for 94 identifying an MPTCP connection. Whilst it is RECOMMENDED that the 95 token is hard to guess, it can be used to carry any data, such as 96 arbitrary routing information, and the security provided by the 97 application-layer security will mitigate any risks of an attacker 98 guessing tokens. 100 When an MPTCP end host wishes to open a new subflow, it will follow 101 the same exchange as described in [4], however the keying material 102 (Key-A and Key-B) will be derived from the TLS handshake, as 103 described in [3]. The "label" field MUST be "EXPORTER-MPTCP". The 104 length used in the key-derivation, following [3] is 16. Key-A are 105 the 64 most-significant bits, while Key-B are the 64 remaining bits. 106 This requires the key exchange to have completed before subflows can 107 be created. Other than the source of the keys, the exchange remains 108 the same. The MP_CAPABLE and MP_JOIN exchange therefore looks like 109 this: 111 Host A Host B 112 ------------------------ ---------- 113 Address A1 Address A2 Address B1 114 ---------- ---------- ---------- 115 | | | 116 | | SYN + MP_CAPABLE | 117 |--------------------------------------------->| 118 |<---------------------------------------------| 119 | SYN/ACK + MP_CAPABLE(Token-B) | 120 | | | 121 | ACK + MP_CAPABLE(Token-A, Token-B) | 122 |--------------------------------------------->| 123 | | | 124 | | SYN + MP_JOIN(Token-B, R-A) | 125 | |------------------------------->| 126 | |<-------------------------------| 127 | | SYN/ACK + MP_JOIN(HMAC-B, R-B) | 128 | | | 129 | | ACK + MP_JOIN(HMAC-A) | 130 | |------------------------------->| 131 | |<-------------------------------| 132 | | ACK | 134 HMAC-A = HMAC(Key=(Key-A+Key-B), Msg=(R-A+R-B)) 135 HMAC-B = HMAC(Key=(Key-B+Key-A), Msg=(R-B+R-A)) 137 Figure 1: Example Use of MPTCP Authentication 139 3. Security Considerations 141 This draft relies on the security provided by TLS [6] and the key 142 export mechanism of [3] to provide additional security for the MPTCP 143 handshake mechanism. These changes remove lingering risks, 144 originally identified in [7], where an intercept of the initial MPTCP 145 handshake could allow session hijack. 147 4. IANA Considerations 149 IANA would be requested to add a value to the TLS Exporter Label 150 registry as described in [3]. The label is "EXPORTER-MPTCP". 152 5. References 154 5.1. Normative References 156 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 157 793, September 1981. 159 [2] Bradner, S., "Key words for use in RFCs to Indicate 160 Requirement Levels", BCP 14, RFC 2119, March 1997. 162 [3] Rescorla, E., "Keying Material Exporters for Transport 163 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 164 March 2010, . 166 [4] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 167 Paasch, "TCP Extensions for Multipath Operation with 168 Multiple Addresses", draft-ietf-mptcp-rfc6824bis-05 (work 169 in progress), January 2016. 171 [5] National Institute of Science and Technology, "Secure Hash 172 Standard", Federal Information Processing Standard (FIPS) 173 180-3, October 2008, 174 . 177 5.2. Informative References 179 [6] Dierks, T. and E. Rescorla, "The Transport Layer Security 180 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 181 RFC5246, August 2008, 182 . 184 [7] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 185 "TCP Extensions for Multipath Operation with Multiple 186 Addresses", RFC 6824, January 2013. 188 Authors' Addresses 190 Christoph Paasch 191 Apple, Inc. 192 Cupertino 193 US 195 EMail: cpaasch@apple.com 197 Alan Ford 198 Pexip 200 EMail: alan.ford@gmail.com