idnits 2.17.1 draft-tschofenig-layered-tls-00.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 30, 2017) is 2370 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 519 -- Looks like a reference, but probably isn't: '2' on line 522 -- Looks like a reference, but probably isn't: '3' on line 525 -- Looks like a reference, but probably isn't: '4' on line 566 -- Looks like a reference, but probably isn't: '5' on line 626 -- Looks like a reference, but probably isn't: '6' on line 637 == Missing Reference: 'Norrell' is mentioned on line 563, but not defined == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-02 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-06 -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft ARM Limited 4 Intended status: Experimental M. Baugher 5 Expires: May 3, 2018 Consultant 6 October 30, 2017 8 Layered DTLS/TLS 9 draft-tschofenig-layered-tls-00 11 Abstract 13 TLS and increasingly also DTLS are frequently used to provide channel 14 security for Internet of Things (IoT) communication. On the Web and 15 smart phones, TLS is already the defacto approach for securing 16 protocol interactions. While the end-to-end security offered by TLS, 17 particularly TLS 1.3, is already too much for some, there are others 18 who believe that TLS is insufficient. While the former group is 19 working on ways to weaken TLS security, the latter group is 20 interested in designing an application layer security solution. 21 Whether application-layer security is used in addition to or as a 22 substitute for transport-layer security is of secondary importance. 23 However, the security needs for such an application layer solution 24 are similar, if not identical, to those that drove the design of TLS. 25 This is for an obvious reason: Security requirements are not tied to 26 the name of a security protocol nor to the layer at which it is 27 executed. One can make this observation also in other areas, such as 28 with the increasing similarity of Internet Key Exchange (IKE) and the 29 TLS handshake protocols. 31 These discussions within the IETF inspired the document authors to 32 explore whether TLS could actually be used also at the application 33 layer and how complex it would be. We call this approach "Layered 34 TLS" since TLS may, in some scenarios, be executed at two layers: 35 above the transport layer in the traditional manner and also at the 36 application layer. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on May 3, 2018. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) controlling 76 the copyright in such materials, this document may not be modified 77 outside the IETF Standards Process, and derivative works of it may 78 not be created outside the IETF Standards Process, except to format 79 it for publication as an RFC or to translate it into languages other 80 than English. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 85 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 3. Layered DTLS Use Cases . . . . . . . . . . . . . . . . . . . 5 87 3.1. Application-Layer DTLS in the end device . . . . . . . . 5 88 3.2. Transport-layer DTLS to the end device . . . . . . . . . 5 89 4. Design Rational . . . . . . . . . . . . . . . . . . . . . . . 6 90 5. Layered TLS Design . . . . . . . . . . . . . . . . . . . . . 7 91 5.1. Relocatable layers . . . . . . . . . . . . . . . . . . . 7 92 5.2. Application-specific layer headers . . . . . . . . . . . 8 93 6. Functional Design . . . . . . . . . . . . . . . . . . . . . . 9 94 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 98 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 99 10.2. Informative References . . . . . . . . . . . . . . . . . 11 100 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 101 Appendix A. Implementation . . . . . . . . . . . . . . . . . . . 13 102 A.1. OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . 13 103 A.2. mbedTLS . . . . . . . . . . . . . . . . . . . . . . . . . 15 104 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 15 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 107 1. Introduction 109 "Layered TLS" addresses two problems with TLS connections to middle 110 boxes: End points cannot authenticate each other, and each 111 intermediary gains more access to decrypted messages than it needs. 112 The lack of end-to-end authentication puts a service at risk of 113 message-forgery attacks. Services lacking end-to-end encryption, 114 moreover, leak information and violate the principle of "least 115 privilege." End-systems that use TLS or DTLS may benefit from 116 applying TLS to secure application messages, end-to-end, and reusing 117 TLS infrastructure and open-source software. This short report 118 solicits ideas and opinions from the Internet standards community on 119 using TLS at the application layer for message security, end-to-end. 121 In this document, "message security" means sender authentication, 122 message-integrity protection, and confidentiality of at least parts 123 of the message. "End-to-end authentication" means that a network 124 receiver can determine the sender of a message - and vice versa. And 125 "end-to-end confidentiality" means that the receiver and only the 126 receiver can read the sender's message. The need for these security 127 services on the Internet is well established and defined [RFC4949]. 128 Nonetheless, most Internet services today lack end-to-end security, 129 which is the subject of this work. 131 Internet mail endpoints, for example, are periodically offline and 132 need always-on SNMP servers to store mail. StartTLS is a standard 133 that authenticates mail servers and encrypts messages on the network, 134 but transport-layer security cannot cryptographically authenticate 135 mail endpoints or encrypt messages between them. That requires PGP, 136 S/MIME or some other method of message authentication and encryption. 137 The absence of this layer of email security has caused enormous 138 problems for people, organizations and nations worldwide, but 139 insecure practices persist. 141 The same had been generally true for chat and VoIP services prior to 142 the introduction of application layer security protocols: XMPP 143 deployments, for example, have generally failed to protect message 144 contents using S/MIME, as specified by XMPP standards. Instead, 145 early deployments used only transport security between chat servers, 146 similar to StartTLS between SNMP servers. Chat, however, has evolved 147 a succession of application-layer security protocols such as Off-the- 148 Record and the "double-ratchet" key-management schemes found in 149 Signal/Noise and its predecessors. VoIP endpoints have initially 150 passed keys in a hop-by-hop fashion between SIP proxies (with SIP 151 proxies seeing the keys in plaintext) before a range of other end-to- 152 end security solutions were developed, including DTLS-SRTP. The 153 emergence of end-to-end security for VoIP and chat is a bright spot 154 for improving privacy and security through middle boxes. 156 Internet of Things (IoT) communications have a similar problem: IoT 157 services commonly use middle boxes for connecting different IoT 158 islands. Unlike most chat deployments, however, IoT devices have 159 additional constraints: they are typically limited in memory, 160 storage, processing power and network capacity. This complicates the 161 problem of securing these applications and raises the specter of many 162 more new and untested security protocols, including problematic key 163 management, seeZillner [1] and authorization systems, see SmartThings 164 [2]. 166 It is unlikely that a single security protocol can satisfy all IoT 167 applications since some of them will require one-shot messages, like 168 firmware updates. But CoAP, MQTT, HTTP and other standards 169 increasingly use DTLS or TLS for communications security in at least 170 some constrained environments. Ideally, deployments should avoid the 171 use of middle boxes to simplify the overall architecture. However, 172 for those cases where this is not feasible this work seeks to 173 authenticate and encrypt through middle boxes by reusing TLS 174 [I-D.ietf-tls-tls13], [I-D.ietf-tls-dtls13] infrastructure and open- 175 source software implementations. 177 This is a work in progress to develop an architecture, design and 178 implementations for layered TLS services in both the end system and 179 middle box. Some problems and evaluation metrics are also considered 180 in the summary. 182 2. Terminology 184 "Layered TLS" can refer to a TLS or DTLS association between 185 endpoints. Also, as used in this document, "middle box" is 186 synonomous with application-layer gateway, hub, semantic gateway, 187 gateway or proxy. 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119 [RFC2119]. 193 3. Layered DTLS Use Cases 195 Two use cases are considered. Both of these examples use DTLS. 197 3.1. Application-Layer DTLS in the end device 199 It is well understood that a TLS or DTLS function is relocatable from 200 an end system to a middle box, and this is true of layered TLS: The 201 end-device might use application or transport security or both. This 202 is necessary given the diversity of today's IoT products. For 203 example, One product runs TLS from a gateway to a user device, which 204 it also connects to a ZigBee device, see Traedfri [3]. The gateway 205 in Figure 1 is a "semantic gateway" that converts one set of 206 operations to another. 208 +----------------------------------------------+ 209 |+------+ | 210 ||DEVICE|<-+ | 211 |+------+ | +---+| 212 | | | M || 213 |+------+ | +-------+ | O || 214 || ... |<-+--ZIGBEE-->|GATEWAY|<- COAP ->| B || 215 |+------+ | +-------+ | I || 216 | | | L || 217 |+------+ | | E || 218 ||DEVICE|<-+ +---+| 219 |+------+ | 220 +----------------------------------------------+ 222 Figure 1: A middle-box semantic gateway 224 In Figure 1, DTLS secures CoAP messages en route. An additional DTLS 225 layer would improve end-to-end security for data that are sent over 226 the ZigBee network but intended only for the mobile endpoint and not 227 needed by the GATEWAY function. 229 3.2. Transport-layer DTLS to the end device 231 In another topology, CoAP is run between a constrained end-device and 232 a cloud server, aggregator, or some type of proxy. In this case, 233 some non-constrained protocol rather than CoAP may run on the other 234 side of the middle box. But either way, all device data are 235 accessible to the proxy en route to their legitimate destination, 236 such as the mobile device shown below. 238 +-----------------------------------------------------------+ 239 |+------+ | 240 ||DEVICE|<-+ | 241 |+------+ | | 242 | | | 243 |+------+ | +-------+ HTTP +--------------+ | 244 || ... |<-+---COAP--->| CLOUD |<--MQTT--> | APPLICATION | | 245 |+------+ | |SERVER | AMQP | SERVER | | 246 | | +-------+ XMPP +--------------+ | 247 |+------+ | | 248 ||DEVICE|<-+ | 249 |+------+ | 250 +-----------------------------------------------------------+ 252 Figure 2: DTLS to the IoT Endpoint 254 Figure 2 illustrates the problem of relying on hop-by-hop transport 255 security: The end systems have no assurance that all hops run it. 256 Thus, in addition to method exposure inside middle boxes, end systems 257 have no assurance of authentication and confidentiality end-to-end. 258 A partial remedy to this problem is to secure messages between the 259 DEVICE and the APPLICATION SERVER. This is done independently of the 260 Figure 2 CLOUD SERVER. This is the goal of layered TLS. 262 4. Design Rational 264 At a first glance, the use of TLS may appear as an overkill since 265 application layer security often gives the perception of being 266 lightweight. However, we argue that the same security services are 267 needed. 269 When protecting data sent by a device, one obviously might want to 270 offer integrity and confidentiality protection. Additionally, it is 271 important for the recipient to verify that the data was sent by a 272 specific party, a property provided by data origin authentication. 273 Today, ciphers offering authenticated encryption with additional data 274 (AEAD) are the preferred approach. 276 So far, a simple JOSE or COSE object provides us such security 277 services. When we design such a system we might want to start with 278 public key cryptography to simplify key management. However, public 279 key cryptography has the unfortunate side-effect of being 280 heavyweight, particularly on a 281 per-message basis. Additionally, there is the risk of denial of 282 service attacks when an entity needs to make heavy computations based 283 on a single message only. 285 The classical design to amortize the cost of public key cryptography 286 is to use two phases: In the first phase, we use public key 287 cryptography for entity authentication. We then exchange symmetric 288 keys for use in the second phase where data is protected. The idea 289 is that the first phase happens less frequently than the second where 290 application data protection takes place. Ideally, we want to avoid 291 the first phase as much as possible, which is why we want to cache 292 symmetric keys for fast re-authentication (or resumption). 294 Best current practice in cryptography today suggests to also 295 incorporate perfect-forward secrecy in the derivation of symmetric 296 key utilizing a Diffie-Hellman approach. Additionally, it has long 297 been a requirement to take crypto-agility into account, since 298 cryptographic algorithms age and different communities tend to have 299 different preferences for algorithms. 300 Finally, a modern protocol design also needs to consider extensions 301 to the main protocol via a negotiation mechanism. 303 Voila! We have just re-designed TLS (minus all the security 304 analysis). Many of the needed security features in today's security 305 protocols are not bound to the name of the protocol but are rather a 306 side-effect of the security and privacy services needed for modern 307 applications and the best current cryptography design practices. 309 Every time you hear "TLS is complex" or "TLS is so heavyweight" ask 310 yourself whether this "complexity" or "weight" is the result of TLS/ 311 DTLS or rather the result of security services that a specific 312 application needs. 314 5. Layered TLS Design 316 In a communications protocol, a "layer" is often associated with a 317 communications-protocol header, which conveys addressing or other 318 "metadata." Message metadata are considered in one subsection below. 320 The next subsection considers where headers and TLS layer services 321 are applied along the service path. Figure 2 shows a case where a 322 transport-layer DTLS connection originates at the constrained device. 323 Figure 1 shows a case where the constrained device has its own link- 324 layer security and the GATEWAY acts as the terminus of a DTLS 325 connection. In either case, an application-DTLS layer might be 326 located at the constrained device or at the middle box. 328 5.1. Relocatable layers 330 An application developer has to decide whether to use TLS or DTLS at 331 the application layer, and this decision depends on the properties 332 offered by the lower layers, end-to-end. If the lower layer has a 333 reliable transport service (usually TCP), then TLS is RECOMMENDED. 334 But if the lower layer has an unreliable service like UDP or connects 335 to a middle box, then DTLS is RECOMMENDED. DTLS operates on top of 336 unreliable transports while TLS assumes reliable transports. 338 By design, TLS layers are independent, but code and data can be 339 shared when two layers share a physical device. More commonly today, 340 the layers can originate either at a communications endpoint or at 341 some middle box in the service path. 343 5.2. Application-specific layer headers 345 By design, application-layer TLS secures services through middle 346 boxes. An upper TLS or DTLS layer restricts access to message data 347 inside the middle box. Nonetheless, middle boxes often need some 348 information from and about the message for message processing. This 349 information is referred to as "metadata," or information about the 350 message that may be conveyed in a header, separate from the content 351 of the message and usually unencrypted. 352 [I-D.ietf-core-object-security] does not require that header metadata 353 be moved to an external header, however, in order to reduce overhead 354 in a constrained device. 356 Application-layer encodings, such as CBOR/COSE or JSON/JOSE define 357 message metadata that need to be shared with middle boxes in two 358 varieties, protected or unprotected, i.e. integrity-protected or re- 359 writable [RFC8152]. The reader should note that the use of the term 360 "layer" in this document is different from the COSE standard in that 361 a TLS layer is a TLS or DTLS connection at or above the transport 362 layer, i.e. source and destination addresses define the layer. 364 The identification and encoding of message parameters into protected 365 or unprotected headers is very much a function of the particular 366 application service, its content and its use of middle boxes. For 367 example, OSCORE maps message fields into protected, protected and 368 encrypted, or unprotected fields. These fields are from the COSE- 369 encoded object parameters that are needed by CoAP proxies or other 370 types of middle boxes [I-D.ietf-core-object-security]. 372 As important as metadata construction might be, the first solution 373 pursued in this work is to scale down to a very simple design that 374 might prove useful, i.e. improve security. For example, two 375 applications listening on remote ports might not need application-to- 376 application address metadata or other types of service-routing 377 parameters. In this case, there is no need for a header. But in 378 many practical cases do require a header, such as routing through an 379 application overlay, and RESTful endpoints. These cases will be 380 considered more closely in future implementation work. 382 6. Functional Design 384 The functional design assumes that an authorization system has 385 established operational keys for authenticating endpoints. In a 386 layered design, this needs to be done for each layer, which may 387 operate in two separate authorization domains. 389 +-------------------------------------------------------+ 390 | +---+ +---+ | 391 | +--------+ |APP| |APP| +--------+ | 392 | |security| +---+ +---+ |security| | 393 | |--------+ ^ ^ |--------+ | 394 | |policies| | | |policies| | 395 | |LAYER 0 | | | |LAYER 0 | | 396 | +--------+ v v +--------+ | 397 | + +------+ APP +------+ + | 398 | | | TLS- |<--------->| TLS- | | | 399 | +----->|SERVER| LAYER |CLIENT|<-----+ | 400 | +------+ +------+ | 401 | TOP LAYER ^ ^ | 402 +-----------------|-------------------|-----------------+ 403 | BOTTTOM LAYER | | | 404 | v v | 405 | +------+ TRANSPORT +------+ | 406 | | TLS- |<--------->| TLS- | | 407 | +--------+ |SERVER| LAYER |CLIENT| +--------+ | 408 | |security| +------+ +------+ |security| | 409 | |--------+ ^ ^ |--------+ | 410 | |policies| | | |policies| | 411 | |LAYER 1 +-----+ +-----+LAYER 1 | | 412 | +--------+ +--------+ | 413 | | 414 +-------------------------------------------------------+ 416 Figure 3 418 Thus, the security policies of one layer are distinct from those of 419 another in Figure 3. They may overlap, but that's not necessary or 420 perhaps even likely since one layer operates end-to-end, the other 421 hop-by-hop, and the two often have different authorization domains, 423 TLS can protect IoT device-to-hub communications "on the wire" using 424 the "bottom layer" of Figure 3, and it can protect application data 425 inside the hub/application-gateway using the "top layer." This is 426 needed. Application and transport security each have a role to play. 427 Transport security restricts access to messages on the networks, 428 notably application TLS headers,if any, and application-layer TLS 429 restricts access to messages inside middle boxes. 431 Thus, Figure 3 accepts an application-layer message, which gets 432 encrypted and integrity protected with optional headers that MAY be 433 integrity protected or not. In the most general case of Figure 3, 434 the resulting TLS message and headers are passed to a TLS socket, 435 which may have a different security policy than the application layer 436 client_hello that the app sends in response to the first message. 437 This application message triggers the transport layer to send its own 438 client_hello to the TLS server or endpoint, which is often a middle 439 box. 441 7. Summary 443 The use of TLS/DTLS for protection of payloads at the application 444 layer does not require much or any standardization. However, 445 conceptually it is a big step. With the capabilities offered by TLS/ 446 DTLS a wide range of security services are available to the 447 application developer. 449 Future work will compare the protocol, message, and platform resource 450 demands of layered TLS with given sets of policies and workloads. 451 The layered TLS design presented here is applicable to TLS 1.3 and 452 earlier versions. But TLS 1.3 is chosen for the Layered TLS 453 prototype, however, to make use of zero-RTT and other new features, 454 as well as ongoing improvements anticipated in future revisions of 455 TLS and DTLS 1.3 specifications 456 [I-D.ietf-tls-tls13][I-D.ietf-tls-dtls13]. 458 The authors are still undecided whether Layered TLS should establish 459 keys for use with the TLS/DTLS record layer only or should establish 460 keys for use with COSE/OSCoAP as well. 462 8. Security Considerations 464 Layered TLS is intended to improve security for an Internet service 465 by offering application layer security. 467 In general, adding more security code increases complexity and can 468 thereby make the service less secure. However, in this case the 469 solution re-uses already existing code and utilizes it twice, at 470 different layers. 472 In any case, it is RECOMMENDED that the layers be isolated and the 473 line between the layers in Figure 4 effectively firewalls one layer 474 off from another using platform features that will foil cross-layer 475 attacks in platforms with two layers. 477 9. IANA Considerations 479 There are no IANA Considerations in this draft. 481 10. References 483 10.1. Normative References 485 [I-D.ietf-tls-dtls13] 486 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 487 Datagram Transport Layer Security (DTLS) Protocol Version 488 1.3", draft-ietf-tls-dtls13-02 (work in progress), October 489 2017. 491 [I-D.ietf-tls-tls13] 492 Rescorla, E., "The Transport Layer Security (TLS) Protocol 493 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 494 July 2017. 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, 498 DOI 10.17487/RFC2119, March 1997, . 501 10.2. Informative References 503 [I-D.ietf-core-object-security] 504 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 505 "Object Security for Constrained RESTful Environments 506 (OSCORE)", draft-ietf-core-object-security-06 (work in 507 progress), October 2017. 509 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 510 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 511 . 513 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 514 RFC 8152, DOI 10.17487/RFC8152, July 2017, 515 . 517 10.3. URIs 519 [1] https://www.blackhat.com/docs/us-15/materials/us-15-Zillner- 520 ZigBee-Exploited-The-Good-The-Bad-And-The-Ugly-wp.pdf 522 [2] https://web.eecs.umich.edu/~earlence/assets/papers/ 523 smartthings_sp16.pdf 525 [3] http://www.sensorsiot.org/145-ikea-tradfri-hack-with-gateway/ 527 [4] https://thekerneldiaries.com/2016/06/13/openssl-ssltls-within-a- 528 different-protocol/ 530 [5] https://wiki.openssl.org/index.php/ 531 EVP_Authenticated_Encryption_and_Decryption 533 [6] https://tls.mbed.org/kb/how-to/mbedtls-tutorial 535 Appendix A. Implementation 537 An implementation with two TLS layers has two TLS or DTLS state 538 machines, two sets of policies, and key store. A device that 539 physically hosts two TLS layers results in roughly twice as much 540 state and twice as much header overhead, than a single layer. This 541 is not unusual. 543 Implementation work is ongoing on both OpenSSL and mbedTLS libraries. 545 +--------------------------+--------------------------+ 546 | +---+ L | L | 547 | |APP| A | A | 548 | +---+ Y | Y | 549 | ^ E | E | 550 | | R | R | 551 |+--------+ v | +--------+| 552 ||security| +------+ | +------+ |security|| 553 ||--------+ |DTLS- | | |DTLS- | |--------+| 554 ||policies|--->|SERVER|<---|--->|SERVER|<---|policies|| 555 || | +------+ | +------+ | || 556 |+--------+ | +--------+| 557 +--------------------------+--------------------------+ 559 Figure 4: Prototype Functional Block Diagram 561 A.1. OpenSSL 563 There is documentation online [Norrell] that describes a way to use 564 the OpenSSL library to create a protocol-independent TLS 565 encapsulation of application-level messages including Handshake 566 messages, see Norrel [4]. Normally, the easiest OpenSSL API calls 567 for a TLS session are SSL_write and SSL_read, shown in the next 568 figure from Norrel. 570 APPLICATION OPENSSL 571 +----------------------+---------------+ 572 | +-----------+ | +---+| 573 | |to_send_buf|--------|--------->| S || 574 | +-----------+ | | O || 575 | | | C || 576 | | | K || 577 |+------------+ | | E || 578 ||received_buf|<-------|<---------| T || 579 |+------------+ | +---+| 580 +----------------------+---------------+ 582 Figure 5: OpenSSL calls send and receive user messages as TLS 583 messages over a socket 585 As shown above, OpenSSL writes a user buffer to a TLS message and 586 sends the message out a communications socket. The converse is done 587 on the receiving side. What's needed to create a layer independent 588 of the host IP stack is to send the TLS message to a buffer rather 589 than to a communications socket and do the reverse on the receiving 590 side. This is shown in Figure 6, which is also from Norrell.. 592 +--------------------+------------+----------------------+ 593 |+---------+ +-+ +----+ +---------+| 594 || buf1 |------->| |------->|RBIO|+------->| buf2 || 595 ||plaintext| |S| +----+ |encrypted|| 596 |+---------+ |S| OPENSSL | +---------+| 597 |+---------+ |L| | +---------+| 598 || buf4 | | | +----+ | buf3 || 599 ||plaintext|<-------| |<-------|WBIO|<--------|encrypted|| 600 |+---------+ +-+ +----+ +---------+| 601 +--------------------+------------+----------------------+ 602 APPLICATION OPENSSL APPLICATION 603 Plaintext side Encrypted side 605 Figure 6: BIO interface provides raw TLS message 607 In #SSLBIO, the SSL_write and SSL_read calls use an OpenSSL context 608 that is bound to a buffer rather than a socket. To retrieve a TLS 609 message for OpenSSL, the application does a BIO_read of the RBIO 610 buffer on the sender side and the converse on the receiver side. 612 In between the send and receive operations, message headers are 613 optionally created and added or parsed and removed. The authors of 614 [I-D.ietf-core-object-security] argue that there is a general need 615 for both unprotected headers and protected headers with a message 616 integrity check. OSCORE describes how to map COSE parameters to a 617 message header. OSCORE uses the AEAD transform to take protected- 618 header data as additional data without replicating the parameters 619 inside the message. The message authentication code is created (on 620 send) and checked (on receipt) in the OpenSSL layer of Figure 6. 621 Prior to calling SSL_write, therefore, the application ("APPLICATION" 622 in #SSLBIO) will add any needed protected and unprotected headers. 623 If a protected header is to be included, the protected-header 624 parameters will be passed as additional data to an AEAD interface, 625 such as a manual encryption using EVP prior to SSL_Write and 626 following SSL_read, see OpenSSL [5]. As mentioned above, protocol- 627 dependent signaling is often needed for those application protocols 628 that support application middle boxes to ensure that Handshake 629 protocol messages are not cached en route. These are added as new 630 parameters in the protected or unprotected headers. 632 A.2. mbedTLS 634 Most of our work is focused on adding layer functionality to a TLS 635 1.3 prototype based on mbedTLS. Like OpenSSL, mbedtls has a 636 straightforward method to receive and send DTLS or TLS-encapsulated 637 data. This uses mbedtls_ssl_set_bio, see mbedtls [6]. 639 Beyond how to use the mbedTLS application API, however, are deeper 640 questions about efficiency, layer isolation, constrained and scalable 641 multi-processor platforms, and platform resource sharing between 642 layers. Our current work extends existing mbedtls example 643 application code to prototype a single layer and multi-layer 644 application program. Early code has been contributed to the mbedtls 645 github repository. 647 Appendix B. Contributors 649 The authors wish to thank our friends in the IPSO Alliance for their 650 ideas and criticisms, particularly Per Staehl, Ned Smith, and Alan 651 Grau. 653 Authors' Addresses 655 Hannes Tschofenig 656 ARM Limited 658 EMail: hannes.tschofenig@gmx.net 660 Mark Baugher 661 Consultant 663 EMail: mark@mbaugher.com