| Network Working Group | O. Friel |
| Internet-Draft | R. Barnes |
| Intended status: Standards Track | M. Pritikin |
| Expires: September 12, 2019 | Cisco |
| H. Tschofenig | |
| ARM Limited | |
| M. Baugher | |
| Consultant | |
| March 11, 2019 |
Application-Layer TLS
draft-friel-tls-atls-02
This document specifies how TLS sessions can be established at the application layer over untrusted transport between clients and services for the purposes of establishing secure end-to-end encrypted communications channels. Transport layer encodings for application layer TLS records are specified for HTTP and CoAP transport. Explicit identification of application layer TLS packets enables middleboxes to provide transport services and enforce suitable transport policies for these payloads, without requiring access to the unencrypted payload content. Multiple scenarios are presented identifying the need for end-to-end application layer encryption between clients and services, and the benefits of reusing the well-defined TLS protocol, and a standard TLS stack, to accomplish this are described. Application software architectures for building, and network architectures for deploying application layer TLS are outlined.
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 September 12, 2019.
Copyright (c) 2019 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.
There are multiple scenarios where there is a need for application layer end-to-end security between clients and application services. Two examples include:
These two scenarios are described in more detail in Section 3.
This document describes how clients and applications can leverage standard TLS software stacks to establish secure end-to-end encrypted connections at the application layer. The connections may establish TLS [RFC5246] [I-D.ietf-tls-tls13] or DTLS [RFC6347] [I-D.ietf-tls-dtls13] sessions. There are multiple advantages to reuse of existing TLS software stacks for establishment of application layer secure connections. These include:
This document also explicitly defines how application layer TLS connections can be established using HTTP [RFC7230] [RFC7540] or CoAP as transport layers. This document does not preclude the use of other transport layers. However, defining how application layer TLS connections can be established over other transport layers, such as [ZigBee] or [Bluetooth], is beyond the scope of this document.
Explicitly identifying application layer TLS packets enables transport layer middleboxes to provide transport capabilities and enforce suitable transport policies for these payloads, without requiring access to unencrypted application data.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Application layer TLS is referred to as ATLS throughout this document.
This section describes in more detail the bootstrapping and constrained device use cases mentioned in the introduction.
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.
Two constrained device use cases are outlined here.
There are industry examples of home smart lighting systems where the smart light bulbs connect using ZigBee to a gateway device. A controller application running on a mobile device connects to the gateway using CoAP over DTLS. The controller can then control the light bulbs by sending messages and commands via the gateway. The gateway device has full access to all messages sent between the light bulbs and the controller application.
A generic use case similar to the smart lighting system outlined above has an IoT device talking ZigBee to a gateway, with the gateway in turn talking CoAP over DTLS to a controller application running on a mobile device. This is illustrated in Figure 2.
There are scenarios where the messages sent between the IoT device and the controller application must not be exposed to the gateway function. Additionally, the end devices (the IoT device and the controller application service) have no visibility to and no guarantees about what transport layer security and encryption is enforced across all hops end-to-end as they only have visibility to their immediate next hop. ATLS addresses these concerns.
+--------+ ZigBee +---------+ CoAP/DTLS +------------+
| Device |-------------->| Gateway |------------->| Mobile App |
+--------+ +---------+ +------------+
^ ^
| |
+--------Device to Mobile App ATLS Connection-------+
Figure 2: IoT Closed Network Gateway
In this example an IoT device connecting to a gateway using a suitable transport mechanism, such as ZigBee, CoAP, MQTT, etc. The gateway function in turn talks HTTP over TLS (or, for example, HTTP over QUIC) to an application service over the Internet. This is illustrated in Figure 3.
The gateway may not be trusted and all messages between the IoT device and the application service must be end-to-end encrypted. Similar to the previous use case, the endpoints have no guarantees about what level of transport layer security is enforced across all hops. Again, ATLS addresses these concerns.
+--------+ CoAP/DTLS +------------------+ HTTP/TLS +---------+
| Device |-------------->| Internet Gateway |------------>| Service |
+--------+ +------------------+ +---------+
^ ^
| |
+---------Device to Cloud Service ATLS Connection----------+
Figure 3: IoT Internet Gateway
End-to-end security at the application layer is increasing seen as a key requirement across multiple applications and services. Some examples of end-to-end security mechanisms are outlined here. All the solutions outlined here have some common characteristics. The solutions:
[Noise] is a framework for cryptographic protocols based on Elliptic Curve Diffie-Hellman (ECDH) key agreement, AEAD encryption, and BLAKE2 and SHA2 hash functions. Noise is currently used by WhatsApp, WireGuard, and Lightning.
The current Noise protocol framework defines mechanisms for proving possession of a private key, but does not define authentication mechanisms. Section 14 “Security Considerations” of Noise states: ~~~ it’s up to the application to determine whether the remote party’s static public key is acceptable ~~~
The [Signal] protocol provides end-to-end encryption and uses EdDSA signatures, Triple Diffie-Hellman handshake for shared secret establishment, and the Double Ratchet Algorithm for key management. It is used by Open Whisper Systems, WhatsApp and Google.
Similar to Noise, Signal does not define an authentication mechanism. The current [X3DH] specification states in Section 4.1 “Authentication”:
Methods for doing this are outside the scope of this document
Google’s Application Layer Transport Security [ALTS] is a mutual authentication and transport encryption system used for securing Remote Procedure Call (RPC) communications within Google’s infrastructure. ALTS uses an ECDH handshake protocol and a record protocol containing AES encrypted payloads.
There is ongoing work to standardise [I-D.selander-ace-cose-ecdhe], whiich defines a SIGMA-I based authenticated key exchange protocol using COSE and CBOR.
The high level goals driving the design of this mechanism are:
TLS software stacks allow application developers to ‘unplug’ the default network socket transport layer and read and write TLS records directly from byte buffers. This enables application developers to create application layer TLS sessions, extract the raw TLS record bytes from the bottom of the TLS stack, and transport these bytes over any suitable transport. The TLS software stacks can generate byte streams of full TLS flights which may include multiple TLS records. Additionally, TLS software stacks support Keying Material Exporters [RFC5705] and allow applications to export keying material from established TLS sessions. This keying material can then be used by the application for encryption of data outside the context of the TLS session. This is illustrated in Figure 4 below.
+------------+ +---------+
Handshake Records | | Handshake Records | |
------------------->| |------------------->| |
| | | Byte |
Unencrypted Data | TLS | Encrypted Data | |
------------------->| |------------------->| Buffers |
| Software | | |
Encrypted Data | | Unencrypted Data | |
------------------->| Stack |------------------->| |
| | +---------+
Keying Material | |
<-------------------| |
+ -----------+
Figure 4: TLS Stack Interfaces
These TLS software stack APIs enable application developers to build the software architectures illustrated in Figure 5 and Figure 6.
In both architectures, the application creates and interacts with an application layer TLS session in order to generate and consume raw TLS records. The application transports these raw TLS records inside transport layer message bodies using whatever standard transport layer stack is suitable for the application or architecture. This document does not place any restrictions on the choice of transport layer and any suitable protocol such as HTTP, TCP, CoAP, ZigBee, Bluetooth, etc. could be used.
The transport layer will typically encrypt data, and this encryption is completely independent from any application layer encryption. The transport stack may create a transport layer TLS session. The application layer TLS session and transport layer TLS session can both leverage a shared, common TLS software stack. This high level architecture is applicable to both clients and application services. The key differences between the architectures are as follows.
In the model illustrated in Figure 5, the application sends all sensitive data that needs to be securely exchanged with the peer application through the Application TLS session in order to be encrypted and decrypted. All sensitive application data is thus encoded within TLS records by the TLS stack, and these TLS records are transmitted over the transport layer.
+-------------+ | | App | | Data +---------+ | Application |<---------->| App | +---------+ | | TLS | TLS |----->| TLS | | | Records | Session | | Stack | | +--->|<---------->| | +---------+ | | | +---------+ ^ | | | |? | | | Transport +-----------+ +------------+ | | | Payload | Transport | | Transport | | +--->|<--------->| Stack |--->| Encryption |-->Packets +-------------+ +-----------+ +------------+
Figure 5: TLS Stack used for all data encryption
In the model illustrated in Figure 6, the application establishes an application layer TLS session purely for the purposes of key exchange. Therefore, the only TLS records that are sent or received by the application layer are TLS handshake records. Once the application layer TLS session is established, the application uses Keying Material Exporter [RFC5705] APIs to export keying material from the TLS stack from this application layer TLS session. The application can then use these exported keys to derive suitable shared encryption keys with its peer for exchange of encrypted data. The application encrypts and decrypts sensitive data using these shared encryption keys using any suitable cryptographic library (which may be part of the same library that provides the TLS stack), and transports the encrypted data directly over the transport layer.
+--------------+ | | | Application | | | | +-------+ | +---------+ | | App | | Key Export | | | | Data |<---|<-----------| | | | Crypto| | | App | | +-------+ | TLS | TLS | +---------+ | ^ | Handshake | Session |----->| TLS | | | | Records | | | Stack | | | +--->|<---------->| | +---------+ | | | | +---------+ ^ | | | | |? | | | | Transport +-----------+ +------------+ | | | | Payload | Transport | | Transport | | +----+--->|<--------->| Stack |--->| Encryption |-->Packets +--------------+ +-----------+ +------------+
Figure 6: TLS stack used for key agreement and exporting
The choice of which application architecture to use will depend on the overall solution architecture, and the underlying transport layer or layers in use. While the choice of application architecture is outside the scope of this document, some considerations are outlined here.
There are several benefits to using a standard TLS software stack to establish an application layer secure communications channel between a client and a service. These include:
It is recommended that ATLS packets are explicitly identified by a standardized, transport-specific identifier enabling any gateways and middleboxes to identify ATLS packets. Middleboxes have to contend with a vast number of applications and network operators have difficulty configuring middleboxes to distinguish unencrypted but not explicitly identified application data from end-to-end encrypted data. This specification aims to assist network operators by explicitly identifying ATLS packets. The HTTP and CoAP encodings documented in Section 9 and Section 10 explicitly identify ATLS packets.
The ATLS application service establishes multiple ATLS sessions with multiple clients. As TLS sessions are stateful, the application service must be able to correlate ATLS records from different clients across the relevant ATLS sessions. The details of how session tracking is implemented are outside the scope of this document. Recommendations are given in Section 9 and Section 10, but session tracking is application and implementation specific.
It should not be necessary for the application layer to have to inspect, parse or understand the contents of ATLS records. No constraints are placed on the ContentType contained within the transported TLS records. The TLS records may contain handshake, application_data, alert or change_cipher_spec messages. If new ContentType messages are defined in future TLS versions, these may also be transported using this protocol.
Pseudo code illustrating how to read and write TLS records directly from byte buffers using both OpenSSL BIO functions and Java JSSE SSLEngine is given in the appendices. A blog post by [Norrell] outlines a similar approach to leveraging OpenSSL BIO functions, and Oracle publish example code for leveraging [SSLEngine].
The functional design assumes that an authorization system has established operational keys for authenticating endpoints. In a layered design, this needs to be done for each layer, which may operate in two separate authorization domains. Note that Figure 7 shows a generic setup where TLS/DTLS is used at two layers. In some cases, use of TLS/DTLS at the application layer may be sufficient where lower layer security mechanisms provide protection of the transport-specific headers.
+-------------------------------------------------------+
| +---+ +---+ |
| +--------+ |APP| |APP| +--------+ |
| |security| +---+ +---+ |security| |
| |--------+ ^ ^ |--------+ |
| |policies| | | |policies| |
| |LAYER 0 | | | |LAYER 0 | |
| +--------+ v v +--------+ |
| + +------+ APP +------+ + |
| | | TLS- |<--------->| TLS- | | |
| +----->|SERVER| LAYER |CLIENT|<-----+ |
| +------+ +------+ |
| TOP LAYER ^ ^ |
+-----------------|-------------------|-----------------+
| BOTTTOM LAYER | | |
| v v |
| +------+ TRANSPORT +------+ |
| | TLS- |<--------->| TLS- | |
| +--------+ |SERVER| LAYER |CLIENT| +--------+ |
| |security| +------+ +------+ |security| |
| |--------+ ^ ^ |--------+ |
| |policies| | | |policies| |
| |LAYER 1 +-----+ +-----+LAYER 1 | |
| +--------+ +--------+ |
| |
+-------------------------------------------------------+
Figure 7: Functional Design
The security policies of one layer are distinct from those of another in Figure 7. They may overlap, but that is not necessary or perhaps even likely since the key exchanges at the different layers terminate at different endpoints and the two often have different authorization domains.
TLS can protect IoT device-to-gateway communications “on the wire” using the “bottom layer” of Figure 7, and it can protect application data from the device to the application server using the “top layer.” Application and transport security each have a role to play. Transport security restricts access to messages on the networks, notably application headers and application-layer TLS restricts access to the application payloads.
As shown in Figure 7, an application-layer message, which gets encrypted and integrity protected and, in the generic case, the the resulting TLS message and headers are passed to a TLS socket at the bottom layer, which may have a different security policy than the application layer.
An example network deployment is illustrated in Figure 8. It shows a constrained client connecting to an application service via an internet gateway. The client uses CoAP over DTLS to communicate with the gateway. The gateway extracts the messages the client sent over CoAP and sends these messages inside HTTP message bodies to the application service. It also shows a TLS terminator deployed in front of the application service. The client establishes a transport layer CoAP/DTLS connection with the gateway (C->G DTLS), the gateway in turn opens a transport layer TLS connection with the TLS terminator deployed in front of the service (G->T TLS). The client can ignore any certificate validation errors when it connects to the gateway. CoAP messages are transported between the client and the gateway, and HTTP messages are transported between the client and the service. Finally, application layer TLS messages are exchanged inside the CoAP and HTTP message bodies in order to establish an end-to-end TLS session between the client and the service (C->S TLS).
+----------+ +----------+
| App Data | | App Data |
+----------+ +----------+ +----------+
| C->S TLS | | C->S TLS | | App Data |
+----------+ +----------+ +----------+
| CoAP | | HTTP | | C->S TLS |
+----------+ +----------+ +----------+
| C->G DTLS| | M->T TLS | | HTTP |
+----------+ +----------+ +----------+
| UDP | | TCP | | TCP |
+----------+ +----------+ +----------+
+--------+ +-----------+ +----------------+ +---------+
| Client |----->| Gateway |----->| TLS Terminator |---->| Service |
+--------+ +-----------+ +----------------+ +---------+
^ ^
| |
+-------------Client to Service ATLS Connection-------------+
Figure 8: Constrained Device Gateway Network Architecture
Another typical network deployment is illustrated in Figure 9. It shows a client connecting to a service via a middlebox. It also shows a TLS terminator deployed in front of the service. The client establishes a transport layer TLS connection with the middlebox (C->M TLS), the middlebox in turn opens a transport layer TLS connection with the TLS terminator deployed in front of the service (M->T TLS). The client can ignore any certificate validation errors when it connects to the middlebox. HTTP messages are transported over this layer between the client and the service. Finally, application layer TLS messages are exchanged inside the HTTP message bodies in order to establish an end-to-end TLS session between the client and the service (C->S TLS).
+----------+ +----------+
| App Data | | App Data |
+----------+ +----------+ +----------+
| C->S TLS | | C->S TLS | | App Data |
+----------+ +----------+ +----------+
| HTTP | | HTTP | | C->S TLS |
+----------+ +----------+ +----------+
| C->M TLS | | M->T TLS | | HTTP |
+----------+ +----------+ +----------+
| TCP | | TCP | | TCP |
+----------+ +----------+ +----------+
+--------+ +-----------+ +----------------+ +---------+
| Client |----->| Middlebox |----->| TLS Terminator |---->| Service |
+--------+ +-----------+ +----------------+ +---------+
^ ^
| |
+-------------Client to Service ATLS Connection-------------+
Figure 9: HTTP Middlebox Network Architecture
When solutions implement the architecture described in Figure 6, they leverage [RFC5705] for exporting keys. When the OSCORE mode has been agreed using the “oscore_connection_id” extension defined in this document, different keys are used for ordinary DTLS/TLS record protection and OSCORE packet protection. These keys are produced using a TLS exporter [RFC5705] and the exporter takes three input values:
The label string for use with this specification is defined as ‘application-layer-tls’. The per-association context value is empty.
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 Secret and the upper-half is used for the Master Salt.
For example, if a TLS/DTLS 1.2 handshake negotiated the TLS_PSK_WITH_AES_128_CCM_8 ciphersuite then the key size utilized by the negotiated algorithm, i.e. AES 128, is 128 bit. Hence, the key extractor is requested to produce 2 x 128 bit keying material.
The following parameters are needed for use with OSCORE:
A future version of this specification will describe how to establish keying material and parameters for security contexts other than OSCORE.
Figure 10 illustrates how an ATLS session is established using the key exporting architectural model shown in Figure 6. The number of RTTs that take place when establishing a TLS session depends on the version of TLS and what capabilities are enabled on the TLS software stack. For example, a 0-RTT exchange is possible with TLS 1.3. If applications wish to ensure a predictable number of RTTs when establishing an application layer TLS connection, this may be achieved by configuring the TLS software stack appropriately.
The outline is as follows:
+-------------------------------+ +-------------------------------+
| Client | | ATLS Server |
+---------+---+-----+-+---------+ +---------+--+-----+--+---------+
| ATLS | | App | |Transport| |Transport| | App | | ATLS |
| Session | +-----+ | Stack | | Stack | +-----+ | Session |
+---------+ | +---------+ +---------+ | +---------+
| | | | | |
| | | | | |
| | | | | |
| Create | | | | |
| Session | | | | |
+ |<---------| | | | |
| | Start | | | | |
| | Handshake| | | | |
| |<---------| | | | |
| | TLS | | | | |
| | Records | Pack | | | |
| |--------->| Records | | | |
| |-------->| send packet | Unpack | |
R | | |------------>| Records | Create |
T | | | |--------->| Session |
T | | | | |--------->|
| | | | | TLS |
1 | | | | | Records |
| | | | |--------->|
| | | | | | TLS |
| | | | | Pack | Records |
| | | | | Records |<---------|
| | | Unpack |send response|<---------| |
| | TLS | Records |<------------| | |
| | Records |<--------| | | |
+ |<---------| | | | |
| TLS | | | | |
| Records | | | | |
+ |--------->|-------->|------------>|--------->|--------->|
| | | | | | |
| | | | | Session |
R | | | | | Up |
T | | | | |<---------|
T | | | | | TLS |
| | | | | Records |
2 |<---------|<--------|<------------|<---------|<---------|
| Session | | | | |
| | Up | | | | |
+ |--------->| | | | |
| Export | | | | Export |
| Keys | | | | Keys |
|--------->| | E2E Session | |<---------|
| |<--------|-------------|--------->| |
Figure 10: ATLS Session Establishment
The assumption is that the client will establish a transport layer connection to the server for exchange of HTTP messages. The underlying transport layer connection could be over TCP or TLS. The client will then establish an application layer TLS connection with the server by exchanging TLS records with the server inside HTTP message request and response bodies.
All ATLS records are transported unmodified as binary data within HTTP message bodies. The application simply extracts the TLS records from the TLS stack and inserts them directly into HTTP message bodies. Each message body contains a full TLS flight, which may contain multiple TLS records.
The client sends all ATLS records to the server in the bodies of POST requests.
The server sends all ATLS records to the client in the bodies of 200 OK responses to the POST requests.
The URI path used by ATLS is “/.well-known/atls”.
A new Content-Type header value is defined:
Content-type: application/atls
All message bodies containing ATLS records must set this Content-Type. This enables middleboxes to readily identify ATLS payloads.
This document does not define any new HTTP status codes, and does not specify additional semantics or refine existing semantics for status codes. This is the best current practice as outlined in [I-D.ietf-httpbis-bcp56bis].
The application service needs to track multiple client application layer TLS sessions so that it can correlate TLS records received in HTTP message bodies with the appropriate TLS session. The application service should use stateful cookies [RFC6265] in order to achieve this as recommended in [I-D.ietf-httpbis-bcp56bis].
It is recommended that applications using ATLS over HTTP transport only use ATLS for session establishment and key exchange, resulting in only 2 ATLS RTTs between the client and the application service.
Key exporting must be carried out as described in Section 7.
A client initiates an ATLS session by sending the first TLS flight in a POST request message body to the ATLS server.
POST /.well-known/atls Content-Type: application/atls <binary TLS client flight 1 records>
The server handles the request, creates an ATLS session object, and replies by including its first TLS flight in a 200 OK message body. The server also sets a suitable cookie for session tracking purposes.
200 OK Content-Type: application/atls Set-Cookie: my-atls-cookie=my-cookie-value <binary TLS server flight 1 records>
The client handles the server first flight TLS records and replies with its second flight.
POST /.well-known/atls Content-Type: application/atls Cookie: my-atls-cookie=my-cookie-value <binary TLS client flight 2 records>
The server handles the second flight, establishes the ATLS session, and replies with its second flight.
200 OK Content-Type: application/atls <binary TLS server flight 2 records>
It is worthwhile comparing and contrasting ATLS with HTTP CONNECT tunneling.
First, let us introduce some terminology:
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 11. 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 11: 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 12. 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:
+----------+ +----------+ +----------+
| 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 12: 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:
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.
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.
To carry TLS messages over CoAP 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 13: 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.
This document defines the “oscore_connection_id” extension, which is used in ClientHello and ServerHello messages. It is used only for establishing the client’s OSCORE Sender ID and the server’s OSCORE Sender ID. The client’s OSCORE Sender ID maps to the CID provided by the server in the ServerHello and the server’s OSCORE Sender ID maps to the CID provided by the client in the ClientHello.
The negotiation mechanism follows the procedure used in [I-D.ietf-tls-dtls-connection-id] with the exception that the negotiated CIDs agreed with the “oscore_connection_id” extension is only used with OSCORE and does not impact the record layer format of the DTLS/TLS payloads nor the MAC calculation used by DTLS/TLS. As such, this extension can be used with DTLS as well as with TLS when those protocols are used at the application layer.
The extension type is specified as follows.
enum { oscore_connection_id(TBD), (65535) } ExtensionType;
struct { opaque cid<0..2^8-1>; } ConnectionId;
Note: This extension allows a client and a server to determine whether an OSCORE security context should be established.
A future version of this specification may extend the negotiation capabilities.
IANA is requested to allocate an entry to the existing TLS “ExtensionType Values” registry, defined in [RFC5246], for oscore_connection_id(TBD) defined in this document.
IANA is requested to add the well-known URI ‘atls’ to the Well-Known URIs registry.
IANA is requested to add the media type ‘application/atls’ to the Media Types registry.
IANA is requested to add the media type ‘application/atls’ to the HTTP Content-Formats registry.
IANA is requested to add the media type ‘application/atls’ to the CoAP Content-Formats registry.
IANA is requested to register the “application-layer-tls” label in the TLS Extractor Label Registry to correspond to this specification.
This specification re-uses the TLS and DTLS and hence the security considerations of the respective TLS/DTLS version applies. As described in Section 6.2, implementers need to take the policy configuration into account when applying security protection at various layers of the stack even if the same protocol is used since the communiation endpoints and the security requirements are likely going to vary.
For use in the IoT environment the considerations described in [RFC7925] apply and other environments the guidelines in [RFC7525] are applicable.
This appendix gives both C and Java pseudo code illustrating how to inject and extract raw TLS records from a TLS software stack. Please not that this is illustrative, non-functional pseudo code that does not compile. Functioning proof-of-concept code is available on the following public repository [[ EDITOR’S NOTE: Add the URL here ]].
OpenSSL provides a set of Basic Input/Output (BIO) APIs that can be 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 client application that completes a TLS handshake and exchanges application data with a service.
char inbound[MAX];
char outbound[MAX];
int rx_bytes;
SSL_CTX *ctx = SSL_CTX_new();
SSL *ssl = SSL_new(ctx);
// Create in-memory BIOs and plug in to the SSL session
BOI* bio_in = BIO_new(BIO_s_mem());
BOI* bio_out = BIO_new(BIO_s_mem());
SSL_set_bio(ssl, bio_in, bio_out);
// We are a client
SSL_set_connect_state(ssl);
// Loop through TLS flights until we are done
do {
// Calling SSL_do_handshake() will result in a full
// TLS flight being written to the BIO buffer
SSL_do_handshake(ssl);
// Read the client flight that the TLS session
// has written to memory
BIO_read(bio_out, outbound, MAX);
// POST the outbound bytes to the server using a suitable
// function. Lets assume that the server response will be
// written to the 'inbound' buffer
num_bytes = postTlsRecords(outbound, inbound);
// Write the server flight to the memory BIO so the TLS session
// can read it. The next call to SSL_do_handshake() will handle
// this received server flight
BIO_write(bio_in, inbound, num_bytes);
} while (!SSL_is_init_finished(ssl));
// Send a message to the server. Calling SSL_write() will run the
// plaintext through the TLS session and write the encrypted TLS
// records to the BIO buffer
SSL_write(ssl, "Hello World", strlen("Hello World"));
// Read the TLS records from the BIO buffer and
// POST them to the server
BIO_read(bio_out, outbound, MAX);
num_bytes = postTlsRecords(outbound, inbound);
The Java SSLEngine class “enables secure communications using protocols such as the Secure Sockets Layer (SSL) or IETF RFC 2246 “Transport Layer Security” (TLS) protocols, but is transport independent”. This pseudo code illustrates how a server could use the SSLEngine class to handle an inbound client TLS flight and generate an outbound server TLS flight response.
SSLEngine sslEngine = SSLContext.getDefault().createSSLEngine();
sslEngine.setUseClientMode(false);
sslEngine.beginHandshake();
// Lets assume 'inbound' has been populated with
// the Client 1st Flight
ByteBuffer inbound;
// 'outbound' will be populated with the
// Server 1st Flight response
ByteBuffer outbound;
// SSLEngine handles one TLS Record per call to unwrap().
// Loop until the engine is finished unwrapping.
while (sslEngine.getHandshakeStatus() ==
HandshakeStatus.NEED_UNWRAP) {
SSLEngineResult res = sslEngine.unwrap(inbound, outbound);
// SSLEngine may need additional tasks run
if (res.getHandshakeStatus() == NEED_TASK) {
Runnable run = sslEngine.getDelegatedTask();
run.run();
}
}
// The SSLEngine has now finished handling all inbound TLS Records.
// Check if it wants to generate outbound TLS Records. SSLEngine
// generates one TLS Record per call to wrap().
// Loop until the engine is finished wrapping.
while (sslEngine.getHandshakeStatus() ==
HandshakeStatus.NEED_WRAP) {
SSLEngineResult res = sslEngine.wrap(inbound, outbound);
// SSLEngine may need additional tasks run
if (res.getHandshakeStatus() == NEED_TASK) {
Runnable run = sslEngine.getDelegatedTask();
run.run();
}
}
// outbound ByteBuffer now contains a complete server flight
// containing multiple TLS Records
// Rinse and repeat!
[[ EDITOR’S NOTE: For completeness, include a simple full TLS handshake showing the raw binary flights, along with the HTTP request/response/headers. And also the raw hex TLS records showing protocol bits ]]