rfc9202.original.xml   rfc9202.xml 
<?xml version='1.0' encoding='utf-8'?> <?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 --> <!DOCTYPE rfc [
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!ENTITY nbsp "&#160;">
<?rfc toc="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc sortrefs="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ]>
-ietf-ace-dtls-authorize-18" category="std" obsoletes="" updates="" submissionTy
pe="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
="3"> -ietf-ace-dtls-authorize-18" number="9202" obsoletes="" updates="" submissionTyp
e="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" sortRef
s="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.7.0 --> <!-- xml2rfc v2v3 conversion 3.7.0 -->
<front> <front>
<title abbrev="CoAP-DTLS">Datagram Transport Layer Security (DTLS) Profile f <title abbrev="DTLS Profile for ACE">Datagram Transport Layer Security (DTLS
or Authentication and Authorization for Constrained Environments (ACE)</title> ) Profile for Authentication and Authorization for Constrained Environments (ACE
<seriesInfo name="Internet-Draft" value="draft-ietf-ace-dtls-authorize-18"/> )</title>
<seriesInfo name="RFC" value="9202"/>
<author initials="S." surname="Gerdes" fullname="Stefanie Gerdes"> <author initials="S." surname="Gerdes" fullname="Stefanie Gerdes">
<organization>Universität Bremen TZI</organization> <organization>Universität Bremen TZI</organization>
<address> <address>
<postal> <postal>
<street>Postfach 330440</street> <street>Postfach 330440</street>
<city>Bremen</city> <city>Bremen</city>
<code>D-28359</code> <code>D-28359</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone>+49-421-218-63906</phone> <phone>+49-421-218-63906</phone>
skipping to change at line 70 skipping to change at line 73
<address> <address>
<postal> <postal>
<street>Djäknegatan 31</street> <street>Djäknegatan 31</street>
<city>Malmö</city> <city>Malmö</city>
<code>211 35</code> <code>211 35</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>ludwig.seitz@combitech.com</email> <email>ludwig.seitz@combitech.com</email>
</address> </address>
</author> </author>
<date year="2021" month="June" day="04"/> <date year="2022" month="August"/>
<area>Security</area> <area>Security</area>
<workgroup>ACE Working Group</workgroup> <workgroup>ACE</workgroup>
<keyword>Internet-Draft</keyword> <keyword>Internet of Things (IoT)</keyword>
<keyword>Internet of Things</keyword>
<keyword>IOT</keyword>
<keyword>OAuth</keyword>
<keyword>Access Token</keyword>
<abstract> <abstract>
<t>This specification defines a profile of the ACE framework that allows c <t>This specification defines a profile of the Authentication and Authoriz
onstrained servers ation for
to delegate client authentication and authorization. The protocol Constrained Environments (ACE) framework that allows constrained
relies on DTLS version 1.2 for communication security between entities in a servers to delegate client authentication and authorization. The protocol
constrained network using either raw public keys or pre-shared keys. A relies on DTLS version 1.2 or later for communication security between ent
resource-constrained server can use this protocol to delegate ities in a
management of authorization information to a trusted host with less constrained network using either raw public keys or pre-shared keys. A
severe limitations regarding processing power and memory.</t> resource-constrained server can use this protocol to delegate
management of authorization information to a trusted host with less-severe
limitations regarding processing power and memory.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>This specification defines a profile of the ACE framework <t>This specification defines a profile of the ACE framework
<xref target="I-D.ietf-ace-oauth-authz" format="default"/>. In this profile, a <xref target="RFC9200" format="default"/>. In this profile, a client (C) and a
client and a resource server (RS) use the Constrained Application Protocol (CoAP) <xref targe
resource server use CoAP <xref target="RFC7252" format="default"/> over DTLS ver t="RFC7252" format="default"/> over DTLS version 1.2 <xref target="RFC6347" form
sion 1.2 <xref target="RFC6347" format="default"/> at="default"/>
to communicate. This specification to communicate. This specification
uses DTLS 1.2 terminology, but later versions such as DTLS 1.3 can be uses DTLS 1.2 terminology, but later versions such as DTLS 1.3 <xref target="RFC
used instead. The client obtains an access token, bound to a key 9147"/> can be
(the proof-of-possession key), from an authorization server to prove used instead. The client obtains an access token bound to a key
(the proof-of-possession (PoP) key) from an authorization server (AS) to prove
its authorization to access protected resources hosted by the resource its authorization to access protected resources hosted by the resource
server. Also, the client and the resource server are provided by the server. Also, the client and the resource server are provided by the
authorization server with the necessary keying material to establish a authorization server with the necessary keying material to establish a
DTLS session. The communication between client and authorization DTLS session. The communication between the client and authorization
server may also be secured with DTLS. This specification supports server may also be secured with DTLS. This specification supports
DTLS with Raw Public Keys (RPK) <xref target="RFC7250" format="default"/> and wi DTLS with raw public keys (RPKs) <xref target="RFC7250" format="default"/> and w
th Pre-Shared Keys ith pre-shared keys
(PSK) <xref target="RFC4279" format="default"/>. How token introspection <xref t (PSKs) <xref target="RFC4279" format="default"/>. How token introspection <xref
arget="RFC7662" format="default"/> is performed target="RFC7662" format="default"/> is performed
between RS and AS is out of scope for this specification.</t> between the RS and AS is out of scope for this specification.</t>
<t>The ACE framework requires that client and server mutually
<t>The ACE framework requires that the client and server mutually
authenticate each other before any application data is exchanged. authenticate each other before any application data is exchanged.
DTLS enables mutual authentication if both client and server prove DTLS enables mutual authentication if both the client and server prove
their ability to use certain keying material in the DTLS handshake. their ability to use certain keying material in the DTLS handshake.
The authorization server assists in this process on the server side by The authorization server assists in this process on the server side by
incorporating keying material (or information about keying material) incorporating keying material (or information about keying material)
into the access token, which is considered a "proof of possession" into the access token, which is considered a proof-of-possession
token.</t> token.</t>
<t>In the RPK mode, the client proves that it can use the RPK bound to <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> 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 <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 this exchange. For the RPK mode, the client must upload the access
token to the resource server before initiating the handshake, as token to the resource server before initiating the handshake, as
described in Section 5.10.1 of the ACE framework described in <xref target="RFC9200" sectionFormat="of" section="5.10.1"> the ACE
<xref target="I-D.ietf-ace-oauth-authz" format="default"/>.</t> framework</xref>.</t>
<t>In the PSK mode, client and server show with the DTLS handshake that
<t>In the PSK mode, the client and server show with the DTLS handshake tha
t
they can use the keying material that is bound to the access token. 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, 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 the <tt>psk_identity</tt> parameter in the DTLS PSK handshake may be used
instead of uploading the token prior to the handshake.</t> 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 <t>As recommended in <xref target="RFC9200" sectionFormat="of" section="5.
" format="default"/>, this 8"/>, this
specification uses CBOR web tokens to convey claims within an access specification uses Concise Binary Object Representation (CBOR) web tokens to con
vey claims within an access
token issued by the server. While other formats could be used as well, token issued by the server. While other formats could be used as well,
those are out of scope for this document.</t> those are out of scope for this document.</t>
<section anchor="terminology" numbered="true" toc="default"> <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14
14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="defa >", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
ult"/> when, and only when, they appear in all "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in
BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" fo
rmat="default"/> when, and only when, they appear in all
capitals, as shown here.</t> capitals, as shown here.</t>
<t>Readers are expected to be familiar with the terms and concepts <t>Readers are expected to be familiar with the terms and concepts
described in <xref target="I-D.ietf-ace-oauth-authz" format="default"/> and in < described in <xref target="RFC9200" format="default"/> and <xref target="RFC9201
xref target="I-D.ietf-ace-oauth-params" format="default"/>.</t> " format="default"/>.</t>
<t>The authorization information (authz-info) resource refers to the aut <t>The authorization information (authz-info) resource refers to the aut
horization information endpoint as specified in <xref target="I-D.ietf-ace-oauth horization information endpoint, as specified in <xref target="RFC9200" format="
-authz" format="default"/>. default"/>.
The term <tt>claim</tt> is used in this document with the same semantics The term <tt>claim</tt> is used in this document with the same semantics
as in <xref target="I-D.ietf-ace-oauth-authz" format="default"/>, i.e., it denot es information carried as in <xref target="RFC9200" format="default"/>, i.e., it denotes information ca rried
in the access token or returned from introspection.</t> in the access token or returned from introspection.</t>
<t>Throughout this document, examples for CBOR data items are expressed
in
CBOR extended diagnostic notation as defined in
<xref section="8" sectionFormat="of" target="RFC8949"/> and
<xref section="G" sectionFormat="of" target="RFC8610"/>
("diagnostic notation"), unless noted otherwise.
We often use diagnostic notation comments to provide
a textual representation of the numeric parameter names and values.
</t>
</section> </section>
</section> </section>
<section anchor="overview" numbered="true" toc="default"> <section anchor="overview" numbered="true" toc="default">
<name>Protocol Overview</name> <name>Protocol Overview</name>
<t>The CoAP-DTLS profile for ACE specifies the transfer of authentication <t>The CoAP-DTLS profile for ACE specifies the transfer of authentication
information and, if necessary, authorization information between the information and, if necessary, authorization information between the
client (C) and the resource server (RS) during setup of a DTLS session 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 for CoAP messaging. It also specifies how the client can use CoAP over
DTLS to retrieve an access token from the authorization server (AS) DTLS to retrieve an access token from the authorization server (AS)
for a protected resource hosted on the resource server. As specified 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"/>, us e of DTLS for one or in <xref target="RFC9200" sectionFormat="of" section="6.7"/>, use of DTLS for on e or
both of these interactions is completely independent.</t> both of these interactions is completely independent.</t>
<t>This profile requires the client to retrieve an access token for <t>This profile requires the client to retrieve an access token for the
protected resource(s) it wants to access on the resource server as protected resource(s) it wants to access on the resource server, as
specified in <xref target="I-D.ietf-ace-oauth-authz" format="default"/>. <xref t specified in <xref target="RFC9200" format="default"/>. <xref target="at-retriev
arget="at-retrieval" format="default"/> shows the al" format="default"/> shows the
typical message flow in this scenario (messages in square brackets are typical message flow in this scenario (messages in square brackets are
optional):</t> optional):</t>
<figure anchor="at-retrieval"> <figure anchor="at-retrieval">
<name>Retrieving an Access Token</name> <name>Retrieving an Access Token</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
C RS AS C RS AS
| [---- Resource Request ------>]| | | [---- Resource Request ------>]| |
| | | | | |
| [<-AS Request Creation Hints-] | | | [<-AS Request Creation Hints-] | |
| | | | | |
| ------- Token Request ----------------------------> | | ------- Token Request ----------------------------> |
| | | | | |
| <---------------------------- Access Token --------- | | <---------------------------- Access Token --------- |
| + Access Information | | + Access Information |
]]></artwork> ]]></artwork>
</figure> </figure>
<t>To determine the authorization server in charge of a resource hosted <t>To determine the authorization server in charge of a resource hosted
at the resource server, the client can send an initial Unauthorized at the resource server, the client can send an initial Unauthorized
Resource Request message to the resource server. The resource server Resource Request message to the resource server. The resource server
then denies the request and sends an AS Request Creation Hints message then denies the request and sends an AS Request Creation Hints message
containing the address of its authorization server back to the client containing the address of its authorization server back to the client,
as specified in Section 5.3 of <xref target="I-D.ietf-ace-oauth-authz" format="d as specified in <xref target="RFC9200" sectionFormat="of" section ="5.3"/>.</t>
efault"/>.</t>
<t>Once the client knows the authorization server's address, it can send <t>Once the client knows the authorization server's address, it can send
an access token request to the token endpoint at the authorization an access token request to the token endpoint at the authorization
server as specified in <xref target="I-D.ietf-ace-oauth-authz" format="default"/ server, as specified in <xref target="RFC9200" format="default"/>. As the access
>. As the access token request and the response may contain confidential data,
token request as well as the response may contain confidential data,
the communication between the client and the authorization server must the communication between the client and the authorization server must
be confidentiality-protected and ensure authenticity. The client is be confidentiality protected and ensure authenticity. The client is
expected to have been registered at the authorization server as expected to have been registered at the authorization server, as
outlined in Section 4 of <xref target="I-D.ietf-ace-oauth-authz" format="default outlined in <xref target="RFC9200" sectionFormat="of" section="4"/>.</t>
"/>.</t>
<t>The access token returned by the authorization server can then be used <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 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 server. When the client intends to use an asymmetric proof-of-possession key in the
DTLS handshake with the resource server, the client MUST upload the DTLS handshake with the resource server, the client <bcp14>MUST</bcp14> upload t
access token to the authz-info resource, i.e. the authz-info endpoint, he
access token to the authz-info resource, i.e., the authz-info endpoint,
on the resource server before on the resource server before
starting the DTLS handshake, as described in Section 5.10.1 of starting the DTLS handshake, as described in
<xref target="I-D.ietf-ace-oauth-authz" format="default"/>. In case the client u <xref target="RFC9200" sectionFormat="of" section="5.10.1"/>. In case the client
ses a symmetric proof-of-possession uses a symmetric proof-of-possession
key in the DTLS handshake, the procedure as above MAY be used, or alternatively, key in the DTLS handshake, the procedure above <bcp14>MAY</bcp14> be used, or al
the access token MAY instead be transferred in the ternatively
the access token <bcp14>MAY</bcp14> instead be transferred in the
DTLS ClientKeyExchange message (see <xref target="psk-dtls-channel" format="defa ult"/>). DTLS ClientKeyExchange message (see <xref target="psk-dtls-channel" format="defa ult"/>).
In any case, DTLS MUST be used in a mode that provides replay In any case, DTLS <bcp14>MUST</bcp14> be used in a mode that provides replay
protection.</t> protection.</t>
<t><xref target="protocol-overview" format="default"/> depicts the common protocol flow for the DTLS <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 profile after the client has retrieved the access token from the
authorization server, AS.</t> authorization server (AS).</t>
<figure anchor="protocol-overview"> <figure anchor="protocol-overview">
<name>Protocol overview</name> <name>Protocol Overview</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
C RS AS C RS AS
| [--- Access Token ------>] | | | [--- Access Token ------>] | |
| | | | | |
| <== DTLS channel setup ==> | | | <== DTLS channel setup ==> | |
| | | | | |
| == Authorized Request ===> | | | == Authorized Request ===> | |
| | | | | |
| <=== Protected Resource == | | | <=== Protected Resource == | |
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="protocol-flow" numbered="true" toc="default"> <section anchor="protocol-flow" numbered="true" toc="default">
<name>Protocol Flow</name> <name>Protocol Flow</name>
<t>The following sections specify how CoAP is used to interchange <t>The following sections specify how CoAP is used to interchange
access-related data between the resource server, the client and the access-related data between the resource server, the client, and the
authorization server so that the authorization server can provide the authorization server so that the authorization server can provide the
client and the resource server with sufficient information to client and the resource server with sufficient information to
establish a secure channel, and convey authorization information establish a secure channel and convey authorization information
specific for this communication relationship to the resource server.</t> specific for this communication relationship to the resource server.</t>
<t><xref target="C-AS-comm" format="default"/> describes how the communica <t><xref target="C-AS-comm" format="default"/> describes how the communica
tion between the client (C) and tion between
the authorization server (AS) must be secured. the client (C) and the authorization server (AS) must be secured.
Depending on the used CoAP security mode (see also Depending on the CoAP security mode used (see also
Section 9 of <xref target="RFC7252" format="default"/>, <xref target="RFC7252" sectionFormat="of" section="9"/>),
the Client-to-AS request, AS-to-Client response and DTLS session the client-to-AS request, AS-to-client response, and DTLS session
establishment carry slightly different information. <xref target="rpk-mode" form establishment carry slightly different information. <xref target="rpk-mode
at="default"/> "
addresses the use of raw public keys while <xref target="psk-mode" format="defau format="default"/> addresses the use of raw public keys, while <xref targe
lt"/> defines how t="psk-mode"
pre-shared keys are used in this profile.</t> format="default"/> defines how pre-shared keys are used in this profile.</
t>
<section anchor="C-AS-comm" numbered="true" toc="default"> <section anchor="C-AS-comm" numbered="true" toc="default">
<name>Communication Between the Client and the Authorization Server</nam e> <name>Communication between the Client and the Authorization Server</nam e>
<t>To retrieve an access token for the resource that the client wants to <t>To retrieve an access token for the resource that the client wants to
access, the client requests an access token from the authorization access, the client requests an access token from the authorization
server. Before the client can request the access token, the client and server. Before the client can request the access token, the client and
the authorization server MUST establish the authorization server <bcp14>MUST</bcp14> establish
a secure communication channel. This profile assumes that the keying a secure communication channel. This profile assumes that the keying
material to secure this communication channel has securely been obtained material to secure this communication channel has securely been obtained
either by manual configuration or in an automated provisioning process. either by manual configuration or in an automated provisioning process.
The following requirements in alignment with Section 6.5 of The following requirements, in alignment with <xref target="RFC9200"
<xref target="I-D.ietf-ace-oauth-authz" format="default"/> therefore must be met sectionFormat="of" section="6.5"/>, therefore must be met:</t>
:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The client MUST securely have obtained keying material to communic <li>The client <bcp14>MUST</bcp14> securely have obtained keying mater
ate ial to
with the authorization server.</li> communicate with the authorization server.</li>
<li>Furthermore, the client MUST verify that the authorization server <li>Furthermore, the client <bcp14>MUST</bcp14> verify that the author
is ization
authorized to provide access tokens (including authorization server is authorized to provide access tokens (including authorization
information) about the resource server to the client, and that information) about the resource server to the client and that
this authorization information about the authorization server is still valid.</l this authorization information about the authorization server is still
i> valid.</li>
<li>Also, the authorization server MUST securely have obtained keying <li>Also, the authorization server <bcp14>MUST</bcp14> securely have o
material for the client, and obtained authorization rules approved btained keying
by the resource owner (RO) concerning the client and the resource material for the client and obtained authorization rules approved
server that relate to this keying material.</li> by the resource owner (RO) concerning the client and the resource
server that relate to this keying material.</li>
</ul> </ul>
<t>The client and the authorization server MUST use their respective <t>The client and the authorization server <bcp14>MUST</bcp14> use their
keying material for all exchanged messages. How the security respective
association between the client and the authorization server is keying material for all exchanged messages. How the security
bootstrapped is not part of this document. The client and the association between the client and the authorization server is
authorization server must ensure the confidentiality, integrity and bootstrapped is not part of this document. The client and the
authenticity of all exchanged messages within the ACE protocol.</t> authorization server must ensure the confidentiality, integrity, and
authenticity of all exchanged messages within the ACE protocol.</t>
<t><xref target="as-commsec" format="default"/> specifies how communicat ion with the authorization server is secured.</t> <t><xref target="as-commsec" format="default"/> specifies how communicat ion with the authorization server is secured.</t>
</section> </section>
<section anchor="rpk-mode" numbered="true" toc="default"> <section anchor="rpk-mode" numbered="true" toc="default">
<name>Raw Public Key Mode</name> <name>Raw Public Key Mode</name>
<t>When the client uses raw public key authentication, the procedure is as <t>When the client uses raw public key authentication, the procedure is as
described in the following.</t> described in the following.</t>
<section anchor="access-token-retrieval-from-the-authorization-server" n umbered="true" toc="default"> <section anchor="access-token-retrieval-from-the-authorization-server" n umbered="true" toc="default">
<name>Access Token Retrieval from the Authorization Server</name> <name>Access Token Retrieval from the Authorization Server</name>
<t>After the client and the authorization server mutually authenticate d each other and validated each <t>After the client and the authorization server mutually authenticate d each other and validated each
other's authorization, the client sends a token request to the authorization ser ver's token endpoint. other's authorization, the client sends a token request to the authorization ser ver's token endpoint.
The client MUST add a <tt>req_cnf</tt> object carrying either its raw public key The client <bcp14>MUST</bcp14> add a <tt>req_cnf</tt> object carrying either its raw public key
or a unique identifier for a public key that it has previously made or a unique identifier for a public key that it has previously made
known to the authorization server. It is RECOMMENDED that known to the authorization server. It is <bcp14>RECOMMENDED</bcp14> that
the client uses DTLS with the same keying material to secure the the client uses DTLS with the same keying material to secure the
communication with the authorization server, proving possession of the key communication with the authorization server, proving possession of the key
as part of the token request. Other mechanisms for proving possession of as part of the token request. Other mechanisms for proving possession of
the key may be defined in the future.</t> the key may be defined in the future.</t>
<t>An example access token request from the client to the authorizatio n <t>An example access token request from the client to the authorizatio n
server is depicted in <xref target="rpk-authorization-message-example" format="d efault"/>.</t> server is depicted in <xref target="rpk-authorization-message-example" format="d efault"/>.</t>
<figure anchor="rpk-authorization-message-example"> <figure anchor="rpk-authorization-message-example">
<name>Access Token Request Example for RPK Mode</name> <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 POST coaps://as.example.com/token
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Payload: Payload:
{ {
grant_type : client_credentials, / grant_type / 33 : / client_credentials / 2,
audience : "tempSensor4711", / audience / 5 : "tempSensor4711",
req_cnf : { / req_cnf / 4 : {
COSE_Key : { / COSE_Key / 1 : {
kty : EC2, / kty / 1 : / EC2 / 2,
crv : P-256, / crv / -1 : / P-256 / 1,
x : h'e866c35f4c3c81bb96a1...', / x / -2 : h'e866c35f4c3c81bb96a1/.../',
y : h'2e25556be097c8778a20...' / y / -3 : h'2e25556be097c8778a20/.../'
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The example shows an access token request for the resource identifi ed <t>The example shows an access token request for the resource identifi ed
by the string "tempSensor4711" on the authorization server by the string "tempSensor4711" on the authorization server
using a raw public key.</t> using a raw public key.</t>
<t>The authorization server MUST check if the client that it communica tes <t>The authorization server <bcp14>MUST</bcp14> check if the client th at it communicates
with is associated with the RPK in the <tt>req_cnf</tt> parameter before 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 issuing an access token to it. If the authorization server determines
that the request is to be authorized according to the respective that the request is to be authorized according to the respective
authorization rules, it generates an access token response for the authorization rules, it generates an access token response for the
client. The access token MUST be bound to the RPK of the client by client. The access token <bcp14>MUST</bcp14> be bound to the RPK of the client b y
means of the <tt>cnf</tt> claim.</t> means of the <tt>cnf</tt> claim.</t>
<t>The response MUST contain an <tt>ace_profile</tt> parameter if <t>The response <bcp14>MUST</bcp14> contain an <tt>ace_profile</tt> pa
the<tt>ace_profile</tt> parameter in the request is empty, and MAY contain rameter if
this parameter otherwise (see Section 5.8.2 of the <tt>ace_profile</tt> parameter in the request is empty and <bcp14>M
<xref target="I-D.ietf-ace-oauth-authz" format="default"/>). This parameter is s AY</bcp14>
et to <tt>coap_dtls</tt> to contain this parameter otherwise (see
indicate that this profile MUST be used for communication between the <xref target="RFC9200" sectionFormat="of" section="5.8.2"/>). This para
client and the resource server. The response meter is set
also contains an access token with information for the resource server to <tt>coap_dtls</tt> to
about the client's public key. The authorization server MUST return in indicate that this profile <bcp14>MUST</bcp14> be used for communicatio
its response the parameter <tt>rs_cnf</tt> unless it is certain that the n between the
client already knows the public key of the resource server. The client and the resource server. The response
authorization server MUST ascertain that the RPK specified in <tt>rs_cnf</tt> also contains an access token with information for the resource server
belongs to the resource server that the client wants to communicate about the client's public key. The authorization server <bcp14>MUST</bc
with. The authorization server MUST protect the integrity of the p14> return
access token such that the resource server can detect unauthorized in its response the parameter <tt>rs_cnf</tt> unless it is certain that
changes. If the access token contains confidential data, the the
authorization server MUST also protect the confidentiality of the client already knows the public key of the resource server. The
access token.</t> authorization server <bcp14>MUST</bcp14> ascertain that the RPK specifi
<t>The client MUST ascertain that the access token response belongs to ed in
a certain <tt>rs_cnf</tt> belongs to the resource server that the client wants to
previously sent access token request, as the request may specify the communicate
resource server with which the client wants to communicate.</t> with. The authorization server <bcp14>MUST</bcp14> protect the integrit
y of the
access token such that the resource server can detect unauthorized
changes. If the access token contains confidential data, the
authorization server <bcp14>MUST</bcp14> also protect the confidentiali
ty of the
access token.</t>
<t>The client <bcp14>MUST</bcp14> ascertain that the access token resp
onse belongs
to a certain, previously sent access token request, as the request may
specify the
resource server with which the client wants to communicate.</t>
<t>An example access token response from the authorization server to t he client <t>An example access token response from the authorization server to t he client
is depicted in <xref target="rpk-authorization-response-example" format="default is depicted in <xref target="rpk-authorization-response-example"
"/>. Here, the format="default"/>. Here, the
contents of the <tt>access_token</tt> claim have been truncated to improve contents of the <tt>access_token</tt> claim have been truncated to impr
readability. The response comprises access information for the client ove
that contains the server's public key in the <tt>rs_cnf</tt> parameter. readability. For the client, the response comprises Access Information
Caching proxies process the Max-Age option in the CoAP response which that contains the server's public key in the <tt>rs_cnf</tt> parameter.
has a default value of 60 seconds (Section 5.6.1 of <xref target="RFC7252" forma Caching proxies process the Max-Age option in the CoAP response, which
t="default"/>). has a default value of 60 seconds (<xref target="RFC7252" sectionFormat
The authorization server SHOULD ="of"
adjust the Max-Age option such that it does not exceed the section="5.6.1"/>).
<tt>expires_in</tt> parameter to avoid stale responses.</t> The authorization server <bcp14>SHOULD</bcp14>
adjust the Max-Age option such that it does not exceed the
<tt>expires_in</tt> parameter to avoid stale responses.</t>
<figure anchor="rpk-authorization-response-example"> <figure anchor="rpk-authorization-response-example">
<name>Access Token Response Example for RPK Mode</name> <name>Access Token Response Example for RPK Mode</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
2.01 Created 2.01 Created
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Max-Age: 3560 Max-Age: 3560
Payload: Payload:
{ {
access_token : b64'SlAV32hkKG... / access_token / 1 : b64'SlAV32hk'/...
(remainder of CWT omitted for brevity; (remainder of CWT omitted for brevity;
CWT contains the client's RPK in the cnf claim)', CWT contains the client's RPK in the cnf claim)/,
expires_in : 3600, / expires_in / 2 : 3600,
rs_cnf : { / rs_cnf / 41 : {
COSE_Key : { / COSE_Key / 1 : {
kty : EC2, / kty / 1 : / EC2 / 2,
crv : P-256, / crv / -1 : / P-256 / 1,
x : h'd7cc072de2205bdc1537...', / x / -2 : h'd7cc072de2205bdc1537/.../',
y : h'f95e1d4b851a2cc80fff...' / y / -3 : h'f95e1d4b851a2cc80fff/.../'
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="rpk-dtls-channel" numbered="true" toc="default"> <section anchor="rpk-dtls-channel" numbered="true" toc="default">
<name>DTLS Channel Setup Between Client and Resource Server</name> <name>DTLS Channel Setup between the Client and Resource Server</name>
<t>Before the client initiates the DTLS handshake with the resource <t>Before the client initiates the DTLS handshake with the resource
server, the client MUST send a <tt>POST</tt> request containing the obtained server, the client <bcp14>MUST</bcp14> send a <tt>POST</tt> request containing t he obtained
access token to the authz-info resource hosted by the resource access token to the authz-info resource hosted by the resource
server. After the client receives a confirmation that the resource server. After the client receives a confirmation that the resource
server has accepted the access token, it proceeds to establish a server has accepted the access token, it proceeds to establish a
new DTLS channel with the resource server. The client MUST use its new DTLS channel with the resource server. The client <bcp14>MUST</bcp14> use i ts
correct public key in the DTLS handshake. If the authorization server 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 has specified a <tt>cnf</tt> field in the access token response, the client
MUST use this key. Otherwise, the client MUST use the public key that <bcp14>MUST</bcp14> use this key. Otherwise, the client <bcp14>MUST</bcp14> use the public key that
it specified in the <tt>req_cnf</tt> of the access token request. The client it specified in the <tt>req_cnf</tt> of the access token request. The client
MUST specify this public key in the SubjectPublicKeyInfo structure of <bcp14>MUST</bcp14> specify this public key in the SubjectPublicKeyInfo structur
the DTLS handshake as described in <xref target="RFC7250" format="default"/>.</t e of
> the DTLS handshake, as described in <xref target="RFC7250" format="default"/>.</
t>
<t>If the client does not have the keying material belonging to the <t>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 public key, the client <bcp14>MAY</bcp14> try to send an access token request to
AS where it specifies its public key in the <tt>req_cnf</tt> parameter. If the
AS, where the client specifies its public key in the <tt>req_cnf</tt> parameter.
If
the AS still specifies a public key in the response that the client the AS still specifies a public key in the response that the client
does not have, the client SHOULD re-register with the authorization does not have, the client <bcp14>SHOULD</bcp14> re-register with the authorizati on
server to establish a new client public key. This process is out of server to establish a new client public key. This process is out of
scope for this document.</t> scope for this document.</t>
<t>To be consistent with <xref target="RFC7252" format="default"/>, wh ich allows for shortened MAC tags <t>To be consistent with <xref target="RFC7252" format="default"/>, wh ich allows for shortened Message Authentication Code (MAC) tags
in constrained environments, in constrained environments,
an implementation that supports the RPK mode of this profile MUST at an implementation that supports the RPK mode of this profile <bcp14>MUST</bcp14> at
least support the cipher suite least support the cipher suite
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 <xref target="RFC7251" format="default"/>. TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 <xref target="RFC7251" format="default"/>.
As discussed in <xref target="RFC7748" format="default"/>, new ECC As discussed in <xref target="RFC7748" format="default"/>, new Elliptic Curve Cr yptography (ECC)
curves have been defined recently that are considered superior to curves have been defined recently that are considered superior to
the so-called NIST curves. Implementations of this profile therefore the so-called NIST curves. Implementations of this profile <bcp14>MUST</bcp14>
MUST implement support for curve25519 (cf. <xref target="RFC8032" format="defa therefore
ult"/>, <xref target="RFC8422" format="default"/>) implement support for curve25519 (cf.&nbsp;<xref target="RFC8032" format="defa
as this curve said to be efficient and less dangerous ult"/>, <xref target="RFC8422" format="default"/>),
regarding implementation errors than the secp256r1 curve mandated in as this curve is said to be efficient and less dangerous,
regarding implementation errors, than the secp256r1 curve mandated in
<xref target="RFC7252" format="default"/>.</t> <xref target="RFC7252" format="default"/>.</t>
<t>The resource server MUST check if the access token is still valid, if <t>The resource server <bcp14>MUST</bcp14> check if the access token i s still valid, if
the resource server is the intended destination (i.e., the audience) the resource server is the intended destination (i.e., the audience)
of the token, and if the token was issued by an authorized of the token, and if the token was issued by an authorized
authorization server (see also section 5.10.1.1 of authorization server (see also
<xref target="I-D.ietf-ace-oauth-authz" format="default"/>). <xref target="RFC9200" sectionFormat="of" section="5.10.1.1"/>).
The access token is constructed by the The access token is constructed by the
authorization server such that the resource server can associate the authorization server such that the resource server can associate the
access token with the Client's public key. The <tt>cnf</tt> claim MUST access token with the client's public key. The <tt>cnf</tt> claim <bcp14>MUST</ bcp14>
contain either the client's RPK or, if the key is already known by the 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 resource server (e.g., from previous communication), a reference to
this key. If the authorization server has no certain knowledge that this key. If the authorization server has no certain knowledge that
the Client's key is already known to the resource server, the Client's the client's key is already known to the resource server, the client's
public key MUST be included in the access token's <tt>cnf</tt> parameter. If public key <bcp14>MUST</bcp14> be included in the access token's <tt>cnf</tt> pa
rameter. If
CBOR web tokens <xref target="RFC8392" format="default"/> are used (as recommend ed in CBOR web tokens <xref target="RFC8392" format="default"/> are used (as recommend ed in
<xref target="I-D.ietf-ace-oauth-authz" format="default"/>), keys MUST be encode <xref target="RFC9200" format="default"/>), keys <bcp14>MUST</bcp14> be encoded
d as specified in as specified in
<xref target="RFC8747" format="default"/>. A resource server MUST have the capac <xref target="RFC8747" format="default"/>. A resource server <bcp14>MUST</bcp14>
ity to store one have the capacity to store one
access token for every proof-of-possession key of every authorized client.</t> 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 <t>The raw public key used in the DTLS handshake with the client <bcp1 4>MUST</bcp14>
belong to the resource server. If the resource server has several raw belong to the resource server. If the resource server has several raw
public keys, it needs to determine which key to use. The authorization 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 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 the access token that is associated with this communication. In this
case, the resource server MUST use the information from the <tt>cnf</tt> case, the resource server <bcp14>MUST</bcp14> use the information from the <tt>c nf</tt>
field to select the proper keying material.</t> field to select the proper keying material.</t>
<t>Thus, the handshake only finishes if the client and the resource <t>Thus, the handshake only finishes if the client and the resource
server are able to use their respective keying material.</t> server are able to use their respective keying material.</t>
</section> </section>
</section> </section>
<section anchor="psk-mode" numbered="true" toc="default"> <section anchor="psk-mode" numbered="true" toc="default">
<name>PreSharedKey Mode</name> <name>Pre-shared Key Mode</name>
<t>When the client uses pre-shared key authentication, the procedure is <t>When the client uses pre-shared key authentication, the procedure is
as described in the following.</t> as described in the following.</t>
<section anchor="access-token-retrieval-from-the-authorization-server-1" numbered="true" toc="default"> <section anchor="access-token-retrieval-from-the-authorization-server-1" numbered="true" toc="default">
<name>Access Token Retrieval from the Authorization Server</name> <name>Access Token Retrieval from the Authorization Server</name>
<t>To retrieve an access token for the resource that the client wants to <t>To retrieve an access token for the resource that the client wants to
access, the client MAY include a <tt>cnf</tt> object carrying an identifier access, the client <bcp14>MAY</bcp14> include a <tt>req_cnf</tt> object carrying an identifier
for a symmetric key in its access token request to the authorization for a symmetric key in its access token request to the authorization
server. This identifier can be used by the authorization server to server. This identifier can be used by the authorization server to
determine the shared secret to construct the proof-of-possession determine the shared secret to construct the proof-of-possession
token. The authorization server MUST check if the identifier refers token. The authorization server <bcp14>MUST</bcp14> check if the identifier ref ers
to a symmetric key that was previously generated by the authorization to a symmetric key that was previously generated by the authorization
server as a shared secret for the communication between this client server as a shared secret for the communication between this client
and the resource server. If no such symmetric key was found, the and the resource server. If no such symmetric key was found, the
authorization server MUST generate a new symmetric key that is authorization server <bcp14>MUST</bcp14> generate a new symmetric key that is
returned in its response to the client.</t> returned in its response to the client.</t>
<t>The authorization server MUST determine the authorization rules for <t>The authorization server <bcp14>MUST</bcp14> determine the authoriz
the client it communicates with as defined by the resource owner and ation rules
generate the access token accordingly. If the authorization server for the client it communicates with, as defined by the resource owner,
authorizes the client, it returns an AS-to-Client response. If the and
<tt>ace_profile</tt> parameter is present, it is set to <tt>coap_dtls</tt>. The generate the access token accordingly. If the authorization server
authorization server MUST ascertain that the access token is generated authorizes the client, it returns an AS-to-client response. If the
for the resource server that the client wants to communicate <tt>ace_profile</tt> parameter is present, it is set to <tt>coap_dtls</
with. Also, the authorization server MUST protect the integrity of the tt>. The
access token to ensure that the resource server can detect authorization server <bcp14>MUST</bcp14> ascertain that the access toke
unauthorized changes. If the token contains confidential data such as n is
the symmetric key, the confidentiality of the token MUST also be generated for the resource server that the client wants to communicate
protected. Depending on the requested token type and algorithm in the with. Also, the authorization server <bcp14>MUST</bcp14> protect the in
access token request, the authorization server adds access Information tegrity of
to the response that provides the client with sufficient information the access token to ensure that the resource server can detect
to setup a DTLS channel with the resource server. The authorization unauthorized changes. If the token contains confidential data, such as
server adds a <tt>cnf</tt> parameter to the access information carrying a the symmetric key, the confidentiality of the token <bcp14>MUST</bcp14>
<tt>COSE_Key</tt> object that informs the client about the shared secret that also be
is to be used between the client and the resource server. To convey protected. Depending on the requested token type and algorithm in the
the same secret to the resource server, the authorization server access token request, the authorization server adds Access Information
can include it directly in the access token by means of the <tt>cnf</tt> to the response that provides the client with sufficient information
claim or provide sufficient information to enable the resource to set up a DTLS channel with the resource server. The authorization
server to derive the shared secret from the access token. As an server adds a <tt>cnf</tt> parameter to the Access Information carrying
alternative, the resource server MAY use token introspection to a
retrieve the keying material for this access token directly from the <tt>COSE_Key</tt> object that informs the client about the shared secre
authorization server.</t> t that
is to be used between the client and the resource server. To convey
the same secret to the resource server, the authorization server
can include it directly in the access token by means of the <tt>cnf</tt
>
claim or provide sufficient information to enable the resource
server to derive the shared secret from the access token. As an
alternative, the resource server <bcp14>MAY</bcp14> use token introspec
tion 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 symmetri c <t>An example access token request for an access token with a symmetri c
proof-of-possession key is illustrated in <xref target="at-request" format="defa ult"/>.</t> proof-of-possession key is illustrated in <xref target="at-request" format="defa ult"/>.</t>
<figure anchor="at-request"> <figure anchor="at-request">
<name>Example Access Token Request, (implicit) symmetric PoP-key</na <name>Example Access Token Request, (Implicit) Symmetric PoP Key</na
me> me>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
POST coaps://as.example.com/token POST coaps://as.example.com/token
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Payload: Payload:
{ {
audience : "smokeSensor1807", / audience / 5 : "smokeSensor1807"
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>A corresponding example access token response is illustrated in <t>A corresponding example access token response is illustrated in
<xref target="at-response" format="default"/>. In this example, the authorizati on server returns a <xref target="at-response" format="default"/>. In this example, the authorizati on server returns a
2.01 response containing a new access token (truncated to improve 2.01 response containing a new access token (truncated to improve
readability) and information for the client, including the symmetric readability) and information for the client, including the symmetric
key in the cnf claim. The information is transferred as a CBOR data key in the <tt>cnf</tt> claim. The information is transferred as a CBOR data
structure as specified in <xref target="I-D.ietf-ace-oauth-authz" format="defaul structure as specified in <xref target="RFC9200" format="default"/>.</t>
t"/>.</t>
<!-- msg1 -->
<figure anchor="at-response"> <figure anchor="at-response">
<name>Example Access Token Response, symmetric PoP-key</name> <name>Example Access Token Response, Symmetric PoP Key</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
2.01 Created 2.01 Created
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Max-Age: 85800 Max-Age: 85800
Payload: Payload:
{ {
access_token : h'd08343a10... / access_token / 1 : h'd08343a1/...
(remainder of CWT omitted for brevity) (remainder of CWT omitted for brevity)/',
token_type : PoP, / token_type / 34 : / PoP / 2,
expires_in : 86400, / expires_in / 2 : 86400,
profile : coap_dtls, / ace_profile / 38 : / coap_dtls / 1,
cnf : { / cnf / 8 : {
COSE_Key : { / COSE_Key / 1 : {
kty : symmetric, / kty / 1 : / symmetric / 4,
kid : h'3d027833fc6267ce', / kid / 2 : h'3d027833fc6267ce',
k : h'73657373696f6e6b6579' / k / -1 : h'73657373696f6e6b6579'
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The access token also comprises a <tt>cnf</tt> claim. This claim us ually <t>The access token also comprises a <tt>cnf</tt> claim. This claim us ually
contains a <tt>COSE_Key</tt> object <xref target="RFC8152" format="default"/> th at carries either the symmetric key contains a <tt>COSE_Key</tt> object <xref target="RFC8152" format="default"/> th at carries either the symmetric key
itself or a key identifier that can be used by the resource server to 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 determine the secret key it shares with the client. If the access
token carries a symmetric key, the access token MUST be encrypted token carries a symmetric key, the access token <bcp14>MUST</bcp14> be encrypted
using a <tt>COSE_Encrypt0</tt> structure (see section 7.1 of <xref target="RFC83 using a <tt>COSE_Encrypt0</tt> structure (see <xref target="RFC8392" sectionForm
92" format="default"/>). The at="of" section="7.1"/>). The
authorization server MUST use authorization server <bcp14>MUST</bcp14> use
the keying material shared with the resource server to encrypt the the keying material shared with the resource server to encrypt the
token.</t> token.</t>
<t>The <tt>cnf</tt> structure in the access token is provided in <xref target="kdf-cnf" format="default"/>.</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"> <figure anchor="kdf-cnf">
<name>Access Token without Keying Material</name> <name>Access Token without Keying Material</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
cnf : { / cnf / 8 : {
COSE_Key : { / COSE_Key / 1 : {
kty : symmetric, / kty / 1 : / symmetric / 4,
kid : h'3d027833fc6267ce' / kid / 2 : h'3d027833fc6267ce'
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>A response that declines any operation on the requested resource is <t>A response that declines any operation on the requested resource is
constructed according to Section 5.2 of <xref target="RFC6749" format="default"/ constructed according to <xref target="RFC6749" sectionFormat="of" section="5.2"
>, />
(cf. Section 5.8.3. of <xref target="I-D.ietf-ace-oauth-authz" format="default"/ (cf.&nbsp;<xref target="RFC9200" sectionFormat="of" section="5.8.3"/>). <xref ta
>). <xref target="token-reject" format="default"/> rget="token-reject" format="default"/>
shows an example for a request that has been rejected due to invalid shows an example for a request that has been rejected due to invalid
request parameters.</t> request parameters.</t>
<figure anchor="token-reject"> <figure anchor="token-reject">
<name>Example Access Token Response With Reject</name> <name>Example Access Token Response with Reject</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
4.00 Bad Request 4.00 Bad Request
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Payload: Payload:
{ {
error : invalid_request / error / 30 : / invalid_request / 1
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The method for how the resource server determines the symmetric key <t>The method for how the resource server determines the symmetric key
from an access token containing only a key identifier is from an access token containing only a key identifier is
application-specific; the remainder of this section provides one application specific; the remainder of this section provides one
example.</t> example.</t>
<t>The authorization server and the resource server are assumed to sha re <t>The authorization server and the resource server are assumed to sha re
a key derivation key used to derive the symmetric key shared with the a key derivation key used to derive the symmetric key shared with the
client from the key identifier in the access token. The key client from the key identifier in the access token. The key
derivation key may be derived from some other secret key shared derivation key may be derived from some other secret key shared
between the authorization server and the resource server. This key between the authorization server and the resource server. This key
needs to be securely stored and processed in the same way as the 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 used to protect the communication between the authorization server and
the resource server.</t> the resource server.</t>
<t>Knowledge of the symmetric key shared with the client must not reve al <t>Knowledge of the symmetric key shared with the client must not reve al
any information about the key derivation key or other secret keys any information about the key derivation key or other secret keys
shared between the authorization server and resource server.</t> shared between the authorization server and resource server.</t>
<t>In order to generate a new symmetric key to be used by client and <t>In order to generate a new symmetric key to be used by the client a nd
resource server, the authorization server generates a new key resource server, the authorization server generates a new key
identifier which MUST be unique among all key identifiers used by the identifier that <bcp14>MUST</bcp14> be unique among all key identifiers used by the
authorization server for this resource server. The authorization server then use s the key authorization server for this resource server. The authorization server then use s the key
derivation key shared with the resource server to derive the symmetric derivation key shared with the resource server to derive the symmetric
key as specified below. Instead of providing the keying material in key, as specified below. Instead of providing the keying material in
the access token, the authorization server includes the key identifier the access token, the authorization server includes the key identifier
in the <tt>kid</tt> parameter, see <xref target="kdf-cnf" format="default"/>. Th is key identifier enables in the <tt>kid</tt> parameter (see <xref target="kdf-cnf" format="default"/>). T his key identifier enables
the resource server to calculate the symmetric key used for the the resource server to calculate the symmetric key used for the
communication with the client using the key derivation key and a KDF communication with the client using the key derivation key and a key derivation
to be defined by the application, for example HKDF-SHA-256. The key function (KDF)
identifier picked by the authorization server MUST be unique for to be defined by the application, for example, HKDF-SHA-256. The key
identifier picked by the authorization server <bcp14>MUST</bcp14> be unique for
each access token where a unique symmetric key is required.</t> each access token where a unique symmetric key is required.</t>
<t>In this example, HKDF consists of the composition of the HKDF-Extra ct <t>In this example, the HMAC-based key derivation function (HKDF) cons ists of the composition of the HKDF-Extract
and HKDF-Expand steps <xref target="RFC5869" format="default"/>. The symmetric k ey is derived from the and HKDF-Expand steps <xref target="RFC5869" format="default"/>. The symmetric k ey is derived from the
key identifier, the key derivation key and other data:</t> key identifier, the key derivation key, and other data:</t>
<t>OKM = HKDF(salt, IKM, info, L),</t> <t indent="3">OKM = HKDF(salt, IKM, info, L),</t>
<t>where:</t> <t>where:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>OKM, the output keying material, is the derived symmetric key</l i> <li>OKM, the output keying material, is the derived symmetric key</l i>
<li>salt is the empty byte string</li> <li>salt is the empty byte string</li>
<li>IKM, the input keying material, is the key derivation key as def <li>IKM, the input keying material, is the key derivation key, as de
ined above</li> fined
<li>info is the serialization of a CBOR array consisting of (<xref t above</li>
arget="RFC8610" format="default"/>):</li> <li><t>info is the serialization of a CBOR array consisting of <xref
</ul> target="RFC8610" format="default"/>:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="cddl"><![CDATA[
info = [ info = [
type : tstr, type : tstr,
L : uint, L : uint,
access_token: bytes access_token : bytes
] ]
]]></artwork> ]]></sourcecode>
<t>where:</t> <t>where:</t>
<ul spacing="normal"> <ul>
<li>type is set to the constant text string "ACE-CoAP-DTLS-key-deriv <li>type is set to the constant text string "ACE-CoAP-DTLS-key-deriv
ation",</li> ation"</li>
<li>L is the size of the symmetric key in bytes,</li> <li>L is the size of the symmetric key in bytes</li>
<li>access_token is the content of the <tt>access_token</tt> field a <li>access_token is the content of the <tt>access_token</tt> field,
s as
transferred from the authorization server to the resource server.</li> transferred from the authorization server to the resource server.</li
>
</ul></li>
</ul> </ul>
<t>All CBOR data types are encoded in CBOR using preferred serializati on <t>All CBOR data types are encoded in CBOR using preferred serializati on
and deterministic encoding as specified in Section 4 of <xref target="RFC8949" f and deterministic encoding, as specified in <xref target="RFC8949"
ormat="default"/>. sectionFormat="of" section="4"/>.
This implies in particular that the <tt>type</tt> and <tt>L</tt> components use In particular, this implies that the <tt>type</tt> and <tt>L</tt> compo
the nents use the
minimum length encoding. The content of the <tt>access_token</tt> field is minimum length encoding. The content of the <tt>access_token</tt> field
treated as opaque data for the purpose of key derivation.</t> is
<t>Use of a unique (per resource server) <tt>kid</tt> and the use of a treated as opaque data for the purpose of key derivation.</t>
key <t>Use of a unique (per-resource-server) <tt>kid</tt> and the use of a
derivation IKM that MUST be unique per authorization server/resource server key
pair as specified above will ensure that the derived key is not shared derivation IKM that <bcp14>MUST</bcp14> be unique
across multiple clients. However, to provide variation per AS/RS pair, as specified above, will ensure that
in the derived key across different tokens used by the same client, it the derived key is not shared across multiple clients. However, to pro
is additionally RECOMMENDED to include the "iat" claim and either the vide
"exp" or "exi" claims in the access token.</t> variation in the derived key across different tokens used by the same c
lient, it
is additionally <bcp14>RECOMMENDED</bcp14> to include the <tt>iat</tt>
claim and either the
<tt>exp</tt> or <tt>exi</tt> claims in the access token.</t>
</section> </section>
<section anchor="psk-dtls-channel" numbered="true" toc="default"> <section anchor="psk-dtls-channel" numbered="true" toc="default">
<name>DTLS Channel Setup Between Client and Resource Server</name> <name>DTLS Channel Setup between the Client and Resource Server</name>
<t>When a client receives an access token response from an authorizati on <t>When a client receives an access token response from an authorizati on
server, the client MUST check if the access token response is bound to server, the client <bcp14>MUST</bcp14> check if the access token response is bou
a certain previously sent access token request, as the request may nd to
a certain, previously sent access token request, as the request may
specify the resource server with which the client wants to specify the resource server with which the client wants to
communicate.</t> communicate.</t>
<t>The client checks if the payload of the access token response conta ins <t>The client checks if the payload of the access token response conta ins
an <tt>access_token</tt> parameter and a <tt>cnf</tt> parameter. With this an <tt>access_token</tt> parameter and a <tt>cnf</tt> parameter. With t
information the client can initiate the establishment of a new DTLS his
channel with a resource server. To use DTLS with pre-shared keys, the information, the client can initiate the establishment of a new DTLS
client follows the PSK key exchange algorithm specified in Section 2 channel with a resource server. To use DTLS with pre-shared keys, the
of <xref target="RFC4279" format="default"/> using the key conveyed in the <tt>c client follows the PSK key exchange algorithm specified in <xref target
nf</tt> parameter of the AS ="RFC4279"
response as PSK when constructing the premaster secret. To be sectionFormat="of" section="2"/>, using the key conveyed in the <tt>cnf
consistent with the recommendations in <xref target="RFC7252" format="default"/> </tt>
, a client in the PSK parameter of the AS response as a PSK when constructing the premaster s
mode MUST support the cipher suite TLS_PSK_WITH_AES_128_CCM_8 ecret. To be
<xref target="RFC6655" format="default"/>.</t> consistent with the recommendations in <xref target="RFC7252" format="d
efault"/>, a
client in the PSK mode <bcp14>MUST</bcp14> support the cipher suite
TLS_PSK_WITH_AES_128_CCM_8 <xref target="RFC6655" format="default"/>.</
t>
<t>In PreSharedKey mode, the knowledge of the shared secret by the cli ent <t>In PreSharedKey mode, the knowledge of the shared secret by the cli ent
and the resource server is used for mutual authentication between both and the resource server is used for mutual authentication between both
peers. Therefore, the resource server must be able to determine the peers. Therefore, the resource server must be able to determine the
shared secret from the access token. Following the general ACE shared secret from the access token. Following the general ACE
authorization framework, the client can upload the access token to the authorization framework, the client can upload the access token to the
resource server's authz-info resource before starting the DTLS resource server's authz-info resource before starting the DTLS
handshake. The client then needs to indicate during the DTLS handshake. The client then needs to indicate during the DTLS
handshake which previously uploaded access token it intends to use. handshake which previously uploaded access token it intends to use.
To do so, it MUST create a <tt>COSE_Key</tt> structure with the <tt>kid</tt> tha To do so, it <bcp14>MUST</bcp14> create a <tt>COSE_Key</tt> structure w
t ith the
was conveyed in the <tt>rs_cnf</tt> claim in the token response from the <tt>kid</tt> that was conveyed in the <tt>rs_cnf</tt> claim in the toke
authorization server and the key type <tt>symmetric</tt>. This structure n response
then is included as the only element in the <tt>cnf</tt> structure whose CBOR se from the authorization server and the key type <tt>symmetric</tt>. Thi
rialization is s structure
used as value for <tt>psk_identity</tt> as shown in <xref target="psk_identity-c then is included as the only element in the <tt>cnf</tt> structure whos
nf" format="default"/>.</t> e CBOR
serialization is used as value for <tt>psk_identity</tt>, as shown in <
xref
target="psk_identity-cnf" format="default"/>.</t>
<figure anchor="psk_identity-cnf"> <figure anchor="psk_identity-cnf">
<name>Access token containing a single kid parameter</name> <name>Access Token Containing a Single <tt>kid</tt> Parameter</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
{ cnf : { { / cnf / 8 : {
COSE_Key : { / COSE_Key / 1 : {
kty: symmetric, / kty / 1 : / symmetric / 4,
kid : h'3d027833fc6267ce' / kid / 2 : h'3d027833fc6267ce'
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The actual CBOR serialization for the data structure from <t>The actual CBOR serialization for the data structure from
<xref target="psk_identity-cnf" format="default"/> as sequence of bytes in hexad <xref target="psk_identity-cnf" format="default"/> as a sequence of byt
ecimal notation will es in
be:</t> 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 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 provid e <t>As an alternative to the access token upload, the client can provid e
the most recent access token in the <tt>psk_identity</tt> field of the the most recent access token in the <tt>psk_identity</tt> field of the
ClientKeyExchange message. To do so, the client MUST treat the ClientKeyExchange message. To do so, the client <bcp14>MUST</bcp14> treat the
contents of the <tt>access_token</tt> field from the AS-to-Client response as contents of the <tt>access_token</tt> field from the AS-to-client response as
opaque data as specified in Section 4.2 of <xref target="RFC7925" format="defaul opaque data, as specified in <xref target="RFC7925" sectionFormat="of" section="
t"/> and not perform 4.2"/>, and not perform
any re-coding. This allows the resource server to retrieve the shared any recoding. This allows the resource server to retrieve the shared
secret directly from the <tt>cnf</tt> claim of the access token.</t> secret directly from the <tt>cnf</tt> claim of the access token.</t>
<t>DTLS 1.3 <xref target="RFC9147"/> does not use the ClientKeyExchange message;
for DTLS 1.3,
the access token is placed in the <tt>identity</tt> field of a <tt>PSKIdentit
y</tt>
within the <tt>PreSharedKeyExtension</tt> of the <tt>ClientHello</tt>.</t>
<t>If a resource server receives a ClientKeyExchange message that <t>If a resource server receives a ClientKeyExchange message that
contains a <tt>psk_identity</tt> with a length greater than zero, it MUST contains a <tt>psk_identity</tt> with a length greater than zero, it <bcp14>MUST
parse the contents of the <tt>psk_identity</tt> field as CBOR data structure </bcp14>
parse the contents of the <tt>psk_identity</tt> field as a CBOR data structure
and process the contents as following:</t> and process the contents as following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the data contains a <tt>cnf</tt> field with a <tt>COSE_Key</t t> structure with <li>If the data contains a <tt>cnf</tt> field with a <tt>COSE_Key</t t> structure with
a <tt>kid</tt>, the resource server continues the DTLS handshake with the a <tt>kid</tt>, the resource server continues the DTLS handshake with the
associated key that corresponds to this kid.</li> associated key that corresponds to this kid.</li>
<li>If the data comprises additional CWT information, this informati on <li>If the data comprises additional CWT information, this informati on
must be stored as an access token for this DTLS association before must be stored as an access token for this DTLS association before
continuing with the DTLS handshake.</li> continuing with the DTLS handshake.</li>
</ul> </ul>
<t>If the contents of the <tt>psk_identity</tt> do not yield sufficien t <t>If the contents of the <tt>psk_identity</tt> do not yield sufficien t
information to select a valid access token for the requesting client, information to select a valid access token for the requesting client,
the resource server aborts the DTLS handshake with an the resource server aborts the DTLS handshake with an
<tt>illegal_parameter</tt> alert.</t> <tt>illegal_parameter</tt> alert.</t>
<t>When the resource server receives an access token, it MUST check if <t>When the resource server receives an access token, it <bcp14>MUST</ bcp14> check if
the access token is still valid, if the resource server is the the access token is still valid, if the resource server is the
intended destination (i.e., the audience of the token), and if the intended destination (i.e., the audience of the token), and if the
token was issued by an authorized authorization server. This token was issued by an authorized authorization server. This
specification implements access tokens as proof-of-possession tokens. specification implements access tokens as proof-of-possession tokens.
Therefore, the access token is bound to a symmetric PoP key Therefore, the access token is bound to a symmetric PoP key
that is used as shared secret between the client and the resource that is used as a shared secret between the client and the resource
server. A resource server MUST have the capacity to store one server. A resource server <bcp14>MUST</bcp14> have the capacity to store one
access token for every proof-of-possession key of every authorized client. access token for every proof-of-possession key of every authorized client.
The resource server may use token introspection <xref target="RFC7662" format="d efault"/> on The resource server may use token introspection <xref target="RFC7662" format="d efault"/> on
the access token to retrieve more information about the specific the access token to retrieve more information about the specific
token. The use of introspection is out of scope for this token. The use of introspection is out of scope for this
specification.</t> specification.</t>
<t>While the client can retrieve the shared secret from the contents o f <t>While the client can retrieve the shared secret from the contents o f
the <tt>cnf</tt> parameter in the AS-to-Client response, the resource server the <tt>cnf</tt> parameter in the AS-to-client response, the resource server
uses the information contained in the <tt>cnf</tt> claim of the access token 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 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> cla im the <tt>psk_identity</tt> field. If key derivation is used, the <tt>cnf</tt> cla im
MUST contain a <tt>kid</tt> parameter to be used by the server as the IKM for <bcp14>MUST</bcp14> contain a <tt>kid</tt> parameter to be used by the server as
key derivation as described above.</t> the IKM for
key derivation, as described above.</t>
</section> </section>
</section> </section>
<section anchor="resource-access" numbered="true" toc="default"> <section anchor="resource-access" numbered="true" toc="default">
<name>Resource Access</name> <name>Resource Access</name>
<t>Once a DTLS channel has been established as described in <xref target <t>Once a DTLS channel has been established as described in either Secti
="rpk-mode" format="default"/> ons <xref target="rpk-mode" format="counter"/>
or <xref target="psk-mode" format="default"/>, respectively, the client is autho or <xref target="psk-mode" format="counter"/>, respectively, the client is autho
rized to access rized to access
resources covered by the access token it has uploaded to the resources covered by the access token it has uploaded to the
authz-info resource hosted by the resource server.</t> authz-info resource that is hosted by the resource server.</t>
<t>With the successful establishment of the DTLS channel, the client and <t>With the successful establishment of the DTLS channel, the client and
the resource server have proven that they can use their respective the resource server have proven that they can use their respective
keying material. An access token that is bound to the client's keying 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 material is associated with the channel. According to
<xref target="I-D.ietf-ace-oauth-authz" format="default"/>, there should be only <xref target="RFC9200" sectionFormat="of" section="5.10.1"/>, there should be on
one access token ly one access token
for each client. New access tokens issued by the authorization server for each client. New access tokens issued by the authorization server
SHOULD replace previously issued access tokens for the <bcp14>SHOULD</bcp14> replace previously issued access tokens for the
respective client. The resource server therefore needs a common respective client. The resource server therefore needs a common
understanding with the authorization server how access tokens are understanding with the authorization server about how access tokens are
ordered. The authorization server may, e.g., specify a <tt>cti</tt> claim for 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" f ormat="default"/>) to the access token (see <xref target="RFC9200" sectionFormat="of" section="5.9.2"/ >) to
employ a strict order.</t> employ a strict order.</t>
<t>Any request that the resource server receives on a DTLS channel that <t>Any request that the resource server receives on a DTLS channel that
is tied to an access token via its keying material is tied to an access token via its keying material
MUST be checked against the authorization rules that can be determined <bcp14>MUST</bcp14> be checked against the authorization rules that can be deter mined
with the access token. The resource server with the access token. The resource server
MUST check for every request if the access token is still valid. <bcp14>MUST</bcp14> check for every request if the access token is still valid.
If the token has expired, the resource server MUST remove it. If the token has expired, the resource server <bcp14>MUST</bcp14> remove it.
Incoming CoAP requests that are not authorized with respect Incoming CoAP requests that are not authorized with respect
to any access token that is associated with the client MUST be to any access token that is associated with the client <bcp14>MUST</bcp14> be
rejected by the resource server with 4.01 response. The response rejected by the resource server with a 4.01 response. The response
SHOULD include AS Request Creation Hints as described in <bcp14>SHOULD</bcp14> include AS Request Creation Hints, as described in
Section 5.2 of <xref target="I-D.ietf-ace-oauth-authz" format="default"/>.</t> <xref target="RFC9200" sectionFormat="of" section="5.2"/>.</t>
<t>The resource server MUST NOT accept an incoming CoAP request as <t>The resource server <bcp14>MUST NOT</bcp14> accept an incoming CoAP r
equest as
authorized if any of the following fails:</t> authorized if any of the following fails:</t>
<ol spacing="normal" type="1"><li>The message was received on a secure c <ol spacing="normal" type="1">
hannel that has been <li>The message was received on a secure channel that has been
established using the procedure defined in this document.</li> established using the procedure defined in this document.</li>
<li>The authorization information tied to the sending client is valid. </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 request is destined for the resource server.</li>
<li>The resource URI specified in the request is covered by the <li>The resource URI specified in the request is covered by the
authorization information.</li> authorization information.</li>
<li>The request method is an authorized action on the resource with <li>The request method is an authorized action on the resource with
respect to the authorization information.</li> respect to the authorization information.</li>
</ol> </ol>
<t>Incoming CoAP requests received on a secure DTLS channel that are not <t>Incoming CoAP requests received on a secure DTLS channel that are not
thus authorized MUST be thus authorized <bcp14>MUST</bcp14> be
rejected according to Section 5.10.1.1 of <xref target="I-D.ietf-ace-oauth-authz rejected according to <xref target="RFC9200"
" format="default"/></t> sectionFormat="of" section="5.10.2"/>:</t>
<ol spacing="normal" type="1"><li>with response code 4.03 (Forbidden) wh <ol spacing="normal" type="1">
en the resource URI specified <li>with response code 4.03 (Forbidden) when the resource URI specified
in the request is not covered by the authorization information, and</li> in the request is not covered by the authorization information and</li>
<li>with response code 4.05 (Method Not Allowed) when the resource URI <li>with response code 4.05 (Method Not Allowed) when the resource URI
specified in the request covered by the authorization information but specified in the request is covered by the authorization information bu
not the requested action.</li> t
not the requested action.</li>
</ol> </ol>
<t>The client MUST ascertain that its keying material is still valid <t>The client <bcp14>MUST</bcp14> ascertain that its keying material is still valid
before sending a request or processing a response. If the client 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 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 prepared that its request is still handled according to the previous
authorization rules as there is no strict ordering between access authorization rules, as there is no strict ordering between access
token uploads and resource access messages. See also token uploads and resource access messages. See also
<xref target="multiple-access-tokens" format="default"/> for a discussion of acc ess token <xref target="multiple-access-tokens" format="default"/> for a discussion of acc ess token
processing.</t> processing.</t>
<t>If the client gets an error response <t>If the client gets an error response
containing AS Request Creation Hints (cf. Section 5.3 of <xref target="I-D.ietf containing AS Request Creation Hints (cf.&nbsp;<xref target="RFC9200" sectionFor
-ace-oauth-authz" format="default"/> mat="of" section="5.3"/>)
as response to its requests, it SHOULD request a new access token from as a response to its requests, it <bcp14>SHOULD</bcp14> request a new access tok
en from
the authorization server in order to continue communication with the the authorization server in order to continue communication with the
resource server.</t> resource server.</t>
<t>Unauthorized requests that have been received over a DTLS session <t>Unauthorized requests that have been received over a DTLS session
SHOULD be treated as non-fatal by the resource server, i.e., the DTLS <bcp14>SHOULD</bcp14> be treated as nonfatal by the resource server, i.e., the D
session SHOULD be kept alive until the associated access token has TLS
session <bcp14>SHOULD</bcp14> be kept alive until the associated access token ha
s
expired.</t> expired.</t>
</section> </section>
</section> </section>
<section anchor="update" numbered="true" toc="default"> <section anchor="update" numbered="true" toc="default">
<name>Dynamic Update of Authorization Information</name> <name>Dynamic Update of Authorization Information</name>
<t>Resource servers must only use a new access token to update the <t>Resource servers must only use a new access token to update the
authorization information for a DTLS session if the keying material 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 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 handshake. By associating the access tokens with the identifier of an
existing DTLS session, the authorization information can be updated existing DTLS session, the authorization information can be updated
without changing the cryptographic keys for the DTLS communication without changing the cryptographic keys for the DTLS communication
between the client and the resource server, i.e. an existing session between the client and the resource server, i.e., an existing session
can be used with updated permissions.</t> can be used with updated permissions.</t>
<t>The client can therefore update the authorization information stored at the <t>The client can therefore update the authorization information stored at the
resource server at any time without changing an established DTLS resource server at any time without changing an established DTLS
session. To do so, the client requests a session. To do so, the client requests a
new access token from the authorization server new access token from the authorization server
for the intended action on the respective resource for the intended action on the respective resource
and uploads this access token to the authz-info resource on the and uploads this access token to the authz-info resource on the
resource server.</t> resource server.</t>
<t><xref target="update-overview" format="default"/> depicts the message f low where the client requests <t><xref target="update-overview" format="default"/> depicts the message f low where the client requests
a new access token after a security association between the client and a new access token after a security association between the client and
the resource server has been established using this protocol. If the the resource server has been established using this protocol. If the
client wants to update the authorization information, the token client wants to update the authorization information, the token
request MUST specify the key identifier of the proof-of-possession key request <bcp14>MUST</bcp14> specify the key identifier of the proof-of-possessio n key
used for the existing DTLS channel between the client and the resource used for the existing DTLS channel between the client and the resource
server in the <tt>kid</tt> parameter of the Client-to-AS request. The server in the <tt>kid</tt> parameter of the client-to-AS request. The
authorization server MUST verify that the specified <tt>kid</tt> denotes a authorization server <bcp14>MUST</bcp14> verify that the specified <tt>kid</tt>
denotes a
valid verifier for a proof-of-possession token that has previously valid verifier for a proof-of-possession token that has previously
been issued to the requesting client. Otherwise, the Client-to-AS been issued to the requesting client. Otherwise, the client-to-AS
request MUST be declined with the error code <tt>unsupported_pop_key</tt> as request <bcp14>MUST</bcp14> be declined with the error code <tt>unsupported_pop_
defined in Section 5.8.3 of <xref target="I-D.ietf-ace-oauth-authz" format="defa key</tt>, as
ult"/>.</t> defined in <xref target="RFC9200" sectionFormat="of" section="5.8.3"/>.</t>
<t>When the authorization server issues a new access token to update <t>When the authorization server issues a new access token to update
existing authorization information, it MUST include the specified <tt>kid</tt> existing authorization information, it <bcp14>MUST</bcp14> include the specified
parameter in this access token. A resource server MUST replace the <tt>kid</tt>
parameter in this access token. A resource server <bcp14>MUST</bcp14> replace th
e
authorization information of any existing DTLS session that is identified authorization information of any existing DTLS session that is identified
by this key identifier with the updated authorization information.</t> by this key identifier with the updated authorization information.</t>
<figure anchor="update-overview"> <figure anchor="update-overview">
<name>Overview of Dynamic Update Operation</name> <name>Overview of Dynamic Update Operation</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
C RS AS C RS AS
| <===== DTLS channel =====> | | | <===== DTLS channel =====> | |
| + Access Token | | | + Access Token | |
| | | | | |
| --- Token Request ----------------------------> | | --- Token Request ----------------------------> |
skipping to change at line 827 skipping to change at line 854
| | | | | |
| <---------------------------- New Access Token - | | <---------------------------- New Access Token - |
| + Access Information | | + Access Information |
| | | | | |
| --- Update /authz-info --> | | | --- Update /authz-info --> | |
| New Access Token | | | New Access Token | |
| | | | | |
| == Authorized Request ===> | | | == Authorized Request ===> | |
| | | | | |
| <=== Protected Resource == | | | <=== Protected Resource == | |
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="teardown" numbered="true" toc="default"> <section anchor="teardown" numbered="true" toc="default">
<name>Token Expiration</name> <name>Token Expiration</name>
<t>The resource server MUST delete access tokens that are no longer <t>The resource server <bcp14>MUST</bcp14> delete access tokens that are n
valid. DTLS associations that have been setup in accordance with o longer
this profile are always tied to specific tokens (which may be valid. DTLS associations that have been set up in accordance with
exchanged with a dynamic update as described in Section 4). As tokens this profile are always tied to specific tokens (which may be
may become invalid at any time (e.g., because they have expired), the exchanged with a dynamic update, as described in <xref target="update"
association may become useless at some point. A resource server therefore format="default"/>). As tokens
MUST terminate existing DTLS association after the last access token may become invalid at any time (e.g., because they have expired), the
associated with this association has expired.</t> association may become useless at some point. A resource server therefore
<t>As specified in Section 5.10.3 of <xref target="I-D.ietf-ace-oauth-auth <bcp14>MUST</bcp14> terminate existing DTLS association after the last acc
z" format="default"/>, ess token
the resource server MUST notify the client with an error response with associated with this association has expired.</t>
code 4.01 (Unauthorized) for any long running request before <t>As specified in <xref target="RFC9200" sectionFormat="of" section="5.10
.3"/>,
the resource server <bcp14>MUST</bcp14> notify the client with an error response
with
code 4.01 (Unauthorized) for any long-running request before
terminating the association.</t> terminating the association.</t>
</section> </section>
<section anchor="as-commsec" numbered="true" toc="default"> <section anchor="as-commsec" numbered="true" toc="default">
<name>Secure Communication with an Authorization Server</name> <name>Secure Communication with an Authorization Server</name>
<t>As specified in the ACE framework (Sections 5.8 and 5.9 of <t>As specified in the ACE framework (Sections <xref target="RFC9200" sect
<xref target="I-D.ietf-ace-oauth-authz" format="default"/>), the requesting enti ion="5.8" sectionFormat="bare"/> and <xref target="RFC9200" section="5.9" sectio
ty (the resource nFormat="bare"/> of
<xref target="RFC9200" format="default"/>), the requesting entity (the resource
server and/or the client) and the authorization server communicate via server and/or the client) and the authorization server communicate via
the token endpoint or introspection endpoint. The use of CoAP and the token endpoint or introspection endpoint. The use of CoAP and
DTLS for this communication is RECOMMENDED in this profile. Other DTLS for this communication is <bcp14>RECOMMENDED</bcp14> in this profile. Other
protocols fulfilling the security requirements defined in Section 5 protocols fulfilling the security requirements defined in <xref target="RFC9200"
of <xref target="I-D.ietf-ace-oauth-authz" format="default"/> MAY be used instea sectionFormat="of" section="5"/> <bcp14>MAY</bcp14> be used instead.</t>
d.</t>
<t>How credentials (e.g., PSK, RPK, X.509 cert) for using DTLS with the <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> authorization server are established is out of scope for this profile.</t>
<t>If other means of securing the communication with the authorization <t>If other means of securing the communication with the authorization
server are used, the communication security requirements from Section server are used, the communication security requirements from <xref target="RFC9
6.2 of <xref target="I-D.ietf-ace-oauth-authz" format="default"/> remain applica 200" sectionFormat="of" section="6.2"/> remain applicable.</t>
ble.</t>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default"> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document specifies a profile for the Authentication and <t>This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework Authorization for Constrained Environments (ACE) framework
<xref target="I-D.ietf-ace-oauth-authz" format="default"/>. As it follows this f <xref target="RFC9200" format="default"/>. As it follows this framework's genera
ramework's general l
approach, the general security considerations from Section approach, the general security considerations from <xref target="RFC9200" sectio
6 of <xref target="I-D.ietf-ace-oauth-authz" format="default"/> also apply to th nFormat="of" section="6"/> also apply to this profile.</t>
is profile.</t>
<t>The authorization server must ascertain that the keying material for <t>The authorization server must ascertain that the keying material for
the client that it provides to the resource server actually is the client that it provides to the resource server actually is
associated with this client. Malicious clients may hand over access associated with this client. Malicious clients may hand over access
tokens containing their own access permissions to other entities. This tokens containing their own access permissions to other entities. This
problem cannot be completely eliminated. Nevertheless, in RPK mode it problem cannot be completely eliminated. Nevertheless, in RPK mode, it
should not be possible for clients to request access tokens for should not be possible for clients to request access tokens for
arbitrary public keys: if the client can cause the authorization arbitrary public keys; if the client can cause the authorization
server to issue a token for a public key without proving possession of server to issue a token for a public key without proving possession of
the corresponding private key, this allows for identity misbinding the corresponding private key, this allows for identity misbinding
attacks where the issued token is usable by an entity other than the attacks, where the issued token is usable by an entity other than the
intended one. The authorization server therefore at some point needs intended one. At some point, the authorization server therefore needs
to validate that the client can actually use the private key to validate that the client can actually use the private key
corresponding to the client's public key.</t> corresponding to the client's public key.</t>
<t>When using pre-shared keys provisioned by the authorization server, <t>When using pre-shared keys provisioned by the authorization server,
the security level depends on the randomness of PSK, and the security the security level depends on the randomness of PSKs and the security
of the TLS cipher suite and key exchange algorithm. As this of the TLS cipher suite and key exchange algorithm. As this
specification targets at constrained environments, message payloads specification targets constrained environments, message payloads
exchanged between the client and the resource server are expected to 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 be small and rare. CoAP <xref target="RFC7252" format="default"/> mandates the implementation of
cipher suites with abbreviated, 8-byte tags for message integrity cipher suites with abbreviated, 8-byte tags for message integrity
protection. For consistency, this profile requires implementation of protection. For consistency, this profile requires implementation of
the same cipher suites. For application scenarios where the cost of the same cipher suites. For application scenarios where the cost of
full-width authentication tags is low compared to the overall amount full-width authentication tags is low compared to the overall amount
of data being transmitted, the use of cipher suites with 16-byte of data being transmitted, the use of cipher suites with 16-byte
integrity protection tags is preferred.</t> integrity protection tags is preferred.</t>
<t>The PSK mode of this profile offers a distribution mechanism to convey <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 authorization tokens together with a shared secret to a client and a
server. As this specification aims at constrained devices and uses server. As this specification aims at constrained devices and uses
CoAP <xref target="RFC7252" format="default"/> as transfer protocol, at least th CoAP <xref target="RFC7252" format="default"/> as the transfer protocol, a
e cipher suite t least the
TLS_PSK_WITH_AES_128_CCM_8 <xref target="RFC6655" format="default"/> should be s cipher suite TLS_PSK_WITH_AES_128_CCM_8 <xref target="RFC6655" format="def
upported. The ault"/>
access tokens and the corresponding shared secrets generated by the should be supported. The
authorization server are expected to be sufficiently short-lived to access tokens and the corresponding shared secrets generated by the
provide similar forward-secrecy properties to using ephemeral authorization server are expected to be sufficiently short-lived to
Diffie-Hellman (DHE) key exchange mechanisms. For longer-lived access provide similar forward-secrecy properties to using ephemeral
tokens, DHE cipher suites should be used, i.e., cipher suites of the Diffie-Hellman (DHE) key exchange mechanisms. For longer-lived access
form TLS_DHE_PSK_*.</t> tokens, DHE cipher suites should be used, i.e., cipher suites of the
<t>Constrained devices that use DTLS <xref target="RFC6347" format="defaul form TLS_DHE_PSK_* or TLS_ECDHE_PSK_*.</t>
t"/> are inherently <t>Constrained devices that use DTLS <xref target="RFC6347" format="defaul
vulnerable to Denial of Service (DoS) attacks as the handshake t"/> <xref target="RFC9147"/> are inherently
vulnerable to Denial of Service (DoS) attacks, as the handshake
protocol requires creation of internal state within the device. This protocol requires creation of internal state within the device. This
is specifically of concern where an adversary is able to intercept the is specifically of concern where an adversary is able to intercept the
initial cookie exchange and interject forged messages with a valid initial cookie exchange and interject forged messages with a valid
cookie to continue with the handshake. A similar issue exists with the cookie to continue with the handshake. A similar issue exists with the
unprotected authorization information endpoint when the resource unprotected authorization information endpoint when the resource
server needs to keep valid access tokens for a long time. Adversaries server needs to keep valid access tokens for a long time. Adversaries
could fill up the constrained resource server's internal storage for a could fill up the constrained resource server's internal storage for a
very long time with interjected or otherwise retrieved valid access very long time with intercepted or otherwise retrieved valid access
tokens. To mitigate against this, the resource server should set a tokens. To mitigate against this, the resource server should set a
time boundary until an access token that has not been used until then time boundary until an access token that has not been used until then
will be deleted.</t> will be deleted.</t>
<t>The protection of access tokens that are stored in the authorization <t>The protection of access tokens that are stored in the authorization
information endpoint depends on the keying material that is used between information endpoint depends on the keying material that is used between
the authorization server and the resource server: The resource server the authorization server and the resource server; the resource server
must ensure that it processes only access tokens that are (encrypted must ensure that it processes only access tokens that are integrity protected (a
and) integrity-protected by an authorization server that is authorized nd encrypted) by an authorization server that is authorized
to provide access tokens for the resource server.</t> to provide access tokens for the resource server.</t>
<section anchor="reuse-of-existing-sessions" numbered="true" toc="default" > <section anchor="reuse-of-existing-sessions" numbered="true" toc="default" >
<name>Reuse of Existing Sessions</name> <name>Reuse of Existing Sessions</name>
<t>To avoid the overhead of a repeated DTLS handshake, <xref target="RFC <t>To avoid the overhead of a repeated DTLS handshake, <xref target="RFC
7925" format="default"/> 7925" format="default"/> recommends
recommends session resumption <xref target="RFC8446" format="default"/> to reuse session resumption <xref target="RFC8446" format="default"/> to reuse session st
session state from ate from
an earlier DTLS association and thus requires client side an earlier DTLS association and thus requires client-side
implementation. In this specification, the DTLS session is subject to implementation. In this specification, the DTLS session is subject to
the authorization rules denoted by the access token that was used for the authorization rules denoted by the access token that was used for
the initial setup of the DTLS association. Enabling session resumption the initial setup of the DTLS association. Enabling session resumption
would require the server to transfer the authorization information would require the server to transfer the authorization information
with the session state in an encrypted SessionTicket to the with the session state in an encrypted SessionTicket to the
client. Assuming that the server uses long-lived keying material, this client. Assuming that the server uses long-lived keying material, this
could open up attacks due to the lack of forward secrecy. Moreover, could open up attacks due to the lack of forward secrecy. Moreover,
using this mechanism, a client can resume a DTLS session without using this mechanism, a client can resume a DTLS session without
proving the possession of the PoP key again. Therefore, session proving the possession of the PoP key again. Therefore, session
resumption should be used only in combination with reasonably resumption should be used only in combination with reasonably
short-lived PoP keys.</t> short-lived PoP keys.</t>
<t>Since renegotiation of DTLS associations is prone to attacks as well, <t>Since renegotiation of DTLS associations is prone to attacks as well,
<xref target="RFC7925" format="default"/> requires clients to decline any renego <xref target="RFC7925" format="default"/> requires that clients decline any
tiation attempt. A renegotiation attempt. A server that wants to initiate rekeying therefore
server that wants to initiate re-keying therefore SHOULD periodically <bcp14>SHOULD</bcp14> periodically force a full handshake.</t>
force a full handshake.</t>
</section> </section>
<section anchor="multiple-access-tokens" numbered="true" toc="default"> <section anchor="multiple-access-tokens" numbered="true" toc="default">
<name>Multiple Access Tokens</name> <name>Multiple Access Tokens</name>
<t>Developers SHOULD avoid using multiple access tokens for a <t>Implementers <bcp14>SHOULD</bcp14> avoid using multiple access tokens
client (see also section 5.10.1 of <xref target="I-D.ietf-ace-oauth-authz" forma for a
t="default"/>).</t> client (see also <xref target="RFC9200" sectionFormat="of" section="5.10.1"/>).<
/t>
<t>Even when a single access token per client is used, an attacker could <t>Even when a single access token per client is used, an attacker could
compromise the dynamic update mechanism for existing DTLS connections compromise the dynamic update mechanism for existing DTLS connections
by delaying or reordering packets destined for the authz-info by delaying or reordering packets destined for the authz-info
endpoint. Thus, the order in which operations occur at the resource endpoint. Thus, the order in which operations occur at the resource
server (and thus which authorization info is used to process a given server (and thus which authorization info is used to process a given
client request) cannot be guaranteed. Especially in the presence of client request) cannot be guaranteed. Especially in the presence of
later-issued access tokens that reduce the client's permissions from later-issued access tokens that reduce the client's permissions from
the initial access token, it is impossible to guarantee that the the initial access token, it is impossible to guarantee that the
reduction in authorization will take effect prior to the expiration of reduction in authorization will take effect prior to the expiration of
the original token.</t> the original token.</t>
</section> </section>
<section anchor="out-of-band-configuration" numbered="true" toc="default"> <section anchor="out-of-band-configuration" numbered="true" toc="default">
<name>Out-of-Band Configuration</name> <name>Out-of-Band Configuration</name>
<t>To communicate securely, the authorization server, the client and the <t>To communicate securely, the authorization server, the client, and th e
resource server require certain information that must be exchanged resource server require certain information that must be exchanged
outside the protocol flow described in this document. The outside the protocol flow described in this document. The
authorization server must have obtained authorization information authorization server must have obtained authorization information
concerning the client and the resource server that is approved by the concerning the client and the resource server that is approved by the
resource owner as well as corresponding keying material. The resource resource owner, as well as corresponding keying material. The resource
server must have received authorization information approved by the server must have received authorization information approved by the
resource owner concerning its authorization managers and the resource owner concerning its authorization managers and the
respective keying material. The client must have obtained respective keying material. The client must have obtained
authorization information concerning the authorization server approved authorization information concerning the authorization server approved
by its owner as well as the corresponding keying material. Also, the by its owner, as well as the corresponding keying material. Also, the
client's owner must have approved of the client's communication with client's owner must have approved of the client's communication with
the resource server. The client and the authorization server must have the resource server. The client and the authorization server must have
obtained a common understanding how this resource server is identified obtained a common understanding about how this resource server is identified
to ensure that the client obtains access token and keying material for to ensure that the client obtains access tokens and keying material for
the correct resource server. If the client is provided with a raw the correct resource server. If the client is provided with a raw
public key for the resource server, it must be ascertained to which public key for the resource server, it must be ascertained to which
resource server (which identifier and authorization information) the resource server (which identifier and authorization information) the
key is associated. All authorization information and keying material key is associated. All authorization information and keying material
must be kept up to date.</t> must be kept up to date.</t>
</section> </section>
</section> </section>
<section anchor="privacy-considerations" numbered="true" toc="default"> <section anchor="privacy-considerations" numbered="true" toc="default">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>This privacy considerations from Section <t>This privacy considerations from <xref target="RFC9200" sectionFormat="
7 of the <xref target="I-D.ietf-ace-oauth-authz" format="default"/> apply also t of" section="7"/> apply also to this profile.</t>
o this profile.</t>
<t>An unprotected response to an unauthorized request may disclose <t>An unprotected response to an unauthorized request may disclose
information about the resource server and/or its existing relationship information about the resource server and/or its existing relationship
with the client. It is advisable to include as little information as with the client. It is advisable to include as little information as
possible in an unencrypted response. When a DTLS session between an authenticate d possible in an unencrypted response. When a DTLS session between an authenticate d
client and the resource server already exists, more detailed client and the resource server already exists, more detailed
information MAY be included with an error response to provide the information <bcp14>MAY</bcp14> be included with an error response to provide the
client with sufficient information to react on that particular error.</t> client with sufficient information to react on that particular error.</t>
<t>Also, unprotected requests to the resource server may reveal <t>Also, unprotected requests to the resource server may reveal
information about the client, e.g., which resources the client information about the client, e.g., which resources the client
attempts to request or the data that the client wants to provide to attempts to request or the data that the client wants to provide to
the resource server. The client SHOULD NOT send confidential data in the resource server. The client <bcp14>SHOULD NOT</bcp14> send confidential data in
an unprotected request.</t> an unprotected request.</t>
<t>Note that some information might still leak after DTLS session is <t>Note that some information might still leak after the DTLS session is
established, due to observable message sizes, the source, and the established, due to observable message sizes, the source, and the
destination addresses.</t> destination addresses.</t>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>The following registrations are done for the ACE OAuth Profile <t>The following registration has been made in the "ACE Profiles"
Registry following the procedure specified in registry, following the procedure specified in
<xref target="I-D.ietf-ace-oauth-authz" format="default"/>.</t> <xref target="RFC9200" format="default"/>.</t>
<t>Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with <dl newline="false" spacing="compact">
the RFC number of this specification and delete this paragraph.</t> <dt>Name:</dt>
<t>Profile name: coap_dtls</t> <dd>coap_dtls</dd>
<t>Profile Description: Profile for delegating client authentication and <dt>Description:</dt>
authorization in a constrained environment by establishing a Datagram <dd>Profile for delegating client Authentication and
Transport Layer Security (DTLS) channel between resource-constrained Authorization for Constrained Environments by establishing a Datagram
nodes.</t> Transport Layer Security (DTLS) channel between resource-constrained
<t>Profile ID: TBD (suggested: 1)</t> nodes.</dd>
<t>Change Controller: IESG</t> <dt>CBOR Value:</dt>
<t>Reference: [RFC-XXXX]</t> <dd>1</dd>
</section> <dt>Reference:</dt>
<section anchor="acknowledgments" numbered="true" toc="default"> <dd>RFC 9202</dd>
<name>Acknowledgments</name> </dl>
<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>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t 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/rfc4
279">
<front>
<title>Pre-Shared Key Ciphersuites for Transport Layer Security (TLS
)</title>
<author fullname="P. Eronen" initials="P." role="editor" surname="Er
onen">
<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-s
hared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance
among the communicating parties. The first set of ciphersuites uses only symmet
ric key operations for authentication. The second set uses a Diffie-Hellman exch
ange 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/rfc6
347">
<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 L
ayer Security (DTLS) protocol. The DTLS protocol provides communications privac
y for datagram protocols. The protocol allows client/server applications to com
municate in a way that is designed to prevent eavesdropping, tampering, or messa
ge forgery. The DTLS protocol is based on the Transport Layer Security (TLS) pr
otocol and provides equivalent security guarantees. Datagram semantics of the u
nderlying transport are preserved by the DTLS protocol. This document updates D
TLS 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/rfc6
749">
<front>
<title>The OAuth 2.0 Authorization Framework</title>
<author fullname="D. Hardt" initials="D." role="editor" surname="Har
dt">
<organization/>
</author>
<date month="October" year="2012"/>
<abstract>
<t>The OAuth 2.0 authorization framework enables a third-party app
lication to obtain limited access to an HTTP service, either on behalf of a reso
urce owner by orchestrating an approval interaction between the resource owner a
nd 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 pro
tocol 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/rfc7
250">
<front>
<title>Using Raw Public Keys in Transport Layer Security (TLS) and D
atagram Transport Layer Security (DTLS)</title>
<author fullname="P. Wouters" initials="P." role="editor" surname="W
outers">
<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 exte
nsions for exchanging raw public keys in Transport Layer Security (TLS) and Data
gram Transport Layer Security (DTLS). The new certificate type allows raw publi
c 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/rfc7
251">
<front>
<title>AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for T
LS</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 secu
rity. The cipher suites defined in this document use Elliptic Curve Cryptograph
y (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/rfc7
252">
<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 we
b transfer protocol for use with constrained nodes and constrained (e.g., low-po
wer, lossy) networks. The nodes often have 8-bit microcontrollers with small am
ounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wir
eless 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 appl
ication endpoints, supports built-in discovery of services and resources, and in
cludes key concepts of the Web such as URIs and Internet media types. CoAP is d
esigned to easily interface with HTTP for integration with the Web while meeting
specialized requirements such as multicast support, very low overhead, and simp
licity 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/rfc7
925">
<front>
<title>Transport Layer Security (TLS) / Datagram Transport Layer Sec
urity (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 a
ctuators for use in home automation, industrial control systems, smart cities, a
nd other IoT deployments.</t>
<t>This document defines a Transport Layer Security (TLS) and Data
gram Transport Layer Security (DTLS) 1.2 profile that offers communications secu
rity for this data exchange thereby preventing eavesdropping, tampering, and mes
sage forgery. The lack of communication security is a common vulnerability in I
oT 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/rfc8
152">
<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 de
signed for small code size and small message size. There is a need for the abil
ity to have basic security services defined for this data format. This document
defines the CBOR Object Signing and Encryption (COSE) protocol. This specificat
ion 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/rfc8
392">
<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 C
oncise Binary Object Representation (CBOR), and CBOR Object Signing and Encrypti
on (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/valu
e pair consisting of a claim name and a claim value. CWT is derived from JSON W
eb 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/rfc8
422">
<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="Pegour
ie-Gonnard">
<organization/>
</author>
<date month="August" year="2018"/>
<abstract>
<t>This document describes key exchange algorithms based on Ellipt
ic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In
particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (EC
DHE) 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/rfc8
747">
<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 a
lso sometimes described as being the holder-of-key. This specification provides
equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Toke
ns (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/rfc8
949">
<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 forma
t whose design goals include the possibility of extremely small code size, fairl
y small message size, and extensibility without the need for version negotiation
. These design goals make it different from earlier binary serializations such a
s ASN.1 and MessagePack.</t>
<t>This document obsoletes RFC 7049, providing editorial improveme
nts, new details, and errata fixes while keeping full compatibility with the int
erchange format of RFC 7049. It does not create a new version of the format.</t
>
</abstract>
</front>
<seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8949"/>
<seriesInfo name="DOI" value="10.17487/RFC8949"/>
</reference>
<reference anchor="I-D.ietf-ace-oauth-authz" target="https://www.ietf.or
g/archive/id/draft-ietf-ace-oauth-authz-41.txt">
<front>
<title>Authentication and Authorization for Constrained Environments
(ACE) 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>
</author>
<date day="6" month="May" year="2021"/>
<abstract>
<t> This specification defines a framework for authentication an
d
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> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
</abstract> xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
<seriesInfo name="Internet-Draft" value="draft-ietf-ace-oauth-authz-41 xml"/>
"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4279.
</reference> xml"/>
<reference anchor="I-D.ietf-ace-oauth-params" target="https://www.ietf.o <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.
rg/archive/id/draft-ietf-ace-oauth-params-15.txt"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6749.
<title>Additional OAuth Parameters for Authorization in Constrained xml"/>
Environments (ACE)</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7250.
<author fullname="Ludwig Seitz"> xml"/>
<organization>Combitech</organization> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7251.
</author> xml"/>
<date day="6" month="May" year="2021"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.
<abstract> xml"/>
<t> This specification defines new parameters and encodings for <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7925.
the OAuth xml"/>
2.0 token and introspection endpoints when used with the framework <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8152.
for authentication and authorization for constrained environments xml"/>
(ACE). These are used to express the proof-of-possession key the <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8392.
client wishes to use, the proof-of-possession key that the xml"/>
Authorization Server has selected, and the key the Resource Server <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8422.
uses to authenticate to the client. 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"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9147.
xml"/>
<reference anchor='RFC9200' target='https://www.rfc-editor.org/info/rfc9200'>
<front>
<title>Authentication and Authorization for Constrained Environments (ACE) Using
the OAuth 2.0 Framework (ACE-OAuth)</title>
<author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
<organization />
</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 year='2022' month='August'/>
</front>
<seriesInfo name="RFC" value="9200"/>
<seriesInfo name="DOI" value="10.17487/RFC9200"/>
</reference>
<reference anchor='RFC9201' target='https://www.rfc-editor.org/info/rfc9201'>
<front>
<title>Additional OAuth Parameters for Authentication and Authorization for Cons
trained Environments (ACE)</title>
<author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
<organization />
</author>
<date year='2022' month='August'/>
</front>
<seriesInfo name="RFC" value="9201"/>
<seriesInfo name="DOI" value="10.17487/RFC9201"/>
</reference>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ace-oauth-params-1
5"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5
869">
<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 buildin
g block in various protocols and applications. The key derivation function (KDF
) is intended to support a wide range of applications and requirements, and is c
onservative in its use of cryptographic hash functions. This document is not an
Internet Standards Track specification; it is published for informational pur
poses.</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/rfc6
655">
<front>
<title>AES-CCM Cipher Suites for Transport Layer Security (TLS)</tit
le>
<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 Datag
ram TLS (DTLS) to provide confidentiality and data origin authentication. The A
ES-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/rfc7
662">
<front>
<title>OAuth 2.0 Token Introspection</title>
<author fullname="J. Richer" initials="J." role="editor" surname="Ri
cher">
<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 OAu
th 2.0 token and to determine meta-information about this token. OAuth 2.0 deplo
yments 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/rfc7
748">
<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, includin
g Transport Layer Security (TLS). These curves are intended to operate at the ~
128-bit and ~224-bit security level, respectively, and are generated determinist
ically 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/rfc8
032">
<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 i
mplementation 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/rfc8
446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<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 Secu
rity (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 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 i
mplementations.</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/rfc8
610">
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convent
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
res</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 Conci
se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goa
l is to provide an easy and unambiguous way to express structures for protocol m
essages and data formats that use CBOR or JSON.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8610"/>
<seriesInfo name="DOI" value="10.17487/RFC8610"/>
</reference>
</references>
</references>
<!-- LocalWords: Datagram CoAP CoRE DTLS introducer URI
-->
<!-- LocalWords: namespace Verifier JSON timestamp timestamps PSK
-->
<!-- LocalWords: decrypt UTC decrypted whitespace preshared HMAC
<!-- Local Variables: --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5869.
<!-- coding: utf-8 --> xml"/>
<!-- ispell-local-dictionary: "american" --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6655.
<!-- End: --> 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>
<section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>Special thanks to <contact fullname="Jim Schaad"/> for his contribution
s 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 t
he CelticNext
projects CyberWI and CRITISEC with funding from Vinnova.</t>
</section>
</back> </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> </rfc>
 End of changes. 171 change blocks. 
1477 lines changed or deleted 703 lines changed or added

This html diff was produced by rfcdiff 1.48.