idnits 2.17.1 draft-kuehlewind-taps-crypto-sep-03.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 (June 30, 2018) is 2124 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7301' is defined on line 599, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-13 == Outdated reference: A later version (-19) exists of draft-ietf-taps-arch-00 == Outdated reference: A later version (-12) exists of draft-mglt-ipsecme-diet-esp-06 -- 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 (~~), 5 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: January 1, 2019 C. Wood 6 Apple Inc. 7 June 30, 2018 9 Separating Crypto Negotiation and Communication 10 draft-kuehlewind-taps-crypto-sep-03 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 January 1, 2019. 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 . . . . . . . . . . . . . . . . . . . 10 72 5.1. Reducing Connection Latency . . . . . . . . . . . . . . . 10 73 5.2. Protocol Flexibility . . . . . . . . . . . . . . . . . . 11 74 5.3. Protocol Capability and Upgrade Negotiation . . . . . . . 11 75 6. Transport Service Architecture Integration . . . . . . . . . 11 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 79 10. Informative References . . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 o OpenVPN [OpenVPN]: OpenVPN consists of two separate stacks - one 375 for TLS, which is used for key exchange and derivation, and the 376 other as an interface to tunnel IP packets over UDP. A common 377 multiplexing layer is used to send TLS and OpenVPN framed packets 378 over an unreliable transport layer. OpenVPN adds a reliability 379 layer to TLS to ensure packets are sent and processed in order. 380 Running over TCP naturally provides this reliability. After the 381 TLS connection finishes, OpenVPN extracts encryption and 382 authentication keys from TLS, via the PRF, and uses them to 383 encrypt and authenticate IP packets. Packets are framed using a 384 simple length-type-value envelope, wherein the type specifies the 385 contents of the packet, e.g., channel control (TLS ciphertext) 386 bytes. 388 Application (configure and I/O) 389 + ^ 390 | | 391 +--v--------+ 392 | OpenVPN | +-----------+ 393 | interface | | TLS | 394 | + record | | (control) | 395 +-----------+ +-----------+ 396 | | 397 | +-----v-----+ 398 | |reliability| 399 | | layer | 400 | +-----------+ 401 | | 402 +-------+ +--------+ 403 | | 404 +----v---V------+ 405 | OpenVPN | 406 | (multiplexer) | 407 +---------------+ 408 | 409 +-------v-------+ 410 | (Unreliable) | 411 | Transport | 412 +---------------+ 414 o DTLS-SRTP: DTLS [RFC5764] is commonly used as a way to perform 415 mutual authentication and key agreement for SRTP [RFC5763]. 416 (Here, certificates marshal public keys between endpoints. Thus, 417 self- signed certificates may be used if peers do not mutually 418 trust one another, as is common on the Internet.) When DTLS is 419 used, certificate fingerprints are transmitted out-of-band using 420 SIP. Peers typically verify that DTLS-offered certificates match 421 that which are offered over SIP. This prevents active attacks on 422 RTP, but not on the signaling (SIP or WebRTC) channel. 424 Application (configure and I/O) 425 + ^ 426 | | 427 +--v--------+ 428 | SRTP | +-----------+ 429 | interface | | DTLS | 430 | + record | | (control) | 431 +-----------+ +-----------+ 432 | | 433 +-------+ +--------+ 434 | | 435 +----V---v------+ 436 | (Unreliable) | 437 | Transport | 438 +---------------+ 440 5. Benefits of Separation 442 5.1. Reducing Connection Latency 444 One of the clearest benefits of separating the control protocol from 445 the record protocol is that the cryptographic handshake can be 446 performed out-of-band from the application's data transfer. This 447 should essentially reduce the number of RTTs required before being 448 able to send data by the full length of the handshake (which is 449 commonly 1 or 2 RTTs in the best cases for TLS 1.2 and IKEv2, 450 potentially more if cookie challenges or extended authentication are 451 required). 453 To avoid long-lived transport connections that wouldn't be actively 454 used, and thus would be vulnerable to timeouts on NATs or firewalls, 455 an obvious approach to separating the control and record protocols is 456 to use different transport connections for the early handshake and 457 the data transfer. However, this approach of using separate 458 connections will not always save RTTs if the cryptographic handshake 459 and data transfer are back-to-back. Each connection may require its 460 own transport protocol handshake, and if the data transfer must wait 461 for two transport protocols to establish and the cryptographic 462 handshake to be finished before sending, then it may experience 463 higher latency. Implementations SHOULD avoid this by either allowing 464 the control and record protocols to share a single transport 465 connection or open two connections in parallel when the control 466 protocol has not pre-fetched keys. Latency benefits, however, can 467 even be achieved when ensuring that this scenario does not occur by 468 always having the control protocol refresh the keys whenever old ones 469 are near expiry. 471 5.2. Protocol Flexibility 473 Separation of the control, record, and transport protocols also 474 allows for more flexible composition of protocols with one another. 475 If a deployment uses a control protocol like TLS, which requires a 476 stream-based transport protocol like TCP, separation of protocols 477 will allow it to use the resulting keys for record protocols that run 478 on datagram transport protocols like UDP. 480 This flexibility may be useful for implementations that are 481 optimizing for packet size by choosing minimal/lightweight record 482 protocols, while being able to use commonly supported control 483 protocols like TLS. One example here is the approach of a VPN tunnel 484 that uses ESP or Diet-ESP [I-D.mglt-ipsecme-diet-esp] to encrypt 485 datagrams, but uses TLS for establishing keys. This design is 486 similar to that used by OpenVPN [OpenVPN], as described above. 488 5.3. Protocol Capability and Upgrade Negotiation 490 Enabling the use of a different transport protocol for the actual 491 data transmission than for the cryptographic handshakes opens also 492 the possibility to negotiate protocol capabilities for the data 493 transmission. For TLS, usually TCP is the appropriate transport 494 protocol to use, as it is also widely supported by endpoints. 495 Allowing an endpoint to indicate the support of other, new transport 496 protocols within the TCP connection that is used for the 497 cryptographic handshake, provides a dynamic transition path to enable 498 easy deployment of new protocols. Another example is providing an 499 upgrade path from TCP+TLS to QUIC. If TLS could negotiate the use of 500 other transport layers, such as QUIC, applications could perform an 501 abbreviated upgrade from TCP+TLS connections to QUIC, i.e., without 502 doing a full QUIC handshake. 504 6. Transport Service Architecture Integration 506 The Transport Services Architecture ([I-D.ietf-taps-arch]) describes 507 a system that can provide transport security functionality behind a 508 common interface. Such systems and their APIs provide applications 509 with the ability to establish connections for sending and receiving 510 data. The lifetime of a connection is comprised of a pre- 511 establishment configuration stage, established (connected) stage, and 512 terminated stage. Pre-establishment properties configured include: 513 Local and Remote Endpoint, protocol selection properties, and 514 specific protocol options. Applications configure security protocols 515 during pre-establishment using the passive interfaces described in 516 Section Section 3.1. Active control interfaces are exercised during 517 connection establishment, i.e., from pre-establishment to established 518 states. Applications can query connection metadata or state 519 information, e.g., peer identity information, during and after 520 connection establishment. 522 7. IANA Considerations 524 This document has on request to IANA. 526 8. Security Considerations 528 (editor's note: this section will be added later. However, this 529 document discusses the use of cryptographic context for transport 530 connections and as such it has security relevant consideration within 531 the whole document.) 533 9. Acknowledgments 535 This work is partially supported by the European Commission under 536 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 537 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 538 for Education, Research, and Innovation under contract no. 15.0268. 539 This support does not imply endorsement. Thanks to Brian Trammell 540 for reviewing this draft. 542 10. Informative References 544 [I-D.ietf-quic-tls] 545 Thomson, M. and S. Turner, "Using Transport Layer Security 546 (TLS) to Secure QUIC", draft-ietf-quic-tls-13 (work in 547 progress), June 2018. 549 [I-D.ietf-taps-arch] 550 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 551 Perkins, C., Tiesel, P., and C. Wood, "An Architecture for 552 Transport Services", draft-ietf-taps-arch-00 (work in 553 progress), April 2018. 555 [I-D.mglt-ipsecme-diet-esp] 556 Migault, D., Guggemos, T., Bormann, C., and D. Schinazi, 557 "ESP Header Compression and Diet-ESP", draft-mglt-ipsecme- 558 diet-esp-06 (work in progress), May 2018. 560 [I-D.moskowitz-sse] 561 Moskowitz, R., Faynberg, I., Lu, H., Hares, S., and P. 562 Giacomin, "Session Security Envelope", draft-moskowitz- 563 sse-05 (work in progress), June 2017. 565 [OpenVPN] "OpenVPN Security Overview", n.d., 566 . 569 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 570 RFC 4303, DOI 10.17487/RFC4303, December 2005, 571 . 573 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 574 (TLS) Protocol Version 1.2", RFC 5246, 575 DOI 10.17487/RFC5246, August 2008, 576 . 578 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 579 for Establishing a Secure Real-time Transport Protocol 580 (SRTP) Security Context Using Datagram Transport Layer 581 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 582 2010, . 584 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 585 Security (DTLS) Extension to Establish Keys for the Secure 586 Real-time Transport Protocol (SRTP)", RFC 5764, 587 DOI 10.17487/RFC5764, May 2010, 588 . 590 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 591 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 592 January 2012, . 594 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 595 Kivinen, "Internet Key Exchange Protocol Version 2 596 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 597 2014, . 599 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 600 "Transport Layer Security (TLS) Application-Layer Protocol 601 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 602 July 2014, . 604 Authors' Addresses 606 Mirja Kuehlewind 607 ETH Zurich 608 Gloriastrasse 35 609 8092 Zurich 610 Switzerland 612 Email: mirja.kuehlewind@tik.ee.ethz.ch 613 Tommy Pauly 614 Apple Inc. 615 One Apple Park Way 616 Cupertino, California 95014 617 United States of America 619 Email: tpauly@apple.com 621 Christopher A. Wood 622 Apple Inc. 623 One Apple Park Way 624 Cupertino, California 95014 625 United States of America 627 Email: cawood@apple.com