]> Universität Bremen TZI

Bremen, D-28359 Germany bergmann@tzi.org

Ericsson AB

SE-164 80 Stockholm Sweden john.mattsson@ericsson.com

Ericsson AB

SE-164 80 Stockholm Sweden goran.selander@ericsson.com

ACE Working Group This document updates the CoAP-DTLS profile for ACE described in RFC 9202 by specifying that the profile applies to TLS as well as DTLS.

Introduction only specifies the use of DTLS but works equally well for TLS . For many constrained implementations, CoAP over UDP is the first choice, but when deploying ACE in networks controlled by other entities (such as the Internet), UDP might be blocked on the path between the client and the RS, and the client might have to fall back to CoAP over TCP for NAT or firewall traversal. This dual support for security over TCP as well as UDP is already supported by the OSCORE profile . This document updates by specifying that the profile applies to TLS as well as DTLS. It only impacts the transport layer security channel between Client and Resource Server. The same access rights are valid in case transport layer security is provided by either DTLS or TLS. The same access token can be used by either DTLS or TLS between a given (Client, RS) pair. Therefore, the value coap_dtls in the ace_profile parameter of an AS-to-Client response or in the ace_profile claim of an access token indicates that either DTLS or TLS can be used for transport layer security.

Terminology 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 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts described in and .

Specific Changes to RFC 9202 The main changes to specified in this document are limited to replacing "DTLS" with "DTLS/TLS" throughout the document. This essentially impacts the use of secure transport as described in the sections 3.2.2, 3.3.2, 4, and 5. In addition to this, the Client and Resource Server behavior is updated to describe the case where either or both DTLS and TLS may be available, as described in the following section.

Connection Establishment Following the procedures defined in , a Client can retrieve an Access Token from an Authorization Server (AS) in order to establish a security association with a specific Resource Server. The ace_profile parameter in the Client-to-AS request and AS-to-client response is used to determine the ACE profile that the Client uses towards the Resource Server (RS). The ace_profile parameter indicates the use of the DTLS profile for ACE as defined in . Therefore, the Client typically first tries using DTLS to connect to the Resource Server. If this fails the Client MAY try to connect to the Resource Server via TLS. The client can try TLS and DTLS in parallel to accelerate the connection setup. It is up to the implementation to handle the case where the RS reponds to both connection requests. As resource-constrained devices are not expected to support both transport layer security mechanisms. Clients and Resource Servers SHOULD support DTLS and MAY support TLS. A Client that implements either TLS or DTLS but not both might fail in establishing a secure communication channel with the Resource Server altogether. Note that a communication setup with an a priori unknown Resource Server typically employs an initial unauthorized resource request as illustrated in Section 2 of . If this message exchange succeeds, the Client SHOULD first use the same underlying transport protocol also for the establishment of the security association to RS (i.e., DTLS for UDP, and TLS for TCP). As a consequence, the selection of the transport protocol used for the initial unauthorized resource request also depends on the transport layer security mechanism supported by the Client. Clients that support either DTLS or TLS but not both SHOULD use the transport protocol underlying the supported transport layer security mechanism also for an initial unauthorized resource request to the RS as in Section 2 of .

IANA Considerations The following updates have been done to the "ACE Profiles" registry for the profile with a "CBOR Value" field value of 1 and "Name" of "coap_dtls": Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph. Description: Profile for delegating client Authentication and Authorization for Constrained Environments by establishing a Datagram Transport Layer Security (DTLS) or Transport Layer Security (TLS) channel between resource-constrained nodes. Change Controller: IESG Reference: [RFC9202] [RFC-XXXX]

Security Considerations The security consideration and requirements in , TLS 1.3 , and BCP 195 also apply to this document.

References Normative References The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. This specification defines a profile of the Authentication and Authorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 or later for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource-constrained server can use this protocol to delegate management of authorization information to a trusted host with less-severe limitations regarding processing power and memory. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance. This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1. This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195. This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.

Acknowledgments The authors would like to thank Marco Tiloca for reviewing this specification.