Internet DRAFT - draft-mattsson-ace-tls-oscore
draft-mattsson-ace-tls-oscore
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
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]
