<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.4.7 --> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?> [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-ace-dtls-authorize-18" category="std" number="9202" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.7.0 -->
  <front>
<!--[rfced] Please note that the short title (which is seen in the header of
the PDF file) has been updated as follows. Please let us know of any objections.

Original:
CoAP-DTLS

Current:
CoAP over DTLS
-->
    <title abbrev="CoAP-DTLS">Datagram abbrev="CoAP over DTLS">Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-ace-dtls-authorize-18"/> name="RFC" value="9202"/>
    <author initials="S." surname="Gerdes" fullname="Stefanie Gerdes">
      <organization>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>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>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>Ericsson AB</organization>
      <address>
        <email>goran.selander@ericsson.com</email>
      </address>
    </author>
    <author initials="L." surname="Seitz" fullname="Ludwig Seitz">
      <organization>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 year="2021" month="June" day="04"/> year="2022" month="March"/>
    <area>Security</area>
    <workgroup>ACE Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <workgroup>ACE</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <t>This specification defines a profile of the ACE 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 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 less-severe
      limitations regarding processing power and memory.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>This specification defines a profile of the ACE framework
<xref target="I-D.ietf-ace-oauth-authz" target="RFC9200" format="default"/>.  In this profile, a client (C) and a
resource server (RS) use CoAP the Constrained Application Protocol (CoAP) <xref target="RFC7252" format="default"/> over DTLS version 1.2 <xref target="RFC6347" format="default"/>
to communicate. This specification
uses DTLS 1.2 terminology, but later versions such as DTLS 1.3 can be
used instead. The client obtains an access token, token bound to a key
(the proof-of-possession key), (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 (RPK) raw public keys (RPKs) <xref target="RFC7250" format="default"/> and with Pre-Shared Keys
(PSK) pre-shared keys
(PSKs) <xref target="RFC4279" format="default"/>. How token introspection <xref target="RFC7662" format="default"/> is performed
between the RS and AS is out of scope for this specification.</t>

      <t>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" "proof-of-possession"
token.</t>
      <t>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>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 Section 5.10.1 of <xref target="RFC9200" sectionFormat="of" section="5.10.1"> the ACE framework
<xref target="I-D.ietf-ace-oauth-authz" format="default"/>.</t> framework</xref>.</t>

<!-- [rfced] FYI, the text rendering of the <tt> element was changed
in Sept. 2021 (xml2rfc release 3.10.0). <tt> no longer yields quotation
marks in the text rendering.
Note that <tt> yields fixed-width font in the HTML and PDF files.

This alternative diff file has been provided so that you can review
changes without the noise of the quotation marks being removed due
to this change to the rendering of <tt>:
https://www.rfc-editor.org/authors/rfc9202-alt-diff.html
-->

      <t>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>As recommended in Section 5.8 of <xref target="I-D.ietf-ace-oauth-authz" format="default"/>, target="RFC9200" sectionFormat="of" section="5.8"/>, this
specification uses CBOR 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="default">
        <name>Terminology</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
"OPTIONAL"
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they appear in all
capitals, as shown here.</t>
        <t>Readers are expected to be familiar with the terms and concepts
described in <xref target="I-D.ietf-ace-oauth-authz" target="RFC9200" format="default"/> and in <xref target="I-D.ietf-ace-oauth-params" target="RFC9201" format="default"/>.</t>
        <t>The authorization information (authz-info) resource refers to the authorization information endpoint endpoint, as specified in <xref target="I-D.ietf-ace-oauth-authz" target="RFC9200" format="default"/>.
The term <tt>claim</tt> is used in this document with the same semantics
as in <xref target="I-D.ietf-ace-oauth-authz" target="RFC9200" format="default"/>, i.e., it denotes information carried
in the access token or returned from introspection.</t>
      </section>
    </section>
    <section anchor="overview" numbered="true" toc="default">
      <name>Protocol Overview</name>
      <t>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 Section 6.7 of <xref target="I-D.ietf-ace-oauth-authz" format="default"/>, target="RFC9200" sectionFormat="of" section="6.7"/>, use of DTLS for one or
both of these interactions is completely independent.</t>
      <t>This profile requires the client to retrieve an access token for the
protected resource(s) it wants to access on the resource server server, as
specified in <xref target="I-D.ietf-ace-oauth-authz" target="RFC9200" format="default"/>. <xref target="at-retrieval" format="default"/> shows the
typical message flow in this scenario (messages in square brackets are
optional):</t>
      <figure anchor="at-retrieval">
        <name>Retrieving an Access Token</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[-->
   C                                RS                   AS
   | [---- Resource Request ------>]|                     |
   |                                |                     |
   | [<-AS Request Creation Hints-] |                     |
   |                                |                     |
   | ------- Token Request  ----------------------------> |
   |                                |                     |
   | <---------------------------- Access Token --------- |
   |                               + Access Information   |
]]></artwork>
      </figure>
      <t>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 client,
as specified in Section 5.3 of <xref target="I-D.ietf-ace-oauth-authz" format="default"/>.</t> target="RFC9200" sectionFormat="of" section ="5.3"/>.</t>
      <t>Once the client knows the authorization server's address, it can send
an access token request to the token endpoint at the authorization
server
server, as specified in <xref target="I-D.ietf-ace-oauth-authz" target="RFC9200" format="default"/>. As the access
token request as well as and the response may contain confidential data,
the communication between the client and the authorization server must
be confidentiality-protected confidentiality protected and ensure authenticity. The client is
expected to have been registered at the authorization server server, as
outlined in Section 4 of <xref target="I-D.ietf-ace-oauth-authz" format="default"/>.</t> target="RFC9200" sectionFormat="of" section="4"/>.</t>
      <t>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 MUST <bcp14>MUST</bcp14> upload the
access token to the authz-info resource, i.e. i.e., the authz-info endpoint,
on the resource server before
starting the DTLS handshake, as described in Section 5.10.1 of
<xref target="I-D.ietf-ace-oauth-authz" format="default"/>. target="RFC9200" sectionFormat="of" section="5.10.1"/>. In case the client uses a symmetric proof-of-possession
key in the DTLS handshake, the procedure as above MAY <bcp14>MAY</bcp14> be used, or alternatively, alternatively
 the access token MAY <bcp14>MAY</bcp14> instead be transferred in the
DTLS ClientKeyExchange message (see <xref target="psk-dtls-channel" format="default"/>).
In any case, DTLS MUST <bcp14>MUST</bcp14> be used in a mode that provides replay
protection.</t>
      <t><xref target="protocol-overview" format="default"/> depicts the common protocol flow for the DTLS
profile after the client has retrieved the access token from the
authorization server, AS.</t> server (AS).</t>
      <figure anchor="protocol-overview">
        <name>Protocol overview</name> Overview</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
   C                            RS                   AS
   | [--- Access Token ------>] |                     |
   |                            |                     |
   | <== DTLS channel setup ==> |                     |
   |                            |                     |
   | == Authorized Request ===> |                     |
   |                            |                     |
   | <=== Protected Resource == |                     |
]]></artwork>
      </figure>
    </section>
    <section anchor="protocol-flow" numbered="true" toc="default">
      <name>Protocol Flow</name>
      <t>The following sections specify how CoAP is used to interchange
access-related data between the resource server, the client 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, channel and convey authorization information
specific for this communication relationship to the resource server.</t>
      <t><xref target="C-AS-comm" format="default"/> describes how the communication between
      the client (C) and the authorization server (AS) must be secured.
      Depending on the used CoAP security mode (see also
Section 9 of
      <xref target="RFC7252" format="default"/>, sectionFormat="of" section="9"/>),
      the Client-to-AS client-to-AS request, AS-to-Client response AS-to-client response, and DTLS session
      establishment carry slightly different information. <xref target="rpk-mode"
      format="default"/> addresses the use of raw public keys keys, while <xref target="psk-mode"
      format="default"/> defines how pre-shared keys are used in this profile.</t>
      <section anchor="C-AS-comm" numbered="true" toc="default">
        <name>Communication Between between the Client and the Authorization Server</name>
        <t>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 MUST <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 requirements, in alignment with Section 6.5 of <xref target="I-D.ietf-ace-oauth-authz" format="default"/> target="RFC9200"
	sectionFormat="of" section="6.5"/>, therefore must be met:</t>
        <ul spacing="normal">
          <li>The client MUST <bcp14>MUST</bcp14> securely have obtained keying material to
	  communicate with the authorization server.</li>
          <li>Furthermore, the client MUST <bcp14>MUST</bcp14> verify that the authorization
	  server is authorized to provide access tokens (including authorization
	  information) about the resource server to the client, client and that
	  this authorization information about the authorization server is still valid.</li>
          <li>Also, the authorization server MUST <bcp14>MUST</bcp14> securely have obtained keying
	  material for the client, 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>The client and the authorization server MUST <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 integrity, and
	authenticity of all exchanged messages within the ACE protocol.</t>
        <t><xref target="as-commsec" format="default"/> specifies how communication with the authorization server is secured.</t>
      </section>
      <section anchor="rpk-mode" numbered="true" toc="default">
<!--[rfced] Should the title of Section 3.2 be updated to be similar
to the title of Section 3.3?

Section 3.3:
 PreSharedKey Mode

Original Section 3.2:
 Raw Public Key Mode

Perhaps Section 3.2:
 RawPublicKey Mode
-->
        <name>Raw Public Key Mode</name>
        <t>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="default">
          <name>Access Token Retrieval from the Authorization Server</name>
          <t>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 MUST <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 RECOMMENDED <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>An example access token request from the client to the authorization
server is depicted in <xref target="rpk-authorization-message-example" format="default"/>.</t>
          <figure anchor="rpk-authorization-message-example">
            <name>Access Token Request Example for RPK Mode</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
            <sourcecode type="cbor-diag"><![CDATA[
   POST coaps://as.example.com/token
   Content-Format: application/ace+cbor
   Payload:
   {
     grant_type : client_credentials,
     audience   : "tempSensor4711",
     req_cnf    : {
       COSE_Key : {
         kty : EC2,
         crv : P-256,
         x   : h'e866c35f4c3c81bb96a1...',
         y   : h'2e25556be097c8778a20...'
       }
     }
   }
]]></artwork>
]]></sourcecode>
          </figure>
          <t>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>The authorization server MUST <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 MUST <bcp14>MUST</bcp14> be bound to the RPK of the client by
means of the <tt>cnf</tt> claim.</t>
          <t>The response MUST <bcp14>MUST</bcp14> contain an <tt>ace_profile</tt> parameter if
the<tt>ace_profile</tt>
	  the <tt>ace_profile</tt> parameter in the request is empty, empty and MAY <bcp14>MAY</bcp14>
	  contain this parameter otherwise (see Section 5.8.2 of
	  <xref target="I-D.ietf-ace-oauth-authz" format="default"/>). target="RFC9200" sectionFormat="of" section="5.8.2"/>). This parameter is set
	  to <tt>coap_dtls</tt> to
	  indicate that this profile MUST <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 MUST <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 MUST <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 MUST <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 MUST <bcp14>MUST</bcp14> also protect the confidentiality of the
	  access token.</t>
          <t>The client MUST <bcp14>MUST</bcp14> ascertain that the access token response belongs
	  to a certain certain, previously sent access token request, as the request may specify the
	  resource server with which the client wants to communicate.</t>
          <t>An example access token response from the authorization server to the client
	  is depicted in <xref target="rpk-authorization-response-example"
	  format="default"/>. Here, the
	  contents of the <tt>access_token</tt> claim have been truncated to improve
	  readability. The For the client, the response comprises access information for the client 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 response, which
	  has a default value of 60 seconds (Section 5.6.1 of <xref (<xref target="RFC7252" format="default"/>). sectionFormat="of"
	  section="5.6.1"/>).
	  The authorization server SHOULD <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">
            <name>Access Token Response Example for RPK Mode</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
            <sourcecode type="cbor-diag"><![CDATA[
   2.01 Created
   Content-Format: application/ace+cbor
   Max-Age: 3560
   Payload:
   {
     access_token : b64'SlAV32hkKG...
      (remainder of CWT omitted for brevity;
      CWT contains the client's RPK in the cnf claim)',
     expires_in : 3600,
     rs_cnf     : {
       COSE_Key : {
         kty : EC2,
         crv : P-256,
         x   : h'd7cc072de2205bdc1537...',
         y   : h'f95e1d4b851a2cc80fff...'
       }
     }
   }
]]></artwork>
]]></sourcecode>
          </figure>
        </section>
        <section anchor="rpk-dtls-channel" numbered="true" toc="default">
          <name>DTLS Channel Setup Between between the Client and Resource Server</name>
          <t>Before the client initiates the DTLS handshake with the resource
server, the client MUST <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 MUST <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
MUST
<bcp14>MUST</bcp14> use this key. Otherwise, the client MUST <bcp14>MUST</bcp14> use the public key that
it specified in the <tt>req_cnf</tt> of the access token request. The client
MUST
<bcp14>MUST</bcp14> specify this public key in the SubjectPublicKeyInfo structure of
the DTLS handshake handshake, as described in <xref target="RFC7250" format="default"/>.</t>
          <t>If
<!--[rfced] Does "it" refer to the client or AS in this sentence?

Original:
   If the client does not have the keying material belonging to the
   public key, the client MAY try to send an access token request to the
   AS where it specifies its public key in the "req_cnf" parameter.

Perhaps A:
   If the client does not have the keying material belonging to the
   public key, the client MAY try to send an access token request to the
   AS, where the client specifies its public key in the "req_cnf" parameter.

Perhaps B:
   If the client does not have the keying material belonging to the
   public key, the client MAY try to send an access token request to the
   AS, where the AS specifies its public key in the "req_cnf" parameter.
-->
          <t>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 it 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 SHOULD <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>
<!--[rfced] Should "MAC" be expanded as "Message Authentication Code"
in this sentence? Please consider if the sentence needs an update, as
RFC 7252 does not mention "MAC".

Original:
   To be consistent with [RFC7252], which allows for shortened MAC tags
   in constrained environments, an implementation that supports the RPK
   mode of this profile MUST at least support the cipher suite
   TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251].

Perhaps:
   To be consistent with [RFC7252], which allows for shortened Message
   Authentication Code (MAC) tags
   in constrained environments, an implementation that supports the RPK
   mode of this profile MUST at least support the cipher suite
   TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251].
-->
          <t>To be consistent with <xref target="RFC7252" format="default"/>, which allows for shortened MAC tags
in constrained environments,
an implementation that supports the RPK mode of this profile MUST <bcp14>MUST</bcp14> at
least support the cipher suite
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 <xref target="RFC7251" format="default"/>.
As discussed in <xref target="RFC7748" format="default"/>, new ECC 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
  MUST
  implement support for curve25519 (cf. <xref (cf.&nbsp;<xref target="RFC8032" format="default"/>, <xref target="RFC8422" format="default"/>) format="default"/>),
  as this curve is said to be efficient and less dangerous dangerous,
  regarding implementation errors errors, than the secp256r1 curve mandated in
  <xref target="RFC7252" format="default"/>.</t>
          <t>The resource server MUST <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 section 5.10.1.1 of
<xref target="I-D.ietf-ace-oauth-authz" format="default"/>). target="RFC9200" sectionFormat="of" section="5.10.1.1"/>).
The access token is constructed by the
authorization server such that the resource server can associate the
access token with the Client's client's public key.  The <tt>cnf</tt> claim MUST <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 client's key is already known to the resource server, the Client's client's
public key MUST <bcp14>MUST</bcp14> be included in the access token's <tt>cnf</tt> parameter. If
CBOR web tokens <xref target="RFC8392" format="default"/> are used (as recommended in
<xref target="I-D.ietf-ace-oauth-authz" target="RFC9200" format="default"/>), keys MUST <bcp14>MUST</bcp14> be encoded encoded, as specified in
<xref target="RFC8747" format="default"/>. A resource server MUST <bcp14>MUST</bcp14> have the capacity to store one
access token for every proof-of-possession key of every authorized client.</t>
          <t>The raw public key used in the DTLS handshake with the client MUST <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 MUST <bcp14>MUST</bcp14> use the information from the <tt>cnf</tt>
field to select the proper keying material.</t>
          <t>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="default">
        <name>PreSharedKey Mode</name>
        <t>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="default">
          <name>Access Token Retrieval from the Authorization Server</name>
          <t>To retrieve an access token for the resource that the client wants to
access, the client MAY <bcp14>MAY</bcp14> include a <tt>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 MUST <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 MUST <bcp14>MUST</bcp14> generate a new symmetric key that is
returned in its response to the client.</t>
          <t>The authorization server MUST <bcp14>MUST</bcp14> determine the authorization rules
	  for the client it communicates with with, as defined by the resource owner owner, and
	  generate the access token accordingly.  If the authorization server
	  authorizes the client, it returns an AS-to-Client AS-to-client response. If the
	  <tt>ace_profile</tt> parameter is present, it is set to <tt>coap_dtls</tt>. The
	  authorization server MUST <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 MUST <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 data, such as
	  the symmetric key, the confidentiality of the token MUST <bcp14>MUST</bcp14> also be
	  protected. Depending on the requested token type and algorithm in the
	  access token request, the authorization server adds access Access Information
	  to the response that provides the client with sufficient information
	  to setup set up a DTLS channel with the resource server. The authorization
	  server adds a <tt>cnf</tt> parameter to the access information 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 MAY <bcp14>MAY</bcp14> use token introspection to
	  retrieve the keying material for this access token directly from the
	  authorization server.</t>
          <t>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"/>.</t>
          <figure anchor="at-request">
            <name>Example Access Token Request, (implicit) symmetric PoP-key</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[ (Implicit) Symmetric PoP Key</name>
            <sourcecode type="cbor-diag"><![CDATA[
   POST coaps://as.example.com/token
   Content-Format: application/ace+cbor
   Payload:
   {
     audience    : "smokeSensor1807",
   }
]]></artwork>
]]></sourcecode>
          </figure>
          <t>A corresponding example access token response is illustrated in
<xref target="at-response" format="default"/>.  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 cnf <tt>cnf</tt> claim.  The information is transferred as a CBOR data
structure as specified in <xref target="I-D.ietf-ace-oauth-authz" target="RFC9200" format="default"/>.</t>
          <!-- msg1 -->

<figure anchor="at-response">
            <name>Example Access Token Response, symmetric PoP-key</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[ Symmetric PoP Key</name>
            <sourcecode type="cbor-diag"><![CDATA[
   2.01 Created
   Content-Format: application/ace+cbor
   Max-Age: 85800
   Payload:
   {
      access_token : h'd08343a10...
      (remainder of CWT omitted for brevity)
      token_type : PoP,
      expires_in : 86400,
      profile    : coap_dtls,
      cnf        : {
        COSE_Key : {
          kty : symmetric,
          kid : h'3d027833fc6267ce',
          k   : h'73657373696f6e6b6579'
        }
      }
   }
]]></artwork>
]]></sourcecode>
          </figure>
          <t>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"/> 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 MUST <bcp14>MUST</bcp14> be encrypted
using a <tt>COSE_Encrypt0</tt> structure (see section 7.1 of <xref target="RFC8392" format="default"/>). sectionFormat="of" section="7.1"/>). The
authorization server MUST <bcp14>MUST</bcp14> use
the keying material shared with the resource server to encrypt the
token.</t>
          <t>The <tt>cnf</tt> structure in the access token is provided in <xref target="kdf-cnf" format="default"/>.</t>
          <figure anchor="kdf-cnf">
            <name>Access Token without Keying Material</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
            <sourcecode type="cbor-diag"><![CDATA[
cnf : {
  COSE_Key : {
    kty : symmetric,
    kid : h'3d027833fc6267ce'
  }
}
]]></artwork>
]]></sourcecode>
          </figure>
          <t>A response that declines any operation on the requested resource is
constructed according to Section 5.2 of <xref target="RFC6749" format="default"/>,
(cf. Section 5.8.3. of <xref target="I-D.ietf-ace-oauth-authz" format="default"/>). sectionFormat="of" section="5.2"/>
(cf.&nbsp;<xref target="RFC9200" sectionFormat="of" section="5.8.3"/>). <xref target="token-reject" format="default"/>
shows an example for a request that has been rejected due to invalid
request parameters.</t>
          <figure anchor="token-reject">
            <name>Example Access Token Response With with Reject</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
            <sourcecode type="cbor-diag"><![CDATA[
    4.00 Bad Request
    Content-Format: application/ace+cbor
    Payload:
    {
      error : invalid_request
    }
]]></artwork>
]]></sourcecode>
          </figure>
          <t>The method for how the resource server determines the symmetric key
from an access token containing only a key identifier is
application-specific;
application specific; the remainder of this section provides one
example.</t>
          <t>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>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>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 which MUST 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
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 parameter (see <xref target="kdf-cnf" format="default"/>. format="default"/>). 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 KDF key derivation function (KDF)
to be defined by the application, for example example, HKDF-SHA-256. The key
identifier picked by the authorization server MUST <bcp14>MUST</bcp14> be unique for
each access token where a unique symmetric key is required.</t>
          <t>In this example, HKDF the HMAC-based key derivation function (HKDF) consists of the composition of the HKDF-Extract
and HKDF-Expand steps <xref target="RFC5869" format="default"/>. The symmetric key is derived from the
key identifier, the key derivation key key, and other data:</t>
          <t>OKM
          <t indent="3">OKM = HKDF(salt, IKM, info, L),</t>
          <t>where:</t>
          <ul spacing="normal">
            <li>OKM, the output keying material, is the derived symmetric key</li>
            <li>salt is the empty byte string</li>
            <li>IKM, the input keying material, is the key derivation key key, as defined
	    above</li>
            <li>info
            <li><t>info is the serialization of a CBOR array consisting of (<xref <xref target="RFC8610" format="default"/>):</li>
          </ul>
          <artwork name="" type="" align="left" alt=""><![CDATA[ format="default"/>:</t>
          <sourcecode type=""><![CDATA[
      info = [
        type : tstr,
        L : uint,
        access_token: bytes
      ]
]]></artwork>
]]></sourcecode>
          <t>where:</t>
          <ul spacing="normal">
	  <ul>
            <li>type is set to the constant text string "ACE-CoAP-DTLS-key-derivation",</li> "ACE-CoAP-DTLS-key-derivation"</li>
            <li>L is the size of the symmetric key in bytes,</li> bytes</li>
            <li>access_token is the content of the <tt>access_token</tt> field field, as
	    transferred from the authorization server to the resource server.</li>
	  </ul></li>
          </ul>
          <t>All CBOR data types are encoded in CBOR using preferred serialization
	  and deterministic encoding encoding, as specified in Section 4 of <xref target="RFC8949" format="default"/>.
This
	  sectionFormat="of" section="4"/>.
	  In particular, this implies in particular 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>Use of a unique (per resource server) (per-resource-server) <tt>kid</tt> and the use of a key
	  derivation IKM that MUST <bcp14>MUST</bcp14> be unique
	  per authorization server/resource server
pair AS/RS pair, as specified above 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 RECOMMENDED <bcp14>RECOMMENDED</bcp14> to include the "iat" claim and either the
	  "exp" or "exi" claims in the access token.</t>
        </section>
        <section anchor="psk-dtls-channel" numbered="true" toc="default">
          <name>DTLS Channel Setup Between between the Client and Resource Server</name>
          <t>When a client receives an access token response from an authorization
server, the client MUST <bcp14>MUST</bcp14> check if the access token response is bound to
a certain certain, previously sent access token request, as the request may
specify the resource server with which the client wants to
communicate.</t>
          <t>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
	  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 Section 2
of <xref target="RFC4279" format="default"/>
	  sectionFormat="of" section="2"/>, 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"/>, a
	  client in the PSK mode MUST <bcp14>MUST</bcp14> support the cipher suite
	  TLS_PSK_WITH_AES_128_CCM_8 <xref target="RFC6655" format="default"/>.</t>
          <t>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 MUST <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> <tt>psk_identity</tt>, as shown in <xref
	  target="psk_identity-cnf" format="default"/>.</t>
          <figure anchor="psk_identity-cnf">
            <name>Access token containing Token Containing a single kid parameter</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[ Single <tt>kid</tt> Parameter</name>
            <sourcecode type="cbor-diag"><![CDATA[
{ cnf : {
   COSE_Key : {
      kty: symmetric,
      kid : h'3d027833fc6267ce'
    }
  }
}
]]></artwork>
]]></sourcecode>
          </figure>
          <t>The actual CBOR serialization for the data structure from
	  <xref target="psk_identity-cnf" format="default"/> as a sequence of bytes in
	  hexadecimal notation will be:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
          <sourcecode type=""><![CDATA[
A1 08 A1 01 A2 01 04 02 48 3D 02 78 33 FC 62 67 CE
]]></artwork>
]]></sourcecode>
          <t>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 MUST <bcp14>MUST</bcp14> treat the
contents of the <tt>access_token</tt> field from the AS-to-Client AS-to-client response as
opaque data data, as specified in Section 4.2 of <xref target="RFC7925" format="default"/> sectionFormat="of" section="4.2"/>, and not perform
any re-coding. recoding. This allows the resource server to retrieve the shared
secret directly from the <tt>cnf</tt> claim of the access token.</t>

<!--[rfced] Should "PSKIdentity" be "psk_identity", as the latter is used
throughout this document?

Original:
   DTLS 1.3 does not use the ClientKeyExchange message; for DTLS 1.3,
   the access token is placed in the "identity" field of a "PskIdentity"
   within the "PreSharedKeyExtension" of the "ClientHello".
-->
<t>DTLS 1.3 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>If a resource server receives a ClientKeyExchange message that
contains a <tt>psk_identity</tt> with a length greater than zero, it MUST <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">
            <li>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>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>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>When the resource server receives an access token, it MUST <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 MUST <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"/> 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>While the client can retrieve the shared secret from the contents of
the <tt>cnf</tt> parameter in the AS-to-Client 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
MUST
<bcp14>MUST</bcp14> contain a <tt>kid</tt> parameter to be used by the server as the IKM for
key derivation derivation, as described above.</t>
        </section>
      </section>
      <section anchor="resource-access" numbered="true" toc="default">
        <name>Resource Access</name>
        <t>Once a DTLS channel has been established established, as described in Sections <xref target="rpk-mode" format="default"/>
or format="counter"/>
and <xref target="psk-mode" format="default"/>, format="counter"/>, 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>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 Section 5.10.1 of
<xref target="I-D.ietf-ace-oauth-authz" format="default"/>, target="RFC9200" sectionFormat="of" section="5.10.1"/>, there should be only one access token
for each client. New access tokens issued by the authorization server
SHOULD
<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 Section 5.9.4 of <xref target="I-D.ietf-ace-oauth-authz" format="default"/>) target="RFC9200" sectionFormat="of" section="5.9.4"/>) to
employ a strict order.</t>
        <t>Any request that the resource server receives on a DTLS channel that
is tied to an access token via its keying material
MUST
<bcp14>MUST</bcp14> be checked against the authorization rules that can be determined
with the access token. The resource server
MUST
<bcp14>MUST</bcp14> check for every request if the access token is still valid.
If the token has expired, the resource server MUST <bcp14>MUST</bcp14> remove it.
Incoming CoAP requests that are not authorized with respect
to any access token that is associated with the client MUST <bcp14>MUST</bcp14> be
rejected by the resource server with a 4.01 response. The response
SHOULD
<bcp14>SHOULD</bcp14> include AS Request Creation Hints Hints, as described in
Section 5.2 of
<xref target="I-D.ietf-ace-oauth-authz" format="default"/>.</t> target="RFC9200" sectionFormat="of" section="5.2"/>.</t>
        <t>The resource server MUST NOT <bcp14>MUST NOT</bcp14> accept an incoming CoAP request as
authorized if any of the following fails:</t>
        <ol spacing="normal" type="1"><li>The type="1">
	  <li>The message was received on a secure channel that has been
	  established using the procedure defined in this document.</li>
          <li>The authorization information tied to the sending client is valid.</li>
          <li>The request is destined for the resource server.</li>
          <li>The resource URI specified in the request is covered by the
	  authorization information.</li>
          <li>The request method is an authorized action on the resource with
	  respect to the authorization information.</li>
        </ol>
        <t>Incoming

<!--[rfced] Should Section 5.10.1.1 be changed to 5.10.2 here, as it mentions
both response codes? Please see
<https://www.rfc-editor.org/authors/rfc9200.html#section-5.10.2>.

Original:
   Incoming CoAP requests received on a secure DTLS channel that are not
   thus authorized MUST be rejected according to Section 5.10.1.1 of
   [I-D.ietf-ace-oauth-authz]

   1.  with response code 4.03 (Forbidden) when the resource URI
       specified in the request is not covered by the authorization
       information, and

   2.  with response code 4.05 (Method Not Allowed) when the resource
       URI specified in the request covered by the authorization
       information but not the requested action.

Perhaps:
   Incoming CoAP requests received on a secure DTLS channel that are not
   thus authorized MUST be rejected according to Section 5.10.2 of
   [RFC9200]: ...
-->
        <t>Incoming CoAP requests received on a secure DTLS channel that are not
	thus authorized <bcp14>MUST</bcp14> be
	rejected according to <xref target="I-D.ietf-ace-oauth-authz" format="default"/></t> target="RFC9200"
	sectionFormat="of" section="5.10.1.1"/>:</t>
        <ol spacing="normal" type="1"><li>with type="1">
	  <li>with response code 4.03 (Forbidden) when the resource URI specified
	  in the request is not covered by the authorization information, information and</li>
          <li>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>The client MUST <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"/>), it must be
prepared that its request is still handled according to the previous
authorization rules rules, as there is no strict ordering between access
token uploads and resource access messages. See also
<xref target="multiple-access-tokens" format="default"/> for a discussion of access token
processing.</t>
        <t>If the client gets an error response
containing AS Request Creation Hints (cf.  Section 5.3 of <xref target="I-D.ietf-ace-oauth-authz" format="default"/> (cf.&nbsp;<xref target="RFC9200" sectionFormat="of" section="5.3"/>)
as a response to its requests, it SHOULD <bcp14>SHOULD</bcp14> request a new access token from
the authorization server in order to continue communication with the
resource server.</t>
        <t>Unauthorized requests that have been received over a DTLS session
SHOULD
<bcp14>SHOULD</bcp14> be treated as non-fatal nonfatal by the resource server, i.e., the DTLS
session SHOULD <bcp14>SHOULD</bcp14> be kept alive until the associated access token has
expired.</t>
      </section>
    </section>
    <section anchor="update" numbered="true" toc="default">
      <name>Dynamic Update of Authorization Information</name>
      <t>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. i.e., an existing session
can be used with updated permissions.</t>
      <t>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><xref target="update-overview" format="default"/> 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 MUST <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 client-to-AS request. The
authorization server MUST <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 client-to-AS
request MUST <bcp14>MUST</bcp14> be declined with the error code <tt>unsupported_pop_key</tt> <tt>unsupported_pop_key</tt>, as
defined in Section 5.8.3 of <xref target="I-D.ietf-ace-oauth-authz" format="default"/>.</t> target="RFC9200" sectionFormat="of" section="5.8.3"/>.</t>
      <t>When the authorization server issues a new access token to update
existing authorization information, it MUST <bcp14>MUST</bcp14> include the specified <tt>kid</tt>
parameter in this access token. A resource server MUST <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">
        <name>Overview of Dynamic Update Operation</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
   C                            RS                   AS
   | <===== DTLS channel =====> |                     |
   |        + Access Token      |                     |
   |                            |                     |
   | --- Token Request  ----------------------------> |
   |                            |                     |
   | <---------------------------- New Access Token - |
   |                           + Access Information   |
   |                            |                     |
   | --- Update /authz-info --> |                     |
   |     New Access Token       |                     |
   |                            |                     |
   | == Authorized Request ===> |                     |
   |                            |                     |
   | <=== Protected Resource == |                     |

]]></artwork>
      </figure>
    </section>
    <section anchor="teardown" numbered="true" toc="default">
      <name>Token Expiration</name>
      <t>The resource server MUST <bcp14>MUST</bcp14> delete access tokens that are no longer
      valid.  DTLS associations that have been setup set up in accordance with
      this profile are always tied to specific tokens (which may be
      exchanged with a dynamic update update, as described in Section 4). <xref target="update"
      format="default"/>). 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
MUST
      <bcp14>MUST</bcp14> terminate existing DTLS association after the last access token
      associated with this association has expired.</t>
      <t>As specified in Section 5.10.3 of <xref target="I-D.ietf-ace-oauth-authz" format="default"/>, target="RFC9200" sectionFormat="of" section="5.10.3"/>,
the resource server MUST <bcp14>MUST</bcp14> notify the client with an error response with
code 4.01 (Unauthorized) for any long running long-running request before
terminating the association.</t>
    </section>
    <section anchor="as-commsec" numbered="true" toc="default">
      <name>Secure Communication with an Authorization Server</name>
      <t>As specified in the ACE framework (Sections 5.8 <xref target="RFC9200" section="5.8" sectionFormat="bare"/> and 5.9 <xref target="RFC9200" section="5.9" sectionFormat="bare"/> of
<xref target="I-D.ietf-ace-oauth-authz" target="RFC9200" format="default"/>), 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 RECOMMENDED <bcp14>RECOMMENDED</bcp14> in this profile. Other
protocols fulfilling the security requirements defined in Section 5
of <xref target="I-D.ietf-ace-oauth-authz" format="default"/> MAY target="RFC9200" sectionFormat="of" section="5"/> <bcp14>MAY</bcp14> be used instead.</t>
      <t>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>If other means of securing the communication with the authorization
server are used, the communication security requirements from Section
6.2 of <xref target="I-D.ietf-ace-oauth-authz" format="default"/> target="RFC9200" sectionFormat="of" section="6.2"/> remain applicable.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework
<xref target="I-D.ietf-ace-oauth-authz" target="RFC9200" format="default"/>. As it follows this framework's general
approach, the general security considerations from Section
6 of <xref target="I-D.ietf-ace-oauth-authz" format="default"/> target="RFC9200" sectionFormat="of" section="6"/> also apply to this profile.</t>
      <t>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 mode, it
should not be possible for clients to request access tokens for
arbitrary public keys: 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
attacks, where the issued token is usable by an entity other than the
intended one.  The At some point, the authorization server therefore at some point needs
to validate that the client can actually use the private key
corresponding to the client's public key.</t>
      <t>When using pre-shared keys provisioned by the authorization server,
the security level depends on the randomness of PSK, PSKs and the security
of the TLS cipher suite and key exchange algorithm.  As this
specification targets at 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"/> 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>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"/> as the transfer protocol, at least the
      cipher suite TLS_PSK_WITH_AES_128_CCM_8 <xref target="RFC6655" format="default"/>
      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_*.</t> TLS_DHE_PSK_* or TLS_ECDHE_PSK_*.</t>
      <t>Constrained devices that use DTLS <xref target="RFC6347" format="default"/> are inherently
vulnerable to Denial of Service (DoS) attacks attacks, as the handshake
protocol requires creation of an 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 interjected 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>
<!--[rfced] For readability, may this parenthetical phrase be moved,
or may the parentheses be removed?

Current:
   The resource server must ensure that it processes only access tokens that
   are (encrypted and) integrity-protected by an authorization server ...

Perhaps:
   The resource server must ensure that it processes only access tokens that
   are integrity protected (and encrypted) by an authorization server ...

Or:
   The resource server must ensure that it processes only access tokens that
   are encrypted and integrity protected by an authorization server ...
-->

      <t>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 server; the resource server
must ensure that it processes only access tokens that are (encrypted and) integrity-protected  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="default">
        <name>Reuse of Existing Sessions</name>
        <t>To avoid the overhead of a repeated DTLS handshake, <xref target="RFC7925" format="default"/> recommends
session resumption <xref target="RFC8446" format="default"/> to reuse session state from
an earlier DTLS association and thus requires client side 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>Since renegotiation of DTLS associations is prone to attacks as well, <xref target="RFC7925" format="default"/> requires that clients to decline any
	renegotiation attempt. A server that wants to initiate re-keying rekeying therefore SHOULD
	<bcp14>SHOULD</bcp14> periodically force a full handshake.</t>
      </section>
      <section anchor="multiple-access-tokens" numbered="true" toc="default">
        <name>Multiple Access Tokens</name>
        <t>Developers SHOULD <bcp14>SHOULD</bcp14> avoid using multiple access tokens for a
client (see also section 5.10.1 of <xref target="I-D.ietf-ace-oauth-authz" format="default"/>).</t> target="RFC9200" sectionFormat="of" section="5.10.1"/>).</t>
        <t>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="default">
        <name>Out-of-Band Configuration</name>
        <t>To communicate securely, the authorization server, the client 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 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 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 token 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="default">
      <name>Privacy Considerations</name>
      <t>This privacy considerations from Section
7 of the <xref target="I-D.ietf-ace-oauth-authz" format="default"/> target="RFC9200" sectionFormat="of" section="7"/> apply also to this profile.</t>
      <t>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 MAY <bcp14>MAY</bcp14> be included with an error response to provide the
client with sufficient information to react on that particular error.</t>
      <t>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 SHOULD NOT <bcp14>SHOULD NOT</bcp14> send confidential data in
an unprotected request.</t>
      <t>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="default">
      <name>IANA Considerations</name>
      <t>The following registrations are done for registration has been made in the ACE OAuth Profile
Registry "ACE Profiles"
registry, following the procedure specified in
<xref target="I-D.ietf-ace-oauth-authz" target="RFC9200" format="default"/>.</t>
      <t>Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with
the RFC number of this specification and delete this paragraph.</t>
      <t>Profile name: coap_dtls</t>
      <t>Profile Description: Profile
<dl newline="false" spacing="compact">
      <dt>Name:</dt>
      <dd>coap_dtls</dd>
      <dt>Description:</dt>
      <dd>Profile for delegating client authentication Authentication and
authorization in a constrained environment
      Authorization for Constrained Environments by establishing a Datagram
      Transport Layer Security (DTLS) channel between resource-constrained
nodes.</t>
      <t>Profile ID:  TBD (suggested: 1)</t>
      <t>Change Controller:  IESG</t>
      <t>Reference:  [RFC-XXXX]</t>
    </section>
    <section anchor="acknowledgments" numbered="true" toc="default">
      <name>Acknowledgments</name>
      <t>Special thanks to Jim Schaad for his contributions and reviews of this
document and to Ben Kaduk for his thorough reviews of this
document. Thanks also to Paul Kyzivat for his review. The authors also
would like to thank Marco Tiloca for his contributions.</t>
      <t>Ludwig Seitz worked on this document as part of the CelticNext
projects CyberWI, and CRITISEC with funding from Vinnova.</t>
      nodes.</dd>
      <dt>CBOR Value:</dt>
      <dd>1</dd>
      <dt>Reference:</dt>
      <dd>RFC 9202</dd>
</dl>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>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="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>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="RFC4279" target="https://www.rfc-editor.org/info/rfc4279">
          <front>
            <title>Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)</title>
            <author fullname="P. Eronen" initials="P." role="editor" surname="Eronen">
              <organization/>
            </author>
            <author fullname="H. Tschofenig" initials="H." role="editor" surname="Tschofenig">
              <organization/>
            </author>
            <date month="December" year="2005"/>
            <abstract>
              <t>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">
          <front>
            <title>Datagram Transport Layer Security Version 1.2</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <author fullname="N. Modadugu" initials="N." surname="Modadugu">
              <organization/>
            </author>
            <date month="January" year="2012"/>
            <abstract>
              <t>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">
          <front>
            <title>The OAuth 2.0 Authorization Framework</title>
            <author fullname="D. Hardt" initials="D." role="editor" surname="Hardt">
              <organization/>
            </author>
            <date month="October" year="2012"/>
            <abstract>
              <t>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">
          <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">
              <organization/>
            </author>
            <author fullname="H. Tschofenig" initials="H." role="editor" surname="Tschofenig">
              <organization/>
            </author>
            <author fullname="J. Gilmore" initials="J." surname="Gilmore">
              <organization/>
            </author>
            <author fullname="S. Weiler" initials="S." surname="Weiler">
              <organization/>
            </author>
            <author fullname="T. Kivinen" initials="T." surname="Kivinen">
              <organization/>
            </author>
            <date month="June" year="2014"/>
            <abstract>
              <t>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">
          <front>
            <title>AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS</title>
            <author fullname="D. McGrew" initials="D." surname="McGrew">
              <organization/>
            </author>
            <author fullname="D. Bailey" initials="D." surname="Bailey">
              <organization/>
            </author>
            <author fullname="M. Campagna" initials="M." surname="Campagna">
              <organization/>
            </author>
            <author fullname="R. Dugal" initials="R." surname="Dugal">
              <organization/>
            </author>
            <date month="June" year="2014"/>
            <abstract>
              <t>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">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby">
              <organization/>
            </author>
            <author fullname="K. Hartke" initials="K." surname="Hartke">
              <organization/>
            </author>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <date month="June" year="2014"/>
            <abstract>
              <t>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>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">
          <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">
              <organization/>
            </author>
            <author fullname="T. Fossati" initials="T." surname="Fossati">
              <organization/>
            </author>
            <date month="July" year="2016"/>
            <abstract>
              <t>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>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">
          <front>
            <title>CBOR Object Signing and Encryption (COSE)</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad">
              <organization/>
            </author>
            <date month="July" year="2017"/>
            <abstract>
              <t>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="RFC8392" target="https://www.rfc-editor.org/info/rfc8392">
          <front>
            <title>CBOR Web Token (CWT)</title>
            <author fullname="M. Jones" initials="M." surname="Jones">
              <organization/>
            </author>
            <author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem">
              <organization/>
            </author>
            <author fullname="S. Erdtman" initials="S." surname="Erdtman">
              <organization/>
            </author>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig">
              <organization/>
            </author>
            <date month="May" year="2018"/>
            <abstract>
              <t>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">
          <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">
              <organization/>
            </author>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson">
              <organization/>
            </author>
            <author fullname="M. Pegourie-Gonnard" initials="M." surname="Pegourie-Gonnard">
              <organization/>
            </author>
            <date month="August" year="2018"/>
            <abstract>
              <t>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>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">
          <front>
            <title>Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)</title>
            <author fullname="M. Jones" initials="M." surname="Jones">
              <organization/>
            </author>
            <author fullname="L. Seitz" initials="L." surname="Seitz">
              <organization/>
            </author>
            <author fullname="G. Selander" initials="G." surname="Selander">
              <organization/>
            </author>
            <author fullname="S. Erdtman" initials="S." surname="Erdtman">
              <organization/>
            </author>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig">
              <organization/>
            </author>
            <date month="March" year="2020"/>
            <abstract>
              <t>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">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            </author>
            <date month="December" year="2020"/>
            <abstract>
              <t>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>This

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4279.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7250.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7251.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7925.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8152.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8392.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8422.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8747.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>

<!-- [I-D.ietf-ace-oauth-authz]; companion 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> 9200 -->
<reference anchor="I-D.ietf-ace-oauth-authz" target="https://www.ietf.org/archive/id/draft-ietf-ace-oauth-authz-41.txt"> anchor='RFC9200' target='https://www.rfc-editor.org/info/rfc9200'>
<front>
<title>Authentication and Authorization for Constrained Environments (ACE) using Using the OAuth 2.0 Framework (ACE-OAuth)</title>
<author fullname="Ludwig Seitz">
              <organization>Combitech</organization>
            </author>
            <author fullname="Goeran Selander">
              <organization>Ericsson</organization>
            </author>
            <author fullname="Erik Wahlstroem">
	 </author>
            <author fullname="Samuel Erdtman">
              <organization>Spotify AB</organization>
            </author>
            <author fullname="Hannes Tschofenig">
              <organization>Arm Ltd.</organization> initials='L' surname='Seitz' fullname='Ludwig Seitz'>
<organization />
</author>
<author initials='G' surname='Selander' fullname='Göran Selander'>
<organization />
</author>
<author initials='E' surname='Wahlstroem' fullname='Erik Wahlstroem'>
<organization />
</author>
<author initials='S' surname='Erdtman' fullname='Samuel Erdtman'>
<organization />
</author>
<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
<organization />
</author>
<date day="6" month="May" year="2021"/>
            <abstract>
              <t>   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  The framework is based on a set of building blocks including
   OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
   transforming a well-known and widely used authorization solution into
   a form suitable for IoT devices.  Existing specifications are used
   where possible, but extensions are added and profiles are defined to
   better serve the IoT use cases.

              </t>
            </abstract> year='2022' month='March'/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ace-oauth-authz-41"/> name="RFC" value="9200"/>
<seriesInfo name="DOI" value="10.17487/RFC9200"/>
</reference>

<!-- [I-D.ietf-ace-oauth-params] - companion document RFC 9201 -->
<reference anchor="I-D.ietf-ace-oauth-params" target="https://www.ietf.org/archive/id/draft-ietf-ace-oauth-params-15.txt"> anchor='RFC9201' target='https://www.rfc-editor.org/info/rfc9201'>
<front>
<title>Additional OAuth Parameters for Authentication and Authorization in for Constrained Environments (ACE)</title>
<author fullname="Ludwig Seitz">
              <organization>Combitech</organization> initials='L' surname='Seitz' fullname='Ludwig Seitz'>
<organization />
</author>
<date day="6" month="May" year="2021"/>
            <abstract>
              <t>   This specification defines new parameters and encodings for the OAuth
   2.0 token and introspection endpoints when used with the framework
   for authentication and authorization for constrained environments
   (ACE).  These are used to express the proof-of-possession key the
   client wishes to use, the proof-of-possession key that the
   Authorization Server has selected, and the key the Resource Server
   uses to authenticate to the client.

              </t>
            </abstract> year='2022' month='March'/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ace-oauth-params-15"/> name="RFC" value="9201"/>
<seriesInfo name="DOI" value="10.17487/RFC9201"/>
</reference>

      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869">
          <front>
            <title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
            <author fullname="H. Krawczyk" initials="H." surname="Krawczyk">
              <organization/>
            </author>
            <author fullname="P. Eronen" initials="P." surname="Eronen">
              <organization/>
            </author>
            <date month="May" year="2010"/>
            <abstract>
              <t>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">
          <front>
            <title>AES-CCM Cipher Suites for Transport Layer Security (TLS)</title>
            <author fullname="D. McGrew" initials="D." surname="McGrew">
              <organization/>
            </author>
            <author fullname="D. Bailey" initials="D." surname="Bailey">
              <organization/>
            </author>
            <date month="July" year="2012"/>
            <abstract>
              <t>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">
          <front>
            <title>OAuth 2.0 Token Introspection</title>
            <author fullname="J. Richer" initials="J." role="editor" surname="Richer">
              <organization/>
            </author>
            <date month="October" year="2015"/>
            <abstract>
              <t>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">
          <front>
            <title>Elliptic Curves for Security</title>
            <author fullname="A. Langley" initials="A." surname="Langley">
              <organization/>
            </author>
            <author fullname="M. Hamburg" initials="M." surname="Hamburg">
              <organization/>
            </author>
            <author fullname="S. Turner" initials="S." surname="Turner">
              <organization/>
            </author>
            <date month="January" year="2016"/>
            <abstract>
              <t>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">
          <front>
            <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson">
              <organization/>
            </author>
            <author fullname="I. Liusvaara" initials="I." surname="Liusvaara">
              <organization/>
            </author>
            <date month="January" year="2017"/>
            <abstract>
              <t>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">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <date month="August" year="2018"/>
            <abstract>
              <t>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>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">
          <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">
              <organization/>
            </author>
            <author fullname="C. Vigano" initials="C." surname="Vigano">
              <organization/>
            </author>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <date month="June" year="2019"/>
            <abstract>
              <t>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>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6655.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7662.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/>

      </references>
    </references>
    <!--  LocalWords:  Datagram CoAP CoRE DTLS introducer URI
 -->
<!--  LocalWords:  namespace Verifier JSON timestamp timestamps PSK
 -->
<!--  LocalWords:  decrypt UTC decrypted whitespace preshared HMAC
-->

<!-- Local Variables: -->
<!-- coding: utf-8 -->
<!-- ispell-local-dictionary: "american" -->
<!-- End: -->

    <section anchor="acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>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><contact fullname="Ludwig Seitz"/> worked on this document as part of the CelticNext
projects CyberWI and CRITISEC with funding from Vinnova.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIACg8umAAA9V963bcxpng/3qKWvmcNZl0t3knxYl9QlO0pZFkaUU6nl3H
R0Q3QBIhGugB0KLbivZp5hnmBfJi+93qBhS66Tg5M6uTEze7gbp89d1vNR6P
1axK8/L2VC/bm/GJUm3eFtmpfpa0yW2dzPVVnZTNoqpb/SpZZbW+zGbLOm9X
euvZ1avLbf22rm7yItM3Va3Plu1dVrb5LGnzqtRJmdJXVZ3/wt/gQ+dV2bR1
kpdZqi/KD3ldlXN4qdFbZ+cX2yqZTuvswyk8dvZ2jFOotJqVyRzWlNbJTTvO
M1hoMsvGaVs040TGz8a7JwrmzW6renWqmzZVKl/Up7qtl027t7PzdGdPJXWW
nNodqIeqvr+tq+XiVMPU+gf4EyChv8Wv1H22gt/TU/2ibLO6zNrxM5xeqaaF
fb1PiqqEJa2yRi3yU/1jW81GugEw1dlNA59Wc/zwk1K8wFOlx0rDv7xsYAUT
/W1Wp/AufsWbu2yzm6TMM/+XqoZz+b7MP2R1k7d/+49Wf11nACx99X9e0AMA
yCxrT/Xbqmlvktmd3t/fOTjYod9msMVTeYG/qFI82PHeyf7hU/lmWbYILphz
npQr+nJxRzv7/cHT8cHe7nhv92R8tP9054h+zOZJXpzqW1rjH9tf8gmsMdjb
m4n+OqtvYbjS292bIrkJv4f3YLuMF/9tNnngb3Iqy41u8xy2WdWdXZ4nddPC
yv1f/hud4d6uv71ZMq2iW/t2AiRSAJJntbe3b//2n8AJwl9obxd1PmsaIO6z
rwMUqeDxSSOP/zGTpyazah7M9gpny9tfvKleLdOH/Nb7muY5r+bTvM1mdwHU
nv3lb/9xX2a3wK5Kvb/rQe11Usz/9p8e1PZ2d/X+YQi0y4csFdDKuguaHBYO
k/9xZuakZasSz7WFowRy1u++OYcRn8rHk93jA/l4sHdsvj3aPzg2H48PzLfH
e4c77uOu+7hnPj7dO7Tj2m9P4ATNx4M9+/HYTnHyFKbQs2mFp/Ni/GxiWWWF
XIh45S+n8d8WCTD75hSYZnnT2eXhyZHdz9GhWdjx0ZFd7vHBiVnCzr5b48GR
+Xi0ixtWKBvgaAjc+O/y4tU3p/rJj/DI+N/g309PlBqPxzqZooSYAbO9ussb
3SyyWX5jpEqa3YDsaHSiFyJ6qhsNcod4+A3sIkO+Dt8krU6Konpo4LidyGmy
GklRtRWMVCDiZHpW5LA0nfTFV+KLr4nWVzAPTAvcvipUncF7jYZHUU5ponD4
Y3eyR4IOUGa+LM1ojZGb06x9yID+CRj4fg5TKX+JIGxoC8sGxREg4h3I3Tp5
0IvltMhnGkQTzFrDQrJxcwdCLaWvJvoMltRUyxpOtb9lIPgShswAMgBTswnt
wUEB/0hukde0CNNg79riBXyGdxIWrDD6HfAt/QCL1EXWNKrJYK5MF/k8b+np
Rtcweo1KBs46g4foY/UAa0IYz7M5yOwJH/08T9MiU0p9hoK3rtLlDAf5DZig
Pn4cooVPn+BIX5QWIjjGCIYz+IAIYEFqwIggROVEf/woVPvpk67wlx4W0BPI
Az59QnxzCJFNdH8/CkZueBB8GbSOeV5WRXW7GunpstUFvFeb8eHdJciKxL6w
T+c7zXCUFFlrmyXphBBWtlNNW8AHABfg2wyPAc7xPithcOCGKR8q4JHaahnJ
q5sx/G9RNQ0eGWwJftweAWCrOY0RoIcABwaBNz9kKgeFLnwCx+dpEfeyGeKO
gW1DWARfTFd0gOZ7xcMCZhdNNaKfvLPxnzQLAGqgFeSpHU1FV0oYiyOUGS4q
qVe4P8TMOcI5T4g0MtD2gOYagLQiQAssBLABhRvC9rHHn1k2A+OvgDE1FbzA
XAFWSqvBCYjH9DC9WS5QBW94DfTwO+AHb5kfvER+sPXu7ctti5M7gJO4AHr0
LfCJS+YT+KjaentpHkVZhVTwvHpgbADMAarD2WliHg9YPYyHNJLVyAWyVJnN
vrtkNf8Sf66WxDiaWbVgg6DtbWWClNzl1XX278scTpKZtgc/A7FluwRWvlIe
h850hspSRcxxmsFsGbwCkF0sCssgQCvAdWU/z+6S8jZLJwzArIRDhel43C7f
z2+AIgBs/XUwasPDOSDaNC+QnQOSIEeYZTVSVw+H8pKQjKaFNaTAr++zCcEg
ipYJoFfTNvwecyWimYrHkacaQG/AbhDWs6oGzIAhYNLu3FtwAj7bBoUPDqjz
1DYMAnvAwUOu8HCXA3xzlp4wH6JPop8QY8BTdozhiaJX4Ghf8CoBFfUcdK6A
Ygl4csR560kjft4wIQSvoKKhcbPpO5Tl3fcTC3oYRbCryxTKLEsbtz3tpoDX
wMhjxgXUvCiyFg/YwxkgyG8Ikwe2NQcpqJeLokpSD4gMETNXdz2CrnkJCgAf
HT5l0QNEUKPAvprV+ZR4OZqsdIKHk92dye7fIebs0QDpyx766I0AdnwxRFmC
O57NKji5Hsuk02mcSOniFaA+fIk+hZus7v3KwsWDbhyAI0KS60Vz/x4Qk5TK
a00abIYi0qc53K/bBLJe4LooIpWISAQmH585B17Jos6r2szvUa46Q4UGOX9W
pt3TOcHR1h3EiKhahdyd5P7512/e6YdsytM3jJDlB4R3keTzhg4GVcUyRLG8
aZZOcBp5qX+4I32IuCNzACTkZZGa/aPq8JAVBcKyQjoChIzz77SaLVEnhL1/
9pm+cmoJExuggEZPSaOfvP7+8urJiP+rv3tDn99d/K/vX7y7eIafL5+fvXpl
P/ATCv548/0r+R0/uTfP37x+ffHdM34ZvtWdr16f/W/4D5yNevLm7dWLN9+d
vXpiOadZNu2sJWmboysHtOaWtx+Q2Nfnb9XuAQs8tOtA4NFnNOzg88Md8kQk
lqosVvInkQMInCwhpAMRpWbJAvTeokEaJoIqNRwB4s07QDbQ3Wg52c8LVoB4
XTfJHIRJ4iklqPw1NB0gwSxbtB2GsA7H6LWhZ9jOI47Ql0G+sNii0cb41baj
vzq7wT0Ywh58G2hjUeUIfCv/Ny+cxSJuXV8T0l8jKxF9tnOoFlINED2gPZgu
IMAblTSbZhnpfJJNRihDgHeAJtoEK58ldZ0Te+hzJ6AIQJ5ljUYVcapAWUL6
QHco21VvgA4/5NmD/vhZJR8/McytZ9OaLeQ7BWZuINUwDhguKbaYU1FUINXL
dIQ6i9VjR2vOxahtqBYLi9063x7UprfeXW7rFOxWYI0N7HxBa9G+JqzYpwv2
0Bynv4VHJ/pFyxqu2xCKFo+vGxlCLyJ8WDEDvAIAA/w/ZF0zxYmGqN60dXa5
TUtJIuaFsS5EiersErjlmYelyuPoR5PjzRwd9wEP0QZwBVUJf9eKdEiW1I2w
nmTGBjEpVaxsAC/JQY4sUJgQi73ybFFfMfZF4jCMYN7+9reabcT2hwS97M4M
i0MDdY/HUyz8mrRjWU9SAPMxWhqoUasF4GsheAFYXgAOGEJuZqCEg4jVW/Iz
0W3z70tkj1OA1H3WEq9U1QKBBorqqVL/N/5PoUfpXG/4B6ZK/9/ZJb77V/3j
GL0P7wws3gHgwfbTY/r31U9/jY74V353w7+17/74hzHYTma68zpjrH4O+NKM
f1r/7m+Zlzc21leEN2Z+83X031f/iHn/sG4GfcaYyYtyXz9q3t+bt194/A7n
HcSaj6f6Mx97NcW+vnzyjr9ApgcE5q/pCbJwdJixcyYb5keAzGA/1LcZc8wO
J1KgJcf02i6LbDJ0IpRiKRT6+9LGu1LVQ1ZDaHGlmV0WnS9RkUZHWmmETi1j
sVlQpuQuGsRQMyW6L9EGMyp0kqY1sZgb3XcEGSMIaNwslbesusqCU6z3N7Fh
4JxvQFHyAXhfCieKzv95Y1Y5MuYk7ld1WaoBSGA2OvWm7U+gLCP9FaoPiqCe
+WgPg1V1/K8c7ALECJszAnn87w0bQ4An6PhgIynuooo40qJnhMatmmbB4GBs
jZ2MwdfBXFnWmdNR4InA8QgGj6/w3iUguaYZ7e82B3Igz0IEkJ5EAsukIF+2
hxUHj8CJq64KZ/U3MZiiEyIyEGEYW1EedhLY8wuC4vUQaERON+25MX+4C4GP
WgHSmDiREPeaFViWwH9mQy5YMW9Vxz7vTRrjKWSYOWeFCkDjKfWs99uhWGXu
/mqIYKQGNAl2c2DAvLZOjnDVo54Z1vN0bHDfv0CNvQnonszpRK8FpHKA7C1J
3N+zLCWsbtBvBhgLxqbBhxFaAkmBeQEUKCtWI9W3FvAF42SYOnW+NuaMHOE5
rfpltroQj5Pl41tNlgGCL5p7znXAn8sMlKztCbpz0NuJex/xDuhsjXGP1ij5
edgjIx5x9FwsimRldEQ2WmAGMVrG1lL5BKcC2lsrmicwkap0MSPS5G7EK0Y5
GkZhTW5acevIYdwljVVX0z6MjFIf9dGPQPBMfoPSt1Hhi+kbX/39Std6xefL
L/mc5BTFnvryy6/+OfPBdGdWV7Di+8t/2nywvy/J+mU+b5UT+HbovbWKWQ8n
jXZmLWzzAyplnuH9DSAnM/6bCsO/bLuK5cUCeUXmKNmexsEAzI9MNCZBYYyg
GmLQLeVAgi881zFZkajxsFNTMUWulT1Crr6VPmShE9tvljc3IHZZovhhWuXL
KY41GfwbGe8SuhgHHQbWU+ncgaFGQRBC0N7liyHFE1nMOZg5Y3yVWAszfM8r
sElLMU4KtdYBwM54F1abqGdkWSMKiIyiw6aTtwF5YpPEa9FnoYwEesrqhY3x
sj7F3HrcVmi2iX6GfAq/4d+ceoYLDlwl9jTmrODX9Uo3RX571xYrneY3IB06
Z4gGdr24H+MaP31SorGKri6Oh25mwAO5fllu8Hs2Ug7wVp2sAfJHBj424eXs
7j0PTuZr72TOQ8QME/0u+VA+fubOnSyndZ6LEHcslQgGGO+FkGZAcXIOvdD2
gM/IqmNfcxymY3RZjb8XEguJfBgXSRTbw1aO9AJgCiFKKoCVoE2znJs4mQux
KD8qLcNFyNEIFxS7/FSxYl2bo/+gy0o+Cai086TE8Ccp97fLmkeo2JVN8f1q
TtyP2BEisJfCMelwWPFUcSYn+cLz29J5ap1D7XCTToebrvlgDDmDHneq1O98
m4JAbHdIJoXZYSyO76VegLiyunLs9CYw0TfLGlcxh0X09Wd4BkXIejaeYwan
M9ZNYgRydR+nGr2Vl7NiSSwqRFLt84FtCd7GREBgQ4+EIJMWBiAEGXYGuyEH
tqCbNgez8wMcZopgcVkYw2i/9kxgTfZUDMX767aPh+PXS4zWJwsKIacwSCdN
RFcPJXmr32xzvKS2nogB8QljGOjhMbKcZ0jCtjsIJHbkYwxmNrDYHslrEgWI
+R8y1UVK8lUDcG1uglH7G8nGuMusiFLAFKpZ/vfZ8ICJ06pqMRtssUA23+iy
ajFc2rJ72g/x6f5G43oMkaYY/izBAw/BiLSpW5KvyCp93wB5xKI7NzHOVoLb
RgckDSJpSI4ATNDLHAQWQh64lroJq412QBIuTKTRr1Eb+PiZFbpKdY12si9D
oduJz3RtSKTCTgCv9bknidrPQmvknfVKWiEWE7FKnXVNrg0eHU6l8VcMK/Jy
afB1onj7g6IfPu+wkoAxiqsw7jMbcL+FrrSJT2NERqDswIjXMNj7WXlzDczh
L0BLrDZ5iZHoYAxPQ1EYCBACVqEZKQFVai3hIXdqJpcEpSWoRR/yatkUKBdT
oNcSY7drdkBRLjhZLyatTZJEgCouZ8vGKyMSysp0dKY+Gp1HLFUon9I6iSQ9
BCGBG7OEnoXHM9FvCIDzDOkwb+YNQSg6oJIBTQYFK5QOkwGrKMh9Bgf6c4Kh
rbgXdSC/I+o/Rb5ETgjjPkWaDJ4cC+MYy5zk8vPsSLAy374BTJpVyaI5/eKL
pJnIk5jP/QUtjbwIFfrh2vE3JBpP/RyyL0A/+b2kVOu3yQpdZ5TA/JGzmG9r
0Evft6tFpk9lU+9ndSacsBnxUwkI+Azd0xqeetJm88Ul8M6qPjje3X0izwie
a3rmo8mRPn9zefEe+ZL3ndb3LX5xcb43ct/N6g/w3dvx3uGR9+3PNNzd59nJ
0dFs//DmYLY/O9mdTp8eJbuTyeRz79GVPLqX7R0eHh5Ns52nx7OT4+OTZG8H
HzVPflLuP59Ux2zfeEbGjO8wO0aPC3kG8RCzrZAZP5GwuXmfA4xDbvqeHWHp
33pxQRIifnePwViIMTJTnIqddBhNNInC1wRmd9nsHoPzPsqbBDankjaKiJzE
BAt6kxKK7yEghM4cM3TZTuJlxTwgiVh1vbp5i2nON8NCwcazGmW1WgPQvJEk
FU+ZhQkqTuh2Fr/RcyKaGwVYbjNQ0XCvkaMTe1nOTlwerIuEHlVxcQbZZQie
KoDwdKXmWVI25utrghhllLgEQZ6ST0lCKLCwayD392KKBSllxAEHfy27IAPU
QiUIZSm6gWUGzix075FcfcgbcT94eWSTvU1m0raxG90qULMhlnqNDO89+oyv
0WLOy5QzZuVwPWszcBr3ixYi6SIDjigbXSS4Ksr+kF33T5yx3bNEelQrZOcs
FJ4dtAaP+vR64uNQD8xDyej2yEk1s0C7rhsmqGWJ5QuIqWhUS0qpoQa7+aLO
knTlhRY9bUKwrZ9dcjWkRLOa03RnI5QOQodmlWqaFVV52wx42gadJoH9i9Df
BDsJENBYTpPnHYZRIypD8LhGuCD0pyB3gaGWfuyaNf/G40v+mBZx+kHNYYuE
gYl45y++Y5fEthCad0NnEmdZ3nnYRGTlqZINYU1EUI1cMFeC96BYGe80rjDq
6OWc7A0HvFYNM6x2bTJVGJV/hB5mxvUUMf08E+cJJQeQX8jwY17Te1qTMGYv
KtzWy5KtEpRdc066R7qTlPuQ1VAmVZ1TzI+3GmMsshWuLzDYxSa2WCMeIVth
23Rk7USdgzkkXrCf0fo06fn4/Ovk5/EZJnwsxNPCblL0NdvF0gEqtDcS1KGT
ZdGisbUkR+7RDloBFVpSW04WHHHC94/iiP5pe031ACfQqiT9y1IcmJ1FOWrF
9McqY18AWOIZR+fUdfbzAjPO3uelL+EQvz9UeQrKU1I44Dc9fXtvsrPLSSLk
qHm0ai3rPNX7h0c7A7q2jzagqU6PDj6/LM7+tL93d//yW9BQRUHdqrGUE6tO
EW7nP1zpap63rQg4rC4HJPoXeRh/DhDCChpP7UK1nLB02+jLDkqwkP2jnR2j
xDdGh/9nKPHp8Wy2c7yXZnt7O4fTdLZ7uH88oMTfPD3MdtOD6cnhbrI3m53s
3Nzc/AYlvkvgA1q8YPmQGo9ODo55i5v6kmKgJqrgRRRs+NAGEnBNQRRcqb77
XioqJD6yKUNCDWVIcNqVvkbj8dpy6E6Ok3WoPzKJYmOJW9ePU2ezLP9AuQwk
xWxYrytsjcFMbGWG2eKRUDsp4cSuMk448UvbbAqLiR8MZZNICWyQToLZrW0D
XL6uUer2GWmn+GmdKUKs0ak+ieju8EdhnQ1RieYfovK8sOzNFVcHqtqRfBij
FIaOIdAaQyUsNMCqiN5iHStXnbU4wZ7HJM3lklxb7IUEPoEZjGimLmfoVjHu
lw46dzNnREDs/ITFPoE9ZPk8ydj2ru9/YjXGGXTKrTGEF9gybb1ifxWnJq5J
llNnl1gogQ7Q1vPYojYek7Y90xYxhXYO43Akwg2SRIbwVPxADVYBAIINScVJ
nY1NLtqAv0051aib+2Xq2wLDxCvds4WRariw5opMbKq0ww4SEjXzo8+i+0lF
O47RwOrg2QxNzHPdJreN4jxAW/idee1VRpjZmCNbxj89TmJqS63lQfFwExkI
DEUgiiJLGvsOQzJfoBexWeZgWwCK/vn9xfmz5xf0n8uzP7//4cXV8z+/P7uA
H3b3Tv78/vz89Z/fn9i97aLT7gyAkTezZdMYHVPaCuDGEcYX5+cgqWbLGvmh
UxWNGxJZZYlBdK76rzO/aBEWm5liLgqKATOrxjOAJPz43Qt0ANC4gG4BeJoe
EFoTmYRhCCAWnhYiZEPjcHuHh7tP9dbsZiJ1RDv7dIz8x8Ee/LGNIcKGp6B3
dJPkpiYosykdKA/JNk3RZqrBsFDaq6nvnGlW11VN4WNTMTpbgDZR78oUcxgu
YVUehvEwbKB2su/HCig+DBKOxFHSGyVvrClJVXPAudq8lEojrsdhkmM/6bby
HdbsR8l9F/YD1vnYyjevGj1L49ahze8wuUCSYbg5x9Do251dM50tZ06kDyT8
bLSPrc+vb1xbXnQec3+QmPGcW3RWJhXbhEd6Om1VjwwsiXc2gVejNJvplQJl
k9uJVP8bAzf0Fm2PKNGdklgwgaNSTvyu8z6iyC8rV0ENqwDKvHUlp2730QUP
1IgGcPMEmvV5ceA9i+oVMNd1RBh1izSZmPefYnm8zaPZSroVouvxa8R5OGZZ
ALwq5QJFX/1QPNcxNpMAZTFOp1bAz5JFMpPy9KZFLbkqO7iFnAp7dawGE42B
BvkBz/UrvlnhFWEQ1GURDevenuIlzqzBcoUXUX+apLbAJ9BbYAHeybKjuTQK
rqvSYNFJih0lWke8X8ojyLusWJgVk/NjRtkvSBleskYXQTT5dzuMwtRD9/36
3dQd14lEcVJvbO+Bvhr4OYw/hxalWF8mLa0wnjA4ZZCD0dyGpaRTufOiIleQ
raDloMYWqJO9XAqv9Qb2VTDZ7G0nBSIy9WeYt5lxbwov+G4z1waC72EK28bg
u+qqyvjAPyb4/k9LaePkcWJQFtW6AXBU6Gx0W4ofXda7KMZUf7OmoCWeGcca
rBc75+YyTOLrSidgN2F1lJwTSN2agxNWcJpz6uXms1dWb3BRBzqJt1IuUVbk
kQ2hQfB/CGP9JiwV35VXypN0dmI9iwMBE6RvqWoaipgAgwO5RwpCuFBc4w3G
uDa5u83qxRKJbBew35a8CDY4M8l3826MZa4reuMELaw+9Z0xYYyTGR+RIivt
8SQuzBay2+rxUxt5LFbrY5oWaEHxLAkIhocUtkXydo3kUYPhPsKgxowXjbtN
fn3Up6thWtRUA+GxQYYSCfc8JnXv8UEftIJN7tfGyI/yIz+6F/nZFPIxja4I
tQIMF4YZjfD4EWNptuQqoye6lxcuXJGCDrRDzOigFk7FLay8vZubop14NGcQ
sknqWs94lanKi5w7n4Wt0/EPdTjDX5GERxdq8lj33aDiw+vsKTVhC5duowQW
Q+raOLitjGLeQ08Hm3EB3Y5cIIebSTVgKTOc59jflWmWwkjCLSGMwBk0DqJ8
Y0bltix4MUaSo1OzWEWdj5hD3Us0UGyLmUwqGGawPEMaUUW1KVJg6/xDTIq6
6J0fxsQS0qRUXl3agBIJqgXpZ5F+XyC+rT4TcxRa31UABwukteVcj0kPQx0m
lizgiXI1WBcJ+FkUS/R+2VAllXfT2P8FuWFe1hemfTVzGJMTjnZPdo4576sX
e3ErNjEWE02JZUyN9Bb6fzCvdttjjm+rt2MACcZczjQ55pHLEL9bHxfuwVAJ
DPn3oGGijLSG91lJqygs6IVsbSSFFZdgMVubAsDb0uFmKMw78sy0QGj4VZ82
pieKpj8cMiKvWpO0PzL9UR4p55j/dc1tlPrD/8AOl83trh6Pv/qHR05PDk92
hkKn3djp3efpzsn+wX6yu/MrA6fb8jCNZBIfAd9MDDKIjJ4cHdjQqPWiEjVY
Tcn8asKmYeR0IHQqsVN7sCP/pzylDe6nO3vHJ/v7N7OjvaPjWfZ58JCESY/3
jw6P9+H/nx7dHGVHU/jrqY2RmiDpQJTUo4sNpGpCVFEC7TkXJXfKZjUE+Wts
mLGIWTbcFdHlWem+JJYmVtSllNMfqMFR4/sHA60Ks6Wy4oZKnJmvOttKBuiZ
gv2SlK4VyIKLhmtZmjVdp9AkzAWSHghmuUlM94tmBwLLrVcYA7VZmwyVC/5+
59oLrZFb2HiEjznTwnPqbW9S4wEIKiYnRV4P6WEs+2k5JC79PCQ+bbfEmOLB
MQluckp85z69GcN7XSGHRMWE06OjKAUN0o5C/O9RgMwaTQbAraOu95Ih81og
wyIp1HrTbFZwI98S1PdFZirRupq5y+ltlO9+D9JRXeLMnj1M7L2NBZwUjfGz
LPcnm3pIbGP4hoAOxI4E9emTshnImZfnkHh1gwmXFEiPi79wRXS6zLjKmCIl
yjxtVe1+Lo0+mOzs6K8TW75NXz5WLgRiwDJPCg/BGcsy3tfeyL3z9ff9KBan
f6DWtPQCnjQhNOzurmIZYup9u+TgEpAj/Mg2HI6kCLIFh+UsXVaFbj8HmbGp
Y/4Xmd8TdNyPSrDCWmDoLzcK4RrXyLo+xFzKyX5Y5AeKF0lqPQ9iveYdbT/w
43R4iclFtUZAd+N9fiEqDgKzM7kt58C5paldU81N50iPbfMqlG+V/RqAiODC
JVgHvS3UxkRJDFJwOxmJmztXLdlzD9g1uTEbVgZqYa7nUBX50EpjsUo47Zc2
BCWG3doDCTrBYpYBKEpZUijkZvFyywgWVHUP5I2SiR4F8/4uXni9bdc7Citf
nnsFzo+2mv3sfpqA9AiHkxyAscnmXJmVzDH6g5WAIQY3vmoRl73WDN3s33C+
skw6rbZxUniEyI6RKNkUgSGAYa0HspNsg1nmKsYe6feI7gWO1oBanBNNhPZN
08prkOOeEwcUT2ok45QES4w+45Cu2NH4PfoUk2K2LIxXNsQgWz7QDpev2QCO
B4YuFZDDTb989o1inOy4ij2GPuL4pQij5/DK+PL5GeZNTiyv8/a2yGf3GyIX
HexEZzZVRYbOCEpnssWFnWhLY8rgU9Nw2TeTcZEmxce6jFDPr5q89er2aDMX
P/MNGAgR+WJBPdnabNFQrhdey/ETb7a3jICf45mERz1aB39mQ2jpnir15uVr
/SUtYKtJCrCsX7x8PSKuNtKvtkdKEUCoOP8N/oLjApdb9PuMj0wOiFlbKOR/
p3F88wyVz8BptaZaC35/YcbPy3XDx3blYg7UygkGo8zM3KaAo+tYsIHa9ZGx
D4YH91fDAyNF40Zv/SjXmfwUbUcpShaN/qX+0RqSYiZjEbazQl/BN0vqn2W+
8Y30U9p+I7/9FJnLgZ6Gd2EI8YrjRVXwd/Zza0vezs4vxrb9LBqgYweqJyMY
6ZUFSv7LgPTLS14ZPh54FXLTLIr004Fkf45MJ7gv38XyqHqEvog7A+FhHTME
BumvLDkUsFb6mZnOgkKD7Ef1jpxozGigeNQzfp9sx4GOhNJ7bozKNjcuRs8Z
euK4kSkW3ebILr0gzTWu75po7PrVNVN+SXUREi1XOP98OddFVt4C1zSrMJdN
bIYrKL0te5Bw5dUiQSZFsDEessWyXlTcNyakFIDm9410qxTutrUgH14A9G0R
LkbNW5p3OhIVqJV33mGrOGTsjL/oln4tkrzTQpHbsD1gslk3+GR4irA/VMJE
X01mddXgTQ9Fm6OkYCmE4afn1UPGSo1rzfEhqbnLgpGk/sAylOvTI0lAviOE
VFUXa8SQRpKmxN6p6j4oFq9soAFffQIzPxHPDnVVtP4Z9ST7efEEVUT4kD8x
DeFjiv5vy7HvdZqT/At7I45LSR+s4YzdDjOYaD+cV+h7pO3VEO6uh7+3xEp5
JVbxXlqDJVYqLLG6ck/QLmyWzILN7oEE8dAD3iiuOfUp2cXeWBvq5aH9YBKI
gjbg3opntmOsKGth3ykiV5Pxr4KQYRJRqDmZxzUx6PSPGgU2acXpyTgp3ryA
ZGPafHiR1ChL3VPGXcOX0nQ0RY7veZn4nUCluRPjUrn+Ww0tAnv1u6wTM+YC
fQCU8M0WF+10SsVqQQ42I4pk80lesM1QltRsSx+5vWRDURY1J/8PJEtrSpaG
Z4dypDnlD+9cMzd4BMlS7iqS+569GoQLg+6lQ+kothMeSor4xTjGDsXO5mqR
ocsKJROnRMdjjaaDk8kLC7zC6lFRzW9sjyn8jQ3NAtvDdExDexNKr4ty73aW
oFana+VKn5Nu9Y7c2dJrZqq8wha/NobsTevqsCXY0ky//7YwHo+x8bLZv+m5
frtdY+lGlbTSmN+RG75KSkAYD3AeZYvXLMop9o4pRz0SMwWQLJTk24FK0rih
bpCN3AyopV5bZfLaXnVlFsbNqFGRMpm5wsDJw5dJpn1A/96m6BYT0vZChR74
pLnvhCstEcE7d8fYuzqIsv3fYl71j9r51WMBqnu8frIXm1rnW+cQU8TD3l1K
x9Xe84UmGpkm0BrO5pijizMRXUegZPRDzrixUMXTVTGIEMhQrmJ8G7gOmQQI
vjuwdzFjdg7zgB5mnABFoaZZ1GQ629U7Jxr/f1ef7eH/7xzonT19cKL3n+GH
Y/iwr78510d7+uhYA+H3B1FnrJO43IdO5gpDikmqxyBE/SPPxxyvM+R6kg7h
Cd6FmMN6t+RIDbbyJeEiNNrVgUhhF8fJ2jppnsolpMZ7TjbKV/sH7ReOjvwo
l43+RIRKbcH4hjdyXtZ4jaQxQCjt3gr3iH8oyBsR7Vs4ey8/JKhaiChKXMLW
00b8ksjhtsnEz/yYaHhiouiIjXVLnJKstFL/ktWOiYIFUpvG0t2DieFA0nim
qONpnkc7HItyPEW0kRUv0U9631++VwEpax/k6lhQxFw9Lo5x2Lxcrq+Ppaok
m65uM0ldGom0n0APIvcFDFduA9fW8KFcAk9Z5Vuwgkw27Xq3SiQg0s3TeH1p
4WFPPKnKkg0iKxy4yMyrjlx/qkCuSBArArxL4VKdFC7JsE+4AGooA5wMEFyV
2IZRJysYuKYOL3Y0SamugY9mt0nx3rJ2kF0F2EQTL1N+mGi6F3/mHTOsX7/Q
L+8a0h0RcR5b3hXkaG775V1qY3nXQC824lCde9VsZVyYrkakF0si41+p3MvX
absA8a5LDRI6yAViCj6MytHRxDfnNLp68P/qEp+rmD6frAZzB3+Uq0J/0lWs
EsaTEHO+/TAWGjMnaIoArpyPKZxt6LrREAeILqR0M+zx2xNWPTPE4w8qZnGa
RpUxORxlv8qGn4I8Wmb1Xct2UDaqrhlltDpZP5m7ZYWJWJQXKFo+1z3YnJHY
DYokYygLp+NEF3wedZenwvZZ3bhTJ7Aovnapp8C/0EmIcZbOdEG5Dnn9uFTI
OqxY+5UbXzqpzzbxwjo9sv5lf0FTbUAcv1n2yCtZKsLyd6+bLkefJVPJnDOa
UB+o5tgEmjqWGy7OmnVifj6+VYTze/9gu0kuaYabZdF38lg5Yju+h2wnKoOI
vVDGpatMCK78XNvVFrhWt/1c7EJQW4/a7W090AHPdso+i2f6POaqENp9Te0D
5RZMsirxsraAuohnYtzPJKV918lP9SVTOxCxULavwKKAlfhWvbwcjmhCp16x
nN8Er1/3YTpky822ckOHWmJOC8Z90kADipfdVt190W1rNRXNrwmkgwgYaS4G
Ns5UVFLb3PAsUwYUJvWGDe6eTjbe3rONPtcMRHiFE2AEC9QsWh4lkq/CfKu1
ig/ylJBL2HqDXAi5g7Yf8oRqpbqhemXCGaQy4Tneopoe66LNNVF+xqTl2qly
RxP4uiKHrTwNzclz22pwY0n+RAV1NsiBOEU3XVNiWmdzjLXkLV40A7iFMJBG
VtJp3zZaQB3ZY4q0MUFjqsHDK7kfVxEbmsVTpAZJnRvIMqX3DvzM8k4XQqFC
E2UZvsasIx9UL4lw4yVTUTDilbXckIcvcYtAEg12D3xwnpQEyUfm2uvfJHnR
gJW4yzs0pu4Dl5pnFKMiLA8v+dBBLiI6mnyp6Bzsrlo2aOwb9CjZjfGEwBjK
rVCj7jDO3MHzFmTcNUdkW2WyreDyR/ribrdDGN+/e9HvzOONGAph3PXgonsL
kmTFvOlaHbMwJ1WWIka3wfhoUW043xBBRY+xx7MMyQGDXQbKSI9mBpJibc+L
tUhNiGZJWSJWQEFAbPt665uqnuYpqI3brGy2g4ejKBmiez7IMrqK0hDA+Hrn
wdUc6q3XfGLfwaBnSC5ZOrAsXMwg2jx2PXq6pGRZ3IP3vsWQzc0kY2IlZNnK
xBqEiFxqMReVITc134clqybGY/vhsMLJDV/iMvnjR/6dGlHkrXHDYBPLBZlF
dtHeCfJi0T9RdFGN2QmrO7FmwKL7c1f8sgoEOw5hTOSgCIB15iZMdJS9uGsT
Ls0VPh8/mnj/WC5yYg3n0ydJ1ZZmQybfx9f/HHx7fbRuM75ihnOorZTx3O/D
EoZSz3/NhZYqCSu1vRPgPhdWxRQ50i+kIuf9oP6Xe+mhxi84cJNCN0SGuSJ+
TW+oFfj3OxqeRkZfeBmSrJ9uxrMpK2VVjm+SFluSRWW+ubzbxs+MM8ONdk/i
tkAdegm7KhjvnbYRgAjoQ4k6RNd3P1uVyTyf6e+JJvCMwr4P/t2yHz8TylHu
KlZeZcNURAYG3evYPxuM3fEc/dhZt7ItBJzXvMfnISpqaQWZWZScYpsgdLu1
+IHMr1fOvWqudA1MBauyeTmWSEklQFOy5fw1x9JZw1piLiliTqVM7Qg59u1N
LlgtU93WyeLO3HTlX0EYoq56fPWwXG5J5RyydIOifqUT7diw0gXq8fRM00kF
4a5bYp25E16zd+PvbmOUhl+jQtjm80z3wJKEXg6fIAYiTu6mLBVlF8Pmom1C
YJ28PZXImK7WlYkQN6y7XzW8plUmjxlhO0ZaDd1UGdw1zsm6kd2rCEHyzZWi
edG1NRvv3BlwoET8T0bT5rotvtPGdJno9m54DNKMHHHbQqJOo8leXYjYFAOe
YOWncOuQiI0C+njvtY4nops1xC7R21Rp96Fz65bT5HgS2GhF9QeKAzH0vHfr
y5C/35lIzkmj6ADFU2OTTzsxnF5PUX9X4amQ7T/jC4wt52QtghTZ62UpSUJZ
+n5RLd7fZ5SUoDxrLChbe4RRasNBA7cgNUtbrBEXTI6Tr0FDE0HyExk7J6M6
HvMOGxgMdBjf2Xr5WLHBHJU61tfQvQOkX/tgT8Vw+HUWXC/9wCQh6N9yIS1e
oNq9I5a+etyFrb8PK/L4iUe8F31i3Xt4b27Qg0DLzbnxf1/95otl141O3tlg
4+PN81lQ+drcPwQuojZ+4ck0gsC69/BfbxePmO/vXef/7xcDdxQAkxH1xvwN
HKGjxb8xJcV8UzBD+AK1fqPIt1lSp9VD+WmNMy/Niqzt6sGeT0ZjM8OsZvED
tl43SaFnHXHnntw0tUpK408Kes5SIWnxkKycs9reySuL2OLUQa7lVO5aPckW
SQUaolgM3bh+sE0dZHhMxYPNsBRUSoUDVVS6gcITicSF5MJHMaa2pXOZp0N5
Iy4xaQKAiN2H8W++AE5HJIHVpdkNzv5z3EXI8P153BXkBbYqDoz7aBtG/2XP
PT6hpLJo9hS50TYK4XiSB+0DVBWjpfldnnq+BcYH4+za1Vu+2b0t7XJWhHm6
XpaluYk1Ix8Owc2AzNpxbrdk8V6yp/G8b/hjf7RI00MgF+8qxj6QKCZ+fuHy
ce1lFg0qL6QyHk6ebmy7O+qqXRym1lsxfRMG/SLoAbO9/hpEL5cfYz3K2crm
PkK+CNfPOLA3FWo/K4G8uGgMECIO3JLduSawe9Mya5LKmAZg2C4L+KGwDWyM
TRLcshtTDtUGnKTmT1N74TMVqAIa4IWj3q11hrzfXr4cYc/gkf63yeHOU6q+
YKxjgya42XAgAbjOAktoKG3Du3Ua7CKuQbS9tXj/xg/wiNsR/ZakLnMhfDMO
VDKCBZzqaHP4R1oJmNLUKd+bzVSFg59LH3IWAYoLxUxQJexnLwzf2GBnYfI9
olhIjvjgudft/cLr9q63gAS3HQ2uJTXi+7lfvZE37tXPTSfCQtENvMnsjsFp
UvEtIGfBXjug3AhIanuDYFzZ9EKHE8PR6CXF0HrNFCONy/zelOYKHNdwL36h
FqfWUNg+LjyMLahfJ5htQ02xucSMBN4dVdTySM6f3XTuEslrbH5pRJXnXMJl
MS0Q88uzhlNxkVUAqs3R34SRiCkXEqOCQpnyOUvJFLMXYHIYoaAGswAh2+E/
b5XkQsgIaBnnU8FAswlK2xIPczdlQSX1NAfsw/wy14T5tNMuGF1iVksYvFSB
DFJ7gWzvplbj+hq+nDTscragZKLMdApyycs4ssl40gDmaU4vqKRtEyzicj4j
a/6LB3XZUBEL5yPKAHw2pte+y3+symxd/1rnIQw0IM7mwKi5uX/X4bMHTIuT
9uISt1kVgqGbbxNcXfkDd0SQyli/psvd+L4+zYU1HEv/BeBage44qk4xfkGg
gGpeIuYAByCJYiSzvd5a3EJk+foFUvhgvIQMlUVmVJ2czzapOUzTDt+EYb2E
UqrXeDrz4/3GLNp+XrBZ01YKc5fn2M6ColTw60SzduDVipnrFyQNMLy6ATDZ
377pmDulzmtIziN9MqaieLzsgwu1ZCe2Xatpckou4G/IwST1bDNDCUbQiNxr
Isuw0YJgPTyg14QBZHhWJnVe+XQzwwIKGAN0mGL8kKe4hVCU0ephIQVf3S1h
RkbVihq7F9gcZFm2iBmUVT7NCJ2xYpxb0rEIEh0sArXdI4KUcn1sHWDsAmxB
uEgYrBaM3n5SYclvw4HDFiynJVs05uJkCaFh/9GQTIyVWAFO3hk3U7eTNN8d
6HAtcSnAIotDFKfi3w5+p4Ahs4wDpJhlqgjx7J1xFHSVcnvrgR7hIHyfC51b
7x6XNaWJ2itN9FLqrBdTvLlhepnQUciiAlg0vX7ca7RKR3o8tcnQx5pgvBpn
XFDsESjTNmIFuYgl+UA5D2Dwj2nS2Upa46N45Zo6sjYAGnPSep7lMHI2fp4V
BVCv3nr2HDSrgC25G7SZRNgTIPMHgn+k4e0OvjrwsarKEc7wGSkwQncVl43S
DTt0QL8D5D2PoAKJDlu6y+e1j7dHEPTy8o6K2IuV+rAsEOZSofksK1FfggnR
3IORYMPVJZhTIiAlddcGC63V4vjJzIS+OWkbK7IKLJxs2Z61pfU4usnc97Ec
ZRtSdVWCWmd7rgDipxhbRXUD5bmslyagFCuWwDk1jp5V1X2eeYKDGobCk9TK
DMCIvN5kDhiy5OQLedWPilsjwwuRnllsYtWFHBIuMKqWpW03vSb4Z63NXsaK
0Y1sCel9li0iRSaNKEt8lUY+x6UJnACfYTeIW2hM6uVCyM/hSr/01TuvqqZI
Go6uKOnQTmEu8BV4osLjX2ZskuvTYLlCAXjgFWhebX5L3iibP5k38YREIQ/s
bQJ2Os5OEW5EA47v9268NgEd1mu57VPqkgFKRT0kKCiDGrPh/p6A6CSFeH4+
idbmkdiKih5sRx3q2iVBvYgoH8M5GwOqyGk0cZRMI79ThrkAEFVn6ZoX3+SW
a6EJM2477WLscDqsy+mot0knV155PTaimc+RHHdK+BcBf2G8fZes9Dd08wbf
SGq0hjvptYVZUQtOKAmrqOTuLax3/PRJ2Zr+xoaLYA3LOd+TKrd0HRxh11Q0
gXAh5jlmZZRdg6ZAUhcYQuo7Iumwlo3HGFnIo5GsQqXLa6scCHuX6eLSP+CR
pXRZryKowllWHA6NFyKEKSDGMjask93Sfv2A7zLUF9glzEuS8KCmHohSZbui
4tsGPkb9WBvYdonRIbD5dnaLlgYPrrCtl71u0NjiZ9h3kU1rEyzmZVD9DXIx
Ec29HlJ8/Q7tAjQCzDuzck/ad7JfeXaPABI1QosaMdGvgTdUZBd5AX+rHHh9
IrgECbtDdpN7xNBVxtAl+843dukbqTZj7hk0YTCpKx4uh/oFEz5dFDifmho9
Sa5MmgpPd6V8/UnmwkSXyxxjFKA2ZLdVm1sZ3490sOpcEsQ8xeEBVKiR8qiw
SxoN94igULnmEmR/LhgKO4PBCSuf1djUCdv0BMxZOVtnakuGGN0FmLKWgfoU
VRChrRKUiALzeW1aBvmBOWA8z9DKRX2xMUMyH+Ijt42GIjLapHoM3UW3uRet
UhcfuAtd6Ur9A9rG/kou6ZoVyqSUQyDHN+CCoiLdap6LA6ETIXJ2DffYC3JB
qrIUbz7G0kGCJgRnClrYJM4FTtZGcrtdYFQ5d7q7gIoTEvNSmmHYXsAgrmaz
Za0HLr7dsqxWLsnssRcrYlkQEcASfQsIXqowOWjb86ndLhPgWm2G9oy+IMbM
zsBS/C54CQyVsypsjFiPo8U9hKOgNCxnfjLS56Gjz+ZqGjbcq9TlBmPGR4c9
Pc3qLJ9TNItsugMF0nlaLCbOwJjFe3rNnZic8GOjoWL+w5u3OSqCrrGUfrNs
MYXmawT3OV67crvkl0gc+zEV09d1uI9ltxpN1t+t4GFRYty7YcOjxGYrW0U/
VcA8Ub7KAYlpQulgnSvA/OKG4dwjmoAim+a+5zXCSywWG6lY7z+yatKC6u3S
3s2LciES801NDVp8y7lXe3cVIQ23fpuMO2yNbFiJtz26VSwYB0xjMBfqxj/L
oYvf/D45fQCvyfbpADiuI8smkD3hMntQ7Psg+lWM5rYkZYmVh3GrtbCqbkKq
7senol2GfRisDVXaKZXDQKn302G9H3fX7nfF7aRARS5vknXwBJ00TXHCxqMp
cud3b3Nh4rzfrt70GQtubhwyA/yKBBflYTZOrL5/TSlLAC+1i1xqQxi1TYds
rhW1AR50LxfFOkrpA0WZdVICOhrbFfouOR74Fl30s4Fw4EJ+XBc/OzZ4tj6G
RuEzUi36MbQzxBdnwPnFBVjeG0nopxAW1koUVZOpeMF+zyvOkXikPKs5gCTg
Pd3lC6fh21sfmAumH/LGOXXk5kNQ1/O2LTrdAhpl5SAbBsvSmQauJkZ6Fwb6
tS0vKX2vNFDFJme/XDnLbp4RtzBIM0DHAl72VycRdtvDaiCzw7OIWy8LePiy
L7ZDE6yVEeHnNRmlwakhKjKu8JhNbUY8wolHLA3L4wdsullySgCTlyt4d08o
0c6DmKHfVWrwtjoLh2ojpxSNGwsr6QL6/m1xOfZzjUEAoPNdZUJqDSc2uf3O
89u7Vuqaiiy5lzSijuWtvFSGkTEJqykulFDXhGOwe66otLwXG/RSfmuUJE1r
8sYQj3hx9t1ZhEH4ZaB8Sb1hEOiqSdHKsikD5xf6DSYJYL4dUr16xy+svDFE
MZJ6z84Vw2tTihl8lQbzTV+keVvVp/otBhAym6yLoRtS1ekOaPJbP/n48X9e
Xrz65tOnJ04a4hDlcj7NvBsYwiAH9eSljDtmY6DrUu0HrEM2p8FoybybhNwP
z0jTI+v31ICCgIQj3iZeEnc3NIVZFl2uT+I2GkpEPcliBFfkPQMchHXO1RX6
O6jv46tkBdu0GSFbiFPbvaR6g/Vjby5VVikhh9nDi2enWl99/QxMyOXtLdUd
nurdbaXO2c2Nd4PUcNLoEtQvLi6/xdIkuZD7FG97l5NAdDubmbaRFBUF657t
Gwpn3xNh/msOAggWmsjtHXztuQ2AmXo8TLtszDkqm9yScBnS17C5l0m6vLdj
IHir5e3d4KtI8rQGI8neJstCv1z9gnFuOwy/7Vcl8wvihirye/HYwFD6dVLP
Kn2VF9UsiW8GwPxqmT7k6GTM21805r5wOW5gK1DzIGC8tpYhA4N/9l32M/ls
0C3X6PMVIPYPL5joz9+9uHpxeXHOvP1myboaCfc/5WBpfkhgZkwenoLRLHeE
6VewzOIHMIcbODaDUxxNPq/eXTBfovQ0NCtrLm/FS8UiryOZNAukzj+Zmoh/
vXzzHXnyAXnnC/eJGqYODpRmfGPR91fn5jPKtzuMUC2kzYWE856/PjtXdMkZ
jUPD6D9hd2W8YuDUzcAN5k71EnjOifs6B25QFGM8rWKc5qQDJfXqVD+BzdRA
reUT9/BFmfKI/w+Mw5TJz8gAAA==

-->
</rfc>

mirror server hosted at Truenetwork, Russian Federation.