[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/