< draft-friel-tls-atls-03.txt   draft-friel-tls-atls-04.txt >
Network Working Group O. Friel Network Working Group O. Friel
Internet-Draft R. Barnes Internet-Draft R. Barnes
Intended status: Standards Track M. Pritikin Intended status: Informational M. Pritikin
Expires: January 9, 2020 Cisco Expires: May 7, 2020 Cisco
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
M. Baugher M. Baugher
Consultant Consultant
July 08, 2019 November 04, 2019
Application-Layer TLS Application-Layer TLS
draft-friel-tls-atls-03 draft-friel-tls-atls-04
Abstract Abstract
This document specifies how TLS and DTLS can be used at the This document specifies how TLS and DTLS can be used at the
application layer for the purpose of establishing secure end-to-end application layer for the purpose of establishing secure end-to-end
encrypted communication security. encrypted communication security.
Encodings for carrying TLS and DTLS payloads are specified for HTTP Encodings for carrying TLS and DTLS payloads are specified for HTTP
and CoAP to improve interoperability. While the use of TLS and DTLS and CoAP to improve interoperability. While the use of TLS and DTLS
is straight forward we present multiple deployment scenarios to is straight forward we present multiple deployment scenarios to
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Application Layer End-to-End Security Use Cases . . . . . . . 4 3. Application Layer End-to-End Security Use Cases . . . . . . . 4
3.1. Bootstrapping Devices . . . . . . . . . . . . . . . . . . 4 3.1. Constrained Devices . . . . . . . . . . . . . . . . . . . 4
3.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 5 3.2. Bootstrapping Devices . . . . . . . . . . . . . . . . . . 6
4. ATLS Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. ATLS Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Architecture Overview . . . . . . . . . . . . . . . . . . . . 7 5. Architecture Overview . . . . . . . . . . . . . . . . . . . . 7
5.1. Application Architecture . . . . . . . . . . . . . . . . 7 5.1. Application Architecture . . . . . . . . . . . . . . . . 7
5.2. Functional Design . . . . . . . . . . . . . . . . . . . . 13 5.2. Functional Design . . . . . . . . . . . . . . . . . . . . 13
5.3. Network Architecture . . . . . . . . . . . . . . . . . . 15 5.3. Network Architecture . . . . . . . . . . . . . . . . . . 15
6. ATLS Session Establishment . . . . . . . . . . . . . . . . . 16 6. ATLS Session Establishment . . . . . . . . . . . . . . . . . 16
7. ATLS over HTTP Transport . . . . . . . . . . . . . . . . . . 18 7. ATLS over CoAP Transport . . . . . . . . . . . . . . . . . . 18
7.1. Protocol Summary . . . . . . . . . . . . . . . . . . . . 18 8. ATLS over HTTP Transport . . . . . . . . . . . . . . . . . . 19
7.2. Content-Type Header . . . . . . . . . . . . . . . . . . . 19 8.1. Protocol Summary . . . . . . . . . . . . . . . . . . . . 20
7.3. HTTP Status Codes . . . . . . . . . . . . . . . . . . . . 19 8.2. Content-Type Header . . . . . . . . . . . . . . . . . . . 20
7.4. ATLS Session Tracking . . . . . . . . . . . . . . . . . . 19 8.3. HTTP Status Codes . . . . . . . . . . . . . . . . . . . . 20
7.5. Session Establishment and Key Exporting . . . . . . . . . 19 8.4. ATLS Session Tracking . . . . . . . . . . . . . . . . . . 20
7.6. Illustrative ATLS over HTTP Session Establishment . . . . 19 8.5. Session Establishment and Key Exporting . . . . . . . . . 21
7.7. ATLS and HTTP CONNECT . . . . . . . . . . . . . . . . . . 20 8.6. Illustrative ATLS over HTTP Session Establishment . . . . 21
8. ATLS over CoAP Transport . . . . . . . . . . . . . . . . . . 23 9. Key Exporting and Application Data Encryption . . . . . . . . 22
9. Key Exporting and Application Data Encryption . . . . . . . . 24 9.1. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. TLS Ciphersuite to COSE/OSCORE Algorithm Mapping . . . . . . 23
10. TLS Ciphersuite to COSE/OSCORE Algorithm Mapping . . . . . . 26 11. TLS Extensions . . . . . . . . . . . . . . . . . . . . . . . 24
11. TLS Extensions . . . . . . . . . . . . . . . . . . . . . . . 27 11.1. The "oscore_connection_id" Extension . . . . . . . . . . 24
11.1. The "oscore_connection_id" Extension . . . . . . . . . . 27 11.2. The "cose_ext" Extension . . . . . . . . . . . . . . . . 25
11.2. The "cose_ext" Extension . . . . . . . . . . . . . . . . 27 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 12.1. "oscore_connection_id" TLS extension . . . . . . . . . . 25
12.1. "oscore_connection_id" TLS extension . . . . . . . . . . 28 12.2. TLS Ciphersuite to OSCORE/COSE Algorithm Mapping . . . . 26
12.2. TLS Ciphersuite to OSCORE/COSE Algorithm Mapping . . . . 28 12.3. .well-known URI Registry . . . . . . . . . . . . . . . . 26
12.3. .well-known URI Registry . . . . . . . . . . . . . . . . 29 12.4. Media Types Registry . . . . . . . . . . . . . . . . . . 27
12.4. Media Types Registry . . . . . . . . . . . . . . . . . . 29 12.5. HTTP Content-Formats Registry . . . . . . . . . . . . . 28
12.5. HTTP Content-Formats Registry . . . . . . . . . . . . . 30 12.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 28
12.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 30 12.7. TLS Key Extractor Label . . . . . . . . . . . . . . . . 28
12.7. TLS Key Extractor Label . . . . . . . . . . . . . . . . 31 13. Security Considerations . . . . . . . . . . . . . . . . . . . 28
13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 14.1. Normative References . . . . . . . . . . . . . . . . . . 29
14.1. Normative References . . . . . . . . . . . . . . . . . . 31 14.2. Informative References . . . . . . . . . . . . . . . . . 30
14.2. Informative References . . . . . . . . . . . . . . . . . 33 Appendix A. Pseudo Code . . . . . . . . . . . . . . . . . . . . 32
Appendix A. Pseudo Code . . . . . . . . . . . . . . . . . . . . 34 A.1. OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.1. OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.2. Java JSSE . . . . . . . . . . . . . . . . . . . . . . . . 34
A.2. Java JSSE . . . . . . . . . . . . . . . . . . . . . . . . 36 Appendix B. ATLS and HTTP CONNECT . . . . . . . . . . . . . . . 36
Appendix B. Example ATLS Handshake . . . . . . . . . . . . . . . 38
Appendix C. Alternative Approaches to Application Layer End-to- Appendix C. Alternative Approaches to Application Layer End-to-
End Security . . . . . . . . . . . . . . . . . . . . 38 End Security . . . . . . . . . . . . . . . . . . . . 39
C.1. Noise . . . . . . . . . . . . . . . . . . . . . . . . . . 38 C.1. Noise . . . . . . . . . . . . . . . . . . . . . . . . . . 39
C.2. Signal . . . . . . . . . . . . . . . . . . . . . . . . . 38 C.2. Signal . . . . . . . . . . . . . . . . . . . . . . . . . 40
C.3. Google ALTS . . . . . . . . . . . . . . . . . . . . . . . 39 C.3. Google ALTS . . . . . . . . . . . . . . . . . . . . . . . 40
C.4. Ephemeral Diffie-Hellman Over COSE (EDHOC) . . . . . . . 39 C.4. Ephemeral Diffie-Hellman Over COSE (EDHOC) . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
There are multiple scenarios where there is a need for application There are multiple scenarios where there is a need for application
layer end-to-end security between clients and application services. layer end-to-end security between clients and application services.
Two examples include: Two examples include:
o Bootstrapping devices that must connect to HTTP application
services across untrusted TLS interception middleboxes
o Constrained devices connecting via gateways to application o Constrained devices connecting via gateways to application
services, where different transport layer protocols may be in use services, where different transport layer protocols may be in use
on either side of the gateway, with the gateway transcoding on either side of the gateway, with the gateway transcoding
between the different transport layer protocols. between the different transport layer protocols.
o Bootstrapping devices that must connect to HTTP application
services across untrusted TLS interception middleboxes
These two scenarios are described in more detail in Section 3. These two scenarios are described in more detail in Section 3.
This document describes how clients and applications can leverage This document describes how clients and applications can leverage
standard TLS software stacks to establish secure end-to-end encrypted standard TLS software stacks to establish secure end-to-end encrypted
connections at the application layer. TLS [RFC5246] [RFC8446] or connections at the application layer. TLS [RFC5246] [RFC8446] or
DTLS [RFC6347] [I-D.ietf-tls-dtls13] can be used and this document is DTLS [RFC6347] [I-D.ietf-tls-dtls13] can be used and this document is
agnostic to the versions being used. There are multiple advantages agnostic to the versions being used. There are multiple advantages
to reuse of existing TLS software stacks for establishment of to reuse of existing TLS software stacks for establishment of
application layer secure connections. These include: application layer secure connections. These include:
skipping to change at page 4, line 27 skipping to change at page 4, line 27
o automatically benefit from new features, bugfixes, etc. in TLS o automatically benefit from new features, bugfixes, etc. in TLS
software stack upgrades software stack upgrades
When TLS or DTLS is used at the application layer we refer to it as When TLS or DTLS is used at the application layer we refer to it as
Application-Layer TLS, or ATLS. There is, however, no difference to Application-Layer TLS, or ATLS. There is, however, no difference to
TLS versions used over connection-oriented transports, such as TCP or TLS versions used over connection-oriented transports, such as TCP or
SCTP. The same is true for DTLS. The difference is mainly in its SCTP. The same is true for DTLS. The difference is mainly in its
use and the requirements placed on the underlying transport. use and the requirements placed on the underlying transport.
This document defines how ATLS can be used over HTTP [RFC7230] This document defines how ATLS can be used over HTTP [RFC7230]
[RFC7540] and over CoAP. This document does not preclude the use of [RFC7540] and over CoAP [RFC7252]. This document does not preclude
other transports. However, defining how ATLS can be established over the use of other transports. However, defining how ATLS can be
[ZigBee], [Bluetooth], etc. is beyond the scope of this document. established over [ZigBee], [Bluetooth], etc. is beyond the scope of
this document.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Application-Layer TLS is referred to as ATLS throughout this Application-Layer TLS is referred to as ATLS throughout this
document. document.
3. Application Layer End-to-End Security Use Cases 3. Application Layer End-to-End Security Use Cases
This section describes describes a few end-to-end use cases in more This section describes describes a few end-to-end use cases in more
detail. detail.
3.1. Bootstrapping Devices 3.1. Constrained Devices
There are far more classes of clients being deployed on today's
networks than at any time previously. This poses challenges for
network administrators who need to manage their network and the
clients connecting to their network, and poses challenges for client
vendors and client software developers who must ensure that their
clients can connect to all required services.
One common example is where a client is deployed on a local domain
TCP/IP network that protects its perimeter using a TLS terminating
middlebox, and the client needs to establish a secure connection to a
service in a different network via the middlebox. This is
illustrated in Figure 1.
Traditionally, this has been enabled by the network administrator
deploying the necessary certificate authority trusted roots on the
client. This can be achieved at scale using standard tools that
enable the administrator to automatically push trusted roots out to
all client machines in the network from a centralized domain
controller. This works for personal computers, laptops and servers
running standard Operating Systems that can be centrally managed.
This client management process breaks for multiple classes of clients
that are being deployed today, there is no standard mechanism for
configuring trusted roots on these clients, and there is no standard
mechanism for these clients to securely traverse middleboxes.
+--------+ C->M TLS +-----------+ M->S TLS +---------+
| Client |--------------->| Middlebox |------------->| Service |
+--------+ +-----------+ +---------+
^ ^
| |
+-----------Client to Service ATLS Connection---------+
Figure 1: Bootstrapping Devices
The ATLS mechanism defined in this document enables clients to
traverse middleboxes and establish secure connections to services
across network domain boundaries. The purpose of this connection may
simply be to facilitate a bootstrapping process, for example
[I-D.ietf-anima-bootstrapping-keyinfra], whereby the client securely
discovers the local domain certificate authorities required to
establish a trusted network layer TLS connection to the middlebox.
3.2. Constrained Devices
Two constrained device use cases are outlined here. Two constrained device use cases are outlined here.
3.2.1. Constrained Device Connecting over a Non-IP Network 3.1.1. Constrained Device Connecting over a Non-IP Network
There are industry examples of smart lighting systems where There are industry examples of smart lighting systems where
luminaires are connected using ZigBee to a gateway. A server luminaires are connected using ZigBee to a gateway. A server
connects to the gateway using CoAP over DTLS. The server can control connects to the gateway using CoAP over DTLS. The server can control
the luminaires by sending messages and commands via the gateway. The the luminaires by sending messages and commands via the gateway. The
gateway has full access to all messages sent between the luminaires gateway has full access to all messages sent between the luminaires
and the server. and the server.
A generic use case similar to the smart lighting system outlined A generic use case similar to the smart lighting system outlined
above has an IoT device talking ZigBee, Bluetooth Low Energy, above has an IoT device talking ZigBee, Bluetooth Low Energy,
LoRaWAN, NB-IoT, etc. to a gateway, with the gateway in turn talking LoRaWAN, NB-IoT, etc. to a gateway, with the gateway in turn talking
CoAP over DTLS or another protocol to a server located in the cloud CoAP over DTLS or another protocol to a server located in the cloud
or on-premise. This is illustrated in Figure 2. or on-premise. This is illustrated in Figure 1.
There are scenarios where certain messages sent between the IoT There are scenarios where certain messages sent between the IoT
device and the server must not be exposed to the gateway function. device and the server must not be exposed to the gateway function.
Additionally, the two endpoints may not have visibility to and no Additionally, the two endpoints may not have visibility to and no
guarantees about what transport layer security and encryption is guarantees about what transport layer security and encryption is
enforced across all hops end-to-end as they only have visibility to enforced across all hops end-to-end as they only have visibility to
their immediate next hop. ATLS addresses these concerns. their immediate next hop. ATLS addresses these concerns.
+--------+ ZigBee +---------+ CoAP/DTLS +------------+ +--------+ ZigBee +---------+ CoAP/DTLS +------------+
| Device |-------------->| Gateway |------------->| Server | | Device |-------------->| Gateway |------------->| Server |
+--------+ +---------+ +------------+ +--------+ +---------+ +------------+
^ ^ ^ ^
| | | |
+-------- Device to Server -------+ +-------- Device to Server -------+
Figure 2: IoT Closed Network Gateway Figure 1: IoT Closed Network Gateway
3.2.2. Constrained Device Connecting over IP 3.1.2. Constrained Device Connecting over IP
In this example an IoT device connecting to a gateway using a In this example an IoT device connecting to a gateway using a
suitable transport mechanism, such as ZigBee, CoAP, MQTT, etc. The suitable transport mechanism, such as ZigBee, CoAP, MQTT, etc. The
gateway function in turn talks HTTP over TLS (or, for example, HTTP gateway function in turn talks HTTP over TLS (or, for example, HTTP
over QUIC) to an application service over the Internet. This is over QUIC) to an application service over the Internet. This is
illustrated in Figure 3. illustrated in Figure 2.
The gateway may not be trusted and all messages between the IoT The gateway may not be trusted and all messages between the IoT
device and the application service must be end-to-end encrypted. device and the application service must be end-to-end encrypted.
Similar to the previous use case, the endpoints have no guarantees Similar to the previous use case, the endpoints have no guarantees
about what level of transport layer security is enforced across all about what level of transport layer security is enforced across all
hops. Again, ATLS addresses these concerns. hops. Again, ATLS addresses these concerns.
+--------+ CoAP/DTLS +------------------+ HTTP/TLS +---------+ +--------+ CoAP/DTLS +------------------+ HTTP/TLS +---------+
| Device |-------------->| Internet Gateway |------------>| Service | | Device |-------------->| Internet Gateway |------------>| Service |
+--------+ +------------------+ +---------+ +--------+ +------------------+ +---------+
^ ^ ^ ^
| | | |
+---------Device to Cloud Service ATLS Connection----------+ +---------Device to Cloud Service ATLS Connection----------+
Figure 3: IoT Internet Gateway Figure 2: IoT Internet Gateway
3.2. Bootstrapping Devices
There are far more classes of clients being deployed on today's
networks than at any time previously. This poses challenges for
network administrators who need to manage their network and the
clients connecting to their network, and poses challenges for client
vendors and client software developers who must ensure that their
clients can connect to all required services.
One common example is where a client is deployed on a local domain
TCP/IP network that protects its perimeter using a TLS terminating
middlebox, and the client needs to establish a secure connection to a
service in a different network via the middlebox. This is
illustrated in Figure 3.
Traditionally, this has been enabled by the network administrator
deploying the necessary certificate authority trusted roots on the
client. This can be achieved at scale using standard tools that
enable the administrator to automatically push trusted roots out to
all client machines in the network from a centralized domain
controller. This works for personal computers, laptops and servers
running standard Operating Systems that can be centrally managed.
This client management process breaks for multiple classes of clients
that are being deployed today, there is no standard mechanism for
configuring trusted roots on these clients, and there is no standard
mechanism for these clients to securely traverse middleboxes.
+--------+ C->M TLS +-----------+ M->S TLS +---------+
| Client |--------------->| Middlebox |------------->| Service |
+--------+ +-----------+ +---------+
^ ^
| |
+-----------Client to Service ATLS Connection---------+
Figure 3: Bootstrapping Devices
The ATLS mechanism defined in this document enables clients to
traverse middleboxes and establish secure connections to services
across network domain boundaries. The purpose of this connection may
simply be to facilitate a bootstrapping process, for example
[I-D.ietf-anima-bootstrapping-keyinfra], whereby the client securely
discovers the local domain certificate authorities required to
establish a trusted network layer TLS connection to the middlebox.
4. ATLS Goals 4. ATLS Goals
The high level goals driving the design of this mechanism are: The high level goals driving the design of this mechanism are:
o enable authenticated key exchange at the application layer by o enable authenticated key exchange at the application layer by
reusing existing technologies, reusing existing technologies,
o ensure that ATLS packets are explicitly identified thus ensuring o ensure that ATLS packets are explicitly identified thus ensuring
that any middleboxes or gateways at the transport layer are that any middleboxes or gateways at the transport layer are
skipping to change at page 11, line 24 skipping to change at page 11, line 24
5.1.2. ATLS Packet Identification 5.1.2. ATLS Packet Identification
It is recommended that ATLS packets are explicitly identified by a It is recommended that ATLS packets are explicitly identified by a
standardized, transport-specific identifier enabling any gateways and standardized, transport-specific identifier enabling any gateways and
middleboxes to identify ATLS packets. Middleboxes have to contend middleboxes to identify ATLS packets. Middleboxes have to contend
with a vast number of applications and network operators have with a vast number of applications and network operators have
difficulty configuring middleboxes to distinguish unencrypted but not difficulty configuring middleboxes to distinguish unencrypted but not
explicitly identified application data from end-to-end encrypted explicitly identified application data from end-to-end encrypted
data. This specification aims to assist network operators by data. This specification aims to assist network operators by
explicitly identifying ATLS packets. The HTTP and CoAP encodings explicitly identifying ATLS packets. The HTTP and CoAP encodings
documented in Section 7 and Section 8 explicitly identify ATLS documented in Section 8 and Section 7 explicitly identify ATLS
packets. packets.
5.1.3. ATLS Session Tracking 5.1.3. ATLS Session Tracking
The ATLS application service establishes multiple ATLS sessions with The ATLS application service establishes multiple ATLS sessions with
multiple clients. As TLS sessions are stateful, the application multiple clients. As TLS sessions are stateful, the application
service must be able to correlate ATLS records from different clients service must be able to correlate ATLS records from different clients
across the relevant ATLS sessions. The details of how session across the relevant ATLS sessions. The details of how session
tracking is implemented are outside the scope of this document. tracking is implemented are outside the scope of this document.
Recommendations are given in Section 7 and Section 8, but session Recommendations are given in Section 8 and Section 7, but session
tracking is application and implementation specific. tracking is application and implementation specific.
5.1.4. ATLS Record Inspection 5.1.4. ATLS Record Inspection
No constraints are placed on the ContentType contained within the No constraints are placed on the ContentType contained within the
transported TLS records. The TLS records may contain handshake, transported TLS records. The TLS records may contain handshake,
application_data, alert or change_cipher_spec messages. If new application_data, alert or change_cipher_spec messages. If new
ContentType messages are defined in future TLS versions, these may ContentType messages are defined in future TLS versions, these may
also be transported using this protocol. also be transported using this protocol.
skipping to change at page 18, line 36 skipping to change at page 18, line 36
| Session | | | | | | Session | | | | |
| | Up | | | | | | | Up | | | | |
+ |--------->| | | | | + |--------->| | | | |
| Export | | | | Export | | Export | | | | Export |
| Keys | | | | Keys | | Keys | | | | Keys |
|--------->| | E2E Session | |<---------| |--------->| | E2E Session | |<---------|
| |<--------|-------------|--------->| | | |<--------|-------------|--------->| |
Figure 11: ATLS Session Establishment Figure 11: ATLS Session Establishment
7. ATLS over HTTP Transport 7. ATLS over CoAP Transport
To carry TLS messages over CoAP [RFC7252] it is recommended to use
Confirmable messages while DTLS payloads may as well use non-
confirmable messages. The exchange pattern in CoAP uses the
following style: A request from the CoAP client to the CoAP server
uses a POST with the ATLS message contained in the payload of the
request. An ATLS response is returned by the CoAP server to the CoAP
client in a 2.04 (Changed) message.
When DTLS messages are conveyed in CoAP over UDP then the DDoS
protection offered by DTLS MAY be used instead of replicating the
functionality at the CoAP layer. If TLS is conveyed in CoAP over UDP
then DDoS protection by CoAP has to be utilized. Carrying ATLS
messages in CoAP over TCP does not require any additional DDoS
protection.
The URI path used by ATLS is "/.well-known/atls".
{{coap-example} shows a TLS 1.3 handshake inside CoAP graphically.
Client Server
| |
+--------->| Header: POST (Code=0.02)
| POST | Uri-Path: "/.well-known/atls"
| | Content-Format: application/atls
| | Payload: ATLS (ClientHello)
| |
|<---------+ Header: 2.04 Changed
| 2.04 | Content-Format: application/atls
| | Payload: ATLS (ServerHello,
| | {EncryptedExtensions}, {CertificateRequest*}
| | {Certificate*}, {CertificateVerify*} {Finished})
| |
+--------->| Header: POST (Code=0.02)
| POST | Uri-Path: "/.well-known/atls"
| | Content-Format: application/atls
| | Payload: ATLS ({Certificate*},
| | {CertificateVerify*}, {Finished})
| |
|<---------+ Header: 2.04 Changed
| 2.04 |
| |
Figure 12: Transferring ATLS in CoAP
Note that application data can already be sent by the server in the
second message and by the client in the third message, in case of the
full TLS 1.3 handshake. In case of the 0-RTT handshake application
data can be sent earlier. To mix different media types in the same
CoAP payload the application/multipart-core content type is used.
Note also that CoAP blockwise transfer MAY be used if the payload
size, for example due to the size of the certificate chain, exceeds
the MTU size.
8. ATLS over HTTP Transport
The assumption is that the client will establish a transport layer The assumption is that the client will establish a transport layer
connection to the server for exchange of HTTP messages. The connection to the server for exchange of HTTP messages. The
underlying transport layer connection could be over TCP or TLS. The underlying transport layer connection could be over TCP or TLS. The
client will then establish an application layer TLS connection with client will then establish an application layer TLS connection with
the server by exchanging TLS records with the server inside HTTP the server by exchanging TLS records with the server inside HTTP
message request and response bodies. message request and response bodies.
7.1. Protocol Summary Note that ATLS over HTTP transport addresses a different deployment
scenario than HTTP CONNECT proxies. HTTP CONNECT proxy behaviour is
compared and contrasted with ATLS in Appendix B.
8.1. Protocol Summary
All ATLS records are transported unmodified as binary data within All ATLS records are transported unmodified as binary data within
HTTP message bodies. The application simply extracts the TLS records HTTP message bodies. The application simply extracts the TLS records
from the TLS stack and inserts them directly into HTTP message from the TLS stack and inserts them directly into HTTP message
bodies. Each message body contains a full TLS flight, which may bodies. Each message body contains a full TLS flight, which may
contain multiple TLS records. contain multiple TLS records.
The client sends all ATLS records to the server in the bodies of POST The client sends all ATLS records to the server in the bodies of POST
requests. requests.
The server sends all ATLS records to the client in the bodies of 200 The server sends all ATLS records to the client in the bodies of 200
OK responses to the POST requests. OK responses to the POST requests.
The URI path used by ATLS is "/.well-known/atls". The URI path used by ATLS is "/.well-known/atls".
7.2. Content-Type Header 8.2. Content-Type Header
A new Content-Type header value is defined: A new Content-Type header value is defined:
Content-type: application/atls Content-type: application/atls
All message bodies containing ATLS records must set this Content- All message bodies containing ATLS records must set this Content-
Type. This enables middleboxes to readily identify ATLS payloads. Type. This enables middleboxes to readily identify ATLS payloads.
7.3. HTTP Status Codes 8.3. HTTP Status Codes
This document does not define any new HTTP status codes, and does not This document does not define any new HTTP status codes, and does not
specify additional semantics or refine existing semantics for status specify additional semantics or refine existing semantics for status
codes. This is the best current practice as outlined in codes. This is the best current practice as outlined in
[I-D.ietf-httpbis-bcp56bis]. [I-D.ietf-httpbis-bcp56bis].
7.4. ATLS Session Tracking 8.4. ATLS Session Tracking
The application service needs to track multiple client application The application service needs to track multiple client application
layer TLS sessions so that it can correlate TLS records received in layer TLS sessions so that it can correlate TLS records received in
HTTP message bodies with the appropriate TLS session. The HTTP message bodies with the appropriate TLS session. The
application service should use stateful cookies [RFC6265] in order to application service should use stateful cookies [RFC6265] in order to
achieve this as recommended in [I-D.ietf-httpbis-bcp56bis]. achieve this as recommended in [I-D.ietf-httpbis-bcp56bis].
7.5. Session Establishment and Key Exporting 8.5. Session Establishment and Key Exporting
It is recommended that applications using ATLS over HTTP transport It is recommended that applications using ATLS over HTTP transport
only use ATLS for session establishment and key exchange, resulting only use ATLS for session establishment and key exchange, resulting
in only 2 ATLS RTTs between the client and the application service. in only 2 ATLS RTTs between the client and the application service.
Key exporting must be carried out as described in Section 9. Key exporting must be carried out as described in Section 9.
7.6. Illustrative ATLS over HTTP Session Establishment 8.6. Illustrative ATLS over HTTP Session Establishment
A client initiates an ATLS session by sending the first TLS flight in A client initiates an ATLS session by sending the first TLS flight in
a POST request message body to the ATLS server. a POST request message body to the ATLS server.
POST /.well-known/atls POST /.well-known/atls
Content-Type: application/atls Content-Type: application/atls
<binary TLS client flight 1 records> <binary TLS client flight 1 records>
The server handles the request, creates an ATLS session object, and The server handles the request, creates an ATLS session object, and
skipping to change at page 20, line 37 skipping to change at page 22, line 5
<binary TLS client flight 2 records> <binary TLS client flight 2 records>
The server handles the second flight, establishes the ATLS session, The server handles the second flight, establishes the ATLS session,
and replies with its second flight. and replies with its second flight.
200 OK 200 OK
Content-Type: application/atls Content-Type: application/atls
<binary TLS server flight 2 records> <binary TLS server flight 2 records>
7.7. ATLS and HTTP CONNECT
It is worthwhile comparing and contrasting ATLS with HTTP CONNECT
tunneling.
First, let us introduce some terminology:
o HTTP Proxy: A HTTP Proxy operates at the application layer,
handles HTTP CONNECT messages from clients, and opens tunnels to
remote origin servers on behalf of clients. If a client
establishes a tunneled TLS connection to the origin server, the
HTTP Proxy does not attempt to intercept or inspect the HTTP
messages exchanged between the client and the server
o middlebox: A middlebox operates at the transport layer, terminates
TLS connections from clients, and originates new TLS connections
to services. A middlebox inspects all messages sent between
clients and services. Middleboxes are generally completely
transparent to applications, provided that the necessary PKI root
Certificate Authority is installed in the client's trust store.
HTTP Proxies and middleboxes are logically separate entities and one
or both of these may be deployed in a network.
HTTP CONNECT is used by clients to instruct a HTTP Forward Proxy
deployed in the local domain to open up a tunnel to a remote origin
server that is typically deployed in a different domain. Assuming
that TLS transport is used between both client and proxy, and proxy
and origin server, the network architecture is as illustrated in
Figure 12. Once the proxy opens the transport tunnel to the service,
the client establishes an end-to-end TLS session with the service,
and the proxy is blindly transporting TLS records (the C->S TLS
session records) between the client and the service. From the client
perspective, it is tunneling a TLS session to the service inside the
TLS session it has established to the proxy (the C->P TLS session).
No middlebox is attempting to intercept or inspect the HTTP messages
between the client and the service.
+----------+ +----------+
| C->S HTTP| | C->S HTTP|
+----------+ +----------+
| C->S TLS | | C->S TLS |
+----------+ +----------+
| C->P TLS | | P->S TCP |
+----------+ +----------+
| C->P TCP |
+----------+
+--------+ +------------+ +---------+
| Client |----->| HTTP Proxy |----->| Service |
+--------+ +------------+ +---------+
Figure 12: HTTP Proxy transport layers
A more complex network topology where the network operator has both a
HTTP Proxy and a middlebox deployed is illustrated in Figure 13. In
this scenario, the proxy has tunneled the TLS session from the client
towards the origin server, however the middlebox is intercepting and
terminating this TLS session. A TLS session is established between
the client and the middlebox (C->M TLS), and not end-to-end between
the client and the server. It can clearly be seen that HTTP CONNECT
and HTTP Proxies serve completely different functions than
middleboxes.
Additionally, the fact that the TLS session is established between
the client and the middlebox can be problematic for two reasons:
o the middle box is inspecting traffic that is sent between the
client and the service
o the client may not have the necessary PKI root Certificate
Authority installed that would enable it to validate the TLS
connection to the middlebox. This is the scenario outlined in
Section 3.1.
+----------+ +----------+ +----------+
| C->S HTTP| | C->S HTTP| | C->S HTTP|
+----------+ +----------+ +----------+
| C->M TLS | | C->M TLS | | M->S TLS |
+----------+ +----------+ +----------+
| C->P TLS | | P->M TCP | | M->S TCP |
+----------+ +----------+ +----------+
| C->P TCP |
+----------+
+--------+ +------------+ +-----------+ +---------+
| Client |----->| HTTP Proxy |----->| Middlebox |----->| Service |
+--------+ +------------+ +-----------+ +---------+
Figure 13: HTTP Proxy and middlebox transport layers
As HTTP CONNECT can be used to establish a tunneled TLS connection,
one hypothetical solution to this middlebox issue is for the client
to issue a HTTP CONNECT command to a HTTP Reverse Proxy deployed in
front of the origin server. This solution is not practical for
several reasons:
o if there is a local domain HTTP Forward Proxy deployed, this would
result in the client doing a first HTTP CONNECT to get past the
Forward Proxy, and then a second HTTP CONNECT to get past the
Reverse Proxy. No client or client library supports the concept
of HTTP CONNECT inside HTTP CONNECT.
o if there is no local domain HTTP Proxy deployed, the client still
has to do a HTTP CONNECT to the HTTP Reverse Proxy. This breaks
with standard and expected HTTP CONNECT operation, as HTTP CONNECT
is only ever called if there is a local domain proxy.
o clients cannot generate CONNECT from XHR in web applications.
o this would require the deployment of a Reverse Proxy in front of
the origin server, or else support of the HTTP CONNECT method in
standard web frameworks. This is not an elegant design.
o using HTTP CONNECT with HTTP 1.1 to a Reverse Proxy will break
middleboxes inspecting HTTP traffic, as the middlebox would see
TLS records when it expects to see HTTP payloads.
In contrast to trying to force HTTP CONNECT to address a problem for
which it was not designed to address, and having to address all the
issues just outlined; ATLS is specifically designed to address the
middlebox issue in a simple, easy to develop, and easy to deploy
fashion.
o ATLS works seamlessly with HTTP Proxy deployments
o no changes are required to HTTP CONNECT semantics
o no changes are required to HTTP libraries or stacks
o no additional Reverse Proxy is required to be deployed in front of
origin servers
It is also worth noting that if HTTP CONNECT to a Reverse Proxy were
a conceptually sound solution, the solution still ultimately results
in encrypted traffic traversing the middlebox that the middlebox
cannot intercept and inspect. That is ultimately what ATLS results
in - traffic traversing the middle box that the middlebox cannot
intercept and inspect. Therefore, from a middlebox perspective, the
differences between the two solutions are in the areas of solution
complexity and protocol semantics. It is clear that ATLS is a
simpler, more elegant solution that HTTP CONNECT.
8. ATLS over CoAP Transport
To carry TLS messages over CoAP [RFC7252] it is recommended to use
Confirmable messages while DTLS payloads may as well use non-
confirmable messages. The exchange pattern in CoAP uses the
following style: A request from the CoAP client to the CoAP server
uses a POST with the ATLS message contained in the payload of the
request. An ATLS response is returned by the CoAP server to the CoAP
client in a 2.04 (Changed) message.
When DTLS messages are conveyed in CoAP over UDP then the DDoS
protection offered by DTLS MAY be used instead of replicating the
functionality at the CoAP layer. If TLS is conveyed in CoAP over UDP
then DDoS protection by CoAP has to be utilized. Carrying ATLS
messages in CoAP over TCP does not require any additional DDoS
protection.
The URI path used by ATLS is "/.well-known/atls".
{{coap-example} shows a TLS 1.3 handshake inside CoAP graphically.
Client Server
| |
+--------->| Header: POST (Code=0.02)
| POST | Uri-Path: "/.well-known/atls"
| | Content-Format: application/atls
| | Payload: ATLS (ClientHello)
| |
|<---------+ Header: 2.04 Changed
| 2.04 | Content-Format: application/atls
| | Payload: ATLS (ServerHello,
| | {EncryptedExtensions}, {CertificateRequest*}
| | {Certificate*}, {CertificateVerify*} {Finished})
| |
+--------->| Header: POST (Code=0.02)
| POST | Uri-Path: "/.well-known/atls"
| | Content-Format: application/atls
| | Payload: ATLS ({Certificate*},
| | {CertificateVerify*}, {Finished})
| |
|<---------+ Header: 2.04 Changed
| 2.04 |
| |
Figure 14: Transferring ATLS in CoAP
Note that application data can already be sent by the server in the
second message and by the client in the third message, in case of the
full TLS 1.3 handshake. In case of the 0-RTT handshake application
data can be sent earlier. To mix different media types in the same
CoAP payload the application/multipart-core content type is used.
Note also that CoAP blockwise transfer MAY be used if the payload
size, for example due to the size of the certificate chain, exceeds
the MTU size.
9. Key Exporting and Application Data Encryption 9. Key Exporting and Application Data Encryption
When solutions implement the architecture described in Figure 6, they When solutions implement the architecture described in Figure 6, they
leverage [RFC5705] for exporting keys. This section describes how to leverage [RFC5705] for exporting keys. This section describes how to
establish keying material and negotiate algorithms for OSCORE and for establish keying material and negotiate algorithms for OSCORE and for
COSE. COSE.
9.1. OSCORE 9.1. OSCORE
When the OSCORE mode has been agreed using the "oscore_connection_id" When the OSCORE mode has been agreed using the "oscore_connection_id"
skipping to change at page 26, line 5 skipping to change at page 23, line 12
TLS/DTLS 1.2 handshake negotiated the TLS_PSK_WITH_AES_128_CCM_8 TLS/DTLS 1.2 handshake negotiated the TLS_PSK_WITH_AES_128_CCM_8
ciphersuite then the AEAD algorithm identifier is AES_128_CCM_8, ciphersuite then the AEAD algorithm identifier is AES_128_CCM_8,
which corresponds to two COSE algorithms, which both use AES-CCM which corresponds to two COSE algorithms, which both use AES-CCM
mode with a 128-bit key, a 64-bit tag: mode with a 128-bit key, a 64-bit tag:
* AES-CCM-64-64-128 * AES-CCM-64-64-128
* AES-CCM-16-64-128 The difference between the two is only the * AES-CCM-16-64-128 The difference between the two is only the
length of the nonce, which is 7-bytes in the former case and length of the nonce, which is 7-bytes in the former case and
13-bytes in the latter. In TLS/DTLS the nonce value is not 13-bytes in the latter. In TLS/DTLS the nonce value is not
negotiated but fixed instead. Figure 15 provides the mapping negotiated but fixed instead. Figure 13 provides the mapping
between the TLS defined ciphersuite and the COSE algorithms. between the TLS defined ciphersuite and the COSE algorithms.
o Master Salt: The master salt is derived as described above. o Master Salt: The master salt is derived as described above.
o HKDF Algorithm: This value is negotiated using the ciphersuite o HKDF Algorithm: This value is negotiated using the ciphersuite
exchange provided by the TLS/DTLS handshake. As a default, exchange provided by the TLS/DTLS handshake. As a default,
SHA-256 is assumed as a HKDF algorithm for algorithms using SHA-256 is assumed as a HKDF algorithm for algorithms using
128-bit key sizes and SHA384 for 256-bit key sizes. 128-bit key sizes and SHA384 for 256-bit key sizes.
o Replay Window: A default window size of 32 packets is assumed. o Replay Window: A default window size of 32 packets is assumed.
skipping to change at page 26, line 28 skipping to change at page 23, line 35
The key exporting procedure for COSE is similiar to the one defined The key exporting procedure for COSE is similiar to the one defined
for OSCORE. The label string for use with this specification is for OSCORE. The label string for use with this specification is
defined as 'atls-cose'. The per-association context value is empty. defined as 'atls-cose'. The per-association context value is empty.
The length value is twice the size of the key size utilized by the The length value is twice the size of the key size utilized by the
negotiated algorithm since the lower-half is used for the Master negotiated algorithm since the lower-half is used for the Master
Secret and the upper-half is used for the Master Salt. Secret and the upper-half is used for the Master Salt.
The COSE algorithm corresponds to the ciphersuite negotiated during The COSE algorithm corresponds to the ciphersuite negotiated during
the TLS/DTLS handshake with with the mapping provided in Figure 15. the TLS/DTLS handshake with with the mapping provided in Figure 13.
The HKDF algorithm is negotiated using the the TLS/DTLS handshake. The HKDF algorithm is negotiated using the the TLS/DTLS handshake.
As a default, SHA-256 is assumed as a HKDF algorithm for algorithms As a default, SHA-256 is assumed as a HKDF algorithm for algorithms
using 128-bit key sizes and SHA384 for 256-bit key sizes. using 128-bit key sizes and SHA384 for 256-bit key sizes.
COSE uses key ids to allow finding the appropriate security context. COSE uses key ids to allow finding the appropriate security context.
Those key IDs conceptually correspond to CIDs, as described in Those key IDs conceptually correspond to CIDs, as described in
Section 11.2. Section 11.2.
10. TLS Ciphersuite to COSE/OSCORE Algorithm Mapping 10. TLS Ciphersuite to COSE/OSCORE Algorithm Mapping
TLS Ciphersuite | COSE/OSCORE Algorithm TLS Ciphersuite | COSE/OSCORE Algorithm
------------------+-------------------------------------------------- ------------------+--------------------------------------------------
AES_128_CCM_8 | AES-CCM w/128-bit key, 64-bit tag, 13-byte nonce AES_128_CCM_8 | AES-CCM w/128-bit key, 64-bit tag, 13-byte nonce
AES_256_CCM_8 | AES-CCM w/256-bit key, 64-bit tag, 13-byte nonce AES_256_CCM_8 | AES-CCM w/256-bit key, 64-bit tag, 13-byte nonce
CHACHA20_POLY1305 | ChaCha20/Poly1305 w/256-bit key, 128-bit tag CHACHA20_POLY1305 | ChaCha20/Poly1305 w/256-bit key, 128-bit tag
AES_128_CCM | AES-CCM w/128-bit key, 128-bit tag, 13-byte nonce AES_128_CCM | AES-CCM w/128-bit key, 128-bit tag, 13-byte nonce
AES_256_CCM | AES-CCM w/256-bit key, 128-bit tag, 13-byte nonce AES_256_CCM | AES-CCM w/256-bit key, 128-bit tag, 13-byte nonce
AES_128_GCM | AES-GCM w/128-bit key, 128-bit tag AES_128_GCM | AES-GCM w/128-bit key, 128-bit tag
AES_256_GCM | AES-GCM w/256-bit key, 128-bit tag AES_256_GCM | AES-GCM w/256-bit key, 128-bit tag
Figure 15: TLS Ciphersuite to COSE/OSCORE Algorithm Mapping Figure 13: TLS Ciphersuite to COSE/OSCORE Algorithm Mapping
11. TLS Extensions 11. TLS Extensions
11.1. The "oscore_connection_id" Extension 11.1. The "oscore_connection_id" Extension
This document defines the "oscore_connection_id" extension, which is This document defines the "oscore_connection_id" extension, which is
used in ClientHello and ServerHello messages. It is used only for used in ClientHello and ServerHello messages. It is used only for
establishing the OSCORE Sender ID and the OSCORE Recipient ID. The establishing the OSCORE Sender ID and the OSCORE Recipient ID. The
OSCORE Sender ID maps to the CID provided by the server in the OSCORE Sender ID maps to the CID provided by the server in the
ServerHello and the OSCORE Recipient ID maps to the CID provided by ServerHello and the OSCORE Recipient ID maps to the CID provided by
skipping to change at page 27, line 34 skipping to change at page 24, line 45
The extension type is specified as follows. The extension type is specified as follows.
enum { enum {
oscore_connection_id(TBD), (65535) oscore_connection_id(TBD), (65535)
} ExtensionType; } ExtensionType;
struct { struct {
opaque cid<0..2^8-1>; opaque cid<0..2^8-1>;
} ConnectionId; } ConnectionId;
Figure 16: The 'oscore_connection_id' Extension Figure 14: The 'oscore_connection_id' Extension
Note: This extension allows a client and a server to determine Note: This extension allows a client and a server to determine
whether an OSCORE security context should be established. whether an OSCORE security context should be established.
11.2. The "cose_ext" Extension 11.2. The "cose_ext" Extension
This document defines the "cose_ext" extension, which is used in This document defines the "cose_ext" extension, which is used in
ClientHello and ServerHello messages. It is used only for ClientHello and ServerHello messages. It is used only for
establishing the key identifiers, AEAD algorithms, as well as keying establishing the key identifiers, AEAD algorithms, as well as keying
material for use with application layer protection using COSE. The material for use with application layer protection using COSE. The
skipping to change at page 28, line 19 skipping to change at page 25, line 34
The extension type is specified as follows. The extension type is specified as follows.
enum { enum {
oscore_connection_id(TBD), (65535) oscore_connection_id(TBD), (65535)
} ExtensionType; } ExtensionType;
struct { struct {
opaque cid<0..2^8-1>; opaque cid<0..2^8-1>;
} ConnectionId; } ConnectionId;
Figure 17: The 'cose_ext' Extension Figure 15: The 'cose_ext' Extension
Note: This extension allows a client and a server to determine Note: This extension allows a client and a server to determine
whether an COSE security context should be established. whether an COSE security context should be established.
12. IANA Considerations 12. IANA Considerations
12.1. "oscore_connection_id" TLS extension 12.1. "oscore_connection_id" TLS extension
IANA is requested to allocate two entries to the existing TLS IANA is requested to allocate two entries to the existing TLS
"ExtensionType Values" registry, defined in [RFC5246], for "ExtensionType Values" registry, defined in [RFC5246], for
skipping to change at page 28, line 37 skipping to change at page 26, line 4
IANA is requested to allocate two entries to the existing TLS IANA is requested to allocate two entries to the existing TLS
"ExtensionType Values" registry, defined in [RFC5246], for "ExtensionType Values" registry, defined in [RFC5246], for
oscore_connection_id(TBD1) and cose_ext(TBD2) defined in this oscore_connection_id(TBD1) and cose_ext(TBD2) defined in this
document, as described in the table below. document, as described in the table below.
Value Extension Name TLS 1.3 DTLS Only Recommended Reference Value Extension Name TLS 1.3 DTLS Only Recommended Reference
----------------------------------------------------------------------- -----------------------------------------------------------------------
TBD1 oscore_connection_id Y N N [[This doc]] TBD1 oscore_connection_id Y N N [[This doc]]
TBD2 cose_ext Y N N [[This doc]] TBD2 cose_ext Y N N [[This doc]]
Note: The "N" values in the Recommended column are set because these Note: The "N" values in the Recommended column are set because these
extensions are intended only for specific use cases. extensions are intended only for specific use cases.
12.2. TLS Ciphersuite to OSCORE/COSE Algorithm Mapping 12.2. TLS Ciphersuite to OSCORE/COSE Algorithm Mapping
IANA is requested to create a new registry for mapping TLS IANA is requested to create a new registry for mapping TLS
ciphersuites to SCORE/COSE algorithms ciphersuites to SCORE/COSE algorithms
An initial mapping can be found in Figure 15. An initial mapping can be found in Figure 13.
Registration requests are evaluated after a three-week review period Registration requests are evaluated after a three-week review period
on the tls-reg-review@ietf.or mailing list, on the advice of one or on the tls-reg-review@ietf.or mailing list, on the advice of one or
more Designated Experts [RFC8126]. However, to allow for the more Designated Experts [RFC8126]. However, to allow for the
allocation of values prior to publication, the Designated Experts may allocation of values prior to publication, the Designated Experts may
approve registration once they are satisfied that such a approve registration once they are satisfied that such a
specification will be published. specification will be published.
Registration requests sent to the mailing list for review should use Registration requests sent to the mailing list for review should use
an appropriate subject (e.g., "Request to register an TLS - OSCORE/ an appropriate subject (e.g., "Request to register an TLS - OSCORE/
skipping to change at page 31, line 45 skipping to change at page 29, line 18
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-16 (work in (OSCORE)", draft-ietf-core-object-security-16 (work in
progress), March 2019. progress), March 2019.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-31 (work in progress), March 1.3", draft-ietf-tls-dtls13-33 (work in progress), October
2019. 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
skipping to change at page 33, line 24 skipping to change at page 30, line 46
[ALTS] Google, "Application Layer Transport Security", December [ALTS] Google, "Application Layer Transport Security", December
2017, <https://cloud.google.com/security/encryption-in- 2017, <https://cloud.google.com/security/encryption-in-
transit/application-layer-transport-security/>. transit/application-layer-transport-security/>.
[Bluetooth] [Bluetooth]
Bluetooth, "Bluetooth Core Specification v5.0", 2016, Bluetooth, "Bluetooth Core Specification v5.0", 2016,
<https://www.bluetooth.com/>. <https://www.bluetooth.com/>.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
S., and K. Watsen, "Bootstrapping Remote Secure Key and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-22 (work in progress), June 2019. keyinfra-29 (work in progress), October 2019.
[I-D.ietf-httpbis-bcp56bis] [I-D.ietf-httpbis-bcp56bis]
Nottingham, M., "Building Protocols with HTTP", draft- Nottingham, M., "Building Protocols with HTTP", draft-
ietf-httpbis-bcp56bis-08 (work in progress), November ietf-httpbis-bcp56bis-09 (work in progress), November
2018. 2019.
[I-D.ietf-tls-dtls-connection-id] [I-D.ietf-tls-dtls-connection-id]
Rescorla, E., Tschofenig, H., and T. Fossati, "Connection Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
id-05 (work in progress), May 2019. id-07 (work in progress), October 2019.
[I-D.mattsson-lwig-security-protocol-comparison] [I-D.mattsson-lwig-security-protocol-comparison]
Mattsson, J. and F. Palombini, "Comparison of CoAP Mattsson, J. and F. Palombini, "Comparison of CoAP
Security Protocols", draft-mattsson-lwig-security- Security Protocols", draft-mattsson-lwig-security-
protocol-comparison-01 (work in progress), March 2018. protocol-comparison-01 (work in progress), March 2018.
[I-D.rescorla-tls-ctls] [I-D.rescorla-tls-ctls]
Rescorla, E., "Compact TLS 1.3", draft-rescorla-tls- Rescorla, E. and R. Barnes, "Compact TLS 1.3", draft-
ctls-01 (work in progress), March 2019. rescorla-tls-ctls-02 (work in progress), July 2019.
[I-D.selander-ace-cose-ecdhe] [I-D.selander-ace-cose-ecdhe]
Selander, G., Mattsson, J., and F. Palombini, "Ephemeral Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace-
cose-ecdhe-13 (work in progress), March 2019. cose-ecdhe-14 (work in progress), September 2019.
[LwM2M] Open Mobile Alliance, "Lightweight Machine to Machine [LwM2M] Open Mobile Alliance, "Lightweight Machine to Machine
Requirements", December 2017, Requirements", December 2017,
<http://www.openmobilealliance.org/>. <http://www.openmobilealliance.org/>.
[Noise] Perrin, T., "Noise Protocol Framework", October 2017, [Noise] Perrin, T., "Noise Protocol Framework", October 2017,
<http://noiseprotocol.org/>. <http://noiseprotocol.org/>.
[Norrell] Norrell, ., "Use SSL/TLS within a different protocol with [Norrell] Norrell, ., "Use SSL/TLS within a different protocol with
BIO pairs", 2016, BIO pairs", 2016,
<https://thekerneldiaries.com/2016/06/13/ <https://thekerneldiaries.com/2016/06/13/openssl-ssltls-
openssl-ssltls-within-a-different-protocol/>. within-a-different-protocol/>.
[Signal] Open Whisper Systems, "Signal Protocol", 2016, [Signal] Open Whisper Systems, "Signal Protocol", 2016,
<https://signal.org/>. <https://signal.org/>.
[SSLEngine] [SSLEngine]
Oracle, "SSLEngineSimpleDemo.java", 2004, <https://docs.or Oracle, "SSLEngineSimpleDemo.java", 2004, <https://docs.or
acle.com/javase/7/docs/technotes/guides/security/jsse/samp acle.com/javase/7/docs/technotes/guides/security/jsse/
les/sslengine/SSLEngineSimpleDemo.java>. samples/sslengine/SSLEngineSimpleDemo.java>.
[ZigBee] ZigBee Alliance, "ZigBee Specification", 2012, [ZigBee] ZigBee Alliance, "ZigBee Specification", 2012,
<http://www.zigbee.org>. <http://www.zigbee.org>.
Appendix A. Pseudo Code Appendix A. Pseudo Code
This appendix gives both C and Java pseudo code illustrating how to This appendix gives both C and Java pseudo code illustrating how to
inject and extract raw TLS records from a TLS software stack. Please inject and extract raw TLS records from a TLS software stack. Please
not that this is illustrative, non-functional pseudo code that does note that this is illustrative, non-functional pseudo code that does
not compile. Functioning proof-of-concept code is available on the not compile.
following public repository [[ EDITOR'S NOTE: Add the URL here ]].
A.1. OpenSSL A.1. OpenSSL
OpenSSL provides a set of Basic Input/Output (BIO) APIs that can be OpenSSL provides a set of Basic Input/Output (BIO) APIs that can be
used to build a custom transport layer for TLS connections. This used to build a custom transport layer for TLS connections. This
appendix gives pseudo code on how BIO APIs could be used to build a appendix gives pseudo code on how BIO APIs could be used to build a
client application that completes a TLS handshake and exchanges client application that completes a TLS handshake and exchanges
application data with a service. application data with a service.
char inbound[MAX]; char inbound[MAX];
skipping to change at page 38, line 5 skipping to change at page 36, line 5
if (res.getHandshakeStatus() == NEED_TASK) { if (res.getHandshakeStatus() == NEED_TASK) {
Runnable run = sslEngine.getDelegatedTask(); Runnable run = sslEngine.getDelegatedTask();
run.run(); run.run();
} }
} }
// outbound ByteBuffer now contains a complete server flight // outbound ByteBuffer now contains a complete server flight
// containing multiple TLS Records // containing multiple TLS Records
// Rinse and repeat! // Rinse and repeat!
Appendix B. Example ATLS Handshake Appendix B. ATLS and HTTP CONNECT
[[ EDITOR'S NOTE: For completeness, include a simple full TLS It is worthwhile comparing and contrasting ATLS with HTTP CONNECT
handshake showing the raw binary flights, along with the HTTP tunneling.
request/response/headers. And also the raw hex TLS records showing
protocol bits ]] First, let us introduce some terminology:
o HTTP Proxy: A HTTP Proxy operates at the application layer,
handles HTTP CONNECT messages from clients, and opens tunnels to
remote origin servers on behalf of clients. If a client
establishes a tunneled TLS connection to the origin server, the
HTTP Proxy does not attempt to intercept or inspect the HTTP
messages exchanged between the client and the server
o middlebox: A middlebox operates at the transport layer, terminates
TLS connections from clients, and originates new TLS connections
to services. A middlebox inspects all messages sent between
clients and services. Middleboxes are generally completely
transparent to applications, provided that the necessary PKI root
Certificate Authority is installed in the client's trust store.
HTTP Proxies and middleboxes are logically separate entities and one
or both of these may be deployed in a network.
HTTP CONNECT is used by clients to instruct a HTTP Forward Proxy
deployed in the local domain to open up a tunnel to a remote origin
server that is typically deployed in a different domain. Assuming
that TLS transport is used between both client and proxy, and proxy
and origin server, the network architecture is as illustrated in
Figure 16. Once the proxy opens the transport tunnel to the service,
the client establishes an end-to-end TLS session with the service,
and the proxy is blindly transporting TLS records (the C->S TLS
session records) between the client and the service. From the client
perspective, it is tunneling a TLS session to the service inside the
TLS session it has established to the proxy (the C->P TLS session).
No middlebox is attempting to intercept or inspect the HTTP messages
between the client and the service.
+----------+ +----------+
| C->S HTTP| | C->S HTTP|
+----------+ +----------+
| C->S TLS | | C->S TLS |
+----------+ +----------+
| C->P TLS | | P->S TCP |
+----------+ +----------+
| C->P TCP |
+----------+
+--------+ +------------+ +---------+
| Client |----->| HTTP Proxy |----->| Service |
+--------+ +------------+ +---------+
Figure 16: HTTP Proxy transport layers
A more complex network topology where the network operator has both a
HTTP Proxy and a middlebox deployed is illustrated in Figure 17. In
this scenario, the proxy has tunneled the TLS session from the client
towards the origin server, however the middlebox is intercepting and
terminating this TLS session. A TLS session is established between
the client and the middlebox (C->M TLS), and not end-to-end between
the client and the server. It can clearly be seen that HTTP CONNECT
and HTTP Proxies serve completely different functions than
middleboxes.
Additionally, the fact that the TLS session is established between
the client and the middlebox can be problematic for two reasons:
o the middle box is inspecting traffic that is sent between the
client and the service
o the client may not have the necessary PKI root Certificate
Authority installed that would enable it to validate the TLS
connection to the middlebox. This is the scenario outlined in
Section 3.2.
+----------+ +----------+ +----------+
| C->S HTTP| | C->S HTTP| | C->S HTTP|
+----------+ +----------+ +----------+
| C->M TLS | | C->M TLS | | M->S TLS |
+----------+ +----------+ +----------+
| C->P TLS | | P->M TCP | | M->S TCP |
+----------+ +----------+ +----------+
| C->P TCP |
+----------+
+--------+ +------------+ +-----------+ +---------+
| Client |----->| HTTP Proxy |----->| Middlebox |----->| Service |
+--------+ +------------+ +-----------+ +---------+
Figure 17: HTTP Proxy and middlebox transport layers
As HTTP CONNECT can be used to establish a tunneled TLS connection,
one hypothetical solution to this middlebox issue is for the client
to issue a HTTP CONNECT command to a HTTP Reverse Proxy deployed in
front of the origin server. This solution is not practical for
several reasons:
o if there is a local domain HTTP Forward Proxy deployed, this would
result in the client doing a first HTTP CONNECT to get past the
Forward Proxy, and then a second HTTP CONNECT to get past the
Reverse Proxy. No client or client library supports the concept
of HTTP CONNECT inside HTTP CONNECT.
o if there is no local domain HTTP Proxy deployed, the client still
has to do a HTTP CONNECT to the HTTP Reverse Proxy. This breaks
with standard and expected HTTP CONNECT operation, as HTTP CONNECT
is only ever called if there is a local domain proxy.
o clients cannot generate CONNECT from XHR in web applications.
o this would require the deployment of a Reverse Proxy in front of
the origin server, or else support of the HTTP CONNECT method in
standard web frameworks. This is not an elegant design.
o using HTTP CONNECT with HTTP 1.1 to a Reverse Proxy will break
middleboxes inspecting HTTP traffic, as the middlebox would see
TLS records when it expects to see HTTP payloads.
In contrast to trying to force HTTP CONNECT to address a problem for
which it was not designed to address, and having to address all the
issues just outlined; ATLS is specifically designed to address the
middlebox issue in a simple, easy to develop, and easy to deploy
fashion.
o ATLS works seamlessly with HTTP Proxy deployments
o no changes are required to HTTP CONNECT semantics
o no changes are required to HTTP libraries or stacks
o no additional Reverse Proxy is required to be deployed in front of
origin servers
It is also worth noting that if HTTP CONNECT to a Reverse Proxy were
a conceptually sound solution, the solution still ultimately results
in encrypted traffic traversing the middlebox that the middlebox
cannot intercept and inspect. That is ultimately what ATLS results
in - traffic traversing the middle box that the middlebox cannot
intercept and inspect. Therefore, from a middlebox perspective, the
differences between the two solutions are in the areas of solution
complexity and protocol semantics. It is clear that ATLS is a
simpler, more elegant solution that HTTP CONNECT.
Appendix C. Alternative Approaches to Application Layer End-to-End Appendix C. Alternative Approaches to Application Layer End-to-End
Security Security
End-to-end security at the application layer is increasing seen as a End-to-end security at the application layer is increasing seen as a
key requirement across multiple applications and services. Some key requirement across multiple applications and services. Some
examples of end-to-end security mechanisms are outlined here. All examples of end-to-end security mechanisms are outlined here. All
the solutions outlined here have some common characteristics. The the solutions outlined here have some common characteristics. The
solutions: solutions:
 End of changes. 47 change blocks. 
340 lines changed or deleted 334 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/