rfc9430.original.xml   rfc9430.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.26 (Ruby 3.0. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
2) --> -ietf-ace-extend-dtls-authorize-07" number="9430" submissionType="IETF" category
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ="std" consensus="true" updates="9202" obsoletes="" tocDepth="2" tocInclude="tru
-ietf-ace-extend-dtls-authorize-07" category="std" consensus="true" submissionTy e" sortRefs="true" symRefs="true" xml:lang="en" version="3">
pe="IETF" updates="9202" tocDepth="2" tocInclude="true" sortRefs="true" symRefs=
"true" version="3">
<!-- xml2rfc v2v3 conversion 3.16.0 --> <!-- xml2rfc v2v3 conversion 3.16.0 -->
<front> <front>
<title abbrev="CoAP-DTLS Extension to TLS">Extension of the Datagram Transpo rt Layer Security (DTLS) Profile for Authentication and Authorization for Constr ained Environments (ACE) to Transport Layer Security (TLS)</title> <title abbrev="CoAP-DTLS Extension to TLS">Extension of the Datagram Transpo rt Layer Security (DTLS) Profile for Authentication and Authorization for Constr ained Environments (ACE) to Transport Layer Security (TLS)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-ace-extend-dtls-authoriz e-07"/> <seriesInfo name="RFC" value="9430"/>
<author initials="O." surname="Bergmann" fullname="Olaf Bergmann"> <author initials="O." surname="Bergmann" fullname="Olaf Bergmann">
<organization abbrev="TZI">Universität Bremen TZI</organization> <organization abbrev="TZI">Universität Bremen TZI</organization>
<address> <address>
<postal> <postal>
<street>Bremen, D-28359</street> <city>Bremen</city>
<code>D-28359</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>bergmann@tzi.org</email> <email>bergmann@tzi.org</email>
</address> </address>
</author> </author>
<author initials="J" surname="Preuß Mattsson" fullname="John Preuß Mattsson" > <author initials="J" surname="Preuß Mattsson" fullname="John Preuß Mattsson" >
<organization abbrev="Ericsson">Ericsson AB</organization> <organization abbrev="Ericsson">Ericsson AB</organization>
<address> <address>
<postal> <postal>
<street>SE-164 80 Stockholm</street> <city>Stockholm</city>
<code>164 80</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>john.mattsson@ericsson.com</email> <email>john.mattsson@ericsson.com</email>
</address> </address>
</author> </author>
<author initials="G." surname="Selander" fullname="Göran Selander"> <author initials="G." surname="Selander" fullname="Göran Selander">
<organization abbrev="Ericsson">Ericsson AB</organization> <organization abbrev="Ericsson">Ericsson AB</organization>
<address> <address>
<postal> <postal>
<street>SE-164 80 Stockholm</street> <city>Stockholm</city>
<code>164 80</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>goran.selander@ericsson.com</email> <email>goran.selander@ericsson.com</email>
</address> </address>
</author> </author>
<date year="2023" month="March" day="09"/> <date month="July" year="2023"/>
<workgroup>ACE Working Group</workgroup> <area>sec</area>
<workgroup>ace</workgroup>
<keyword>Internet of Things (IoT)</keyword>
<keyword>Internet of Things</keyword>
<keyword>IOT</keyword>
<keyword>OAuth</keyword>
<keyword>Access Token</keyword>
<abstract> <abstract>
<t>This document updates the Datagram Transport Layer Security (DTLS) Prof ile for Authentication and Authorization for Constrained Environments (ACE) spec ified in RFC 9202 by specifying that the profile applies to Transport Layer Secu rity (TLS) as well as Datagram TLS (DTLS).</t> <t>This document updates "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)" (RFC 9 202) by specifying that the profile applies to TLS as well as DTLS.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The Authentication and Authorization for Constrained Environments (ACE) <t>The Authentication and Authorization for Constrained Environments (ACE)
framework <xref target="RFC9200"/> defines an architecture for lightweight auth framework <xref target="RFC9200"/> defines an architecture for lightweight auth
entication between Client, Resource Server (RS), and Authorization Server (AS) w entication between the Client, Resource Server (RS), and Authorization Server (A
here the Client and RS may be constrained. The Datagram Transport Layer Security S), where the Client and RS may be constrained.
(DTLS) Profile for Authentication and Authorization for Constrained Environment
s (ACE) <xref target="RFC9202"/> only specifies the use of Datagram Transport La "Datagram Transport Layer Security (DTLS) Profile for Authentication and A
yer Security (DTLS) <xref target="RFC9147"/> for transport-layer security betwee uthorization for Constrained Environments (ACE)" <xref target="RFC9202"/> only s
n the nodes in the ACE architecture but works equally well for Transport Layer S pecifies the use of DTLS <xref target="RFC9147"/> for transport layer security b
ecurity (TLS) <xref target="RFC8446"/>. For many constrained implementations, Co etween the nodes in the ACE architecture but works equally well for Transport La
nstrained Application Protocol (CoAP) over UDP <xref target="RFC7252"/> is the f yer Security (TLS) <xref target="RFC8446"/>. For many constrained implementation
irst choice, but when deploying ACE in networks controlled by other entities (su s, the Constrained Application Protocol (CoAP) over UDP <xref target="RFC7252"/>
ch as the Internet), UDP might be blocked on the path between the Client and the is the first choice, but when deploying ACE in networks controlled by other ent
Resource ities (such as the Internet), UDP might be blocked on the path between the Clien
t and the Resource
Server, and the Client might have to fall back to CoAP over TCP <xref target="RF C8323"/> for NAT or firewall traversal. This dual support for security over TCP as well as UDP is already supported by the Object Security for Constrained RESTf ul Environments (OSCORE) profile <xref target="RFC9203"/>.</t> Server, and the Client might have to fall back to CoAP over TCP <xref target="RF C8323"/> for NAT or firewall traversal. This dual support for security over TCP as well as UDP is already supported by the Object Security for Constrained RESTf ul Environments (OSCORE) profile <xref target="RFC9203"/>.</t>
<t>This document updates <xref target="RFC9202"/> by specifying that the p rofile applies to TLS as well as DTLS. It only impacts the transport layer secur ity 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 ac cess token can be used by either DTLS or TLS between a given (Client, RS) pair. Therefore, the value <tt>coap_dtls</tt> in the <tt>ace_profile</tt> parameter of an Authorization Server to Client (AS-to-Client) response or in the <tt>ace_pro file</tt> claim of an access token indicates that either DTLS or TLS can be used for transport layer security.</t> <t>This document updates <xref target="RFC9202"/> by specifying that the p rofile applies to TLS as well as DTLS. It only impacts the transport layer secur ity channel between the Client and Resource Server. The same access rights are v alid in case transport layer security is provided by either DTLS or TLS. The sam e access token can be used by either DTLS or TLS between a given (Client, RS) pa ir. Therefore, the value <tt>coap_dtls</tt> in the <tt>ace_profile</tt> paramete r of an Authorization Server to Client (AS-to-Client) response or in the <tt>ace _profile</tt> claim of an access token indicates that either DTLS or TLS can be used for transport layer security.</t>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and be interpreted as
only when, they described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
</t>
<t>Readers are expected to be familiar with the terms and concepts <t>Readers are expected to be familiar with the terms and concepts
described in <xref target="RFC9200"/> and <xref target="RFC9202"/>.</t> described in <xref target="RFC9200"/> and <xref target="RFC9202"/>.</t>
</section> </section>
<section anchor="specific-changes-to-rfc-9202"> <section anchor="specific-changes-to-rfc-9202">
<name>Specific Changes to RFC 9202</name> <name>Specific Changes to RFC 9202</name>
<t>The main changes to <xref target="RFC9202"/> specified in this document are limited <t>The main changes to <xref target="RFC9202"/> specified in this document are limited
to replacing "DTLS" with "DTLS/TLS" throughout the document. This to replacing "DTLS" with "DTLS/TLS" throughout the document. This
essentially impacts the use of secure transport as described in the essentially impacts the use of secure transport, as described in
sections 3.2.2, 3.3.2, 4, and 5.</t> Sections <xref target="RFC9202" section="3.2.2" sectionFormat="bare"/>, <xref ta
rget="RFC9202" section="3.3.2" sectionFormat="bare"/>, <xref target="RFC9202" se
ction="4" sectionFormat="bare"/>, and <xref target="RFC9202" section="5" section
Format="bare"/>.</t>
<t>In addition to this, the Client and Resource Server behavior is <t>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 updated to describe the case where either or both DTLS and TLS may be
available, as described in the following section.</t> available, as described in the following section.</t>
</section> </section>
<section anchor="connection-establishment"> <section anchor="connection-establishment">
<name>Connection Establishment</name> <name>Connection Establishment</name>
<t>Following the procedures defined in <xref target="RFC9202"/>, a <t>Following the procedures defined in <xref target="RFC9202"/>, a
Client can retrieve an Access Token from an Authorization Server in Client can retrieve an access token from an Authorization Server in
order to establish a security association with a specific Resource order to establish a security association with a specific Resource
Server. The <tt>ace_profile</tt> parameter in the Client-to-AS request and Server. The <tt>ace_profile</tt> parameter in the Client-to-AS request and
AS-to-client response is used to determine the ACE profile that the AS-to-Client response is used to determine the ACE profile that the
Client uses towards the Resource Server.</t> Client uses towards the Resource Server.</t>
<t>The <tt>ace_profile</tt> parameter indicates the use of the DTLS <t>The <tt>ace_profile</tt> parameter indicates the use of the DTLS
profile for ACE as defined in <xref target="RFC9202"/>. Therefore, the Client ty profile for ACE, as defined in <xref target="RFC9202"/>. Therefore, the Client t
pically ypically
first tries using DTLS to connect to the Resource Server. If this fails the first tries using DTLS to connect to the Resource Server. If this fails, the
Client <bcp14>MAY</bcp14> try to connect to the Resource Server via TLS.</t> Client <bcp14>MAY</bcp14> try to connect to the Resource Server via TLS.</t>
<t>As resource-constrained devices are not expected to support both <t>As resource-constrained devices are not expected to support both
transport layer security mechanisms, Clients and Resource Servers transport layer security mechanisms, Clients and Resource Servers
<bcp14>SHOULD</bcp14> support DTLS and <bcp14>MAY</bcp14> support TLS. A Client that implements either <bcp14>SHOULD</bcp14> support DTLS and <bcp14>MAY</bcp14> support TLS. A Client that implements either
TLS or DTLS but not both might fail in establishing a secure TLS or DTLS but not both might fail in establishing a secure
communication channel with the Resource Server altogether. Non-constrained communication channel with the Resource Server altogether. Nonconstrained
Clients and Resource Servers <bcp14>SHOULD</bcp14> support both TLS and DTLS.</t > Clients and Resource Servers <bcp14>SHOULD</bcp14> support both TLS and DTLS.</t >
<t>Note that a communication setup with an a priori unknown Resource <t>Note that a communication setup with an a priori unknown Resource
Server typically employs an initial unauthorized resource request as Server typically employs an initial unauthorized resource request, as
illustrated in Section 2 of <xref target="RFC9202"/>. If this illustrated in <xref target="RFC9202" section="2" sectionFormat="of"/>. If this
message exchange succeeds, the Client <bcp14>SHOULD</bcp14> first use the same message exchange succeeds, the Client <bcp14>SHOULD</bcp14> first use the same
underlying transport protocol also for the establishment of the security underlying transport protocol for the establishment of the security
association to the Resource Server (i.e., DTLS for UDP, and TLS for TCP).</t> association to the Resource Server (i.e., DTLS for UDP, and TLS for TCP).</t>
<t>As a consequence, the selection of the transport protocol used for the <t>As a consequence, the selection of the transport protocol used for the
initial unauthorized resource request also depends on the transport initial unauthorized resource request also depends on the transport
layer security mechanism supported by the Client. Clients that layer security mechanism supported by the Client. Clients that
support either DTLS or TLS but not both <bcp14>SHOULD</bcp14> use the transport support either DTLS or TLS but not both <bcp14>SHOULD</bcp14> use the transport
protocol underlying the supported transport layer security mechanism protocol underlying the supported transport layer security mechanism
also for an initial unauthorized resource request to the Resource for an initial unauthorized resource request to the Resource
Server as in Section 2 of <xref target="RFC9202"/>.</t> Server, as in <xref target="RFC9202" section="2" sectionFormat="of"/>.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>The following updates have been done to the "ACE Profiles" registry <t>In the "ACE Profiles" registry, the Description and Reference fields
for the profile with a "CBOR Value" field value of 1 and "Name" of "coap_dtls":< have been updated as follows for coap_dtls:</t>
/t> <dl newline="false" spacing="normal">
<t>Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with <dt>Name:</dt><dd>coap_dtls</dd>
the RFC number of this specification and delete this paragraph.</t> <dt>Description:</dt> <dd>Profile for delegating client Authentication an
<t>Description: Profile for delegating client Authentication and d
Authorization for Constrained Environments by establishing a Datagram Authorization for Constrained Environments by establishing a Datagram
Transport Layer Security (DTLS) or Transport Layer Security (TLS) Transport Layer Security (DTLS) or Transport Layer Security (TLS)
channel between resource-constrained nodes.</t> channel between resource-constrained nodes.</dd>
<t>Change Controller: IESG</t> <dt>CBOR Value:</dt> <dd>1</dd>
<t>Reference: [RFC9202] [RFC-XXXX]</t> <dt>Reference:</dt> <dd><xref target="RFC9202"/>, RFC 9430</dd>
</dl>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The security consideration and requirements in <xref target="RFC9202"/> , TLS 1.3 <xref target="RFC8446"/>, and BCP 195 <xref target="RFC8996"/> <xref t arget="RFC9325"/> also apply to this document.</t> <t>The security consideration and requirements in <xref target="RFC9202"/> , TLS 1.3 <xref target="RFC8446"/>, and BCP 195 <xref target="RFC8996"/> <xref t arget="RFC9325"/> also apply to this document.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7
252" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"
<front> />
<title>The Constrained Application Protocol (CoAP)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8323.xml"
<author fullname="Z. Shelby" initials="Z." surname="Shelby"/> />
<author fullname="K. Hartke" initials="K." surname="Hartke"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"
<author fullname="C. Bormann" initials="C." surname="Bormann"/> />
<date month="June" year="2014"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"
<abstract> />
<t>The Constrained Application Protocol (CoAP) is a specialized we <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9200.xml"
b transfer protocol for use with constrained nodes and constrained (e.g., low-po />
wer, lossy) networks. The nodes often have 8-bit microcontrollers with small amo <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9202.xml"
unts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wire />
less Personal Area Networks (6LoWPANs) often have high packet error rates and a <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
typical throughput of 10s of kbit/s. The protocol is designed for machine- to-ma />
chine (M2M) applications such as smart energy and building automation.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
<t>CoAP provides a request/response interaction model between appl />
ication endpoints, supports built-in discovery of services and resources, and in
cludes key concepts of the Web such as URIs and Internet media types. CoAP is de
signed to easily interface with HTTP for integration with the Web while meeting
specialized requirements such as multicast support, very low overhead, and simpl
icity for constrained environments.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7252"/>
<seriesInfo name="DOI" value="10.17487/RFC7252"/>
</reference>
<reference anchor="RFC8323" target="https://www.rfc-editor.org/info/rfc8
323" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8323.xml">
<front>
<title>CoAP (Constrained Application Protocol) over TCP, TLS, and We
bSockets</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="S. Lemay" initials="S." surname="Lemay"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<author fullname="K. Hartke" initials="K." surname="Hartke"/>
<author fullname="B. Silverajan" initials="B." surname="Silverajan"/
>
<author fullname="B. Raymor" initials="B." role="editor" surname="Ra
ymor"/>
<date month="February" year="2018"/>
<abstract>
<t>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.</t>
<t>Some environments benefit from the availability of CoAP carried
over reliable transports such as TCP or Transport Layer Security (TLS). This do
cument outlines the changes required to use CoAP over TCP, TLS, and WebSockets t
ransports. It also formally updates RFC 7641 for use with these transports and R
FC 7959 to enable the use of larger messages over a reliable transport.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8323"/>
<seriesInfo name="DOI" value="10.17487/RFC8323"/>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
446" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC9147" target="https://www.rfc-editor.org/info/rfc9
147" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version
1.3</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
<date month="April" year="2022"/>
<abstract>
<t>This document specifies version 1.3 of the Datagram Transport L
ayer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to com
municate over the Internet in a way that is designed to prevent eavesdropping, t
ampering, and message forgery.</t>
<t>The DTLS 1.3 protocol is based on the Transport Layer Security
(TLS) 1.3 protocol and provides equivalent security guarantees with the exceptio
n of order protection / non-replayability. Datagram semantics of the underlying
transport are preserved by the DTLS protocol.</t>
<t>This document obsoletes RFC 6347.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9147"/>
<seriesInfo name="DOI" value="10.17487/RFC9147"/>
</reference>
<reference anchor="RFC9200" target="https://www.rfc-editor.org/info/rfc9
200" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9200.xml">
<front>
<title>Authentication and Authorization for Constrained Environments
Using the OAuth 2.0 Framework (ACE-OAuth)</title>
<author fullname="L. Seitz" initials="L." surname="Seitz"/>
<author fullname="G. Selander" initials="G." surname="Selander"/>
<author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/
>
<author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<date month="August" year="2022"/>
<abstract>
<t>This specification defines a framework for authentication and a
uthorization in Internet of Things (IoT) environments called ACE-OAuth. The fra
mework is based on a set of building blocks including OAuth 2.0 and the Constrai
ned Application Protocol (CoAP), thus transforming a well-known and widely used
authorization solution into a form suitable for IoT devices. Existing specifica
tions are used where possible, but extensions are added and profiles are defined
to better serve the IoT use cases.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9200"/>
<seriesInfo name="DOI" value="10.17487/RFC9200"/>
</reference>
<reference anchor="RFC9202" target="https://www.rfc-editor.org/info/rfc9
202" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9202.xml">
<front>
<title>Datagram Transport Layer Security (DTLS) Profile for Authenti
cation and Authorization for Constrained Environments (ACE)</title>
<author fullname="S. Gerdes" initials="S." surname="Gerdes"/>
<author fullname="O. Bergmann" initials="O." surname="Bergmann"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="G. Selander" initials="G." surname="Selander"/>
<author fullname="L. Seitz" initials="L." surname="Seitz"/>
<date month="August" year="2022"/>
<abstract>
<t>This specification defines a profile of the Authentication and
Authorization for Constrained Environments (ACE) framework that allows constrain
ed servers to delegate client authentication and authorization. The protocol re
lies 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 resou
rce-constrained server can use this protocol to delegate management of authoriza
tion information to a trusted host with less-severe limitations regarding proces
sing power and memory.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9202"/>
<seriesInfo name="DOI" value="10.17487/RFC9202"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF documen
ts. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC8996" target="https://www.rfc-editor.org/info/rfc8
996" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8996.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8996.xml"
<front> />
<title>Deprecating TLS 1.0 and TLS 1.1</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9203.xml"
<author fullname="K. Moriarty" initials="K." surname="Moriarty"/> />
<author fullname="S. Farrell" initials="S." surname="Farrell"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"
<date month="March" year="2021"/> />
<abstract>
<t>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 recom
mended cryptographic algorithms and mechanisms, and various government and indus
try profiles of applications using TLS now mandate avoiding these old TLS versio
ns. TLS version 1.2 became the recommended version for IETF protocols in 2008 (s
ubsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient ti
me to transition away from older versions. Removing support for older versions f
rom implementations reduces the attack surface, reduces opportunity for misconfi
guration, and streamlines library and product maintenance.</t>
<t>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.</t>
<t>This document updates many RFCs that normatively refer to TLS v
ersion 1.0 or TLS version 1.1, as described herein. This document also updates t
he best practices for TLS usage in RFC 7525; hence, it is part of BCP 195.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="195"/>
<seriesInfo name="RFC" value="8996"/>
<seriesInfo name="DOI" value="10.17487/RFC8996"/>
</reference>
<reference anchor="RFC9203" target="https://www.rfc-editor.org/info/rfc9
203" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9203.xml">
<front>
<title>The Object Security for Constrained RESTful Environments (OSC
ORE) Profile of the Authentication and Authorization for Constrained Environment
s (ACE) Framework</title>
<author fullname="F. Palombini" initials="F." surname="Palombini"/>
<author fullname="L. Seitz" initials="L." surname="Seitz"/>
<author fullname="G. Selander" initials="G." surname="Selander"/>
<author fullname="M. Gunnarsson" initials="M." surname="Gunnarsson"/
>
<date month="August" year="2022"/>
<abstract>
<t>This document specifies a profile for the Authentication and Au
thorization for Constrained Environments (ACE) framework. It utilizes Object Se
curity for Constrained RESTful Environments (OSCORE) to provide communication se
curity and proof-of-possession for a key owned by the client and bound to an OAu
th 2.0 access token.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9203"/>
<seriesInfo name="DOI" value="10.17487/RFC9203"/>
</reference>
<reference anchor="RFC9325" target="https://www.rfc-editor.org/info/rfc9
325" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (T
LS) and Datagram Transport Layer Security (DTLS)</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<author fullname="T. Fossati" initials="T." surname="Fossati"/>
<date month="November" year="2022"/>
<abstract>
<t>Transport Layer Security (TLS) and Datagram Transport Layer Sec
urity (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, inclu
ding attacks on the most commonly used cipher suites and their modes of operatio
n. This document provides the latest recommendations for ensuring the security o
f deployed services that use TLS and DTLS. These recommendations are applicable
to the majority of use cases.</t>
<t>RFC 7525, an earlier version of the TLS recommendations, was pu
blished when the industry was transitioning to TLS 1.2. Years later, this transi
tion 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, thi
s document updates RFCs 5288 and 6066 in view of recent attacks.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="195"/>
<seriesInfo name="RFC" value="9325"/>
<seriesInfo name="DOI" value="10.17487/RFC9325"/>
</reference>
</references> </references>
</references> </references>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The authors would like to thank Marco Tiloca for reviewing this <t>The authors would like to thank <contact fullname="Marco Tiloca"/> for reviewing this
specification.</t> specification.</t>
</section> </section>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA8VY7XLbuBX9j6dAtTOdpCOpsewktqbtrGIrWe84tmspbbfZ
zAYiIQlrkuACoL3ajJ+l/dFn6AM0L9ZzAZCiZDtOZtpZ/7BIEB/3Hpx77gV6
vR5zymVyyMc/O1lYpQuu59wtJT8STiyMyPnUiMKW2jh+IlbS8IlMKqPcij86
mp5MHvNzo+cqk3yuDR9VGFo4lQhHU4ki9U3aqF9CC3U61IV1RqhCpnxcXCmj
ixyDLH80Ohw/5k5/YklakaU6KUQOo1Mj5q6npJv3RCJ7knxIe6nLbE/EZSUT
s5mRV0MsOzrvkcktX2mtk8mXTdjLhJPWsapM6WHIDwZPBkyVZsidqawbPHly
gAZAMOTWpexam8uF0VU55PCP/xWvqljwV9TEAIQU+ZAfj6cvGUt0ik9DXmH9
fVaqIf+KJ6LglZVcGCMAgJpzkWV8Je1jDiyXwi75UhrJOJxJhvQBjxbYGTm3
zfsqb7+iZypLtxzyAWPBsSHr8YDBWSbm/IU0i1wUBY2tTPjQatMGVr4p1JU0
VrmP/3L8hZHYRD79+zE+15CHN/JRAozQpcuPeoP93acH+JLoqnBmNeSvpMHM
KzTJXKhsyGdxra/dL6qP1RrrvtXLApST1cd/8NfCOWs1GaQK5ZTI4OG3bZNv
d/SWj41K6J2PXrSsrVtbJk/GvZ1ne3z/CZ8As8ulzvK22ZNrmcpibfWPMK6f
x8W+lnG+fqLzxv5XH/8NcoPRGYJDmraxrbb/q5ULDQv6Nq62aSZjhcZWOOzs
kGHIxcvD54Ong2F43N8d7NaPe3vP4uPBzt7z+hHkXz9iGFPFfHvC/YODZ+tO
9YQHu4On6EHq4VbUFv4m45OXQ955ix69v+HvXYexXq8HOEhDEsfYdKksRwRX
JCI8RuWvK2G2lImaK3xUBfnmJYLPVvHDiuLfLYXzVpZxcVGWmSLLH9I/Liy/
lhAB/K5dhK4Fb/oBoFylaSYZ+4ofgwY6rRJvPeEl/ydOzrGsJHHjHz7Erb+5
4amcY4DFlFCsZKmcTFxlArSZWizdtaT/XGxaMJP4AP04BASF6/ILaXVlEgnX
DUSGP7qYPO7eYWf9eQRYrkkHPaRhFt/9YsJz6OZMIh4ad/p8+mvSo8ZrALx0
ka0avgTaktojCX+2eWE6BCGmo9Vd3R+Zivrbun8NMi1S6BTLqfBCeWljt2aV
47S1lsufKuSbVSAczf4AN70xJA43N33+Ev1J19vYc5WXGSUC5/Gy3Q20RhQE
EVvADjnTGX9EqRvpjnb6zdF5WINkCQ6rgNlcGet4stQqkd1gPrYJbCwz7cON
XIS3BSDwfsEiREWWYU3EpcYchnvtoV14ZKtkSeFFUyN8pME48I8Wzz19wadZ
Bq3FcB0wLIVbbiDcIiG91oxmgbLd5kPsF+ZdiitJCjCnJD8TySW9kPvB++lh
9J6UOG736WhKlQAQkNc0ClBSWhYZsZykERuIJFP6PaMBDR+aKVuCQi5ikMhQ
l6SrelxAiaw9m/0Ijqx3fZvuF+PJdF5lW7Q/mxyeXYD5tdbVEQAf+vcpeDtK
vkA6oYNtfcR7nx+7EGegHlJG2NYmSvhWlCRL1B0y25KkICabqhRkxEIGuUgS
aS03tIlADyF0JTLl9T8R9hOrwXN4caXSALFUnom+TKVgI+u3F3H6Uha+Lpx5
sbhnYOOA4Atk3wJhVIsr4rQUKtiPulAbxAxhApsryd8nWpQ/UNH7vhaI96iG
f4hov8dYkn5EBckUzLhTkom3ATmIc8/pXnh7zI0EEAVpnLl7+iQTKo9Tb7is
ipS0wcskGHCHy21QNqRwC3aQDolxiqpTFTrTi1VIi5dyRbKXWt55/WYy7XTD
Lz89888X4z+/Ob4YH9Hz5JvRyUnzwGKPyTdnb06O1k/rkYdnr1+PT4/CYLTy
jSbWeT36rhM0oXN2Pj0+Ox2ddAI87dggYgFYuKhIlUojKTSFZRDzxKhZqDhe
HJ7/5587e4ig3yCEBjs7Bwih8LK/83wPLySOYTUfF+EVaK4YQkkKvzGkJYko
lUNZ3aVYskt9XfjDBuD73VtC5t2Q/2GWlDt7f4oN5PBGY43ZRqPH7HbLrcEB
xDua7limQXOjfQvpTXtH322817i3Ghm7gAxCTT3y8mdoEAEetmAucpUpgHUN
IgZNAaGshxXpJcEJa2tj2oUS9WpJXJ8IOQl1QMIPoUGLIGh1+RgYigq+8AoV
v7ZFcqPqvM2bTOXI7ynDKIO0KBKS0g5FTyd44J9/79/dEqfTxVJXQWfreUJG
YYhISpW+LmhLaixcfJC1JQ/c2YABfRk6+fTPd/uD/qCLn1362QusfAo4jkHB
NFUuntPJoe6t6m6rTJxJJFBFwmLj+dxvVr26H+71ONSKUUHQf4YKICgJTUu/
oWpk4gpnJjHLZPcuNyAyWaavCcnokN9HJMQivPKxdRit7JLwY+xl0z/mr0Sm
AMvGunmDJdhTLMqiuyRtCHejJCoEEt2gjFOvjHOj83uVWBUMmhYkWdbmICs0
OUjg+JeoMMYzQdRcSrbLlpCN7ksHql35kOaPJrD5pwqrEq4sJIIkONTkARDV
C7bfKOc1WTZlaZ3i65xfw4ERFADXgtS6XV/VuTnEy/2WrlNJQ1x/ZqT7oLJd
8FNtfN/+3Mqg0Tq3KjE94oOFwpS2jbykjfcsg69JIEng9m37+fE8BPEcBLRt
16FbmHD18Bz8SglfQjA2soS3/9hrF+OpvELFHOSt0G5D4uqakWKD3VvA5JLk
SNmcKnlvoL0rNC2Lyl3P2gQbuVM3+npn1KBIe94cF2wMVxbzvZ+AKn2y28dv
KKEJL9qmhuoEemS7ZInO86qojxh1rdco+DaCInN6IWnZPj/VRRs79ilv+Za3
3r7a46OwJ6faRV4LvmmWla4qYyhS/VYaaJriVXFZUAreisk127jM6bzjT9/x
RgyDmpvLtOHAOiotU1lWkU8usHsShWtAEbFB9UhIlkN3xILSYUhEcBJaJNNN
eY4ABP5TgLlYxrKKrp2yUMk3rCrrwx6qDR1qN/SXbfWsQ7SmHmvr1j0R8Ej1
Zb8buEKT4njTbSTeH2cPzx+H+BD+lEq4FEmMZiuziEZc+g5717UmIvQzQScX
cTSVBbQrHh+bmdl98XX7LBaQ7vMm7ohMrKbcXSeCdrTEDaq3Zm3A2rXWRhEa
zfoPiwFrtvGzqbi1gzW5hf0kK/0F1+h05A+hOEWZcKsQ1H+dnetDpT9fz+hU
lOpC1mt2SOTjLY/twKKFQkRAvCMN63wQk2Pn8MXZBf8LHZY6ILjM0nhygm07
oYY/BdE79N5pDlOdYR3yoagbo7bRZsjPM0kVSajJpC+7dQI8DfHQ+jk+fPgt
3YPe3IRKjXmcMEVR5bNwCvOZok7a66upFAT2IkPHTCS/hRHlEpgd+TqmpH7D
jestGrDAeEAW0/TtCy/2BRdedDLd1OH6Wos9dK314F0T2z6p35nh/EUXXA4l
NVka7n2APD8eT15RiT+XHmy0fP82Uuv7d7xB3Zfm9dJ38Wx9d9D+6HeA2K1M
TGDbxR3F5E5/t31pFtQJJzi+c/A0fjg4eOYPcPGWnA4PFF1067GqS+N1jR6u
f+nuiOweJZQzMpkuvAnswzCyRqZ/7BS6cxM8CIFpcfqtwOZMXcbYEMUlfy1M
ovlUZToRfrcNigYZi1jkgw3axeXnWTWfs/8Cun4WQGAcAAA=
</back>
</rfc> </rfc>
 End of changes. 26 change blocks. 
397 lines changed or deleted 104 lines changed or added

This html diff was produced by rfcdiff 1.48.