<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-ace-dtls-authorize-18" indexInclude="true" ipr="trust200902" number="9202" prepTime="2022-08-31T13:47:48" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-ace-dtls-authorize-18" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9202" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="DTLS Profile for ACE">Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)</title>
    <seriesInfo name="RFC" value="9202" stream="IETF"/>
    <author initials="S." surname="Gerdes" fullname="Stefanie Gerdes">
      <organization showOnFrontPage="true">Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63906</phone>
        <email>gerdes@tzi.org</email>
      </address>
    </author>
    <author initials="O." surname="Bergmann" fullname="Olaf Bergmann">
      <organization showOnFrontPage="true">Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63904</phone>
        <email>bergmann@tzi.org</email>
      </address>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization showOnFrontPage="true">Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <author initials="G." surname="Selander" fullname="Göran Selander">
      <organization showOnFrontPage="true">Ericsson AB</organization>
      <address>
        <email>goran.selander@ericsson.com</email>
      </address>
    </author>
    <author initials="L." surname="Seitz" fullname="Ludwig Seitz">
      <organization showOnFrontPage="true">Combitech</organization>
      <address>
        <postal>
          <street>Djäknegatan 31</street>
          <city>Malmö</city>
          <code>211 35</code>
          <country>Sweden</country>
        </postal>
        <email>ludwig.seitz@combitech.com</email>
      </address>
    </author>
    <date month="08" year="2022"/>
    <area>Security</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 pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9202" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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 Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protocol-overview">Protocol Overview</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protocol-flow">Protocol Flow</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-communication-between-the-c">Communication between the Client and the Authorization Server</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-raw-public-key-mode">Raw Public Key Mode</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2">
                  <li pn="section-toc.1-1.3.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derivedContent="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-access-token-retrieval-from">Access Token Retrieval from the Authorization Server</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.2.1"><xref derivedContent="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dtls-channel-setup-between-">DTLS Channel Setup between the Client and Resource Server</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pre-shared-key-mode">Pre-shared Key Mode</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.3.2">
                  <li pn="section-toc.1-1.3.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.1.1"><xref derivedContent="3.3.1" format="counter" sectionFormat="of" target="section-3.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-access-token-retrieval-from-">Access Token Retrieval from the Authorization Server</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.2.1"><xref derivedContent="3.3.2" format="counter" sectionFormat="of" target="section-3.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dtls-channel-setup-between-t">DTLS Channel Setup between the Client and Resource Server</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-resource-access">Resource Access</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dynamic-update-of-authoriza">Dynamic Update of Authorization Information</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-token-expiration">Token Expiration</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-secure-communication-with-a">Secure Communication with an Authorization Server</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reuse-of-existing-sessions">Reuse of Existing Sessions</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multiple-access-tokens">Multiple Access Tokens</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-out-of-band-configuration">Out-of-Band Configuration</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">This specification defines a profile of the ACE framework
<xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/>.  In this profile, a client (C) and a
resource server (RS) use the Constrained Application Protocol (CoAP) <xref target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/> over DTLS version 1.2 <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/>
to communicate. This specification
uses DTLS 1.2 terminology, but later versions such as DTLS 1.3 <xref target="RFC9147" format="default" sectionFormat="of" derivedContent="RFC9147"/> can be
used instead. The client obtains an access token bound to a key
(the proof-of-possession (PoP) key) from an authorization server (AS) to prove
its authorization to access protected resources hosted by the resource
server. Also, the client and the resource server are provided by the
authorization server with the necessary keying material to establish a
DTLS session. The communication between the client and authorization
server may also be secured with DTLS.  This specification supports
DTLS with raw public keys (RPKs) <xref target="RFC7250" format="default" sectionFormat="of" derivedContent="RFC7250"/> and with pre-shared keys
(PSKs) <xref target="RFC4279" format="default" sectionFormat="of" derivedContent="RFC4279"/>. How token introspection <xref target="RFC7662" format="default" sectionFormat="of" derivedContent="RFC7662"/> is performed
between the RS and AS is out of scope for this specification.</t>
      <t indent="0" pn="section-1-2">The ACE framework requires that the client and server mutually
authenticate each other before any application data is exchanged.
DTLS enables mutual authentication if both the client and server prove
their ability to use certain keying material in the DTLS handshake.
The authorization server assists in this process on the server side by
incorporating keying material (or information about keying material)
into the access token, which is considered a proof-of-possession
token.</t>
      <t indent="0" pn="section-1-3">In the RPK mode, the client proves that it can use the RPK bound to
the token and the server shows that it can use a certain RPK.</t>
      <t indent="0" pn="section-1-4">The resource server needs access to the token in order to complete
this exchange.  For the RPK mode, the client must upload the access
token to the resource server before initiating the handshake, as
described in <xref target="RFC9200" sectionFormat="of" section="5.10.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.10.1" derivedContent="RFC9200"> the ACE framework</xref>.</t>
      <t indent="0" pn="section-1-5">In the PSK mode, the client and server show with the DTLS handshake that
they can use the keying material that is bound to the access token.
To transfer the access token from the client to the resource server,
the <tt>psk_identity</tt> parameter in the DTLS PSK handshake may be used
instead of uploading the token prior to the handshake.</t>
      <t indent="0" pn="section-1-6">As recommended in <xref target="RFC9200" sectionFormat="of" section="5.8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.8" derivedContent="RFC9200"/>, this
specification uses Concise Binary Object Representation (CBOR) web tokens to convey claims within an access
token issued by the server.  While other formats could be used as well,
those are out of scope for this document.</t>
      <section anchor="terminology" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-terminology">Terminology</name>
        <t indent="0" pn="section-1.1-1">The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.</t>
        <t indent="0" pn="section-1.1-2">Readers are expected to be familiar with the terms and concepts
described in <xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/> and <xref target="RFC9201" format="default" sectionFormat="of" derivedContent="RFC9201"/>.</t>
        <t indent="0" pn="section-1.1-3">The authorization information (authz-info) resource refers to the authorization information endpoint, as specified in <xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/>.
The term <tt>claim</tt> is used in this document with the same semantics
as in <xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/>, i.e., it denotes information carried
in the access token or returned from introspection.</t>
        <t indent="0" pn="section-1.1-4">Throughout this document, examples for CBOR data items are expressed in
           CBOR extended diagnostic notation as defined in
           <xref section="8" sectionFormat="of" target="RFC8949" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-8" derivedContent="RFC8949"/> and
           <xref section="G" sectionFormat="of" target="RFC8610" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8610#appendix-G" derivedContent="RFC8610"/>
           ("diagnostic notation"), unless noted otherwise.
           We often use diagnostic notation comments to provide
           a textual representation of the numeric parameter names and values.
        </t>
      </section>
    </section>
    <section anchor="overview" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-protocol-overview">Protocol Overview</name>
      <t indent="0" pn="section-2-1">The CoAP-DTLS profile for ACE specifies the transfer of authentication
information and, if necessary, authorization information between the
client (C) and the resource server (RS) during setup of a DTLS session
for CoAP messaging. It also specifies how the client can use CoAP over
DTLS to retrieve an access token from the authorization server (AS)
for a protected resource hosted on the resource server.  As specified
in <xref target="RFC9200" sectionFormat="of" section="6.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-6.7" derivedContent="RFC9200"/>, use of DTLS for one or
both of these interactions is completely independent.</t>
      <t indent="0" pn="section-2-2">This profile requires the client to retrieve an access token for the
protected resource(s) it wants to access on the resource server, as
specified in <xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/>. <xref target="at-retrieval" format="default" sectionFormat="of" derivedContent="Figure 1"/> shows the
typical message flow in this scenario (messages in square brackets are
optional):</t>
      <figure anchor="at-retrieval" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-retrieving-an-access-token">Retrieving an Access Token</name>
        <artwork name="" type="" align="left" alt="" pn="section-2-3.1">
   C                                RS                   AS
   | [---- Resource Request ------&gt;]|                     |
   |                                |                     |
   | [&lt;-AS Request Creation Hints-] |                     |
   |                                |                     |
   | ------- Token Request  ----------------------------&gt; |
   |                                |                     |
   | &lt;---------------------------- Access Token --------- |
   |                               + Access Information   |
</artwork>
      </figure>
      <t indent="0" pn="section-2-4">To determine the authorization server in charge of a resource hosted
at the resource server, the client can send an initial Unauthorized
Resource Request message to the resource server. The resource server
then denies the request and sends an AS Request Creation Hints message
containing the address of its authorization server back to the client,
as specified in <xref target="RFC9200" sectionFormat="of" section="5.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.3" derivedContent="RFC9200"/>.</t>
      <t indent="0" pn="section-2-5">Once the client knows the authorization server's address, it can send
an access token request to the token endpoint at the authorization
server, as specified in <xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/>. As the access
token request and the response may contain confidential data,
the communication between the client and the authorization server must
be confidentiality protected and ensure authenticity. The client is
expected to have been registered at the authorization server, as
outlined in <xref target="RFC9200" sectionFormat="of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-4" derivedContent="RFC9200"/>.</t>
      <t indent="0" pn="section-2-6">The access token returned by the authorization server can then be used
by the client to establish a new DTLS session with the resource
server. When the client intends to use an asymmetric proof-of-possession key in the
DTLS handshake with the resource server, the client <bcp14>MUST</bcp14> upload the
access token to the authz-info resource, i.e., the authz-info endpoint,
on the resource server before
starting the DTLS handshake, as described in
<xref target="RFC9200" sectionFormat="of" section="5.10.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.10.1" derivedContent="RFC9200"/>. In case the client uses a symmetric proof-of-possession
key in the DTLS handshake, the procedure above <bcp14>MAY</bcp14> be used, or alternatively
 the access token <bcp14>MAY</bcp14> instead be transferred in the
DTLS ClientKeyExchange message (see <xref target="psk-dtls-channel" format="default" sectionFormat="of" derivedContent="Section 3.3.2"/>).
In any case, DTLS <bcp14>MUST</bcp14> be used in a mode that provides replay
protection.</t>
      <t indent="0" pn="section-2-7"><xref target="protocol-overview" format="default" sectionFormat="of" derivedContent="Figure 2"/> depicts the common protocol flow for the DTLS
profile after the client has retrieved the access token from the
authorization server (AS).</t>
      <figure anchor="protocol-overview" align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-protocol-overview-2">Protocol Overview</name>
        <artwork name="" type="" align="left" alt="" pn="section-2-8.1">
   C                            RS                   AS
   | [--- Access Token ------&gt;] |                     |
   |                            |                     |
   | &lt;== DTLS channel setup ==&gt; |                     |
   |                            |                     |
   | == Authorized Request ===&gt; |                     |
   |                            |                     |
   | &lt;=== Protected Resource == |                     |
</artwork>
      </figure>
    </section>
    <section anchor="protocol-flow" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-protocol-flow">Protocol Flow</name>
      <t indent="0" pn="section-3-1">The following sections specify how CoAP is used to interchange
access-related data between the resource server, the client, and the
authorization server so that the authorization server can provide the
client and the resource server with sufficient information to
establish a secure channel and convey authorization information
specific for this communication relationship to the resource server.</t>
      <t indent="0" pn="section-3-2"><xref target="C-AS-comm" format="default" sectionFormat="of" derivedContent="Section 3.1"/> describes how the communication between
      the client (C) and the authorization server (AS) must be secured.
      Depending on the CoAP security mode used (see also
      <xref target="RFC7252" sectionFormat="of" section="9" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-9" derivedContent="RFC7252"/>),
      the client-to-AS request, AS-to-client response, and DTLS session
      establishment carry slightly different information. <xref target="rpk-mode" format="default" sectionFormat="of" derivedContent="Section 3.2"/> addresses the use of raw public keys, while <xref target="psk-mode" format="default" sectionFormat="of" derivedContent="Section 3.3"/> defines how pre-shared keys are used in this profile.</t>
      <section anchor="C-AS-comm" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-communication-between-the-c">Communication between the Client and the Authorization Server</name>
        <t indent="0" pn="section-3.1-1">To retrieve an access token for the resource that the client wants to
	access, the client requests an access token from the authorization
	server. Before the client can request the access token, the client and
	the authorization server <bcp14>MUST</bcp14> establish
	a secure communication channel. This profile assumes that the keying
	material to secure this communication channel has securely been obtained
	either by manual configuration or in an automated provisioning process.
	The following requirements, in alignment with <xref target="RFC9200" sectionFormat="of" section="6.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-6.5" derivedContent="RFC9200"/>, therefore must be met:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-2">
          <li pn="section-3.1-2.1">The client <bcp14>MUST</bcp14> securely have obtained keying material to
	  communicate with the authorization server.</li>
          <li pn="section-3.1-2.2">Furthermore, the client <bcp14>MUST</bcp14> verify that the authorization
	  server is authorized to provide access tokens (including authorization
	  information) about the resource server to the client and that
	  this authorization information about the authorization server is still valid.</li>
          <li pn="section-3.1-2.3">Also, the authorization server <bcp14>MUST</bcp14> securely have obtained keying
	  material for the client and obtained authorization rules approved
	  by the resource owner (RO) concerning the client and the resource
	  server that relate to this keying material.</li>
        </ul>
        <t indent="0" pn="section-3.1-3">The client and the authorization server <bcp14>MUST</bcp14> use their respective
	keying material for all exchanged messages. How the security
	association between the client and the authorization server is
	bootstrapped is not part of this document. The client and the
	authorization server must ensure the confidentiality, integrity, and
	authenticity of all exchanged messages within the ACE protocol.</t>
        <t indent="0" pn="section-3.1-4"><xref target="as-commsec" format="default" sectionFormat="of" derivedContent="Section 6"/> specifies how communication with the authorization server is secured.</t>
      </section>
      <section anchor="rpk-mode" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-raw-public-key-mode">Raw Public Key Mode</name>
        <t indent="0" pn="section-3.2-1">When the client uses raw public key authentication, the procedure is as
described in the following.</t>
        <section anchor="access-token-retrieval-from-the-authorization-server" numbered="true" toc="include" removeInRFC="false" pn="section-3.2.1">
          <name slugifiedName="name-access-token-retrieval-from">Access Token Retrieval from the Authorization Server</name>
          <t indent="0" pn="section-3.2.1-1">After the client and the authorization server mutually authenticated each other and validated each
other's authorization, the client sends a token request to the authorization server's token endpoint.
The client <bcp14>MUST</bcp14> add a <tt>req_cnf</tt> object carrying either its raw public key
or a unique identifier for a public key that it has previously made
known to the authorization server. It is <bcp14>RECOMMENDED</bcp14> that
the client uses DTLS with the same keying material to secure the
communication with the authorization server, proving possession of the key
as part of the token request. Other mechanisms for proving possession of
the key may be defined in the future.</t>
          <t indent="0" pn="section-3.2.1-2">An example access token request from the client to the authorization
server is depicted in <xref target="rpk-authorization-message-example" format="default" sectionFormat="of" derivedContent="Figure 3"/>.</t>
          <figure anchor="rpk-authorization-message-example" align="left" suppress-title="false" pn="figure-3">
            <name slugifiedName="name-access-token-request-exampl">Access Token Request Example for RPK Mode</name>
            <sourcecode type="cbor-diag" markers="false" pn="section-3.2.1-3.1">
   POST coaps://as.example.com/token
   Content-Format: application/ace+cbor
   Payload:
   {
     / grant_type / 33 : / client_credentials / 2,
     / audience /    5 : "tempSensor4711",
     / req_cnf /     4 : {
       / COSE_Key / 1 : {
         / kty /  1 : / EC2 /   2,
         / crv / -1 : / P-256 / 1,
         / x /   -2 : h'e866c35f4c3c81bb96a1/.../',
         / y /   -3 : h'2e25556be097c8778a20/.../'
       }
     }
   }
</sourcecode>
          </figure>
          <t indent="0" pn="section-3.2.1-4">The example shows an access token request for the resource identified
by the string "tempSensor4711" on the authorization server
using a raw public key.</t>
          <t indent="0" pn="section-3.2.1-5">The authorization server <bcp14>MUST</bcp14> check if the client that it communicates
with is associated with the RPK in the <tt>req_cnf</tt> parameter before
issuing an access token to it.  If the authorization server determines
that the request is to be authorized according to the respective
authorization rules, it generates an access token response for the
client. The access token <bcp14>MUST</bcp14> be bound to the RPK of the client by
means of the <tt>cnf</tt> claim.</t>
          <t indent="0" pn="section-3.2.1-6">The response <bcp14>MUST</bcp14> contain an <tt>ace_profile</tt> parameter if
	  the <tt>ace_profile</tt> parameter in the request is empty and <bcp14>MAY</bcp14>
	  contain this parameter otherwise (see 
	  <xref target="RFC9200" sectionFormat="of" section="5.8.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.8.2" derivedContent="RFC9200"/>). This parameter is set
	  to <tt>coap_dtls</tt> to
	  indicate that this profile <bcp14>MUST</bcp14> be used for communication between the
	  client and the resource server. The response
	  also contains an access token with information for the resource server
	  about the client's public key. The authorization server <bcp14>MUST</bcp14> return
	  in its response the parameter <tt>rs_cnf</tt> unless it is certain that the
	  client already knows the public key of the resource server.  The
	  authorization server <bcp14>MUST</bcp14> ascertain that the RPK specified in
	  <tt>rs_cnf</tt> belongs to the resource server that the client wants to communicate
	  with. The authorization server <bcp14>MUST</bcp14> protect the integrity of the
	  access token such that the resource server can detect unauthorized
	  changes.  If the access token contains confidential data, the
	  authorization server <bcp14>MUST</bcp14> also protect the confidentiality of the
	  access token.</t>
          <t indent="0" pn="section-3.2.1-7">The client <bcp14>MUST</bcp14> ascertain that the access token response belongs
	  to a certain, previously sent access token request, as the request may specify the
	  resource server with which the client wants to communicate.</t>
          <t indent="0" pn="section-3.2.1-8">An example access token response from the authorization server to the client
	  is depicted in <xref target="rpk-authorization-response-example" format="default" sectionFormat="of" derivedContent="Figure 4"/>. Here, the
	  contents of the <tt>access_token</tt> claim have been truncated to improve
	  readability. For the client, the response comprises Access Information
	  that contains the server's public key in the <tt>rs_cnf</tt> parameter.
	  Caching proxies process the Max-Age option in the CoAP response, which
	  has a default value of 60 seconds (<xref target="RFC7252" sectionFormat="of" section="5.6.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-5.6.1" derivedContent="RFC7252"/>).
	  The authorization server <bcp14>SHOULD</bcp14>
	  adjust the Max-Age option such that it does not exceed the
	  <tt>expires_in</tt> parameter to avoid stale responses.</t>
          <figure anchor="rpk-authorization-response-example" align="left" suppress-title="false" pn="figure-4">
            <name slugifiedName="name-access-token-response-examp">Access Token Response Example for RPK Mode</name>
            <sourcecode type="cbor-diag" markers="false" pn="section-3.2.1-9.1">
   2.01 Created
   Content-Format: application/ace+cbor
   Max-Age: 3560
   Payload:
   {
     / access_token / 1 : b64'SlAV32hk'/...
      (remainder of CWT omitted for brevity;
      CWT contains the client's RPK in the cnf claim)/,
     / expires_in /  2 : 3600,
     / rs_cnf /     41 : {
       / COSE_Key /  1 : {
         / kty /  1 : / EC2 /   2,
         / crv / -1 : / P-256 / 1,
         / x /   -2 : h'd7cc072de2205bdc1537/.../',
         / y /   -3 : h'f95e1d4b851a2cc80fff/.../'
       }
     }
   }
</sourcecode>
          </figure>
        </section>
        <section anchor="rpk-dtls-channel" numbered="true" toc="include" removeInRFC="false" pn="section-3.2.2">
          <name slugifiedName="name-dtls-channel-setup-between-">DTLS Channel Setup between the Client and Resource Server</name>
          <t indent="0" pn="section-3.2.2-1">Before the client initiates the DTLS handshake with the resource
server, the client <bcp14>MUST</bcp14> send a <tt>POST</tt> request containing the obtained
access token to the authz-info resource hosted by the resource
server. After the client receives a confirmation that the resource
server has accepted the access token, it proceeds to establish a
new DTLS channel with the resource server.  The client <bcp14>MUST</bcp14> use its
correct public key in the DTLS handshake. If the authorization server
has specified a <tt>cnf</tt> field in the access token response, the client
<bcp14>MUST</bcp14> use this key. Otherwise, the client <bcp14>MUST</bcp14> use the public key that
it specified in the <tt>req_cnf</tt> of the access token request. The client
<bcp14>MUST</bcp14> specify this public key in the SubjectPublicKeyInfo structure of
the DTLS handshake, as described in <xref target="RFC7250" format="default" sectionFormat="of" derivedContent="RFC7250"/>.</t>
          <t indent="0" pn="section-3.2.2-2">If the client does not have the keying material belonging to the
public key, the client <bcp14>MAY</bcp14> try to send an access token request to the
AS, where the client specifies its public key in the <tt>req_cnf</tt> parameter. If
the AS still specifies a public key in the response that the client
does not have, the client <bcp14>SHOULD</bcp14> re-register with the authorization
server to establish a new client public key. This process is out of
scope for this document.</t>
          <t indent="0" pn="section-3.2.2-3">To be consistent with <xref target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/>, which allows for shortened Message Authentication Code (MAC) tags
in constrained environments,
an implementation that supports the RPK mode of this profile <bcp14>MUST</bcp14> at
least support the cipher suite
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 <xref target="RFC7251" format="default" sectionFormat="of" derivedContent="RFC7251"/>.
As discussed in <xref target="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/>, new Elliptic Curve Cryptography (ECC)
  curves have been defined recently that are considered superior to 
  the so-called NIST curves. Implementations of this profile <bcp14>MUST</bcp14> therefore
  implement support for curve25519 (cf. <xref target="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>, <xref target="RFC8422" format="default" sectionFormat="of" derivedContent="RFC8422"/>),
  as this curve is said to be efficient and less dangerous,
  regarding implementation errors, than the secp256r1 curve mandated in
  <xref target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/>.</t>
          <t indent="0" pn="section-3.2.2-4">The resource server <bcp14>MUST</bcp14> check if the access token is still valid, if
the resource server is the intended destination (i.e., the audience)
of the token, and if the token was issued by an authorized
authorization server (see also
<xref target="RFC9200" sectionFormat="of" section="5.10.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.10.1.1" derivedContent="RFC9200"/>).
The access token is constructed by the
authorization server such that the resource server can associate the
access token with the client's public key.  The <tt>cnf</tt> claim <bcp14>MUST</bcp14>
contain either the client's RPK or, if the key is already known by the
resource server (e.g., from previous communication), a reference to
this key. If the authorization server has no certain knowledge that
the client's key is already known to the resource server, the client's
public key <bcp14>MUST</bcp14> be included in the access token's <tt>cnf</tt> parameter. If
CBOR web tokens <xref target="RFC8392" format="default" sectionFormat="of" derivedContent="RFC8392"/> are used (as recommended in
<xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/>), keys <bcp14>MUST</bcp14> be encoded as specified in
<xref target="RFC8747" format="default" sectionFormat="of" derivedContent="RFC8747"/>. A resource server <bcp14>MUST</bcp14> have the capacity to store one
access token for every proof-of-possession key of every authorized client.</t>
          <t indent="0" pn="section-3.2.2-5">The raw public key used in the DTLS handshake with the client <bcp14>MUST</bcp14>
belong to the resource server. If the resource server has several raw
public keys, it needs to determine which key to use. The authorization
server can help with this decision by including a <tt>cnf</tt> parameter in
the access token that is associated with this communication.  In this
case, the resource server <bcp14>MUST</bcp14> use the information from the <tt>cnf</tt>
field to select the proper keying material.</t>
          <t indent="0" pn="section-3.2.2-6">Thus, the handshake only finishes if the client and the resource
server are able to use their respective keying material.</t>
        </section>
      </section>
      <section anchor="psk-mode" numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-pre-shared-key-mode">Pre-shared Key Mode</name>
        <t indent="0" pn="section-3.3-1">When the client uses pre-shared key authentication, the procedure is
as described in the following.</t>
        <section anchor="access-token-retrieval-from-the-authorization-server-1" numbered="true" toc="include" removeInRFC="false" pn="section-3.3.1">
          <name slugifiedName="name-access-token-retrieval-from-">Access Token Retrieval from the Authorization Server</name>
          <t indent="0" pn="section-3.3.1-1">To retrieve an access token for the resource that the client wants to
access, the client <bcp14>MAY</bcp14> include a <tt>req_cnf</tt> object carrying an identifier
for a symmetric key in its access token request to the authorization
server.  This identifier can be used by the authorization server to
determine the shared secret to construct the proof-of-possession
token.  The authorization server <bcp14>MUST</bcp14> check if the identifier refers
to a symmetric key that was previously generated by the authorization
server as a shared secret for the communication between this client
and the resource server. If no such symmetric key was found, the
authorization server <bcp14>MUST</bcp14> generate a new symmetric key that is
returned in its response to the client.</t>
          <t indent="0" pn="section-3.3.1-2">The authorization server <bcp14>MUST</bcp14> determine the authorization rules
	  for the client it communicates with, as defined by the resource owner, and
	  generate the access token accordingly.  If the authorization server
	  authorizes the client, it returns an AS-to-client response. If the
	  <tt>ace_profile</tt> parameter is present, it is set to <tt>coap_dtls</tt>. The
	  authorization server <bcp14>MUST</bcp14> ascertain that the access token is
	  generated for the resource server that the client wants to communicate
	  with. Also, the authorization server <bcp14>MUST</bcp14> protect the integrity of
	  the access token to ensure that the resource server can detect
	  unauthorized changes.  If the token contains confidential data, such as
	  the symmetric key, the confidentiality of the token <bcp14>MUST</bcp14> also be
	  protected. Depending on the requested token type and algorithm in the
	  access token request, the authorization server adds Access Information
	  to the response that provides the client with sufficient information
	  to set up a DTLS channel with the resource server. The authorization
	  server adds a <tt>cnf</tt> parameter to the Access Information carrying a
	  <tt>COSE_Key</tt> object that informs the client about the shared secret that
	  is to be used between the client and the resource server. To convey
	  the same secret to the resource server, the authorization server
	  can include it directly in the access token by means of the <tt>cnf</tt>
	  claim or provide sufficient information to enable the resource
	  server to derive the shared secret from the access token. As an
	  alternative, the resource server <bcp14>MAY</bcp14> use token introspection to
	  retrieve the keying material for this access token directly from the
	  authorization server.</t>
          <t indent="0" pn="section-3.3.1-3">An example access token request for an access token with a symmetric
proof-of-possession key is illustrated in <xref target="at-request" format="default" sectionFormat="of" derivedContent="Figure 5"/>.</t>
          <figure anchor="at-request" align="left" suppress-title="false" pn="figure-5">
            <name slugifiedName="name-example-access-token-reques">Example Access Token Request, (Implicit) Symmetric PoP Key</name>
            <sourcecode type="cbor-diag" markers="false" pn="section-3.3.1-4.1">
   POST coaps://as.example.com/token
   Content-Format: application/ace+cbor
   Payload:
   {
     / audience / 5 : "smokeSensor1807"
   }
</sourcecode>
          </figure>
          <t indent="0" pn="section-3.3.1-5">A corresponding example access token response is illustrated in
<xref target="at-response" format="default" sectionFormat="of" derivedContent="Figure 6"/>.  In this example, the authorization server returns a
2.01 response containing a new access token (truncated to improve
readability) and information for the client, including the symmetric
key in the <tt>cnf</tt> claim.  The information is transferred as a CBOR data
structure as specified in <xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/>.</t>
          <figure anchor="at-response" align="left" suppress-title="false" pn="figure-6">
            <name slugifiedName="name-example-access-token-respon">Example Access Token Response, Symmetric PoP Key</name>
            <sourcecode type="cbor-diag" markers="false" pn="section-3.3.1-6.1">
   2.01 Created
   Content-Format: application/ace+cbor
   Max-Age: 85800
   Payload:
   {
      / access_token /  1 : h'd08343a1/...
        (remainder of CWT omitted for brevity)/',
      / token_type /   34 : / PoP / 2,
      / expires_in /    2 : 86400,
      / ace_profile /  38 : / coap_dtls / 1,
      / cnf /           8 : {
        / COSE_Key / 1 : {
          / kty / 1 : / symmetric / 4,
          / kid / 2 : h'3d027833fc6267ce',
          / k /  -1 : h'73657373696f6e6b6579'
        }
      }
   }
</sourcecode>
          </figure>
          <t indent="0" pn="section-3.3.1-7">The access token also comprises a <tt>cnf</tt> claim. This claim usually
contains a <tt>COSE_Key</tt> object <xref target="RFC8152" format="default" sectionFormat="of" derivedContent="RFC8152"/> that carries either the symmetric key
itself or a key identifier that can be used by the resource server to
determine the secret key it shares with the client. If the access
token carries a symmetric key, the access token <bcp14>MUST</bcp14> be encrypted
using a <tt>COSE_Encrypt0</tt> structure (see <xref target="RFC8392" sectionFormat="of" section="7.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8392#section-7.1" derivedContent="RFC8392"/>). The
authorization server <bcp14>MUST</bcp14> use
the keying material shared with the resource server to encrypt the
token.</t>
          <t indent="0" pn="section-3.3.1-8">The <tt>cnf</tt> structure in the access token is provided in <xref target="kdf-cnf" format="default" sectionFormat="of" derivedContent="Figure 7"/>.</t>
          <figure anchor="kdf-cnf" align="left" suppress-title="false" pn="figure-7">
            <name slugifiedName="name-access-token-without-keying">Access Token without Keying Material</name>
            <sourcecode type="cbor-diag" markers="false" pn="section-3.3.1-9.1">
/ cnf / 8 : {
  / COSE_Key / 1 : {
    / kty / 1 : / symmetric / 4,
    / kid / 2 : h'3d027833fc6267ce'
  }
}
</sourcecode>
          </figure>
          <t indent="0" pn="section-3.3.1-10">A response that declines any operation on the requested resource is
constructed according to <xref target="RFC6749" sectionFormat="of" section="5.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6749#section-5.2" derivedContent="RFC6749"/>
(cf. <xref target="RFC9200" sectionFormat="of" section="5.8.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.8.3" derivedContent="RFC9200"/>). <xref target="token-reject" format="default" sectionFormat="of" derivedContent="Figure 8"/>
shows an example for a request that has been rejected due to invalid
request parameters.</t>
          <figure anchor="token-reject" align="left" suppress-title="false" pn="figure-8">
            <name slugifiedName="name-example-access-token-respons">Example Access Token Response with Reject</name>
            <sourcecode type="cbor-diag" markers="false" pn="section-3.3.1-11.1">
    4.00 Bad Request
    Content-Format: application/ace+cbor
    Payload:
    {
      / error / 30 : / invalid_request / 1
    }
</sourcecode>
          </figure>
          <t indent="0" pn="section-3.3.1-12">The method for how the resource server determines the symmetric key
from an access token containing only a key identifier is
application specific; the remainder of this section provides one
example.</t>
          <t indent="0" pn="section-3.3.1-13">The authorization server and the resource server are assumed to share
a key derivation key used to derive the symmetric key shared with the
client from the key identifier in the access token.  The key
derivation key may be derived from some other secret key shared
between the authorization server and the resource server. This key
needs to be securely stored and processed in the same way as the key
used to protect the communication between the authorization server and
the resource server.</t>
          <t indent="0" pn="section-3.3.1-14">Knowledge of the symmetric key shared with the client must not reveal
any information about the key derivation key or other secret keys
shared between the authorization server and resource server.</t>
          <t indent="0" pn="section-3.3.1-15">In order to generate a new symmetric key to be used by the client and
resource server, the authorization server generates a new key
identifier that <bcp14>MUST</bcp14> be unique among all key identifiers used by the
authorization server for this resource server. The authorization server then uses the key
derivation key shared with the resource server to derive the symmetric
key, as specified below.  Instead of providing the keying material in
the access token, the authorization server includes the key identifier
in the <tt>kid</tt> parameter (see <xref target="kdf-cnf" format="default" sectionFormat="of" derivedContent="Figure 7"/>). This key identifier enables
the resource server to calculate the symmetric key used for the
communication with the client using the key derivation key and a key derivation function (KDF)
to be defined by the application, for example, HKDF-SHA-256. The key
identifier picked by the authorization server <bcp14>MUST</bcp14> be unique for
each access token where a unique symmetric key is required.</t>
          <t indent="0" pn="section-3.3.1-16">In this example, the HMAC-based key derivation function (HKDF) consists of the composition of the HKDF-Extract
and HKDF-Expand steps <xref target="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/>. The symmetric key is derived from the
key identifier, the key derivation key, and other data:</t>
          <t indent="3" pn="section-3.3.1-17">OKM = HKDF(salt, IKM, info, L),</t>
          <t indent="0" pn="section-3.3.1-18">where:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.3.1-19">
            <li pn="section-3.3.1-19.1">OKM, the output keying material, is the derived symmetric key</li>
            <li pn="section-3.3.1-19.2">salt is the empty byte string</li>
            <li pn="section-3.3.1-19.3">IKM, the input keying material, is the key derivation key, as defined
	    above</li>
            <li pn="section-3.3.1-19.4">
              <t indent="0" pn="section-3.3.1-19.4.1">info is the serialization of a CBOR array consisting of <xref target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/>:</t>
              <sourcecode type="cddl" markers="false" pn="section-3.3.1-19.4.2">
      info = [
        type : tstr,
        L    : uint,
        access_token : bytes
      ]
</sourcecode>
              <t indent="0" pn="section-3.3.1-19.4.3">where:</t>
              <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.3.1-19.4.4">
                <li pn="section-3.3.1-19.4.4.1">type is set to the constant text string "ACE-CoAP-DTLS-key-derivation"</li>
                <li pn="section-3.3.1-19.4.4.2">L is the size of the symmetric key in bytes</li>
                <li pn="section-3.3.1-19.4.4.3">access_token is the content of the <tt>access_token</tt> field, as
	    transferred from the authorization server to the resource server.</li>
              </ul>
            </li>
          </ul>
          <t indent="0" pn="section-3.3.1-20">All CBOR data types are encoded in CBOR using preferred serialization
	  and deterministic encoding, as specified in <xref target="RFC8949" sectionFormat="of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-4" derivedContent="RFC8949"/>.
	  In particular, this implies that the <tt>type</tt> and <tt>L</tt> components use the
	  minimum length encoding. The content of the <tt>access_token</tt> field is
	  treated as opaque data for the purpose of key derivation.</t>
          <t indent="0" pn="section-3.3.1-21">Use of a unique (per-resource-server) <tt>kid</tt> and the use of a key
	  derivation IKM that <bcp14>MUST</bcp14> be unique
	  per AS/RS pair, as specified above, will ensure that
	  the derived key is not shared across multiple clients.  However, to provide
	  variation in the derived key across different tokens used by the same client, it
	  is additionally <bcp14>RECOMMENDED</bcp14> to include the <tt>iat</tt> claim and either the
	  <tt>exp</tt> or <tt>exi</tt> claims in the access token.</t>
        </section>
        <section anchor="psk-dtls-channel" numbered="true" toc="include" removeInRFC="false" pn="section-3.3.2">
          <name slugifiedName="name-dtls-channel-setup-between-t">DTLS Channel Setup between the Client and Resource Server</name>
          <t indent="0" pn="section-3.3.2-1">When a client receives an access token response from an authorization
server, the client <bcp14>MUST</bcp14> check if the access token response is bound to
a certain, previously sent access token request, as the request may
specify the resource server with which the client wants to
communicate.</t>
          <t indent="0" pn="section-3.3.2-2">The client checks if the payload of the access token response contains
	  an <tt>access_token</tt> parameter and a <tt>cnf</tt> parameter. With this
	  information, the client can initiate the establishment of a new DTLS
	  channel with a resource server. To use DTLS with pre-shared keys, the
	  client follows the PSK key exchange algorithm specified in <xref target="RFC4279" sectionFormat="of" section="2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4279#section-2" derivedContent="RFC4279"/>, using the key conveyed in the <tt>cnf</tt>
	  parameter of the AS response as a PSK when constructing the premaster secret. To be
	  consistent with the recommendations in <xref target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/>, a
	  client in the PSK mode <bcp14>MUST</bcp14> support the cipher suite
	  TLS_PSK_WITH_AES_128_CCM_8 <xref target="RFC6655" format="default" sectionFormat="of" derivedContent="RFC6655"/>.</t>
          <t indent="0" pn="section-3.3.2-3">In PreSharedKey mode, the knowledge of the shared secret by the client
	  and the resource server is used for mutual authentication between both
	  peers. Therefore, the resource server must be able to determine the
	  shared secret from the access token. Following the general ACE
	  authorization framework, the client can upload the access token to the
	  resource server's authz-info resource before starting the DTLS
	  handshake.  The client then needs to indicate during the DTLS
	  handshake which previously uploaded access token it intends to use.
	  To do so, it <bcp14>MUST</bcp14> create a <tt>COSE_Key</tt> structure with the
	  <tt>kid</tt> that was conveyed in the <tt>rs_cnf</tt> claim in the token response
	  from the authorization server and the key type <tt>symmetric</tt>.  This structure
	  then is included as the only element in the <tt>cnf</tt> structure whose CBOR
	  serialization is used as value for <tt>psk_identity</tt>, as shown in <xref target="psk_identity-cnf" format="default" sectionFormat="of" derivedContent="Figure 9"/>.</t>
          <figure anchor="psk_identity-cnf" align="left" suppress-title="false" pn="figure-9">
            <name slugifiedName="name-access-token-containing-a-s">Access Token Containing a Single <tt>kid</tt> Parameter</name>
            <sourcecode type="cbor-diag" markers="false" pn="section-3.3.2-4.1">
{ / cnf / 8 : {
   / COSE_Key / 1 : {
      / kty / 1 : / symmetric / 4,
      / kid / 2 : h'3d027833fc6267ce'
    }
  }
}
</sourcecode>
          </figure>
          <t indent="0" pn="section-3.3.2-5">The actual CBOR serialization for the data structure from
	  <xref target="psk_identity-cnf" format="default" sectionFormat="of" derivedContent="Figure 9"/> as a sequence of bytes in
	  hexadecimal notation will be:</t>
          <sourcecode type="" markers="false" pn="section-3.3.2-6">
A1 08 A1 01 A2 01 04 02 48 3D 02 78 33 FC 62 67 CE
</sourcecode>
          <t indent="0" pn="section-3.3.2-7">As an alternative to the access token upload, the client can provide
the most recent access token in the <tt>psk_identity</tt> field of the
ClientKeyExchange message. To do so, the client <bcp14>MUST</bcp14> treat the
contents of the <tt>access_token</tt> field from the AS-to-client response as
opaque data, as specified in <xref target="RFC7925" sectionFormat="of" section="4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7925#section-4.2" derivedContent="RFC7925"/>, and not perform
any recoding. This allows the resource server to retrieve the shared
secret directly from the <tt>cnf</tt> claim of the access token.</t>
          <t indent="0" pn="section-3.3.2-8">DTLS 1.3 <xref target="RFC9147" format="default" sectionFormat="of" derivedContent="RFC9147"/> does not use the ClientKeyExchange message; for DTLS 1.3,
   the access token is placed in the <tt>identity</tt> field of a <tt>PSKIdentity</tt>
   within the <tt>PreSharedKeyExtension</tt> of the <tt>ClientHello</tt>.</t>
          <t indent="0" pn="section-3.3.2-9">If a resource server receives a ClientKeyExchange message that
contains a <tt>psk_identity</tt> with a length greater than zero, it <bcp14>MUST</bcp14>
parse the contents of the <tt>psk_identity</tt> field as a CBOR data structure
and process the contents as following:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.3.2-10">
            <li pn="section-3.3.2-10.1">If the data contains a <tt>cnf</tt> field with a <tt>COSE_Key</tt> structure with
a <tt>kid</tt>, the resource server continues the DTLS handshake with the
associated key that corresponds to this kid.</li>
            <li pn="section-3.3.2-10.2">If the data comprises additional CWT information, this information
must be stored as an access token for this DTLS association before
continuing with the DTLS handshake.</li>
          </ul>
          <t indent="0" pn="section-3.3.2-11">If the contents of the <tt>psk_identity</tt> do not yield sufficient
information to select a valid access token for the requesting client,
the resource server aborts the DTLS handshake with an
<tt>illegal_parameter</tt> alert.</t>
          <t indent="0" pn="section-3.3.2-12">When the resource server receives an access token, it <bcp14>MUST</bcp14> check if
the access token is still valid, if the resource server is the
intended destination (i.e., the audience of the token), and if the
token was issued by an authorized authorization server.  This
specification implements access tokens as proof-of-possession tokens.
Therefore, the access token is bound to a symmetric PoP key
that is used as a shared secret between the client and the resource
server. A resource server <bcp14>MUST</bcp14> have the capacity to store one
access token for every proof-of-possession key of every authorized client.
The resource server may use token introspection <xref target="RFC7662" format="default" sectionFormat="of" derivedContent="RFC7662"/> on
the access token to retrieve more information about the specific
token. The use of introspection is out of scope for this
specification.</t>
          <t indent="0" pn="section-3.3.2-13">While the client can retrieve the shared secret from the contents of
the <tt>cnf</tt> parameter in the AS-to-client response, the resource server
uses the information contained in the <tt>cnf</tt> claim of the access token
to determine the actual secret when no explicit <tt>kid</tt> was provided in
the <tt>psk_identity</tt> field. If key derivation is used, the <tt>cnf</tt> claim
<bcp14>MUST</bcp14> contain a <tt>kid</tt> parameter to be used by the server as the IKM for
key derivation, as described above.</t>
        </section>
      </section>
      <section anchor="resource-access" numbered="true" toc="include" removeInRFC="false" pn="section-3.4">
        <name slugifiedName="name-resource-access">Resource Access</name>
        <t indent="0" pn="section-3.4-1">Once a DTLS channel has been established as described in either Sections <xref target="rpk-mode" format="counter" sectionFormat="of" derivedContent="3.2"/>
or <xref target="psk-mode" format="counter" sectionFormat="of" derivedContent="3.3"/>, respectively, the client is authorized to access
resources covered by the access token it has uploaded to the
authz-info resource that is hosted by the resource server.</t>
        <t indent="0" pn="section-3.4-2">With the successful establishment of the DTLS channel, the client and
the resource server have proven that they can use their respective
keying material. An access token that is bound to the client's keying
material is associated with the channel. According to
<xref target="RFC9200" sectionFormat="of" section="5.10.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.10.1" derivedContent="RFC9200"/>, there should be only one access token
for each client. New access tokens issued by the authorization server
<bcp14>SHOULD</bcp14> replace previously issued access tokens for the
respective client. The resource server therefore needs a common
understanding with the authorization server about how access tokens are
ordered. The authorization server may, e.g., specify a <tt>cti</tt> claim for
the access token (see <xref target="RFC9200" sectionFormat="of" section="5.9.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.9.2" derivedContent="RFC9200"/>) to
employ a strict order.</t>
        <t indent="0" pn="section-3.4-3">Any request that the resource server receives on a DTLS channel that
is tied to an access token via its keying material 
<bcp14>MUST</bcp14> be checked against the authorization rules that can be determined
with the access token. The resource server
<bcp14>MUST</bcp14> check for every request if the access token is still valid.
If the token has expired, the resource server <bcp14>MUST</bcp14> remove it.
Incoming CoAP requests that are not authorized with respect
to any access token that is associated with the client <bcp14>MUST</bcp14> be
rejected by the resource server with a 4.01 response. The response
<bcp14>SHOULD</bcp14> include AS Request Creation Hints, as described in
<xref target="RFC9200" sectionFormat="of" section="5.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.2" derivedContent="RFC9200"/>.</t>
        <t indent="0" pn="section-3.4-4">The resource server <bcp14>MUST NOT</bcp14> accept an incoming CoAP request as
authorized if any of the following fails:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3.4-5">
	  <li pn="section-3.4-5.1" derivedCounter="1.">The message was received on a secure channel that has been
	  established using the procedure defined in this document.</li>
          <li pn="section-3.4-5.2" derivedCounter="2.">The authorization information tied to the sending client is valid.</li>
          <li pn="section-3.4-5.3" derivedCounter="3.">The request is destined for the resource server.</li>
          <li pn="section-3.4-5.4" derivedCounter="4.">The resource URI specified in the request is covered by the
	  authorization information.</li>
          <li pn="section-3.4-5.5" derivedCounter="5.">The request method is an authorized action on the resource with
	  respect to the authorization information.</li>
        </ol>
        <t indent="0" pn="section-3.4-6">Incoming CoAP requests received on a secure DTLS channel that are not
	thus authorized <bcp14>MUST</bcp14> be
	rejected according to <xref target="RFC9200" sectionFormat="of" section="5.10.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.10.2" derivedContent="RFC9200"/>:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3.4-7">
	  <li pn="section-3.4-7.1" derivedCounter="1.">with response code 4.03 (Forbidden) when the resource URI specified
	  in the request is not covered by the authorization information and</li>
          <li pn="section-3.4-7.2" derivedCounter="2.">with response code 4.05 (Method Not Allowed) when the resource URI
	  specified in the request is covered by the authorization information but
	  not the requested action.</li>
        </ol>
        <t indent="0" pn="section-3.4-8">The client <bcp14>MUST</bcp14> ascertain that its keying material is still valid
before sending a request or processing a response. If the client
recently has updated the access token (see <xref target="update" format="default" sectionFormat="of" derivedContent="Section 4"/>), it must be
prepared that its request is still handled according to the previous
authorization rules, as there is no strict ordering between access
token uploads and resource access messages. See also
<xref target="multiple-access-tokens" format="default" sectionFormat="of" derivedContent="Section 7.2"/> for a discussion of access token
processing.</t>
        <t indent="0" pn="section-3.4-9">If the client gets an error response
containing AS Request Creation Hints (cf. <xref target="RFC9200" sectionFormat="of" section="5.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.3" derivedContent="RFC9200"/>)
as a response to its requests, it <bcp14>SHOULD</bcp14> request a new access token from
the authorization server in order to continue communication with the
resource server.</t>
        <t indent="0" pn="section-3.4-10">Unauthorized requests that have been received over a DTLS session
<bcp14>SHOULD</bcp14> be treated as nonfatal by the resource server, i.e., the DTLS
session <bcp14>SHOULD</bcp14> be kept alive until the associated access token has
expired.</t>
      </section>
    </section>
    <section anchor="update" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-dynamic-update-of-authoriza">Dynamic Update of Authorization Information</name>
      <t indent="0" pn="section-4-1">Resource servers must only use a new access token to update the
authorization information for a DTLS session if the keying material
that is bound to the token is the same that was used in the DTLS
handshake. By associating the access tokens with the identifier of an
existing DTLS session, the authorization information can be updated
without changing the cryptographic keys for the DTLS communication
between the client and the resource server, i.e., an existing session
can be used with updated permissions.</t>
      <t indent="0" pn="section-4-2">The client can therefore update the authorization information stored at the
resource server at any time without changing an established DTLS
session. To do so, the client requests a
new access token from the authorization server 
for the intended action on the respective resource
and uploads this access token to the authz-info resource on the
resource server.</t>
      <t indent="0" pn="section-4-3"><xref target="update-overview" format="default" sectionFormat="of" derivedContent="Figure 10"/> depicts the message flow where the client requests
a new access token after a security association between the client and
the resource server has been established using this protocol. If the
client wants to update the authorization information, the token
request <bcp14>MUST</bcp14> specify the key identifier of the proof-of-possession key
used for the existing DTLS channel between the client and the resource
server in the <tt>kid</tt> parameter of the client-to-AS request. The
authorization server <bcp14>MUST</bcp14> verify that the specified <tt>kid</tt> denotes a
valid verifier for a proof-of-possession token that has previously
been issued to the requesting client. Otherwise, the client-to-AS
request <bcp14>MUST</bcp14> be declined with the error code <tt>unsupported_pop_key</tt>, as
defined in <xref target="RFC9200" sectionFormat="of" section="5.8.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.8.3" derivedContent="RFC9200"/>.</t>
      <t indent="0" pn="section-4-4">When the authorization server issues a new access token to update
existing authorization information, it <bcp14>MUST</bcp14> include the specified <tt>kid</tt>
parameter in this access token. A resource server <bcp14>MUST</bcp14> replace the
authorization information of any existing DTLS session that is identified
by this key identifier with the updated authorization information.</t>
      <figure anchor="update-overview" align="left" suppress-title="false" pn="figure-10">
        <name slugifiedName="name-overview-of-dynamic-update-">Overview of Dynamic Update Operation</name>
        <artwork name="" type="" align="left" alt="" pn="section-4-5.1">
   C                            RS                   AS
   | &lt;===== DTLS channel =====&gt; |                     |
   |        + Access Token      |                     |
   |                            |                     |
   | --- Token Request  ----------------------------&gt; |
   |                            |                     |
   | &lt;---------------------------- New Access Token - |
   |                           + Access Information   |
   |                            |                     |
   | --- Update /authz-info --&gt; |                     |
   |     New Access Token       |                     |
   |                            |                     |
   | == Authorized Request ===&gt; |                     |
   |                            |                     |
   | &lt;=== Protected Resource == |                     |
</artwork>
      </figure>
    </section>
    <section anchor="teardown" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-token-expiration">Token Expiration</name>
      <t indent="0" pn="section-5-1">The resource server <bcp14>MUST</bcp14> delete access tokens that are no longer
      valid.  DTLS associations that have been set up in accordance with
      this profile are always tied to specific tokens (which may be
      exchanged with a dynamic update, as described in <xref target="update" format="default" sectionFormat="of" derivedContent="Section 4"/>). As tokens
      may become invalid at any time (e.g., because they have expired), the
      association may become useless at some point.  A resource server therefore
      <bcp14>MUST</bcp14> terminate existing DTLS association after the last access token
      associated with this association has expired.</t>
      <t indent="0" pn="section-5-2">As specified in <xref target="RFC9200" sectionFormat="of" section="5.10.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.10.3" derivedContent="RFC9200"/>,
the resource server <bcp14>MUST</bcp14> notify the client with an error response with
code 4.01 (Unauthorized) for any long-running request before
terminating the association.</t>
    </section>
    <section anchor="as-commsec" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-secure-communication-with-a">Secure Communication with an Authorization Server</name>
      <t indent="0" pn="section-6-1">As specified in the ACE framework (Sections <xref target="RFC9200" section="5.8" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.8" derivedContent="RFC9200"/> and <xref target="RFC9200" section="5.9" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.9" derivedContent="RFC9200"/> of
<xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/>), the requesting entity (the resource
server and/or the client) and the authorization server communicate via
the token endpoint or introspection endpoint.  The use of CoAP and
DTLS for this communication is <bcp14>RECOMMENDED</bcp14> in this profile. Other
protocols fulfilling the security requirements defined in <xref target="RFC9200" sectionFormat="of" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5" derivedContent="RFC9200"/> <bcp14>MAY</bcp14> be used instead.</t>
      <t indent="0" pn="section-6-2">How credentials (e.g., PSK, RPK, X.509 cert) for using DTLS with the
authorization server are established is out of scope for this profile.</t>
      <t indent="0" pn="section-6-3">If other means of securing the communication with the authorization
server are used, the communication security requirements from <xref target="RFC9200" sectionFormat="of" section="6.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-6.2" derivedContent="RFC9200"/> remain applicable.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework
<xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/>. As it follows this framework's general
approach, the general security considerations from <xref target="RFC9200" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-6" derivedContent="RFC9200"/> also apply to this profile.</t>
      <t indent="0" pn="section-7-2">The authorization server must ascertain that the keying material for
the client that it provides to the resource server actually is
associated with this client.  Malicious clients may hand over access
tokens containing their own access permissions to other entities. This
problem cannot be completely eliminated. Nevertheless, in RPK mode, it
should not be possible for clients to request access tokens for
arbitrary public keys; if the client can cause the authorization
server to issue a token for a public key without proving possession of
the corresponding private key, this allows for identity misbinding
attacks, where the issued token is usable by an entity other than the
intended one. At some point, the authorization server therefore needs
to validate that the client can actually use the private key
corresponding to the client's public key.</t>
      <t indent="0" pn="section-7-3">When using pre-shared keys provisioned by the authorization server,
the security level depends on the randomness of PSKs and the security
of the TLS cipher suite and key exchange algorithm.  As this
specification targets constrained environments, message payloads
exchanged between the client and the resource server are expected to
be small and rare.  CoAP <xref target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/> mandates the implementation of
cipher suites with abbreviated, 8-byte tags for message integrity
protection. For consistency, this profile requires implementation of
the same cipher suites. For application scenarios where the cost of
full-width authentication tags is low compared to the overall amount
of data being transmitted, the use of cipher suites with 16-byte
integrity protection tags is preferred.</t>
      <t indent="0" pn="section-7-4">The PSK mode of this profile offers a distribution mechanism to convey
      authorization tokens together with a shared secret to a client and a
      server. As this specification aims at constrained devices and uses
      CoAP <xref target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/> as the transfer protocol, at least the
      cipher suite TLS_PSK_WITH_AES_128_CCM_8 <xref target="RFC6655" format="default" sectionFormat="of" derivedContent="RFC6655"/>
      should be supported. The
      access tokens and the corresponding shared secrets generated by the
      authorization server are expected to be sufficiently short-lived to
      provide similar forward-secrecy properties to using ephemeral
      Diffie-Hellman (DHE) key exchange mechanisms. For longer-lived access
      tokens, DHE cipher suites should be used, i.e., cipher suites of the
      form TLS_DHE_PSK_* or TLS_ECDHE_PSK_*.</t>
      <t indent="0" pn="section-7-5">Constrained devices that use DTLS <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/> <xref target="RFC9147" format="default" sectionFormat="of" derivedContent="RFC9147"/> are inherently
vulnerable to Denial of Service (DoS) attacks, as the handshake
protocol requires creation of internal state within the device.  This
is specifically of concern where an adversary is able to intercept the
initial cookie exchange and interject forged messages with a valid
cookie to continue with the handshake. A similar issue exists with the
unprotected authorization information endpoint when the resource
server needs to keep valid access tokens for a long time. Adversaries
could fill up the constrained resource server's internal storage for a
very long time with intercepted or otherwise retrieved valid access
tokens.  To mitigate against this, the resource server should set a
time boundary until an access token that has not been used until then
will be deleted.</t>
      <t indent="0" pn="section-7-6">The protection of access tokens that are stored in the authorization
information endpoint depends on the keying material that is used between
the authorization server and the resource server; the resource server
must ensure that it processes only access tokens that are integrity protected (and encrypted) by an authorization server that is authorized
to provide access tokens for the resource server.</t>
      <section anchor="reuse-of-existing-sessions" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-reuse-of-existing-sessions">Reuse of Existing Sessions</name>
        <t indent="0" pn="section-7.1-1">To avoid the overhead of a repeated DTLS handshake, <xref target="RFC7925" format="default" sectionFormat="of" derivedContent="RFC7925"/> recommends
session resumption <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> to reuse session state from
an earlier DTLS association and thus requires client-side
implementation.  In this specification, the DTLS session is subject to
the authorization rules denoted by the access token that was used for
the initial setup of the DTLS association. Enabling session resumption
would require the server to transfer the authorization information
with the session state in an encrypted SessionTicket to the
client. Assuming that the server uses long-lived keying material, this
could open up attacks due to the lack of forward secrecy. Moreover,
using this mechanism, a client can resume a DTLS session without
proving the possession of the PoP key again. Therefore, session
resumption should be used only in combination with reasonably
short-lived PoP keys.</t>
        <t indent="0" pn="section-7.1-2">Since renegotiation of DTLS associations is prone to attacks as well, <xref target="RFC7925" format="default" sectionFormat="of" derivedContent="RFC7925"/> requires that clients decline any
	renegotiation attempt. A server that wants to initiate rekeying therefore
	<bcp14>SHOULD</bcp14> periodically force a full handshake.</t>
      </section>
      <section anchor="multiple-access-tokens" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-multiple-access-tokens">Multiple Access Tokens</name>
        <t indent="0" pn="section-7.2-1">Implementers <bcp14>SHOULD</bcp14> avoid using multiple access tokens for a
client (see also <xref target="RFC9200" sectionFormat="of" section="5.10.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.10.1" derivedContent="RFC9200"/>).</t>
        <t indent="0" pn="section-7.2-2">Even when a single access token per client is used, an attacker could
compromise the dynamic update mechanism for existing DTLS connections
by delaying or reordering packets destined for the authz-info
endpoint. Thus, the order in which operations occur at the resource
server (and thus which authorization info is used to process a given
client request) cannot be guaranteed.  Especially in the presence of
later-issued access tokens that reduce the client's permissions from
the initial access token, it is impossible to guarantee that the
reduction in authorization will take effect prior to the expiration of
the original token.</t>
      </section>
      <section anchor="out-of-band-configuration" numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-out-of-band-configuration">Out-of-Band Configuration</name>
        <t indent="0" pn="section-7.3-1">To communicate securely, the authorization server, the client, and the
resource server require certain information that must be exchanged
outside the protocol flow described in this document. The
authorization server must have obtained authorization information
concerning the client and the resource server that is approved by the
resource owner, as well as corresponding keying material. The resource
server must have received authorization information approved by the
resource owner concerning its authorization managers and the
respective keying material. The client must have obtained
authorization information concerning the authorization server approved
by its owner, as well as the corresponding keying material. Also, the
client's owner must have approved of the client's communication with
the resource server. The client and the authorization server must have
obtained a common understanding about how this resource server is identified
to ensure that the client obtains access tokens and keying material for
the correct resource server. If the client is provided with a raw
public key for the resource server, it must be ascertained to which
resource server (which identifier and authorization information) the
key is associated.  All authorization information and keying material
must be kept up to date.</t>
      </section>
    </section>
    <section anchor="privacy-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t indent="0" pn="section-8-1">This privacy considerations from <xref target="RFC9200" sectionFormat="of" section="7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-7" derivedContent="RFC9200"/> apply also to this profile.</t>
      <t indent="0" pn="section-8-2">An unprotected response to an unauthorized request may disclose
information about the resource server and/or its existing relationship
with the client. It is advisable to include as little information as
possible in an unencrypted response. When a DTLS session between an authenticated
client and the resource server already exists, more detailed
information <bcp14>MAY</bcp14> be included with an error response to provide the
client with sufficient information to react on that particular error.</t>
      <t indent="0" pn="section-8-3">Also, unprotected requests to the resource server may reveal
information about the client, e.g., which resources the client
attempts to request or the data that the client wants to provide to
the resource server. The client <bcp14>SHOULD NOT</bcp14> send confidential data in
an unprotected request.</t>
      <t indent="0" pn="section-8-4">Note that some information might still leak after the DTLS session is
established, due to observable message sizes, the source, and the
destination addresses.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-9-1">The following registration has been made in the "ACE Profiles"
registry, following the procedure specified in
<xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/>.</t>
      <dl newline="false" spacing="compact" indent="3" pn="section-9-2">
        <dt pn="section-9-2.1">Name:</dt>
        <dd pn="section-9-2.2">coap_dtls</dd>
        <dt pn="section-9-2.3">Description:</dt>
        <dd pn="section-9-2.4">Profile for delegating client Authentication and
      Authorization for Constrained Environments by establishing a Datagram
      Transport Layer Security (DTLS) channel between resource-constrained
      nodes.</dd>
        <dt pn="section-9-2.5">CBOR Value:</dt>
        <dd pn="section-9-2.6">1</dd>
        <dt pn="section-9-2.7">Reference:</dt>
        <dd pn="section-9-2.8">RFC 9202</dd>
      </dl>
    </section>
  </middle>
  <back>
    <references pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC4279" target="https://www.rfc-editor.org/info/rfc4279" quoteTitle="true" derivedAnchor="RFC4279">
          <front>
            <title>Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)</title>
            <author fullname="P. Eronen" initials="P." role="editor" surname="Eronen"/>
            <author fullname="H. Tschofenig" initials="H." role="editor" surname="Tschofenig"/>
            <date month="December" year="2005"/>
            <abstract>
              <t indent="0">This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs).  These pre-shared keys are symmetric keys, shared in advance among the communicating parties.  The first set of ciphersuites uses only symmetric key operations for authentication.  The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4279"/>
          <seriesInfo name="DOI" value="10.17487/RFC4279"/>
        </reference>
        <reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6347" quoteTitle="true" derivedAnchor="RFC6347">
          <front>
            <title>Datagram Transport Layer Security Version 1.2</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
            <date month="January" year="2012"/>
            <abstract>
              <t indent="0">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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6347"/>
          <seriesInfo name="DOI" value="10.17487/RFC6347"/>
        </reference>
        <reference anchor="RFC6749" target="https://www.rfc-editor.org/info/rfc6749" quoteTitle="true" derivedAnchor="RFC6749">
          <front>
            <title>The OAuth 2.0 Authorization Framework</title>
            <author fullname="D. Hardt" initials="D." role="editor" surname="Hardt"/>
            <date month="October" year="2012"/>
            <abstract>
              <t indent="0">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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6749"/>
          <seriesInfo name="DOI" value="10.17487/RFC6749"/>
        </reference>
        <reference anchor="RFC7250" target="https://www.rfc-editor.org/info/rfc7250" quoteTitle="true" derivedAnchor="RFC7250">
          <front>
            <title>Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
            <author fullname="P. Wouters" initials="P." role="editor" surname="Wouters"/>
            <author fullname="H. Tschofenig" initials="H." role="editor" surname="Tschofenig"/>
            <author fullname="J. Gilmore" initials="J." surname="Gilmore"/>
            <author fullname="S. Weiler" initials="S." surname="Weiler"/>
            <author fullname="T. Kivinen" initials="T." surname="Kivinen"/>
            <date month="June" year="2014"/>
            <abstract>
              <t indent="0">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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7250"/>
          <seriesInfo name="DOI" value="10.17487/RFC7250"/>
        </reference>
        <reference anchor="RFC7251" target="https://www.rfc-editor.org/info/rfc7251" quoteTitle="true" derivedAnchor="RFC7251">
          <front>
            <title>AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS</title>
            <author fullname="D. McGrew" initials="D." surname="McGrew"/>
            <author fullname="D. Bailey" initials="D." surname="Bailey"/>
            <author fullname="M. Campagna" initials="M." surname="Campagna"/>
            <author fullname="R. Dugal" initials="R." surname="Dugal"/>
            <date month="June" year="2014"/>
            <abstract>
              <t indent="0">This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within Transport Layer Security (TLS) to provide confidentiality and data-origin authentication.  The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments, while at the same time providing a high level of security.  The cipher suites defined in this document use Elliptic Curve Cryptography (ECC) and are advantageous in networks with limited bandwidth.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7251"/>
          <seriesInfo name="DOI" value="10.17487/RFC7251"/>
        </reference>
        <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252" quoteTitle="true" derivedAnchor="RFC7252">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
            <author fullname="K. Hartke" initials="K." surname="Hartke"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="June" year="2014"/>
            <abstract>
              <t indent="0">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.</t>
              <t indent="0">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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7252"/>
          <seriesInfo name="DOI" value="10.17487/RFC7252"/>
        </reference>
        <reference anchor="RFC7925" target="https://www.rfc-editor.org/info/rfc7925" quoteTitle="true" derivedAnchor="RFC7925">
          <front>
            <title>Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things</title>
            <author fullname="H. Tschofenig" initials="H." role="editor" surname="Tschofenig"/>
            <author fullname="T. Fossati" initials="T." surname="Fossati"/>
            <date month="July" year="2016"/>
            <abstract>
              <t indent="0">A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.</t>
              <t indent="0">This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7925"/>
          <seriesInfo name="DOI" value="10.17487/RFC7925"/>
        </reference>
        <reference anchor="RFC8152" target="https://www.rfc-editor.org/info/rfc8152" quoteTitle="true" derivedAnchor="RFC8152">
          <front>
            <title>CBOR Object Signing and Encryption (COSE)</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="July" year="2017"/>
            <abstract>
              <t indent="0">Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size.  There is a need for the ability to have basic security services defined 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8152"/>
          <seriesInfo name="DOI" value="10.17487/RFC8152"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8392" target="https://www.rfc-editor.org/info/rfc8392" quoteTitle="true" derivedAnchor="RFC8392">
          <front>
            <title>CBOR Web Token (CWT)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <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="May" year="2018"/>
            <abstract>
              <t indent="0">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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8392"/>
          <seriesInfo name="DOI" value="10.17487/RFC8392"/>
        </reference>
        <reference anchor="RFC8422" target="https://www.rfc-editor.org/info/rfc8422" quoteTitle="true" derivedAnchor="RFC8422">
          <front>
            <title>Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier</title>
            <author fullname="Y. Nir" initials="Y." surname="Nir"/>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <author fullname="M. Pegourie-Gonnard" initials="M." surname="Pegourie-Gonnard"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.</t>
              <t indent="0">This document obsoletes RFC 4492.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8422"/>
          <seriesInfo name="DOI" value="10.17487/RFC8422"/>
        </reference>
        <reference anchor="RFC8747" target="https://www.rfc-editor.org/info/rfc8747" quoteTitle="true" derivedAnchor="RFC8747">
          <front>
            <title>Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="L. Seitz" initials="L." surname="Seitz"/>
            <author fullname="G. Selander" initials="G." surname="Selander"/>
            <author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <date month="March" year="2020"/>
            <abstract>
              <t indent="0">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).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8747"/>
          <seriesInfo name="DOI" value="10.17487/RFC8747"/>
        </reference>
        <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949" quoteTitle="true" derivedAnchor="RFC8949">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="December" year="2020"/>
            <abstract>
              <t indent="0">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.</t>
              <t indent="0">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.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="94"/>
          <seriesInfo name="RFC" value="8949"/>
          <seriesInfo name="DOI" value="10.17487/RFC8949"/>
        </reference>
        <reference anchor="RFC9147" target="https://www.rfc-editor.org/info/rfc9147" quoteTitle="true" derivedAnchor="RFC9147">
          <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 indent="0">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.</t>
              <t indent="0">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.</t>
              <t indent="0">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/rfc9200" quoteTitle="true" derivedAnchor="RFC9200">
          <front>
            <title>Authentication and Authorization for Constrained Environments (ACE) Using the OAuth 2.0 Framework (ACE-OAuth)</title>
            <author initials="L" surname="Seitz" fullname="Ludwig Seitz">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G" surname="Selander" fullname="Göran Selander">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E" surname="Wahlstroem" fullname="Erik Wahlstroem">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S" surname="Erdtman" fullname="Samuel Erdtman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H" surname="Tschofenig" fullname="Hannes Tschofenig">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2022" month="August"/>
          </front>
          <seriesInfo name="RFC" value="9200"/>
          <seriesInfo name="DOI" value="10.17487/RFC9200"/>
        </reference>
        <reference anchor="RFC9201" target="https://www.rfc-editor.org/info/rfc9201" quoteTitle="true" derivedAnchor="RFC9201">
          <front>
            <title>Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE)</title>
            <author initials="L" surname="Seitz" fullname="Ludwig Seitz">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2022" month="August"/>
          </front>
          <seriesInfo name="RFC" value="9201"/>
          <seriesInfo name="DOI" value="10.17487/RFC9201"/>
        </reference>
      </references>
      <references pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869" quoteTitle="true" derivedAnchor="RFC5869">
          <front>
            <title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
            <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
            <author fullname="P. Eronen" initials="P." surname="Eronen"/>
            <date month="May" year="2010"/>
            <abstract>
              <t indent="0">This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications.  The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions.  This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5869"/>
          <seriesInfo name="DOI" value="10.17487/RFC5869"/>
        </reference>
        <reference anchor="RFC6655" target="https://www.rfc-editor.org/info/rfc6655" quoteTitle="true" derivedAnchor="RFC6655">
          <front>
            <title>AES-CCM Cipher Suites for Transport Layer Security (TLS)</title>
            <author fullname="D. McGrew" initials="D." surname="McGrew"/>
            <author fullname="D. Bailey" initials="D." surname="Bailey"/>
            <date month="July" year="2012"/>
            <abstract>
              <t indent="0">This memo describes the use of the Advanced Encryption Standard (AES) in the Counter with Cipher Block Chaining - Message Authentication Code (CBC-MAC) Mode (CCM) of operation within Transport Layer Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication.  The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6655"/>
          <seriesInfo name="DOI" value="10.17487/RFC6655"/>
        </reference>
        <reference anchor="RFC7662" target="https://www.rfc-editor.org/info/rfc7662" quoteTitle="true" derivedAnchor="RFC7662">
          <front>
            <title>OAuth 2.0 Token Introspection</title>
            <author fullname="J. Richer" initials="J." role="editor" surname="Richer"/>
            <date month="October" year="2015"/>
            <abstract>
              <t indent="0">This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token.  OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7662"/>
          <seriesInfo name="DOI" value="10.17487/RFC7662"/>
        </reference>
        <reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc7748" quoteTitle="true" derivedAnchor="RFC7748">
          <front>
            <title>Elliptic Curves for Security</title>
            <author fullname="A. Langley" initials="A." surname="Langley"/>
            <author fullname="M. Hamburg" initials="M." surname="Hamburg"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="January" year="2016"/>
            <abstract>
              <t indent="0">This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS).  These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7748"/>
          <seriesInfo name="DOI" value="10.17487/RFC7748"/>
        </reference>
        <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032" quoteTitle="true" derivedAnchor="RFC8032">
          <front>
            <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <author fullname="I. Liusvaara" initials="I." surname="Liusvaara"/>
            <date month="January" year="2017"/>
            <abstract>
              <t indent="0">This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA).  The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves.  An example implementation and test vectors are provided.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8032"/>
          <seriesInfo name="DOI" value="10.17487/RFC8032"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">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.</t>
              <t indent="0">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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8610" quoteTitle="true" derivedAnchor="RFC8610">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
            <author fullname="C. Vigano" initials="C." surname="Vigano"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="June" year="2019"/>
            <abstract>
              <t indent="0">This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049).  Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8610"/>
          <seriesInfo name="DOI" value="10.17487/RFC8610"/>
        </reference>
      </references>
    </references>
    <section anchor="acknowledgments" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">Special thanks to <contact fullname="Jim Schaad"/> for his contributions and reviews of this
document and to <contact fullname="Ben Kaduk"/> for his thorough reviews of this
document. Thanks also to <contact fullname="Paul Kyzivat"/> for his review. The authors also
would like to thank <contact fullname="Marco Tiloca"/> for his contributions.</t>
      <t indent="0" pn="section-appendix.a-2"><contact fullname="Ludwig Seitz"/> worked on this document as part of the CelticNext
projects CyberWI and CRITISEC with funding from Vinnova.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="S." surname="Gerdes" fullname="Stefanie Gerdes">
        <organization showOnFrontPage="true">Universität Bremen TZI</organization>
        <address>
          <postal>
            <street>Postfach 330440</street>
            <city>Bremen</city>
            <code>D-28359</code>
            <country>Germany</country>
          </postal>
          <phone>+49-421-218-63906</phone>
          <email>gerdes@tzi.org</email>
        </address>
      </author>
      <author initials="O." surname="Bergmann" fullname="Olaf Bergmann">
        <organization showOnFrontPage="true">Universität Bremen TZI</organization>
        <address>
          <postal>
            <street>Postfach 330440</street>
            <city>Bremen</city>
            <code>D-28359</code>
            <country>Germany</country>
          </postal>
          <phone>+49-421-218-63904</phone>
          <email>bergmann@tzi.org</email>
        </address>
      </author>
      <author initials="C." surname="Bormann" fullname="Carsten Bormann">
        <organization showOnFrontPage="true">Universität Bremen TZI</organization>
        <address>
          <postal>
            <street>Postfach 330440</street>
            <city>Bremen</city>
            <code>D-28359</code>
            <country>Germany</country>
          </postal>
          <phone>+49-421-218-63921</phone>
          <email>cabo@tzi.org</email>
        </address>
      </author>
      <author initials="G." surname="Selander" fullname="Göran Selander">
        <organization showOnFrontPage="true">Ericsson AB</organization>
        <address>
          <email>goran.selander@ericsson.com</email>
        </address>
      </author>
      <author initials="L." surname="Seitz" fullname="Ludwig Seitz">
        <organization showOnFrontPage="true">Combitech</organization>
        <address>
          <postal>
            <street>Djäknegatan 31</street>
            <city>Malmö</city>
            <code>211 35</code>
            <country>Sweden</country>
          </postal>
          <email>ludwig.seitz@combitech.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
