idnits 2.17.1 draft-mavrogiannopoulos-tls-cid-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 13, 2016) is 2721 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) == Unused Reference: 'I-D.ietf-tls-tls13' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'I-D.rescorla-tls-dtls13' is defined on line 314, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-18 == Outdated reference: A later version (-01) exists of draft-rescorla-tls-dtls13-00 ** Downref: Normative reference to an Informational RFC: RFC 4226 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group N. Mavrogiannopoulos 3 Internet-Draft RedHat 4 Intended status: Standards Track H. Tschofenig 5 Expires: May 17, 2017 ARM 6 T. Fossati 7 Nokia 8 November 13, 2016 10 Datagram Transport Transport Layer Security (DTLS) Transport-Agnostic 11 Security Association Extension 12 draft-mavrogiannopoulos-tls-cid-00 14 Abstract 16 This memo proposes a new Datagram Transport Transport Layer Security 17 (DTLS) extension that provides the ability to negotiate, during 18 handshake, a transport independent identifier that is unique per 19 security association. This identifier effectively decouples the DTLS 20 session from the underlying transport protocol, allowing the same 21 security association to be migrated across different instances of the 22 same transport, or to a completely different transport. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 17, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions used in this document . . . . . . . . . . . . . . 3 60 3. Transport Agnostic Security Associatiation Extension . . . . 4 61 3.1. Extended Client Hello . . . . . . . . . . . . . . . . . . 4 62 3.2. Extended Server Hello . . . . . . . . . . . . . . . . . . 5 63 3.3. Wire Format Changes . . . . . . . . . . . . . . . . . . . 6 64 4. Clashing HOTP CIDs . . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 8.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 DTLS security context demultiplexing is done via the 5-tuple. 76 Therefore, the security association needs to be re-negotiated from 77 scratch whenever the transport identifiers change. For example, when 78 moving the network attachment from WLAN to a cellular connection, or 79 when the IP address of the IoT devices changes during a sleep cycle. 80 A NAT device may also modify the source UDP port after a short idle 81 period. In such cases, there is not enough information in the DTLS 82 record header for a server that is handling multiple concurrent 83 sessions to associate the new address to an existing client. 85 This memo proposes a new TLS extension [RFC6066] that provides the 86 ability to negotiate, at handshake time, a transport independent 87 identifier that is unique per security association. We call this 88 identifier Connection ID (CID). Its function is to effectively 89 decouple the DTLS session from the underlying transport protocol, 90 allowing the same DTLS security association to be migrated across 91 different instances of the same transport, or even to a completely 92 different transport - e.g., from UDP to GSM-SMS as showed in 93 Figure 1. 95 00 96 /\ 97 : 98 IP UDP : DTLS Record Header 99 +-----+-----+-------+ +-----+-----+ : +---------+-------+------ 100 | src | dst | proto | | src | dst | : | Seq#i | CID | ... 101 +-----+-----+-------+ +-----+-----+ : +---------+-------+------ 102 `----------------+----------------' : ^ 103 `................ : .............' 104 : 105 GSM-SMS : DTLS Record Header 106 +-------+-------+ : +---------+-------+----- 107 | tp-oa | tp-da | : | Seq#i+1 | CID | ... 108 +-------+-------+ : +---------+-------+----- 109 : 110 \/ 111 00 113 Figure 1: Transparent Handover of DTLS Session 115 We present two methods for producing the CID: the first uses a single 116 value generated unilaterally by the server which is fixed throughout 117 the session, whereas the second provides a sequence of identifiers 118 that are created using a HMAC-based OTP algorithm [RFC4226] keyed 119 with the session shared secret. The latter allows a client to shift 120 to a new identifier, for example when switching networks, and is 121 intended as a mechanism to counteract tracking. However, it must be 122 noted that this is not generally applicable as a tracking-protection 123 measure: in fact, it becomes totally ineffective when the client is 124 oblivious of changes in the underlying transport identifiers (e.g., 125 on NAT rebind after timeout), and also does not guarantee unique 126 identifiers (see Section 4 for further details). Both methods 127 generate a CID that is 32-bits in size, like the Security Parameter 128 Index (SPI) in IPsec [RFC4301]. 130 Similar approaches to support transparent handover of a DTLS session 131 have been described in [I-D.barrett-mobile-dtls] and [DTLSMOB]. 133 2. Conventions used in this document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in 138 [RFC2119]. 140 3. Transport Agnostic Security Associatiation Extension 142 In order to negotiate a Transport Agnostic Security Association, 143 clients include an extension of type "ta_sa" in the extended client 144 hello (Section 3.1). Servers that receive an extended hello 145 containing a "ta_sa" extension MAY agree to use a Transport Agnostic 146 Security Association by including an extension of type "ta_sa" in the 147 extended server hello (Section 3.2). 149 If both server and client agree, the DTLSCiphertext format does 150 change after the DTLS connection state is updated; i.e.: for the 151 sending side, after the ChangeCipherSpec message is sent, for the 152 receiving sides, after the ChangeCipherSpec is received. 154 The DTLSCiphertext format is changed for both the client and the 155 server. However, only a client can initiate a switch to an unused 156 'cid' value; a server MUST utilize the same value seen on the last 157 valid message received by the client. A server which receives a 158 'cid' value which is not expected (e.g., a value outside its 159 advertised window) MAY ignore the packet. 161 struct { 162 ContentType type; 163 ProtocolVersion version; 164 uint16 epoch; 165 uint48 sequence_number; 166 uint32 cid; // New field 167 uint16 length; 168 select (CipherSpec.cipher_type) { 169 case block: GenericBlockCipher; 170 case aead: GenericAEADCipher; 171 } fragment; 172 } DTLSCiphertext; 174 Figure 2: Modified DTLS Record Format 176 3.1. Extended Client Hello 178 In order to negotiate a Transport Agnostic Security Association, 179 clients include an extension of type "ta_sa" in the extended client 180 hello. The "extension_data" field of this extension SHALL contain 181 the ClientSecAssocData structure in Figure 3. 183 In case the fixed(0) type has been negotiated, the 'cid' of the 184 packets after ChangeCipherSpec is sent explicitly by the server. 186 In case the hotp(1) type has been negotiated, the initial 'cid' is 187 calculated using the HOTP algorithm ([RFC4226]) as follows: 189 o A 20-byte string is generated using a [RFC5705] exporter. The key 190 material exporter uses the label "EXPORTER-ta-security- 191 association-hotp" without the quotes, and without any context 192 value. 193 o The initial 'cid' equals to the first HOTP value (i.e., the 31-bit 194 value of Sbits in [RFC4226] notation), generated by using the 195 previously exported value as K. 197 Subsequent values of the HOTP algorithm can be used in place of the 198 initial, as long as they fall into the negotiated window_size (see 199 Figure 4). 201 enum { 202 fixed(0), hotp(1), (255) 203 } SecAssocType; 205 struct { 206 SecAssocType types<1..2^8-1>; 207 } ClientSecAssocData; 209 Figure 3: ta_sa extension, client 211 3.2. Extended Server Hello 213 Servers that receive an extended hello containing a "ta_sa" extension 214 MAY agree to use a Transport Agnostic Security Association by 215 including an extension of type "ta_sa", with "extension_data" being 216 ServerSecAssocData in the extended server hello (Figure 4). 218 struct { 219 SecAssocType type; 220 select (type) { 221 case fixed: 222 struct { 223 uint32 cid_value; 224 }; 225 case hotp: 226 struct { 227 uint16 window_size; 228 }; 229 }; 230 } ServerSecAssocData; 232 Figure 4: ta_sa extension, server 234 In case the fixed(0) type is chosen, 'cid_value' contains the value 235 to be used as 'cid'. In case hotp(1) type is chosen, 'window_size' 236 must be greater or equal to 1, indicating the number of HOTP values 237 that the server can recognize for this particular client. 239 3.3. Wire Format Changes 241 How to signal the modified wire format to the receiving end is 242 currently an open problem. 244 Note that moving the cid after the length field and computing the 245 difference between the UDP datagram's and DTLS record's lengths is 246 not an option because there is no guarantee that UDP datagrams carry 247 one and one only DTLS record (Section 4.1.1. of [RFC6347]). 249 Ideally, we would just bump the version number, but there seems to be 250 limited room for maneuver given the way TLS encodes version 251 information in the record header, and also given that we want CID to 252 work with DTLS 1.2 and later. 254 More discussion needed to sort out this point. 256 4. Clashing HOTP CIDs 258 HOTP behaves like a PRF, thus uniformly distributing the produced 259 CIDs across the 32-bit space. Table 1 presents the probability to 260 end up with two separate sessions having the same HOTP CID when the 261 number of concurrent sessions is increased. 263 +----------+---------------------------------------------+ 264 | Sessions | Collision probability | 265 +----------+---------------------------------------------+ 266 | 10 | 1.16415320717e-08, or about 1 in 85,899,347 | 267 | 100 | 1.16415254059e-06, or about 1 in 858,994 | 268 | 1000 | 0.000116408545826, or about 1 in 8,590 | 269 | 10000 | 0.011574031737, or about 1 in 86 | 270 | 100000 | 0.687813095694, or about 1 in 1 | 271 | 1000000 | 1.0, or about 1 in 1 | 272 +----------+---------------------------------------------+ 274 Table 1 276 The takeaway is that 32-bits are probably too few for highly loaded 277 servers that want to do HOTP as their primary CID allocation 278 strategy. An alternative would be for the server to stop negotiating 279 'hotp' and fall back to 'fixed' when the number of active sessions 280 crosses some threshold; another would be to increase the CID space to 281 40 or 48 bits when HOTP is used. 283 5. Security Considerations 285 TODO 287 6. IANA Considerations 289 This document adds a new extension for DTLS: ts_sa(TODO). This 290 extension MUST only be used with DTLS, and not with TLS. This 291 extension is assigned from the TLS ExtensionType registry defined in 292 [RFC5246]. 294 7. Acknowledgments 296 Thanks to Achim Krauss, Carsten Bormann, Kai Hudalla, Simon Bernard, 297 Stephen Farrell, for helpful comments and discussions that have 298 shaped the document. 300 This work is partially supported by the European Commission under 301 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 302 for a Middleboxed Internet (MAMI). This support does not imply 303 endorsement. 305 8. References 307 8.1. Normative References 309 [I-D.ietf-tls-tls13] 310 Rescorla, E., "The Transport Layer Security (TLS) Protocol 311 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 312 October 2016. 314 [I-D.rescorla-tls-dtls13] 315 Rescorla, E. and H. Tschofenig, "The Datagram Transport 316 Layer Security (DTLS) Protocol Version 1.3", draft- 317 rescorla-tls-dtls13-00 (work in progress), October 2016. 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, 321 DOI 10.17487/RFC2119, March 1997, 322 . 324 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 325 O. Ranen, "HOTP: An HMAC-Based One-Time Password 326 Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, 327 . 329 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 330 (TLS) Protocol Version 1.2", RFC 5246, 331 DOI 10.17487/RFC5246, August 2008, 332 . 334 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 335 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 336 March 2010, . 338 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 339 Extensions: Extension Definitions", RFC 6066, 340 DOI 10.17487/RFC6066, January 2011, 341 . 343 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 344 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 345 January 2012, . 347 8.2. Informative References 349 [DTLSMOB] Seggelmann, R., Tuexen, M., and E. Rathgeb, "DTLS 350 Mobility", 2012. 352 [I-D.barrett-mobile-dtls] 353 Williams, M. and J. Barrett, "Mobile DTLS", draft-barrett- 354 mobile-dtls-00 (work in progress), March 2009. 356 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 357 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 358 December 2005, . 360 Authors' Addresses 362 Nikos Mavrogiannopoulos 363 RedHat 365 EMail: nmav@redhat.com 367 Hannes Tschofenig 368 ARM 370 EMail: hannes.tschofenig@arm.com 371 Thomas Fossati 372 Nokia 374 EMail: thomas.fossati@nokia.com