idnits 2.17.1 draft-friel-tls-atls-05.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 (August 22, 2021) is 949 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MAX' is mentioned on line 1461, but not defined == Missing Reference: 'X3DH' is mentioned on line 1737, but not defined == Unused Reference: 'LwM2M' is defined on line 1422, but no explicit reference was found in the text ** 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 (-15) exists of draft-ietf-httpbis-bcp56bis-14 Summary: 5 errors (**), 0 flaws (~~), 5 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: February 23, 2022 Cisco 6 H. Tschofenig 7 Arm Ltd. 8 M. Baugher 9 Consultant 10 August 22, 2021 12 Application-Layer TLS 13 draft-friel-tls-atls-05 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 February 23, 2022. 47 Copyright Notice 49 Copyright (c) 2021 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 . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . . . 26 91 12.1. "oscore_connection_id" TLS extension . . . . . . . . . . 26 92 12.2. TLS Ciphersuite to OSCORE/COSE Algorithm Mapping . . . . 26 93 12.3. .well-known URI Registry . . . . . . . . . . . . . . . . 27 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 [[TODO]] An alternative approach for session tracking is to use a 908 RESTful model and create new resoruces to track sessions. 910 For example: 912 Client Server 913 | | 914 +--------->| Header: POST (Code=0.02) 915 | POST | Uri-Path: "/.well-known/atls" 916 | | Content-Format: application/atls 917 | | Payload: ATLS (ClientHello) 918 | | 919 |<---------+ Header: 2.01 Created 920 | 2.01 | Content-Format: application/atls 921 | | Location-Path: /RaNdOm 922 | | Payload: ATLS (ServerHello, 923 | | {EncryptedExtensions}, {CertificateRequest*} 924 | | {Certificate*}, {CertificateVerify*} {Finished}) 925 | | 926 +--------->| Header: POST (Code=0.02) 927 | POST | Uri-Path: "/RaNdOm" 928 | | Content-Format: application/atls 929 | | Payload: ATLS ({Certificate*}, 930 | | {CertificateVerify*}, {Finished}) 931 | | 932 |<---------+ Header: 2.04 Changed 933 | 2.04 | 934 | | 936 This may align bettern with CoAP implementations. 938 8.5. Session Establishment and Key Exporting 940 It is recommended that applications using ATLS over HTTP transport 941 only use ATLS for session establishment and key exchange, resulting 942 in only 2 ATLS RTTs between the client and the application service. 944 Key exporting must be carried out as described in Section 9. 946 8.6. Illustrative ATLS over HTTP Session Establishment 948 A client initiates an ATLS session by sending the first TLS flight in 949 a POST request message body to the ATLS server. 951 POST /.well-known/atls 952 Content-Type: application/atls 954 956 The server handles the request, creates an ATLS session object, and 957 replies by including its first TLS flight in a 200 OK message body. 958 The server also sets a suitable cookie for session tracking purposes. 960 200 OK 961 Content-Type: application/atls 962 Set-Cookie: my-atls-cookie=my-cookie-value 964 966 The client handles the server first flight TLS records and replies 967 with its second flight. 969 POST /.well-known/atls 970 Content-Type: application/atls 971 Cookie: my-atls-cookie=my-cookie-value 973 975 The server handles the second flight, establishes the ATLS session, 976 and replies with its second flight. 978 200 OK 979 Content-Type: application/atls 981 983 9. Key Exporting and Application Data Encryption 985 When solutions implement the architecture described in Figure 6, they 986 leverage [RFC5705] for exporting keys. This section describes how to 987 establish keying material and negotiate algorithms for OSCORE and for 988 COSE. 990 9.1. OSCORE 992 When the OSCORE mode has been agreed using the "oscore_connection_id" 993 extension defined in this document, different keys are used for DTLS/ 994 TLS record protection and for OSCORE packet protection. These keys 995 are produced using a TLS exporter [RFC5705] and the exporter takes 996 three input values: 998 o a disambiguating label string, 1000 o a per-association context value provided by the application using 1001 the exporter, and 1003 o a length value. 1005 The label string for use with this specification is defined as 'atls- 1006 oscore'. The per-association context value is empty. 1008 The length value is twice the size of the key size utilized by the 1009 negotiated algorithm since the lower-half is used for the Master 1010 Secret and the upper-half is used for the Master Salt. 1012 For example, if a TLS/DTLS 1.2 handshake negotiated the 1013 TLS_PSK_WITH_AES_128_CCM_8 ciphersuite then the key size utilized by 1014 the negotiated algorithm, i.e. AES 128, is 128 bit. Hence, the key 1015 extractor is requested to produce 2 x 128 bit keying material. 1017 The following parameters are needed for use with OSCORE: 1019 o Master Secret: The master secret is derived as described above. 1021 o Sender ID: This values is negotiated using the 1022 "oscore_connection_id" extension, as described in Section 11.1. 1024 o Recipient ID: This values is negotiated using the 1025 "oscore_connection_id" extension, as described in Section 11.1. 1027 o AEAD Algorithm: This value is negotiated using the ciphersuite 1028 exchange provided by the TLS/DTLS handshake. For example, if a 1029 TLS/DTLS 1.2 handshake negotiated the TLS_PSK_WITH_AES_128_CCM_8 1030 ciphersuite then the AEAD algorithm identifier is AES_128_CCM_8, 1031 which corresponds to two COSE algorithms, which both use AES-CCM 1032 mode with a 128-bit key, a 64-bit tag: 1034 * AES-CCM-64-64-128 1036 * AES-CCM-16-64-128 The difference between the two is only the 1037 length of the nonce, which is 7-bytes in the former case and 1038 13-bytes in the latter. In TLS/DTLS the nonce value is not 1039 negotiated but fixed instead. Figure 13 provides the mapping 1040 between the TLS defined ciphersuite and the COSE algorithms. 1042 o Master Salt: The master salt is derived as described above. 1044 o HKDF Algorithm: This value is negotiated using the ciphersuite 1045 exchange provided by the TLS/DTLS handshake. As a default, 1046 SHA-256 is assumed as a HKDF algorithm for algorithms using 1047 128-bit key sizes and SHA384 for 256-bit key sizes. 1049 o Replay Window: A default window size of 32 packets is assumed. 1051 9.2. COSE 1053 The key exporting procedure for COSE is similiar to the one defined 1054 for OSCORE. The label string for use with this specification is 1055 defined as 'atls-cose'. The per-association context value is empty. 1057 The length value is twice the size of the key size utilized by the 1058 negotiated algorithm since the lower-half is used for the Master 1059 Secret and the upper-half is used for the Master Salt. 1061 The COSE algorithm corresponds to the ciphersuite negotiated during 1062 the TLS/DTLS handshake with with the mapping provided in Figure 13. 1063 The HKDF algorithm is negotiated using the the TLS/DTLS handshake. 1064 As a default, SHA-256 is assumed as a HKDF algorithm for algorithms 1065 using 128-bit key sizes and SHA384 for 256-bit key sizes. 1067 COSE uses key ids to allow finding the appropriate security context. 1068 Those key IDs conceptually correspond to CIDs, as described in 1069 Section 11.2. 1071 10. TLS Ciphersuite to COSE/OSCORE Algorithm Mapping 1073 TLS Ciphersuite | COSE/OSCORE Algorithm 1074 ------------------+-------------------------------------------------- 1075 AES_128_CCM_8 | AES-CCM w/128-bit key, 64-bit tag, 13-byte nonce 1076 AES_256_CCM_8 | AES-CCM w/256-bit key, 64-bit tag, 13-byte nonce 1077 CHACHA20_POLY1305 | ChaCha20/Poly1305 w/256-bit key, 128-bit tag 1078 AES_128_CCM | AES-CCM w/128-bit key, 128-bit tag, 13-byte nonce 1079 AES_256_CCM | AES-CCM w/256-bit key, 128-bit tag, 13-byte nonce 1080 AES_128_GCM | AES-GCM w/128-bit key, 128-bit tag 1081 AES_256_GCM | AES-GCM w/256-bit key, 128-bit tag 1083 Figure 13: TLS Ciphersuite to COSE/OSCORE Algorithm Mapping 1085 11. TLS Extensions 1087 11.1. The "oscore_connection_id" Extension 1089 This document defines the "oscore_connection_id" extension, which is 1090 used in ClientHello and ServerHello messages. It is used only for 1091 establishing the OSCORE Sender ID and the OSCORE Recipient ID. The 1092 OSCORE Sender ID maps to the CID provided by the server in the 1093 ServerHello and the OSCORE Recipient ID maps to the CID provided by 1094 the client in the ClientHello. 1096 The negotiation mechanism follows the procedure used in 1097 [I-D.ietf-tls-dtls-connection-id] with the exception that the 1098 negotiated CIDs agreed with the "oscore_connection_id" extension is 1099 only used with OSCORE and does not impact the record layer format of 1100 the DTLS/TLS payloads nor the MAC calculation used by DTLS/TLS. As 1101 such, this extension can be used with DTLS as well as with TLS when 1102 those protocols are used at the application layer. 1104 The extension type is specified as follows. 1106 enum { 1107 oscore_connection_id(TBD), (65535) 1108 } ExtensionType; 1110 struct { 1111 opaque cid<0..2^8-1>; 1112 } ConnectionId; 1114 Figure 14: The 'oscore_connection_id' Extension 1116 Note: This extension allows a client and a server to determine 1117 whether an OSCORE security context should be established. 1119 11.2. The "cose_ext" Extension 1121 This document defines the "cose_ext" extension, which is used in 1122 ClientHello and ServerHello messages. It is used only for 1123 establishing the key identifiers, AEAD algorithms, as well as keying 1124 material for use with application layer protection using COSE. The 1125 CID provided by the server in the ServerHello maps to the COSE kid 1126 transmitted from the client to the server and the CID provided by the 1127 client in the ClientHello maps to the COSE kid transmitted from the 1128 server to the client. 1130 The negotiation mechanism follows the procedure used in 1131 [I-D.ietf-tls-dtls-connection-id] with the exception that the 1132 negotiated CIDs agreed with the "cose_ext" extension is only used 1133 with COSE and does not impact the record layer format of the DTLS/TLS 1134 payloads nor the MAC calculation used by DTLS/TLS. As such, this 1135 extension can be used with DTLS as well as with TLS when those 1136 protocols are used at the application layer. 1138 The extension type is specified as follows. 1140 enum { 1141 oscore_connection_id(TBD), (65535) 1142 } ExtensionType; 1144 struct { 1145 opaque cid<0..2^8-1>; 1146 } ConnectionId; 1148 Figure 15: The 'cose_ext' Extension 1150 Note: This extension allows a client and a server to determine 1151 whether an COSE security context should be established. 1153 12. IANA Considerations 1155 12.1. "oscore_connection_id" TLS extension 1157 IANA is requested to allocate two entries to the existing TLS 1158 "ExtensionType Values" registry, defined in [RFC5246], for 1159 oscore_connection_id(TBD1) and cose_ext(TBD2) defined in this 1160 document, as described in the table below. 1162 Value Extension Name TLS 1.3 DTLS Only Recommended Reference 1163 ----------------------------------------------------------------------- 1164 TBD1 oscore_connection_id Y N N [[This doc]] 1165 TBD2 cose_ext Y N N [[This doc]] 1167 Note: The "N" values in the Recommended column are set because these 1168 extensions are intended only for specific use cases. 1170 12.2. TLS Ciphersuite to OSCORE/COSE Algorithm Mapping 1172 IANA is requested to create a new registry for mapping TLS 1173 ciphersuites to SCORE/COSE algorithms 1175 An initial mapping can be found in Figure 13. 1177 Registration requests are evaluated after a three-week review period 1178 on the tls-reg-review@ietf.or mailing list, on the advice of one or 1179 more Designated Experts [RFC8126]. However, to allow for the 1180 allocation of values prior to publication, the Designated Experts may 1181 approve registration once they are satisfied that such a 1182 specification will be published. 1184 Registration requests sent to the mailing list for review should use 1185 an appropriate subject (e.g., "Request to register an TLS - OSCORE/ 1186 COSE algorithm mapping: example"). Registration requests that are 1187 undetermined for a period longer than 21 days can be brought to the 1188 IESG's attention (using the iesg@ietf.org mailing list) for 1189 resolution. 1191 Criteria that should be applied by the Designated Experts includes 1192 determining whether the proposed registration duplicates existing 1193 functionality, whether it is likely to be of general applicability or 1194 whether it is useful only for a single extension, and whether the 1195 registration description is clear. 1197 IANA must only accept registry updates from the Designated Experts 1198 and should direct all requests for registration to the review mailing 1199 list. 1201 12.3. .well-known URI Registry 1203 IANA is requested to add the well-known URI 'atls' to the Well-Known 1204 URIs registry. 1206 o URI suffix: atls 1208 o Change controller: IETF 1210 o Specification document(s): [[this document]] 1212 o Related information: None 1214 12.4. Media Types Registry 1216 IANA is requested to add the media type 'application/atls' to the 1217 Media Types registry. 1219 o Type name: application 1221 o Subtype name: atls 1223 o Required parameters: N/A 1225 o Optional parameters: N/A 1227 o Encoding considerations: binary 1229 o Security considerations: See Security Considerations section of 1230 this document. 1232 o Interoperability considerations: N/A 1234 o Published specification: [[this document]] (this document) 1236 o Applications that use this media type: Potentially any 1238 o Fragment identifier considerations: N/A 1240 o Additional information: 1242 * Magic number(s): N/A 1244 * File extension(s): N/A 1246 * Macintosh file type code(s): N/A 1248 o Person & email address to contact for further information: See 1249 "Authors' Addresses" section. 1251 o Intended usage: COMMON 1253 o Restrictions on usage: N/A 1255 o Author: See "Authors' Addresses" section. 1257 o Change Controller: IESG 1259 12.5. HTTP Content-Formats Registry 1261 IANA is requested to add the media type 'application/atls' to the 1262 HTTP Content-Formats registry. 1264 o Media Type: application/atls 1266 o Encoding: binary 1268 o ID: TBD 1270 o Reference: [[this document]] 1272 12.6. CoAP Content-Formats Registry 1274 IANA is requested to add the media type 'application/atls' to the 1275 CoAP Content-Formats registry. 1277 o Media Type: application/atls 1279 o Encoding: binary 1281 o ID: TBD 1283 o Reference: [[this document]] 1285 12.7. TLS Key Extractor Label 1287 IANA is requested to register the "application-layer-tls" label in 1288 the TLS Extractor Label Registry to correspond to this specification. 1290 13. Security Considerations 1292 This specification re-uses the TLS and DTLS and hence the security 1293 considerations of the respective TLS/DTLS version applies. As 1294 described in Section 5.2, implementers need to take the policy 1295 configuration into account when applying security protection at 1296 various layers of the stack even if the same protocol is used since 1297 the communiation endpoints and the security requirements are likely 1298 going to vary. 1300 For use in the IoT environment the considerations described in 1301 [RFC7925] apply and other environments the guidelines in [RFC7525] 1302 are applicable. 1304 14. References 1306 14.1. Normative References 1308 [I-D.ietf-core-object-security] 1309 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1310 "Object Security for Constrained RESTful Environments 1311 (OSCORE)", draft-ietf-core-object-security-16 (work in 1312 progress), March 2019. 1314 [I-D.ietf-tls-dtls13] 1315 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1316 Datagram Transport Layer Security (DTLS) Protocol Version 1317 1.3", draft-ietf-tls-dtls13-43 (work in progress), April 1318 2021. 1320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1321 Requirement Levels", BCP 14, RFC 2119, 1322 DOI 10.17487/RFC2119, March 1997, 1323 . 1325 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1326 (TLS) Protocol Version 1.2", RFC 5246, 1327 DOI 10.17487/RFC5246, August 2008, 1328 . 1330 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1331 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1332 March 2010, . 1334 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1335 DOI 10.17487/RFC6265, April 2011, 1336 . 1338 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1339 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1340 January 2012, . 1342 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1343 Protocol (HTTP/1.1): Message Syntax and Routing", 1344 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1345 . 1347 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1348 Application Protocol (CoAP)", RFC 7252, 1349 DOI 10.17487/RFC7252, June 2014, 1350 . 1352 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1353 "Recommendations for Secure Use of Transport Layer 1354 Security (TLS) and Datagram Transport Layer Security 1355 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1356 2015, . 1358 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1359 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1360 DOI 10.17487/RFC7540, May 2015, 1361 . 1363 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1364 Security (TLS) / Datagram Transport Layer Security (DTLS) 1365 Profiles for the Internet of Things", RFC 7925, 1366 DOI 10.17487/RFC7925, July 2016, 1367 . 1369 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1370 Writing an IANA Considerations Section in RFCs", BCP 26, 1371 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1372 . 1374 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1375 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1376 May 2017, . 1378 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1379 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1380 . 1382 14.2. Informative References 1384 [ALTS] Google, "Application Layer Transport Security", December 1385 2017, . 1388 [Bluetooth] 1389 Bluetooth, "Bluetooth Core Specification v5.0", 2016, 1390 . 1392 [I-D.ietf-anima-bootstrapping-keyinfra] 1393 Pritikin, M., Richardson, M. C., Eckert, T., Behringer, M. 1394 H., and K. Watsen, "Bootstrapping Remote Secure Key 1395 Infrastructure (BRSKI)", draft-ietf-anima-bootstrapping- 1396 keyinfra-45 (work in progress), November 2020. 1398 [I-D.ietf-httpbis-bcp56bis] 1399 Nottingham, M., "Building Protocols with HTTP", draft- 1400 ietf-httpbis-bcp56bis-14 (work in progress), August 2021. 1402 [I-D.ietf-tls-dtls-connection-id] 1403 Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus, 1404 "Connection Identifiers for DTLS 1.2", draft-ietf-tls- 1405 dtls-connection-id-13 (work in progress), June 2021. 1407 [I-D.mattsson-lwig-security-protocol-comparison] 1408 Mattsson, J. and F. Palombini, "Comparison of CoAP 1409 Security Protocols", draft-mattsson-lwig-security- 1410 protocol-comparison-01 (work in progress), March 2018. 1412 [I-D.rescorla-tls-ctls] 1413 Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS 1414 1.3", draft-rescorla-tls-ctls-04 (work in progress), March 1415 2020. 1417 [I-D.selander-ace-cose-ecdhe] 1418 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 1419 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 1420 cose-ecdhe-14 (work in progress), September 2019. 1422 [LwM2M] Open Mobile Alliance, "Lightweight Machine to Machine 1423 Requirements", December 2017, 1424 . 1426 [Noise] Perrin, T., "Noise Protocol Framework", October 2017, 1427 . 1429 [Norrell] Norrell, ., "Use SSL/TLS within a different protocol with 1430 BIO pairs", 2016, 1431 . 1434 [Signal] Open Whisper Systems, "Signal Protocol", 2016, 1435 . 1437 [SSLEngine] 1438 Oracle, "SSLEngineSimpleDemo.java", 2004, . 1442 [ZigBee] ZigBee Alliance, "ZigBee Specification", 2012, 1443 . 1445 Appendix A. Pseudo Code 1447 This appendix gives both C and Java pseudo code illustrating how to 1448 inject and extract raw TLS records from a TLS software stack. Please 1449 note that this is illustrative, non-functional pseudo code that does 1450 not compile. 1452 A.1. OpenSSL 1454 OpenSSL provides a set of Basic Input/Output (BIO) APIs that can be 1455 used to build a custom transport layer for TLS connections. This 1456 appendix gives pseudo code on how BIO APIs could be used to build a 1457 client application that completes a TLS handshake and exchanges 1458 application data with a service. 1460 char inbound[MAX]; 1461 char outbound[MAX]; 1462 int rx_bytes; 1463 SSL_CTX *ctx = SSL_CTX_new(); 1464 SSL *ssl = SSL_new(ctx); 1466 // Create in-memory BIOs and plug in to the SSL session 1467 BOI* bio_in = BIO_new(BIO_s_mem()); 1468 BOI* bio_out = BIO_new(BIO_s_mem()); 1469 SSL_set_bio(ssl, bio_in, bio_out); 1471 // We are a client 1472 SSL_set_connect_state(ssl); 1474 // Loop through TLS flights until we are done 1475 do { 1476 // Calling SSL_do_handshake() will result in a full 1477 // TLS flight being written to the BIO buffer 1478 SSL_do_handshake(ssl); 1480 // Read the client flight that the TLS session 1481 // has written to memory 1482 BIO_read(bio_out, outbound, MAX); 1484 // POST the outbound bytes to the server using a suitable 1485 // function. Lets assume that the server response will be 1486 // written to the 'inbound' buffer 1487 num_bytes = postTlsRecords(outbound, inbound); 1489 // Write the server flight to the memory BIO so the TLS session 1490 // can read it. The next call to SSL_do_handshake() will handle 1491 // this received server flight 1492 BIO_write(bio_in, inbound, num_bytes); 1494 } while (!SSL_is_init_finished(ssl)); 1496 // Send a message to the server. Calling SSL_write() will run the 1497 // plaintext through the TLS session and write the encrypted TLS 1498 // records to the BIO buffer 1499 SSL_write(ssl, "Hello World", strlen("Hello World")); 1501 // Read the TLS records from the BIO buffer and 1502 // POST them to the server 1503 BIO_read(bio_out, outbound, MAX); 1504 num_bytes = postTlsRecords(outbound, inbound); 1506 A.2. Java JSSE 1508 The Java SSLEngine class "enables secure communications using 1509 protocols such as the Secure Sockets Layer (SSL) or IETF RFC 2246 1510 "Transport Layer Security" (TLS) protocols, but is transport 1511 independent". This pseudo code illustrates how a server could use 1512 the SSLEngine class to handle an inbound client TLS flight and 1513 generate an outbound server TLS flight response. 1515 SSLEngine sslEngine = SSLContext.getDefault().createSSLEngine(); 1516 sslEngine.setUseClientMode(false); 1517 sslEngine.beginHandshake(); 1519 // Lets assume 'inbound' has been populated with 1520 // the Client 1st Flight 1521 ByteBuffer inbound; 1523 // 'outbound' will be populated with the 1524 // Server 1st Flight response 1525 ByteBuffer outbound; 1527 // SSLEngine handles one TLS Record per call to unwrap(). 1528 // Loop until the engine is finished unwrapping. 1529 while (sslEngine.getHandshakeStatus() == 1530 HandshakeStatus.NEED_UNWRAP) { 1531 SSLEngineResult res = sslEngine.unwrap(inbound, outbound); 1533 // SSLEngine may need additional tasks run 1534 if (res.getHandshakeStatus() == NEED_TASK) { 1535 Runnable run = sslEngine.getDelegatedTask(); 1536 run.run(); 1537 } 1538 } 1540 // The SSLEngine has now finished handling all inbound TLS Records. 1541 // Check if it wants to generate outbound TLS Records. SSLEngine 1542 // generates one TLS Record per call to wrap(). 1543 // Loop until the engine is finished wrapping. 1544 while (sslEngine.getHandshakeStatus() == 1545 HandshakeStatus.NEED_WRAP) { 1546 SSLEngineResult res = sslEngine.wrap(inbound, outbound); 1548 // SSLEngine may need additional tasks run 1549 if (res.getHandshakeStatus() == NEED_TASK) { 1550 Runnable run = sslEngine.getDelegatedTask(); 1551 run.run(); 1552 } 1553 } 1555 // outbound ByteBuffer now contains a complete server flight 1556 // containing multiple TLS Records 1557 // Rinse and repeat! 1559 Appendix B. ATLS and HTTP CONNECT 1561 It is worthwhile comparing and contrasting ATLS with HTTP CONNECT 1562 tunneling. 1564 First, let us introduce some terminology: 1566 o HTTP Proxy: A HTTP Proxy operates at the application layer, 1567 handles HTTP CONNECT messages from clients, and opens tunnels to 1568 remote origin servers on behalf of clients. If a client 1569 establishes a tunneled TLS connection to the origin server, the 1570 HTTP Proxy does not attempt to intercept or inspect the HTTP 1571 messages exchanged between the client and the server 1573 o middlebox: A middlebox operates at the transport layer, terminates 1574 TLS connections from clients, and originates new TLS connections 1575 to services. A middlebox inspects all messages sent between 1576 clients and services. Middleboxes are generally completely 1577 transparent to applications, provided that the necessary PKI root 1578 Certificate Authority is installed in the client's trust store. 1580 HTTP Proxies and middleboxes are logically separate entities and one 1581 or both of these may be deployed in a network. 1583 HTTP CONNECT is used by clients to instruct a HTTP Forward Proxy 1584 deployed in the local domain to open up a tunnel to a remote origin 1585 server that is typically deployed in a different domain. Assuming 1586 that TLS transport is used between both client and proxy, and proxy 1587 and origin server, the network architecture is as illustrated in 1588 Figure 16. Once the proxy opens the transport tunnel to the service, 1589 the client establishes an end-to-end TLS session with the service, 1590 and the proxy is blindly transporting TLS records (the C->S TLS 1591 session records) between the client and the service. From the client 1592 perspective, it is tunneling a TLS session to the service inside the 1593 TLS session it has established to the proxy (the C->P TLS session). 1594 No middlebox is attempting to intercept or inspect the HTTP messages 1595 between the client and the service. 1597 +----------+ +----------+ 1598 | C->S HTTP| | C->S HTTP| 1599 +----------+ +----------+ 1600 | C->S TLS | | C->S TLS | 1601 +----------+ +----------+ 1602 | C->P TLS | | P->S TCP | 1603 +----------+ +----------+ 1604 | C->P TCP | 1605 +----------+ 1607 +--------+ +------------+ +---------+ 1608 | Client |----->| HTTP Proxy |----->| Service | 1609 +--------+ +------------+ +---------+ 1611 Figure 16: HTTP Proxy transport layers 1613 A more complex network topology where the network operator has both a 1614 HTTP Proxy and a middlebox deployed is illustrated in Figure 17. In 1615 this scenario, the proxy has tunneled the TLS session from the client 1616 towards the origin server, however the middlebox is intercepting and 1617 terminating this TLS session. A TLS session is established between 1618 the client and the middlebox (C->M TLS), and not end-to-end between 1619 the client and the server. It can clearly be seen that HTTP CONNECT 1620 and HTTP Proxies serve completely different functions than 1621 middleboxes. 1623 Additionally, the fact that the TLS session is established between 1624 the client and the middlebox can be problematic for two reasons: 1626 o the middle box is inspecting traffic that is sent between the 1627 client and the service 1629 o the client may not have the necessary PKI root Certificate 1630 Authority installed that would enable it to validate the TLS 1631 connection to the middlebox. This is the scenario outlined in 1632 Section 3.2. 1634 +----------+ +----------+ +----------+ 1635 | C->S HTTP| | C->S HTTP| | C->S HTTP| 1636 +----------+ +----------+ +----------+ 1637 | C->M TLS | | C->M TLS | | M->S TLS | 1638 +----------+ +----------+ +----------+ 1639 | C->P TLS | | P->M TCP | | M->S TCP | 1640 +----------+ +----------+ +----------+ 1641 | C->P TCP | 1642 +----------+ 1644 +--------+ +------------+ +-----------+ +---------+ 1645 | Client |----->| HTTP Proxy |----->| Middlebox |----->| Service | 1646 +--------+ +------------+ +-----------+ +---------+ 1648 Figure 17: HTTP Proxy and middlebox transport layers 1650 As HTTP CONNECT can be used to establish a tunneled TLS connection, 1651 one hypothetical solution to this middlebox issue is for the client 1652 to issue a HTTP CONNECT command to a HTTP Reverse Proxy deployed in 1653 front of the origin server. This solution is not practical for 1654 several reasons: 1656 o if there is a local domain HTTP Forward Proxy deployed, this would 1657 result in the client doing a first HTTP CONNECT to get past the 1658 Forward Proxy, and then a second HTTP CONNECT to get past the 1659 Reverse Proxy. No client or client library supports the concept 1660 of HTTP CONNECT inside HTTP CONNECT. 1662 o if there is no local domain HTTP Proxy deployed, the client still 1663 has to do a HTTP CONNECT to the HTTP Reverse Proxy. This breaks 1664 with standard and expected HTTP CONNECT operation, as HTTP CONNECT 1665 is only ever called if there is a local domain proxy. 1667 o clients cannot generate CONNECT from XHR in web applications. 1669 o this would require the deployment of a Reverse Proxy in front of 1670 the origin server, or else support of the HTTP CONNECT method in 1671 standard web frameworks. This is not an elegant design. 1673 o using HTTP CONNECT with HTTP 1.1 to a Reverse Proxy will break 1674 middleboxes inspecting HTTP traffic, as the middlebox would see 1675 TLS records when it expects to see HTTP payloads. 1677 In contrast to trying to force HTTP CONNECT to address a problem for 1678 which it was not designed to address, and having to address all the 1679 issues just outlined; ATLS is specifically designed to address the 1680 middlebox issue in a simple, easy to develop, and easy to deploy 1681 fashion. 1683 o ATLS works seamlessly with HTTP Proxy deployments 1685 o no changes are required to HTTP CONNECT semantics 1687 o no changes are required to HTTP libraries or stacks 1689 o no additional Reverse Proxy is required to be deployed in front of 1690 origin servers 1692 It is also worth noting that if HTTP CONNECT to a Reverse Proxy were 1693 a conceptually sound solution, the solution still ultimately results 1694 in encrypted traffic traversing the middlebox that the middlebox 1695 cannot intercept and inspect. That is ultimately what ATLS results 1696 in - traffic traversing the middle box that the middlebox cannot 1697 intercept and inspect. Therefore, from a middlebox perspective, the 1698 differences between the two solutions are in the areas of solution 1699 complexity and protocol semantics. It is clear that ATLS is a 1700 simpler, more elegant solution that HTTP CONNECT. 1702 Appendix C. Alternative Approaches to Application Layer End-to-End 1703 Security 1705 End-to-end security at the application layer is increasing seen as a 1706 key requirement across multiple applications and services. Some 1707 examples of end-to-end security mechanisms are outlined here. All 1708 the solutions outlined here have some common characteristics. The 1709 solutions: 1711 o do not rely on transport layer security 1713 o define a new handshake protocol for establishment of a secure end- 1714 to-end session 1716 C.1. Noise 1718 [Noise] is a framework for cryptographic protocols based on Elliptic 1719 Curve Diffie-Hellman (ECDH) key agreement, AEAD encryption, and 1720 BLAKE2 and SHA2 hash functions. Noise is currently used by WhatsApp, 1721 WireGuard, and Lightning. 1723 The current Noise protocol framework defines mechanisms for proving 1724 possession of a private key, but does not define authentication 1725 mechanisms. Section 14 "Security Considerations" of Noise states: 1726 ~~~ it's up to the application to determine whether the remote 1727 party's static public key is acceptable ~~~ 1729 C.2. Signal 1731 The [Signal] protocol provides end-to-end encryption and uses EdDSA 1732 signatures, Triple Diffie-Hellman handshake for shared secret 1733 establishment, and the Double Ratchet Algorithm for key management. 1734 It is used by Open Whisper Systems, WhatsApp and Google. 1736 Similar to Noise, Signal does not define an authentication mechanism. 1737 The current [X3DH] specification states in Section 4.1 1738 "Authentication": 1740 Methods for doing this are outside the scope of this document 1742 C.3. Google ALTS 1744 Google's Application Layer Transport Security [ALTS] is a mutual 1745 authentication and transport encryption system used for securing 1746 Remote Procedure Call (RPC) communications within Google's 1747 infrastructure. ALTS uses an ECDH handshake protocol and a record 1748 protocol containing AES encrypted payloads. 1750 C.4. Ephemeral Diffie-Hellman Over COSE (EDHOC) 1752 There is ongoing work to standardise EDHOC 1753 [I-D.selander-ace-cose-ecdhe], which defines a SIGMA-I based 1754 authenticated key exchange protocol using COSE and CBOR. 1756 Authors' Addresses 1758 Owen Friel 1759 Cisco 1761 Email: ofriel@cisco.com 1763 Richard Barnes 1764 Cisco 1766 Email: rlb@ipv.sx 1768 Max Pritikin 1769 Cisco 1771 Email: pritikin@cisco.com 1772 Hannes Tschofenig 1773 Arm Ltd. 1775 Email: hannes.tschofenig@gmx.net 1777 Mark Baugher 1778 Consultant 1780 Email: mark@mbaugher.com