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 by specifying that the profile applies to TLS as well as DTLS. Discussion Venues Discussion of this document takes place on the Authentication and Authorization for Constrained Environments Working Group mailing list (ace@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

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 feature is supported by the OSCORE profile but is lacking in the DTLS profile. This document updates by specifying that the profile applies to TLS as well as DTLS. The same access rights are valid in case transport layer security is provided by either DTLS or TLS, and the same access token can be used. 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 .

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). In case the ace_profile parameter indicates the use of the DTLS profile for ACE as defined in , the Client MAY try to connect to the Resource Server via TLS, or try TLS and DTLS in parallel to accelerate the session setup. As resource-constrained devices are not expected to support both transport layer security mechanisms, a Client that implements either TLS or DTLS but not both might fail in establishing a secure communication channel with the Resource Server altogether. This error SHOULD be handled by the Client in the same way as unsupported ACE profiles. If the Client is modified accordingly or it learns that the Resource Server has been, the Client may try to connect to the Resource Server using the transport layer security mechanism that was previously not mutually supported. 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 for the establishment of the security association as well (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.

IANA Considerations The following updates have been done for the "ACE Profiles" registry for the profile with Profile ID 1 and Profile name 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: [RFC-XXXX]

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

References Normative References This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK] 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. Combitech Ericsson Spotify AB Arm Ltd. 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. Universität Bremen TZI Universität Bremen TZI Universität Bremen TZI Ericsson AB Combitech This specification defines a profile of the ACE framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 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 Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases. 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. Ericsson AB Combitech Ericsson AB RISE 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.

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