Network Working Group J. Mattsson Internet-Draft Ericsson AB Intended status: Standards Track October 30, 2017 Expires: May 3, 2018 Using Transport Layer Security (TLS) to Secure OSCORE draft-mattsson-ace-tls-oscore-00 Abstract This document describes how Transport Layer Security (TLS) is used to secure OSCORE. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 3, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Mattsson Expires May 3, 2018 [Page 1] Internet-Draft TLS-OSCORE October 2017 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 3.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 3 3.2. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 4 4. OSCORE Security Context . . . . . . . . . . . . . . . . . . . 5 4.1. Key Derivation Function . . . . . . . . . . . . . . . . . 5 4.2. AEAD Algorithm . . . . . . . . . . . . . . . . . . . . . 5 4.3. Master Secret and Master Salt . . . . . . . . . . . . . . 5 4.4. Sender ID and Recipient ID . . . . . . . . . . . . . . . 6 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This document describes how OSCORE [I-D.ietf-core-object-security] is secured using Transport Layer Security (TLS) version 1.3 [I-D.ietf-tls-tls13]. TLS 1.3 provides critical latency improvements for connection establishment over previous versions. Absent packet loss, most new connections can be established and secured within a single round trip; on subsequent connections between the same client and server, the client can often send application data immediately, that is, using a zero round trip setup. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document uses the terminology established in CoAP [RFC7252], OSCORE [I-D.ietf-core-object-security], and TLS 1.3 [I-D.ietf-tls-tls13]. For brevity, the acronym TLS is used to refer to TLS 1.3. Mattsson Expires May 3, 2018 [Page 2] Internet-Draft TLS-OSCORE October 2017 3. Protocol Overview OSCORE [I-D.ietf-core-object-security] provides end-to-end confidentiality, integrity protection, replay protection, as well as a secure message binding of CoAP and CoAP-mappable HTTP requests and responses end-to-end across intermediary nodes such as CoAP forward proxies and cross-protocol translators including HTTP-to-CoAP proxies [RFC8075]. OSCORE can use keys derived from a TLS 1.3 connection [I-D.ietf-tls-tls13], in this case OSCORE also relies on the TLS 1.3 handshake for authentication and negotiation of parameters. This document defines how OSCORE interacts with TLS. This includes a description of how TLS is used, how keying material is derived from TLS, and how other parameters such as AEAD algorithm are negotiated. 3.1. TLS Overview TLS features can be separated into two basic functions: an authenticated key exchange and record protection. OSCORE primarily uses the authenticated key exchange provided by TLS but provides its own packet protection. The TLS record protection is only used to protect the TLS handshake. The keys used to protect the TLS handshake are not exported for use in OSCORE. Keys are exported from the TLS connection when they become available using a TLS exporter (see Section 7.5 of [I-D.ietf-tls-tls13]. The TLS key exchange occurs between two entities: client and server. The client initiates the exchange and the server responds. If the key exchange completes successfully, both client and server will agree on a secret. TLS supports both pre-shared key (PSK) and Diffie-Hellman (DH) key exchanges. PSK is the basis for 0-RTT; the latter provides perfect forward secrecy (PFS) when the ephemeral DH keys are erased. After completing the TLS handshake, the client will have learned and authenticated an identity for the server and the server is optionally able to learn and authenticate an identity for the client. TLS supports X.509 [RFC5280] certificate-based authentication for both server and client. The TLS key exchange is resistent to tampering by attackers and it produces shared secrets that cannot be controlled by either participating peer. Mattsson Expires May 3, 2018 [Page 3] Internet-Draft TLS-OSCORE October 2017 3.2. TLS Usage To use the TLS handshake to key OSCORE, a CoAP server provides a resource that accepts the media types defined in this section, identified by the content-formats in Section 5.2. The specific URI of the resource is up to the server. (In the examples, we are assuming it is at the root of the server, i.e., no Uri-Path options are sent.) The client learns the URI using the usual discovery processes, e.g., the CoRE resource directory [I-D.ietf-core-resource-directory]. A CoAP client starts TLS-OSCORE by requesting TLS handshake octets from TLS. The client acquires handshake octets before sending its first request. A CoAP server starts TLS-OSCORE by providing TLS with handshake octets from a request. Each time that an endpoint receives data (i.e. a CoAP server receiving a request to the TLS-OSCORE resource or a CoAP client receiving a response to a request send to the TLS-OSCORE resource), it delivers the octets to TLS if it is able. Each time that TLS is provided with new data, new handshake octets are requested from TLS. TLS might not provide any octets if the handshake messages it has received are incomplete or it has no data to send. Once the TLS handshake is complete, this is indicated to CoAP along with any final handshake octets that TLS needs to send. TLS also provides OSCORE with the transport parameters that the peer advertised during the handshake. Once the handshake is complete, TLS becomes passive. TLS can still receive data from its peer and respond in kind, but it will not need to send more data unless specifically requested. 3.3. TLS Version This document describes how TLS 1.3 [I-D.ietf-tls-tls13] is used with QUIC. In practice, the TLS handshake will negotiate a version of TLS to use. This could result in a newer version of TLS than 1.3 being negotiated if both endpoints support that version. This is acceptable provided that the features of TLS 1.3 that are used by QUIC are supported by the newer version. A badly configured TLS implementation could negotiate TLS 1.2 or another older version of TLS. An endpoint MUST terminate the connection if a version of TLS older than 1.3 is negotiated. Mattsson Expires May 3, 2018 [Page 4] Internet-Draft TLS-OSCORE October 2017 4. OSCORE Security Context Using this specification, the parameters in the OSCORE security context are obtained using TLS exporters (see Section 7.5 of [I-D.ietf-tls-tls13]). 4.1. Key Derivation Function OSCORE uses HKDF with the same hash function negotiated by TLS for key derivation. For example, if TLS is using the TLS_AES_128_GCM_SHA256, the SHA-256 hash function is used. 4.2. AEAD Algorithm The Authentication Encryption with Associated Data (AEAD) algorithm used for OSCORE is the AEAD that is negotiated for use with the TLS connection. For example, if TLS is using TLS_AES_128_CCM_8_SHA256, the AES-CCM-16-64-128 algorithm is used. +-------------------+--------------------+ | TLS AEAD | COSE AEAD | +-------------------+--------------------+ | AES_128_GCM | A128GCM | | | | | AES_256_GCM | A256GCM | | | | | CHACHA20_POLY1305 | ChaCha20/Poly1305 | | | | | AES_128_CCM | AES-CCM-16-128-128 | | | | | AES_128_CCM_8 | AES-CCM-16-64-128 | +-------------------+--------------------+ 4.3. Master Secret and Master Salt The Master Secret and Master Salt are exported from TLS using the exporter labels "EXPORTER-OSCORE Master Secret" and "EXPORTER-OSCORE Master Salt". Both exporters use an empty context. Master Secret = TLS-Exporter("EXPORTER-OSCORE Master Secret" "", AEAD key length) Master Salt = TLS-Exporter("EXPORTER-OSCORE Master Salt" "", 64) Mattsson Expires May 3, 2018 [Page 5] Internet-Draft TLS-OSCORE October 2017 4.4. Sender ID and Recipient ID The Sender ID and Recipient ID are negotiated using the Connection Identifier. Each endpoint set their Recipient ID to the CID which they told the other endpoint to use. Each endpoint set their Sender ID to the CID which the other endpoint told them to use. 5. Example Below is an example message flow showing the the basic full TLS handshake. For the full possibility of handshake message flow, see the TLS 1.3 specification. Client Server POST /TLS-OSCORE ClientHello --------> 2.04 Changed ServerHello EncryptedExtensions CertificateRequest Certificate CertificateVerify <-------- Finished POST /TLS-OSCORE Certificate CertificateVerify Finished --------> <-------- 2.04 Changed The client can derive the OSCORE Security Context after the Finished message has been sent to the server. The server can derive the OSCORE Security Context after the Finished message from the client has been recieved. 6. Security Considerations TODO 7. IANA Considerations 8. Acknowledgments The following individuals provided input to this document: Goeran Selander. This document borrows from ... Mattsson Expires May 3, 2018 [Page 6] Internet-Draft TLS-OSCORE October 2017 9. References 9.1. Normative References [I-D.ietf-core-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", draft-ietf-core-object-security-06 (work in progress), October 2017. [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-21 (work in progress), July 2017. [I-D.rescorla-tls-dtls-connection-id] Rescorla, E. and H. Tschofenig, "The Datagram Transport Layer Security (DTLS) Connection Identifier", draft- rescorla-tls-dtls-connection-id-00 (work in progress), October 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . 9.2. Informative References [I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, "CoRE Resource Directory", draft-ietf-core- resource-directory-12 (work in progress), October 2017. Author's Address John Mattsson Ericsson AB Email: john.mattsson@ericsson.com Mattsson Expires May 3, 2018 [Page 7]