idnits 2.17.1 draft-friel-tls-atls-04.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 04, 2019) is 1635 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MAX' is mentioned on line 1428, but not defined == Missing Reference: 'X3DH' is mentioned on line 1704, but not defined == Unused Reference: 'LwM2M' is defined on line 1389, but no explicit reference was found in the text == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-33 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-29 == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-bcp56bis-09 == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-07 == Outdated reference: A later version (-04) exists of draft-rescorla-tls-ctls-02 Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Friel 3 Internet-Draft R. Barnes 4 Intended status: Informational M. Pritikin 5 Expires: May 7, 2020 Cisco 6 H. Tschofenig 7 Arm Ltd. 8 M. Baugher 9 Consultant 10 November 04, 2019 12 Application-Layer TLS 13 draft-friel-tls-atls-04 15 Abstract 17 This document specifies how TLS and DTLS can be used at the 18 application layer for the purpose of establishing secure end-to-end 19 encrypted communication security. 21 Encodings for carrying TLS and DTLS payloads are specified for HTTP 22 and CoAP to improve interoperability. While the use of TLS and DTLS 23 is straight forward we present multiple deployment scenarios to 24 illustrate the need for end-to-end application layer encryption and 25 the benefits of reusing a widely deployed and readily available 26 protocol. Application software architectures for building, and 27 network architectures for deploying application layer TLS are 28 outlined. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 7, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Application Layer End-to-End Security Use Cases . . . . . . . 4 67 3.1. Constrained Devices . . . . . . . . . . . . . . . . . . . 4 68 3.2. Bootstrapping Devices . . . . . . . . . . . . . . . . . . 6 69 4. ATLS Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5. Architecture Overview . . . . . . . . . . . . . . . . . . . . 7 71 5.1. Application Architecture . . . . . . . . . . . . . . . . 7 72 5.2. Functional Design . . . . . . . . . . . . . . . . . . . . 13 73 5.3. Network Architecture . . . . . . . . . . . . . . . . . . 15 74 6. ATLS Session Establishment . . . . . . . . . . . . . . . . . 16 75 7. ATLS over CoAP Transport . . . . . . . . . . . . . . . . . . 18 76 8. ATLS over HTTP Transport . . . . . . . . . . . . . . . . . . 19 77 8.1. Protocol Summary . . . . . . . . . . . . . . . . . . . . 20 78 8.2. Content-Type Header . . . . . . . . . . . . . . . . . . . 20 79 8.3. HTTP Status Codes . . . . . . . . . . . . . . . . . . . . 20 80 8.4. ATLS Session Tracking . . . . . . . . . . . . . . . . . . 20 81 8.5. Session Establishment and Key Exporting . . . . . . . . . 21 82 8.6. Illustrative ATLS over HTTP Session Establishment . . . . 21 83 9. Key Exporting and Application Data Encryption . . . . . . . . 22 84 9.1. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 22 85 9.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 10. TLS Ciphersuite to COSE/OSCORE Algorithm Mapping . . . . . . 23 87 11. TLS Extensions . . . . . . . . . . . . . . . . . . . . . . . 24 88 11.1. The "oscore_connection_id" Extension . . . . . . . . . . 24 89 11.2. The "cose_ext" Extension . . . . . . . . . . . . . . . . 25 90 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 91 12.1. "oscore_connection_id" TLS extension . . . . . . . . . . 25 92 12.2. TLS Ciphersuite to OSCORE/COSE Algorithm Mapping . . . . 26 93 12.3. .well-known URI Registry . . . . . . . . . . . . . . . . 26 94 12.4. Media Types Registry . . . . . . . . . . . . . . . . . . 27 95 12.5. HTTP Content-Formats Registry . . . . . . . . . . . . . 28 96 12.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 28 97 12.7. TLS Key Extractor Label . . . . . . . . . . . . . . . . 28 98 13. Security Considerations . . . . . . . . . . . . . . . . . . . 28 99 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 100 14.1. Normative References . . . . . . . . . . . . . . . . . . 29 101 14.2. Informative References . . . . . . . . . . . . . . . . . 30 102 Appendix A. Pseudo Code . . . . . . . . . . . . . . . . . . . . 32 103 A.1. OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 A.2. Java JSSE . . . . . . . . . . . . . . . . . . . . . . . . 34 105 Appendix B. ATLS and HTTP CONNECT . . . . . . . . . . . . . . . 36 106 Appendix C. Alternative Approaches to Application Layer End-to- 107 End Security . . . . . . . . . . . . . . . . . . . . 39 108 C.1. Noise . . . . . . . . . . . . . . . . . . . . . . . . . . 39 109 C.2. Signal . . . . . . . . . . . . . . . . . . . . . . . . . 40 110 C.3. Google ALTS . . . . . . . . . . . . . . . . . . . . . . . 40 111 C.4. Ephemeral Diffie-Hellman Over COSE (EDHOC) . . . . . . . 40 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 114 1. Introduction 116 There are multiple scenarios where there is a need for application 117 layer end-to-end security between clients and application services. 118 Two examples include: 120 o Constrained devices connecting via gateways to application 121 services, where different transport layer protocols may be in use 122 on either side of the gateway, with the gateway transcoding 123 between the different transport layer protocols. 125 o Bootstrapping devices that must connect to HTTP application 126 services across untrusted TLS interception middleboxes 128 These two scenarios are described in more detail in Section 3. 130 This document describes how clients and applications can leverage 131 standard TLS software stacks to establish secure end-to-end encrypted 132 connections at the application layer. TLS [RFC5246] [RFC8446] or 133 DTLS [RFC6347] [I-D.ietf-tls-dtls13] can be used and this document is 134 agnostic to the versions being used. There are multiple advantages 135 to reuse of existing TLS software stacks for establishment of 136 application layer secure connections. These include: 138 o many clients and application services already include a TLS 139 software stack, so there is no need to include yet another 140 software stack in the software build 142 o no need to define a new cryptographic negotiation, authentication, 143 and key exchange protocol between clients and services 145 o provides standards based PKI mutual authentication between clients 146 and services 148 o no need to train software developers on how to use a new 149 cryptographic protocols or libraries 151 o automatically benefit from new cipher suites by simply upgrading 152 the TLS software stack 154 o automatically benefit from new features, bugfixes, etc. in TLS 155 software stack upgrades 157 When TLS or DTLS is used at the application layer we refer to it as 158 Application-Layer TLS, or ATLS. There is, however, no difference to 159 TLS versions used over connection-oriented transports, such as TCP or 160 SCTP. The same is true for DTLS. The difference is mainly in its 161 use and the requirements placed on the underlying transport. 163 This document defines how ATLS can be used over HTTP [RFC7230] 164 [RFC7540] and over CoAP [RFC7252]. This document does not preclude 165 the use of other transports. However, defining how ATLS can be 166 established over [ZigBee], [Bluetooth], etc. is beyond the scope of 167 this document. 169 2. Terminology 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 Application-Layer TLS is referred to as ATLS throughout this 178 document. 180 3. Application Layer End-to-End Security Use Cases 182 This section describes describes a few end-to-end use cases in more 183 detail. 185 3.1. Constrained Devices 187 Two constrained device use cases are outlined here. 189 3.1.1. Constrained Device Connecting over a Non-IP Network 191 There are industry examples of smart lighting systems where 192 luminaires are connected using ZigBee to a gateway. A server 193 connects to the gateway using CoAP over DTLS. The server can control 194 the luminaires by sending messages and commands via the gateway. The 195 gateway has full access to all messages sent between the luminaires 196 and the server. 198 A generic use case similar to the smart lighting system outlined 199 above has an IoT device talking ZigBee, Bluetooth Low Energy, 200 LoRaWAN, NB-IoT, etc. to a gateway, with the gateway in turn talking 201 CoAP over DTLS or another protocol to a server located in the cloud 202 or on-premise. This is illustrated in Figure 1. 204 There are scenarios where certain messages sent between the IoT 205 device and the server must not be exposed to the gateway function. 206 Additionally, the two endpoints may not have visibility to and no 207 guarantees about what transport layer security and encryption is 208 enforced across all hops end-to-end as they only have visibility to 209 their immediate next hop. ATLS addresses these concerns. 211 +--------+ ZigBee +---------+ CoAP/DTLS +------------+ 212 | Device |-------------->| Gateway |------------->| Server | 213 +--------+ +---------+ +------------+ 214 ^ ^ 215 | | 216 +-------- Device to Server -------+ 218 Figure 1: IoT Closed Network Gateway 220 3.1.2. Constrained Device Connecting over IP 222 In this example an IoT device connecting to a gateway using a 223 suitable transport mechanism, such as ZigBee, CoAP, MQTT, etc. The 224 gateway function in turn talks HTTP over TLS (or, for example, HTTP 225 over QUIC) to an application service over the Internet. This is 226 illustrated in Figure 2. 228 The gateway may not be trusted and all messages between the IoT 229 device and the application service must be end-to-end encrypted. 230 Similar to the previous use case, the endpoints have no guarantees 231 about what level of transport layer security is enforced across all 232 hops. Again, ATLS addresses these concerns. 234 +--------+ CoAP/DTLS +------------------+ HTTP/TLS +---------+ 235 | Device |-------------->| Internet Gateway |------------>| Service | 236 +--------+ +------------------+ +---------+ 237 ^ ^ 238 | | 239 +---------Device to Cloud Service ATLS Connection----------+ 241 Figure 2: IoT Internet Gateway 243 3.2. Bootstrapping Devices 245 There are far more classes of clients being deployed on today's 246 networks than at any time previously. This poses challenges for 247 network administrators who need to manage their network and the 248 clients connecting to their network, and poses challenges for client 249 vendors and client software developers who must ensure that their 250 clients can connect to all required services. 252 One common example is where a client is deployed on a local domain 253 TCP/IP network that protects its perimeter using a TLS terminating 254 middlebox, and the client needs to establish a secure connection to a 255 service in a different network via the middlebox. This is 256 illustrated in Figure 3. 258 Traditionally, this has been enabled by the network administrator 259 deploying the necessary certificate authority trusted roots on the 260 client. This can be achieved at scale using standard tools that 261 enable the administrator to automatically push trusted roots out to 262 all client machines in the network from a centralized domain 263 controller. This works for personal computers, laptops and servers 264 running standard Operating Systems that can be centrally managed. 265 This client management process breaks for multiple classes of clients 266 that are being deployed today, there is no standard mechanism for 267 configuring trusted roots on these clients, and there is no standard 268 mechanism for these clients to securely traverse middleboxes. 270 +--------+ C->M TLS +-----------+ M->S TLS +---------+ 271 | Client |--------------->| Middlebox |------------->| Service | 272 +--------+ +-----------+ +---------+ 273 ^ ^ 274 | | 275 +-----------Client to Service ATLS Connection---------+ 277 Figure 3: Bootstrapping Devices 279 The ATLS mechanism defined in this document enables clients to 280 traverse middleboxes and establish secure connections to services 281 across network domain boundaries. The purpose of this connection may 282 simply be to facilitate a bootstrapping process, for example 283 [I-D.ietf-anima-bootstrapping-keyinfra], whereby the client securely 284 discovers the local domain certificate authorities required to 285 establish a trusted network layer TLS connection to the middlebox. 287 4. ATLS Goals 289 The high level goals driving the design of this mechanism are: 291 o enable authenticated key exchange at the application layer by 292 reusing existing technologies, 294 o ensure that ATLS packets are explicitly identified thus ensuring 295 that any middleboxes or gateways at the transport layer are 296 content aware, 298 o leverage TLS stacks and handshake protocols thus avoiding 299 introducing new software or protocol dependencies in clients and 300 applications 302 o reuse TLS [RFC5246] [RFC8446] and DTLS [RFC6347] 303 [I-D.ietf-tls-dtls13] specifications, 305 o do not mandate constraints on how the TLS stack is configured or 306 used, 308 o be forward compatible with future TLS versions including new 309 developments such as compact TLS [I-D.rescorla-tls-ctls], and 311 o ensure that the design is as simple as possible. 313 5. Architecture Overview 315 5.1. Application Architecture 317 TLS software stacks allow application developers to 'unplug' the 318 default network socket transport layer and read and write TLS records 319 directly from byte buffers. This enables application developers to 320 use ATLS, extract the raw TLS record bytes from the bottom of the TLS 321 stack, and transport these bytes over any suitable transport. The 322 TLS software stacks can generate byte streams of full TLS flights, 323 which may include multiple TLS records. Additionally, TLS software 324 stacks support Keying Material Exporters [RFC5705] and allow 325 applications to export keying material from established TLS sessions. 326 This keying material can then be used by the application for 327 encryption of data outside the context of the TLS session. This is 328 illustrated in Figure 4 below. 330 +------------+ +---------+ 331 Handshake Records | | Handshake Records | | 332 ------------------->| |------------------->| | 333 | | | Byte | 334 Unencrypted Data | TLS | Encrypted Data | | 335 ------------------->| |------------------->| Buffers | 336 | Software | | | 337 Encrypted Data | | Unencrypted Data | | 338 ------------------->| Stack |------------------->| | 339 | | +---------+ 340 Keying Material | | 341 <-------------------| | 342 + -----------+ 344 Figure 4: TLS Stack Interfaces 346 These TLS software stack APIs enable application developers to build 347 the software architectures illustrated in Figure 5 and Figure 6. 349 In both architectures, the application creates and interacts with an 350 application layer TLS session in order to generate and consume raw 351 TLS records. The application transports these raw TLS records inside 352 transport layer message bodies using whatever standard transport 353 layer stack is suitable for the application or architecture. This 354 document does not place any restrictions on the choice of transport 355 layer and any suitable protocol such as HTTP, TCP, CoAP, ZigBee, 356 Bluetooth, etc. could be used. 358 The transport layer will typically encrypt data, and this encryption 359 is completely independent from any application layer encryption. The 360 transport stack may create a transport layer TLS session. The 361 application layer TLS session and transport layer TLS session can 362 both leverage a shared, common TLS software stack. This high level 363 architecture is applicable to both clients and application services. 364 The key differences between the architectures are as follows. 366 In the model illustrated in Figure 5, the application sends all 367 sensitive data that needs to be securely exchanged with the peer 368 application through the Application TLS session in order to be 369 encrypted and decrypted. All sensitive application data is thus 370 encoded within TLS records by the TLS stack, and these TLS records 371 are transmitted over the transport layer. 373 +-------------+ 374 | | App 375 | | Data +---------+ 376 | Application |<---------->| App | +---------+ 377 | | TLS | TLS |----->| TLS | 378 | | Records | Session | | Stack | 379 | +--->|<---------->| | +---------+ 380 | | | +---------+ ^ 381 | | | |? 382 | | | Transport +-----------+ +------------+ 383 | | | Payload | Transport | | Transport | 384 | +--->|<--------->| Stack |--->| Encryption |-->Packets 385 +-------------+ +-----------+ +------------+ 387 Figure 5: TLS Stack used for all data encryption 389 In the model illustrated in Figure 6, the application establishes an 390 application layer TLS session purely for the purposes of key 391 exchange. Therefore, the only TLS records that are sent or received 392 by the application layer are TLS handshake records. Once the 393 application layer TLS session is established, the application uses 394 Keying Material Exporter [RFC5705] APIs to export keying material 395 from the TLS stack from this application layer TLS session. The 396 application can then use these exported keys to derive suitable 397 shared encryption keys with its peer for exchange of encrypted data. 398 The application encrypts and decrypts sensitive data using these 399 shared encryption keys using any suitable cryptographic library 400 (which may be part of the same library that provides the TLS stack), 401 and transports the encrypted data directly over the transport layer. 403 +--------------+ 404 | | 405 | Application | 406 | | 407 | +-------+ | +---------+ 408 | | App | | Key Export | | 409 | | Data |<---|<-----------| | 410 | | Crypto| | | App | 411 | +-------+ | TLS | TLS | +---------+ 412 | ^ | Handshake | Session |----->| TLS | 413 | | | Records | | | Stack | 414 | | +--->|<---------->| | +---------+ 415 | | | | +---------+ ^ 416 | | | | |? 417 | | | | Transport +-----------+ +------------+ 418 | | | | Payload | Transport | | Transport | 419 | +----+--->|<--------->| Stack |--->| Encryption |-->Packets 420 +--------------+ +-----------+ +------------+ 422 Figure 6: TLS stack used for key agreement and exporting 424 The choice of which application architecture to use will depend on 425 the overall solution architecture, and the underlying transport layer 426 or layers in use. While the choice of application architecture is 427 outside the scope of this document, some considerations are outlined 428 here. 430 o in some IoT use cases reducing the number of bytes transmitted is 431 important. [I-D.mattsson-lwig-security-protocol-comparison] 432 analyses the overhead of TLS headers compared with OSCORE 433 [I-D.ietf-core-object-security] illustrating the additional 434 overhead associated with TLS headers. The overhead varies between 435 the different TLS versions and also between TLS and DTLS. It may 436 be more appropriate to use the architecture defined in Figure 6 in 437 order to establish shared encryption keys, and then transport 438 encrypted data directly without the overhead of unwanted TLS 439 record headers. 441 o when using HTTP as a transport layer, it may be more appropriate 442 to use the architecture defined in Figure 6 in order to avoid any 443 TLS session vs. HTTP session affinity issues. 445 5.1.1. Application Architecture Benefits 447 There are several benefits to using a standard TLS software stack to 448 establish an application layer secure communications channel between 449 a client and a service. These include: 451 o no need to define a new cryptographic negotiation and exchange 452 protocol between client and service 454 o automatically benefit from new cipher suites by simply upgrading 455 the TLS software stack 457 o automatically benefit from new features, bugfixes, etc. in TLS 458 software stack upgrades 460 5.1.2. ATLS Packet Identification 462 It is recommended that ATLS packets are explicitly identified by a 463 standardized, transport-specific identifier enabling any gateways and 464 middleboxes to identify ATLS packets. Middleboxes have to contend 465 with a vast number of applications and network operators have 466 difficulty configuring middleboxes to distinguish unencrypted but not 467 explicitly identified application data from end-to-end encrypted 468 data. This specification aims to assist network operators by 469 explicitly identifying ATLS packets. The HTTP and CoAP encodings 470 documented in Section 8 and Section 7 explicitly identify ATLS 471 packets. 473 5.1.3. ATLS Session Tracking 475 The ATLS application service establishes multiple ATLS sessions with 476 multiple clients. As TLS sessions are stateful, the application 477 service must be able to correlate ATLS records from different clients 478 across the relevant ATLS sessions. The details of how session 479 tracking is implemented are outside the scope of this document. 480 Recommendations are given in Section 8 and Section 7, but session 481 tracking is application and implementation specific. 483 5.1.4. ATLS Record Inspection 485 No constraints are placed on the ContentType contained within the 486 transported TLS records. The TLS records may contain handshake, 487 application_data, alert or change_cipher_spec messages. If new 488 ContentType messages are defined in future TLS versions, these may 489 also be transported using this protocol. 491 5.1.5. ATLS Message Routing 493 In many cases ATLS message routing is trival. However, there are 494 potentially cases where the middlebox topology is quite complex and 495 an example is shown in Figure 7. In this scenario multiple devices 496 (Client 1-3) are connected using serial communication to a gateway 497 (referred as middlebox A). Middlebox A communicates with another 498 middlebox B over UDP/IP. Middlebox B then interacts with some 499 servers in the backend using CoAP over TCP. 501 This scenario raises the question about the ATLS message routing. In 502 particular, there are two questions: 504 o How do the middleboxes know to which IP address to address the 505 ATLS packet? This question arises in scenarios where clients are 506 communicating over non-IP transports. 508 o How are response messages demultiplexed? 510 In some scenarios it is feasible to pre-configure the destination IP 511 address of outgoing packets. Another other scenarios extra 512 information available in the ATLS message or in a shim layer has to 513 provide the necessary information. In the case of ATLS the use of 514 the Server Name Indicating (SNI) parameter in the TLS/DTLS 515 ClientHello message is a possibility to give middleboxes enough 516 information to determine the ATLS communication endpoint. This 517 approach is also compatible with SNI encryption. 519 For demultiplexing again different approaches are possible. The 520 simplest approach is to use separate source ports for each ATLS 521 session. In our example, Middlebox A allocates a dedicated socket 522 (with a separate source port) for outgoing UDP datagrams in order to 523 be able to relay a response message to the respective client. 524 Alternatively, it is possible to make use of a shim layer on top of 525 the transport that provides this extra demultiplexing capabilities. 526 The use of multiple UDP "sessions" (as well as different TCP 527 sessions) has the advantage of avoiding head-of-line blocking. 529 +---------+ +---------+ 530 | Server 1|----+-----| Server 2| 531 +---------+ | +---------+ 532 | 533 |CoAP 534 |over 535 |TCP/TLS 536 | 537 +-----+-----+ 538 |Middlebox B| 539 +-----------+ 540 | 541 | 542 |CoAP 543 |over 544 |UDP/DTLS 545 | 546 +-----------+ 547 +---------|Middlebox A|-----------+ 548 | +-----------+ | 549 | | | 550 |CoAP |CoAP |CoAP 551 |over |over |over 552 |Serial |Serial |Serial 553 | | | 554 +--------+ +--------+ +--------+ 555 |Client 1| |Client 2| |Client 3| 556 +--------+ +--------+ +--------+ 558 Figure 7: Message Routing Scenario 560 5.1.6. Implementation 562 Pseudo code illustrating how to read and write TLS records directly 563 from byte buffers using both OpenSSL BIO functions and Java JSSE 564 SSLEngine is given in the appendices. A blog post by [Norrell] 565 outlines a similar approach to leveraging OpenSSL BIO functions, and 566 Oracle publish example code for leveraging [SSLEngine]. 568 5.2. Functional Design 570 The functional design assumes that an authorization system has 571 established operational keys for authenticating endpoints. In a 572 layered design, this needs to be done for each layer, which may 573 operate in two separate authorization domains. Note that Figure 8 574 shows a generic setup where TLS/DTLS is used at two layers. In some 575 cases, use of TLS/DTLS at the application layer may be sufficient 576 where lower layer security mechanisms provide protection of the 577 transport-specific headers. 579 +-------------------------------------------------------+ 580 | +---+ +---+ | 581 | +--------+ |APP| |APP| +--------+ | 582 | |security| +---+ +---+ |security| | 583 | |--------+ ^ ^ |--------+ | 584 | |policies| | | |policies| | 585 | |LAYER 0 | | | |LAYER 0 | | 586 | +--------+ v v +--------+ | 587 | + +------+ APP +------+ + | 588 | | | TLS- |<--------->| TLS- | | | 589 | +----->|SERVER| LAYER |CLIENT|<-----+ | 590 | +------+ +------+ | 591 | TOP LAYER ^ ^ | 592 +-----------------|-------------------|-----------------+ 593 | BOTTTOM LAYER | | | 594 | v v | 595 | +------+ TRANSPORT +------+ | 596 | | TLS- |<--------->| TLS- | | 597 | +--------+ |SERVER| LAYER |CLIENT| +--------+ | 598 | |security| +------+ +------+ |security| | 599 | |--------+ ^ ^ |--------+ | 600 | |policies| | | |policies| | 601 | |LAYER 1 +-----+ +-----+LAYER 1 | | 602 | +--------+ +--------+ | 603 | | 604 +-------------------------------------------------------+ 606 Figure 8: Functional Design 608 The security policies of one layer are distinct from those of another 609 in Figure 8. They may overlap, but that is not necessary or perhaps 610 even likely since the key exchanges at the different layers terminate 611 at different endpoints and the two often have different authorization 612 domains. 614 TLS can protect IoT device-to-gateway communications "on the wire" 615 using the "bottom layer" of Figure 8, and it can protect application 616 data from the device to the application server using the "top layer." 617 Application and transport security each have a role to play. 618 Transport security restricts access to messages on the networks, 619 notably application headers and application-layer TLS restricts 620 access to the application payloads. 622 As shown in Figure 8, an application-layer message, which gets 623 encrypted and integrity protected and, in the generic case, the the 624 resulting TLS message and headers are passed to a TLS socket at the 625 bottom layer, which may have a different security policy than the 626 application layer. 628 5.3. Network Architecture 630 An example network deployment is illustrated in Figure 9. It shows a 631 constrained client connecting to an application service via an 632 internet gateway. The client uses CoAP over DTLS to communicate with 633 the gateway. The gateway extracts the messages the client sent over 634 CoAP and sends these messages inside HTTP message bodies to the 635 application service. It also shows a TLS terminator deployed in 636 front of the application service. The client establishes a transport 637 layer CoAP/DTLS connection with the gateway (C->G DTLS), the gateway 638 in turn opens a transport layer TLS connection with the TLS 639 terminator deployed in front of the service (G->T TLS). The client 640 can ignore any certificate validation errors when it connects to the 641 gateway. CoAP messages are transported between the client and the 642 gateway, and HTTP messages are transported between the client and the 643 service. Finally, application layer TLS messages are exchanged 644 inside the CoAP and HTTP message bodies in order to establish an end- 645 to-end TLS session between the client and the service (C->S TLS). 647 +----------+ +----------+ 648 | App Data | | App Data | 649 +----------+ +----------+ +----------+ 650 | C->S TLS | | C->S TLS | | App Data | 651 +----------+ +----------+ +----------+ 652 | CoAP | | HTTP | | C->S TLS | 653 +----------+ +----------+ +----------+ 654 | C->G DTLS| | M->T TLS | | HTTP | 655 +----------+ +----------+ +----------+ 656 | UDP | | TCP | | TCP | 657 +----------+ +----------+ +----------+ 659 +--------+ +-----------+ +----------------+ +---------+ 660 | Client |----->| Gateway |----->| TLS Terminator |---->| Service | 661 +--------+ +-----------+ +----------------+ +---------+ 662 ^ ^ 663 | | 664 +-------------Client to Service ATLS Connection-------------+ 666 Figure 9: Constrained Device Gateway Network Architecture 668 Another typical network deployment is illustrated in Figure 10. It 669 shows a client connecting to a service via a middlebox. It also 670 shows a TLS terminator deployed in front of the service. The client 671 establishes a transport layer TLS connection with the middlebox (C->M 672 TLS), the middlebox in turn opens a transport layer TLS connection 673 with the TLS terminator deployed in front of the service (M->T TLS). 674 The client can ignore any certificate validation errors when it 675 connects to the middlebox. HTTP messages are transported over this 676 layer between the client and the service. Finally, application layer 677 TLS messages are exchanged inside the HTTP message bodies in order to 678 establish an end-to-end TLS session between the client and the 679 service (C->S TLS). 681 +----------+ +----------+ 682 | App Data | | App Data | 683 +----------+ +----------+ +----------+ 684 | C->S TLS | | C->S TLS | | App Data | 685 +----------+ +----------+ +----------+ 686 | HTTP | | HTTP | | C->S TLS | 687 +----------+ +----------+ +----------+ 688 | C->M TLS | | M->T TLS | | HTTP | 689 +----------+ +----------+ +----------+ 690 | TCP | | TCP | | TCP | 691 +----------+ +----------+ +----------+ 693 +--------+ +-----------+ +----------------+ +---------+ 694 | Client |----->| Middlebox |----->| TLS Terminator |---->| Service | 695 +--------+ +-----------+ +----------------+ +---------+ 696 ^ ^ 697 | | 698 +-------------Client to Service ATLS Connection-------------+ 700 Figure 10: HTTP Middlebox Network Architecture 702 6. ATLS Session Establishment 704 Figure 11 illustrates how an ATLS session is established using the 705 key exporting architectural model shown in Figure 6. The number of 706 RTTs that take place when establishing a TLS session depends on the 707 version of TLS and what capabilities are enabled on the TLS software 708 stack. For example, a 0-RTT exchange is possible with TLS 1.3. If 709 applications wish to ensure a predictable number of RTTs when 710 establishing an application layer TLS connection, this may be 711 achieved by configuring the TLS software stack appropriately. 713 The outline is as follows: 715 o the client creates an ATLS session object 717 o the client initiates a TLS handshake on the session 718 o the client extracts the TLS records for the first TLS flight (the 719 first RTT) 721 o the client sends the TLS records over the transport layer to the 722 server 724 o on receipt of the TLS flight, the server creates an ATLS session 725 object 727 o the server injects the received TLS flight into the session 729 o the server extracts the TLS records for the first TLS flight 730 response 732 o the server sends the TLS response records over the transport layer 733 to the client 735 o the client injects the received TLS records into its TLS session 736 completing the first full RTT 738 o the client and server repeat the above process and complete the 739 second RTT 741 o once the ATLS session is up, both sides export keying material 743 o both sides now can exchange data encrypted using shared keys 744 derived from the keying material 746 +-------------------------------+ +-------------------------------+ 747 | Client | | ATLS Server | 748 +---------+---+-----+-+---------+ +---------+--+-----+--+---------+ 749 | ATLS | | App | |Transport| |Transport| | App | | ATLS | 750 | Session | +-----+ | Stack | | Stack | +-----+ | Session | 751 +---------+ | +---------+ +---------+ | +---------+ 752 | | | | | | 753 | | | | | | 754 | | | | | | 755 | Create | | | | | 756 | Session | | | | | 757 + |<---------| | | | | 758 | | Start | | | | | 759 | | Handshake| | | | | 760 | |<---------| | | | | 761 | | TLS | | | | | 762 | | Records | Pack | | | | 763 | |--------->| Records | | | | 764 | |-------->| send packet | Unpack | | 765 R | | |------------>| Records | Create | 766 T | | | |--------->| Session | 767 T | | | | |--------->| 768 | | | | | TLS | 769 1 | | | | | Records | 770 | | | | |--------->| 771 | | | | | | TLS | 772 | | | | | Pack | Records | 773 | | | | | Records |<---------| 774 | | | Unpack |send response|<---------| | 775 | | TLS | Records |<------------| | | 776 | | Records |<--------| | | | 777 + |<---------| | | | | 778 | TLS | | | | | 779 | Records | | | | | 780 + |--------->|-------->|------------>|--------->|--------->| 781 | | | | | | | 782 | | | | | Session | 783 R | | | | | Up | 784 T | | | | |<---------| 785 T | | | | | TLS | 786 | | | | | Records | 787 2 |<---------|<--------|<------------|<---------|<---------| 788 | Session | | | | | 789 | | Up | | | | | 790 + |--------->| | | | | 791 | Export | | | | Export | 792 | Keys | | | | Keys | 793 |--------->| | E2E Session | |<---------| 794 | |<--------|-------------|--------->| | 796 Figure 11: ATLS Session Establishment 798 7. ATLS over CoAP Transport 800 To carry TLS messages over CoAP [RFC7252] it is recommended to use 801 Confirmable messages while DTLS payloads may as well use non- 802 confirmable messages. The exchange pattern in CoAP uses the 803 following style: A request from the CoAP client to the CoAP server 804 uses a POST with the ATLS message contained in the payload of the 805 request. An ATLS response is returned by the CoAP server to the CoAP 806 client in a 2.04 (Changed) message. 808 When DTLS messages are conveyed in CoAP over UDP then the DDoS 809 protection offered by DTLS MAY be used instead of replicating the 810 functionality at the CoAP layer. If TLS is conveyed in CoAP over UDP 811 then DDoS protection by CoAP has to be utilized. Carrying ATLS 812 messages in CoAP over TCP does not require any additional DDoS 813 protection. 815 The URI path used by ATLS is "/.well-known/atls". 817 {{coap-example} shows a TLS 1.3 handshake inside CoAP graphically. 819 Client Server 820 | | 821 +--------->| Header: POST (Code=0.02) 822 | POST | Uri-Path: "/.well-known/atls" 823 | | Content-Format: application/atls 824 | | Payload: ATLS (ClientHello) 825 | | 826 |<---------+ Header: 2.04 Changed 827 | 2.04 | Content-Format: application/atls 828 | | Payload: ATLS (ServerHello, 829 | | {EncryptedExtensions}, {CertificateRequest*} 830 | | {Certificate*}, {CertificateVerify*} {Finished}) 831 | | 832 +--------->| Header: POST (Code=0.02) 833 | POST | Uri-Path: "/.well-known/atls" 834 | | Content-Format: application/atls 835 | | Payload: ATLS ({Certificate*}, 836 | | {CertificateVerify*}, {Finished}) 837 | | 838 |<---------+ Header: 2.04 Changed 839 | 2.04 | 840 | | 842 Figure 12: Transferring ATLS in CoAP 844 Note that application data can already be sent by the server in the 845 second message and by the client in the third message, in case of the 846 full TLS 1.3 handshake. In case of the 0-RTT handshake application 847 data can be sent earlier. To mix different media types in the same 848 CoAP payload the application/multipart-core content type is used. 850 Note also that CoAP blockwise transfer MAY be used if the payload 851 size, for example due to the size of the certificate chain, exceeds 852 the MTU size. 854 8. ATLS over HTTP Transport 856 The assumption is that the client will establish a transport layer 857 connection to the server for exchange of HTTP messages. The 858 underlying transport layer connection could be over TCP or TLS. The 859 client will then establish an application layer TLS connection with 860 the server by exchanging TLS records with the server inside HTTP 861 message request and response bodies. 863 Note that ATLS over HTTP transport addresses a different deployment 864 scenario than HTTP CONNECT proxies. HTTP CONNECT proxy behaviour is 865 compared and contrasted with ATLS in Appendix B. 867 8.1. Protocol Summary 869 All ATLS records are transported unmodified as binary data within 870 HTTP message bodies. The application simply extracts the TLS records 871 from the TLS stack and inserts them directly into HTTP message 872 bodies. Each message body contains a full TLS flight, which may 873 contain multiple TLS records. 875 The client sends all ATLS records to the server in the bodies of POST 876 requests. 878 The server sends all ATLS records to the client in the bodies of 200 879 OK responses to the POST requests. 881 The URI path used by ATLS is "/.well-known/atls". 883 8.2. Content-Type Header 885 A new Content-Type header value is defined: 887 Content-type: application/atls 889 All message bodies containing ATLS records must set this Content- 890 Type. This enables middleboxes to readily identify ATLS payloads. 892 8.3. HTTP Status Codes 894 This document does not define any new HTTP status codes, and does not 895 specify additional semantics or refine existing semantics for status 896 codes. This is the best current practice as outlined in 897 [I-D.ietf-httpbis-bcp56bis]. 899 8.4. ATLS Session Tracking 901 The application service needs to track multiple client application 902 layer TLS sessions so that it can correlate TLS records received in 903 HTTP message bodies with the appropriate TLS session. The 904 application service should use stateful cookies [RFC6265] in order to 905 achieve this as recommended in [I-D.ietf-httpbis-bcp56bis]. 907 8.5. Session Establishment and Key Exporting 909 It is recommended that applications using ATLS over HTTP transport 910 only use ATLS for session establishment and key exchange, resulting 911 in only 2 ATLS RTTs between the client and the application service. 913 Key exporting must be carried out as described in Section 9. 915 8.6. Illustrative ATLS over HTTP Session Establishment 917 A client initiates an ATLS session by sending the first TLS flight in 918 a POST request message body to the ATLS server. 920 POST /.well-known/atls 921 Content-Type: application/atls 923 925 The server handles the request, creates an ATLS session object, and 926 replies by including its first TLS flight in a 200 OK message body. 927 The server also sets a suitable cookie for session tracking purposes. 929 200 OK 930 Content-Type: application/atls 931 Set-Cookie: my-atls-cookie=my-cookie-value 933 935 The client handles the server first flight TLS records and replies 936 with its second flight. 938 POST /.well-known/atls 939 Content-Type: application/atls 940 Cookie: my-atls-cookie=my-cookie-value 942 944 The server handles the second flight, establishes the ATLS session, 945 and replies with its second flight. 947 200 OK 948 Content-Type: application/atls 950 952 9. Key Exporting and Application Data Encryption 954 When solutions implement the architecture described in Figure 6, they 955 leverage [RFC5705] for exporting keys. This section describes how to 956 establish keying material and negotiate algorithms for OSCORE and for 957 COSE. 959 9.1. OSCORE 961 When the OSCORE mode has been agreed using the "oscore_connection_id" 962 extension defined in this document, different keys are used for DTLS/ 963 TLS record protection and for OSCORE packet protection. These keys 964 are produced using a TLS exporter [RFC5705] and the exporter takes 965 three input values: 967 o a disambiguating label string, 969 o a per-association context value provided by the application using 970 the exporter, and 972 o a length value. 974 The label string for use with this specification is defined as 'atls- 975 oscore'. The per-association context value is empty. 977 The length value is twice the size of the key size utilized by the 978 negotiated algorithm since the lower-half is used for the Master 979 Secret and the upper-half is used for the Master Salt. 981 For example, if a TLS/DTLS 1.2 handshake negotiated the 982 TLS_PSK_WITH_AES_128_CCM_8 ciphersuite then the key size utilized by 983 the negotiated algorithm, i.e. AES 128, is 128 bit. Hence, the key 984 extractor is requested to produce 2 x 128 bit keying material. 986 The following parameters are needed for use with OSCORE: 988 o Master Secret: The master secret is derived as described above. 990 o Sender ID: This values is negotiated using the 991 "oscore_connection_id" extension, as described in Section 11.1. 993 o Recipient ID: This values is negotiated using the 994 "oscore_connection_id" extension, as described in Section 11.1. 996 o AEAD Algorithm: This value is negotiated using the ciphersuite 997 exchange provided by the TLS/DTLS handshake. For example, if a 998 TLS/DTLS 1.2 handshake negotiated the TLS_PSK_WITH_AES_128_CCM_8 999 ciphersuite then the AEAD algorithm identifier is AES_128_CCM_8, 1000 which corresponds to two COSE algorithms, which both use AES-CCM 1001 mode with a 128-bit key, a 64-bit tag: 1003 * AES-CCM-64-64-128 1005 * AES-CCM-16-64-128 The difference between the two is only the 1006 length of the nonce, which is 7-bytes in the former case and 1007 13-bytes in the latter. In TLS/DTLS the nonce value is not 1008 negotiated but fixed instead. Figure 13 provides the mapping 1009 between the TLS defined ciphersuite and the COSE algorithms. 1011 o Master Salt: The master salt is derived as described above. 1013 o HKDF Algorithm: This value is negotiated using the ciphersuite 1014 exchange provided by the TLS/DTLS handshake. As a default, 1015 SHA-256 is assumed as a HKDF algorithm for algorithms using 1016 128-bit key sizes and SHA384 for 256-bit key sizes. 1018 o Replay Window: A default window size of 32 packets is assumed. 1020 9.2. COSE 1022 The key exporting procedure for COSE is similiar to the one defined 1023 for OSCORE. The label string for use with this specification is 1024 defined as 'atls-cose'. The per-association context value is empty. 1026 The length value is twice the size of the key size utilized by the 1027 negotiated algorithm since the lower-half is used for the Master 1028 Secret and the upper-half is used for the Master Salt. 1030 The COSE algorithm corresponds to the ciphersuite negotiated during 1031 the TLS/DTLS handshake with with the mapping provided in Figure 13. 1032 The HKDF algorithm is negotiated using the the TLS/DTLS handshake. 1033 As a default, SHA-256 is assumed as a HKDF algorithm for algorithms 1034 using 128-bit key sizes and SHA384 for 256-bit key sizes. 1036 COSE uses key ids to allow finding the appropriate security context. 1037 Those key IDs conceptually correspond to CIDs, as described in 1038 Section 11.2. 1040 10. TLS Ciphersuite to COSE/OSCORE Algorithm Mapping 1041 TLS Ciphersuite | COSE/OSCORE Algorithm 1042 ------------------+-------------------------------------------------- 1043 AES_128_CCM_8 | AES-CCM w/128-bit key, 64-bit tag, 13-byte nonce 1044 AES_256_CCM_8 | AES-CCM w/256-bit key, 64-bit tag, 13-byte nonce 1045 CHACHA20_POLY1305 | ChaCha20/Poly1305 w/256-bit key, 128-bit tag 1046 AES_128_CCM | AES-CCM w/128-bit key, 128-bit tag, 13-byte nonce 1047 AES_256_CCM | AES-CCM w/256-bit key, 128-bit tag, 13-byte nonce 1048 AES_128_GCM | AES-GCM w/128-bit key, 128-bit tag 1049 AES_256_GCM | AES-GCM w/256-bit key, 128-bit tag 1051 Figure 13: TLS Ciphersuite to COSE/OSCORE Algorithm Mapping 1053 11. TLS Extensions 1055 11.1. The "oscore_connection_id" Extension 1057 This document defines the "oscore_connection_id" extension, which is 1058 used in ClientHello and ServerHello messages. It is used only for 1059 establishing the OSCORE Sender ID and the OSCORE Recipient ID. The 1060 OSCORE Sender ID maps to the CID provided by the server in the 1061 ServerHello and the OSCORE Recipient ID maps to the CID provided by 1062 the client in the ClientHello. 1064 The negotiation mechanism follows the procedure used in 1065 [I-D.ietf-tls-dtls-connection-id] with the exception that the 1066 negotiated CIDs agreed with the "oscore_connection_id" extension is 1067 only used with OSCORE and does not impact the record layer format of 1068 the DTLS/TLS payloads nor the MAC calculation used by DTLS/TLS. As 1069 such, this extension can be used with DTLS as well as with TLS when 1070 those protocols are used at the application layer. 1072 The extension type is specified as follows. 1074 enum { 1075 oscore_connection_id(TBD), (65535) 1076 } ExtensionType; 1078 struct { 1079 opaque cid<0..2^8-1>; 1080 } ConnectionId; 1082 Figure 14: The 'oscore_connection_id' Extension 1084 Note: This extension allows a client and a server to determine 1085 whether an OSCORE security context should be established. 1087 11.2. The "cose_ext" Extension 1089 This document defines the "cose_ext" extension, which is used in 1090 ClientHello and ServerHello messages. It is used only for 1091 establishing the key identifiers, AEAD algorithms, as well as keying 1092 material for use with application layer protection using COSE. The 1093 CID provided by the server in the ServerHello maps to the COSE kid 1094 transmitted from the client to the server and the CID provided by the 1095 client in the ClientHello maps to the COSE kid transmitted from the 1096 server to the client. 1098 The negotiation mechanism follows the procedure used in 1099 [I-D.ietf-tls-dtls-connection-id] with the exception that the 1100 negotiated CIDs agreed with the "cose_ext" extension is only used 1101 with COSE and does not impact the record layer format of the DTLS/TLS 1102 payloads nor the MAC calculation used by DTLS/TLS. As such, this 1103 extension can be used with DTLS as well as with TLS when those 1104 protocols are used at the application layer. 1106 The extension type is specified as follows. 1108 enum { 1109 oscore_connection_id(TBD), (65535) 1110 } ExtensionType; 1112 struct { 1113 opaque cid<0..2^8-1>; 1114 } ConnectionId; 1116 Figure 15: The 'cose_ext' Extension 1118 Note: This extension allows a client and a server to determine 1119 whether an COSE security context should be established. 1121 12. IANA Considerations 1123 12.1. "oscore_connection_id" TLS extension 1125 IANA is requested to allocate two entries to the existing TLS 1126 "ExtensionType Values" registry, defined in [RFC5246], for 1127 oscore_connection_id(TBD1) and cose_ext(TBD2) defined in this 1128 document, as described in the table below. 1130 Value Extension Name TLS 1.3 DTLS Only Recommended Reference 1131 ----------------------------------------------------------------------- 1132 TBD1 oscore_connection_id Y N N [[This doc]] 1133 TBD2 cose_ext Y N N [[This doc]] 1134 Note: The "N" values in the Recommended column are set because these 1135 extensions are intended only for specific use cases. 1137 12.2. TLS Ciphersuite to OSCORE/COSE Algorithm Mapping 1139 IANA is requested to create a new registry for mapping TLS 1140 ciphersuites to SCORE/COSE algorithms 1142 An initial mapping can be found in Figure 13. 1144 Registration requests are evaluated after a three-week review period 1145 on the tls-reg-review@ietf.or mailing list, on the advice of one or 1146 more Designated Experts [RFC8126]. However, to allow for the 1147 allocation of values prior to publication, the Designated Experts may 1148 approve registration once they are satisfied that such a 1149 specification will be published. 1151 Registration requests sent to the mailing list for review should use 1152 an appropriate subject (e.g., "Request to register an TLS - OSCORE/ 1153 COSE algorithm mapping: example"). Registration requests that are 1154 undetermined for a period longer than 21 days can be brought to the 1155 IESG's attention (using the iesg@ietf.org mailing list) for 1156 resolution. 1158 Criteria that should be applied by the Designated Experts includes 1159 determining whether the proposed registration duplicates existing 1160 functionality, whether it is likely to be of general applicability or 1161 whether it is useful only for a single extension, and whether the 1162 registration description is clear. 1164 IANA must only accept registry updates from the Designated Experts 1165 and should direct all requests for registration to the review mailing 1166 list. 1168 12.3. .well-known URI Registry 1170 IANA is requested to add the well-known URI 'atls' to the Well-Known 1171 URIs registry. 1173 o URI suffix: atls 1175 o Change controller: IETF 1177 o Specification document(s): [[this document]] 1179 o Related information: None 1181 12.4. Media Types Registry 1183 IANA is requested to add the media type 'application/atls' to the 1184 Media Types registry. 1186 o Type name: application 1188 o Subtype name: atls 1190 o Required parameters: N/A 1192 o Optional parameters: N/A 1194 o Encoding considerations: binary 1196 o Security considerations: See Security Considerations section of 1197 this document. 1199 o Interoperability considerations: N/A 1201 o Published specification: [[this document]] (this document) 1203 o Applications that use this media type: Potentially any 1205 o Fragment identifier considerations: N/A 1207 o Additional information: 1209 * Magic number(s): N/A 1211 * File extension(s): N/A 1213 * Macintosh file type code(s): N/A 1215 o Person & email address to contact for further information: See 1216 "Authors' Addresses" section. 1218 o Intended usage: COMMON 1220 o Restrictions on usage: N/A 1222 o Author: See "Authors' Addresses" section. 1224 o Change Controller: IESG 1226 12.5. HTTP Content-Formats Registry 1228 IANA is requested to add the media type 'application/atls' to the 1229 HTTP Content-Formats registry. 1231 o Media Type: application/atls 1233 o Encoding: binary 1235 o ID: TBD 1237 o Reference: [[this document]] 1239 12.6. CoAP Content-Formats Registry 1241 IANA is requested to add the media type 'application/atls' to the 1242 CoAP Content-Formats registry. 1244 o Media Type: application/atls 1246 o Encoding: binary 1248 o ID: TBD 1250 o Reference: [[this document]] 1252 12.7. TLS Key Extractor Label 1254 IANA is requested to register the "application-layer-tls" label in 1255 the TLS Extractor Label Registry to correspond to this specification. 1257 13. Security Considerations 1259 This specification re-uses the TLS and DTLS and hence the security 1260 considerations of the respective TLS/DTLS version applies. As 1261 described in Section 5.2, implementers need to take the policy 1262 configuration into account when applying security protection at 1263 various layers of the stack even if the same protocol is used since 1264 the communiation endpoints and the security requirements are likely 1265 going to vary. 1267 For use in the IoT environment the considerations described in 1268 [RFC7925] apply and other environments the guidelines in [RFC7525] 1269 are applicable. 1271 14. References 1273 14.1. Normative References 1275 [I-D.ietf-core-object-security] 1276 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1277 "Object Security for Constrained RESTful Environments 1278 (OSCORE)", draft-ietf-core-object-security-16 (work in 1279 progress), March 2019. 1281 [I-D.ietf-tls-dtls13] 1282 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1283 Datagram Transport Layer Security (DTLS) Protocol Version 1284 1.3", draft-ietf-tls-dtls13-33 (work in progress), October 1285 2019. 1287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1288 Requirement Levels", BCP 14, RFC 2119, 1289 DOI 10.17487/RFC2119, March 1997, 1290 . 1292 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1293 (TLS) Protocol Version 1.2", RFC 5246, 1294 DOI 10.17487/RFC5246, August 2008, 1295 . 1297 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1298 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1299 March 2010, . 1301 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1302 DOI 10.17487/RFC6265, April 2011, 1303 . 1305 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1306 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1307 January 2012, . 1309 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1310 Protocol (HTTP/1.1): Message Syntax and Routing", 1311 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1312 . 1314 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1315 Application Protocol (CoAP)", RFC 7252, 1316 DOI 10.17487/RFC7252, June 2014, 1317 . 1319 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1320 "Recommendations for Secure Use of Transport Layer 1321 Security (TLS) and Datagram Transport Layer Security 1322 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1323 2015, . 1325 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1326 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1327 DOI 10.17487/RFC7540, May 2015, 1328 . 1330 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1331 Security (TLS) / Datagram Transport Layer Security (DTLS) 1332 Profiles for the Internet of Things", RFC 7925, 1333 DOI 10.17487/RFC7925, July 2016, 1334 . 1336 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1337 Writing an IANA Considerations Section in RFCs", BCP 26, 1338 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1339 . 1341 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1342 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1343 May 2017, . 1345 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1346 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1347 . 1349 14.2. Informative References 1351 [ALTS] Google, "Application Layer Transport Security", December 1352 2017, . 1355 [Bluetooth] 1356 Bluetooth, "Bluetooth Core Specification v5.0", 2016, 1357 . 1359 [I-D.ietf-anima-bootstrapping-keyinfra] 1360 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 1361 and K. Watsen, "Bootstrapping Remote Secure Key 1362 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1363 keyinfra-29 (work in progress), October 2019. 1365 [I-D.ietf-httpbis-bcp56bis] 1366 Nottingham, M., "Building Protocols with HTTP", draft- 1367 ietf-httpbis-bcp56bis-09 (work in progress), November 1368 2019. 1370 [I-D.ietf-tls-dtls-connection-id] 1371 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 1372 Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- 1373 id-07 (work in progress), October 2019. 1375 [I-D.mattsson-lwig-security-protocol-comparison] 1376 Mattsson, J. and F. Palombini, "Comparison of CoAP 1377 Security Protocols", draft-mattsson-lwig-security- 1378 protocol-comparison-01 (work in progress), March 2018. 1380 [I-D.rescorla-tls-ctls] 1381 Rescorla, E. and R. Barnes, "Compact TLS 1.3", draft- 1382 rescorla-tls-ctls-02 (work in progress), July 2019. 1384 [I-D.selander-ace-cose-ecdhe] 1385 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 1386 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 1387 cose-ecdhe-14 (work in progress), September 2019. 1389 [LwM2M] Open Mobile Alliance, "Lightweight Machine to Machine 1390 Requirements", December 2017, 1391 . 1393 [Noise] Perrin, T., "Noise Protocol Framework", October 2017, 1394 . 1396 [Norrell] Norrell, ., "Use SSL/TLS within a different protocol with 1397 BIO pairs", 2016, 1398 . 1401 [Signal] Open Whisper Systems, "Signal Protocol", 2016, 1402 . 1404 [SSLEngine] 1405 Oracle, "SSLEngineSimpleDemo.java", 2004, . 1409 [ZigBee] ZigBee Alliance, "ZigBee Specification", 2012, 1410 . 1412 Appendix A. Pseudo Code 1414 This appendix gives both C and Java pseudo code illustrating how to 1415 inject and extract raw TLS records from a TLS software stack. Please 1416 note that this is illustrative, non-functional pseudo code that does 1417 not compile. 1419 A.1. OpenSSL 1421 OpenSSL provides a set of Basic Input/Output (BIO) APIs that can be 1422 used to build a custom transport layer for TLS connections. This 1423 appendix gives pseudo code on how BIO APIs could be used to build a 1424 client application that completes a TLS handshake and exchanges 1425 application data with a service. 1427 char inbound[MAX]; 1428 char outbound[MAX]; 1429 int rx_bytes; 1430 SSL_CTX *ctx = SSL_CTX_new(); 1431 SSL *ssl = SSL_new(ctx); 1433 // Create in-memory BIOs and plug in to the SSL session 1434 BOI* bio_in = BIO_new(BIO_s_mem()); 1435 BOI* bio_out = BIO_new(BIO_s_mem()); 1436 SSL_set_bio(ssl, bio_in, bio_out); 1438 // We are a client 1439 SSL_set_connect_state(ssl); 1441 // Loop through TLS flights until we are done 1442 do { 1443 // Calling SSL_do_handshake() will result in a full 1444 // TLS flight being written to the BIO buffer 1445 SSL_do_handshake(ssl); 1447 // Read the client flight that the TLS session 1448 // has written to memory 1449 BIO_read(bio_out, outbound, MAX); 1451 // POST the outbound bytes to the server using a suitable 1452 // function. Lets assume that the server response will be 1453 // written to the 'inbound' buffer 1454 num_bytes = postTlsRecords(outbound, inbound); 1456 // Write the server flight to the memory BIO so the TLS session 1457 // can read it. The next call to SSL_do_handshake() will handle 1458 // this received server flight 1459 BIO_write(bio_in, inbound, num_bytes); 1461 } while (!SSL_is_init_finished(ssl)); 1463 // Send a message to the server. Calling SSL_write() will run the 1464 // plaintext through the TLS session and write the encrypted TLS 1465 // records to the BIO buffer 1466 SSL_write(ssl, "Hello World", strlen("Hello World")); 1468 // Read the TLS records from the BIO buffer and 1469 // POST them to the server 1470 BIO_read(bio_out, outbound, MAX); 1471 num_bytes = postTlsRecords(outbound, inbound); 1473 A.2. Java JSSE 1475 The Java SSLEngine class "enables secure communications using 1476 protocols such as the Secure Sockets Layer (SSL) or IETF RFC 2246 1477 "Transport Layer Security" (TLS) protocols, but is transport 1478 independent". This pseudo code illustrates how a server could use 1479 the SSLEngine class to handle an inbound client TLS flight and 1480 generate an outbound server TLS flight response. 1482 SSLEngine sslEngine = SSLContext.getDefault().createSSLEngine(); 1483 sslEngine.setUseClientMode(false); 1484 sslEngine.beginHandshake(); 1486 // Lets assume 'inbound' has been populated with 1487 // the Client 1st Flight 1488 ByteBuffer inbound; 1490 // 'outbound' will be populated with the 1491 // Server 1st Flight response 1492 ByteBuffer outbound; 1494 // SSLEngine handles one TLS Record per call to unwrap(). 1495 // Loop until the engine is finished unwrapping. 1496 while (sslEngine.getHandshakeStatus() == 1497 HandshakeStatus.NEED_UNWRAP) { 1498 SSLEngineResult res = sslEngine.unwrap(inbound, outbound); 1500 // SSLEngine may need additional tasks run 1501 if (res.getHandshakeStatus() == NEED_TASK) { 1502 Runnable run = sslEngine.getDelegatedTask(); 1503 run.run(); 1504 } 1505 } 1507 // The SSLEngine has now finished handling all inbound TLS Records. 1508 // Check if it wants to generate outbound TLS Records. SSLEngine 1509 // generates one TLS Record per call to wrap(). 1510 // Loop until the engine is finished wrapping. 1511 while (sslEngine.getHandshakeStatus() == 1512 HandshakeStatus.NEED_WRAP) { 1513 SSLEngineResult res = sslEngine.wrap(inbound, outbound); 1515 // SSLEngine may need additional tasks run 1516 if (res.getHandshakeStatus() == NEED_TASK) { 1517 Runnable run = sslEngine.getDelegatedTask(); 1518 run.run(); 1519 } 1520 } 1522 // outbound ByteBuffer now contains a complete server flight 1523 // containing multiple TLS Records 1524 // Rinse and repeat! 1526 Appendix B. ATLS and HTTP CONNECT 1528 It is worthwhile comparing and contrasting ATLS with HTTP CONNECT 1529 tunneling. 1531 First, let us introduce some terminology: 1533 o HTTP Proxy: A HTTP Proxy operates at the application layer, 1534 handles HTTP CONNECT messages from clients, and opens tunnels to 1535 remote origin servers on behalf of clients. If a client 1536 establishes a tunneled TLS connection to the origin server, the 1537 HTTP Proxy does not attempt to intercept or inspect the HTTP 1538 messages exchanged between the client and the server 1540 o middlebox: A middlebox operates at the transport layer, terminates 1541 TLS connections from clients, and originates new TLS connections 1542 to services. A middlebox inspects all messages sent between 1543 clients and services. Middleboxes are generally completely 1544 transparent to applications, provided that the necessary PKI root 1545 Certificate Authority is installed in the client's trust store. 1547 HTTP Proxies and middleboxes are logically separate entities and one 1548 or both of these may be deployed in a network. 1550 HTTP CONNECT is used by clients to instruct a HTTP Forward Proxy 1551 deployed in the local domain to open up a tunnel to a remote origin 1552 server that is typically deployed in a different domain. Assuming 1553 that TLS transport is used between both client and proxy, and proxy 1554 and origin server, the network architecture is as illustrated in 1555 Figure 16. Once the proxy opens the transport tunnel to the service, 1556 the client establishes an end-to-end TLS session with the service, 1557 and the proxy is blindly transporting TLS records (the C->S TLS 1558 session records) between the client and the service. From the client 1559 perspective, it is tunneling a TLS session to the service inside the 1560 TLS session it has established to the proxy (the C->P TLS session). 1561 No middlebox is attempting to intercept or inspect the HTTP messages 1562 between the client and the service. 1564 +----------+ +----------+ 1565 | C->S HTTP| | C->S HTTP| 1566 +----------+ +----------+ 1567 | C->S TLS | | C->S TLS | 1568 +----------+ +----------+ 1569 | C->P TLS | | P->S TCP | 1570 +----------+ +----------+ 1571 | C->P TCP | 1572 +----------+ 1574 +--------+ +------------+ +---------+ 1575 | Client |----->| HTTP Proxy |----->| Service | 1576 +--------+ +------------+ +---------+ 1578 Figure 16: HTTP Proxy transport layers 1580 A more complex network topology where the network operator has both a 1581 HTTP Proxy and a middlebox deployed is illustrated in Figure 17. In 1582 this scenario, the proxy has tunneled the TLS session from the client 1583 towards the origin server, however the middlebox is intercepting and 1584 terminating this TLS session. A TLS session is established between 1585 the client and the middlebox (C->M TLS), and not end-to-end between 1586 the client and the server. It can clearly be seen that HTTP CONNECT 1587 and HTTP Proxies serve completely different functions than 1588 middleboxes. 1590 Additionally, the fact that the TLS session is established between 1591 the client and the middlebox can be problematic for two reasons: 1593 o the middle box is inspecting traffic that is sent between the 1594 client and the service 1596 o the client may not have the necessary PKI root Certificate 1597 Authority installed that would enable it to validate the TLS 1598 connection to the middlebox. This is the scenario outlined in 1599 Section 3.2. 1601 +----------+ +----------+ +----------+ 1602 | C->S HTTP| | C->S HTTP| | C->S HTTP| 1603 +----------+ +----------+ +----------+ 1604 | C->M TLS | | C->M TLS | | M->S TLS | 1605 +----------+ +----------+ +----------+ 1606 | C->P TLS | | P->M TCP | | M->S TCP | 1607 +----------+ +----------+ +----------+ 1608 | C->P TCP | 1609 +----------+ 1611 +--------+ +------------+ +-----------+ +---------+ 1612 | Client |----->| HTTP Proxy |----->| Middlebox |----->| Service | 1613 +--------+ +------------+ +-----------+ +---------+ 1615 Figure 17: HTTP Proxy and middlebox transport layers 1617 As HTTP CONNECT can be used to establish a tunneled TLS connection, 1618 one hypothetical solution to this middlebox issue is for the client 1619 to issue a HTTP CONNECT command to a HTTP Reverse Proxy deployed in 1620 front of the origin server. This solution is not practical for 1621 several reasons: 1623 o if there is a local domain HTTP Forward Proxy deployed, this would 1624 result in the client doing a first HTTP CONNECT to get past the 1625 Forward Proxy, and then a second HTTP CONNECT to get past the 1626 Reverse Proxy. No client or client library supports the concept 1627 of HTTP CONNECT inside HTTP CONNECT. 1629 o if there is no local domain HTTP Proxy deployed, the client still 1630 has to do a HTTP CONNECT to the HTTP Reverse Proxy. This breaks 1631 with standard and expected HTTP CONNECT operation, as HTTP CONNECT 1632 is only ever called if there is a local domain proxy. 1634 o clients cannot generate CONNECT from XHR in web applications. 1636 o this would require the deployment of a Reverse Proxy in front of 1637 the origin server, or else support of the HTTP CONNECT method in 1638 standard web frameworks. This is not an elegant design. 1640 o using HTTP CONNECT with HTTP 1.1 to a Reverse Proxy will break 1641 middleboxes inspecting HTTP traffic, as the middlebox would see 1642 TLS records when it expects to see HTTP payloads. 1644 In contrast to trying to force HTTP CONNECT to address a problem for 1645 which it was not designed to address, and having to address all the 1646 issues just outlined; ATLS is specifically designed to address the 1647 middlebox issue in a simple, easy to develop, and easy to deploy 1648 fashion. 1650 o ATLS works seamlessly with HTTP Proxy deployments 1652 o no changes are required to HTTP CONNECT semantics 1654 o no changes are required to HTTP libraries or stacks 1656 o no additional Reverse Proxy is required to be deployed in front of 1657 origin servers 1659 It is also worth noting that if HTTP CONNECT to a Reverse Proxy were 1660 a conceptually sound solution, the solution still ultimately results 1661 in encrypted traffic traversing the middlebox that the middlebox 1662 cannot intercept and inspect. That is ultimately what ATLS results 1663 in - traffic traversing the middle box that the middlebox cannot 1664 intercept and inspect. Therefore, from a middlebox perspective, the 1665 differences between the two solutions are in the areas of solution 1666 complexity and protocol semantics. It is clear that ATLS is a 1667 simpler, more elegant solution that HTTP CONNECT. 1669 Appendix C. Alternative Approaches to Application Layer End-to-End 1670 Security 1672 End-to-end security at the application layer is increasing seen as a 1673 key requirement across multiple applications and services. Some 1674 examples of end-to-end security mechanisms are outlined here. All 1675 the solutions outlined here have some common characteristics. The 1676 solutions: 1678 o do not rely on transport layer security 1680 o define a new handshake protocol for establishment of a secure end- 1681 to-end session 1683 C.1. Noise 1685 [Noise] is a framework for cryptographic protocols based on Elliptic 1686 Curve Diffie-Hellman (ECDH) key agreement, AEAD encryption, and 1687 BLAKE2 and SHA2 hash functions. Noise is currently used by WhatsApp, 1688 WireGuard, and Lightning. 1690 The current Noise protocol framework defines mechanisms for proving 1691 possession of a private key, but does not define authentication 1692 mechanisms. Section 14 "Security Considerations" of Noise states: 1693 ~~~ it's up to the application to determine whether the remote 1694 party's static public key is acceptable ~~~ 1696 C.2. Signal 1698 The [Signal] protocol provides end-to-end encryption and uses EdDSA 1699 signatures, Triple Diffie-Hellman handshake for shared secret 1700 establishment, and the Double Ratchet Algorithm for key management. 1701 It is used by Open Whisper Systems, WhatsApp and Google. 1703 Similar to Noise, Signal does not define an authentication mechanism. 1704 The current [X3DH] specification states in Section 4.1 1705 "Authentication": 1707 Methods for doing this are outside the scope of this document 1709 C.3. Google ALTS 1711 Google's Application Layer Transport Security [ALTS] is a mutual 1712 authentication and transport encryption system used for securing 1713 Remote Procedure Call (RPC) communications within Google's 1714 infrastructure. ALTS uses an ECDH handshake protocol and a record 1715 protocol containing AES encrypted payloads. 1717 C.4. Ephemeral Diffie-Hellman Over COSE (EDHOC) 1719 There is ongoing work to standardise EDHOC 1720 [I-D.selander-ace-cose-ecdhe], which defines a SIGMA-I based 1721 authenticated key exchange protocol using COSE and CBOR. 1723 Authors' Addresses 1725 Owen Friel 1726 Cisco 1728 Email: ofriel@cisco.com 1730 Richard Barnes 1731 Cisco 1733 Email: rlb@ipv.sx 1735 Max Pritikin 1736 Cisco 1738 Email: pritikin@cisco.com 1739 Hannes Tschofenig 1740 Arm Ltd. 1742 Email: hannes.tschofenig@gmx.net 1744 Mark Baugher 1745 Consultant 1747 Email: mark@mbaugher.com