idnits 2.17.1 draft-mavrogiannopoulos-tls-cid-01.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 (May 16, 2017) is 2537 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 376, but no explicit reference was found in the text == Unused Reference: 'I-D.rescorla-tls-dtls13' is defined on line 381, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-20 ** 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 (~~), 4 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: November 17, 2017 ARM 6 T. Fossati 7 Nokia 8 May 16, 2017 10 Datagram Transport Transport Layer Security (DTLS) Transport-Agnostic 11 Security Association Extension 12 draft-mavrogiannopoulos-tls-cid-01 14 Abstract 16 This memo proposes a new Datagram Transport Transport Layer Security 17 (DTLS) extension for DTLS 1.2 that provides the ability to negotiate, 18 during handshake, a transport independent identifier that is unique 19 per security association. This identifier effectively decouples the 20 DTLS session from the underlying transport protocol, allowing the 21 same security association to be migrated across different instances 22 of the 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 November 17, 2017. 41 Copyright Notice 43 Copyright (c) 2017 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. Handling unknown CIDs . . . . . . . . . . . . . . . . . . 6 64 3.4. Wire Format Changes . . . . . . . . . . . . . . . . . . . 6 65 3.5. De-duplication Algorithm . . . . . . . . . . . . . . . . 7 66 4. Clashing HOTP CIDs . . . . . . . . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 8.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 DTLS security context demultiplexing is done via the 5-tuple. 78 Therefore, the security association needs to be re-negotiated from 79 scratch whenever the transport identifiers change. For example, when 80 moving the network attachment from WLAN to a cellular connection, or 81 when the IP address of the IoT devices changes during a sleep cycle. 82 A NAT device may also modify the source UDP port after a short idle 83 period. In such cases, there is not enough information in the DTLS 84 record header for a server that is handling multiple concurrent 85 sessions to associate the new address to an existing client. 87 This memo proposes a new TLS extension [RFC6066] for DTLS 1.2 that 88 provides the ability to negotiate, at handshake time, a transport 89 independent identifier that is unique per security association. We 90 call this identifier Connection ID (CID). Its function is to 91 effectively decouple the DTLS session from the underlying transport 92 protocol, allowing the same DTLS security association to be migrated 93 across different instances of the same transport, or even to a 94 completely different transport - e.g., from UDP to GSM-SMS as showed 95 in Figure 1. 97 00 98 /\ 99 : 100 IP UDP : DTLS Record Header 101 +-----+-----+-------+ +-----+-----+ : +---------+-------+------ 102 | src | dst | proto | | src | dst | : | Seq#i | CID | ... 103 +-----+-----+-------+ +-----+-----+ : +---------+-------+------ 104 `----------------+----------------' : ^ 105 `................ : .............' 106 : 107 GSM-SMS : DTLS Record Header 108 +-------+-------+ : +---------+-------+----- 109 | tp-oa | tp-da | : | Seq#i+1 | CID | ... 110 +-------+-------+ : +---------+-------+----- 111 : 112 \/ 113 00 115 Figure 1: Transparent Handover of DTLS Session 117 We present two methods for producing the CID: the first uses a single 118 value generated unilaterally by the server which is fixed throughout 119 the session, whereas the second provides a sequence of identifiers 120 that are created using a HMAC-based OTP algorithm [RFC4226] keyed 121 with a per-session shared secret (see Section 3.1 for details). The 122 latter allows a client to shift to a new identifier, for example when 123 switching networks, and is intended as a mechanism to counteract 124 tracking by third party observers. However, it must be noted that 125 this is not generally applicable as a tracking-protection measure: in 126 fact, it becomes totally ineffective when the client is oblivious of 127 changes in the underlying transport identifiers (e.g., on NAT rebind 128 after timeout), and also does not guarantee unique identifiers (see 129 Section 4 for further details). Both methods generate a CID that is 130 32-bits in size, like the Security Parameter Index (SPI) in IPsec 131 [RFC4301]. 133 Similar approaches to support transparent handover of a DTLS session 134 have been described in [I-D.barrett-mobile-dtls] and [DTLSMOB]. 136 2. Conventions used in this document 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in 141 [RFC2119]. 143 3. Transport Agnostic Security Associatiation Extension 145 In order to negotiate a Transport Agnostic Security Association, 146 clients include an extension of type "ta_sa" in the extended client 147 hello (Section 3.1). Servers that receive an extended hello 148 containing a "ta_sa" extension MAY agree to use a Transport Agnostic 149 Security Association by including an extension of type "ta_sa" in the 150 extended server hello (Section 3.2). 152 If both server and client agree, the DTLSCiphertext format does 153 change after the DTLS connection state is updated; i.e.: for the 154 sending side, after the ChangeCipherSpec message is sent, for the 155 receiving sides, after the ChangeCipherSpec is received. 157 The DTLSCiphertext format is changed for both the client and the 158 server. However, only a client can initiate a switch to an unused 159 'cid' value; a server MUST utilize the same value seen on the last 160 valid message received by the client. 162 struct { 163 ContentType type; 164 ProtocolVersion version; 165 uint16 epoch; 166 uint48 sequence_number; 167 uint32 cid; // New field 168 uint16 length; 169 select (CipherSpec.cipher_type) { 170 case block: GenericBlockCipher; 171 case aead: GenericAEADCipher; 172 } fragment; 173 } DTLSCiphertext; 175 Figure 2: Modified DTLS Record Format 177 See Section 3.3 for details on how to handle receipt of unknown or 178 unexpected CIDs. 180 3.1. Extended Client Hello 182 In order to negotiate a Transport Agnostic Security Association, 183 clients include an extension of type "ta_sa" in the extended client 184 hello. The "extension_data" field of this extension SHALL contain 185 the ClientSecAssocData structure in Figure 3. 187 In case the fixed(0) type has been negotiated, the 'cid' of the 188 packets after ChangeCipherSpec is sent explicitly by the server. 190 In case the hotp(1) type has been negotiated, the initial 'cid' is 191 calculated using the HOTP algorithm ([RFC4226]) as follows: 193 o A 20-byte string is generated using a [RFC5705] exporter. The key 194 material exporter uses the label "EXPORTER-ta-security- 195 association-hotp" without the quotes, and without any context 196 value. 197 o The initial 'cid' equals to the first HOTP value (i.e., the 31-bit 198 value of Sbits in [RFC4226] notation), generated by using the 199 previously exported value as K. 201 Subsequent values of the HOTP algorithm can be used in place of the 202 initial, as long as they fall into the negotiated window_size (see 203 Figure 4). 205 enum { 206 fixed(0), hotp(1), (255) 207 } SecAssocType; 209 struct { 210 SecAssocType types<1..2^8-1>; 211 } ClientSecAssocData; 213 Figure 3: ta_sa extension, client 215 3.2. Extended Server Hello 217 Servers that receive an extended hello containing a "ta_sa" extension 218 MAY agree to use a Transport Agnostic Security Association by 219 including an extension of type "ta_sa", with "extension_data" being 220 ServerSecAssocData in the extended server hello (Figure 4). 222 struct { 223 SecAssocType type; 224 select (type) { 225 case fixed: 226 struct { 227 uint32 cid_value; 228 }; 229 case hotp: 230 struct { 231 uint16 window_size; 232 }; 233 }; 234 } ServerSecAssocData; 236 Figure 4: ta_sa extension, server 238 In case the fixed(0) type is chosen, 'cid_value' contains the value 239 to be used as 'cid'. In case hotp(1) type is chosen, 'window_size' 240 must be greater or equal to 1, indicating the number of HOTP values 241 that the server can recognize for this particular client. 243 3.3. Handling unknown CIDs 245 Server might need to deal with unknown or unexpected CIDs. 247 An unknown CID is one that is not found in the server's lookup table. 248 This could happen because: 250 o Server reboots and looses its state; or 251 o There is a genuine bug in either client or server code (or even 252 somewhere on the network path). 254 Either way, the server will not be able to locate a suitable context 255 to use for sending an (encrypted) Alert back to the sender. 256 Therefore, the server should simply discard records containing an 257 unknown CID. 259 A CID might be unexpected if it existed but it's been already 260 shifted. This situation may arise if the packet has been delayed by 261 the network. Server MAY ignore a record carrying an unexpected CID. 263 Ignoring unknown or unexpected CIDs should also reduce the attack 264 surface. 266 3.4. Wire Format Changes 268 How to signal the modified wire format to the receiving end is 269 currently an open problem. 271 Note that moving the cid after the length field and computing the 272 difference between the UDP datagram's and DTLS record's lengths is 273 not an option because there is no guarantee that UDP datagrams carry 274 one and one only DTLS record (Section 4.1.1. of [RFC6347]). 276 Ideally, we would just bump the version number, but there seems to be 277 limited room for maneuver given the way TLS encodes version 278 information in the record header, and also given that we want CID to 279 work with DTLS 1.2 and later. 281 More discussion needed to sort out this point. 283 3.5. De-duplication Algorithm 285 The following algorithm assumes that receivers have an unambiguous 286 way to tell that the wire format is the one described in Section 3. 287 As suggested in Section 3.4, this could be signalled by a different 288 version number { TBD, TBD }. 290 In order to enqueue an incoming record to the right security context, 291 a receiver SHALL extract the 4-tuple from the UDP packet and the 292 ContentType of the TLS record. Then, if ContentType is 293 change_cipher_spec or handshake, the receiver SHALL use the sender 294 address to lookup or create (if ContentType is handshake and 295 HandshakeType is one of ClientHello or ServerHello) the session 296 context. If ContentType is one of application_data or alert, 297 receiver SHALL inspect the ProtocolVersion field and: if it is { 3, 3 298 } (i.e., TLS v1.2), use the 4-tuple to lookup the session context, if 299 it is { TBD, TBD }, extract the CID from the record and use it to 300 lookup the session context. 302 4. Clashing HOTP CIDs 304 HOTP behaves like a PRF, thus uniformly distributing the produced 305 CIDs across the 32-bit space. Table 1 presents the probability to 306 end up with two separate sessions having the same HOTP CID when the 307 number of concurrent sessions and/or the length of the CIDs sequence 308 is increased. 310 +-----------------------+-------------------------------------------+ 311 | Sessions x | Collision probability | 312 | window_size | | 313 +-----------------------+-------------------------------------------+ 314 | 10 | 1.16415320717e-08, or about 1 in | 315 | | 85,899,347 | 316 | 100 | 1.16415254059e-06, or about 1 in 858,994 | 317 | 1000 | 0.000116408545826, or about 1 in 8,590 | 318 | 10000 | 0.011574031737, or about 1 in 86 | 319 | 100000 | 0.687813095694, or about 1 in 1 | 320 | 1000000 | 1.0, or about 1 in 1 | 321 +-----------------------+-------------------------------------------+ 323 Table 1 325 The takeaway is that 32-bits are probably too few for highly loaded 326 servers that want to do HOTP as their primary CID allocation 327 strategy. An alternative would be for the server to stop negotiating 328 'hotp' and fall back to 'fixed' when the number of active sessions 329 crosses some threshold; another would be to increase the CID space to 330 40 or 48 bits when HOTP is used; yet another would be to allow the 331 length to be negotiable. 333 5. Security Considerations 335 CID does not affect the running protocol in any way other than adding 336 an un-authenticated field to the record header. As such, this 337 identifier has no effect on the overall security of the session with 338 respect to authentication, confidentiality and integrity. On the 339 other hand, since this identifier is not authenticated, it should not 340 be used in any way that assumes it is, nor be assumed to be secret or 341 unknown to an adversary. In general, this identifier should not be 342 relied on more than the IP address or UDP port numbers are. 344 To address the privacy concerns of using a fixed identifier for the 345 lifetime of a session which may roam through multiple networks, we 346 have introduced the hotp identifier type. This type of identifier 347 gives the client a chance to switch its ts_sa identity when also 348 switching its transport identifiers or network attachment (assuming 349 that client is made aware of the change before it sends a new DTLS 350 record). The choice of which type of identifier to use is a trade- 351 off between the request for privacy stated by the client and the 352 ability of the server to control the identifiers in use at each point 353 in time, as explained in Section 4. 355 6. IANA Considerations 357 This document adds a new extension for DTLS: ts_sa(TODO). This 358 extension MUST only be used with DTLS, and not with TLS. This 359 extension is assigned from the TLS ExtensionType registry defined in 360 [RFC5246]. 362 7. Acknowledgments 364 Thanks to Achim Kraus, Carsten Bormann, Kai Hudalla, Simon Bernard, 365 Stephen Farrell, for helpful comments and discussions that have 366 shaped the document. 368 This work is partially supported by the European Commission under 369 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 370 for a Middleboxed Internet (MAMI). This support does not imply 371 endorsement. 373 8. References 374 8.1. Normative References 376 [I-D.ietf-tls-tls13] 377 Rescorla, E., "The Transport Layer Security (TLS) Protocol 378 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 379 April 2017. 381 [I-D.rescorla-tls-dtls13] 382 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 383 Datagram Transport Layer Security (DTLS) Protocol Version 384 1.3", draft-rescorla-tls-dtls13-01 (work in progress), 385 March 2017. 387 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 388 Requirement Levels", BCP 14, RFC 2119, 389 DOI 10.17487/RFC2119, March 1997, 390 . 392 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 393 O. Ranen, "HOTP: An HMAC-Based One-Time Password 394 Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, 395 . 397 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 398 (TLS) Protocol Version 1.2", RFC 5246, 399 DOI 10.17487/RFC5246, August 2008, 400 . 402 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 403 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 404 March 2010, . 406 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 407 Extensions: Extension Definitions", RFC 6066, 408 DOI 10.17487/RFC6066, January 2011, 409 . 411 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 412 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 413 January 2012, . 415 8.2. Informative References 417 [DTLSMOB] Seggelmann, R., Tuexen, M., and E. Rathgeb, "DTLS 418 Mobility", 2012. 420 [I-D.barrett-mobile-dtls] 421 Williams, M. and J. Barrett, "Mobile DTLS", draft-barrett- 422 mobile-dtls-00 (work in progress), March 2009. 424 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 425 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 426 December 2005, . 428 Authors' Addresses 430 Nikos Mavrogiannopoulos 431 RedHat 433 EMail: nmav@redhat.com 435 Hannes Tschofenig 436 ARM 438 EMail: hannes.tschofenig@arm.com 440 Thomas Fossati 441 Nokia 443 EMail: thomas.fossati@nokia.com