idnits 2.17.00 (12 Aug 2021) /tmp/idnits58067/draft-friel-tls-atls-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (July 08, 2019) is 1048 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MAX' is mentioned on line 1569, but not defined == Missing Reference: 'X3DH' is mentioned on line 1709, but not defined == Unused Reference: 'LwM2M' is defined on line 1529, but no explicit reference was found in the text == Outdated reference: draft-ietf-core-object-security has been published as RFC 8613 == Outdated reference: draft-ietf-tls-dtls13 has been published as RFC 9147 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: draft-ietf-anima-bootstrapping-keyinfra has been published as RFC 8995 == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-bcp56bis-08 == Outdated reference: draft-ietf-tls-dtls-connection-id has been published as RFC 9146 == Outdated reference: A later version (-04) exists of draft-rescorla-tls-ctls-01 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-13 Summary: 2 errors (**), 0 flaws (~~), 11 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: Standards Track M. Pritikin 5 Expires: January 9, 2020 Cisco 6 H. Tschofenig 7 Arm Ltd. 8 M. Baugher 9 Consultant 10 July 08, 2019 12 Application-Layer TLS 13 draft-friel-tls-atls-03 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 January 9, 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. Bootstrapping Devices . . . . . . . . . . . . . . . . . . 4 68 3.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 5 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 HTTP Transport . . . . . . . . . . . . . . . . . . 18 76 7.1. Protocol Summary . . . . . . . . . . . . . . . . . . . . 18 77 7.2. Content-Type Header . . . . . . . . . . . . . . . . . . . 19 78 7.3. HTTP Status Codes . . . . . . . . . . . . . . . . . . . . 19 79 7.4. ATLS Session Tracking . . . . . . . . . . . . . . . . . . 19 80 7.5. Session Establishment and Key Exporting . . . . . . . . . 19 81 7.6. Illustrative ATLS over HTTP Session Establishment . . . . 19 82 7.7. ATLS and HTTP CONNECT . . . . . . . . . . . . . . . . . . 20 83 8. ATLS over CoAP Transport . . . . . . . . . . . . . . . . . . 23 84 9. Key Exporting and Application Data Encryption . . . . . . . . 24 85 9.1. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 25 86 9.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 26 87 10. TLS Ciphersuite to COSE/OSCORE Algorithm Mapping . . . . . . 26 88 11. TLS Extensions . . . . . . . . . . . . . . . . . . . . . . . 27 89 11.1. The "oscore_connection_id" Extension . . . . . . . . . . 27 90 11.2. The "cose_ext" Extension . . . . . . . . . . . . . . . . 27 91 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 92 12.1. "oscore_connection_id" TLS extension . . . . . . . . . . 28 93 12.2. TLS Ciphersuite to OSCORE/COSE Algorithm Mapping . . . . 28 94 12.3. .well-known URI Registry . . . . . . . . . . . . . . . . 29 95 12.4. Media Types Registry . . . . . . . . . . . . . . . . . . 29 96 12.5. HTTP Content-Formats Registry . . . . . . . . . . . . . 30 97 12.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 30 98 12.7. TLS Key Extractor Label . . . . . . . . . . . . . . . . 31 99 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 100 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 101 14.1. Normative References . . . . . . . . . . . . . . . . . . 31 102 14.2. Informative References . . . . . . . . . . . . . . . . . 33 103 Appendix A. Pseudo Code . . . . . . . . . . . . . . . . . . . . 34 104 A.1. OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . 34 105 A.2. Java JSSE . . . . . . . . . . . . . . . . . . . . . . . . 36 106 Appendix B. Example ATLS Handshake . . . . . . . . . . . . . . . 38 107 Appendix C. Alternative Approaches to Application Layer End-to- 108 End Security . . . . . . . . . . . . . . . . . . . . 38 109 C.1. Noise . . . . . . . . . . . . . . . . . . . . . . . . . . 38 110 C.2. Signal . . . . . . . . . . . . . . . . . . . . . . . . . 38 111 C.3. Google ALTS . . . . . . . . . . . . . . . . . . . . . . . 39 112 C.4. Ephemeral Diffie-Hellman Over COSE (EDHOC) . . . . . . . 39 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 115 1. Introduction 117 There are multiple scenarios where there is a need for application 118 layer end-to-end security between clients and application services. 119 Two examples include: 121 o Bootstrapping devices that must connect to HTTP application 122 services across untrusted TLS interception middleboxes 124 o Constrained devices connecting via gateways to application 125 services, where different transport layer protocols may be in use 126 on either side of the gateway, with the gateway transcoding 127 between the different transport layer protocols. 129 These two scenarios are described in more detail in Section 3. 131 This document describes how clients and applications can leverage 132 standard TLS software stacks to establish secure end-to-end encrypted 133 connections at the application layer. TLS [RFC5246] [RFC8446] or 134 DTLS [RFC6347] [I-D.ietf-tls-dtls13] can be used and this document is 135 agnostic to the versions being used. There are multiple advantages 136 to reuse of existing TLS software stacks for establishment of 137 application layer secure connections. These include: 139 o many clients and application services already include a TLS 140 software stack, so there is no need to include yet another 141 software stack in the software build 143 o no need to define a new cryptographic negotiation, authentication, 144 and key exchange protocol between clients and services 146 o provides standards based PKI mutual authentication between clients 147 and services 149 o no need to train software developers on how to use a new 150 cryptographic protocols or libraries 152 o automatically benefit from new cipher suites by simply upgrading 153 the TLS software stack 155 o automatically benefit from new features, bugfixes, etc. in TLS 156 software stack upgrades 158 When TLS or DTLS is used at the application layer we refer to it as 159 Application-Layer TLS, or ATLS. There is, however, no difference to 160 TLS versions used over connection-oriented transports, such as TCP or 161 SCTP. The same is true for DTLS. The difference is mainly in its 162 use and the requirements placed on the underlying transport. 164 This document defines how ATLS can be used over HTTP [RFC7230] 165 [RFC7540] and over CoAP. This document does not preclude the use of 166 other transports. However, defining how ATLS can be established over 167 [ZigBee], [Bluetooth], etc. is beyond the scope of 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. Bootstrapping Devices 187 There are far more classes of clients being deployed on today's 188 networks than at any time previously. This poses challenges for 189 network administrators who need to manage their network and the 190 clients connecting to their network, and poses challenges for client 191 vendors and client software developers who must ensure that their 192 clients can connect to all required services. 194 One common example is where a client is deployed on a local domain 195 TCP/IP network that protects its perimeter using a TLS terminating 196 middlebox, and the client needs to establish a secure connection to a 197 service in a different network via the middlebox. This is 198 illustrated in Figure 1. 200 Traditionally, this has been enabled by the network administrator 201 deploying the necessary certificate authority trusted roots on the 202 client. This can be achieved at scale using standard tools that 203 enable the administrator to automatically push trusted roots out to 204 all client machines in the network from a centralized domain 205 controller. This works for personal computers, laptops and servers 206 running standard Operating Systems that can be centrally managed. 207 This client management process breaks for multiple classes of clients 208 that are being deployed today, there is no standard mechanism for 209 configuring trusted roots on these clients, and there is no standard 210 mechanism for these clients to securely traverse middleboxes. 212 +--------+ C->M TLS +-----------+ M->S TLS +---------+ 213 | Client |--------------->| Middlebox |------------->| Service | 214 +--------+ +-----------+ +---------+ 215 ^ ^ 216 | | 217 +-----------Client to Service ATLS Connection---------+ 219 Figure 1: Bootstrapping Devices 221 The ATLS mechanism defined in this document enables clients to 222 traverse middleboxes and establish secure connections to services 223 across network domain boundaries. The purpose of this connection may 224 simply be to facilitate a bootstrapping process, for example 225 [I-D.ietf-anima-bootstrapping-keyinfra], whereby the client securely 226 discovers the local domain certificate authorities required to 227 establish a trusted network layer TLS connection to the middlebox. 229 3.2. Constrained Devices 231 Two constrained device use cases are outlined here. 233 3.2.1. Constrained Device Connecting over a Non-IP Network 235 There are industry examples of smart lighting systems where 236 luminaires are connected using ZigBee to a gateway. A server 237 connects to the gateway using CoAP over DTLS. The server can control 238 the luminaires by sending messages and commands via the gateway. The 239 gateway has full access to all messages sent between the luminaires 240 and the server. 242 A generic use case similar to the smart lighting system outlined 243 above has an IoT device talking ZigBee, Bluetooth Low Energy, 244 LoRaWAN, NB-IoT, etc. to a gateway, with the gateway in turn talking 245 CoAP over DTLS or another protocol to a server located in the cloud 246 or on-premise. This is illustrated in Figure 2. 248 There are scenarios where certain messages sent between the IoT 249 device and the server must not be exposed to the gateway function. 250 Additionally, the two endpoints may not have visibility to and no 251 guarantees about what transport layer security and encryption is 252 enforced across all hops end-to-end as they only have visibility to 253 their immediate next hop. ATLS addresses these concerns. 255 +--------+ ZigBee +---------+ CoAP/DTLS +------------+ 256 | Device |-------------->| Gateway |------------->| Server | 257 +--------+ +---------+ +------------+ 258 ^ ^ 259 | | 260 +-------- Device to Server -------+ 262 Figure 2: IoT Closed Network Gateway 264 3.2.2. Constrained Device Connecting over IP 266 In this example an IoT device connecting to a gateway using a 267 suitable transport mechanism, such as ZigBee, CoAP, MQTT, etc. The 268 gateway function in turn talks HTTP over TLS (or, for example, HTTP 269 over QUIC) to an application service over the Internet. This is 270 illustrated in Figure 3. 272 The gateway may not be trusted and all messages between the IoT 273 device and the application service must be end-to-end encrypted. 274 Similar to the previous use case, the endpoints have no guarantees 275 about what level of transport layer security is enforced across all 276 hops. Again, ATLS addresses these concerns. 278 +--------+ CoAP/DTLS +------------------+ HTTP/TLS +---------+ 279 | Device |-------------->| Internet Gateway |------------>| Service | 280 +--------+ +------------------+ +---------+ 281 ^ ^ 282 | | 283 +---------Device to Cloud Service ATLS Connection----------+ 285 Figure 3: IoT Internet Gateway 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 7 and Section 8 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 7 and Section 8, 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 HTTP Transport 800 The assumption is that the client will establish a transport layer 801 connection to the server for exchange of HTTP messages. The 802 underlying transport layer connection could be over TCP or TLS. The 803 client will then establish an application layer TLS connection with 804 the server by exchanging TLS records with the server inside HTTP 805 message request and response bodies. 807 7.1. Protocol Summary 809 All ATLS records are transported unmodified as binary data within 810 HTTP message bodies. The application simply extracts the TLS records 811 from the TLS stack and inserts them directly into HTTP message 812 bodies. Each message body contains a full TLS flight, which may 813 contain multiple TLS records. 815 The client sends all ATLS records to the server in the bodies of POST 816 requests. 818 The server sends all ATLS records to the client in the bodies of 200 819 OK responses to the POST requests. 821 The URI path used by ATLS is "/.well-known/atls". 823 7.2. Content-Type Header 825 A new Content-Type header value is defined: 827 Content-type: application/atls 829 All message bodies containing ATLS records must set this Content- 830 Type. This enables middleboxes to readily identify ATLS payloads. 832 7.3. HTTP Status Codes 834 This document does not define any new HTTP status codes, and does not 835 specify additional semantics or refine existing semantics for status 836 codes. This is the best current practice as outlined in 837 [I-D.ietf-httpbis-bcp56bis]. 839 7.4. ATLS Session Tracking 841 The application service needs to track multiple client application 842 layer TLS sessions so that it can correlate TLS records received in 843 HTTP message bodies with the appropriate TLS session. The 844 application service should use stateful cookies [RFC6265] in order to 845 achieve this as recommended in [I-D.ietf-httpbis-bcp56bis]. 847 7.5. Session Establishment and Key Exporting 849 It is recommended that applications using ATLS over HTTP transport 850 only use ATLS for session establishment and key exchange, resulting 851 in only 2 ATLS RTTs between the client and the application service. 853 Key exporting must be carried out as described in Section 9. 855 7.6. Illustrative ATLS over HTTP Session Establishment 857 A client initiates an ATLS session by sending the first TLS flight in 858 a POST request message body to the ATLS server. 860 POST /.well-known/atls 861 Content-Type: application/atls 863 865 The server handles the request, creates an ATLS session object, and 866 replies by including its first TLS flight in a 200 OK message body. 867 The server also sets a suitable cookie for session tracking purposes. 869 200 OK 870 Content-Type: application/atls 871 Set-Cookie: my-atls-cookie=my-cookie-value 873 875 The client handles the server first flight TLS records and replies 876 with its second flight. 878 POST /.well-known/atls 879 Content-Type: application/atls 880 Cookie: my-atls-cookie=my-cookie-value 882 884 The server handles the second flight, establishes the ATLS session, 885 and replies with its second flight. 887 200 OK 888 Content-Type: application/atls 890 892 7.7. ATLS and HTTP CONNECT 894 It is worthwhile comparing and contrasting ATLS with HTTP CONNECT 895 tunneling. 897 First, let us introduce some terminology: 899 o HTTP Proxy: A HTTP Proxy operates at the application layer, 900 handles HTTP CONNECT messages from clients, and opens tunnels to 901 remote origin servers on behalf of clients. If a client 902 establishes a tunneled TLS connection to the origin server, the 903 HTTP Proxy does not attempt to intercept or inspect the HTTP 904 messages exchanged between the client and the server 906 o middlebox: A middlebox operates at the transport layer, terminates 907 TLS connections from clients, and originates new TLS connections 908 to services. A middlebox inspects all messages sent between 909 clients and services. Middleboxes are generally completely 910 transparent to applications, provided that the necessary PKI root 911 Certificate Authority is installed in the client's trust store. 913 HTTP Proxies and middleboxes are logically separate entities and one 914 or both of these may be deployed in a network. 916 HTTP CONNECT is used by clients to instruct a HTTP Forward Proxy 917 deployed in the local domain to open up a tunnel to a remote origin 918 server that is typically deployed in a different domain. Assuming 919 that TLS transport is used between both client and proxy, and proxy 920 and origin server, the network architecture is as illustrated in 921 Figure 12. Once the proxy opens the transport tunnel to the service, 922 the client establishes an end-to-end TLS session with the service, 923 and the proxy is blindly transporting TLS records (the C->S TLS 924 session records) between the client and the service. From the client 925 perspective, it is tunneling a TLS session to the service inside the 926 TLS session it has established to the proxy (the C->P TLS session). 927 No middlebox is attempting to intercept or inspect the HTTP messages 928 between the client and the service. 930 +----------+ +----------+ 931 | C->S HTTP| | C->S HTTP| 932 +----------+ +----------+ 933 | C->S TLS | | C->S TLS | 934 +----------+ +----------+ 935 | C->P TLS | | P->S TCP | 936 +----------+ +----------+ 937 | C->P TCP | 938 +----------+ 940 +--------+ +------------+ +---------+ 941 | Client |----->| HTTP Proxy |----->| Service | 942 +--------+ +------------+ +---------+ 944 Figure 12: HTTP Proxy transport layers 946 A more complex network topology where the network operator has both a 947 HTTP Proxy and a middlebox deployed is illustrated in Figure 13. In 948 this scenario, the proxy has tunneled the TLS session from the client 949 towards the origin server, however the middlebox is intercepting and 950 terminating this TLS session. A TLS session is established between 951 the client and the middlebox (C->M TLS), and not end-to-end between 952 the client and the server. It can clearly be seen that HTTP CONNECT 953 and HTTP Proxies serve completely different functions than 954 middleboxes. 956 Additionally, the fact that the TLS session is established between 957 the client and the middlebox can be problematic for two reasons: 959 o the middle box is inspecting traffic that is sent between the 960 client and the service 962 o the client may not have the necessary PKI root Certificate 963 Authority installed that would enable it to validate the TLS 964 connection to the middlebox. This is the scenario outlined in 965 Section 3.1. 967 +----------+ +----------+ +----------+ 968 | C->S HTTP| | C->S HTTP| | C->S HTTP| 969 +----------+ +----------+ +----------+ 970 | C->M TLS | | C->M TLS | | M->S TLS | 971 +----------+ +----------+ +----------+ 972 | C->P TLS | | P->M TCP | | M->S TCP | 973 +----------+ +----------+ +----------+ 974 | C->P TCP | 975 +----------+ 977 +--------+ +------------+ +-----------+ +---------+ 978 | Client |----->| HTTP Proxy |----->| Middlebox |----->| Service | 979 +--------+ +------------+ +-----------+ +---------+ 981 Figure 13: HTTP Proxy and middlebox transport layers 983 As HTTP CONNECT can be used to establish a tunneled TLS connection, 984 one hypothetical solution to this middlebox issue is for the client 985 to issue a HTTP CONNECT command to a HTTP Reverse Proxy deployed in 986 front of the origin server. This solution is not practical for 987 several reasons: 989 o if there is a local domain HTTP Forward Proxy deployed, this would 990 result in the client doing a first HTTP CONNECT to get past the 991 Forward Proxy, and then a second HTTP CONNECT to get past the 992 Reverse Proxy. No client or client library supports the concept 993 of HTTP CONNECT inside HTTP CONNECT. 995 o if there is no local domain HTTP Proxy deployed, the client still 996 has to do a HTTP CONNECT to the HTTP Reverse Proxy. This breaks 997 with standard and expected HTTP CONNECT operation, as HTTP CONNECT 998 is only ever called if there is a local domain proxy. 1000 o clients cannot generate CONNECT from XHR in web applications. 1002 o this would require the deployment of a Reverse Proxy in front of 1003 the origin server, or else support of the HTTP CONNECT method in 1004 standard web frameworks. This is not an elegant design. 1006 o using HTTP CONNECT with HTTP 1.1 to a Reverse Proxy will break 1007 middleboxes inspecting HTTP traffic, as the middlebox would see 1008 TLS records when it expects to see HTTP payloads. 1010 In contrast to trying to force HTTP CONNECT to address a problem for 1011 which it was not designed to address, and having to address all the 1012 issues just outlined; ATLS is specifically designed to address the 1013 middlebox issue in a simple, easy to develop, and easy to deploy 1014 fashion. 1016 o ATLS works seamlessly with HTTP Proxy deployments 1018 o no changes are required to HTTP CONNECT semantics 1020 o no changes are required to HTTP libraries or stacks 1022 o no additional Reverse Proxy is required to be deployed in front of 1023 origin servers 1025 It is also worth noting that if HTTP CONNECT to a Reverse Proxy were 1026 a conceptually sound solution, the solution still ultimately results 1027 in encrypted traffic traversing the middlebox that the middlebox 1028 cannot intercept and inspect. That is ultimately what ATLS results 1029 in - traffic traversing the middle box that the middlebox cannot 1030 intercept and inspect. Therefore, from a middlebox perspective, the 1031 differences between the two solutions are in the areas of solution 1032 complexity and protocol semantics. It is clear that ATLS is a 1033 simpler, more elegant solution that HTTP CONNECT. 1035 8. ATLS over CoAP Transport 1037 To carry TLS messages over CoAP [RFC7252] it is recommended to use 1038 Confirmable messages while DTLS payloads may as well use non- 1039 confirmable messages. The exchange pattern in CoAP uses the 1040 following style: A request from the CoAP client to the CoAP server 1041 uses a POST with the ATLS message contained in the payload of the 1042 request. An ATLS response is returned by the CoAP server to the CoAP 1043 client in a 2.04 (Changed) message. 1045 When DTLS messages are conveyed in CoAP over UDP then the DDoS 1046 protection offered by DTLS MAY be used instead of replicating the 1047 functionality at the CoAP layer. If TLS is conveyed in CoAP over UDP 1048 then DDoS protection by CoAP has to be utilized. Carrying ATLS 1049 messages in CoAP over TCP does not require any additional DDoS 1050 protection. 1052 The URI path used by ATLS is "/.well-known/atls". 1054 {{coap-example} shows a TLS 1.3 handshake inside CoAP graphically. 1056 Client Server 1057 | | 1058 +--------->| Header: POST (Code=0.02) 1059 | POST | Uri-Path: "/.well-known/atls" 1060 | | Content-Format: application/atls 1061 | | Payload: ATLS (ClientHello) 1062 | | 1063 |<---------+ Header: 2.04 Changed 1064 | 2.04 | Content-Format: application/atls 1065 | | Payload: ATLS (ServerHello, 1066 | | {EncryptedExtensions}, {CertificateRequest*} 1067 | | {Certificate*}, {CertificateVerify*} {Finished}) 1068 | | 1069 +--------->| Header: POST (Code=0.02) 1070 | POST | Uri-Path: "/.well-known/atls" 1071 | | Content-Format: application/atls 1072 | | Payload: ATLS ({Certificate*}, 1073 | | {CertificateVerify*}, {Finished}) 1074 | | 1075 |<---------+ Header: 2.04 Changed 1076 | 2.04 | 1077 | | 1079 Figure 14: Transferring ATLS in CoAP 1081 Note that application data can already be sent by the server in the 1082 second message and by the client in the third message, in case of the 1083 full TLS 1.3 handshake. In case of the 0-RTT handshake application 1084 data can be sent earlier. To mix different media types in the same 1085 CoAP payload the application/multipart-core content type is used. 1087 Note also that CoAP blockwise transfer MAY be used if the payload 1088 size, for example due to the size of the certificate chain, exceeds 1089 the MTU size. 1091 9. Key Exporting and Application Data Encryption 1093 When solutions implement the architecture described in Figure 6, they 1094 leverage [RFC5705] for exporting keys. This section describes how to 1095 establish keying material and negotiate algorithms for OSCORE and for 1096 COSE. 1098 9.1. OSCORE 1100 When the OSCORE mode has been agreed using the "oscore_connection_id" 1101 extension defined in this document, different keys are used for DTLS/ 1102 TLS record protection and for OSCORE packet protection. These keys 1103 are produced using a TLS exporter [RFC5705] and the exporter takes 1104 three input values: 1106 o a disambiguating label string, 1108 o a per-association context value provided by the application using 1109 the exporter, and 1111 o a length value. 1113 The label string for use with this specification is defined as 'atls- 1114 oscore'. The per-association context value is empty. 1116 The length value is twice the size of the key size utilized by the 1117 negotiated algorithm since the lower-half is used for the Master 1118 Secret and the upper-half is used for the Master Salt. 1120 For example, if a TLS/DTLS 1.2 handshake negotiated the 1121 TLS_PSK_WITH_AES_128_CCM_8 ciphersuite then the key size utilized by 1122 the negotiated algorithm, i.e. AES 128, is 128 bit. Hence, the key 1123 extractor is requested to produce 2 x 128 bit keying material. 1125 The following parameters are needed for use with OSCORE: 1127 o Master Secret: The master secret is derived as described above. 1129 o Sender ID: This values is negotiated using the 1130 "oscore_connection_id" extension, as described in Section 11.1. 1132 o Recipient ID: This values is negotiated using the 1133 "oscore_connection_id" extension, as described in Section 11.1. 1135 o AEAD Algorithm: This value is negotiated using the ciphersuite 1136 exchange provided by the TLS/DTLS handshake. For example, if a 1137 TLS/DTLS 1.2 handshake negotiated the TLS_PSK_WITH_AES_128_CCM_8 1138 ciphersuite then the AEAD algorithm identifier is AES_128_CCM_8, 1139 which corresponds to two COSE algorithms, which both use AES-CCM 1140 mode with a 128-bit key, a 64-bit tag: 1142 * AES-CCM-64-64-128 1144 * AES-CCM-16-64-128 The difference between the two is only the 1145 length of the nonce, which is 7-bytes in the former case and 1146 13-bytes in the latter. In TLS/DTLS the nonce value is not 1147 negotiated but fixed instead. Figure 15 provides the mapping 1148 between the TLS defined ciphersuite and the COSE algorithms. 1150 o Master Salt: The master salt is derived as described above. 1152 o HKDF Algorithm: This value is negotiated using the ciphersuite 1153 exchange provided by the TLS/DTLS handshake. As a default, 1154 SHA-256 is assumed as a HKDF algorithm for algorithms using 1155 128-bit key sizes and SHA384 for 256-bit key sizes. 1157 o Replay Window: A default window size of 32 packets is assumed. 1159 9.2. COSE 1161 The key exporting procedure for COSE is similiar to the one defined 1162 for OSCORE. The label string for use with this specification is 1163 defined as 'atls-cose'. The per-association context value is empty. 1165 The length value is twice the size of the key size utilized by the 1166 negotiated algorithm since the lower-half is used for the Master 1167 Secret and the upper-half is used for the Master Salt. 1169 The COSE algorithm corresponds to the ciphersuite negotiated during 1170 the TLS/DTLS handshake with with the mapping provided in Figure 15. 1171 The HKDF algorithm is negotiated using the the TLS/DTLS handshake. 1172 As a default, SHA-256 is assumed as a HKDF algorithm for algorithms 1173 using 128-bit key sizes and SHA384 for 256-bit key sizes. 1175 COSE uses key ids to allow finding the appropriate security context. 1176 Those key IDs conceptually correspond to CIDs, as described in 1177 Section 11.2. 1179 10. TLS Ciphersuite to COSE/OSCORE Algorithm Mapping 1181 TLS Ciphersuite | COSE/OSCORE Algorithm 1182 ------------------+-------------------------------------------------- 1183 AES_128_CCM_8 | AES-CCM w/128-bit key, 64-bit tag, 13-byte nonce 1184 AES_256_CCM_8 | AES-CCM w/256-bit key, 64-bit tag, 13-byte nonce 1185 CHACHA20_POLY1305 | ChaCha20/Poly1305 w/256-bit key, 128-bit tag 1186 AES_128_CCM | AES-CCM w/128-bit key, 128-bit tag, 13-byte nonce 1187 AES_256_CCM | AES-CCM w/256-bit key, 128-bit tag, 13-byte nonce 1188 AES_128_GCM | AES-GCM w/128-bit key, 128-bit tag 1189 AES_256_GCM | AES-GCM w/256-bit key, 128-bit tag 1191 Figure 15: TLS Ciphersuite to COSE/OSCORE Algorithm Mapping 1193 11. TLS Extensions 1195 11.1. The "oscore_connection_id" Extension 1197 This document defines the "oscore_connection_id" extension, which is 1198 used in ClientHello and ServerHello messages. It is used only for 1199 establishing the OSCORE Sender ID and the OSCORE Recipient ID. The 1200 OSCORE Sender ID maps to the CID provided by the server in the 1201 ServerHello and the OSCORE Recipient ID maps to the CID provided by 1202 the client in the ClientHello. 1204 The negotiation mechanism follows the procedure used in 1205 [I-D.ietf-tls-dtls-connection-id] with the exception that the 1206 negotiated CIDs agreed with the "oscore_connection_id" extension is 1207 only used with OSCORE and does not impact the record layer format of 1208 the DTLS/TLS payloads nor the MAC calculation used by DTLS/TLS. As 1209 such, this extension can be used with DTLS as well as with TLS when 1210 those protocols are used at the application layer. 1212 The extension type is specified as follows. 1214 enum { 1215 oscore_connection_id(TBD), (65535) 1216 } ExtensionType; 1218 struct { 1219 opaque cid<0..2^8-1>; 1220 } ConnectionId; 1222 Figure 16: The 'oscore_connection_id' Extension 1224 Note: This extension allows a client and a server to determine 1225 whether an OSCORE security context should be established. 1227 11.2. The "cose_ext" Extension 1229 This document defines the "cose_ext" extension, which is used in 1230 ClientHello and ServerHello messages. It is used only for 1231 establishing the key identifiers, AEAD algorithms, as well as keying 1232 material for use with application layer protection using COSE. The 1233 CID provided by the server in the ServerHello maps to the COSE kid 1234 transmitted from the client to the server and the CID provided by the 1235 client in the ClientHello maps to the COSE kid transmitted from the 1236 server to the client. 1238 The negotiation mechanism follows the procedure used in 1239 [I-D.ietf-tls-dtls-connection-id] with the exception that the 1240 negotiated CIDs agreed with the "cose_ext" extension is only used 1241 with COSE and does not impact the record layer format of the DTLS/TLS 1242 payloads nor the MAC calculation used by DTLS/TLS. As such, this 1243 extension can be used with DTLS as well as with TLS when those 1244 protocols are used at the application layer. 1246 The extension type is specified as follows. 1248 enum { 1249 oscore_connection_id(TBD), (65535) 1250 } ExtensionType; 1252 struct { 1253 opaque cid<0..2^8-1>; 1254 } ConnectionId; 1256 Figure 17: The 'cose_ext' Extension 1258 Note: This extension allows a client and a server to determine 1259 whether an COSE security context should be established. 1261 12. IANA Considerations 1263 12.1. "oscore_connection_id" TLS extension 1265 IANA is requested to allocate two entries to the existing TLS 1266 "ExtensionType Values" registry, defined in [RFC5246], for 1267 oscore_connection_id(TBD1) and cose_ext(TBD2) defined in this 1268 document, as described in the table below. 1270 Value Extension Name TLS 1.3 DTLS Only Recommended Reference 1271 ----------------------------------------------------------------------- 1272 TBD1 oscore_connection_id Y N N [[This doc]] 1273 TBD2 cose_ext Y N N [[This doc]] 1275 Note: The "N" values in the Recommended column are set because these 1276 extensions are intended only for specific use cases. 1278 12.2. TLS Ciphersuite to OSCORE/COSE Algorithm Mapping 1280 IANA is requested to create a new registry for mapping TLS 1281 ciphersuites to SCORE/COSE algorithms 1283 An initial mapping can be found in Figure 15. 1285 Registration requests are evaluated after a three-week review period 1286 on the tls-reg-review@ietf.or mailing list, on the advice of one or 1287 more Designated Experts [RFC8126]. However, to allow for the 1288 allocation of values prior to publication, the Designated Experts may 1289 approve registration once they are satisfied that such a 1290 specification will be published. 1292 Registration requests sent to the mailing list for review should use 1293 an appropriate subject (e.g., "Request to register an TLS - OSCORE/ 1294 COSE algorithm mapping: example"). Registration requests that are 1295 undetermined for a period longer than 21 days can be brought to the 1296 IESG's attention (using the iesg@ietf.org mailing list) for 1297 resolution. 1299 Criteria that should be applied by the Designated Experts includes 1300 determining whether the proposed registration duplicates existing 1301 functionality, whether it is likely to be of general applicability or 1302 whether it is useful only for a single extension, and whether the 1303 registration description is clear. 1305 IANA must only accept registry updates from the Designated Experts 1306 and should direct all requests for registration to the review mailing 1307 list. 1309 12.3. .well-known URI Registry 1311 IANA is requested to add the well-known URI 'atls' to the Well-Known 1312 URIs registry. 1314 o URI suffix: atls 1316 o Change controller: IETF 1318 o Specification document(s): [[this document]] 1320 o Related information: None 1322 12.4. Media Types Registry 1324 IANA is requested to add the media type 'application/atls' to the 1325 Media Types registry. 1327 o Type name: application 1329 o Subtype name: atls 1331 o Required parameters: N/A 1333 o Optional parameters: N/A 1335 o Encoding considerations: binary 1336 o Security considerations: See Security Considerations section of 1337 this document. 1339 o Interoperability considerations: N/A 1341 o Published specification: [[this document]] (this document) 1343 o Applications that use this media type: Potentially any 1345 o Fragment identifier considerations: N/A 1347 o Additional information: 1349 * Magic number(s): N/A 1351 * File extension(s): N/A 1353 * Macintosh file type code(s): N/A 1355 o Person & email address to contact for further information: See 1356 "Authors' Addresses" section. 1358 o Intended usage: COMMON 1360 o Restrictions on usage: N/A 1362 o Author: See "Authors' Addresses" section. 1364 o Change Controller: IESG 1366 12.5. HTTP Content-Formats Registry 1368 IANA is requested to add the media type 'application/atls' to the 1369 HTTP Content-Formats registry. 1371 o Media Type: application/atls 1373 o Encoding: binary 1375 o ID: TBD 1377 o Reference: [[this document]] 1379 12.6. CoAP Content-Formats Registry 1381 IANA is requested to add the media type 'application/atls' to the 1382 CoAP Content-Formats registry. 1384 o Media Type: application/atls 1386 o Encoding: binary 1388 o ID: TBD 1390 o Reference: [[this document]] 1392 12.7. TLS Key Extractor Label 1394 IANA is requested to register the "application-layer-tls" label in 1395 the TLS Extractor Label Registry to correspond to this specification. 1397 13. Security Considerations 1399 This specification re-uses the TLS and DTLS and hence the security 1400 considerations of the respective TLS/DTLS version applies. As 1401 described in Section 5.2, implementers need to take the policy 1402 configuration into account when applying security protection at 1403 various layers of the stack even if the same protocol is used since 1404 the communiation endpoints and the security requirements are likely 1405 going to vary. 1407 For use in the IoT environment the considerations described in 1408 [RFC7925] apply and other environments the guidelines in [RFC7525] 1409 are applicable. 1411 14. References 1413 14.1. Normative References 1415 [I-D.ietf-core-object-security] 1416 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1417 "Object Security for Constrained RESTful Environments 1418 (OSCORE)", draft-ietf-core-object-security-16 (work in 1419 progress), March 2019. 1421 [I-D.ietf-tls-dtls13] 1422 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1423 Datagram Transport Layer Security (DTLS) Protocol Version 1424 1.3", draft-ietf-tls-dtls13-31 (work in progress), March 1425 2019. 1427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1428 Requirement Levels", BCP 14, RFC 2119, 1429 DOI 10.17487/RFC2119, March 1997, 1430 . 1432 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1433 (TLS) Protocol Version 1.2", RFC 5246, 1434 DOI 10.17487/RFC5246, August 2008, 1435 . 1437 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1438 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1439 March 2010, . 1441 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1442 DOI 10.17487/RFC6265, April 2011, 1443 . 1445 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1446 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1447 January 2012, . 1449 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1450 Protocol (HTTP/1.1): Message Syntax and Routing", 1451 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1452 . 1454 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1455 Application Protocol (CoAP)", RFC 7252, 1456 DOI 10.17487/RFC7252, June 2014, 1457 . 1459 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1460 "Recommendations for Secure Use of Transport Layer 1461 Security (TLS) and Datagram Transport Layer Security 1462 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1463 2015, . 1465 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1466 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1467 DOI 10.17487/RFC7540, May 2015, 1468 . 1470 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1471 Security (TLS) / Datagram Transport Layer Security (DTLS) 1472 Profiles for the Internet of Things", RFC 7925, 1473 DOI 10.17487/RFC7925, July 2016, 1474 . 1476 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1477 Writing an IANA Considerations Section in RFCs", BCP 26, 1478 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1479 . 1481 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1482 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1483 May 2017, . 1485 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1486 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1487 . 1489 14.2. Informative References 1491 [ALTS] Google, "Application Layer Transport Security", December 1492 2017, . 1495 [Bluetooth] 1496 Bluetooth, "Bluetooth Core Specification v5.0", 2016, 1497 . 1499 [I-D.ietf-anima-bootstrapping-keyinfra] 1500 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1501 S., and K. Watsen, "Bootstrapping Remote Secure Key 1502 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1503 keyinfra-22 (work in progress), June 2019. 1505 [I-D.ietf-httpbis-bcp56bis] 1506 Nottingham, M., "Building Protocols with HTTP", draft- 1507 ietf-httpbis-bcp56bis-08 (work in progress), November 1508 2018. 1510 [I-D.ietf-tls-dtls-connection-id] 1511 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 1512 Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- 1513 id-05 (work in progress), May 2019. 1515 [I-D.mattsson-lwig-security-protocol-comparison] 1516 Mattsson, J. and F. Palombini, "Comparison of CoAP 1517 Security Protocols", draft-mattsson-lwig-security- 1518 protocol-comparison-01 (work in progress), March 2018. 1520 [I-D.rescorla-tls-ctls] 1521 Rescorla, E., "Compact TLS 1.3", draft-rescorla-tls- 1522 ctls-01 (work in progress), March 2019. 1524 [I-D.selander-ace-cose-ecdhe] 1525 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 1526 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 1527 cose-ecdhe-13 (work in progress), March 2019. 1529 [LwM2M] Open Mobile Alliance, "Lightweight Machine to Machine 1530 Requirements", December 2017, 1531 . 1533 [Noise] Perrin, T., "Noise Protocol Framework", October 2017, 1534 . 1536 [Norrell] Norrell, ., "Use SSL/TLS within a different protocol with 1537 BIO pairs", 2016, 1538 . 1541 [Signal] Open Whisper Systems, "Signal Protocol", 2016, 1542 . 1544 [SSLEngine] 1545 Oracle, "SSLEngineSimpleDemo.java", 2004, . 1549 [ZigBee] ZigBee Alliance, "ZigBee Specification", 2012, 1550 . 1552 Appendix A. Pseudo Code 1554 This appendix gives both C and Java pseudo code illustrating how to 1555 inject and extract raw TLS records from a TLS software stack. Please 1556 not that this is illustrative, non-functional pseudo code that does 1557 not compile. Functioning proof-of-concept code is available on the 1558 following public repository [[ EDITOR'S NOTE: Add the URL here ]]. 1560 A.1. OpenSSL 1562 OpenSSL provides a set of Basic Input/Output (BIO) APIs that can be 1563 used to build a custom transport layer for TLS connections. This 1564 appendix gives pseudo code on how BIO APIs could be used to build a 1565 client application that completes a TLS handshake and exchanges 1566 application data with a service. 1568 char inbound[MAX]; 1569 char outbound[MAX]; 1570 int rx_bytes; 1571 SSL_CTX *ctx = SSL_CTX_new(); 1572 SSL *ssl = SSL_new(ctx); 1574 // Create in-memory BIOs and plug in to the SSL session 1575 BOI* bio_in = BIO_new(BIO_s_mem()); 1576 BOI* bio_out = BIO_new(BIO_s_mem()); 1577 SSL_set_bio(ssl, bio_in, bio_out); 1579 // We are a client 1580 SSL_set_connect_state(ssl); 1582 // Loop through TLS flights until we are done 1583 do { 1584 // Calling SSL_do_handshake() will result in a full 1585 // TLS flight being written to the BIO buffer 1586 SSL_do_handshake(ssl); 1588 // Read the client flight that the TLS session 1589 // has written to memory 1590 BIO_read(bio_out, outbound, MAX); 1592 // POST the outbound bytes to the server using a suitable 1593 // function. Lets assume that the server response will be 1594 // written to the 'inbound' buffer 1595 num_bytes = postTlsRecords(outbound, inbound); 1597 // Write the server flight to the memory BIO so the TLS session 1598 // can read it. The next call to SSL_do_handshake() will handle 1599 // this received server flight 1600 BIO_write(bio_in, inbound, num_bytes); 1602 } while (!SSL_is_init_finished(ssl)); 1604 // Send a message to the server. Calling SSL_write() will run the 1605 // plaintext through the TLS session and write the encrypted TLS 1606 // records to the BIO buffer 1607 SSL_write(ssl, "Hello World", strlen("Hello World")); 1609 // Read the TLS records from the BIO buffer and 1610 // POST them to the server 1611 BIO_read(bio_out, outbound, MAX); 1612 num_bytes = postTlsRecords(outbound, inbound); 1614 A.2. Java JSSE 1616 The Java SSLEngine class "enables secure communications using 1617 protocols such as the Secure Sockets Layer (SSL) or IETF RFC 2246 1618 "Transport Layer Security" (TLS) protocols, but is transport 1619 independent". This pseudo code illustrates how a server could use 1620 the SSLEngine class to handle an inbound client TLS flight and 1621 generate an outbound server TLS flight response. 1623 SSLEngine sslEngine = SSLContext.getDefault().createSSLEngine(); 1624 sslEngine.setUseClientMode(false); 1625 sslEngine.beginHandshake(); 1627 // Lets assume 'inbound' has been populated with 1628 // the Client 1st Flight 1629 ByteBuffer inbound; 1631 // 'outbound' will be populated with the 1632 // Server 1st Flight response 1633 ByteBuffer outbound; 1635 // SSLEngine handles one TLS Record per call to unwrap(). 1636 // Loop until the engine is finished unwrapping. 1637 while (sslEngine.getHandshakeStatus() == 1638 HandshakeStatus.NEED_UNWRAP) { 1639 SSLEngineResult res = sslEngine.unwrap(inbound, outbound); 1641 // SSLEngine may need additional tasks run 1642 if (res.getHandshakeStatus() == NEED_TASK) { 1643 Runnable run = sslEngine.getDelegatedTask(); 1644 run.run(); 1645 } 1646 } 1648 // The SSLEngine has now finished handling all inbound TLS Records. 1649 // Check if it wants to generate outbound TLS Records. SSLEngine 1650 // generates one TLS Record per call to wrap(). 1651 // Loop until the engine is finished wrapping. 1652 while (sslEngine.getHandshakeStatus() == 1653 HandshakeStatus.NEED_WRAP) { 1654 SSLEngineResult res = sslEngine.wrap(inbound, outbound); 1656 // SSLEngine may need additional tasks run 1657 if (res.getHandshakeStatus() == NEED_TASK) { 1658 Runnable run = sslEngine.getDelegatedTask(); 1659 run.run(); 1660 } 1661 } 1663 // outbound ByteBuffer now contains a complete server flight 1664 // containing multiple TLS Records 1665 // Rinse and repeat! 1667 Appendix B. Example ATLS Handshake 1669 [[ EDITOR'S NOTE: For completeness, include a simple full TLS 1670 handshake showing the raw binary flights, along with the HTTP 1671 request/response/headers. And also the raw hex TLS records showing 1672 protocol bits ]] 1674 Appendix C. Alternative Approaches to Application Layer End-to-End 1675 Security 1677 End-to-end security at the application layer is increasing seen as a 1678 key requirement across multiple applications and services. Some 1679 examples of end-to-end security mechanisms are outlined here. All 1680 the solutions outlined here have some common characteristics. The 1681 solutions: 1683 o do not rely on transport layer security 1685 o define a new handshake protocol for establishment of a secure end- 1686 to-end session 1688 C.1. Noise 1690 [Noise] is a framework for cryptographic protocols based on Elliptic 1691 Curve Diffie-Hellman (ECDH) key agreement, AEAD encryption, and 1692 BLAKE2 and SHA2 hash functions. Noise is currently used by WhatsApp, 1693 WireGuard, and Lightning. 1695 The current Noise protocol framework defines mechanisms for proving 1696 possession of a private key, but does not define authentication 1697 mechanisms. Section 14 "Security Considerations" of Noise states: 1698 ~~~ it's up to the application to determine whether the remote 1699 party's static public key is acceptable ~~~ 1701 C.2. Signal 1703 The [Signal] protocol provides end-to-end encryption and uses EdDSA 1704 signatures, Triple Diffie-Hellman handshake for shared secret 1705 establishment, and the Double Ratchet Algorithm for key management. 1706 It is used by Open Whisper Systems, WhatsApp and Google. 1708 Similar to Noise, Signal does not define an authentication mechanism. 1709 The current [X3DH] specification states in Section 4.1 1710 "Authentication": 1712 Methods for doing this are outside the scope of this document 1714 C.3. Google ALTS 1716 Google's Application Layer Transport Security [ALTS] is a mutual 1717 authentication and transport encryption system used for securing 1718 Remote Procedure Call (RPC) communications within Google's 1719 infrastructure. ALTS uses an ECDH handshake protocol and a record 1720 protocol containing AES encrypted payloads. 1722 C.4. Ephemeral Diffie-Hellman Over COSE (EDHOC) 1724 There is ongoing work to standardise EDHOC 1725 [I-D.selander-ace-cose-ecdhe], which defines a SIGMA-I based 1726 authenticated key exchange protocol using COSE and CBOR. 1728 Authors' Addresses 1730 Owen Friel 1731 Cisco 1733 Email: ofriel@cisco.com 1735 Richard Barnes 1736 Cisco 1738 Email: rlb@ipv.sx 1740 Max Pritikin 1741 Cisco 1743 Email: pritikin@cisco.com 1745 Hannes Tschofenig 1746 Arm Ltd. 1748 Email: hannes.tschofenig@gmx.net 1750 Mark Baugher 1751 Consultant 1753 Email: mark@mbaugher.com