]> RISE AB

Isafjordsgatan 22 Kista 16440 Sweden marco.tiloca@ri.se

Ericsson AB

Torshamnsgatan 23 Kista 16440 Stockholm Sweden john.mattsson@ericsson.com

Security ACE Working Group Internet-Draft This document updates the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE). In particular, it specifies the use of additional formats of authentication credentials for establishing a DTLS session, when peer authentication is based on asymmetric cryptography. Therefore, this document updates RFC 9202. What is defined in this document is seamlessly applicable also if the profile uses Transport Layer Security (TLS) instead. 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 The Authentication and Authorization for Constrained Environments (ACE) framework defines an architecture to enforce access control for constrained devices. A Client (C) requests an evidence of granted permissions from an Authorization Server (AS) in the form of an access token, then uploads the access token to the target Resource Server (RS), and finally accesses protected resources at the RS according to what is specified in the access token. The framework has as main building blocks the OAuth 2.0 framework , the Constrained Application Protocol (CoAP) for message transfer, CBOR for compact encoding, and COSE for self-contained protection of access tokens. Separate profile documents define in detail how the participants in the ACE architecture communicate, especially as to the security protocols that they use. In particular, the ACE profile defined in specifies how Datagram Transport Layer Security (DTLS) is used to protect communications with transport-layer security in the ACE architecture. The profile has also been extended in , in order to allow the alternative use of Transport Layer Security (TLS) when CoAP is transported over TCP or WebSockets . The DTLS profile allows C and RS to establish a DTLS session with peer authentication based on symmetric or asymmetric cryptography. For the latter case, the profile defines an RPK mode (see ), where authentication relies on the public keys of the two peers as raw public keys . That is, C specifies its public key to the AS when requesting an access token, and the AS provides such public key to the target RS as included in the issued access token. Upon issuing the access token, the AS also provides C with the public key of the RS. Then, C and RS use their asymmetric keys when performing the DTLS handshake, as defined in . Per , the DTLS profile admits only a COSE Key object as the format of authentication credentials to use for transporting the public keys of C and RS, as raw public keys. However, it is desirable to enable additional types of authentication credentials, as enhanced raw public keys or as public certificates. This document enables such additional formats, by defining how the public keys of C and RS can be specified as CBOR Web Token (CWT) Claims Sets (CCSs) , or X.509 certificates , or C509 certificates . In particular, this document updates as follows.

• It extends the RPK mode defined in , by enabling the use of CCSs to transport the raw public keys of C and RS (see ).
• It defines a new certificate mode, which enables the transport of the public keys of C and RS as X.509 or C509 certificates (see ).

When using the updated RPK mode, both public keys can be transported as a CCS, or instead only one can be transported as a CCS while the other one as a COSE Key object. Also, the RPK mode and the certificate mode can be combined. That is, it is possible that one of the two authentication credentials is a public certificate, while the other one is a raw public key. These updates to the DTLS profile rely on the CWT Confirmation Methods "kccs", "x5bag", "x5chain", "c5b", and "c5c", which are defined in . What is defined in this document is seamlessly applicable if TLS is used instead, as defined in .

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 the ACE framework for Authentication and Authorization and its DTLS profile , as well as with terms and concepts related to CBOR Web Tokens (CWTs) and CWT Confirmation Methods . The terminology for entities in the considered architecture is defined in OAuth 2.0 . In particular, this includes Client (C), Resource Server (RS), and Authorization Server (AS). Readers are also expected to be familiar with the terms and concepts related to the CoAP protocol , CBOR , COSE , the DTLS protocol suite , and the use of raw public keys in DTLS . Note that, unless otherwise indicated, the term "endpoint" is used here following its OAuth definition, aimed at denoting resources such as /token and /introspect at the AS, and /authz-info at the RS. This document does not use the CoAP definition of "endpoint", which is "An entity participating in the CoAP protocol." This document also refers to the term "authentication credential", which denotes the information associated with an entity, including that entity's public key and parameters associated with the public key. Examples of authentication credentials are CWT Claims Sets (CCSs) , X.509 certificates , and C509 certificates . Examples throughout this document are expressed in CBOR diagnostic notation without the tag and value abbreviations.

Updates to the RPK Mode The rest of this section updates , by defining how the raw public key of C and RS can be transported as a CCS , as an alternative to a COSE Key object . Note that only the differences from are compiled below. If the raw public key of C is transported as a CCS, the following applies.

• The payload of the Access Token Request (see ) is as defined in , with the difference that the "req_cnf" parameter MUST specify a "kccs" structure, with value a CCS specifying the public key of C.
• The content of the access token that the AS provides to C in the Access Token Response (see ) is as defined in , with the difference that the "cnf" claim of the access token MUST specify a "kccs" structure, with value a CCS specifying the public key of C.

If the raw public key of RS is transported as a CCS, the following applies.

• The payload of the Access Token Response is as defined in , with the difference that the "rs_cnf" parameter MUST specify a "kccs" structure, with value a CCS specifying the public key of RS.

For the "req_cnf" parameter of the Access Token Request, the "rs_cnf" parameter of the Access Token Response, and the "cnf" claim of the access token, the Confirmation Method "kccs" structure and its identifier are defined in . It is not required that both public keys are transported as a CCS. That is, one of the two authentication credentials can be a CCS, while the other one can be a COSE Key object as per . shows an example of Access Token Request from C to the AS.

Access Token Request Example for RPK Mode with CCS

shows an example of Access Token Response from the AS to C.

Access Token Response Example for RPK Mode with CCS

Certificate Mode This section defines a new certificate mode of the DTLS profile, which enables the transport of public keys of C and RS as public certificates. Compared to the RPK mode defined in and extended in of this document, the certificate mode displays the following differences.

• The authentication credential of C and/or RS is a public certificate, i.e., an X.509 certificate or a C509 certificate . The CWT Confimation Methods "x5chain", "x5bag", "c5c", and "c5b" defined in are used to transport such authentication credentials.
• If the authentication credential AUTH_CRED_C of C is a public certificate, the following applies.
  • The "req_cnf" parameter of the Access Token Request (see specifies AUTH_CRED_C as follows.
    • If AUTH_CRED_C is an X.509 certificate, the "req_cnf" parameter MUST specify an "x5chain" or "x5bag" structure, in case AUTH_CRED_C is conveyed in a certificate chain or a certificate bag, respectively.
    • If AUTH_CRED_C is a C509 certificate, the "req_cnf" parameter MUST specify a "c5c" or "c5b" structure, in case AUTH_CRED_C is conveyed in a certificate chain or a certificate bag, respectively.
  • The "cnf" claim of the access token that the AS provides to C in the Access Token Response (see ) specifies AUTH_CRED_C as follows.
    • If AUTH_CRED_C is an X.509 certificate, the "cnf" claim MUST specify an "x5chain" or "x5bag" structure, in case AUTH_CRED_C is conveyed in a certificate chain or a certificate bag, respectively.
    • If AUTH_CRED_C is a C509 certificate, the "cnf" claim MUST specify a "c5c" or "c5b" structure, in case AUTH_CRED_C is conveyed in a certificate chain or a certificate bag, respectively.
• If the authentication credential AUTH_CRED_RS of RS is a public certificate, the following applies.
  • The "rs_cnf" parameter of the Access Token Response specifies AUTH_CRED_RS as follows.
    • If AUTH_CRED_RS is an X.509 certificate, the "rs_cnf" parameter MUST specify an "x5chain" or "x5bag" structure, in case AUTH_CRED_RS is conveyed in a certificate chain or a certificate bag, respectively.
    • If AUTH_CRED_RS is a C509 certificate, the "rs_cnf" parameter MUST specify a "c5c" or "c5b" structure, in case AUTH_CRED_RS is conveyed in a certificate chain or a certificate bag, respectively.

For the "req_cnf" parameter of the Access Token Request, the "rs_cnf" parameter of the Access Token Response, and the "cnf" claim of the access token, the Confirmation Method "c5c" and "c5b" structures and their identifiers are defined in . When using either of the structures "x5chain", "x5bag", "c5c" and "c5b", i.e., either a chain or a bag of certificates, the specified authentication credential is just the end entity X.509 or C509 certificate. As per , a public certificate is specified in the Certificate message of the DTLS handshake. For X.509 certificates, the TLS Certificate Type is "X509", as defined in . For C509 certificates, the TLS certificate type is "C509 Certificate", as defined in . It is not required that AUTH_CRED_C and AUTH_CRED_RS are both X.509 certificates or both C509 certificates. Also, one of the two authentication credentials can be a public certificate, while the other one can be a raw public key. This is consistent with the admitted, combined use of raw public keys and certificates, as discussed in . shows an example of Access Token Request from C to the AS. In the example, C specifies its authentication credential by means of an "x5chain" structure, including only its own X.509 certificate.

Access Token Request Example for Certificate Mode with an X.509 Certificate as Authentication Credential of C

shows an example of Access Token Response from the AS to C. In the example, the AS specifies the authentication credential of RS by means of an "x5chain" structure, including only the X.509 certificate of the RS.

Access Token Response Example for Certificate Mode with an X.509 Certificate as Authentication Credential of RS

Security Considerations The security considerations from and apply to this document as well. When using public certificates as authentication credentials, the security considerations from apply. When using X.509 certificates as authentication credentials, the security considerations from , , , and apply. When using C509 certificates as authentication credentials, the security considerations from apply.

IANA Considerations This document has no actions for IANA.

References Normative References Universität Bremen TZI Ericsson AB Ericsson AB This document updates the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) specified in RFC 9202 by specifying that the profile applies to Transport Layer Security (TLS) as well as Datagram TLS (DTLS). Ericsson AB Ericsson AB RISE AB RISE AB Nexus Group This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50%. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 COSE headers, a C509 TLS certificate type, and a C509 file format. Ericsson Ericsson RISE RISE This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an OAuth 2.0 Client and Resource Server, and it binds an authentication credential of the Client to an OAuth 2.0 access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications when accessing protected resources according to the authorization information indicated in the access token. A resource-constrained server can use this profile 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. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] 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 OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This document updates RFC 5280, the "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. [STANDARDS-TRACK] This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. 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. 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. 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. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an internationalized email address. This document updates RFC 5280. The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for internationalized email addresses in X.509 certificates. 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 specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs). The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. 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 new parameters and encodings for the OAuth 2.0 token and introspection endpoints when used with the framework for Authentication and Authorization for Constrained Environments (ACE). These are used to express the proof-of-possession (PoP) key the client wishes to use, the PoP key that the authorization server has selected, and the PoP key the resource server uses to authenticate to the client. 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. Informative References This memo defines Transport Layer Security (TLS) extensions and associated semantics that allow clients and servers to negotiate the use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS. It also defines the registry for non-X.509 certificate types. This document is not an Internet Standards Track specification; it is published for informational purposes.

Acknowledgments The authors sincerely thank and for their comments and feedback. The work on this document has been partly supported by the H2020 project SIFIS-Home (Grant agreement 952652).