idnits 2.17.1 draft-kuehlewind-taps-crypto-sep-02.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 both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 220: '...n: The interface MUST provide an indic...' RFC 2119 keyword, line 224: '...s: The interface MUST allow the applic...' RFC 2119 keyword, line 228: '...s: The interface MUST allow the local ...' RFC 2119 keyword, line 232: '...ime: The application SHOULD be able to...' RFC 2119 keyword, line 236: '...ial: The application SHOULD be able to...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 05, 2018) is 2236 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7301' is defined on line 512, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-10 == Outdated reference: A later version (-12) exists of draft-mglt-ipsecme-diet-esp-05 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kuehlewind 3 Internet-Draft ETH Zurich 4 Intended status: Informational T. Pauly 5 Expires: September 6, 2018 C. Wood 6 Apple Inc. 7 March 05, 2018 9 Separating Crypto Negotiation and Communication 10 draft-kuehlewind-taps-crypto-sep-02 12 Abstract 14 Secure transport protocols often consist of three logically distinct 15 components: transport, control (handshake), and record protection. 16 Typically, such a protocol contains a single module that is 17 responsible for all three functions. However, in many cases, this 18 coupling is unnecessary. For example, while cryptographic context 19 and endpoint capabilities need to be known before encrypted 20 application data can be sent on a specific transport connection, 21 there is otherwise no technical constraint that a cryptographic 22 handshake must be performed on said connection. This document 23 recommends a logical separation between transport, control, and 24 record components of secure transport protocols. We compare existing 25 protocols such as Transport Layer Security, QUIC, and IKEv2+ESP in 26 the context of this logical separation. 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 https://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 September 6, 2018. 45 Copyright Notice 47 Copyright (c) 2018 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 (https://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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Protocol Interfaces . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Control-Transport Interface . . . . . . . . . . . . . . . 5 66 3.1.1. Passive Configuration Interface . . . . . . . . . . . 5 67 3.1.2. Active Control and Introspection Interface . . . . . 6 68 3.2. Control-Record Interface . . . . . . . . . . . . . . . . 6 69 3.3. Transport-Record Interface . . . . . . . . . . . . . . . 6 70 4. Existing Mappings . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Benefits of Separation . . . . . . . . . . . . . . . . . . . 8 72 5.1. Reducing Connection Latency . . . . . . . . . . . . . . . 9 73 5.2. Protocol Flexibility . . . . . . . . . . . . . . . . . . 9 74 5.3. Protocol Capability Negotiation . . . . . . . . . . . . . 10 75 6. Transport Service Architecture Integration . . . . . . . . . 10 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 79 10. Informative References . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 Secure transport protocols are generally composed of three pieces: 86 1. A transport protocol to handle the transfer of data. 88 2. A record protocol to frame, encrypt and/or authenticate data 90 3. A control protocol to perform cryptographic handshakes, negotiate 91 shared secrets, and maintain state during the lifetime of 92 cryptographic session including session resumption and key 93 refreshment. (In the context of TLS, the control protocol is 94 called the handshake protocol.) 96 For ease of deployment and standardization, among other reasons, 97 these constituents are often tightly coupled. For example, in TLS 98 [RFC5246], the control protocol depends on the record protocol, and 99 vice versa. However, more recent transport protocols such as QUIC 100 [I-D.ietf-quic-tls] keep these pieces separate. For example, QUIC 101 uses TLS to negotiate secrets, and exports those secrets to encrypt 102 packets independent of TLS. 104 Separating these pieces is important, as new secure transport 105 protocols increasingly rely on session resumption mechanisms where 106 cryptographic context can be resumed to transmit application data 107 with the first packet without delay for connection setup and 108 negotiation. In the case where there is no cryptographic context 109 available when an application expresses the need to transmit data to 110 a certain endpoint, it must first run the control protocol on a 111 transport connection before being able to transmit application data. 112 If the control protocol can be separated from the other components, 113 then it can use another transport connection to establish secrets 114 without blocking the application's main transport connection. This 115 also opens up the possibility to run the control protocol well in 116 advance of the need to send application data, to avoid unnecessary 117 delays. For example, a client system could maintain a database of 118 endpoints it is likely to communicate with, and establish keying 119 material with a control protocol at periodic intervals to ensure 120 fresh keys for new transport connections. 122 [I-D.moskowitz-sse] proposes a similar approach. However while 123 [I-D.moskowitz-sse] proposes a new protocol to negotiate and maintain 124 long-term cryptographic sessions, this document relies on the use of 125 existing protocols and only discusses requirements for the evolution 126 of these protocols and exchange of information within one endpoint 127 locally. 129 2. Terminology 131 o Transport Protocol: A protocol that can transport messages between 132 two endpoints. This may represent the service offered to 133 applications to allow them to send and receive data before 134 encryption; and also represent the protocol that can transmit 135 control data and encrypted records. 137 o Control Protocol: A protocol that performs a cryptographic 138 handshake and, in addition, can validate and authenticate 139 endpoints, encrypt and authenticate its negotiation, and 140 ultimately generate keying material. 142 o Record Protocol: A protocol that can use keying material to 143 transform messages. A record will generally add a frame around 144 application data, and authenticate and/or encrypt the data. 146 o Keying Material: A shared secret from which pre-shared keys can be 147 derived and subsequently used to encrypt and authenticate data, 148 generated by a control protocol and used by a record protocol. 150 3. Protocol Interfaces 152 In traditional models in which the protocols are not separated out 153 into the three elements of control, record, and transport protocols, 154 there are two basic approaches to the interactions: 156 1. The transport protocol provides data to the security protocol and 157 gets back an encrypted version of the data to be sent (control 158 and record protocols are combined). 160 2. The security protocol provides keying material to the transport 161 protocol, and the transport protocol is responsible for 162 encrypting data (transport and record protocols are combined). 164 By teasing apart all three portions as separate protocols, there end 165 up being six interface points: 167 Application Data 168 | ^ 169 | | 170 +----V----+-----+ (1) +---------------+ 171 | +----------------> | 172 | Transport | | Control | 173 | <----------------+ | 174 +-+-----^-------+ (2) +-----+-----^---+ 175 | | | | 176 | |(6) (3)| | 177 | | | |(4) 178 | | +---------------+ | | 179 | +--------+ <-----+ | 180 |(5) | Record | | 181 +--------------> +-----------+ 182 +---------------+ 184 Figure 1: Secure Transport Protocol Components and Interactions 186 1. A transport protocol depends upon a control protocol to establish 187 keying material to protect application data being sent through 188 the transport. The main interface it relies upon is starting the 189 control channel, or handshake, or ensuring that the material is 190 ready. 192 2. A control protocol depends upon a transport protocol in order to 193 send and receive negotiation messages with the remote peer. 195 3. A control protocol sends its keying material and cryptographic 196 context to the record protocol to use. 198 4. A record protocol may signal state expiration events to a control 199 protocol. 201 5. A transport protocol uses a record protocol to send and receive 202 application data. 204 6. A record protocol uses a transport protocol to send and receive 205 encrypted data. 207 3.1. Control-Transport Interface 209 Note that for the purposes of this interface description, it is 210 assumed that the application is primarily interacting with the 211 transport protocol, and thus the control protocol interacts with the 212 application primarily through the abstraction of the transport 213 protocol. Since security protocol interfaces often require pre- 214 connection and active behavior on behalf of clients, we further 215 categorize the following interfaces based on whether they are meant 216 for passive configuration or active control. 218 3.1.1. Passive Configuration Interface 220 o Start negotiation: The interface MUST provide an indication to 221 start the protocol handshake for key negotiation, and have a way 222 to be notified when the handshake is complete. 224 o Identity constraints: The interface MUST allow the application to 225 constrain the identities that it will accept a connection to, such 226 as the hostname it expects to be provided in certificate SAN. 228 o Local identities: The interface MUST allow the local identity to 229 be set via a raw private key or interface to one to perform 230 cryptographic operations such as signing and decryption. 232 o Caching domain and lifetime: The application SHOULD be able to 233 specify the instances of the protocol that can share cached keys, 234 as well as the lifetime of cached resources. 236 o Pre-shared keying material: The application SHOULD be able to 237 specify pre-share keying material to use to bootstrap connections. 238 The control protocol can pass this directly to the record protocol 239 for use. 241 o The protocol SHOULD allow applications to negotiate application 242 protocols and related information. 244 o The protocol SHOULD allow applications to specify negotiable 245 cryptographic algorithm suites. 247 3.1.2. Active Control and Introspection Interface 249 o State changes: The interface SHOULD provide a way for the 250 transport to be notified of important state changes during the 251 protocol execution and session lifetime, e.g., when the handshake 252 begins, ends, or when a key update occurs. 254 o Validation: The interface MUST provide a way for the application 255 to participate in the endpoint authentication and validation, 256 which can either be specified as parameters to define how the 257 peer's authentication can be validated, or when the protocol 258 provides the authentication information for the application to 259 inspect directly. 261 o The protocol SHOULD expose the peer's identity information during 262 and after connection establishment. 264 3.2. Control-Record Interface 266 o Key export: The interface MUST provide a way to export keying 267 material from a control protocol to a record protocol with well- 268 defined cryptographic properties, e.g., "forward-secure." 270 o Key lifetime and rotation: The interface MUST provide a way for 271 the control protocol to define key lifetime bounds in terms of 272 _time_ or _bytes encrypted_ and, additionally, provide a way to 273 forcefully update cryptographic session keys at will. The record 274 protocol MUST be able to signal back to the control protocol that 275 a lifetime has been reached and that rotation is required. These 276 values SHOULD be configurable by the application. 278 3.3. Transport-Record Interface 280 o Transform data: The interface MUST provide a way to send raw 281 application data from the transport protocol to a record protocol 282 to transform it based on the keying material. This data is then 283 sent out by the transport protocol. The same applies for inbound 284 data, in which inbound transport data is transformed by the record 285 protocol into raw application data. 287 o Reliability: The transport MUST specify if messages are 288 transmitted reliable and in order. 290 o Maximum message size (optional): The transport may specify a 291 maximum message size for the encrypted data if e.g. a datagram 292 transport is used 294 4. Existing Mappings 296 In this section we document existing mappings between common 297 transport security protocols and the three components described in 298 Section I. 300 o TLS/DTLS: TLS [RFC5246] and DTLS [RFC6347] is a combination of a 301 control (handshake) and record protocol, with a dependency on some 302 underlying transport. 304 Application (configure and I/O) 305 | ^ 306 | | 307 +---------V-----+--------+ 308 | Connection | 309 +----+----^--------------+ 310 +----------|----|------------------------------------+ 311 | | | --TLS-- | 312 | +----V----+-----+ +---------------+ | 313 | | +---------> | | 314 | | Control | | Record | | 315 | | (Handshake) <---------+ | | 316 | +---------------+ +----+------^---+ | 317 | | | | 318 +------------------------------------|------|--------+ 319 | | 320 +----V------+----+ 321 | Transport | 322 +----------------+ 324 o QUIC + TLS: The emerging QUIC standard is decomposed into the 325 three pieces outlined in Section I [I-D.ietf-quic-tls]. TLS is 326 used as the control protocol running on a dedicated QUIC stream, a 327 QUIC-specific record protocol encrypts and encapsulates stream 328 frames, and the main QUIC component handles the transport of these 329 frames. 331 Application (configure and I/O) 332 | ^ 333 +-----|-----|------------------------------------+ 334 | | | --QUIC-- | 335 | | | | 336 | +--V-----+---+ +--------------+ | 337 | | QUIC |------------>| TLS | | 338 | | (transport)| | (control) | | 339 | | <-------------+ | | 340 | ++---^--+--^-+ +--^-------+---+ | 341 | | | | | | | | 342 | | | | | | | | 343 | | | | | +V---------+-+ | | | 344 | | | | +--> Packet +--+ | | 345 | | | | | Protection | | | 346 | | | +-----+ (record) <----------+ | 347 | | | +------------+ | 348 | | | | 349 +---|---|----------+-----------------------------+ 350 | | 351 +---V---+--------+ 352 | Transport | 353 +----------------+ 355 o IKEv2 + ESP: IKEv2 [RFC7296] is a control protocol commonly used 356 to establish keys for use in IPsec (often VPN) deployments. It is 357 already a distinct protocol from its commonly paired record 358 protocol, which is ESP [RFC4303]. ESP encrypts and authenticates 359 IP datagrams, and sends them as datagrams over a transport 360 mechanism such, e.g., IP or UDP. 362 Application (configure) Application (I/O) 363 | ^ | ^ 364 +----V----+-----+ +-----V----+----+ 365 | +---------> | 366 | IKEv2 | | Record | 367 | <---------+ | 368 +----+------^---+ +----+------^---+ 369 | | | | 370 +----V------+------------------V------+----+ 371 | (Unreliable) Transport | 372 +------------------------------------------+ 374 5. Benefits of Separation 375 5.1. Reducing Connection Latency 377 One of the clearest benefits of separating the control protocol from 378 the record protocol is that the cryptographic handshake can be 379 performed out-of-band from the application's data transfer. This 380 should essentially reduce the number of RTTs required before being 381 able to send data by the full length of the handshake (which is 382 commonly 1 or 2 RTTs in the best cases for TLS 1.2 and IKEv2, 383 potentially more if cookie challenges or extended authentication are 384 required). 386 To avoid long-lived transport connections that wouldn't be actively 387 used, and thus would be vulnerable to timeouts on NATs or firewalls, 388 an obvious approach to separating the control and record protocols is 389 to use different transport connections for the early handshake and 390 the data transfer. However, this approach of using separate 391 connections will not always save RTTs if the cryptographic handshake 392 and data transfer are back-to-back. Each connection may require its 393 own transport protocol handshake, and if the data transfer must wait 394 for two transport protocols to establish and the cryptographic 395 handshake to be finished before sending, then it may experience 396 higher latency. Implementations SHOULD avoid this by either allowing 397 the control and record protocols to share a single transport 398 connection or open two connections in parallel when the control 399 protocol has not pre-fetched keys. Latency benefits, however, can 400 even be achieved when ensuring that this scenario does not occur by 401 always having the control protocol refresh the keys whenever old ones 402 are near expiry. 404 5.2. Protocol Flexibility 406 Separation of the control, record, and transport protocols also 407 allows for more flexible composition of protocols with one another. 408 If a deployment uses a control protocol like TLS, which requires a 409 stream-based transport protocol like TCP, separation of protocols 410 will allow it to use the resulting keys for record protocols that run 411 on datagram transport protocols like UDP. 413 This flexibility may be useful for implementations that are 414 optimizing for packet size by choosing minimal/lightweight record 415 protocols, while being able to use commonly supported control 416 protocols like TLS. One example here is the approach of a VPN tunnel 417 that uses ESP or Diet-ESP [I-D.mglt-ipsecme-diet-esp] to encrypt 418 datagrams, but uses TLS for establishing keys. 420 5.3. Protocol Capability Negotiation 422 Enabling the use of a different transport protocol for the actual 423 data transmission than for the cryptographic handshakes opens also 424 the possibility to negotiate protocol capabilities for the data 425 transmission. For TLS, usually TCP is the appropriate transport 426 protocol to use, as it is also widely supported by endpoints. 427 Allowing an endpoint to indicate the support of other, new transport 428 protocols within the TCP connection that is used for the 429 cryptographic handshake, provides a dynamic transition path to enable 430 easy deployment of new protocols. 432 6. Transport Service Architecture Integration 434 The Transport Services Architecture ([I-D.pauly-taps-arch]) describes 435 a system that can provide transport security functionality behind a 436 common interface. Such systems and their APIs provide applications 437 with the ability to establish connections for sending and receiving 438 data. The lifetime of a connection is comprised of a pre- 439 establishment configuration stage, established (connected) stage, and 440 terminated stage. Pre-establishment properties configured include: 441 Local and Remote Endpoint, protocol selection properties, and 442 specific protocol options. Applications configure security protocols 443 during pre-establishment using the passive interfaces described in 444 Section Section 3.1. Active control interfaces are exercised during 445 connection establishment, i.e., from pre-establishment to established 446 states. Applications can query connection metadata or state 447 information, e.g., peer identity information, during and after 448 connection establishment. 450 7. IANA Considerations 452 This document has on request to IANA. 454 8. Security Considerations 456 (editor's note: this section will be added later. However, this 457 document discusses the use of cryptographic context for transport 458 connections and as such it has security relevant consideration within 459 the whole document.) 461 9. Acknowledgments 463 This work is partially supported by the European Commission under 464 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 465 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 466 for Education, Research, and Innovation under contract no. 15.0268. 468 This support does not imply endorsement. Thanks to Brian Trammell 469 for reviewing this draft. 471 10. Informative References 473 [I-D.ietf-quic-tls] 474 Thomson, M. and S. Turner, "Using Transport Layer Security 475 (TLS) to Secure QUIC", draft-ietf-quic-tls-10 (work in 476 progress), March 2018. 478 [I-D.mglt-ipsecme-diet-esp] 479 Migault, D., Guggemos, T., and C. Bormann, "ESP Header 480 Compression and Diet-ESP", draft-mglt-ipsecme-diet-esp-05 481 (work in progress), October 2017. 483 [I-D.moskowitz-sse] 484 Moskowitz, R., Faynberg, I., Lu, H., Hares, S., and P. 485 Giacomin, "Session Security Envelope", draft-moskowitz- 486 sse-05 (work in progress), June 2017. 488 [I-D.pauly-taps-arch] 489 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 490 Perkins, C., Tiesel, P., and C. Wood, "An Architecture for 491 Transport Services", draft-pauly-taps-arch-00 (work in 492 progress), February 2018. 494 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 495 RFC 4303, DOI 10.17487/RFC4303, December 2005, 496 . 498 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 499 (TLS) Protocol Version 1.2", RFC 5246, 500 DOI 10.17487/RFC5246, August 2008, 501 . 503 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 504 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 505 January 2012, . 507 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 508 Kivinen, "Internet Key Exchange Protocol Version 2 509 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 510 2014, . 512 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 513 "Transport Layer Security (TLS) Application-Layer Protocol 514 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 515 July 2014, . 517 Authors' Addresses 519 Mirja Kuehlewind 520 ETH Zurich 521 Gloriastrasse 35 522 8092 Zurich 523 Switzerland 525 Email: mirja.kuehlewind@tik.ee.ethz.ch 527 Tommy Pauly 528 Apple Inc. 529 One Apple Park Way 530 Cupertino, California 95014 531 United States of America 533 Email: tpauly@apple.com 535 Christopher A. Wood 536 Apple Inc. 537 One Apple Park Way 538 Cupertino, California 95014 539 United States of America 541 Email: cawood@apple.com