rfc9175.original.xml   rfc9175.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 --> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc sortrefs="yes"?> <!ENTITY nbsp "&#160;">
<?rfc symrefs="yes"?> <!ENTITY zwsp "&#8203;">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft <!ENTITY nbhy "&#8209;">
-ietf-core-echo-request-tag-14" category="std" updates="7252" obsoletes="" submi <!ENTITY wj "&#8288;">
ssionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" ]>
version="3">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-core-echo-request-tag-14" number="9175" category="std" consensus="true" up
dates="7252" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true"
sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 2.47.0 --> <!-- xml2rfc v2v3 conversion 2.47.0 -->
<front> <front>
<title abbrev="Echo, Request-Tag, and Token Processing">CoAP: Echo, Request- <title abbrev="Echo, Request-Tag, and Token Processing">Constrained Applicat
Tag, and Token Processing</title> ion Protocol (CoAP): Echo, Request-Tag, and Token Processing</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-core-echo-request-tag-14 <seriesInfo name="RFC" value="9175"/>
"/> <author initials="C." surname="Amsüss" fullname="Christian Amsüss">
<author initials="C." surname="Amsuess" fullname="Christian Amsüss">
<organization/> <organization/>
<address> <address>
<email>christian@amsuess.com</email> <email>christian@amsuess.com</email>
</address> </address>
</author> </author>
<author initials="J." surname="Mattsson" fullname="John Preuß Mattsson"> <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson ">
<organization>Ericsson AB</organization> <organization>Ericsson AB</organization>
<address> <address>
<email>john.mattsson@ericsson.com</email> <email>john.mattsson@ericsson.com</email>
</address> </address>
</author> </author>
<author initials="G." surname="Selander" fullname="Göran Selander"> <author initials="G." surname="Selander" fullname="Göran Selander">
<organization>Ericsson AB</organization> <organization>Ericsson AB</organization>
<address> <address>
<email>goran.selander@ericsson.com</email> <email>goran.selander@ericsson.com</email>
</address> </address>
</author> </author>
<date year="2021" month="October" day="04"/> <date year="2022" month="February"/>
<area>General</area> <area>General</area>
<workgroup>CoRE Working Group</workgroup> <workgroup>CoRE Working Group</workgroup>
<keyword>OSCORE</keyword>
<keyword>block-wise</keyword>
<keyword>DTLS</keyword>
<keyword>freshness</keyword>
<keyword>delay</keyword>
<keyword>denial-of-service</keyword>
<keyword>amplification</keyword>
<keyword>Message Body Integrity</keyword>
<keyword>Concurrent Block-Wise</keyword>
<keyword>Request-Response Binding</keyword>
<keyword>Token Reuse</keyword>
<abstract> <abstract>
<t>This document specifies enhancements to the Constrained Application Pro <t>This document specifies enhancements to the Constrained Application Pro
tocol (CoAP) that mitigate security issues in particular use cases. The Echo opt tocol
ion enables a CoAP server to verify the freshness of a request or to force a cli (CoAP) that mitigate security issues in particular use cases. The Echo opt
ent to demonstrate reachability at its claimed network address. The Request-Tag ion enables
option allows the CoAP server to match block-wise message fragments belonging to a CoAP server to verify the freshness of a request or to force a client to
the same request. This document updates RFC 7252 with respect to the client Tok demonstrate reachability at its claimed network address. The Request-Tag o
en processing requirements, forbidding non-secure reuse of Tokens to ensure bind ption
ing of response to request when CoAP is used with a security protocol, and with allows the CoAP server to match block-wise message fragments belonging to
respect to amplification mitigation, where the use of Echo is now recommended.</ the same
t> request. This document updates RFC 7252 with respect to the following: pro
cessing
requirements for client Tokens, forbidding non-secure reuse of Tokens to e
nsure response-to-request binding when CoAP is used with a security protocol, an
d
amplification mitigation (where the use of the Echo option is now recommen
ded).</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Discussion of this document takes place on the
CORE Working Group mailing list (core@ietf.org),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/co
re/"/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/core-wg/echo-request-tag"/>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>The initial Constrained Application Protocol (CoAP) suite of specificat <t>The initial suite of specifications for the Constrained Application Pro
ions (<xref target="RFC7252" format="default"/>, <xref target="RFC7641" format=" tocol (CoAP)
default"/>, and <xref target="RFC7959" format="default"/>) was designed with the (<xref target="RFC7252" format="default"/>, <xref target="RFC7641"
assumption that security could be provided on a separate layer, in particular b format="default"/>, and
y using DTLS (<xref target="RFC6347" format="default"/>). However, for some use <xref target="RFC7959" format="default"/>) was designed with the assumptio
cases, additional functionality or extra processing is needed to support secure n that
CoAP operations. This document specifies security enhancements to the Constraine security could be provided on a separate layer, in particular, by using DT
d Application Protocol (CoAP).</t> LS <xref
<t>[ Note to RFC editor: If C321 gets published before C280, target="RFC6347" format="default"/>. However, for some use cases, addition
then the <xref target="RFC6347" format="default"/> references can be upgraded to al
draft-ietf-tls-dtls13-43 without the need for further changes; functionality or extra processing is needed to support secure CoAP operati
the reference is to 6347 here because that was the stable DTLS reference when th ons. This
e document was last touched by the authors. ]</t> document specifies security enhancements to CoAP.</t>
<t>This document specifies two CoAP options, the Echo option and the Reque <t>This document specifies two CoAP options, the Echo option and the Reque
st-Tag option: The Echo option enables a CoAP server to verify the freshness of st-Tag
a request, which can be used to synchronize state, or to force a client to demon option. The Echo option enables a CoAP server to verify the freshness of a
strate reachability at its claimed network address. The Request-Tag option allow request,
s the CoAP server to match message fragments belonging to the same request, frag which can be used to synchronize state, or to force a client to demonstrat
mented using the CoAP block-wise transfer mechanism, which mitigates attacks and e
enables concurrent block-wise operations. These options in themselves do not re reachability at its claimed network address. The Request-Tag option allows
place the need for a security protocol; they specify the format and processing o the CoAP
f data which, when integrity protected using e.g. DTLS (<xref target="RFC6347" f server to match message fragments belonging to the same request, fragmente
ormat="default"/>), TLS (<xref target="RFC8446" format="default"/>), or OSCORE ( d using the
<xref target="RFC8613" format="default"/>), provide the additional security feat CoAP block-wise transfer mechanism, which mitigates attacks and enables co
ures.</t> ncurrent
<t>This document updates <xref target="RFC7252" format="default"/> with a block-wise operations. These options in themselves do not replace the need
recommendation that servers use the Echo option to mitigate amplification attack for a
s.</t> security protocol; they specify the format and processing of data that, wh
<t>The document also updates the Token processing requirements for clients en
specified in <xref target="RFC7252" format="default"/>. The updated processing integrity protected using, e.g., DTLS <xref target="RFC6347" format="defau
forbids non-secure reuse of Tokens to ensure binding of responses to requests wh lt"/>, TLS
en CoAP is used with security, thus mitigating error cases and attacks where the <xref target="RFC8446" format="default"/>, or Object Security for Constrai
client may erroneously associate the wrong response to a request.</t> ned
<t>Each of the following sections provides a more detailed introduction to RESTful Environments (OSCORE) <xref target="RFC8613"
the topic at hand in its first subsection.</t> format="default"/>, provide the additional security features.</t>
<t>This document updates <xref target="RFC7252" format="default"/> with a
recommendation that servers use the Echo option to mitigate amplification
attacks.</t>
<t>The document also updates the Token processing requirements for clients
specified
in <xref target="RFC7252" format="default"/>. The updated processing forbi
ds
non-secure reuse of Tokens to ensure binding of responses to requests when
CoAP is
used with security, thus mitigating error cases and attacks where the clie
nt may
erroneously associate the wrong response to a request.</t>
<t>Each of the following sections provides a more-detailed introduction to
the topic
at hand in its first subsection.</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>
SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" i The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
n this document are to be interpreted as described in BCP 14 <xref target="RFC21 "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
19" format="default"/> <xref target="RFC8174" format="default"/> when, and only NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
when, they appear in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<t>Like <xref target="RFC7252" format="default"/>, this document is rely "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document ar
ing on the Representational State Transfer <xref target="REST" format="default"/ e
> architecture of the Web.</t> to be interpreted as
<t>Unless otherwise specified, the terms "client" and "server" refer to described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
"CoAP client" and "CoAP server", respectively, as defined in <xref target="RFC72 target="RFC8174"/> when, and only when, they appear in all capitals, as
52" format="default"/>. The term "origin server" is used as in <xref target="RFC shown
7252" format="default"/>. The term "origin client" is used in this document to d here.
enote the client from which a request originates; to distinguish from clients in </t>
proxies.</t> <t>Like <xref target="RFC7252" format="default"/>, this document relies
<t>A message's "freshness" is a measure of when a message was sent on a on the Representational State Transfer <xref target="REST" format="defaul
time scale of the recipient. t"/>
A server that receives a request can either verify that the request is fresh architecture of the Web.</t>
or determine that it cannot be verified that the request is fresh. <t>Unless otherwise specified, the terms "client" and "server" refer to
What is considered a fresh message is application dependent; "CoAP
exemplary uses are "no more than one hour ago" or "after this server's last rebo client" and "CoAP server", respectively, as defined in <xref target="RFC7
ot".</t> 252"
<t>The terms "payload" and "body" of a message are used as in <xref targ format="default"/>.</t>
et="RFC7959" format="default"/>. The complete interchange of a request and a re <t>A message's "freshness" is a measure of when a message was sent on a
sponse body is called a (REST) "operation". An operation fragmented using <xref timescale
target="RFC7959" format="default"/> is called a "block-wise operation". A block- of the recipient. A server that receives a request can either verify that
wise operation which is fragmenting the request body is called a "block-wise req the
uest operation". A block-wise operation which is fragmenting the response body request is fresh or determine that it cannot be verified that the request
is called a "block-wise response operation".</t> is fresh.
<t>Two request messages are said to be "matchable" if they occur between What is considered a fresh message is application dependent;
the same endpoint pair, have the same code, and have the same set of options, w exemplary uses are "no more than 42 seconds ago" or "after this server's
ith the exception that elective NoCacheKey options and options involved in block last
-wise transfer (Block1, Block2 and Request-Tag) need not be the same. reboot".</t>
<!-- We could also keep the Request-Tag inside the matchable criterion, but then <t>The terms "payload" and "body" of a message are used as in <xref
we'd be saying "matchable except for the Request-Tag" all over the document. -- target="RFC7959" format="default"/>. The complete interchange of a reque
> st and a
Two operations are said to be matchable if any of their messages are.</t> response body is called a (REST) "operation". An operation fragmented usi
<t>Two matchable block-wise operations are said to be "concurrent" if a ng <xref
block of the second request is exchanged even though the client still intends to target="RFC7959" format="default"/> is called a "block-wise operation". A
exchange further blocks in the first operation. (Concurrent block-wise request block-wise operation that is fragmenting the request body is called a "bl
operations from a single endpoint are impossible with the options of <xref targe ock-wise
t="RFC7959" format="default"/> (see the last paragraphs of Sections 2.4 and 2.5) request operation". A block-wise operation that is fragmenting the respo
because the second operation's block overwrites any state of the first exchange nse body
.).</t> is called a "block-wise response operation".</t>
<t>Two request messages are said to be "matchable" if they occur between
the same
endpoint pair, have the same code, and have the same set of options, with
the
exception that elective NoCacheKey options and options involved in block-
wise
transfer (Block1, Block2, and Request-Tag) need not be the same.
Two blockwise request operations are said to be matchable if their reque
st
messages are matchable.</t>
<t>Two matchable block-wise request operations are said to be "concurren
t" if a
block of
the second request is exchanged even though the client still intends to e
xchange
further blocks in the first operation. (Concurrent block-wise request ope
rations
from a single endpoint are impossible with the options of <xref target="R
FC7959"
format="default"/> -- see the last paragraphs of Sections <xref target="R
FC7959"
section="2.4" sectionFormat="bare"/> and <xref target="RFC7959" section="
2.5"
sectionFormat="bare"/> -- because the second operation's block overwrites
any state
of the first exchange.)</t>
<t>The Echo and Request-Tag options are defined in this document.</t> <t>The Echo and Request-Tag options are defined in this document.</t>
</section> </section>
</section> </section>
<section anchor="echo" numbered="true" toc="default"> <section anchor="echo" numbered="true" toc="default">
<name>Request Freshness and the Echo Option</name> <name>Request Freshness and the Echo Option</name>
<section anchor="req-fresh" numbered="true" toc="default"> <section anchor="req-fresh" numbered="true" toc="default">
<name>Request Freshness</name> <name>Request Freshness</name>
<t>A CoAP server receiving a request is in general not able to verify wh <t>A CoAP server receiving a request is, in general, not able to verify
en the request was sent by the CoAP client. This remains true even if the reques when the
t was protected with a security protocol, such as DTLS. This makes CoAP requests request was sent by the CoAP client. This remains true even if the reques
vulnerable to certain delay attacks which are particularly perilous in the case t was
of actuators (<xref target="I-D.mattsson-core-coap-attacks" format="default"/>) protected with a security protocol, such as DTLS. This makes CoAP request
. Some attacks can be mitigated by establishing fresh session keys, e.g. perform s
ing a DTLS handshake for each request, but in general this is not a solution sui vulnerable to certain delay attacks that are particularly perilous in the
table for constrained environments, for example, due to increased message overhe case of
ad and latency. Additionally, if there are proxies, fresh DTLS session keys betw actuators <xref target="I-D.mattsson-core-coap-attacks" format="default"/
een server and proxy does not say anything about when the client made the reques >. Some
t. In a general hop-by-hop setting, freshness may need to be verified in each ho attacks can be mitigated by establishing fresh session keys, e.g., perfor
p.</t> ming a DTLS
<t>A straightforward mitigation of potential delayed requests is that th handshake for each request, but, in general, this is not a solution suita
e CoAP server rejects a request the first time it appears and asks the CoAP clie ble for
nt to prove that it intended to make the request at this point in time.</t> constrained environments, for example, due to increased message overhead
and
latency. Additionally, if there are proxies, fresh DTLS session keys betw
een the
server
and the proxy do not say anything about when the client made the request.
In a
general hop-by-hop setting, freshness may need to be verified in each hop
.</t>
<t>A straightforward mitigation of potential delayed requests is that th
e CoAP
server rejects a request the first time it appears and asks the CoAP clie
nt to
prove that it intended to make the request at this point in time.</t>
</section> </section>
<section anchor="the-echo-option" numbered="true" toc="default"> <section anchor="the-echo-option" numbered="true" toc="default">
<name>The Echo Option</name> <name>The Echo Option</name>
<t>This document defines the Echo option, a lightweight challenge-respon <t>This document defines the Echo option, a lightweight challenge-respon
se mechanism for CoAP that enables a CoAP server to verify the freshness of a re se
quest. A fresh request is one whose age has not yet exceeded the freshness requi mechanism for CoAP that enables a CoAP server to verify the freshness of
rements set by the server. The freshness requirements are application specific a a request.
nd may vary based on resource, method, and parameters outside of CoAP such as po A fresh request is one whose age has not yet exceeded the freshness requi
licies. The Echo option value is a challenge from the server to the client inclu rements
ded in a CoAP response and echoed back to the server in one or more CoAP request set by the server. The freshness requirements are application specific an
s.</t> d may vary
<t>This mechanism is not only important in the case of actuators, or oth based on resource, method, and parameters outside of CoAP, such as polici
er use cases where the CoAP operations require freshness of requests, but also i es. The
n general for synchronizing state between CoAP client and server, cryptographica Echo option value is a challenge from the server to the client included i
lly verifying the aliveness of the client, or forcing a client to demonstrate re n a CoAP
achability at its claimed network address. The same functionality can be provide response and echoed back to the server in one or more CoAP requests.</t>
d by echoing freshness indicators in CoAP payloads, but this only works for meth <t>This mechanism is not only important in the case of actuators, or oth
ods and response codes defined to have a payload. The Echo option provides a con er use
vention to transfer freshness indicators that works for all methods and response cases where the CoAP operations require freshness of requests, but also i
codes.</t> n general
for synchronizing state between a CoAP client and server, cryptographical
ly
verifying
the aliveness of the client or forcing a client to demonstrate reachabili
ty at its
claimed network address. The same functionality can be provided by echoin
g
freshness indicators in CoAP payloads, but this only works for methods an
d response
codes defined to have a payload. The Echo option provides a convention to
transfer
freshness indicators that works for all methods and response codes.</t>
<section anchor="echo-format" numbered="true" toc="default"> <section anchor="echo-format" numbered="true" toc="default">
<name>Echo Option Format</name> <name>Echo Option Format</name>
<t>The Echo Option is elective, safe-to-forward, not part of the cache <t>The Echo option is elective, safe to forward, not part of the cache
-key, and not repeatable, see <xref target="echo-table" format="default"/>, whic -key, and
h extends Table 4 of <xref target="RFC7252" format="default"/>).</t> not repeatable (see <xref target="echo-table" format="default"/>, which
<figure anchor="echo-table"> extends
Table 4 of <xref target="RFC7252" format="default"/>).</t>
<table anchor="echo-table" align="left">
<name>Echo Option Summary</name> <name>Echo Option Summary</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <thead>
+--------+---+---+---+---+-------------+--------+------+---------+ <tr>
| No. | C | U | N | R | Name | Format | Len. | Default | <th>No.</th>
+--------+---+---+---+---+-------------+--------+------+---------+ <th>C</th>
| TBD252 | | | x | | Echo | opaque | 1-40 | (none) | <th>U</th>
+--------+---+---+---+---+-------------+--------+------+---------+ <th>N</th>
<th>R</th>
C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable <th>Name</th>
]]></artwork> <th>Format</th>
</figure> <th>Length</th>
<t>The Echo option value is generated by a server, and its content and <th>Default</th>
structure are implementation specific. Different methods for generating Echo op </tr>
tion values are outlined in <xref target="echo-state" format="default"/>. Client </thead>
s and intermediaries MUST treat an Echo option value as opaque and make no assum <tbody>
ptions about its content or structure.</t> <tr>
<t>When receiving an Echo option in a request, the server MUST be able <td>252</td>
to verify that the Echo option value (a) was generated by the server or some ot <td></td>
her party that the server trusts, and (b) fulfills the freshness requirements of <td></td>
the application. Depending on the freshness requirements the server may verify <td>x</td>
exactly when the Echo option value was generated (time-based freshness) or verif <td></td>
y that the Echo option was generated after a specific event (event-based freshne <td>Echo</td>
ss). As the request is bound to the Echo option value, the server can determine <td>opaque</td>
that the request is not older that the Echo option value.</t> <td>1-40</td>
<t>When the Echo option is used with OSCORE <xref target="RFC8613" for <td>(none)</td>
mat="default"/> it MAY be an Inner or Outer option, and the Inner and Outer valu </tr>
es are independent. OSCORE servers MUST only produce Inner Echo options unless t </tbody>
hey are merely testing for reachability of the client (the same as proxies may d </table>
o). The Inner option is encrypted and integrity protected between the endpoints, <t>C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable</t>
whereas the Outer option is not protected by OSCORE. As always with OSCORE, out <t>The Echo option value is generated by a server, and its content and
er options are visible to (and may be acted on by) all proxies, and are visible structure
on all links where no additional encryption (like TLS between client and proxy) are implementation specific. Different methods for generating Echo opti
is used.</t> on values
are outlined in <xref target="echo-state" format="default"/>. Clients a
nd
intermediaries <bcp14>MUST</bcp14> treat an Echo option value as opaque
and make
no assumptions about its content or structure.</t>
<t>When receiving an Echo option in a request, the server <bcp14>MUST<
/bcp14> be
able to verify that the Echo option value (a) was generated by the serv
er or some
other party that the server trusts and (b) fulfills the freshness requi
rements
of the application. Depending on the freshness requirements, the server
may verify
exactly when the Echo option value was generated (time-based freshness)
or verify
that the Echo option was generated after a specific event (event-based
freshness). As the request is bound to the Echo option value, the serve
r can
determine that the request is not older than the Echo option value.</t>
<t>When the Echo option is used with OSCORE <xref target="RFC8613"
format="default"/>, it <bcp14>MAY</bcp14> be an Inner or Outer option,
and the
Inner and Outer values are independent. OSCORE servers <bcp14>MUST</bcp
14> only
produce Inner Echo options unless they are merely testing for reachabil
ity of the
client (the same as proxies may do). The Inner option is encrypted and
integrity
protected between the endpoints, whereas the Outer option is not protec
ted by
OSCORE. As always with OSCORE, Outer options are visible to (and may be
acted on
by) all proxies and are visible on all links where no additional encryp
tion
(like TLS between client and proxy) is used.</t>
</section> </section>
</section> </section>
<section anchor="echo-proc" numbered="true" toc="default"> <section anchor="echo-proc" numbered="true" toc="default">
<name>Echo Processing</name> <name>Echo Processing</name>
<t>The Echo option MAY be included in any request or response (see <xref <t>The Echo option <bcp14>MAY</bcp14> be included in any request or resp
target="echo-app" format="default"/> for different applications).</t> onse (see
<t>The application decides under what conditions a CoAP request to a res <xref target="echo-app" format="default"/> for different applications).</
ource is required to be fresh. These conditions can for example include what res t>
ource is requested, the request method and other data in the request, and condit <t>The application decides under what conditions a CoAP request to a res
ions in the environment such as the state of the server or the time of the day.< ource is
/t> required to be fresh. These conditions can, for example, include what res
<t>If a certain request is required to be fresh, the request does not co ource is
ntain a fresh Echo option value, and the server cannot verify the freshness of t requested, the request method and other data in the request, and conditio
he request in some other way, the server MUST NOT process the request further an ns in the
d SHOULD send a 4.01 Unauthorized response with an Echo option. The server MAY i environment, such as the state of the server or the time of the day.</t>
nclude the same Echo option value in several different response messages and to <t>If a certain request is required to be fresh, the request does not co
different clients. Examples of this could be time-based freshness when several r ntain a
esponses are sent closely after each other or event-based freshness with no even fresh Echo option value, and the server cannot verify the freshness of th
t taking place between the responses.</t> e request
<t>The server may use request freshness provided by the Echo option to v in some other way, the server <bcp14>MUST NOT</bcp14> process the request
erify the aliveness of a client or to synchronize state. The server may also inc further
lude the Echo option in a response to force a client to demonstrate reachability and <bcp14>SHOULD</bcp14> send a 4.01 (Unauthorized) response with an Ech
at its claimed network address. Note that the Echo option does not bind a reque o option.
st to any particular previous response, but provides an indication that the clie The server <bcp14>MAY</bcp14> include the same Echo option value in sever
nt had access to the previous response at the time when it created the request.< al
/t> different response messages and to different clients. Examples of this co
<t>Upon receiving a 4.01 Unauthorized response with the Echo option, the uld be
client SHOULD resend the original request with the addition of an Echo option w time-based freshness (when several responses are sent closely after each
ith the received Echo option value. The client MAY send a different request comp other) or
ared to the original request. Upon receiving any other response with the Echo op event-based freshness (with no event taking place between the responses).
tion, the client SHOULD echo the Echo option value in the next request to the se </t>
rver. The client MAY include the same Echo option value in several different req <t>The server may use request freshness provided by the Echo option to v
uests to the server, or discard it at any time (especially to avoid tracking, se erify the
e <xref target="priv-cons" format="default"/>).</t> aliveness of a client or to synchronize state. The server may also includ
<t>A client MUST only send Echo values to endpoints it received them fro e the Echo
m (where as defined in <xref target="RFC7252" format="default"/> Section 1.2, th option in a response to force a client to demonstrate reachability at its
e security association is part of the endpoint). In OSCORE processing, that mean claimed
s sending Echo values from Outer options (or from non-OSCORE responses) back in network address. Note that the Echo option does not bind a request to any
Outer options, and those from Inner options in Inner options in the same securit particular previous response but provides an indication that the client h
y context.</t> ad access
<t>Upon receiving a request with the Echo option, the server determines to the previous response at the time when it created the request.</t>
if the request is required to be fresh. If not, the Echo option MAY be ignored. <t>Upon receiving a 4.01 (Unauthorized) response with the Echo option, t
If the request is required to be fresh and the server cannot verify the freshnes he client
s of the request in some other way, the server MUST use the Echo option to verif <bcp14>SHOULD</bcp14> resend the original request with the addition of an
y that the request is fresh. If the server cannot verify that the request is fre Echo
sh, the request is not processed further, and an error message MAY be sent. The option with the received Echo option value. The client <bcp14>MAY</bcp14>
error message SHOULD include a new Echo option.</t> send a
<t>One way for the server to verify freshness is to bind the Echo value different request compared to the original request. Upon receiving any ot
to a specific point in time and verify that the request is not older than a cert her
ain threshold T. The server can verify this by checking that (t1 - t0) &lt; T, w response with the Echo option, the client <bcp14>SHOULD</bcp14> echo the
here t1 is the request receive time and t0 is the time when the Echo option valu Echo
e was generated. An example message flow over DTLS is shown <xref target="echo-f option value in the next request to the server. The client <bcp14>MAY</bc
igure-time" format="default"/>.</t> p14>
include the same Echo option value in several different requests to the s
erver or
discard it at any time (especially to avoid tracking; see <xref target="p
riv-cons"
format="default"/>).</t>
<t>A client <bcp14>MUST</bcp14> only send Echo option values to endpoint
s it
received them
from (where, as defined in <xref target="RFC7252" section="1.2"
sectionFormat="of"/>, the security association is part of the endpoint).
In
OSCORE processing, that means sending Echo option values from Outer optio
ns (or
from non-OSCORE responses) back in Outer options and sending those from I
nner
options in Inner options in the same security context.</t>
<t>Upon receiving a request with the Echo option, the server determines
if the
request is required to be fresh. If not, the Echo option <bcp14>MAY</bcp1
4> be
ignored. If the request is required to be fresh and the server cannot ver
ify the
freshness of the request in some other way, the server <bcp14>MUST</bcp14
> use the
Echo option to verify that the request is fresh. If the server cannot ver
ify that
the request is fresh, the request is not processed further, and an error
message
<bcp14>MAY</bcp14> be sent. The error message <bcp14>SHOULD</bcp14> inclu
de a new
Echo option.</t>
<t>One way for the server to verify freshness is to bind the Echo option
value to a
specific point in time and verify that the request is not older than a ce
rtain
threshold T. The server can verify this by checking that (t1 - t0) &lt; T
, where t1
is the request receive time and t0 is the time when the Echo option value
was
generated. An example message flow over DTLS is shown <xref
target="echo-figure-time" format="default"/>.</t>
<figure anchor="echo-figure-time"> <figure anchor="echo-figure-time">
<name>Example Message Flow for Time-Based Freshness using the 'Integri <name>Example Message Flow for Time-Based Freshness Using the
ty Protected Timestamp' construction of Appendix A</name> 'Integrity&nbhy;Protected Timestamp' Construction of Appendix A</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
Client Server Client Server
| | | |
+------>| Code: 0.03 (PUT) +------>| Code: 0.03 (PUT)
| PUT | Token: 0x41 | PUT | Token: 0x41
| | Uri-Path: lock | | Uri-Path: lock
| | Payload: 0 (Unlock) | | Payload: 0 (Unlock)
| | | |
|<------+ Code: 4.01 (Unauthorized) |<------+ Code: 4.01 (Unauthorized)
| 4.01 | Token: 0x41 | 4.01 | Token: 0x41
skipping to change at line 145 skipping to change at line 323
| | Echo: 0x00000009437468756c687521 (t0 = 9, +MAC) | | Echo: 0x00000009437468756c687521 (t0 = 9, +MAC)
| | Payload: 0 (Unlock) | | Payload: 0 (Unlock)
| | | |
| | Verify MAC, compare t1 - t0 = 1 < T => permitted. | | Verify MAC, compare t1 - t0 = 1 < T => permitted.
| | | |
|<------+ Code: 2.04 (Changed) |<------+ Code: 2.04 (Changed)
| 2.04 | Token: 0x42 | 2.04 | Token: 0x42
| | | |
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Another way for the server to verify freshness is to maintain a cache
of values associated to events. The size of the cache is defined by the applica <t>Another way for the server to verify freshness is to maintain a cache
tion. In the following we assume the cache size is 1, in which case freshness is of values
defined as no new event has taken place. At each event a new value is written i associated to events. The size of the cache is defined by the application
nto the cache. The cache values MUST be different except with negligible probabi . In the
lity. The server verifies freshness by checking that e0 equals e1, where e0 is t following, we assume the cache size is 1, in which case, freshness is def
he cached value when the Echo option value was generated, and e1 is the cached v ined as
alue at the reception of the request. An example message flow over DTLS is shown "no new event has taken place". At each event, a new value is written int
in <xref target="echo-figure-event" format="default"/>.</t> o the
cache. The cache values <bcp14>MUST</bcp14> be different or chosen in a w
ay so the
probability for collisions is negligible.
The server verifies freshness by checking that e0 equals e1, where e0 is
the cached
value when the Echo option value was generated, and e1 is the cached valu
e at the
reception of the request. An example message flow over DTLS is shown in <
xref
target="echo-figure-event" format="default"/>.</t>
<figure anchor="echo-figure-event"> <figure anchor="echo-figure-event">
<name>Example Message Flow for Event-Based Freshness using the 'Persis <name>Example Message Flow for Event-Based Freshness Using the 'Persis
tent Counter' construction of Appendix A</name> tent
Counter' Construction of Appendix A</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
Client Server Client Server
| | | |
+------>| Code: 0.03 (PUT) +------>| Code: 0.03 (PUT)
| PUT | Token: 0x41 | PUT | Token: 0x41
| | Uri-Path: lock | | Uri-Path: lock
| | Payload: 0 (Unlock) | | Payload: 0 (Unlock)
| | | |
|<------+ Code: 4.01 (Unauthorized) |<------+ Code: 4.01 (Unauthorized)
| 4.01 | Token: 0x41 | 4.01 | Token: 0x41
skipping to change at line 175 skipping to change at line 364
| PUT | Token: 0x42 | PUT | Token: 0x42
| | Uri-Path: lock | | Uri-Path: lock
| | Echo: 0x05 | | Echo: 0x05
| | Payload: 0 (Unlock) | | Payload: 0 (Unlock)
| | | |
| | Compare e1 = e0 => permitted. | | Compare e1 = e0 => permitted.
| | | |
|<------+ Code: 2.04 (Changed) |<------+ Code: 2.04 (Changed)
| 2.04 | Token: 0x42 | 2.04 | Token: 0x42
| | Echo: 0x06 (e2 = 6, to allow later locking | | Echo: 0x06 (e2 = 6, to allow later locking
| | without more round-trips) | | without more round trips)
| | | |
]]></artwork> ]]></artwork>
</figure> </figure>
<t>When used to serve freshness requirements (including client aliveness <t>When used to serve freshness requirements (including client aliveness
and state synchronizing), the Echo option value MUST be integrity protected bet and state
ween the intended endpoints, e.g. using DTLS, TLS, or an OSCORE Inner option (<x synchronizing), the Echo option value <bcp14>MUST</bcp14> be integrity pr
ref target="RFC8613" format="default"/>). When used to demonstrate reachability otected
at a claimed network address, the Echo option SHOULD be a MAC of the claimed add between the intended endpoints, e.g., using DTLS, TLS, or an OSCORE Inner
ress, but MAY be unprotected. Combining different Echo applications can necessit option
ate different choices, see <xref target="echo-state" format="default"/> item 2 f <xref target="RFC8613" format="default"/>.
or an example.</t> When used to demonstrate reachability
<t>An Echo option MAY be sent with a successful response, at a claimed network address, the Echo option <bcp14>SHOULD</bcp14> be a
i.e., even though the request satisfied any freshness requirements on the operat Message
ion. Authentication Code (MAC) of the
This is called a "preemptive" Echo value, claimed address but <bcp14>MAY</bcp14> be unprotected. Combining differen
and useful when the server anticipates that the client will need to demonstrate t Echo
freshness relative to the current response the near future.</t> applications can necessitate different choices; see <xref target="echo-st
<t>A CoAP-to-CoAP proxy MAY set an Echo option on responses, both on for ate"
warded ones that had no Echo option or ones generated by the proxy (from cache o format="default"/>, item 2 for an example.</t>
r as an error). If it does so, it MUST remove the Echo option it recognizes as o <t>An Echo option <bcp14>MAY</bcp14> be sent with a successful response,
ne generated by itself on follow-up requests. When it receives an Echo option in i.e., even though
a response, it MAY forward it to the client (and, not recognizing it as an own the request satisfied any freshness requirements on the operation. This i
in future requests, relay it in the other direction as well) or process it on it s called a
s own. "preemptive" Echo option value and is useful when the server anticipates
If it does so, it MUST ensure that the client's request was generated (or is re- that the client
generated) after the Echo value used to send to the server was first seen. will need to demonstrate freshness relative to the current response in th
(In most cases, this means that the proxy needs to ask the client to repeat the e near future.</t>
request with a new Echo value.)</t> <t>A CoAP-to-CoAP proxy <bcp14>MAY</bcp14> set an Echo option on response
<t>The CoAP server side of CoAP-to-HTTP proxies MAY request freshness, e s, both on
specially if they have reason to assume that access may require it (e.g. because forwarded ones that had no Echo option or ones generated by the proxy (fr
it is a PUT or POST); how this is determined is out of scope for this document. om cache
The CoAP client side of HTTP-to-CoAP proxies MUST respond to Echo challenges it or as an error). If it does so, it <bcp14>MUST</bcp14> remove the Echo op
self if the proxy knows from the recent establishing of the connection that the tion it
HTTP request is fresh. Otherwise, it MUST NOT repeat an unsafe request and SHOUL recognizes as one generated by itself on follow-up requests. When it rece
D respond with 503 Service Unavailable, Retry-After: 0 and terminate any underly ives an
ing Keep-Alive connection. If the HTTP request arrived in Early Data, the proxy Echo option in a response, it <bcp14>MAY</bcp14> forward it to the client
SHOULD use a 425 Too Early response instead (see <xref target="RFC8470" format=" (and, not
default"/>). They MAY also use other mechanisms to establish freshness of the HT recognizing it as its own in future requests, relay it in the other direc
TP request that are not specified here.</t> tion as
well) or process it on its own. If it does so, it <bcp14>MUST</bcp14> ens
ure that
the client's request was generated (or is regenerated) after the Echo opt
ion value
used
to send to the server was first seen. (In most cases, this means that the
proxy
needs to ask the client to repeat the request with a new Echo option valu
e.)</t>
<t>The CoAP server side of CoAP-to-HTTP proxies <bcp14>MAY</bcp14> reques
t
freshness, especially if they have reason to assume that access may requi
re it
(e.g., because it is a PUT or POST); how this is determined is out of sco
pe for this
document. The CoAP client side of HTTP-to-CoAP proxies <bcp14>MUST</bcp14
> respond
to Echo challenges itself if the proxy knows from the recent establishing
of the
connection that the HTTP request is fresh. Otherwise, it <bcp14>MUST NOT<
/bcp14>
repeat an unsafe request and <bcp14>SHOULD</bcp14> respond with a 503 (Se
rvice
Unavailable) with a Retry-After value of 0 seconds and terminate any unde
rlying
Keep-Alive connection. If
the HTTP request arrived in early data, the proxy <bcp14>SHOULD</bcp14> u
se a 425
(Too Early) response instead (see <xref target="RFC8470" format="default"
/>). The
proxy <bcp14>MAY</bcp14> also use other mechanisms to establish freshness
of the
HTTP request that are not specified here.</t>
</section> </section>
<section anchor="echo-app" numbered="true" toc="default"> <section anchor="echo-app" numbered="true" toc="default">
<name>Applications of the Echo Option</name> <name>Applications of the Echo Option</name>
<t>Unless otherwise noted, <t>Unless otherwise noted, all these applications require a security pro
all these applications require a security protocol to be used, tocol to be
and the Echo option to be protected by it.</t> used and the Echo option to be protected by it.</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li> <li>
<t>Actuation requests often require freshness guarantees to avoid ac <t>Actuation requests often require freshness guarantees to avoid ac
cidental or malicious delayed actuator actions. In general, all non-safe methods cidental or
(e.g. POST, PUT, DELETE) may require freshness guarantees for secure operation. malicious delayed actuator actions. In general, all unsafe methods (e
</t> .g.,
POST, PUT, and DELETE) may require freshness guarantees for secure op
eration.
</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The same Echo value may be used for multiple actuation request <li>The same Echo option value may be used for multiple actuation
s to the same server, as long as the total time since the Echo option value was requests
generated is below the freshness threshold.</li> to the
<li>For actuator applications with low delay tolerance, to avoid a same server, as long as the total time since the Echo option value
dditional round-trips for multiple requests in rapid sequence, the server may se was
nd preemptive Echo values in successful requests, irrespectively of whether the generated is below the freshness threshold.</li>
request contained an Echo option or not. The client then uses the Echo option wi <li>For actuator applications with low delay tolerance, to avoid a
th the new value in the next actuation request, and the server compares the rece dditional
ive time accordingly.</li> round trips for multiple requests in rapid sequence, the server may
send
preemptive Echo option values in successful requests, irrespectivel
y of
whether or not the
request contained an Echo option. The client then uses the Echo opt
ion
with the new value in the next actuation request, and the server co
mpares the
receive time accordingly.</li>
</ul> </ul>
</li> </li>
<li> <li>
<t>A server may use the Echo option to synchronize properties (such <t>A server may use the Echo option to synchronize properties (such
as state or time) with a requesting client. A server MUST NOT synchronize a prop as state or
erty with a client which is not the authority of the property being synchronized time) with a requesting client. A server <bcp14>MUST NOT</bcp14> sync
. E.g. if access to a server resource is dependent on time, then server MUST NOT hronize a
synchronize time with a client requesting access unless the client is time auth property with a client that is not the authority of the property bein
ority for the server. </t> g
<t> synchronized. For example, if access to a server resource is dependen
Note that the state to be synchronized is not carried inside the Echo option. t on time,
Any explicit state information needs to be carried along in the messages the Ec then the server <bcp14>MUST NOT</bcp14> synchronize time with a clien
ho value is sent in; t
the Echo mechanism only provides a partial order on the messages' processing. requesting access unless the client is a time authority for the serve
</t> r. </t>
<t>Note that the state to be synchronized is not carried inside the
Echo option.
Any explicit state information needs to be carried along in the messa
ges the
Echo option value is sent in; the Echo mechanism only provides a part
ial order
on the messages' processing. </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If a server reboots during operation it may need to synchroniz <li>If a server reboots during operation, it may need to synchroni
e state or time before continuing the interaction. For example, with OSCORE it i ze
s possible to reuse a partly persistently stored security context by synchronizi state or
ng the Partial IV (sequence number) using the Echo option as specified in Sectio time before continuing the interaction. For example, with OSCORE, i
n 7.5 of <xref target="RFC8613" format="default"/>.</li> t is
<li>A device joining a CoAP group communication <xref target="I-D. possible to reuse a partly persistently stored security context by
ietf-core-groupcomm-bis" format="default"/> protected with OSCORE <xref target=" synchronizing the Partial IV (sequence number) using the Echo optio
I-D.ietf-core-oscore-groupcomm" format="default"/> may be required to initially n, as
synchronize its replay window state with a client by using the Echo option in a specified in <xref target="RFC8613" sectionFormat="of" section="7.5
unicast response to a multicast request. The client receiving the response with "/>.</li>
the Echo option includes the Echo value in a subsequent unicast request to the r <li>A device joining a CoAP group communication <xref
esponding server.</li> target="I-D.ietf-core-groupcomm-bis" format="default"/> protected w
ith OSCORE
<xref target="I-D.ietf-core-oscore-groupcomm" format="default"/> ma
y be
required to initially synchronize its replay window state with a cl
ient by
using the Echo option in a unicast response to a multicast request.
The
client receiving the response with the Echo option includes the Ech
o option
value in a subsequent unicast request to the responding server.</li
>
</ul> </ul>
</li> </li>
<li> <li>
<t>An attacker can perform a denial-of-service attack by putting a v <t>An attacker can perform a denial-of-service attack by putting a v
ictim's address in the source address of a CoAP request and sending the request ictim's
to a resource with a large amplification factor. The amplification factor is the address in the source address of a CoAP request and sending the reque
ratio between the size of the request and the total size of the response(s) to st to a
that request. A server that provides a large amplification factor to an unauthen resource with a large amplification factor. The amplification factor
ticated peer SHOULD mitigate amplification attacks as described in Section 11.3 is the
of <xref target="RFC7252" format="default"/>. One way to mitigate such attacks i ratio between the size of the request and the total size of the respo
s that the server responds to the alleged source address of the request with an nse(s) to
Echo option in short response message (e.g. 4.01 Unauthorized), thereby requesti that request. A server that provides a large amplification factor to
ng the client to verify its source address. This needs to be done only once per an
endpoint and limits the range of potential victims from the general Internet to unauthenticated peer <bcp14>SHOULD</bcp14> mitigate amplification att
endpoints that have been previously in contact with the server. For this applica acks, as
tion, the Echo option can be used in messages that are not integrity protected, described in <xref target="RFC7252" sectionFormat="of" section="11.3"
for example during discovery. (This is formally recommended in <xref target="amp />. One way
l-mit" format="default"/>). </t> to mitigate such attacks is for the server to respond to the alleged
source
address of the request with an Echo option in a short response messag
e (e.g.,
4.01 (Unauthorized)), thereby requesting the client to verify its sou
rce
address. This
needs to be done only once per endpoint and limits the range of poten
tial
victims from the general Internet to endpoints that have been previou
sly in
contact with the server. For this application, the Echo option can be
used in
messages that are not integrity protected, for example, during discov
ery. (This
is formally recommended in <xref target="ampl-mit" format="default"/>
.)</t>
<ul spacing="normal"> <ul spacing="normal">
<li>In the presence of a proxy, a server will not be able to disti <li>In the presence of a proxy, a server will not be able to disti
nguish different origin client endpoints. Following from the recommendation abov nguish
e, a proxy that provides a large amplification factor to unauthenticated peers S different origin client endpoints, i.e., the client from which a re
HOULD mitigate amplification attacks. The proxy SHOULD use Echo to verify origin quest
reachability as described in <xref target="echo-proc" format="default"/>. The p originates. Following from the recommendation above, a
roxy MAY forward safe requests immediately to have a cached result available whe proxy that provides a large amplification factor to unauthenticated
n the client's repeated request arrives.</li> peers
<bcp14>SHOULD</bcp14> mitigate amplification attacks. The proxy
<bcp14>SHOULD</bcp14> use the Echo option to verify origin reachabi
lity, as
described in
<xref target="echo-proc" format="default"/>. The proxy <bcp14>MAY</
bcp14>
forward safe requests immediately to have a cached result available
when the
client's repeated request arrives.</li>
<li> <li>
<t>Amplification mitigation is a trade-off between giving levera <t>Amplification mitigation is a trade-off between giving levera
ge to an attacker and causing overhead. ge to an
An amplification factor of 3 (i.e., don't send more than three times the number attacker and causing overhead. An amplification factor of 3 (i.e.
of bytes received until the peer's address is confirmed) , don't
is considered acceptable for unconstrained applications in <xref target="RFC9000 send more than three times the number of bytes received until the
" format="default"/> Section 8. </t> peer's
<t> address is confirmed) is considered acceptable for unconstrained
When that limit is applied and no further context is available, applications in <xref target="RFC9000" sectionFormat="comma"
a safe default is sending initial responses no larger than 136 Bytes in CoAP ser section="8"/>.</t>
ialization. <t>When that limit is applied and no further context is available
(The number is assuming a 14 + 40 + 8 Bytes Ethernet, IP and UDP header , a safe
with 4 Bytes added for the CoAP header. Triple that minus the non-CoAP headers g default is sending initial responses no larger than 136 bytes in
ives the 136 Bytes). CoAP
Given the token also takes up space in the request, responding with 132 Bytes af serialization. (The number is assuming Ethernet, IP, and UDP head
ter the token is safe as well.</t> ers of
14, 40, and 8 bytes, respectively, with 4 bytes added for the CoA
P header.
Triple that minus the
non-CoAP headers gives the 136 bytes.) Given the token also takes
up space
in the request, responding with 132 bytes after the token is safe
as
well.</t>
</li> </li>
<li>When an Echo response is sent to mitigate amplification, <li>When an Echo response is sent to mitigate amplification, it
it MUST be sent as a piggybacked or Non-confirmable response, <bcp14>MUST</bcp14> be sent as a piggybacked or Non-confirmable res
never as a separate one (which would cause amplification due to retransmission). ponse,
</li> never as a separate one (which would cause amplification due to
retransmission).</li>
</ul> </ul>
</li> </li>
<li>A server may want to use the request freshness provided by the Ech <li>A server may want to use the request freshness provided by the Ech
o to verify the aliveness of a client. Note that in a deployment with hop-by-hop o option
security and proxies, the server can only verify aliveness of the closest proxy to verify the aliveness of a client. Note that, in a deployment with ho
.</li> p-by-hop
security and proxies, the server can only verify aliveness of the close
st
proxy.</li>
</ol> </ol>
</section> </section>
<section anchor="characterization-of-echo-applications" numbered="true" to c="default"> <section anchor="characterization-of-echo-applications" numbered="true" to c="default">
<name>Characterization of Echo Applications</name> <name>Characterization of Echo Applications</name>
<t>Use cases for the Echo option <t>Use cases for the Echo option can be characterized by several criteri
can be characterized by several criteria that help determine the required proper a that help
ties of the Echo value. determine the required properties of the Echo option value. These criteri
These criteria apply both to those listed in <xref target="echo-app" format="def a apply
ault"/> and any novel applications. both to those listed in <xref target="echo-app" format="default"/> and an
They provide rationale for the statements in the former, and guidance for the la y novel
tter.</t> applications. They provide rationale for the statements in the former and
guidance
for the latter.</t>
<section anchor="time-versus-event-based-freshness" numbered="true" toc= "default"> <section anchor="time-versus-event-based-freshness" numbered="true" toc= "default">
<name>Time versus Event Based Freshness</name> <name>Time-Based versus Event-Based Freshness</name>
<t>The property a client demonstrates by sending an Echo value is that <t>The property a client demonstrates by sending an Echo option value
the request was sent is that the
after a certain point in time, request was sent after a certain point in time or after some event happ
or after some event happened on the server.</t> ened on
<t>When events are counted, the server.</t>
they form something that can be used as a monotonic but very non-uniform time li <t>When events are counted, they form something that can be used as a
ne. monotonic
With highly regular events and low-resolution time, but very non-uniform time line. With highly regular events and low-reso
the distinction between time and event based freshness can be blurred: lution
"No longer than a month ago" is similar to "since the last full moon".</t> time, the distinction between time-based and event-based freshness can
<t>In an extreme form of event based freshness, be blurred:
the server can place an event whenever an Echo value is used. "no longer than a month ago" is similar to "since the last full moon".<
This makes the Echo value effectively single-use.</t> /t>
<t>Event and time based freshness can be combined in a single Echo val <t>In an extreme form of event-based freshness,
ue, the server can place an event whenever an Echo option value is used.
e.g. by encrypting a timestamp with a key that changes with every event This makes the Echo option value effectively single use.</t>
to obtain "usable once but only for 5 minutes"-style semantics.</t> <t>Event-based and time-based freshness can be combined in a single Ec
ho option
value,
e.g., by encrypting a timestamp with a key that changes with every even
t
to obtain semantics in the style of "usable once but only for 5 minutes
".</t>
</section> </section>
<section anchor="source-of-truth" numbered="true" toc="default"> <section anchor="source-of-truth" numbered="true" toc="default">
<name>Authority over Used Information</name> <name>Authority over Used Information</name>
<t>Information conveyed to the server in the request Echo value <t>Information conveyed to the server in the request Echo option value
has different authority depending on the application. has
Understanding who or what is the authoritative source of that information helps different
the server implementer decide the necessary protection of the Echo value.</t> authority depending on the application. Understanding who or what is th
<t>If all that is conveyed to the server is information which the clie e
nt is authorized to provide arbitrarily, authoritative source of that information helps the server implementor d
(which is another way of saying that the server has to trust the client on whate ecide the
ver Echo is being used for), necessary protection of the Echo option value.</t>
then the server can issue Echo values that do not need to be protected on their <t>If all that is conveyed to the server is information that the clien
own. t is
They still need to be covered by the security protocol that covers the rest of t authorized to provide arbitrarily (which is another way of saying that
he message, the
but the Echo value can be just short enough to be unique between this server and server has to trust the client on whatever the Echo option is being use
client.</t> d for),
<t>For example, then the server can issue Echo option values that do not need to be pro
the client's OSCORE sender sequence number (as used in <xref target="RFC8613" fo tected on
rmat="default"/> Appendix B.1.2) is such information.</t> their own. They still need to be covered by the security protocol that
<t>In most other cases, covers
there is information conveyed for which the server is the authority the rest of the message, but the Echo option value can be just short en
("The request must not be older than five minutes" is counted on the server's cl ough to
ock, not the client's) be unique between this server and client.</t>
or which even involve the network <t>For example, the client's OSCORE Sender Sequence Number (as used in
(as when performing amplification mitigation). <xref
In these cases, the Echo value itself needs to be protected against forgery by t target="RFC8613" sectionFormat="comma" section="B.1.2"/>) is such infor
he client, mation.</t>
e.g. by using a sufficiently large random value or a MAC as described in <xref t <t>In most other cases, there is information conveyed for which the se
arget="echo-state" format="default"/> items 1 and 2.</t> rver is the
<t>For some applications, authority ("the request must not be older than five minutes" is counted
the server may be able to trust the client to also act as the authority on the
(e.g. when using time based freshness purely to mitigate request delay attacks); server's clock, not the client's) or which even involve the network (as
these need careful case-by-case evaluation. when
<!-- RD's registration state is an example; RD may need to provide that evaluati performing amplification mitigation). In these cases, the Echo option v
on now. --> alue
itself needs
to be protected against forgery by the client, e.g., by using a suffici
ently
large, random value or a MAC, as described in <xref target="echo-state"
format="default"/>, items 1 and 2.</t>
<t>For some applications, the server may be able to trust the client t
o also act
as the authority (e.g., when using time-based freshness purely to mitig
ate request
delay attacks); these need careful case-by-case evaluation.
</t> </t>
<t>To issue Echo values without own protection,
the server needs to trust the client to never produce requests with attacker con <t>To issue Echo option values without integrity protection of its own,
trolled Echo values. the server needs to trust the
The provisions of <xref target="echo-proc" format="default"/> (saying that an Ec client to never produce requests with attacker-controlled Echo option v
ho value may only be sent as received from the same server) alues.
allow that. The provisions of <xref target="echo-proc" format="default"/> (saying t
The requirement stated there for the client to treat the Echo value as opaque ho hat an
lds for these application like for all others.</t> Echo option value may only be sent as received from the same server) al
low that.
The requirement stated there for the client to treat the Echo option va
lue as
opaque
holds for these applications like for all others.</t>
<t>When the client is the sole authority over the synchronized propert y, <t>When the client is the sole authority over the synchronized propert y,
the server can still use time or events to issue new Echo values. the server can still use time or events to issue new Echo option values
Then, the request's Echo value not so much proves the indicated freshness to the .
server, Then, the request's Echo option value not so much proves the indicated
but reflects the client's intention to indicate reception of responses containin freshness
g that value when sending the later ones.</t> to the
<t>Note that a single Echo value can be used for multiple purposes server but reflects the client's intention to indicate reception of res
(e.g. to get both the sequence number information and perform amplification miti ponses
gation). containing that value when sending the later ones.</t>
In this case the stricter protection requirements apply.</t> <t>Note that a single Echo option value can be used for multiple purpo
ses (e.g.,
to both get
the sequence number information and perform amplification mitigation).
In
this case, the stricter protection requirements apply.</t>
</section> </section>
<section anchor="protection-by-a-security-protocol" numbered="true" toc= "default"> <section anchor="protection-by-a-security-protocol" numbered="true" toc= "default">
<name>Protection by a Security Protocol</name> <name>Protection by a Security Protocol</name>
<t>For meaningful results, the Echo option needs to be used in combina <t>For meaningful results, the Echo option needs to be used in combina
tion with a security protocol in almost all applications.</t> tion with a
<t>When the information extracted by the server security protocol in almost all applications.</t>
is only about a part of the system outside of any security protocol, <t>When the information extracted by the server is only about a part o
then the Echo option can also be used without a security protocol f the
(in case of OSCORE, as an outer option).</t> system outside of any security protocol, then the Echo option can also
<t>The only known application satisfying this requirement is network a be used
ddress reachability, without a security protocol (in case of OSCORE, as an Outer option).</t
where unprotected Echo values are used both by servers (e.g. during setup of a s >
ecurity context) <t>The only known application satisfying this requirement is network a
and proxies (which do not necessarily have a security association with their cli ddress
ents) reachability, where unprotected Echo option values are used both by ser
for amplification mitigation.</t> vers
(e.g., during
setup of a security context) and proxies (which do not necessarily have
a
security association with their clients) for amplification mitigation.<
/t>
</section> </section>
</section> </section>
<section anchor="ampl-mit" numbered="true" toc="default"> <section anchor="ampl-mit" numbered="true" toc="default">
<name>Updated Amplification Mitigation Requirements for Servers</name> <name>Updated Amplification Mitigation Requirements for Servers</name>
<t>This section updates the amplification mitigation requirements for se <t>This section updates the amplification mitigation requirements for se
rvers in <xref target="RFC7252" format="default"/> to recommend use of the Echo rvers in
option to mitigate amplification attacks. The requirements for clients are not u <xref target="RFC7252" format="default"/> to recommend the use of the Ech
pdated. Section 11.3 of <xref target="RFC7252" format="default"/> is updated by o option to
adding the following text:</t> mitigate amplification attacks. The requirements for clients are not upda
<t>A CoAP server SHOULD mitigate potential amplification attacks by resp ted. <xref
onding to unauthenticated clients with 4.01 Unauthorized including an Echo optio target="RFC7252" sectionFormat="of" section="11.3"/> is updated by adding
n, as described in <xref target="echo-app" format="default"/> item 3 of [[this d the
ocument]].</t> following text:</t>
<blockquote>A CoAP server <bcp14>SHOULD</bcp14> mitigate potential ampli
fication
attacks by responding to unauthenticated clients with 4.01 (Unauthorized)
including
an Echo option, as described in item 3 in <xref target="echo-app"
format="default"/> of RFC 9175.</blockquote>
</section> </section>
</section> </section>
<section anchor="request-tag" numbered="true" toc="default"> <section anchor="request-tag" numbered="true" toc="default">
<name>Protecting Message Bodies using Request Tags</name> <name>Protecting Message Bodies Using Request Tags</name>
<section anchor="body-int" numbered="true" toc="default"> <section anchor="body-int" numbered="true" toc="default">
<name>Fragmented Message Body Integrity</name> <name>Fragmented Message Body Integrity</name>
<t>CoAP was designed to work over unreliable transports, such as UDP, an <t>CoAP was designed to work over unreliable transports, such as UDP, an
d includes a lightweight reliability feature to handle messages which are lost o d includes
r arrive out of order. In order for a security protocol to support CoAP operatio a lightweight reliability feature to handle messages that are lost or arr
ns over unreliable transports, it must allow out-of-order delivery of messages.< ive out
/t> of order. In order for a security protocol to support CoAP operations ove
<t>The block-wise transfer mechanism <xref target="RFC7959" format="defa r
ult"/> extends CoAP by defining the transfer of a large resource representation unreliable transports, it must allow out-of-order delivery of messages.</
(CoAP message body) as a sequence of blocks (CoAP message payloads). The mechani t>
sm uses a pair of CoAP options, Block1 and Block2, pertaining to the request and
response payload, respectively. The block-wise functionality does not support t <t>The block-wise transfer mechanism <xref target="RFC7959" format="defau
he detection of interchanged blocks between different message bodies to the same lt"/>
resource having the same block number. This remains true even when CoAP is used extends CoAP by defining the transfer of a large resource representation
together with a security protocol such as DTLS or OSCORE, within the replay win (CoAP
dow (<xref target="I-D.mattsson-core-coap-attacks" format="default"/>), which is message body) as a sequence of blocks (CoAP message payloads). The mechan
a vulnerability of CoAP when using RFC7959.</t> ism uses a
<t>A straightforward mitigation of mixing up blocks from different messa pair of CoAP options, Block1 and Block2, pertaining to the request and re
ges is to use unique identifiers for different message bodies, which would provi sponse
de equivalent protection to the case where the complete body fits into a single payload, respectively. The block-wise functionality does not support the
payload. The ETag option <xref target="RFC7252" format="default"/>, set by the C detection
oAP server, identifies a response body fragmented using the Block2 option.</t> of interchanged blocks between different message bodies to the same resou
rce having
the same block number. This remains true even when CoAP is used together
with a
security protocol (such as DTLS or OSCORE) within the replay window <xref
target="I-D.mattsson-core-coap-attacks" format="default"/>, which is a
vulnerability of the block-wise functionality of CoAP <xref target="RFC79
59" format="default"/>.</t>
<t>A straightforward mitigation of mixing up blocks from different messa
ges is to
use unique identifiers for different message bodies, which would provide
equivalent
protection to the case where the complete body fits into a single payload
. The ETag
option <xref target="RFC7252" format="default"/>, set by the CoAP server,
identifies a response body fragmented using the Block2 option.</t>
</section> </section>
<section anchor="the-request-tag-option" numbered="true" toc="default"> <section anchor="the-request-tag-option" numbered="true" toc="default">
<name>The Request-Tag Option</name> <name>The Request-Tag Option</name>
<t>This document defines the Request-Tag option for identifying request <t>This document defines the Request-Tag option for identifying request
bodies, similar to ETag, but ephemeral and set by the CoAP client. The Request-T bodies,
ag is intended for use as a short-lived identifier for keeping apart distinct bl similar to ETag, but ephemeral and set by the CoAP client. The Request-Ta
ock-wise request operations on one resource from one client, addressing the issu g is
e described in <xref target="body-int" format="default"/>. It enables the receiv intended for use as a short-lived identifier for keeping apart distinct b
ing server to reliably assemble request payloads (blocks) to their message bodie lock-wise
s, and, if it chooses to support it, to reliably process simultaneous block-wise request operations on one resource from one client, addressing the issue
request operations on a single resource. The requests must be integrity protect described
ed if they should protect against interchange of blocks between different messag in <xref target="body-int" format="default"/>. It enables the receiving s
e bodies. The Request-Tag option is only used in requests that carry the Block1 erver to
option, and in Block2 requests following these.</t> reliably assemble request payloads (blocks) to their message bodies and,
<t>In essence, it is an implementation of the "proxy-safe elective optio if it
n" used just to "vary the cache key" as suggested in <xref target="RFC7959" form chooses to support it, to reliably process simultaneous block-wise reques
at="default"/> Section 2.4.</t> t
operations on a single resource. The requests must be integrity protected
if they
should protect against interchange of blocks between different message bo
dies. The
Request-Tag option is mainly used in requests that carry the Block1 optio
n and in
Block2 requests following these.</t>
<t>In essence, it is an implementation of the "proxy-safe elective optio
n" used
just to "vary the cache key", as suggested in <xref target="RFC7959"
sectionFormat="comma" section="2.4"/>.</t>
<section anchor="req-tag-format" numbered="true" toc="default"> <section anchor="req-tag-format" numbered="true" toc="default">
<name>Request-Tag Option Format</name> <name>Request-Tag Option Format</name>
<t>The Request-Tag option is not critical, is safe to forward, repeata <t>The Request-Tag option is elective, safe to forward, repeatable, an
ble, and part of the cache key, see <xref target="req-tag-table" format="default d
"/>, which extends Table 4 of <xref target="RFC7252" format="default"/>).</t> part of the cache key (see <xref target="req-tag-table" format="default
<figure anchor="req-tag-table"> "/>, which
extends Table 4 of <xref target="RFC7252" format="default"/>).</t>
<table anchor="req-tag-table" align="left">
<name>Request-Tag Option Summary</name> <name>Request-Tag Option Summary</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <thead>
+--------+---+---+---+---+-------------+--------+------+---------+ <tr>
| No. | C | U | N | R | Name | Format | Len. | Default | <th>No.</th>
+--------+---+---+---+---+-------------+--------+------+---------+ <th>C</th>
| TBD292 | | | | x | Request-Tag | opaque | 0-8 | (none) | <th>U</th>
+--------+---+---+---+---+-------------+--------+------+---------+ <th>N</th>
<th>R</th>
<th>Name</th>
<th>Format</th>
<th>Length</th>
<th>Default</th>
</tr>
</thead>
<tbody>
<tr>
<td>292</td>
<td></td>
<td></td>
<td></td>
<td>x</td>
<td>Request-Tag</td>
<td>opaque</td>
<td>0-8</td>
<td>(none)</td>
</tr>
</tbody>
</table>
<t>C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable</t>
<t>Request-Tag, like the Block options, is both a class E and a class
U option in
terms of OSCORE processing (see <xref target="RFC8613" sectionFormat="o
f"
section="4.1"/>). The Request-Tag <bcp14>MAY</bcp14> be an Inner or Out
er option.
It influences the Inner or Outer block operations, respectively. The In
ner and
Outer values are therefore independent of each other. The Inner option
is
encrypted and integrity protected between the client and server, and it
provides
message
body identification in case of end-to-end fragmentation of requests. Th
e Outer
option is visible to proxies and labels message bodies in case of hop-b
y-hop
fragmentation of requests.</t>
<t>The Request-Tag option is only used in the request messages of bloc
k-wise
operations.</t>
C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable <t>The Request-Tag mechanism can be applied independently on the server
]]></artwork> and
</figure> client sides of CoAP-to-CoAP proxies, as are the Block options. However
<t>Request-Tag, like the block options, is both a class E and a class , given it
U option in terms of OSCORE processing (see Section 4.1 of <xref target="RFC8613 is safe to forward, a proxy is free to just forward it when processing
" format="default"/>): The Request-Tag MAY be an Inner or Outer option. It influ an
ences the Inner or Outer block operation, respectively. The Inner and Outer valu operation.
es are therefore independent of each other. The Inner option is encrypted and in CoAP-to-HTTP proxies and HTTP-to-CoAP proxies can use Request-Tag on th
tegrity protected between client and server, and provides message body identific eir CoAP
ation in case of end-to-end fragmentation of requests. The Outer option is visib sides; it is not applicable to HTTP requests.</t>
le to proxies and labels message bodies in case of hop-by-hop fragmentation of r
equests.</t>
<t>The Request-Tag option is only used in the request messages of bloc
k-wise operations.</t>
<t>The Request-Tag mechanism can be applied independently on the serve
r and client sides of CoAP-to-CoAP proxies as are the block options,
though given it is safe to forward, a proxy is free to just forward it when proc
essing an operation.
CoAP-to-HTTP proxies and HTTP-to-CoAP proxies can use Request-Tag on their CoAP
sides;
it is not applicable to HTTP requests.</t>
</section> </section>
</section> </section>
<section anchor="request-tag-processing" numbered="true" toc="default"> <section anchor="request-tag-processing" numbered="true" toc="default">
<name>Request-Tag Processing by Servers</name> <name>Request-Tag Processing by Servers</name>
<t>The Request-Tag option does not require any particular processing on <t>The Request-Tag option does not require any particular processing on t
the server side he server
outside of the processing already necessary for any unknown elective proxy-safe side outside of the processing already necessary for any unknown elective
cache-key option: proxy-safe cache-key option. The option varies the properties that distin
The option varies the properties that distinguish block-wise operations guish
(which includes all options except elective NoCacheKey and except Block1/2), block-wise operations (which includes all options except Block1, Block2,
and thus the server cannot treat messages with a different list of Request-Tag o and all
ptions as belonging to the same operation. operations that are elective NoCacheKey). Thus, the server cannot treat m
<!-- not speaking of "matchable" here as that working definition explicitly excl essages
udes Request-Tag to make the rest of the document easier to read --> with a different list of Request-Tag options as belonging to the same ope
ration.
</t> </t>
<t>To keep utilizing the cache, <t>To keep utilizing the cache, a server (including proxies) <bcp14>MAY<
a server (including proxies) MAY discard the Request-Tag option /bcp14>
from an assembled block-wise request when consulting its cache, discard the Request-Tag option from an assembled block-wise request when
as the option relates to the operation-on-the-wire and not its semantics. consulting
For example, a FETCH request with the same body as an older one can be served fr its cache, as the option relates to the operation on the wire and not its
om the cache if the older's Max-Age has not expired yet, semantics.
even if the second operation uses a Request-Tag and the first did not. For example, a FETCH request with the same body as an older one can be se
(This is similar to the situation about ETag in that it is formally part of the rved from
cache key, the cache if the older's Max-Age has not expired yet, even if the second
but implementations that are aware of its meaning can cache more efficiently, operation
see <xref target="RFC7252" format="default"/> Section 5.4.2).</t> uses a Request-Tag and the first did not. (This is similar to the situati
<t>A server receiving a Request-Tag MUST treat it as opaque and make no on about
assumptions about its content or structure.</t> ETag in that it is formally part of the cache key, but implementations th
<t>Two messages carrying the same Request-Tag is a necessary but not suf at are
ficient condition for being part of the same operation. aware of its meaning can cache more efficiently (see <xref target="RFC725
For one, a server may still treat them as independent messages when it sends 2.0 2"
1/2.04 responses for every block. sectionFormat="comma" section="5.4.2"/>).</t>
Also, a client that lost interest in an old operation but wants to start over ca <t>A server receiving a Request-Tag <bcp14>MUST</bcp14> treat it as opaq
n overwrite the server's old state with a new initial (num=0) Block1 request and ue and make
the same Request-Tag under some circumstances. Likewise, that results in the ne no assumptions about its content or structure.</t>
w message not being part of the old operation.</t>
<t>As it has always been, <t>Two messages carrying the same Request-Tag is a necessary but not suff
a server that can only serve a limited number of block-wise operations at the sa icient
me time condition for being part of the same operation. For one, a server may sti
can delay the start of the operation by replying with 5.03 (Service unavailable) ll treat
and a Max-Age indicating how long it expects the existing operation to go on, them as independent messages when it sends 2.01 (Created) and 2.04 (Chang
or it can forget about the state established with the older operation and respon ed)
d with 4.08 (Request Entity Incomplete) to later blocks on the first operation.< responses for every block.
/t> Also, a client that lost interest in an old operation but wants to start
over can
overwrite the server's old state with a new initial (num=0) Block1 reques
t and the
same Request-Tag under some circumstances. Likewise, that results in the
new
message not being part of the old operation.</t>
<t>As it has always been, a server that can only serve a limited number
of
block-wise operations at the same time can delay the start of the operati
on by
replying with 5.03 (Service Unavailable) and a Max-Age indicating how lon
g it
expects the existing operation to go on, or it can forget about the state
established with the older operation and respond with 4.08 (Request Entit
y
Incomplete) to later blocks on the first operation.</t>
</section> </section>
<section anchor="setting-the-request-tag" numbered="true" toc="default"> <section anchor="setting-the-request-tag" numbered="true" toc="default">
<name>Setting the Request-Tag</name> <name>Setting the Request-Tag</name>
<t>For each separate block-wise request operation, the client can choose <t>For each separate block-wise request operation, the client can choose
a Request-Tag value, or choose not to set a Request-Tag. a
It needs to be set to the same value (or unset) in all messages belonging to the Request-Tag value or choose not to set a Request-Tag. It needs to be set
same operation, to the
as otherwise they are treated as separate operations by the server.</t> same value (or unset) in all messages belonging to the same operation; ot
<t>Starting a request operation matchable to a herwise,
previous operation and even using the same Request-Tag value is called request t they are treated as separate operations by the server.</t>
ag recycling. <t>Starting a request operation matchable to a previous operation and ev
The absence of a Request-Tag option is viewed as a value distinct from all value en using
s with a single Request-Tag option set; the same Request-Tag value is called "request tag recycling". The absence
starting a request operation matchable to a previous operation where neither has of a
a Request-Tag option Request-Tag option is viewed as a value distinct from all values with a s
therefore constitutes request tag recycling just as well ingle
(also called "recycling the absent option").</t> Request-Tag option set; starting a request operation matchable to a previ
<t>Clients that use Request-Tag for a particular purpose (like in <xref ous
target="req-tag-applications" format="default"/>) MUST NOT recycle a request tag operation where neither has a Request-Tag option therefore constitutes re
unless the first operation has concluded. quest tag
What constitutes a concluded operation depends on the purpose, and is defined ac recycling just as well (also called "recycling the absent option").</t>
cordingly; see examples in <xref target="req-tag-applications" format="default"/ <t>Clients that use Request-Tag for a particular purpose (like in <xref
>.</t> target="req-tag-applications" format="default"/>) <bcp14>MUST NOT</bcp14>
<t>When Block1 and Block2 are combined in an operation, recycle a
the Request-Tag of the Block1 phase is set in the Block2 phase as well request tag unless the first operation has concluded. What constitutes a
for otherwise the request would have a different set of options concluded
and would not be recognized any more.</t> operation depends on the purpose and is defined accordingly; see examples
<t>Clients are encouraged to generate compact messages. This means sendi in <xref
ng messages without Request-Tag options whenever possible, and using short value target="req-tag-applications" format="default"/>.</t>
s when the absent option cannot be recycled.</t> <t>When Block1 and Block2 are combined in an operation, the Request-Tag
<t>Note that Request-Tag options can be present in request messages that of the
carry no Block option Block1 phase is set in the Block2 phase as well; otherwise, the request w
(for example, because a Request-Tag unaware proxy reassembled them), ould
and MUST be ignored in those.</t> have a different set of options and would not be recognized any more.</t>
<t>The Request-Tag option MUST NOT be present in response messages.</t> <t>Clients are encouraged to generate compact messages. This means sendi
ng messages
without Request-Tag options whenever possible and using short values when
the
absent option cannot be recycled.</t>
<t>Note that Request-Tag options can be present in request messages that
carry no
Block options (for example, because a proxy unaware of Request-Tag reasse
mbled them).</t>
<t>The Request-Tag option <bcp14>MUST NOT</bcp14> be present in response
messages.</t>
</section> </section>
<section anchor="req-tag-applications" numbered="true" toc="default"> <section anchor="req-tag-applications" numbered="true" toc="default">
<name>Applications of the Request-Tag Option</name> <name>Applications of the Request-Tag Option</name>
<section anchor="body-integrity" numbered="true" toc="default"> <section anchor="body-integrity" numbered="true" toc="default">
<name>Body Integrity Based on Payload Integrity</name> <name>Body Integrity Based on Payload Integrity</name>
<t>When a client fragments a request body into multiple message payloa <t>When a client fragments a request body into multiple message payloa
ds, even if the individual messages are integrity protected, it is still possibl ds, even if
e for an attacker to maliciously replace a later operation's blocks with an earl the individual messages are integrity protected, it is still possible f
ier operation's blocks (see Section 2.5 of <xref target="I-D.mattsson-core-coap- or an
attacks" format="default"/>). Therefore, the integrity protection of each block attacker to maliciously replace a later operation's blocks with an earl
does not extend to the operation's request body.</t> ier
operation's blocks (see <xref target="I-D.mattsson-core-coap-attacks"
sectionFormat="of" section="2.5"/>). Therefore, the integrity protectio
n of each
block does not extend to the operation's request body.</t>
<t>In order to gain that protection, use the Request-Tag mechanism as follows:</t> <t>In order to gain that protection, use the Request-Tag mechanism as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The individual exchanges MUST be integrity protected end-to-end <li>The individual exchanges <bcp14>MUST</bcp14> be integrity protec
between client and server.</li> ted
end to end between the client and server.</li>
<li> <li>
<t>The client MUST NOT recycle a request tag in a new operation un <t>The client <bcp14>MUST NOT</bcp14> recycle a request tag in a n
less the <!-- or "all", but by this rule there can only be one --> previous oper ew
ation matchable to the new one has concluded. </t> operation unless the previous operation matchable to the new one ha
<t> s concluded. </t>
If any future security mechanisms allow a block-wise transfer to continue
after an endpoint's details (like the IP address) have changed, then <t>If any future security mechanisms allow a block-wise transfer t
the client MUST consider messages matchable if they were sent to <em>any</em> en o continue
dpoint address using the new operation's security context.</t> after an endpoint's details (like the IP address) have changed, the
n
the client <bcp14>MUST</bcp14> consider messages matchable if they
were sent
to any endpoint address using the new operation's security
context.</t>
</li> </li>
<li> <li>
<t>The client MUST NOT regard a block-wise request operation as co <t>The client <bcp14>MUST NOT</bcp14> regard a block-wise request
ncluded unless all of the messages the client has sent in the operation would be operation
regarded as invalid by the server if they were replayed. </t> as concluded unless all of the messages the client has sent in the
<t> operation
When security services are provided by OSCORE, these confirmations typically res would be regarded as invalid by the server if they were replayed.</
ult either from the client receiving an OSCORE response message matching the req t>
uest (an empty ACK is insufficient), or because the message's sequence number is <t>When security services are provided by OSCORE, these confirmati
old enough to be outside the server's receive window. </t> ons
<t> typically result either from the client receiving an OSCORE respons
When security services are provided by DTLS, this can only be confirmed if there e message
was no CoAP retransmission of the request, the request was responded to, and th matching the request (an empty Acknowledgement (ACK) is insufficien
e server uses replay protection.</t> t) or
because the message's
sequence number is old enough to be outside the server's receive wi
ndow.</t>
<t>When security services are provided by DTLS, this can only be c
onfirmed if
there was no CoAP retransmission of the request, the request was re
sponded
to, and the server uses replay protection.</t>
</li> </li>
</ul> </ul>
<!-- pending see thread "ERT and OSCORE" --> <t>Authors of other documents (e.g., applications of <xref target="RFC8
<t>Authors of other documents (e.g. applications of <xref target="RFC8613" forma 613"
t="default"/>) are invited to mandate this subsection's behavior for clients tha format="default"/>) are invited to mandate this subsection's behavior f
t execute block-wise interactions over secured transports. In this way, the serv or clients
er can rely on a conforming client to set the Request-Tag option when required, that execute block-wise interactions over secured transports. In this w
and thereby have confidence in the integrity of the assembled body.</t> ay, the
<t>Note that this mechanism is implicitly implemented when the securit server can rely on a conforming client to set the Request-Tag option wh
y layer guarantees ordered delivery (e.g. CoAP over TLS <xref target="RFC8323" f en
ormat="default"/>). This is because with each message, any earlier message canno required and thereby have confidence in the integrity of the assembled
t be replayed any more, so the client never needs to set the Request-Tag option body.</t>
unless it wants to perform concurrent operations.</t> <t>Note that this mechanism is implicitly implemented when the securit
<t>Body integrity only makes sense in applications that have stateful y layer
block-wise transfers. guarantees ordered delivery (e.g., CoAP over TLS <xref target="RFC8323"
On applications where all the state is in the application format="default"/>). This is because, with each message, any earlier me
(e.g. because rather than POSTing a large representation to a collection in a st ssage
ateful block-wise transfer, cannot be replayed any more, so the client never needs to set the Reque
a collection item is created first, then written to once and available when writ st-Tag
ten completely), option unless it wants to perform concurrent operations.</t>
clients need not concern themselves with body integrity and thus the Request-Tag <t>Body integrity only makes sense in applications that have stateful
.</t> block-wise
<t>Body integrity is largely independent from replay protection: transfers. On applications where all the state is in the application (e
When no replay protection is available (it is optional in DTLS), .g.,
a full block-wise operation may be replayed, because rather than POSTing a large representation to a collection in a
but by adhering to the above, no operations will be mixed up. stateful
<!-- the other direction was covered already, see core-coap-attacks --> block-wise transfer, a collection item is created first, then written t
The only link between body integrity and replay protection is that without repla o once and
y protection, recycling is not possible.</t> available when written completely), clients need not concern themselves
with body
integrity and thus the Request-Tag.</t>
<t>Body integrity is largely independent from replay protection. When
no replay
protection is available (it is optional in DTLS), a full block-wise ope
ration may
be replayed, but, by adhering to the above, no operations will be mixed
up.
The only link between body integrity and replay protection is that, wit
hout replay
protection, recycling is not possible.</t>
</section> </section>
<section anchor="multiple-concurrent-block-wise-operations" numbered="tr <section anchor="multiple-concurrent-block-wise-operations" numbered="tr
ue" toc="default"> ue"
<name>Multiple Concurrent Block-wise Operations</name> toc="default">
<t>CoAP clients, especially CoAP proxies, may initiate a block-wise re <name>Multiple Concurrent Block-Wise Operations</name>
quest operation to a resource, to which a previous one is already in progress, w <t>CoAP clients, especially CoAP proxies, may initiate a block-wise re
hich the new request should not cancel. quest
A CoAP proxy would be in such a situation when it forwards operations with the s operation to a resource, to which a previous one is already in progress
ame cache-key options but possibly different payloads.</t> , which
<t>For those cases, Request-Tag is the proxy-safe elective option sugg the new request should not cancel. A CoAP proxy would be in such a situ
ested in <xref target="RFC7959" format="default"/> Section 2.4 last paragraph.</ ation when
t> it forwards operations with the same cache-key options but possibly dif
<t>When initializing a new block-wise operation, a client has to look ferent
at other active operations:</t> payloads.</t>
<t>For those cases, Request-Tag is the proxy-safe elective option sugg
ested in
the last paragraph of
<xref target="RFC7959" sectionFormat="of" section="2.4"/>.</t>
<t>When initializing a new block-wise operation, a client has to look
at other
active operations:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If any of them is matchable to the new one, and the client neith <li>If any of them is matchable to the new one, and the client neith
er wants to cancel the old one nor postpone the new one, er wants to
it can pick a Request-Tag value (including the absent option) that is not in use cancel the old one nor postpone the new one, it can pick a Request-Ta
by the other matchable operations for the new operation.</li> g value
<li>Otherwise, it can start the new operation without setting the Re (including the absent option) that is not in use by the other matchab
quest-Tag option on it.</li> le
operations for the new operation.</li>
<li>Otherwise, it can start the new operation without setting the Re
quest-Tag
option on it.</li>
</ul> </ul>
</section> </section>
<section anchor="simpleproxy" numbered="true" toc="default"> <section anchor="simpleproxy" numbered="true" toc="default">
<name>Simplified Block-Wise Handling for Constrained Proxies</name> <name>Simplified Block-Wise Handling for Constrained Proxies</name>
<t>The Block options were defined to be unsafe to forward <t>The Block options were defined to be unsafe to forward because a pr
because a proxy that would forward blocks as plain messages would risk mixing up oxy that
clients' requests.</t> would forward blocks as plain messages would risk mixing up clients' re
<t>In some cases, quests.</t>
for example when forwarding block-wise request operations, <t>In some cases, for example, when forwarding block-wise request oper
appending a Request-Tag value unique to the client ations,
can satisfy the requirements on the proxy that come from the presence of a block appending a Request-Tag value unique to the client can satisfy the requ
option.</t> irements
<t>This is particularly useful to proxies that strive for stateless op on the proxy that come from the presence of a Block option.</t>
eration <t>This is particularly useful to proxies that strive for stateless op
as described in <xref target="RFC8974" format="default"/> Section 4.</t> erations,
<t>The precise classification of cases in which such a Request-Tag opt as described in <xref target="RFC8974" sectionFormat="comma" section="4
ion is sufficient "/>.</t>
is not trivial, especially when both request and response body are fragmented, <t>The precise classification of cases in which such a Request-Tag opt
and out of scope for this document.</t> ion is
sufficient is not trivial, especially when both request and response bo
dy are
fragmented, and is out of scope for this document.</t>
</section> </section>
</section> </section>
<section anchor="rationale-for-the-option-properties" numbered="true" toc= "default"> <section anchor="rationale-for-the-option-properties" numbered="true" toc= "default">
<name>Rationale for the Option Properties</name> <name>Rationale for the Option Properties</name>
<t>The Request-Tag option can be elective, because to servers unaware of
the Request-Tag option, operations with differing request tags will not be matc <t>The Request-Tag option can be elective, because to servers unaware of
hable.</t> the
<t>The Request-Tag option can be safe to forward but part of the cache k Request-Tag option, operations with differing request tags will not be
ey, because proxies unaware of the Request-Tag option will consider operations w matchable.</t>
ith differing request tags unmatchable but can still forward them.</t> <t>The Request-Tag option can be safe to forward but part of the cache k
<t>The Request-Tag option is repeatable ey, because
because this easily allows several cascaded stateless proxies to each put in an proxies unaware of the Request-Tag option will consider operations with d
origin address. iffering
They can perform the steps of <xref target="simpleproxy" format="default"/> with request tags unmatchable but can still forward them.</t>
out the need to create an option value <t>The Request-Tag option is repeatable because this easily allows sever
that is the concatenation of the received option and their own value, al cascaded
and can simply add a new Request-Tag option unconditionally.</t> stateless proxies to each put in an origin address. They can perform the
<t>In draft versions of this document, the Request-Tag option used to be steps of
critical and unsafe to forward. <xref target="simpleproxy" format="default"/> without the need to create
That design was based on an erroneous understanding of which blocks could be com an option
posed according to <xref target="RFC7959" format="default"/>.</t> value that is the concatenation of the received option and their own valu
e
and can simply add a new Request-Tag option unconditionally.</t>
<t>In draft versions of this document, the Request-Tag option used to be
critical
and unsafe to forward. That design was based on an erroneous understandin
g of which
blocks could be composed according to <xref target="RFC7959" format="defa
ult"/>.</t>
</section> </section>
<section anchor="rationale-for-introducing-the-option" numbered="true" toc ="default"> <section anchor="rationale-for-introducing-the-option" numbered="true" toc ="default">
<name>Rationale for Introducing the Option</name> <name>Rationale for Introducing the Option</name>
<t>An alternative that was considered to the Request-Tag option <t>An alternative that was considered to the Request-Tag option for copi
for coping with the problem of fragmented message body integrity (<xref target=" ng with the
body-integrity" format="default"/>) problem of fragmented message body integrity (<xref target="body-integrit
was to update <xref target="RFC7959" format="default"/> to say that blocks could y"
only be assembled format="default"/>) was to update <xref target="RFC7959" format="default"
if their fragments' order corresponded to the sequence numbers.</t> /> to say
<t>That approach would have been difficult to roll out reliably on DTLS that blocks could only be assembled if their fragments' order corresponde
where many implementations do not expose sequence numbers, d to the
and would still not prevent attacks like in <xref target="I-D.mattsson-core-coap sequence numbers.</t>
-attacks" format="default"/> Section 2.5.2.</t> <t>That approach would have been difficult to roll out reliably on DTLS,
where many implementations do not expose sequence numbers, and would stil
l not
prevent attacks like in <xref target="I-D.mattsson-core-coap-attacks"
sectionFormat="of" section="2.5.2"/>.</t>
</section> </section>
<section anchor="etag" numbered="true" toc="default"> <section anchor="etag" numbered="true" toc="default">
<name>Block2 / ETag Processing</name> <name>Block2 and ETag Processing</name>
<t>The same security properties as in <xref target="body-integrity" form <t>The same security properties as in <xref target="body-integrity"
at="default"/> can be obtained for block-wise response operations. format="default"/> can be obtained for block-wise response operations. Th
The threat model here does not depend on an attacker: e threat
a client can construct a wrong representation model here does not depend on an attacker; a client can construct a wrong
by assembling it from blocks from different resource states. representation by assembling it from blocks from different resource state
That can happen when a resource is modified during a transfer, s. That
or when some blocks are still valid in the client's cache.</t> can happen when a resource is modified during a transfer or when some blo
<t>Rules stating that response body reassembly is conditional on matchin cks are
g ETag values are already in place from Section 2.4 of <xref target="RFC7959" fo still valid in the client's cache.</t>
rmat="default"/>.</t> <t>Rules stating that response body reassembly is conditional on matchin
<t>To gain equivalent protection to <xref target="body-integrity" format g ETag
="default"/>, values are already in place from <xref target="RFC7959" sectionFormat="of
a server MUST use the Block2 option in conjunction with the ETag option (<xref t "
arget="RFC7252" format="default"/>, Section 5.10.6), section="2.4"/>.</t>
and MUST NOT use the same ETag value for different representations of a resource <t>To gain protection equivalent to that described in <xref target="body-
.</t> integrity"
format="default"/>, a server <bcp14>MUST</bcp14> use the Block2 option in
conjunction with the ETag option (<xref target="RFC7252" sectionFormat="c
omma"
section="5.10.6"/>) and <bcp14>MUST NOT</bcp14> use the same ETag value f
or
different representations of a resource.</t>
</section> </section>
</section> </section>
<section anchor="token" numbered="true" toc="default"> <section anchor="token" numbered="true" toc="default">
<name>Token Processing for Secure Request-Response Binding</name> <name>Token Processing for Secure Request-Response Binding</name>
<section anchor="req-resp-bind" numbered="true" toc="default"> <section anchor="req-resp-bind" numbered="true" toc="default">
<name>Request-Response Binding</name> <name>Request-Response Binding</name>
<t>A fundamental requirement of secure REST operations is that the clien <t>A fundamental requirement of secure REST operations is that the clien
t can bind a response to a particular request. If this is not ensured, a client t can bind
may erroneously associate the wrong response to a request. The wrong response ma a response to a particular request. If this is not ensured, a client may
y be an old response for the same resource or a response for a completely differ erroneously associate the wrong response to a request. The wrong response
ent resource (see e.g. Section 2.3 of <xref target="I-D.mattsson-core-coap-attac may be an
ks" format="default"/>). For example, a request for the alarm status "GET /statu old response for the same resource or a response for a completely differe
s" may be associated to a prior response "on", instead of the correct response " nt
off".</t> resource (e.g., see <xref target="I-D.mattsson-core-coap-attacks" section
<t>In HTTP/1.1, this type of binding is always assured by the ordered an Format="of"
d reliable delivery as well as mandating that the server sends responses in the section="2.3"/>). For example, a request for the alarm status "GET /statu
same order that the requests were received. The same is not true for CoAP where s" may be
the server (or an attacker) can return responses in any order and where there ca associated to a prior response "on", instead of the correct response "off
n be any number of responses to a request (see e.g. <xref target="RFC7641" forma ".</t>
t="default"/>). In CoAP, concurrent requests are differentiated by their Token. <t>In HTTP/1.1, this type of binding is always assured by the ordered an
Note that the CoAP Message ID cannot be used for this purpose since those are ty d reliable
pically different for REST request and corresponding response in case of "separa delivery, as well as mandating that the server sends responses in the sam
te response", see Section 2.2 of <xref target="RFC7252" format="default"/>.</t> e order
<t>CoAP <xref target="RFC7252" format="default"/> does not treat Token a that the requests were received. The same is not true for CoAP, where the
s a cryptographically important value and does not give stricter guidelines than server (or
that the Tokens currently "in use" SHOULD (not SHALL) be unique. If used with a an attacker) can return responses in any order and where there can be any
security protocol not providing bindings between requests and responses (e.g. D number of
TLS and TLS) Token reuse may result in situations where a client matches a respo responses to a request (e.g., see <xref target="RFC7641" format="default"
nse to the wrong request. Note that mismatches can also happen for other reasons />). In
than a malicious attacker, e.g. delayed delivery or a server sending notificati CoAP, concurrent requests are differentiated by their Token. Note that th
ons to an uninterested client.</t> e CoAP
<t>A straightforward mitigation is to mandate clients to not reuse Token Message ID cannot be used for this purpose since those are typically diff
s until the traffic keys have been replaced. The following section formalizes th erent for
at.</t> the REST request and corresponding response in case of "separate response
" (see
<xref target="RFC7252" sectionFormat="of" section="2.2"/>).</t>
<t>CoAP <xref target="RFC7252" format="default"/> does not treat the Tok
en as a
cryptographically important value and does not give stricter guidelines t
han that
the Tokens currently "in use" <bcp14>SHOULD</bcp14> (not <bcp14>SHALL</bc
p14>) be
unique. If used with a security protocol not providing bindings between r
equests
and responses (e.g., DTLS and TLS), Token reuse may result in situations
where a
client matches a response to the wrong request. Note that mismatches can
also
happen for other reasons than a malicious attacker, e.g., delayed deliver
y or a
server sending notifications to an uninterested client.</t>
<t>A straightforward mitigation is to mandate clients to not reuse Token
s until the
traffic keys have been replaced. The following section formalizes that.</
t>
</section> </section>
<section anchor="updated-token-processing-requirements-for-clients" number <section anchor="updated-token-processing-requirements-for-clients" number
ed="true" toc="default"> ed="true"
toc="default">
<name>Updated Token Processing Requirements for Clients</name> <name>Updated Token Processing Requirements for Clients</name>
<t>As described in <xref target="req-resp-bind" format="default"/>, the <t>As described in <xref target="req-resp-bind" format="default"/>, the
client must be able to verify that a response corresponds to a particular reques client must
t. This section updates the Token processing requirements for clients in <xref t be able to verify that a response corresponds to a particular request. Th
arget="RFC7252" format="default"/> to always assure a cryptographically secure b is section
inding of responses to requests for secure REST operations like "coaps". The Tok updates the Token processing requirements for clients in <xref target="RF
en processing for servers is not updated. Token processing in Section 5.3.1 of < C7252"
xref target="RFC7252" format="default"/> is updated by adding the following text format="default"/> to always assure a cryptographically secure binding of
:</t> responses
<t>When CoAP is used with a security protocol not providing bindings bet to requests for secure REST operations like "coaps". The Token processing
ween requests and responses, the Tokens have cryptographic importance. The clien for
t MUST make sure that Tokens are not used in a way so that responses risk being servers is not updated. Token processing in <xref target="RFC7252"
associated with the wrong request.</t> sectionFormat="of" section="5.3.1"/> is updated by adding the following t
<t>One easy way to accomplish this is to implement the Token (or part of ext:</t>
the Token) as a sequence number starting at zero for each new or rekeyed secure <blockquote>
connection. This approach SHOULD be followed.</t> <t>When CoAP is used with a security protocol not providing bindings bet
ween
requests and responses, the Tokens have cryptographic importance. The cli
ent
<bcp14>MUST</bcp14> make sure that Tokens are not used in a way so that r
esponses
risk being associated with the wrong request.</t>
<t>One easy way to accomplish this is to implement the Token (or part of
the Token)
as a sequence number, starting at zero for each new or rekeyed secure con
nection.
This approach <bcp14>SHOULD</bcp14> be followed.</t>
</blockquote>
</section> </section>
</section> </section>
<section anchor="sec-cons" numbered="true" toc="default"> <section anchor="sec-cons" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The freshness assertion of the Echo option comes from the client reprod <t>The freshness assertion of the Echo option comes from the client reprod
ucing the same value of the Echo option in a request as it received in a previou ucing the
s response. If the Echo value is a large random number then there is a high prob same value of the Echo option in a request as it received in a previous re
ability that the request is generated after having seen the response. If the Ech sponse. If
o value of the response can be guessed, e.g. if based on a small random number o the Echo option value is a large random number, then there is a high proba
r a counter (see <xref target="echo-state" format="default"/>), then it is possi bility
ble to compose a request with the right Echo value ahead of time. Using guessabl that the request is generated after having seen the response. If the Echo
e Echo values is only permissible in a narrow set of cases described in <xref ta option
rget="source-of-truth" format="default"/>. Echo values MUST be set by the CoAP s value of the response can be guessed, e.g., if based on a small random num
erver such that the risk associated with unintended reuse can be managed.</t> ber or a
<t>If uniqueness of the Echo value is based on randomness, then the availa counter (see <xref target="echo-state" format="default"/>), then it is pos
bility of a secure pseudorandom number generator and truly random seeds are esse sible to
ntial for the security of the Echo option. If no true random number generator is compose a request with the right Echo option value ahead of time. Using gu
available, a truly random seed must be provided from an external source. As eac essable
h pseudorandom number must only be used once, an implementation needs to get a n Echo option values is only permissible in a narrow set of cases described
ew truly random seed after reboot, or continuously store state in nonvolatile me in <xref
mory. See (<xref target="RFC8613" format="default"/>, Appendix B.1.1) for issues target="source-of-truth" format="default"/>. Echo option values <bcp14>MUS
and approaches for writing to nonvolatile memory.</t> T</bcp14>
<t>A single active Echo value with 64 (pseudo-)random bits gives the same be set by the CoAP server such that the risk associated with unintended re
theoretical security level as a 64-bit MAC (as used in e.g. AES_128_CCM_8). If a use can be
random unique Echo value is intended, the Echo option value SHOULD contain 64 ( managed.</t>
pseudo-)random bits that are not predictable for any other party than the server <t>If uniqueness of the Echo option value is based on randomness, then the
. A server MAY use different security levels for different uses cases (client al availability of a
iveness, request freshness, state synchronization, network address reachability, secure pseudorandom number generator and truly random seeds are essential
etc.).</t> for the
<t>The security provided by the Echo and Request-Tag options depends on th security of the Echo option. If no true random number generator is availab
e security protocol used. CoAP and HTTP proxies require (D)TLS to be terminated le, a truly
at the proxies. The proxies are therefore able to manipulate, inject, delete, or random seed must be provided from an external source. As each pseudorandom
reorder options or packets. The security claims in such architectures only hold number
under the assumption that all intermediaries are fully trusted and have not bee must only be used once, an implementation needs to get a new truly random
n compromised.</t> seed after
<t>Echo values without the protection of randomness or a MAC are limited t reboot or continuously store the state in nonvolatile memory. See <xref
o cases when the client is the trusted source of all derived properties (as per target="RFC8613" sectionFormat="comma" section="B.1.1"/> for issues and ap
<xref target="source-of-truth" format="default"/>). Using them needs per-applica proaches for
tion consideration of both the impact of a malicious client and of implementatio writing to nonvolatile memory.</t>
n errors in clients. These Echo values are the only legitimate case for Echo val <t>A single active Echo option value with 64 (pseudo)random bits gives the
ues shorter than four bytes, which are not necessarily secret. They MUST NOT be same theoretical
used unless the request Echo values are integrity protected as per <xref target= security level as a 64-bit MAC (as used in, e.g., AES_128_CCM_8). If a ran
"echo-proc" format="default"/>.</t> dom unique
<t>Servers SHOULD use a monotonic clock to generate timestamps and compute Echo option value is intended, the Echo option value <bcp14>SHOULD</bcp14>
round-trip times. Use of non-monotonic clocks is not secure as the server will contain 64
accept expired Echo option values if the clock is moved backward. The server wil (pseudo)random bits that are not predictable for any other party than the
l also reject fresh Echo option values if the clock is moved forward. Non-monoto server. A
nic clocks MAY be used as long as they have deviations that are acceptable given server <bcp14>MAY</bcp14> use different security levels for different use
the freshness requirements. If the deviations from a monotonic clock are known, cases
it may be possible to adjust the threshold accordingly.</t> (client aliveness, request freshness, state synchronization, network addre
<t>An attacker may be able to affect the server's system time in various w ss
ays such as setting up a fake NTP server or broadcasting false time signals to r reachability, etc.).</t>
adio-controlled clocks.</t> <t>The security provided by the Echo and Request-Tag options depends on th
<t>For the purpose of generating timestamps for Echo a server MAY set a ti e security
mer at reboot and use the time since reboot, choosing the granularity such that protocol used. CoAP and HTTP proxies require (D)TLS to be terminated at th
different requests arrive at different times. Servers MAY intermittently reset e proxies.
the timer and MAY generate a random offset applied to all timestamps. When reset The proxies are therefore able to manipulate, inject, delete, or reorder o
ting the timer, the server MUST reject all Echo values that were created before ptions or
the reset.</t> packets. The security claims in such architectures only hold under the ass
<t>Servers that use the List of Cached Random Values and Timestamps method umption
described in <xref target="echo-state" format="default"/> may be vulnerable to that all intermediaries are fully trusted and have not been compromised.</
resource exhaustion attacks. One way to minimize state is to use the Integrity P t>
rotected Timestamp method described in <xref target="echo-state" format="default
"/>.</t> <t>Echo option values without the protection of randomness or a MAC are li
mited to cases
when the client is the trusted source of all derived properties (as per <x
ref
target="source-of-truth" format="default"/>). Using them needs per-applica
tion
consideration of both the impact of a malicious client and of implementati
on errors
in clients. These Echo option values are the only legitimate case for Echo
option
values shorter
than four bytes, which are not necessarily secret. They <bcp14>MUST NOT</b
cp14> be
used unless the Echo option values in the request are integrity protected,
as per <xref
target="echo-proc" format="default"/>.</t>
<t>Servers <bcp14>SHOULD</bcp14> use a monotonic clock to generate timesta
mps and
compute round-trip times. Use of non-monotonic clocks is not secure, as th
e server
will accept expired Echo option values if the clock is moved backward. The
server
will also reject fresh Echo option values if the clock is moved forward.
Non-monotonic clocks <bcp14>MAY</bcp14> be used as long as they have devia
tions that
are acceptable given the freshness requirements. If the deviations from a
monotonic
clock are known, it may be possible to adjust the threshold accordingly.</
t>
<t>An attacker may be able to affect the server's system time in various w
ays, such as
setting up a fake NTP server or broadcasting false time signals to radio-c
ontrolled
clocks.</t>
<t>For the purpose of generating timestamps for the Echo option, a server
<bcp14>MAY</bcp14> set
a timer at reboot and use the time since reboot, choosing the granularity
such that
different requests arrive at different times. Servers <bcp14>MAY</bcp14>
intermittently reset the timer and <bcp14>MAY</bcp14> generate a random of
fset
applied to all timestamps. When resetting the timer, the server <bcp14>MUS
T</bcp14>
reject all Echo option values that were created before the reset.</t>
<t>Servers that use the "List of Cached Random Values and Timestamps" meth
od described
in <xref target="echo-state" format="default"/> may be vulnerable to resou
rce
exhaustion attacks. One way to minimize the state is to use the "Integrity
-Protected
Timestamp" method described in <xref target="echo-state" format="default"/
>.</t>
<section anchor="token-reuse" numbered="true" toc="default"> <section anchor="token-reuse" numbered="true" toc="default">
<name>Token reuse</name> <name>Token Reuse</name>
<t>Reusing Tokens in a way so that responses are guaranteed to not be as <t>Reusing Tokens in a way so that responses are guaranteed to not be as
sociated with the wrong request is not trivial: The server may process requests sociated
in any order, and send multiple responses to the same request. An attacker may b with the wrong request is not trivial. The server may process requests in
lock, delay, and reorder messages. The use of a sequence number is therefore rec any
ommended when CoAP is used with a security protocol that does not provide bindin order and send multiple responses to the same request. An attacker may bl
gs between requests and responses such as DTLS or TLS.</t> ock,
<t>For a generic response to a Confirmable request over DTLS, binding ca delay, and reorder messages. The use of a sequence number is therefore re
n only be claimed without out-of-band knowledge if</t> commended
<ul spacing="normal"> when CoAP is used with a security protocol that does not provide bindings
<li>the original request was never retransmitted,</li> between
<li>the response was piggybacked in an Acknowledgement message (as a C requests and responses, such as DTLS or TLS.</t>
onfirmable or Non-confirmable response may have been transmitted multiple times) <t>For a generic response to a Confirmable request over DTLS, binding ca
, and</li> n only be
<li>if observation was used, the same holds for the registration, all claimed without out-of-band knowledge if:</t>
re-registrations, and the cancellation.</li>
<ul spacing="normal">
<li>the original request was never retransmitted and</li>
<li>the response was piggybacked in an Acknowledgement message (as a C
onfirmable
or Non-confirmable response may have been transmitted multiple times).<
/li>
</ul> </ul>
<t>(In addition, for observations, any responses using that Token and a <t>If observation was used, the same holds for the registration, all
DTLS sequence number earlier than the cancellation Acknowledgement message need reregistrations, and the cancellation.</t>
to be discarded. This is typically not supported in DTLS implementations.)</t> <t>(In addition, for observations, any responses using that Token and a
<t>In some setups, Tokens can be reused without the above constraints, a DTLS
s a different component in the setup provides the associations:</t> sequence number earlier than the cancellation Acknowledgement message nee
d to be
discarded. This is typically not supported in DTLS implementations.)</t>
<t>In some setups, Tokens can be reused without the above constraints, a
s a
different component in the setup provides the associations:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>In CoAP over TLS, retransmissions are not handled by the CoAP laye <li>In CoAP over TLS, retransmissions are not handled by the CoAP laye
r and behaves like a replay window size of 1. When a client is sending TLS-prote r and
cted requests without Observe to a single server, the client can reuse a Token a behave like a replay window size of 1. When a client is sending TLS-pro
s soon as the previous response with that Token has been received.</li> tected
<li>Requests whose responses are cryptographically bound to the reques requests without Observe to a single server, the client can reuse a Tok
ts (like in OSCORE) can reuse Tokens indefinitely. en as soon
<!-- could be added but is probably not worth the lines of text * Requests whose as the previous response with that Token has been received.</li>
responses reflect all the data in the request that is varied over reuses of the <li>Requests whose responses are cryptographically bound to the reques
same token (for example, if a token is always used on a single path with the si ts (like in
ngle query parameter `?t=X` for various values of X, then the response needs to OSCORE) can reuse Tokens indefinitely.
contain X in a unique position) can share a token, provided the application does
not rely on the freshness of the responses, or sends different requests all the
time.
</li> </li>
</ul> </ul>
<t>In all other cases, a sequence number approach is RECOMMENDED as per <t>In all other cases, a sequence number approach is <bcp14>RECOMMENDED<
<xref target="token" format="default"/>.</t> /bcp14>, as
<t>Tokens that cannot be reused need to be handled appropriately. This c per <xref target="token" format="default"/>.</t>
ould be solved by increasing the Token as soon as the currently used Token canno <t>Tokens that cannot be reused need to be handled appropriately. This c
t be reused, or by keeping a list of all Tokens unsuitable for reuse.</t> ould be
<t>When the Token (or part of the Token) contains a sequence number, the solved by increasing the Token as soon as the currently used Token cannot
encoding of the sequence number has to be chosen in a way to avoid any collisio be
ns. This is especially true when the Token contains more information than just t reused or by keeping a list of all Tokens unsuitable for reuse.</t>
he sequence number, e.g. serialized state as in <xref target="RFC8974" format="d <t>When the Token (or part of the Token) contains a sequence number, the
efault"/>.</t> encoding
of the sequence number has to be chosen in a way to avoid any collisions.
This is
especially true when the Token contains more information than just the se
quence
number, e.g., the serialized state, as in <xref target="RFC8974"
format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="priv-cons" numbered="true" toc="default"> <section anchor="priv-cons" numbered="true" toc="default">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>Implementations SHOULD NOT put any privacy-sensitive information in the <t>Implementations <bcp14>SHOULD NOT</bcp14> put any privacy-sensitive inf
Echo or Request-Tag option values. Unencrypted timestamps could reveal informat ormation in
ion about the server such as location or time since reboot, or that the server w the Echo or Request-Tag option values. Unencrypted timestamps could reveal
ill accept expired certificates. Timestamps MAY be used if Echo is encrypted bet information about the server, such as location, time since reboot, or that
ween the client and the server, e.g. in the case of DTLS without proxies or when the
using OSCORE with an Inner Echo option.</t> server will accept expired certificates. Timestamps <bcp14>MAY</bcp14> be
<t>Like HTTP cookies, the Echo option could potentially be abused as a tra used if
cking mechanism that identifies a client across requests. This is especially tru the Echo option is encrypted between the client and the server, e.g., in t
e for preemptive Echo values. Servers MUST NOT use the Echo option to correlate he case of
requests for other purposes than freshness and reachability. Clients only send E DTLS without
cho values to the same server from which the values were received. Compared to H proxies or when using OSCORE with an Inner Echo option.</t>
TTP, CoAP clients are often authenticated and non-mobile, and servers can theref <t>Like HTTP cookies, the Echo option could potentially be abused as a tra
ore often correlate requests based on the security context, the client credentia cking
ls, or the network address. Especially when the Echo option increases a server's mechanism that identifies a client across requests. This is especially tru
ability to correlate requests, clients MAY discard all preemptive Echo values.< e for
/t> preemptive Echo option values. Servers <bcp14>MUST NOT</bcp14> use the Ech
<t>Publicly visible generated identifiers, o option to
even when opaque (as all defined in this document are), correlate requests for other purposes than freshness and reachability. Cli
can leak information as described in <xref target="I-D.irtf-pearg-numeric-ids-ge ents only
neration" format="default"/>. send Echo option values to the same server from which the values were rece
To avoid effects described there, the absent Request-Tag option should be recycl ived. Compared to
ed as much as possible. HTTP, CoAP clients are often authenticated and non-mobile, and servers can
(That is generally possible as long as a security mechanism is in place - even i therefore
n the case of OSCORE outer block-wise transfers, as the OSCORE option's variatio often correlate requests based on the security context, the client credent
n ensures that no matchable requests are created by different clients). ials, or
When an unprotected Echo option is used to demonstrate reachability, the network address. Especially when the Echo option increases a server's
the recommended mechanism of <xref target="echo-proc" format="default"/> keeps t ability to
he effects to a minimum.</t> correlate requests, clients <bcp14>MAY</bcp14> discard all preemptive Echo
option values.</t>
<t>Publicly visible generated identifiers, even when opaque (as all define
d in this
document are), can leak information as described in <xref
target="I-D.irtf-pearg-numeric-ids-generation" format="default"/>. To avoi
d the effects
described there, the absent Request-Tag option should be recycled as much
as possible.
(That is generally possible as long as a security mechanism is in place --
even in the
case of OSCORE outer block-wise transfers, as the OSCORE option's variatio
n ensures
that no matchable requests are created by different clients.) When an unpr
otected
Echo option is used to demonstrate reachability, the recommended mechanism
of <xref
target="echo-proc" format="default"/> keeps the effects to a minimum.</t>
</section> </section>
<section anchor="iana" numbered="true" toc="default"> <section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to add the following option numbers to the "CoAP Opti <t>IANA has added the following option numbers to the "CoAP Option Numbers
on Numbers" registry defined by <xref target="RFC7252" format="default"/>:</t> "
<t>[</t> registry defined by <xref target="RFC7252" format="default"/>:</t>
<t>The editor is asked to suggest the numbers after TBD, as those satisfy <table anchor="iana-table" align="left">
the construction requirements set out in RFC7252: <name>Additions to CoAP Option Numbers Registry</name>
Echo is NoCacheKey but not Unsafe or Critical, so it needs to end with 11100 in <thead>
binary representation; <tr>
Request-Tag has no properties so it needs to end with 00 and not with 11100).</t <th>Number</th>
> <th>Name</th>
<t>Request-Tag was picked to not waste the precious space of less-than-one <th>Reference</th>
-byte options, </tr>
but such that its offset from the Block1 option it regularly occurs with can sti </thead>
ll be expressed in an 1-byte offset (27 + (13 + 255) &gt; 292).</t> <tbody>
<t>Echo was picked to be the shortest it can be in an empty message as a N <tr>
oCacheKey option <td>252</td>
(11100 in binary does not fit in a nibble, and two lower ones are already taken) <td>Echo</td>
, <td>RFC 9175</td>
and as high as possible to keep room for other options that might typically occu </tr>
r in pairs and might still use optimization around low numbers.</t> <tr>
<t>]</t> <td>292</td>
<figure anchor="iana-table"> <td>Request-Tag</td>
<name>CoAP Option Numbers</name> <td>RFC 9175</td>
<artwork align="center" name="" type="" alt=""><![CDATA[ </tr>
+--------+-------------+-------------------+ </tbody>
| Number | Name | Reference | </table>
+--------+-------------+-------------------+
| TBD252 | Echo | [[this document]] |
| | | |
| TBD292 | Request-Tag | [[this document]] |
+--------+-------------+-------------------+
]]></artwork>
</figure>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-core-groupcomm-bis" to="GROUP-COAP"/>
<displayreference target="I-D.ietf-core-oscore-groupcomm" to="GROUP-OSCORE"/
>
<displayreference target="I-D.irtf-pearg-numeric-ids-generation" to="NUMERIC
-IDS"/>
<displayreference target="I-D.mattsson-core-coap-attacks" to="COAP-ATTACKS"/
>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<front> C.2119.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
le> C.7252.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<seriesInfo name="RFC" value="2119"/> C.7959.xml"/>
<seriesInfo name="BCP" value="14"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<author fullname="S. Bradner" initials="S." surname="Bradner"> C.8174.xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
</author> C.8613.xml"/>
<date month="March" year="1997"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<abstract> FC.6347.xml"/>
<t>In many standards track documents several words are used to sig <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
nify the requirements in the specification. These words are often capitalized. C.8470.xml"/>
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>
</reference>
<reference anchor="RFC7252">
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<seriesInfo name="DOI" value="10.17487/RFC7252"/>
<seriesInfo name="RFC" value="7252"/>
<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>
</reference>
<reference anchor="RFC7959">
<front>
<title>Block-Wise Transfers in the Constrained Application Protocol
(CoAP)</title>
<seriesInfo name="DOI" value="10.17487/RFC7959"/>
<seriesInfo name="RFC" value="7959"/>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author>
<author fullname="Z. Shelby" initials="Z." role="editor" surname="Sh
elby">
<organization/>
</author>
<date month="August" year="2016"/>
<abstract>
<t>The Constrained Application Protocol (CoAP) is a RESTful transf
er protocol for constrained nodes and networks. Basic CoAP messages work well f
or small payloads from sensors and actuators; however, applications will need to
transfer larger payloads occasionally -- for instance, for firmware updates. I
n contrast to HTTP, where TCP does the grunt work of segmenting and resequencing
, CoAP is based on datagram transports such as UDP or Datagram Transport Layer S
ecurity (DTLS). These transports only offer fragmentation, which is even more p
roblematic in constrained nodes and networks, limiting the maximum size of resou
rce representations that can practically be transferred.</t>
<t>Instead of relying on IP fragmentation, this specification exte
nds basic CoAP with a pair of "Block" options for transferring multiple blocks o
f information from a resource representation in multiple request-response pairs.
In many important cases, the Block options enable a server to be truly statele
ss: the server can handle each block transfer separately, with no need for a con
nection setup or other server-side memory of previous block transfers. Essentia
lly, the Block options provide a minimal way to transfer larger representations
in a block-wise fashion.</t>
<t>A CoAP implementation that does not support these options gener
ally is limited in the size of the representations that can be exchanged, so the
re is an expectation that the Block options will be widely used in CoAP implemen
tations. Therefore, this specification updates RFC 7252.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="BCP" value="14"/>
<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>
</reference>
<reference anchor="RFC8613">
<front>
<title>Object Security for Constrained RESTful Environments (OSCORE)
</title>
<seriesInfo name="DOI" value="10.17487/RFC8613"/>
<seriesInfo name="RFC" value="8613"/>
<author fullname="G. Selander" initials="G." surname="Selander">
<organization/>
</author>
<author fullname="J. Mattsson" initials="J." surname="Mattsson">
<organization/>
</author>
<author fullname="F. Palombini" initials="F." surname="Palombini">
<organization/>
</author>
<author fullname="L. Seitz" initials="L." surname="Seitz">
<organization/>
</author>
<date month="July" year="2019"/>
<abstract>
<t>This document defines Object Security for Constrained RESTful E
nvironments (OSCORE), a method for application-layer protection of the Constrain
ed Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE).
OSCORE provides end-to-end protection between endpoints communicating using Co
AP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks
supporting a range of proxy operations, including translation between different
transport protocols.</t>
<t>Although an optional functionality of CoAP, OSCORE alters CoAP
options processing and IANA registration. Therefore, this document updates RFC
7252.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6347">
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<seriesInfo name="DOI" value="10.17487/RFC6347"/>
<seriesInfo name="RFC" value="6347"/>
<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>
</reference>
<reference anchor="RFC8470">
<front>
<title>Using Early Data in HTTP</title>
<seriesInfo name="DOI" value="10.17487/RFC8470"/>
<seriesInfo name="RFC" value="8470"/>
<author fullname="M. Thomson" initials="M." surname="Thomson">
<organization/>
</author>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/>
</author>
<author fullname="W. Tarreau" initials="W." surname="Tarreau">
<organization/>
</author>
<date month="September" year="2018"/>
<abstract>
<t>Using TLS early data creates an exposure to the possibility of
a replay attack. This document defines mechanisms that allow clients to communi
cate with servers about HTTP requests that are sent in early data. Techniques a
re described that use these mechanisms to mitigate the risk of replay.</t>
</abstract>
</front>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC7641"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<front> C.7641.xml"/>
<title>Observing Resources in the Constrained Application Protocol ( <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
CoAP)</title> C.8323.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC7641"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<seriesInfo name="RFC" value="7641"/> C.8446.xml"/>
<author fullname="K. Hartke" initials="K." surname="Hartke">
<organization/>
</author>
<date month="September" year="2015"/>
<abstract>
<t>The Constrained Application Protocol (CoAP) is a RESTful applic
ation protocol for constrained nodes and networks. The state of a resource on a
CoAP server can change over time. This document specifies a simple protocol ex
tension for CoAP that enables CoAP clients to "observe" resources, i.e., to retr
ieve a representation of a resource and keep this representation updated by the
server over a period of time. The protocol follows a best-effort approach for s
ending new representations to clients and provides eventual consistency between
the state observed by each client and the actual resource state at the server.</
t>
</abstract>
</front>
</reference>
<reference anchor="RFC8323">
<front>
<title>CoAP (Constrained Application Protocol) over TCP, TLS, and We
bSockets</title>
<seriesInfo name="DOI" value="10.17487/RFC8323"/>
<seriesInfo name="RFC" value="8323"/>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author>
<author fullname="S. Lemay" initials="S." surname="Lemay">
<organization/>
</author>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig">
<organization/>
</author>
<author fullname="K. Hartke" initials="K." surname="Hartke">
<organization/>
</author>
<author fullname="B. Silverajan" initials="B." surname="Silverajan">
<organization/>
</author>
<author fullname="B. Raymor" initials="B." role="editor" surname="Ra
ymor">
<organization/>
</author>
<date month="February" year="2018"/>
<abstract>
<t>The Constrained Application Protocol (CoAP), although inspired
by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over
UDP includes support for reliable delivery, simple congestion control, and flow
control.</t>
<t>Some environments benefit from the availability of CoAP carried
over reliable transports such as TCP or Transport Layer Security (TLS). This do
cument outlines the changes required to use CoAP over TCP, TLS, and WebSockets t
ransports. It also formally updates RFC 7641 for use with these transports and
RFC 7959 to enable the use of larger messages over a reliable transport.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
<seriesInfo name="RFC" value="8446"/>
<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>
</reference>
<reference anchor="I-D.ietf-core-groupcomm-bis">
<front>
<title>Group Communication for the Constrained Application Protocol
(CoAP)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-core-groupcomm-b
is-04"/>
<author fullname="Esko Dijk">
<organization>IoTconsultancy.nl</organization>
</author>
<author fullname="Chonggang Wang">
<organization>InterDigital</organization>
</author>
<author fullname="Marco Tiloca">
<organization>RISE AB</organization>
</author>
<date day="12" month="July" year="2021"/>
<abstract>
<t> This document specifies the use of the Constrained Applicati
on
Protocol (CoAP) for group communication, including the use of UDP/IP
multicast as the default underlying data transport. Both unsecured
and secured CoAP group communication are specified. Security is
achieved by use of the Group Object Security for Constrained RESTful
Environments (Group OSCORE) protocol. The target application area of
this specification is any group communication use cases that involve
resource-constrained devices or networks that support CoAP. This
document replaces RFC7390, while it updates RFC7252 and RFC7641.
</t> <!-- [I-D.ietf-core-groupcomm-bis] I-D Exists -->
</abstract> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.
</front> ietf-core-groupcomm-bis.xml"/>
</reference>
<reference anchor="I-D.ietf-core-oscore-groupcomm">
<front>
<title>Group OSCORE - Secure Group Communication for CoAP</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-core-oscore-grou
pcomm-12"/>
<author fullname="Marco Tiloca">
<organization>RISE AB</organization>
</author>
<author fullname="Göran Selander">
<organization>Ericsson AB</organization>
</author>
<author fullname="Francesca Palombini">
<organization>Ericsson AB</organization>
</author>
<author fullname="John Preuss Mattsson">
<organization>Ericsson AB</organization>
</author>
<author fullname="Jiye Park">
<organization>Universitaet Duisburg-Essen</organization>
</author>
<date day="12" month="July" year="2021"/>
<abstract>
<t> This document defines Group Object Security for Constrained
RESTful
Environments (Group OSCORE), providing end-to-end security of CoAP
messages exchanged between members of a group, e.g., sent over IP
multicast. In particular, the described approach defines how OSCORE
is used in a group communication setting to provide source
authentication for CoAP group requests, sent by a client to multiple
servers, and for protection of the corresponding CoAP responses.
Group OSCORE also defines a pairwise mode where each member of the
group can efficiently derive a symmetric pairwise key with any other
member of the group for pairwise OSCORE communication.
</t> <!-- [I-D.ietf-core-oscore-groupcomm] I-D Exists -->
</abstract> <reference anchor="I-D.ietf-core-oscore-groupcomm">
</front> <front>
</reference> <title>Group OSCORE - Secure Group Communication for CoAP</title>
<reference anchor="I-D.mattsson-core-coap-attacks"> <author fullname="Marco Tiloca">
<front> <organization>RISE AB</organization>
<title>CoAP Attacks</title> </author>
<seriesInfo name="Internet-Draft" value="draft-mattsson-core-coap-at <author fullname="Göran Selander">
tacks-01"/> <organization>Ericsson AB</organization>
<author fullname="John Preuß Mattsson"> </author>
<organization>Ericsson AB</organization> <author fullname="Francesca Palombini">
</author> <organization>Ericsson AB</organization>
<author fullname="John Fornehed"> </author>
<organization>Ericsson AB</organization> <author initials="J" surname="Preuß Mattsson" fullname="John Preuß Mattsson">
</author> <organization>Ericsson AB</organization>
<author fullname="Göran Selander"> </author>
<organization>Ericsson AB</organization> <author fullname="Jiye Park">
</author> <organization>Universitaet Duisburg-Essen</organization>
<author fullname="Francesca Palombini"> </author>
<organization>Ericsson AB</organization> <date month="October" day="25" year="2021"/>
</author> </front>
<author fullname="Christian Amsüss"> <seriesInfo name="Internet-Draft" value="draft-ietf-core-oscore-groupcomm-13"/>
<organization>Energy Harvesting Solutions</organization> <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-core-oscor
</author> e-groupcomm-13.txt"/>
<date day="27" month="July" year="2021"/> </reference>
<abstract>
<t> Being able to securely read information from sensors, to sec
urely
control actuators, and to not enable distributed denial-of-service
attacks are essential in a world of connected and networking things
interacting with the physical world. This document summarizes a
number of known attacks on CoAP and show that just using CoAP with a
security protocol like DTLS, TLS, or OSCORE is not enough for secure
operation. The document also summarizes different denial-of-service
attacks using CoAP. The goal with this document is motivating
generic and protocol-specific recommendations on the usage of CoAP.
Several of the discussed attacks can be mitigated with the solutions
in draft-ietf-core-echo-request-tag.
</t> <!-- [I-D.mattsson-core-coap-attacks] I-D Exists -->
</abstract> <reference anchor="I-D.mattsson-core-coap-attacks">
</front> <front>
</reference> <title>Attacks on the Constrained Application Protocol (CoAP)</title>
<reference anchor="RFC8974"> <author initials="J" surname="Preuß Mattsson" fullname="John Preuß Mattsson">
<front> <organization>Ericsson AB</organization>
<title>Extended Tokens and Stateless Clients in the Constrained Appl </author>
ication Protocol (CoAP)</title> <author fullname="John Fornehed">
<seriesInfo name="DOI" value="10.17487/RFC8974"/> <organization>Ericsson AB</organization>
<seriesInfo name="RFC" value="8974"/> </author>
<author fullname="K. Hartke" initials="K." surname="Hartke"> <author fullname="Göran Selander">
<organization/> <organization>Ericsson AB</organization>
</author> </author>
<author fullname="M. Richardson" initials="M." surname="Richardson"> <author fullname="Francesca Palombini">
<organization/> <organization>Ericsson AB</organization>
</author> </author>
<date month="January" year="2021"/> <author fullname="Christian Amsüss">
<abstract> <organization>Energy Harvesting Solutions</organization>
<t>This document provides considerations for alleviating Constrain </author>
ed Application Protocol (CoAP) clients and intermediaries of keeping per-request <date month="July" day="27" year="2021"/>
state. To facilitate this, this document additionally introduces a new, optiona </front>
l CoAP protocol extension for extended token lengths. </t> <seriesInfo name="Internet-Draft" value="draft-mattsson-core-coap-attacks-01"/>
<t>This document updates RFCs 7252 and 8323 with an extended defin <format type="TXT" target="https://www.ietf.org/archive/id/draft-mattsson-core-c
ition of the "TKL" field in the CoAP message header.</t> oap-attacks-01.txt"/>
</abstract> </reference>
</front>
</reference>
<reference anchor="REST" target="https://www.ics.uci.edu/~fielding/pubs/
dissertation/fielding_dissertation.pdf">
<front>
<title>Architectural Styles and the Design of Network-based Software
Architectures</title>
<author initials="R." surname="Fielding">
<organization/>
</author>
<date year="2000"/>
</front>
</reference>
<reference anchor="RFC9000">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
<seriesInfo name="RFC" value="9000"/>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar">
<organization/>
</author>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson">
<organization/>
</author>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communic
ation, low-latency connection establishment, and network path migration. QUIC in
cludes security measures that ensure confidentiality, integrity, and availabilit
y in a range of deployment circumstances. Accompanying documents describe the i
ntegration of TLS for key negotiation, loss detection, and an exemplary congesti
on control algorithm.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.irtf-pearg-numeric-ids-generation">
<front>
<title>On the Generation of Transient Numeric Identifiers</title>
<seriesInfo name="Internet-Draft" value="draft-irtf-pearg-numeric-id
s-generation-07"/>
<author fullname="Fernando Gont">
<organization>SI6 Networks</organization>
</author>
<author fullname="Ivan Arce">
<organization>Quarkslab</organization>
</author>
<date day="2" month="February" year="2021"/>
<abstract>
<t> This document performs an analysis of the security and priva
cy
implications of different types of "transient numeric identifiers"
used in IETF protocols, and tries to categorize them based on their
interoperability requirements and their associated failure severity
when such requirements are not met. Subsequently, it provides advice
on possible algorithms that could be employed to satisfy the
interoperability requirements of each identifier category, while
minimizing the negative security and privacy implications, thus
providing guidance to protocol designers and protocol implementers.
Finally, it describes a number of algorithms that have been employed
in real implementations to generate transient numeric identifiers,
and analyzes their security and privacy properties. This document is
a product of the Privacy Enhancement and Assessment Research Group
(PEARG) in the IRTF.
</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
</abstract> C.8974.xml"/>
</front>
</reference> <reference anchor="REST" target="https://www.ics.uci.ed
u/~fielding/pubs/dissertation/fielding_dissertation.pdf">
<front>
<title>Architectural Styles and the Design of Network-based Software
Architectures</title>
<author initials="R." surname="Fielding">
<organization/>
</author>
<date year="2000"/>
</front>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9000.xml"/>
<!-- [I-D.irtf-pearg-numeric-ids-generation] IRSG Review Revised I-D Need
ed -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.
irtf-pearg-numeric-ids-generation.xml"/>
</references> </references>
</references> </references>
<section anchor="echo-state" numbered="true" toc="default"> <section anchor="echo-state" numbered="true" toc="default">
<name>Methods for Generating Echo Option Values</name> <name>Methods for Generating Echo Option Values</name>
<t>The content and structure of the Echo option value are implementation s <t>The content and structure of the Echo option value are implementation s
pecific and determined by the server. Two simple mechanisms for time-based fresh pecific and
ness and one for event-based freshness are outlined in this section, the first i determined by the server. Two simple mechanisms for time-based freshness a
s RECOMMENDED in general, and the second is RECOMMENDED in case the Echo option nd one for
is encrypted between the client and the server.</t> event-based freshness are outlined in this appendix. The "List of Cached R
<t>Different mechanisms have different tradeoffs between the size of the E andom
cho option value, the amount of server state, the amount of computation, and the Values and Timestamps" mechanism is
security properties offered. A server MAY use different methods and security le <bcp14>RECOMMENDED</bcp14> in general. The "Integrity-Protected Timestamp"
vels for different uses cases (client aliveness, request freshness, state synchr mechanism is <bcp14>RECOMMENDED</bcp14>
onization, network address reachability, etc.).</t> in case the Echo option is encrypted between the client and the server.</t
<t>1. List of Cached Random Values and Timestamps. The Echo option value i >
s a (pseudo-)random byte string called r. The server caches a list containing th <t>Different mechanisms have different trade-offs between the size of the
e random byte strings and their transmission times. Assuming 72-bit random value Echo option
s and 32-bit timestamps, the size of the Echo option value is 9 bytes and the am value, the amount of server state, the amount of computation, and the secu
ount of server state is 13n bytes, where n is the number of active Echo Option v rity
alues. The security against an attacker guessing echo values is given by s = bit properties offered. A server <bcp14>MAY</bcp14> use different methods and
length of r - log2(n). The length of r and the maximum allowed n should be set security
so that the security level is harmonized with other parts of the deployment, e.g levels for different use cases (client aliveness, request freshness, state
., s &gt;= 64. If the server loses time continuity, e.g. due to reboot, the entr synchronization, network address reachability, etc.).</t>
ies in the old list MUST be deleted.</t> <ol spacing="normal">
<artwork name="" type="" align="left" alt=""><![CDATA[ <li><t>List of Cached Random Values and Timestamps. The Echo option value
Echo option value: random value r is a
Server State: random value r, timestamp t0 (pseudo)random byte string called r. The server caches a list containin
]]></artwork> g the
<t>This method is suitable both for time- and for event-based freshness (e random byte strings and their initial transmission times. Assuming 72-b
.g. by clearing the cache when an event occurs), it random
and independent of the client authority.</t> values
<t>2. Integrity Protected Timestamp. The Echo option value is an integrity and 32-bit timestamps, the size of the Echo option value is 9 bytes and
protected timestamp. The timestamp can have different resolution and range. A 3 the
2-bit timestamp can e.g. give a resolution of 1 second with a range of 136 years amount of server state is 13n bytes, where n is the number of active Ec
. The (pseudo-)random secret key is generated by the server and not shared with ho option
any other party. The use of truncated HMAC-SHA-256 is RECOMMENDED. With a 32-bit values. The security against an attacker guessing Echo option values is
timestamp and a 64-bit MAC, the size of the Echo option value is 12 bytes and t given by
he Server state is small and constant. The security against an attacker guessing s = bit
echo values is given by the MAC length. If the server loses time continuity, e. length of r - log2(n). The length of r and the maximum allowed n should
g. due to reboot, the old key MUST be deleted and replaced by a new random secre be set so
t key. Note that the privacy considerations in <xref target="priv-cons" format=" that the security level is harmonized with other parts of the deploymen
default"/> may apply to the timestamp. Therefore, it might be important to encry t, e.g., s
pt it. Depending on the choice of encryption algorithms, this may require an ini &gt;= 64. If the server loses time continuity, e.g., due to reboot, the
tialization vector to be included in the Echo option value, see below.</t> entries
<artwork name="" type="" align="left" alt=""><![CDATA[ in the old list <bcp14>MUST</bcp14> be deleted.</t>
Echo option value: timestamp t0, MAC(k, t0) <dl>
Server State: secret key k <dt>Echo option value:</dt><dd>random value r</dd>
]]></artwork> <dt>Server State:</dt><dd>random value r, timestamp t0</dd>
<t>This method is suitable both for time- and for event-based freshness (b </dl>
y the server remembering the time at which the event took place), <t>This method is suitable for both time-based and event-based freshnes
and independent of the client authority.</t> s (e.g.,
<t>If this method is used to additionally obtain network reachability of t by clearing the cache when an event occurs) and is independent of the c
he client, lient
the server MUST use the client's network address too, e.g. as in <tt>MAC(k, t0 authority.</t>
, apparent network address)</tt>.</t> </li>
<t>3. Persistent Counter. This can be used in OSCORE for sequence number r <li><t>Integrity-Protected Timestamp. The Echo option value is an
ecovery per Appendix B.1.2 of <xref target="RFC8613" format="default"/>. The Ech integrity-protected
o option value is a simple counter without integrity protection of its own, seri timestamp. The timestamp can have a different resolution and range. A 3
alized in uint format. The counter is incremented in a persistent way every time 2-bit
the state that needs to be synchronized is changed (in the B.1.2 case: when a r timestamp can, e.g., give a resolution of 1 second with a range of 136
eboot indicates that volatile state may have been lost). An example of how such years. The
a persistent counter can be implemented efficiently is the OSCORE server Sender (pseudo)random secret key is generated by the server and not shared wit
Sequence Number mechanism described in Appendix B.1.1 of <xref target="RFC8613" h any
format="default"/>.</t> other party. The use of truncated HMAC-SHA-256 is <bcp14>RECOMMENDED</b
<artwork name="" type="" align="left" alt=""><![CDATA[ cp14>.
Echo option value: counter With a 32-bit timestamp and a 64-bit MAC, the size of the Echo option v
Server State: counter alue is 12
]]></artwork> bytes, and the server state is small and constant. The security against
<t>This method is suitable only if the client is the authority over the sy an
nchronized property. attacker guessing Echo option values is given by the MAC length. If the
Consequently, it cannot be used to show client aliveness. server loses
It provides statements from the client similar to event based freshness (but w time continuity, e.g., due to reboot, the old key <bcp14>MUST</bcp14> b
ithout a proof of freshness).</t> e deleted
<t>Other mechanisms complying with the security and privacy considerations and replaced by a new random secret key. Note that the privacy consider
may be used. The use of encrypted timestamps in the Echo option provides additi ations in
onal protection, but typically requires an initialization vector (a.k.a. nonce) <xref target="priv-cons" format="default"/> may apply to the timestamp.
as input to the encryption algorithm, which adds a slight complication to the pr Therefore, it might be important to encrypt it. Depending on the choice
ocedure as well as overhead.</t> of
encryption algorithms, this may require an initialization vector to be
included
in the Echo option value (see below).</t>
<dl>
<dt>Echo option value:</dt><dd>timestamp t0, MAC(k, t0)</dd>
<dt>Server State:</dt><dd>secret key k</dd>
</dl>
<t>This method is suitable for both time-based and event-based freshnes
s (by the
server remembering the time at which the event took place) and independ
ent of
the client authority.</t>
<t>If this method is used to additionally obtain network reachability o
f the
client, the server <bcp14>MUST</bcp14> use the client's network address
too, e.g.,
as in MAC(k, t0, claimed network address).</t>
</li>
<li><t>Persistent Counter. This can be used in OSCORE for sequence number
recovery,
per <xref
target="RFC8613" sectionFormat="of" section="B.1.2"/>. The Echo option
value is a simple counter without integrity protection of its own, serial
ized in
uint format. The counter is incremented in a persistent way every time th
e state
that needs to be synchronized is changed (in the case described in <xref
target="RFC8613"
sectionFormat="of" section="B.1.2"/>, when a reboot
indicates that volatile state may have been lost). An example of how such
a
persistent counter can be implemented efficiently is the OSCORE server Se
nder
Sequence Number mechanism described in <xref target="RFC8613"
sectionFormat="of" section="B.1.1"/>.</t>
<dl>
<dt>Echo option value:</dt><dd>counter</dd>
<dt>Server State:</dt><dd>counter</dd>
</dl>
<t>This method is suitable only if the client is the authority over the
synchronized property. Consequently, it cannot be used to show client a
liveness.
It provides statements from the client similar to event-based freshness
(but
without a proof of freshness).</t>
</li>
</ol>
<t>Other mechanisms complying with the security and privacy considerati
ons may be
used. The use of encrypted timestamps in the Echo option provides addit
ional
protection but typically requires an initialization vector (a.k.a. nonc
e) as
input to the encryption algorithm, which adds a slight complication to
the
procedure as well as overhead.</t>
</section> </section>
<section anchor="request-tag-message-size-impact" numbered="true" toc="defau lt"> <section anchor="request-tag-message-size-impact" numbered="true" toc="defau lt">
<name>Request-Tag Message Size Impact</name> <name>Request-Tag Message Size Impact</name>
<t>In absence of concurrent operations, the Request-Tag mechanism for body <t>In absence of concurrent operations, the Request-Tag mechanism for body
integrity (<xref target="body-integrity" format="default"/>) incurs no overhead integrity
if no messages are lost (more precisely: in OSCORE, if no operations are aborte (<xref target="body-integrity" format="default"/>) incurs no overhead if n
d due to repeated transmission failure; in DTLS, if no packets are lost and repl o messages
ay protection is active), are lost (more precisely, in OSCORE, if no operations are aborted due to r
or when block-wise request operations happen rarely (in OSCORE, if there is alwa epeated
ys only one request block-wise operation in the replay window).</t> transmission failure and, in DTLS, if no packets are lost and replay prote
<t>In those situations, no message has any Request-Tag option set, and tha ction is
t can be recycled indefinitely.</t> active) or when block-wise request operations happen rarely (in OSCORE, if
<t>When the absence of a Request-Tag option cannot be recycled any more wi there is
thin a security context, the messages with a present but empty Request-Tag optio always only one request block-wise operation in the replay window).</t>
n can be used (1 Byte overhead), and when that is used-up, 256 values from one b
yte long options (2 Bytes overhead) are available.</t> <t>In those situations, no message has any Request-Tag option set, and the
<t>In situations where those overheads are unacceptable (e.g. because the Request-Tag value can be recycled indefinitely.</t>
payloads are known to be at a fragmentation threshold), the absent Request-Tag v <t>When the absence of a Request-Tag option cannot be recycled any more wi
alue can be made usable again:</t> thin a
security context, the messages with a present but empty Request-Tag option
can be
used (1 byte overhead), and when that is used up, 256 values from 1-byte
options (2 bytes overhead) are available.</t>
<t>In situations where that overhead is unacceptable (e.g., because the pa
yloads
are known to be at a fragmentation threshold), the absent Request-Tag valu
e can be
made usable again:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>In DTLS, a new session can be established.</li> <li>In DTLS, a new session can be established.</li>
<li>In OSCORE, the sequence number can be artificially increased so that <li>In OSCORE, the sequence number can be artificially increased so that
all lost messages are outside of the replay window by the time the first reques all lost
t of the new operation gets processed, and all earlier operations can therefore messages are outside of the replay window by the time the first request o
be regarded as concluded.</li> f the new
</ul> operation gets processed, and all earlier operations can therefore be reg
</section> arded as
<section anchor="change-log" numbered="true" toc="default"> concluded.</li>
<name>Change Log</name>
<t>[ The editor is asked to remove this section before publication. ]</t>
<ul spacing="normal">
<li>
<t>Changes since draft-ietf-core-echo-request-tag-13 </t>
<ul spacing="normal">
<li>Minor editorial fixes.</li>
<li>
<t>Wording enhancements:
</t>
<ul spacing="normal">
<li>nonce -&gt; initialization vector</li>
<li>information extracted by the sever -&gt; information conveye
d to the server</li>
</ul>
</li>
<li>Acknowledgements updated.</li>
<li>Changelog for -13 added (previous upload just pointed to other r
esources).</li>
<li>Short title is "Echo, Request-Tag, and Token Processing" now ins
tead of outdated acronym.</li>
<li>Informative reference to RFC 7390 is now to draft-ietf-core-grou
pcomm-bis</li>
</ul>
</li>
<li>
<t>Changes since draft-ietf-core-echo-request-tag-12 (addressing comme
nts from IESG review) </t>
<t>
See CoRE point-to-point responses at <eref target="https://github.com/core-wg/ec
ho-request-tag/blob/master/point-to-point.md">https://github.com/core-wg/echo-re
quest-tag/blob/master/point-to-point.md</eref> and on CoRE mailing list. </t>
<ul spacing="normal">
<li>
<t>Add subsection "Characterization of Echo Applications".
</t>
<ul spacing="normal">
<li>Changes in applications and appendices to use the newly intr
oduced terms.</li>
<li>In particular, some of the legitimization for using short Ec
ho values was drawn from the applications being event based; the concept of the
client being the "Authority over [the] Used Information" now legitimizes these m
ore precisely.</li>
</ul>
</li>
<li>Add subsection "Updated Amplification Mitigation Requirements fo
r Servers". It contains the normative text updating RFC 7252 w/rt recommended mi
tigation methods, which previously happened in passing.</li>
<li>
<t>Amplification mitigation:
</t>
<ul spacing="normal">
<li>Increase precision: Reachability check is performed once per
endpoint (was: peer).</li>
<li>State that amplification factor applies to the sum of all (p
reviously: "the size of the", implicitly, single) returned packets.</li>
<li>Fix odd wording around how the Echo value would "contain" th
e claimed address: was meant to contain in a cryptographic sense, now clarified
in that a MAC is recommended</li>
</ul>
</li>
<li>Define "preemptive Echo value" that was previously used without
definition; another occurrence of the concept was simplified using the term.</li
>
<li>Add considerations for the use of DTLS without replay protection
.</li>
<li>Privacy considerations: Address concerns raised in various numer
ic-ids documents.</li>
<li>Explicitly state expected security modes for Echo applications a
nd examples.</li>
<li>Fix of requirements for H-C proxies: They <em>MUST NOT</em> rela
y unsafe requests. (Previously, it only said that they SHOULD use a particular m
ethod, but not clearly that some method is mandated.)</li>
<li>Clarify that state synchonization is an application of the fresh
ness results in combination with some transported application data, and not an i
mmediate result of using Echo alone.</li>
<li>Add text to tie together applications and suggested mechanisms <
!-- eg. 92070767 as I'm pretty sure I wouldn't find that when asked for it -->
</li>
<li>Restrict C-C proxy allowed behavior: Only safe requests (incorre
ctly said "idempotent") may be used to proactively populate the proxy's cache.</
li>
<li>
<t>Justify some "SHOULD"s by outlining justification for different
behavior.
</t>
<ul spacing="normal">
<li>Normatively require H-C proxies to process Echo if they're j
ustified to do so, as no alternatives are available.</li>
</ul>
</li>
<li>
<t>Reference updates:
</t>
<ul spacing="normal">
<li>QUIC is now RFC9000; precise section given as amplification
reference.</li>
<li>Add note for RFC editor that RFC6347 can be upgraded to DTLS
1.3 if C321 overtakes C280</li>
<li>Follow the core-coap-actuators to core-coap-attacks update</
li>
<li>RFC8470 reference is now normative (as using what's defined
there has been RECOMMENDED already)</li>
</ul>
</li>
<li>
<t>Editorial fixes
</t>
<ul spacing="normal">
<li>Rewording of confusing sentences in amplification mitigation
and inner-/outer Echo values</li>
<li>Replace "blacklist" terminology with "deny-list" where left
after other changes</li>
<li>Removed sloppy use of Echo as a verb</li>
<li>Minor clarifications</li>
<li>Remove duplicate statements</li>
<li>Typography and spelling fixes</li>
</ul>
</li>
<li>
<t>Fixes that are not editorial but minor
</t>
<ul spacing="normal">
<li>Freshness is about time, of which round-trip time (specializ
ation now removed) is only a part.</li>
<li>Reference how HTTP <em>1.1</em> does it when explaining toke
n requirements, as that's an easily and widely understood baseline.</li>
</ul>
</li>
</ul>
</li>
<li>
<t>Changes since draft-ietf-core-echo-request-tag-11 (addressing GenAR
T, TSVART, OpsDir comments) </t>
<ul spacing="normal">
<li>Explain the size permissible for responses before amplification
mitigation by referring to the QUIC draft for an OK factor, and giving the remai
ning numbers that led to it. The actual number is reduced from 152 to 136 becaus
e the more conservative case of the attacker not sending a token is considered n
ow.</li>
<li>Added a definition for "freshness"</li>
<li>Give more concrete example values in figures 2 and 3 (based on t
he appendix suggestions), highlighting the differences between the figures by te
lling how they are processed in the examples.</li>
<li>Figure with option summary: E/U columns removed (for duplicate h
eaders and generally not contributing)</li>
<li>MAY capitalization changed for consistency.</li>
<li>Editorial changes (IV acronym expanded, s/can not/cannot/g)</li>
<li>Draft ietf-core-stateless has become RFC8974</li>
</ul>
</li>
<li>
<t>Changes since draft-ietf-core-echo-request-tag-10 (Barry's comments
) </t>
<ul spacing="normal">
<li>Align terminology on attacker</li>
<li>A number of clarifications and editorial fixes</li>
<li>Promote DTLS and OSCORE to normative references</li>
<li>Add counter-based version to the Methods for Generating Echo Opt
ion Values appendix</li>
<li>Use 64-bit randomness recommendation throughout (but keep it as
SHOULD so applications with strict requirements can reduce if if really needed)<
/li>
<li>Speling and Capitalization</li>
</ul>
</li>
<li>
<t>Changes since draft-ietf-core-echo-request-tag-09: </t>
<ul spacing="normal">
<li>Allow intermediaries to do Echo processing, provided they ask at
least as much freshness as they forward</li>
<li>Emphasize that clients can forget Echo to further discourage abu
se as cookies</li>
<li>Emphasize that RESTful application design can avoid the need for
a Request-Tag</li>
<li>Align with core-oscore-groupcomm-09</li>
<li>Add interaction with HTTP Early Data / 425 Too Early</li>
<li>Abstract: Explicitly mention both updates to 7252</li>
<li>Change requested option number of Echo to 252 (previous property
calculation was erroneous)</li>
</ul>
</li>
<li>
<t>Changes since draft-ietf-core-echo-request-tag-08: </t>
<ul spacing="normal">
<li>Make amplification attack mitigation by Echo an RFC7252 updating
recommendation</li>
<li>Give some more concrete guidance to that use case in terms of si
zes and message types</li>
<li>Allow short (1-3 byte) Echo values for deterministic cases, with
according security considerations</li>
<li>Point out the tricky parts around Request-Tag for stateless prox
ies, and make that purely an outlook example with out-of-scope details</li>
<li>Lift ban on Request-Tag options without Block1 (as they can legi
timately be generated by an unaware proxy)</li>
<li>Suggest concrete numbers for the options</li>
</ul>
</li>
<li>
<t>Changes since draft-ietf-core-echo-request-tag-07 (largely addressi
ng Francesca's review): </t>
<ul spacing="normal">
<li>Request tag: Explicitly limit "MUST NOT recycle" requirement to
particular applications</li>
<li>Token reuse: upper-case RECOMMEND sequence number approach</li>
<li>Structure: Move per-topic introductions to respective chapters (
this avoids long jumps by the reader)</li>
<li>Structure: Group Block2 / ETag section inside new fragmentation
(formerly Request-Tag) section</li>
<li>More precise references into other documents</li>
<li>"concurrent operations": Emphasise that all here only matters be
tween endpoint pairs</li>
<li>Freshness: Generalize wording away from time-based freshness</li
>
<li>Echo: Emphasise that no binding between any particular pair of r
esponses and requests is established</li>
<li>Echo: Add event-based example</li>
<li>Echo: Clarify when protection is needed</li>
<li>Request tag: Enhance wording around "not sufficient condition"</
li>
<li>Request tag: Explicitly state when a tag needs to be set</li>
<li>Request tag: Clarification about permissibility of leaving the o
ption absent</li>
<li>Security considerations: wall clock time -&gt; system time (and
remove inaccurate explanations)</li>
<li>Token reuse: describe deny-listing in a more implementation-inde
pendent way</li>
</ul>
</li>
<li>
<t>Changes since draft-ietf-core-echo-request-tag-06: </t>
<ul spacing="normal">
<li>Removed visible comment that should not be visible in Token reus
e considerations.</li>
</ul>
</li>
<li>
<t>Changes since draft-ietf-core-echo-request-tag-05: </t>
<ul spacing="normal">
<li>Add privacy considerations on cookie-style use of Echo values</l
i>
<li>Add security considerations for token reuse</li>
<li>Add note in security considerations on use of nonvolatile memory
when
dealing with pseudorandom numbers</li>
<li>Appendix on echo generation: add a few words on up- and downside
s of the
encrypted timestamp alternative</li>
<li>
<t>Clarifications around Outer Echo: </t>
<ul spacing="normal">
<li>Could be generated by the origin server to prove network rea
chability
(but for most applications it MUST be inner)</li>
<li>Could be generated by intermediaries</li>
<li>Is answered by the client to the endpoint from which it rece
ived it
(ie. Outer if received as Outer)</li>
</ul>
</li>
<li>Clarification that a server can send Echo preemtively</li>
<li>Refer to stateless to explain what "more information than just t
he
sequence number" could be</li>
<li>Remove explanations around 0.00 empty messags</li>
<li>
<t>Rewordings: </t>
<ul spacing="normal">
<li>the attack: from "forging" to "guessing"</li>
<li>"freshness tokens" to "freshness indicators" (to avoid confu
sion with
the Token)</li>
</ul>
</li>
<li>
<t>Editorial fixes: </t>
<ul spacing="normal">
<li>Abstract and introduction mention what is updated in RFC7252
</li>
<li>Reference updates</li>
<li>Capitalization, spelling, terms from other documents</li>
</ul>
</li>
</ul>
</li>
<li>
<t>Changes since draft-ietf-core-echo-request-tag-04: </t>
<ul spacing="normal">
<li>
<t>Editorial fixes </t>
<ul spacing="normal">
<li>Moved paragraph on collision-free encoding of data in the To
ken to
Security Considerations and rephrased it</li>
<li>"easiest" -&gt; "one easy"</li>
</ul>
</li>
</ul>
</li>
<li>
<t>Changes since draft-ietf-core-echo-request-tag-03: </t>
<ul spacing="normal">
<li>Mention Token processing changes in title</li>
<li>Abstract reworded</li>
<li>Clarify updates to Token processing</li>
<li>Describe security levels from Echo length</li>
<li>Allow non-monotonic clocks under certain conditions for freshnes
s</li>
<li>Simplify freshness expressions</li>
<li>Describe when a Request-Tag can be set</li>
<li>Add note on application-level freshness mechanisms</li>
<li>Minor editorial changes</li>
</ul>
</li>
<li>
<t>Changes since draft-ietf-core-echo-request-tag-02: </t>
<ul spacing="normal">
<li>Define "freshness"</li>
<li>Note limitations of "aliveness"</li>
<li>Clarify proxy and OSCORE handling in presence of "echo"</li>
<li>Clarify when Echo values may be reused</li>
<li>Update security considerations</li>
<li>Various minor clarifications</li>
<li>Minor editorial changes</li>
</ul>
</li>
<li>
<t>Major changes since draft-ietf-core-echo-request-tag-01: </t>
<ul spacing="normal">
<li>
<t>Follow-up changes after the "relying on block-wise" change in -
01: </t>
<ul spacing="normal">
<li>Simplify the description of Request-Tag and matchability</li
>
<li>Do not update RFC7959 any more</li>
</ul>
</li>
<li>Make Request-Tag repeatable.</li>
<li>Add rationale on not relying purely on sequence numbers.</li>
</ul>
</li>
<li>
<t>Major changes since draft-ietf-core-echo-request-tag-00:
</t>
<ul spacing="normal">
<li>Reworded the Echo section.</li>
<li>Added rules for Token processing.</li>
<li>Added security considerations.</li>
<li>Added actual IANA section.</li>
<li>Made Request-Tag optional and safe-to-forward, relying on block-
wise to treat it as part of the cache-key</li>
<li>Dropped use case about OSCORE Outer-block-wise (the case went aw
ay when its Partial IV was moved into the Object-Security option)</li>
</ul>
</li>
<li>
<t>Major changes since draft-amsuess-core-repeat-request-tag-00:
</t>
<ul spacing="normal">
<li>The option used for establishing freshness was renamed from "Rep
eat" to "Echo" to reduce confusion about repeatable options.</li>
<li>The response code that goes with Echo was changed from 4.03 to 4
.01 because the client needs to provide better credentials.</li>
<li>The interaction between the new option and (cross) proxies is no
w covered.</li>
<li>Two messages being "Request-Tag matchable" was introduced to rep
lace the older concept of having a request tag value with its slightly awkward e
quivalence definition.</li>
</ul>
</li>
</ul> </ul>
</section> </section>
<section numbered="false" anchor="acknowledgments" toc="default"> <section numbered="false" anchor="acknowledgements" toc="default">
<name>Acknowledgments</name> <name>Acknowledgements</name>
<t>The authors want to thank <t>The authors want to thank <contact fullname="Carsten Bormann"/>, <conta
Carsten Bormann, ct
Roman Danyliw, fullname="Roman Danyliw"/>, <contact fullname="Benjamin Kaduk"/>, <contact
Benjamin Kaduk, fullname="Murray Kucherawy"/>, <contact fullname="Francesca Palombini"/>,
Murray Kucherawy, and
Francesca Palombini <contact fullname="Jim Schaad"/> for providing valuable input to the docum
and ent.</t>
Jim Schaad
for providing valuable input to the draft.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAHP1WmEAA+193ZbbVpbePZ8CoS5EukmqqvRnl8dOSiXZ1rRlKapSe2b1
9OpBkWAVXCTAAGCVOG7NyjvkKld5i1zlbt4kT5L9f/YBwJKs7mTNRbRmWjIJ
AgfnZ/9++9vT6XTQ5M0qO06Gp+XJm+PkxfyqnCRvs/+yzepmep5eTpK0WCTn
5XVWJG+qcp7VdV5cDgfpxUWV3cDvPvkXi3JepGt41KJKl800z5rldF5W2TSD
O0wruUGTXk4PHw3maZNdltXuOKmbxWC7WcB/18fJ06PHR4NBvqmOk6ba1s3R
wcFXB0eDtMrS4+T7rMiqdDW4Lavry6rcbo6T0/Lti+Rn+G8YQfI9fjYY1A2M
78/pqixgLLusHmzy4+SPTTmfJHVZNVW2rOFfuzX+40+DQbptrsrqeJBMBwn8
yQsYxuksOVnXMN6aPuPXOr2q8rrJ0wK/+7f/Jd9l6zRfHSdz/fI/pfzD2bxc
R/f8+1nyKm2aui4Ld9O/L69wFrPtv/2P+OuyukyL/F/SJi8LWLYqn+NXyckz
/9Rf4NeztfzsP2VyUefR38+Ss2wFs5JV7tHf/9v/rOBlom/gqXsfBsuVFrNa
Lo+fNijKCsaR32Qwkcnb706PDg+/kn/imuo/v3qsn355+PSR/vPJ4UP555OH
j54ewwYolq37PX3y6FAvf3ikl3/56NET/OfL6fNZ2G+0N2BU6+lFXne/Luv4
Kr1C55GvmpfpZgqfpPPrWp/2lQz5xdn5Mc1Mk1aXWXOcXDXNpj5+8OD29nYG
szLbzvNZttg++Ndlnq0WsDcfbLYX9YNFXtdZ1dCaPtCv/uw/nW0WS76znNqT
an6VN9m82cLOT86a3Sqr6fw1V1nyPKvzyyIpl8lPWYOnYnqR1tkiOSuXzS2c
mcT9OquHdGPb7vRnKn/LRnk7S76TYdEXeCqPEziEBwP8M51Ok/Sibqp03gwG
51d5ncCh366zoknqTTbP4Z3qJCuu0mKe4ad10pQ00tOywJ/lBYzuZLNZ5XN6
XZQfcDDLVTJC8TSGa9MmWedNfglPTupsvq3yZpfADMGZgjEmm7Rq8vl2lVbJ
ts6SObxvPUvO4REop5JyQ7fNivSCJirB28J9qpuswrHAX/lyR0NawpRcFXBS
cf7SROQTnAC8DrbfPINP56scXw4+WWRrfgcYF0ij+VV6ka9wbDDgHF50vkrz
NbxdwSuRpItFhWKAxuakpw4xXa3K21omJxoj7MP5VXKxKufX09scXnIN90kv
ccTpJc/qRQbS7RJlnsxvDSdaXwEf6VdGhCvuYJKvyW3eXMHFuGKN3kBelKX6
xqQ63TOveDEnOC0X+QK3R1LAQaH1wefiUsAs0q9pzeEv/OYiL+hi+A6fBxOY
4bc617dX8DB6exjvFncuDS0NC7+R/cE6pz3wdA07aal7SbYN/HOCd4bH44vJ
0Gh3wFOK8hbugMc+Aym2mPGmXsNLrbLB4F7ysmiqcrGd0x1/vZfjf37AvZ7B
7oMHwCH81L1cb+Ho4bPlaPBldTL69VeRih8+TBL+D5Bu+B/4kvwBCMoPH8bJ
bQoLSadcJwffKYXjsOZtRAfGpmteblcL2B04bzc5vF+COw2+h2ODG3eV7rJq
0jpHFzuYJFyl5+c/nsnoUA7D82fJD+VtdoO/gaUH9bnOwrGb4B7PcRQwKctt
Med/4jjg2uw9zJHfSTj5WYZjgpWrt5sN6OJEdhDtgXID2p2mqL2Dg2yxN/0r
hAys+R+Tn8qGtiIeigzeAkRi8nKZnD48OkxApNcJCOxVXl9lOJ3w7nD3oy8P
JoMGtyw+zE0TbKglbDcYDogB0Kgw/9vNZZXKuzpzqFnV0wX8z+HD6aOHtJ7l
tqHb4dTQHC+3Ffx3BQZFWlxm9df4xPAAnEW4JT43oS1+kc1TXBHaB7hbSBo0
KP54PcNPb3XoNq94/Sqt8Sxt5/SqLBpZR8Ay/Gm/lAcpp8tGazahX3ohrFqq
K/yO/4YCG896DvJSJ76WDbYrwCQrwYKi6Wiyyb8byf4bxfnELoQx8EG1Wzsl
AeMvalhquD1unbxe68yoOoXZZXOGVkZnfF4WcKQqnAt3t/gsZvQJS6+c9tAa
zMCbDDcGSNQGhrpZpfMs3sk9YvxrvGInu0hWlQw9GpITFrDCoLRSfoMJb12Q
xdml3Q5UgM1HNruc9UivSRI+QkuRPoKBvT47fQ1ug3wBxid9ISKTD0AQbPYO
yywlM2rWPhOqX51YVz1mmib1whq3A+m7zpHBPaLGT6zcZOlmrIrs2emqLm0A
eLc7FTgtC2/82o7yApfUjZ33Nd8zWhNW/vVna/7aqf56n+7X6UZxsq1Np+Mi
VxWOHjUP7RbdzEHVy5Fepzu6uMjKbb3aobYs5zlOKV50C19cRtaIiRKY3Bdw
/HHMvDPxIOOjYVC8+WWPoJxao05YZA24RjSFzmyQQ9yUm3yOQuQKhwuTjMJk
mVcgb2vwBvie8Mx795LzrFrnRbkqL3e8wNdwSkDYwGwPX707Ox9O+O/kp9f0
77cv/vO7l29fPMd/n/1w8uOP9g+94uyH1+9+fB7+FX55+vrVqxc/Pecfw6dJ
66NXJ/84ZEtk+PrN+cvXP538OORT7zc9ehfwnhcZHctqU2W4W9hamVf5BW+r
Z6dvksNHvLvQI4STwYcOnD88JbAH+FFlAQvF/0kSIt1sMjBNcpKmsOibvIGt
PsEH1FflbUHKD+bux/w6SyJ7Kh4m/LvKVjvaiYVoIxhrDd+lcsDPUDsk5yo+
4Wbg3sHgUuc76Zb4ObuAh74rVqSFUE+TtLSjxEoQ5mMNC8fbcchTyad+yOoY
Z47iMUl0jdMWsAJi54ILvNpNeGaXZNr0HVd8ZDIsqxy0iN7CDlZaf/w3OhD9
TWfBSVEWZRMdtWVVrkXLeA8K74gS6Wv6FcZFisstGFN8vQqgnOTU+5xE6omq
xfswc6bpaTxw1rK0llUgsZGaDkULBheT7dwG9HRSz9OVLRgI4HyDj5vBE1QR
oxSGL7L8hk6yjhstiCwn48usjrSR2/AlMBoa2wAkEZx9OrVie+V0A1SGcCbo
9yha995hNviZfkUKuAaZUuFC8Xf2dvjyzo5dZBt0Worm60H2PgP1kFZouuNL
wOQMi5KFEjyzgPnIEjAuQQtflkNUekMwQunl81om4r4Yf1V2UZbNUFSLbN5N
uluV6UJ25kW52A3Z7NKx4SM7u4u8lllC2ws032YFc8QCgs3Z2NUmKR5EMT6E
JgSOPE3GCE/iGLaoGiPDWXJSBNukaxi5UUR3GvaZNni3XptHdjQtFT9AjS4d
eWeo/gF2DtyDPuNJ+2YlfpRc5Z4Fy3gbXGxZLt4idZovRGoPyRZFExDO2JKF
bjkH3QtfNreZeApkh8Ke25SwiOAz5uAIXqU3WfhyXi4yFuHx53XW4GKbc2C+
a/Z+njnXNVuxjAOH7BR0b/Z7HIeYmqQYzOy8KcHiJMHUZ/WOnuGHh5OE/j6i
3zrbfMxmqRxPHeVs8Hf/Abz/nzNxnMmaus6yTcdvyemM0sc2cQnoOdjZFG+4
YDcOFjS7Tw54nZLSCdMsL04mWOvuQ1JyJcumYNzNkun0W1rMYI23lzHcHhYx
LXYi9/IqWnjZE+HiXku/s0WCa0B7JOWfqWgFA6aESXaCDd6QTjk4Fze0gcrt
5ZVXF6AI4EVRHhQLNhblF+b10hPUyRBjyUY4Qwe+z1vpnLiaNQ14ILAIK7eF
8RXz9aYEixbnwXalbjN4Ny9DRnXGi06CEoMo4NZvrui6MzUKj2aPaLsdzR6P
nT9uM2SjAoErMwhLfYubp6Y1I//UrE56Z52Y2VjEMnkJrU0dDgqZomYdRIob
DUz9UfKdudDqnNN9X28k3IWZmg9kkXZ/8es9mOYpKagPqK+9b8vaFDd86jcE
jOWSczZ08mjrBZ/e4hEWDlRlLmEIZyFJRKjCVAT6GdU2402WLzu3CN7h/mhi
vUWTpSanUe69Tq9hPeiZ5qTcbFc4fBn3HKP0OerhVbpz/geZP7AEIaYGxiws
er4CB0T3MjoupP7AoEybsqI44N1pBwrAnWHMTZ8lQQ71ESlgk1G0B6wr8tHI
fqjRY4MFBS8CRC95xzAc9LR5ichVRq+kvoKXJpGEcY8QcUBx5haPNhQFTxuc
znK1pf2CAU6aG3IrXfAtK25ycLNC0Bj2M7qzoCkWW5rKvJhXGeUq1J7AM3GV
pQvamSt4uWK+AwVtjjgawbzYFRsfYjtO5J3pnfyLmyKTPSoRhvc7OBoZv0uN
y1jsGpq69AJjcbYpzZkUsW/B9ZdoaerMXJWb6cVuCn+hxkPtPXFxKvRESe+w
QDWrEKaW5ht+RqYvTdzlVQMzdZtWCxfJxh2zge1cUOSZNl62CPsTo4FqYcbn
8Rc4Ad64DaKFjGSwVtnFEl+6vq7bRw4Hjf5usG9ZcPPr4GmJTh6NAsbDchY3
fY4KlrzbWM604ycsuep2MASsimSFs3Kb4f9iQBQsIJCJU7N6LNRFe4zGzkbF
Z0cT0STk/eTEGNrSt1clPBA36lXKm2eXkZiWkHZ0xyjmgpaQCDQeCHtfe67G
ne1tfs0d0DLhfrpBo5/TfPA13ASM/DkcrHUG+nbBphgqqjW6JzD2bUOWC7wk
z4UIvk0Jj8j7cmc36WrLrkeYclan4RVaWSM4zavtgjd2qiJU1ohijXB7FFYg
wyzCyffJ2VOB1SPXJZK+GmgLqywiiIIFqMVBHMte6xOwFOsjJz3kLFy0qJVz
0GWIN4aOhUUi2YdOLlJOxALNFCkiVa6Sx58mnAd+6QkYjrtNU5IpkaNdv5ON
qcZ/ugKLWIcQ5pleCOPXLMX/RhFsMtfj9I2oGUsioZaBJTQFQ0PDAN+cNVku
rypOY632MJ2dFUWyrjn4yLuUhY5tEfQhQngD3odciVRv192iLgwHaucGpaOE
3dQd6B0m50hsLGh07x8Pia57kX30HYeq2UyacuD6gzPP5DK0hMWrAUMjXWbT
hq5G0T6hDYyGgi0tej1TUFh8dCWanqWkWeH3Gca36IH0CYa42OLI3rMZfU4q
+FEwXSnEg3bjv9qfwe+m8ud3Pf8f/vyu9Y/w7e8GfwEXbYaggL8kp/D/7+D/
f4L/f4t/4xaSP3/RafpL8mMGJvtfkufZMt2u4IO/zSjOnz3HJPZf6Fn4/+/l
b1oDG0W5SeHowj8Op48O4K9RAYJmnPxtRiGoidPkm+QULEs8xBOYkW+SdwUu
+ARm5hvn0U5glr7ByKMsq1+ZX4+Te2F5GffxzdDvp7Pteg1CH7zEikEecEgv
i2+Gc4x8VEO/A9sinAWVGIqpyR+KRzcUempMNoFNzbFO8ZFWpJFiLTRLnudL
yic2dnTwKMlzUEB0xsE6DfTQKkQv6YVJVmK46FQCghwmxwBUtsjTCrOMFPRu
QKbhIHveETSZLDTrRzBKitLlx2sx6/zbotDWl4VT8jNafM6BiR9DGs3sYqe5
aGQgJFtOjZlj3bGOUs7nR4vi7qgJdlZZKCPc7VTvIiiu5hUcXYxBbq+W4FPX
dxkgImicVQHLSKFEFxbf81v3aDI++CXBmp83K+fBdV82ftERGoMCTrInjfGN
75q2+B4cv0yDRYT+X5OM6K/OvcGQq9uBV9gJxUINkM6Qo9VFDdgK8LZuRobI
aqHx5N5b6u5qfxllvCQb6ZKRaGu/OvlH2l0F+BsFb47XW5wAM47Fgeev8b/4
e3fmQPVpxHimj9HsI21fUs4bSlzpjdwwYZCc6OCMTIX2NiZTkiajiD6d/Mjc
iKwVWHS1LtgpR2+NdtGiHLNOl1cLarMgyyhbmCho53t9cFKDOrXAfQT84KdJ
F8rdYCczQRskXd2m4Cm6dZigpLLf8zze5Bwtgp0zUjMc14ZuCA+52I3JmDCP
lFwq90MGBYA3U1i+EqVUSDLLi+OIRytMaaEzq+/qDEjyX8e6f2B7DdRECUBc
tU8wc9ujG2RjRSZ7sfPwN7ODRs74AOkBGxNXfGEawEmUWuNUcb5iTlbaFvGi
8N5wTDAglsvMRta+JmLZneG8HckhdZ45ayJgBHcbPKkuwqAvxo9r3w8epEm6
ECBHNcaxZhK8hDvIo8gUr6h7aK470OIc5lgJ/iYE9IJ0p9wget/yzSLdway9
RPdTQ0tOwPS9fzx0i2OgZktJU7Hv2iPbVFwE+YY/3OcPR7Ku8GoJzktXDWIW
WYAC0U81qosPlzR0nVHS59Hs4BCMJQYa5f+SOeubg3aRFhZHRZ4IG1gX2SRM
j/WDgZ8bctPCjnWRA42Os0YIl0h2cpa84A0l80GJOgHX9Skz1oX6xAB5oJg6
37esUXiyGqPwD88o7t0+FcYTAXKC9VyTEsadcTZeDNqz5AQ6db11sfFwX+/W
9QBQ3J6I/FBzOBlH1QFYRYuETxdvOaxUj10VUBh/Q1wWY/v6tLKdGISn+OhY
SULQgSI3VXaTY/hWx8g+bfA8C/UsLZXlVN8VxjHnfB7Y3OjcL5FfkEBgfBNs
ErR0JZwUQCnvNmVkoX709HQiaW5ocg4JA8EPknz9KgTRDWcqGoqWP7aL7RpJ
pC96rB9OA/Nj8dTK2ffHUTLv5RqmPjPbrD2iWdKeAsx00en5zS+O2myPzSpS
vQDP2u+MduTOvdHnyyEJ4Ea3p/jOIq/nGAPOKaSKL0o7ZERokJyCRbhbb0rM
01Xp/JpizqypN1V+M8VAPPv/JzZUM/ZoCWiQYicSYkvsKHymLScMa81hvxFb
LHsRKJoJSw5nR6obJOGi0CsxxXzcQ586poi6WKcBbTbhM7XO0oKSQgvzLWXg
NLTXka02wvAYfowINbmjSccxhx9h6NGPVDNidJd+621SUvSdD1yO22DXYKq+
7z2qnTPV2Z4iMc3bqNs5rb22EFgOIMu6wFs18S6LEn5D133C/f7vmgh70I4f
A9rY4PcMas/PJu1PxQnAzYU6lu0SMdQLgRZqJkqmr5a0Y9b6WuSIHv0U5MVt
ZKwMBq8xYQAaUHP9nQSEC0/SESR1ZNPDgoMMYnN2o7QKjfuOOYh808KZl80V
Phi+Ss4jdY1GtN0PPWXY01cZyRZ+wKg5TKZJczBO/i45t/KKQ05AhWeL9AiD
bA70kqDnPiFgQDgftegNL70qbxklQbm+XKGA4qEs88ttlU3xOR8+xNFPDjAl
CUgqfN2BhA4pUIj/IaG9b/VD8EwW2XFyMDt4mIzevDsfyy/gn+GXBHmFi94/
OoxuiP/zrsqnb9Lm6jjBfH/n6+QNR7bh18noXYHXjDuD+svfSbQxHhTp/pFX
/vpT+uZTRod/cAHw6wP+89Wjh08fPfny6eMnc/zfI3gELN03yVeT5HevTk57
RpfMZjP6G7dRxZGVKt/UaKhmyaGAHyaSbuTCG9gw3ySHB7O/9QIc/eYF+Ctn
4NMX0X7xBz5ecKuJ2juJHCqcFDxXyTffYp5+nTd4BD51QxzNDh4lo1NG3ugI
6MOPTVRvGNodIwtGy0F8JQfxOzyIKNvO0RF6Rm5LwImEEoX7Ly2C88YCMPgb
8BfWm/sCGRDQNKiUkw0FJd8nJ3fEuk8K0zKfLl8RNSIeMuVb8GkaKFN0OClD
8rU0MYaujc/S4M3UBNJKGR9UfSmhVMON30qpVubuQXeFGx1SGZbWrtRZPGZ9
DOWaScOwF4jJZzxgBTuCICcb9iX5a1ZGFv5HjFHDlRNlGIJYsTQamQQNZgcL
VdBq7INml7AKFMkCHXohblikQATaULu36OiQ7CABNQFeYZIdqgrJTD/QeBaq
DD5RT7AGzw57b2J6UQGHsdXym3RM3lYzNN+kZ/6/ovk0RfMYfBgUdY8nSbFd
X6BNDetRNuAY7ZXRfX9cyl5ATWFk7qVMP/0EdtSqsd9cIe7FajQIjif1YbCN
rjiAF4+FbH3eUhkqsMf/zvTX479WNZ2KOqK3wzX6f6uGOi/0BHbKEQzlyYSM
YJSmhAiraDKkNv2T9opWWBK4hIyUKRkp40/WgxJ8+4gifEEBvDs04ZusqvOa
0o+nMAx4l89Uf5RPsiJHlDL7Uncj9lBwCJpBsHAeJ3ypxN7DV8ZdX5L3veqH
j6VkDCHmcjMEPwwFxlSUR5GO1Nz+KA8UleXNkuiF7woJpvsCgt2XEhcOczho
kIW8Ff/efocRP/EGt4W98QwPDHhs+EZBYTJA12VEyKkqMopn0FS7GPNVmc8x
UeQSLJINT/ImWydHDFAx/YTBnKLPx6fQssJctxRxXG5D/HkyyGfZbNLBY6u/
VsNQa4IkYqBpX/6Y1zbAsBmWFdUkbKosw4z7TTZ0PuxkgBsNFg/HZDrd8JhN
Ps83UrkYx09vESeuyEm/6H6IK+IHMSiawMJDTJlCeSlWVEumnzHLiMZhtBKB
QTkw2YEXMLaOQ0ewEcDmxI8ExUNpPx02xnrBRot+XPH3nUw/P3LEZVBsiFZo
42kMYkzxjlxSO3U5oVQwHj5YjPKmJ4xOPnd5iWH4mtAQRRY/Nm/qbLXkwaMk
nW43AWHHpyv35VC98AcNgUtiWnGqeZs+AtOjE8Ew8aio8r+RdxRLihfEYesq
AlTnBuWTRBzsQBaO8OvbbLUiwIDmmXKq+cI8ANx1NtgzbVKN2tpf9+sQl4tx
CvAACo9N7bNxooVTUXQmiOAAKZCNjbeUMk+Qi7PBCPyCdUkFZrSZGgY1YmDT
xsUbA3c8+Stpfe2nlepmETwUHV459hZ+4qD7mLNAHvjqAaC4+384P39jCXlc
z06OCCRGCDdreRCh8jDNzqE782xQ9nKuA7M+CqPMEZqBol8rIvKGQaVoA8E0
v3l9dj7+OrnCsICIEwuBLgh1u6VYcT0HwSOeni9rSOwttbhE3hLfLjrjhiPi
fUzLRRNm8NZaT4lEXnk1rgss4zfkKx4RdIw83F4VRwkKbB5ngmiSu+HM140U
jYY9itlTWV44I1tCkEU1ciFlQ8OndX8MliU6GaBHMBN0k+YrBgy+zZpqNz3B
PYvmHwXhaFapphykPGXjuST291m2mZ6gVeBewUKu0RukVZVL+dULqm94njbp
xM2WDBJXOk0eHT0Gc6+US00k5yDGEeIvwIL/QHX5Tw9Iz5/jFsPNyCXttUoB
Q/9yrkJnvxuMjobLu5JwFo2rdJeqYURNnHhVLbfoFsMQ7qGn4hcLYReg3lZY
HIGIhEjz6xnoKT2RiDuKD9aOPUFxht4GwEqOmYVD8FcJ2ZyXBhPAgTdZ0QNd
vtymFSjYjDM8nC2CQ5ojFggcLgxnpwgAx4ykVhUocBr/wcwPLw3qPCEAC1X+
4+5U7B+fcDzKEzzXk+T5ix9fnL8YR5Kgd1QEnWYSAWdYEK7yiwBLdgJXQDck
dwlJvF01ORrjaXdWPIuGYR7rBEk2FKLBjicXDOfFvKtZ+2BsOVN13LayIRZV
txf4jmdRptNvDTq8eAsuImrKFdy7QAB/WKeAC3IuS/zSoQIEXjvd5Igth0/4
RnEanjRUsM+iJBombrzVqAo5r3z1udRd03H0CkhgJ2Q9tu0fOCBRtrQRM75T
5hEyYy505RKxneXtYlnYfa1NSocMxHxeVugBrRBoc4TFHS10RM/p88AGOIaw
ORvUICMF+Ai4p6JHjAPTBw0ueFvuYSbl/a1TvflOb6G2r5YEo+iiGCMHYAK+
zn54kVHNQbgr+CYv8ERitabBDxT3G6GhDBlI5j28yYSX6K4hcwonGqx7bXlg
wAxadUgtq2HvEcdt5dTEqA2eZRaG/gV1YuaokEgfWWFulIPDO54UCFXFw5c3
ckMjFiyLYG1dZHa7lGSE7D8DCbVsv1zKFPPia+bq069DpYoiK7VMgZAlJHgx
K1fG97/v8t4mQggWZguHFfqwaKBL0Oqw8vG8iWrMOpgc3abKYYUnNi+2GpYg
sHUqWv87X6bnkalsuFnNLBmjrObxrbjUUYIbiDBoMOncyY2jHotLZXAAb2Ra
Xv4BbQIWYBIdHLvwScQq1WKuUfDB09ljK4Hg4IFN5QnsdjKUfinZaxfoITFA
ovhYbwtF8nBN5h4uSXDPW8WlBt69m2ISfij6y2fehVButYsWDl0a4lNCwVAs
QFXwUsYHz0jbOh4hemz0PrV3hlEMkPaQz40pMAtHWVELLEfvwNVo8rt7Moht
DsltcC0bN44ITSOWLFPriAgYPKSAPFe6Skpa4ruIGcoKmKlpuZzWYvTyhTgP
m23DAiiBL2C3g3cnERxDa7DY008JzBaBT7k4i0fkNVwMSpUVWCHpZ4ueaQmn
qBR8UN83lijHD2OKBZdl8sMJRkp8BS/LqB7zZKZuMWOGEyd99o+YkW+wTiic
sY5qzqxPGdxFLPq7Cak6lD8GBjqcPWzVJIH3I8AIz3PFelXu5gtag9bCzWJW
HfpsyDHQXdSuc9wJZoCZVnVhoGLHdmB1HA8F6bvzii52zCXjiKc2HpGUlXst
s6BaR1QNJQq6DQJBjZkAy57zdd7oRhG6lFD9y7vbeaRahohp1qrImhjMJcGp
GxT+RAnGAER06As23eYOlqQAt+/U0XZWazeA6sn24G5OUTq3qydYHBWDqzpD
xBum3HazZKSRRdLSK/IdjauTk3D40ylME0PcWMBr5pWZneZCM0N+6SRoUQ4q
MgOIVu14cqIQn404kcKU4uxoateHBTzFW3pRYtmfPP03nsS+Y1h/2jlk0dNx
xWnRwi6VF4tD560DLPFoKh/44G/rI38+RgELtqaKrSZjcKKUb0oyFtYEq/8s
RNEusadg3IZxr3G0oQ4afA/RK0eUGqTaBN2wNMF6yYpsRcDLy0yknOkWQvOn
rD+Vd2AmNX2og/qWB7bUw2TE4XQ4x/cbdqwC4xJ6gWwj8wkOSc6LHca4DVm5
hfVd8X7NiIXJtBXVqC1zy2jCnxZB1Bxz2ca5sC0860LkZ9JC/kcQvV8dHBw4
jOaXMy1elMok2J8kdoxsSqpvijJQkYoJh1dYoEnukvJWWEiNZx7AmkqXG7Dw
cEva/wJLO3z4JHlGU6P1w3BQ4RdCeq4LMjoPk5nXHHZkdX/4KPld8ugA/udL
udELHC9Iwkny8g29xbvnbxJcXaE354xg8kguh4mXaEKjwUS+GLZ9RX628FEX
W1nTspi6y2rcaLLc9jZjHfj3+Y1s9IZIGSmw1RDLCJid9QaB/O06E2cZ0UgP
Hx7pWC0KzXfDmcaZl9i4HRVaVlV8IfImLstegkldTw1Kam4pJe8lv7zcIXwW
Ex8VeGpIVkIblbZiyDbxPYqM8ju1Zx5GzTdi1/aW6ig4KBwfNSEHqTKq417n
ROaBYv5Ry3W/Tfld1IX/xCKHT6hu8NUDZM2Co7wqd2vLs0WMHwpzltKsPKs7
VYSk7uWpPXX9ZY3jJgHLZBmnVym6ZPCDfzEGEBq8D1gOBu+M0UC3r9PPA9HP
83AvnglFogtzVSpGQrbaRNWOzk1xERAfJJXyxnOuxtK7ofzYcbKMjDUEVa/Q
M/SKhSvJGHkLrivI31Ukuuiu5jyzxVykqyxEDdAdWiuFIIXiEAQicF7Q5QsM
qNnlKxD75GFgOT+iz3A1ajjQlLRPWkl7zp5YhMX8LZeErHkm+ZTqSbPIQAeP
q6xGAy1gVTBuBOmdIKUgX0FQaoV7ISaAqwyjgAmdcgarkb01J1DBgvipKb6y
ptswsw0NyZtsKROYgi0ELuec0txof5F4A5eNfk5hAyzZng1+pn2fX16RPXZJ
9TH6bLRay1ukZFFWIH4bHC0bV6x3zOVRZDC/YLvmSUZ5scJs7uJ4MPyppLBt
gDLDsNGyR1ZDFGqgunA4SKgZ4rjE1rXcIr9DyZR4LwvOpjeY1Ob5ge3cOwYe
uzvBXHKVynyT+cICrr30XJPpyKRa3nEG9qWGVJmYbAo/QdbZGy3w5GBN/6TM
CXWgLCvCbOaT7Zxu21k1KSnJRvGW6r4itSzvCGYY588z2gD0hgOYzPKCtuhw
W6dcwIpFZ1uhXsGT9Zi0IhyG4bTGphQwYWvK6CtxxkmIWuJkvcNXeumib7/e
Y3cJffqmgos/4CqF74nYY5e1k6uxwnSvP0DslqtNtccv2qXuHrM5eIfZMOoY
QzoXRaiUqorHrjdisIG4eCQKSUOEAaMUjQrmjUOBqjvmGqZkSAiy+Ihb5KCJ
XrZSYSjll4wntHdC6mgUrGLj6KurExNOJxxLWl3kIM+qfLWbDEYWdU4dvhbT
r+nORIh7KgHlSqYj8E+jEYCMvNFSckqZ4B00cTN2HPrukFGHj7gyCR8p/OKO
RCsE4Hg584oBAKQ0mGDQXU2OpWda6KTjuCqZauIlwGIlSuLWTgbC7ujPspzJ
X/D9OaiQFQyv4fxekSMpRQj0GOsqOx9sawwGPug6iHwiq9en4ulWcDQZpYGn
1zMHGIbs2exwdkSV4hRfcVuEpSEBEnilGZYwoEhHezvZplvSsdC9FfZelKAY
jIbn7nCucXLE4XblKEs8SCo9eGeT8oqV3H0s8Czn1xPLg+jUjAc2FqYAZGpQ
OVwE/Rrg/JCf6Xnv9jiRYGBy/CA0tmiHNRkd4EM5YRuml0hJSMSelyhDZasJ
ZZMJZfY2MTq6XCLzFgXLORwAxu6iXMuziDgfQWl7/HKPE6uTQ2Ge5J1EloO3
pSJdprQFEvronF3CWoKLgnGhtLOy9B63nMUjidCnqTbbSmIA5mVYsbonTRxT
W4tamgXMwYLB/CNOPtrWBIfPcDpkwxJL69vnFCm4zMkKwyWUlE7tgHJfw2VR
SiSw+iMC3e6J5SjMrzo4L3uEjwJHEbEUxHQ0nbYb+iaSLQSl1gik96SCLcRd
Ims8Qejcs2dqgSJ7hHGSuphMMvJCObZC8NVJRzv/zQIPgcQtJMbHA8bX4r34
yQ77xzO84CCoGdThLZmYp3VYAiUPpsTNP4kxEgmxXCgLF8mh2rOluNQhxe9X
URpUmXKjxKDa7B37jZUCuYpEvmDGa6MrH0OoeAWKqIYQtp57RQKVwB5HyUoU
ibWk0xYSuHPYgKjAlzQJbPYVsTNG8p6gs5qD1jvFxQshkiKZd9sErmrCpzEY
NI1QRJjb4Nf2GI+RexAhDeBIb9BJFQkAg7tEQsPS4saxYvLKg9xiTeF8RPgS
mlR5c5sqR6/VG0gxSSL6mWJnvgnXEMfVmap47frDohHxdvDSAo6Fl+uBBXv5
rsqVje40IBX6MD3UpoA0Ku7m2JkNe9pPDXVHmjdZiwNqoIx5zFqVRhXT9a5G
bLBjdCTy4A65bbCv2iF7Eu/6ciriel5oMMI3Fz5F5cURCKcrnlbOFxoxouWK
mLqSwMUiqfIIVMzNoCKUdhSUngy4PMihriPxbOTztA/JHWdaI96kklios2a7
4eBOOx09HriYjQamzNhkAx0MYw1l9xa0a+4kt54q4wFJtD1bneM776SxShzS
fhVC2m/bDVvO5N1+vWe5D2HGlB4iUQOYfU+PTxDDr/i+rWp+CsBJTkO7p7U3
08f71CQtVRL3ntEUkXSZmd2VNSTPWiYNT/jCxFsotMMlPW6TUrfzJiGT1p/J
vNj58GtPOkZHzzHkDgdHqLeI846TfaYcR8II8E8v/cc/RhDXP/2JuLtVwMF9
te7kWbnAbcuGmDJ1n6eXdXKPabq10ypzeX8X2iS4O+ySUJ756z1sMzAFHQS/
oDmMGs/BXNBRJcW7LcDGy9mKxDAt0rDWgVH73fM3QjCoGIGYxpd/zKknaanE
OaNisXKQm8CqvSqZlopzQgoLJiANIRQZUrOn4RShYqTXXJvw9a63ycV7YeMI
nolhCn4SGLI5BUtgFDpcEYR3tuOKiOWVvJO7eO243lP3tf2WRJf4CApCqKL+
NdzSzvLYuIpjjbyLYsYEFLPqx9cqWatwsYVxckcR6vZgtMHGlsFtFmiBudPC
BFW8GSOlN5piVlV5XtzYhp/t5i0mog1M3bKGFFbMXNTENRdZ6Huq171wXJU2
P3kW40NtYkHU6wLQF0zVz2bNXvr5bherprxkpORea8Fzz4d2ZIy5svCWx/98
ClH8JOAGU6OtN1Y+PtLBeZON+Ank4+v8PUVvNjq55ER0ZlYLrVFfSOyDsMYI
06rqFm9cvBo6ck4Lqb+GmgOUPV7urEArY64z3/dLO81Qr5RlTokBBj6ynRsT
CbtWfVHnKEfU7dTIJLxI3elW09uZTzqQGBuIMKD7xg0fJ0Lv6SuIkyhj2Wln
N2lGQ9PoYuEvqE03OhvZ5gr0L+Z8GOO0r7lCq91JHUr5KNFcZyJVMNQ1XXEp
gC0wXYN9U0j5kc2qsf+PtOkomf/bDiHtLvxEGa/FOjTEIvlrLWVquusDKITA
/i7oDAG1BY4AEfhkzGXri4CmNpGYjHizC8bKtVOxyaZCp5yKjkCVl9LdTsVU
3kyiJ2nREiwRuB4pdab7+MzY/tXpCVYVRRNIQ+2pytSiHVgwOVb4hQWrWj2Z
PlFw7m15qW6Lek0Bic+pp6rahaNxGHGYYpc4PjD2I2fXYdyAA5bI3EPwdoEq
FG2OYjFTh5RL5TIFay7EDxzy+ChmiwkjotJneYKleNcZcixjwPTyMgtJy6C0
1Ug9mj0S57N7ppX9+p5YYtTvPqIK758+wjQblbQm95kXj4nDPSu4kPzHJOIJ
kYhzaY0++f9zhhtn+FeeM1x5w/1iOM7w5GD65b9zzvBohbVAvWc/fpw93P1o
wnG5Rm2yYPcRfbIAkEFuJi+kexv/1zsHseQGchY48B1Eqe5LT9Gj2WELsD0+
7siXj9Agk7zPi+Vqy92XceCtC/U9RLD2mZ93UChT5JOg845MmVLHRuD511IZ
9/SHkNgEgwa9bW86V1xXF6bJsFConKLTrlaJycVQ74tDbRMkO3pjDYhwD56L
bFW3TWf3RIeE2f/Eu2RepDK832BGpaqmTlPi7m2D/yKhTAWzuYUj4K1PYIVc
HJWP1r5KNqofTW07tA7GQKrqLwnsxbqpI7oVDcploPQdKSFXR83JqnBUUtfn
cDbordzFwfcWu+IEoMUWzbomS9m0xZf9epAbW5zE7WQb+FJKzudH93Jc02BM
anjqXiv2MA1vs1/zmYNnJZNtGtbQEjpaOXyDgQuFNpwzselbVVm62LlkOxMq
YPkrRyrNNnD2gvXi0D7lHN7UgkDqSNBcRWVhnKV2KOLe/Wr5dYuJYNZDKCWF
aqmvEyIBZfhrNp0eHI21bHQbgQ2EGJEzMiGKwj5osOcQjYXT1V0K2uP9jcjd
RqRMnNTUMiEx3Mz3klSqUOu1Qghvim5I4JvrsVZYmiWT4QcTt5YKuXhzkrK0
ztWOTxeWwqOujdsGPF4rLqLVhNnSKXKEKHJSxqRflHG13+0acCfBwryFRZ/h
TscXwbiYNiHKg9qez+sku4hoK0IIwqZ2Cv8HH8Bdq8wawVBRQcDVRBVaafLd
i/PTH+KChxC8QGUhEfsVl5xZjoemw2UDhduM55muvl8nr9L30xPX7QrWjfCA
uwxz2q7zXrvJoYaP/ExqPQuzIixyervZwND+znOlW+Za8slpkBfcgTOxPmSu
PqDfCqY8W+wfuOKE9DblZsI4v5IYosnhGxCkOwtZ+smAbeou4e1jcASOmGm3
pxFiZMeEPibMhvHXdi2hfp56zMnBioJXLWc+dYIQp4ZDavqKgdmepCTjdaLM
U0sKfMcEJ662ggqNKc9qOeE1dwYOVpOL7bKqrMkXOZodgFhDoqiQ31xykhZH
i2dtNjhZIatHYAcn2Hqpjqxw0PJmd1sRXxWhwuybN/RGhsu9kR6cMeYEbxDV
22FuWKHso2K7/uZgrG5su1yrM/Pc+IBQGfO8AgGGQLM5+tHYt5xZIKSEi1KS
ofD51uwuxs+0VyR6T9yARIiCh1VaWmDNj5N9BgEVFuiK0loE/EfCpFCq0N8Y
tgnvhzn0AbdHoQJ2ytf6kYXZ31Ecc2dg9sdEh6asFdvAWjEWZ0KFjjKrww+R
H4RrckkGWd48e8861z0PU9NlgigNDJQ12hkC09V8nGSssLZGI6F1nCb63P1C
9HphKZ8vk5HmW16AVG4wiaLhR4oWccpd4illfxtbMqjOuF1kW+sIJAy9C8PO
3xUoiijOSYZRNKolfqQJBGbg+GuyFUomPvJXzgYvmygPXmdNZAtIKyMqPoHv
xpz7XoXD/RETgvRh4NFotLVMI8z3BJbWmoGwA+MGioPBGW65mGE7LFzoc4xB
4IFR78dLS0osRG07h9dgvcJyZTWhKYZe5zuYcyzXRgsxvXBlZ/2+zk2e3Sry
mu9sEVI2MGAOHfYoxP56bgfz/vWg/vQZSHpmQLrQSL97Ehx9xk/wf6nSCBQz
lzL1TAW7NFKOMhgR1kCmbhguanS6Gg3Kof7UDmAkptquC6f2vFPAkBRplUNB
Oo2GeOzFhw9jT7CDI8h8zwcS0EZW0DqkNCXYAJu65MwGP0v3GpuDNHzrfsXa
zk6+jFQinY7WNRBTfE0Ru0ybjdzxNool6aTgpALAocMLf+A6du3Sx2I3V6nW
Bxn/ltyWv9IVXWo3TT24wfSkELNAJYKvEbeAJ6+FrxRIqBGXcSUIml1uKxAh
JcjWLRbwLRh3xDwsTPgxDwaFNnCOegVEPhBK/z6Xx7D8ym7AK8VSgWG9eigV
UxNtXnW7+G1wgy0ipFXfM625ZiYkEt2wh4uag134zAUcBqOom7Jya6Uts4Mt
XA46IGOXei5olokDaZSO3CWAl76kaPseX93OUnv0rZ46s738Sj3hyRAkjzb7
gOPrLZjCM217K/ymvQgG/kCpMs1k1BCVb4rMITVMFRrcrZ0dn0RtxtEwuckX
29QpPO601lPqLMEgsoqNPUN4HQ0DSv6uMDGt2GCiahPF7rV7x9dW2Z6l1Srv
vySKsx4pMcYnNBs/V3E/kddtvZZE98g84TiYBXA4tdDxax3VHs4253IYSIFH
OlW3zoFsraqvP7yXaoKoPh4MmCvKLUv2Xsta7uIsdcHSvWHYmd7dN1HZr0qo
KAcNd+cJB+1CcRNY+iEoxCFnZi+k10K1XUmcORjoF1wwOZ1+26e7I+2u/gJe
39JZg4RYZJDZkxkXDYvgSNUY4ZL2Ylfg9sIYg5TIUr9WWEH8faLsAxu+FlVM
4fc3mrMds0oQcAbzCw0Sb6/SlGp5czhR4f00i3mbaRstGNIX8EZfOOIEwQ8G
Uy5ahft1X5+WfSt7iYGg9E6LO/GTrGtM8byoaiSiQLpKjTKo5STdalMxfjab
iHkBWidv9weNJoMRIrLKPzPwV95SGFJYMvk6WAWaNNpDjyp4JTiy20graqnX
F8swRInaLDGBvrdDp0EL2OZSGeHOWW9ggCenv2eEQQhBjMk5UXXmppGWrwUx
Zi89qrfRSHDkyysXGMNofstMMVGxoJLDmbTqfFmLigniQEcLm4yvW24xksQt
aW5T7QRG3ePLDqkZRdEEBhRkI7wDSRKtaEM5j7wDoAqHL96ecw6LFmVIkVEu
wiP9K5yqEkZVpGza0tI+Gyea7SaX3gjrFEkuMp4WIvmZq9rJEDzFzckNJckV
F+9hrmMX1pFOCQaPeQAXDoAnvRSwhUGrmRAuB9WYED4CF0Sqe0JVArms/SbM
7VVgS1zYnBPBC8sqXOAFbbY8MFpfevI1FwZmfeZ5y9rd6jEEKdHuUA248FTI
shPxLFeeH5FUJFxqaENeLwbj4UQgeIxX6+HRQ1HeHE3VU8R1naiqtZCNdIHa
DXpYvQm7ESZIMccnWOXgDj/byhYeuGOiRSzmLv6mlQAoO4WrOUroPRNjTKcb
zxyX0YLkrJlbyu/WwG9DMR1E9vfoMLjz69YPpZ0ZU3eGIqK8Ux06iAlsYahX
WsOGlJfsfCs8M0Jlktc9x9KeueZp0zuHiaE6fz1iglH4SFSEnFNh6NOmHlil
W8w5hNwiV9FLNDK12oHRr+eSKqOka+g8q+it13W2utHQw0W8EFG2KQoVtZcM
BkyzQRRDIe5LKqQjyo7ZPi/K7lcR0UgyYjuaN1ZKxRYontGN4RrvvphloFvj
Lc0ZAYKPwxq66JTw9RSljzYRU9AFFim+RxW/kbwXae4mpqa+JWuAi0wl6cgY
nI6BTQKZ8om4s7EXsNmePTPeOymcVBN/tnPFxMVitOWZuB0CV3qlXs5pOIPP
wuy9DvnKgYMHxmzQPtM8oWnm6DhWAtxtN0VkaoSPE5C3s3ELrueT7G1OKfFL
JuMP1ado3+ntBd/GlJCwn1czrQJg79fsK6Y65cCappc0ESF5+DreAz6f1s4M
19wNlKd354Ie6jdKRSZzYEhVaSspI5nkPWC1T4KhMdMBhksvq3RzpREiyVdw
KpS9kr5D4hIqUs+9KstrjPbzLk91PDop5HCJS8HqkKTUPn8kGDWmP9ioNJ3A
SxYyGgVGpika02zKIotuNpCQPtip133hbZ/f7QRqxomW0TMzGfmYYl4Lz7S9
hNsEWvIYeRTkPsQ83lxmmApAPfYC9bzW/QF/13CAeJ7xnJ7lXKCSSYRv+jOu
2w9YIqF9108d8dMbwX38eq8mK4M2lWAufPCoZtdBg5Baqd6CqwxCUMlxmPE5
UsCKxBmwr/sq9QRwfFmV19cOOS5i5L6HlLyUlpFSfO5p4ehUypMIY3IXTha0
wEat4b5NIWD0qE0Bpa+kOs2s8na7C/fucxyoOUIxyZxHA80G1hkjRKsZ4oRq
3+Gr6LZY5njDESEyDZhiXN9s0C0aQjqvL796+sjJgEczJawB+VxnDMcL+DAY
IpMEWasxkYH9SYrgjw2UfxiGmCNQ0WkAWh8CA/bWeTD0gHi/FRzPEcePEPoz
zKjD9iNxwjcGudkbn5TAqsrREB1tSqt109BoT0BSQcltHcCy3QPuG6y08myC
Jjv2B08VexGfNdYi/UBeHb3umY8OnYdk4ZRPfI9tESQfjiZUTOsYUczfieML
yORB8OARA5nWWENJEaY6cE+l9TxFrzdsejsWJfsrm63l85mwUCk1meXDU8Oy
CZ9txHv1AvCDiV4Wyizy2KTmFIngupA9RtUDLQJYR3BNEeHKrYpeeYhZtTH9
iG93QxOIw6BaRVG/vS6SwS7wWLFMXFTpksiYrPQ/OiSTvf5WHShPBFzMmYy2
dMcpRMQalfaR9XqhQXVpQsPFCduIF4cI4HMN+hJjB1tV6GGUtc9o4bOctdJ3
rF8i7cFiO1dtqNUwSL2IndoK5tphvZNGBIgix/tgWhh6KDcGNhAZDpuSqJ5c
pU4MqDWrexQKSSSF8GE8uGW7iOtPIysMhUoqCiKaFQ0WWaBgwMGivAo5iPsS
Aoc581EgiQlE4S7GuqYE0azK1AqlArMrHmzUNdwnpsRI5FbrLDlQgv6SVFSv
0XZrI6Ok8Dl7T2nV9gAmLnUnBDvUTVlaTop3E3KxH8sz+MzE7Ig3iGQcHzDW
ywFMEVSacSXruRrjvqROcZhpHdcC6RKq4GVCKylniiwKUVs+FoFPorAado5b
gIFKU2epDnZt5choJud4kEYwDG3uBgLgtipJ6voQweDC6o+kRRIZGP1FdlYe
RSKzljOMj5Fuhrec6vIE/zBwtiClGD51sQbiz8nEAlNbDiPstLoce85bHK3c
OnQweLvFNDUOxNgnYtVv+cadsFZZNwtNXeAPX5iJxo/2Lh9lwGgKvKtjtSoq
V84lf7S3VLC7GxwiKupKHpXsCT/yL1KJ6hjQncAdRaWDARB4eDB74jOsmFbQ
p3BLk2CbxlWR8f4QUkqr/MJKcGqg6A8HswNQExWViG91LZ7lLLp/vUd8oR8i
FHfPVZiGxYWcYi9y7LOLpbiLlKTEKuJuQBtOHvoC3tDZGZ7+0J0F6m7uSicZ
kxLwHEZg/lLUnRif3Lxr4dxUDDeYjloFOgaeXz1n/jF27/PuBUqIxLBB+9h4
JqPyYAKhRNekLr7Wd1gpC0sRxLCNH35yKrYF9jWGUxlcChO3pmMIynr4/Yvz
5AH/x9BeK2psjM4cRujtDYZlMZxYRyZrZFVhYMtftVwKfyIWBTw4nB1KXqTZ
bbh0UHZQbtBDxLE6zjWNZLOTILX2FtYWdAn+zfmFPrY5BooGeKjS+hOyrFoo
vtElWGrNkrHRNgsthcyxkQOopdGVTx4RwM0J97HkHZptVcTjoFAIDYGUpN6n
MrQ1kZwavjL81u9Ot1VYrDx5dEib4CUXl0980NzeEMWmbbvctRkES4NExazV
U4VeVRkgXj53kX+j/aGlVXyVEmoSnhDfy3KEYbfjj0gMeF8wmDW5P2+udmho
ID/9dshh03BUjtrdAyQo6YHYppIZdcwCkrBsVH1VUlRMxgxGT1k1SBwsPFUw
UPv9JZE7Ku8QcshmK6nFTl1TN3pArb0m4aZDDiUNlWxkhDc7++Hkxx/HgQaQ
BJtx7vRyArBFhQlIinjwmQoFuWHNnaetOTziEcAvMCouc8AdWrgLF6VzMfyp
cU9LgQSxClo5Lm8XY1QlpgjRsJ/Wea2/MmYhMUYMKJZws0CZxNS1HNNzJd1h
tQNZoNaoArRcAV0wRRbYqK1vheK/M0eqeCenQV77XKYlK0upQsJpk1UOPO1w
NzSx0S+vneEtYB2RLqFqWWl5uEiBOnMyvZrn/+ko8w7vjyDhCNzdigTFyvpD
BALWqnANyBrjNTF/2QKHM1rvV8h7WYZ49K7gai/VT5ddKFITvUdVzAtVLW25
6QrFq32mCLkjQ9Sq9ZDXpzPkiAOpjvmIOhe7ziaPZw9d6epvJin6uUMZ8reV
ChMvqTir7SfY5KDSCXgQDJWihI6pchNja6qVfBjJYWtrP6NLQ2FfrlVwxoeZ
z7EsGQywGQwIiJ12hMEQAsa96yuzApEKT31Vt+9QO/uoGX3a5r0RpRtw0k3y
L1lVcm0J+tEUpsfNfk0Mp7KRfCPMc2mEwn536BrNa0rgm8G9wDh3KnEK2YK/
3oNbIlF+Lc5rYAVED6ny0aWIqa3EFhJd4M0mCpo4NH7PPaRvr6jk2rX4lRW0
lJsun7X9jDmt05ijVCa1EQBDJdcgOThFW5RzpsOCnvs+iowkE8KdWjsh3TWS
VvsjNa4ut0gLsRA1ki9dMCupsUCsNW6x2qkBu3Yh9ayqY8mxd1ueSaDLzart
64p4rTwD5pWa1Pka3uYdCRAaKsnkqAGjVEFvkHtfnsZIwhTcnFvFUHMQv6UE
2vzZH2bRrUMbhz5aG04EhGXCo9s+tKxdKTbFilFmHZQnYrKZoppNHN/UIN5A
tiK8EoU2ZBe0Baf5jago1WO4qbPtooxXTzZQybY2vDSi1fiKmjAphBlHnhCq
1gpdBuV8ds8JbbWiZG9g38OiticUR2k92FSuQci0ZhRBsRWGPpS/5aSWCHfP
69FdNHq45VmbUxK1TXViCByqbSJB1h0UHzJuHcilPwzlZM+Z2vRZU0Rk/r8p
saE6QaDXJTZjOoPjMXKAsEnMLn04ZkYiZORhFaSSUgr4EIUiAeGe25OZxiUu
kmd2+4a235NHyYjnaTqWF7vAisjQc4UL0q4yeBUOeQc8VUZtJVA2PXkEVlJD
lMqeNZskxsmLsz8fHn3559PTV3/+kpuvpzqJkjmMd7MeiC55KF8iOkL4Wfe+
QtQnC0TxAvyONMDDd2I/o47bqQsSenSFxqIn/0jBJV9z4SegTbxFoEKWJSPF
O2tLkkkIMYQu4Lw/As2uwAbupO5MsmY+U2pQb9N0+7HgpukrkWhV0XQNI+q0
wOJMWRAsiaRMAqPnY3SMOCliLbAXWswol4cGV3mH8kMtaJB3+WaLgHwMmPwC
1sEEXZWs4ZK6KpOunjJ6Mk7Au1G+jQA/XqXYv82QKNX8Ksdw5Rab19LBR8Zk
qRoVrKFUBMuOWa0YPknttiodMaKgdkxDLXEWMvvYtxcYGAiknNpTDPpormVC
HMQ/SGvHSI5sjFIySuCN2hfGxJTNOprQMAEHDy9GJojvq4sgAnjfHn02Vt1J
QBMWenCprxSx3JDl6oyZOOciIVIqwfN0MH8sAI/lKoYWmRBVvBdawDrrcM82
BuPKLkHIrcmVTCUu6C+mGiIjvocX5GZgE8dv2aache0C4kwboruaG5JcrqZA
z2t7cH0FDzbJvrfbYKDcHVHz9tAYhgj4o9Ir6yZSS6BnvUF4b+hTzVfgwtGi
Y0eZ1v3M2RJNn0Y8FpTD5jZnxjnQEbO11uPwACnbgdsKW1RRklPOnbsjxieq
DM8uy7dPv6kmTqntVeddhKBI2+q4FuMCKcbWsx0CgtDG7dKahAXvwPvSZgy7
+7B10VknvDNxm0y0LzCaJM6GTRe/KFO9tSxv9cj2HVhb/QJS6l7j1gqh+UxJ
TbzqOVOk4CEj/976ZQvuabuBMS/Rwfzp3KxQTMaBzbDALrHkk8NCZdqW/RIs
J3b400VeTh1dPk++Yeys0BK3nOxV7VEgu9UOZuqVJ9c/42VVQq4sGktSAsin
3HWIV1OKSqjVDQOvusCYCZUTmEkdpQMsXEtwH6KL0S/lsOgxxCGxfCf8bsPV
GIKyllFiYgkusxNp9kq5XNLrCO0RBVpWbgpmXPxANzQgGt00AtiTxJGTgjfo
tGShwLoCk6WvtPhmWeNkitXy4pc/Cu/MKfeEfMtD/oMILYxdhqXCtlXl4s7m
F7I1ledUu1KLssneX6Ww0XNPRx11ni1AiVmL7EBcigMNFYVvTHja2D5haML3
GYKwyK/GpUkSTbkjgIIn2GoAFhqUjHM5/eGUkNYgvNaxF4DrNBBQ2m70qYuJ
9T8OdZBRwM1lwyQw2JET3KqFArkTiUexVeSLdDPlE++GadhsEMPLN33tMuzu
DZdJxyAJ6SuT7KcG09u0vPCXCJiUTxsI2ji3eBr1QBRkIs44lw9p+DKqIEIT
0JHvC7P0BQ4FZTcIN+S/WCLElJNniH+SBKwWDnEZhlUbNYSw+yIOkOB1vm0j
w6lO5vaQtaf3HJGn5N/njjaPtOAhCu5GEbYPiZ0x7QQYGSjW8gJ3Y2qY+W2t
ThRtrKhVSOK7vExIClXZ1H9YO2gxQYhXiswdvSS0WM4/pVREeHLNFTBhzbVm
MOSOKFNNW6C9Q7Vuxtwx/+S9M+t6UQnPFOcLJL5pGTVHcs2rRWNoAXVm4wCc
peYG8EKakuLQDImcRWTXU4VDYo1iEc5Pqx20EMW2CleeyI0TjIFQXBFtfCAw
8CIuRpq0yt9C2Jip3RdREIrrnVKqv8WtJAH7NImZr7X1+aEor9R5GZoXgmdP
g6Eb8r8yBa8vmO3G80Erz2ILp8BBrjSkEeuSyz3ZPWoFTFUS2965SmvNC0nW
GabprY2H0qixrO9mPi7QkG7RqNeB6IJr+8ZutKZUhGMNSS25WsUwetzllhix
agnSyoYDJ16UCSc7MUCGjX7vGLY0r7HyqUXapG36RsVSEmPegncIjdZChBy4
4Vh+RGiQo26wBreSKdqGmK7yecOwQ4EGfwjProgPDO6NLtc//8fmm3/4ZxIB
apeKGQOD+AcXg7QFtbCahm/+gZW1RILAwMy5loAgnldkyfNgJyG+QYfFOaiO
4TDQTwZbvxXYrimiwHiHPhtSZp0CywPivntZhBZKWmjSVa+WxIBZffvi9PWr
Vy9+ev7iefALGSTEsCraUcoYZbWBtApOnOmxpltvKm7/LaLN9l6Nndno6IMJ
jelgNTx7z1jIq9PD+Jr2GLhSeBf4xo3UEOfBcrf1Ng8hNfql78VzZx5Jlr8n
m8QiA2lJNDHZdBGbWkxDDXjh9BTB5EMhdFPmXGGJ9X7c4isoBAezp5j0bTxg
G9maKWlDQyHSSubedYZN0U5tr63YawNNhsIC6TiS36TznnwWrPKNJrRetjCk
EkLAWAXCt4nHk+8zxfrNnEK8fsS571FU9YGapRtX8q4IbLrOpeNNhjBUqgp0
facC25fLdZB3rnURVZ9jVzoc0R3hCOzfy0gEsmrDgHwsIF9a/8sw+NAOMvOB
qPA8TWSpgcHWMpkCqs80VKkYTjZhpBJfuUGYjdgnOgYDpJzjSOm8LK/zrKcB
Fs+o9ckRHPNF6BmMTauumV1Hq5xZ2PsWCfpm86p0Hsf+PY4HFLQrcgPEaQDv
GbexlK1uRIRmWLl+g7WDoWgLM4nChSws2f8hdD1TyIWy5BVx1ynvCcn+oFBM
qEzUsGqMPTtFviJBr+MCTHzzBbYEyiXW68bthpgFFGNOMLxMnTSej3laOH+J
f90zB5Z8i8LoQoMR2z8wPl71Wg5C1g7zz5IXrSKgbtaZZHxWW5Tlf//X/45k
lpIU7lunic2D52JFUb5nTwwGb7YXoF6xrbowV4fMsms6IjSlNFBh2yQ3h8LQ
S6XKisorcCmwUhomd5Wl17FQ6ZZjIYozr5rldAO+weUUZC06idN8UU81CFWS
Tj1Xsc8doP2daBEnYqhTwWIf4dtVYAlhlinCS4pUC0W+o3OxvPjxxI+q8T8X
nHS+c8xWoNjr//1f/5u2Vo0EkUiZMhCrt4rtJ6rJ9cqNMESgBSYxdgL1in1R
lK7uMgI2WoDJgw21zdpMuJ2KboO4UJWkJTGuc3ucqBqw4RVCDWEyOi030dgQ
4klZQvInKJS0XZPWfHny00lXZeZpkaK2xC9zk4YSn1sILa5BhLQRIRdeqMAZ
kriQQrif+LuhOsk7280wVQ6RBE7aP/2Rk3AZuMOSx66v+dFSXMzHXJ7GCePz
Z89lFQkC6qokraQhL1vd5AilwDVb8vzjgWo/x2atzLPc8AClTGiEUJcYtDYL
PFPOzcPDw4MDvDF2Yax2LZT81755gXAV++TSvrvCLZVjOTwFc5b+dhxCmV+H
SBx8IlBzqrdEl6LepJzewrTMFBXMFFzpKWZ5Akc8vngIDmMCWIK1BvKJGqMw
WudSqkfLOZxVqeELxXlY6Pgep0IxWUVyKE/lW4+Onia/S0aHD+F/jx4/Hiff
JkdfEVkxrUz8chcCfqZsVd1oSTOXzRtvj8Y0SIS4dVVquvZameuzzBtBteQX
RrIHuiVBFBU3KI2KQJoU7XCuooCHEboojfE4xPddlTB9Qc9rAlYAqojKCQEW
mkYScWlese7nS0J7WPz9WpLcMB5yxZEcKxRi/dOf9ndI6ekC4j/DXijsHrR7
n7zNSLzN7aN2v5GP3xn7mzzG/ia0tnbnTkNBuPNfwtf+T/xfOgzXOcWfjP47
/6Yxt7qZoJiMW5n0yry9PUzAF55S+g8l8SuK0rMF+H3IBtHcyB0l8/DrPRe7
Z2GpfNtkbSnhdh/ETrBeVdbOIpORhHBhQphnDD3IWmxeYA7D/udyVU/HthTX
ZNpurU0Z6yJTauyi6V5REQ/WKjJtauUGIUVDHKetEABcKeaCJ6EiUvfuldaj
t6Vsf4OPA8fouesvZW/O2dKQGqvSRYayLLqjBgR7F0PMqDXi+7hKib2/hpAb
8XecudYIc3jtTmFhSQNa3Im6WcuGYwv93w8C5/CfZr8l8yb98Tp7nCCeHRwT
6hqsmKAMBzMkR3n3eSo1BRSeiTpWG9bO3aR2FdURjZrkSE8QC4M/f3pEeC65
w014kYf8RYgQTD6+ZfDdvmJMhu2C/g2EVx4+LAJ+g/iTFe4SKnw8mO11HMeI
wEDaic2TgRJGFN8xiyGiDBLANsfJNwggg71VXII5gDidZAo66vJoVEgfT/+V
vtE6fY9mKlfiYxTPeRRoK2gmMjoDDKHL8WBWa+mxTkZIwKZZ+HKRbVbljivU
MYIB+zb59pvkySODL8hUrtgPx9iLwBF5w3LXZknjcjSGI21NlYeCL8Qr0G5S
bCujsBZx3zJWXp2lPo62TFLJdWfSLBjXuH3JJGympDnwz4AfC+cwJYSJO0Pi
jQRAMjFOa7BfZgvDGGLDwIeMOpdIUW/BvxQzEIyiRDpKRe2ovLTljsQNwjmO
/ml2d0b7riNf9CKJmvinYYK4HDmS4ZiRX22NLqFCIlAUpO2TSr+lmaA6rNT/
ELM/qo8k81tp28LDh0+SHcybnK22iGIkFVbtxPDzmFZTHQEK6OszYghmlLsG
m6DgAM0Pr05Op2c/nEyPHj9p6cpZ8jOPtfOqnGEMoNRPFFKHRy0pddaSTQx3
Z1BWgcQNzd9C4OCTEPrHUuWvPM14fK8V1BZOb+A7m0v1DDN8tRexXc4o4eUY
AigR7RCpZrAIZmR26k/HW1gJj3P1GS4yVytIXiPZNkjPlDzPlGxIgmowb/lc
GrDRZbTZV5d4Aq/WtRTLciGedrgK/FxsMN7AySor8cNyZZbNu/E1sXKwbgHb
LNx+otzzQmyCyzm6hnEdjHsloDs01/9XJF58+jCEgKrTA5IQIxViqiz+GmQm
oy3yG0VgYlXlYeQaGlKgADuIxBBhlpW3qOLbT4TEuI9IwOgS2gYajF8OBidd
/tmWYYKbM62YHy360fifYfwPQYS/QT6YmtySUy5e0TwbO+mKaZeoGxe2xTkp
jHNRaSWm+yIcf6izZZj/nVagOCxaQqNJiX1E4RTqQECiSz1hxWzOlcPrVISU
3o+CkPNKeVK5Uim8PKbQuC0QbRNahCZVmRC1LTGDOaMV1w7hI+1wQC+Ohvhx
IM8g8J/0ntEIpZUt8INi6At2IBoTGEq5y6gt4q2ybLmh6xtqWMWxwbpWU2pO
ykLKDjvLCBF+pksqcYQQrowC03GRRntxP01iyGh7BYR+92mygTIpeXQ65R3t
kDJAgBbTr5r4YHCGEwqr0ttjOy6JTvnSdYxo4ry3XSr87csmIFloEaVGtVVf
53qQscTpCq5tIN8kbjxkVV6GK9DjGhAvoHdrqaYx9ECKTGzu89mrxQThyIUO
zvrozYT2qAp75SDjIqpQfBnP+U26qd6vnEbp7HqWzjAhNc/GLMQwzysqtU/5
Gch9sSDRsSLtyjWec6MEZU1eguoXMLjSQeCuwEI6Cq5HvdQkDHmGNtNLQvkz
DCJ04enlGO6SZ4UTRKxAH+eDQumEwViki5Xh4eYuXC82KpLAzmQjytELMd9q
dxwE9ER+4ztsUbkJg7/MctpwCiTyhpdpvoKJ+lohYnovqTgJj99LIssO6jiw
AN3dh1yK+quU8Cuj+CUaKwFlpA6ddm7oLj0f+rh5DS7koF5jJhmRrIMxFUzc
3HKXIrDM+1siaRgnbQIYTpJlMToqoEA+1rep293FqLHpNDOtc29atd2CUxum
4LnjaPp+kkASaaPD5BmF82WfMZhS866c5sMLp9vNJEEHRKx3kmu4BBRboZSf
xsVHR3TLcLSY4t2KG4WWs00TwWuiv+Etti1cDUNMk00HWlhwQ02C6GXiIIi7
BVspwnhvGpQNEKs+XeAU0ZPJp1E4Ih8Hdh7qjI+LckKGfm8zvtj1QujYSsrc
wjAPzndranthwRJ0t+ikRUe/1ZI2hjOK6WvGC8dj7dAtJevu2WMv8VALelsp
6/HJne4vbUxAq6WEbwtyLzklcyj5sbzELGGyJ0kIdlh5o3z/IkAE8L+hFDyD
bhPMinwh96wFU0NEhtM8a5bMb0RxdnlTavdz+BDNhi+SVzky/vLTqWo3f5+R
3v4i+VkYBbPiCqG2pLePySb5gvVQMv22X13JRT5/DycTuw549x/NDrpDuAqm
6YbYAIyMD00fGk0L4Wt8DzxWfvtVybQS8HYCuxwZbnS7oZZFhNGiziX8FGVK
4doFNCLwdmfUe4pSIbgkQ1TtEYE074Q2icgQ5uXWkzrBdmRSCkTjFLs13/2l
vvENbhLNPsFgwE5Mnj786oDLCW4pfd5ayMuq3G4wZz69yOvPWfcjsCXYv6HQ
MWXf1R57+eLse0R05dntGLcHliCflthEHicMW/ZwzxcHo22Sv7tqmk19/ODB
JYja7cUMbvmAnn17+aD9+AegkC4erDGPWz2IbzpbL76VLAs/cw1iEYeIEUdy
JGkXLBau90UyhLenbVXpBiwF+OX7Xw1nYkmH2Wp3M5D6abTc51lUkQLygOQP
c2bipsmqdR3u+LJw1C0TBoeLKJHqRB0a7kzf2iyqBEV8S5XeFsEwjsbHtB7O
Mv5aMQGEjYv9b76YoAsnsZX/R/jwT1gcuAibsCx429poGXJeSydes6Bme5ZA
GXVOmDRbTMtXgfKnw6wjqLLhDJ0Dw1TSZNu5ICA0HXEi58GDgSnW2wdVE4NG
wnMkDaR2r558rOulpWX/bJPSzre3iUYd7nbsFphVj8wEfgev5KIT86uMCxaF
FFeYA8jVtzZJI1jhY/goq8Zh75wF7zmNxrFMyernYrKAfNuuFWc7Cm93nAxb
IUwklrPOJxMBaI8T5k9D107Ko20c34G7Wi6QZJQlviTf0aUzx0aYAShvMZRF
G8qu46IaESvHtJmxG2DjwdxkrMVUONRYZEKbb441fMSXqR3JuOaZMDu22rJm
zwlxkwx7EWrDxIhr3Q6IyjJCP/Sv4eALeGHOHsvcTq+eLbxTHRjhQ58rFAT+
ULRcSK2m2fagSHs6C/F93vS6o8d4f4pjSdMQmJU0l6iTousd/i30GdL7vgh9
36UFLzXzzVzCFKlWfaFmWzxqj0y9JW2aZZd56ofpqaJkj7mK+guFj36BKHx4
b6FFDtjU0RtbKoovMAA0zRcWbt7FRdKOLYuP/cTgTZTKWQkHDonjEBcR3rHF
bCwvcUr7Ti8OyV7L9UoqxpcUyP7wBcPWPprbgIbOAzwA66zEeP1QnJA26cQy
IEQ0QtQCzMuHvHHlUjYcrwn4E5nfciQlUTrkaD+AsXqVVd2VC60sXGCEilQy
cBy+Ojp4evD0yVM0U1/eX+OpaaiaFoT/Sz7wxX0EEal7xwE7slKX3OoZKyF4
UG8zZvFLTmUX7CzrqV2qjpPXvLpLX2ID1guTX+rCD2H7rxkLPRz7eIwQ+bMf
TRBLJofQUMb7XaDL5UH9PVajLne8FkPeR0Nqasx4De2e6+RvhBrQkQeB+ZPq
qRC88ftehkglnwzE495x9+EyeZCAI8uEGqtTSMORb9dtz1BnV41FIYMLWuo/
v3t5qmYjaMuvDg4Ovra2BKqrOa+EbnykbcwGDS+Im6vAdA8RTIL2Ff+E26p+
d/rk4aOn5i9vLqtUGLRJyh3OHuIbnz48OiSzo6E2UqdHXx4EjUOYS5Gzxr86
R9e3rKQIqN3Ah9/ZboFB1UdPD5wFLa8fjAgmnKHgH4z7fmgAzIETqxiLSnIY
BKcC4kXsGYWnZ6osOd61FMsOY8rYY5703R7bQtInRVZNHzCY15mC7gmMBh5e
wF/XaAUPhUelBD9nx+JluMiK3ZS/5HDBKls2giWVoiQ2ed19mVihXpWbzU7V
E8sXao+dVRd2MbuHop1FprTulCy2LG8yF9+1a853G9b3HG6tN9mKm6jYbJIm
0Xi/Fi0GhxTFOr5zFfaOCV6UzVxsAgbIJNDkt/gwkpEA51Wm4y5h73oxNg4w
Vioz93a6r9AOosqNLw5nh18wrjIXOQh6dKXAGqk6D/pQkLy09ahlLDdkoFT6
AmWH0PyX5YKsesSOzT7HqTuMnLrvs+Lk7fkkOT/7A/39elM/zyvz9cYDZxSk
uUN2eRq0pWMrrjXusHdHX+z4HPreXiSSuKOCtN19/XuxbFnpXXInSw7UrGUW
DXyN22HFUiWXPBUJiJWrWa8y9snIaToE/wAuRlRC1MlS26dzGfJNwNOTl6W5
eKZE0U42VgPpmh8UmPE18Yiq3FmS9IpDswmGcuH3+DwdAWZ2rde4pfvhp/kl
YfKPGEeVjKK6kVQTSqLG8QiOJ4TKpZC+TqHqq3kWY/b07hh3kcMnhv1OG2/O
DcdMyYSOoYc3EPCRNsdar9MKXI8XD95hId12jSapCBYqKQ1CAaOWmUB+Q2GE
dMCDMwoHHMak8hbRffN0kzfhtGrykFtMFJzSm5s/GiS0th4evfyDBlzwfKbM
GFY/QH0Fz33AceUH9szntEfD+QqdUVhDUAMiqdH7nNN5kIyeYTfx+3X3DJ4g
lDaS62UAiOg1Dt8Wi2I2zHtUFHoS5RoVuNETS1KTsPSd6FPtjErJMAp0QJqh
6KH+dHCv7lu5MzISCezGkVuZc2fBaOwqiyKd8n0EM8+JQlPM/7rlmbCRzTZn
5IpwjTaKB7RFcnRUeONlGWwHXfqzTbbibrqL5DTadp+x0AdfHYdlXVEkMCIL
Y4OPpipQ28a1y8jITi3gwIlh6lAqM/LUpXyZdguTM7DewFZFEc4JGCnpmhPr
VYU0hfRU7EOzrRpuoVjDOldUT3BBPlWthYn990SGX2yjFfkv3MaGGKipwIoD
ZnJWo5xOtN25mALnsKxbUc2Dr9xOdL1q+TekhV+Qe/ccK98fJI+OHifnZckf
6k8vago2H3u3F3cFaSpEyxiXcklhJXUGOSwfioSieiCzkuBHGIoKoWVNlSMQ
F31SHi9MqPVKGH/ObvrSdtMrpG2KdS+LiJYKFlY/rQIK8bP4mHndxA5ypKCQ
fj2ViLSxCJHOzFlSEe60pkAh1XFIfhBbEtTR/uc45+hw+pDSYeMo5ElaQuD5
INKRR4vL5zllZw2NfILPxURUzFF0TQuOUQ5c7wQcK1Esn8mKm71ZG016i/Ra
dvpmS7lWpI0B9xCBT9Yaj1Qgc8ZwHzVpwC6D+TFfYniWugn2EStq+EfKjUZ6
mLniUansuO43wktSqR33HyMP18SX1JHZ2qn1pMEnefLnbL+nyUjbyTrb8rsK
t0Y9T6nBN2UKbJu+DY3NoqNHpIXJ0PV5p2zu0AtscplDUMfLeLm7I3U6hp2N
TIS0Kc1528u6oOM703qS4+QVOi54i6bcICm3hPelgInIrDbSDxSsik2Dczqi
TBwJOinm/GWL8I8L7WKIds64+6zvUbi1WiypR57TlqakY5yWHVEkGQWd20hj
/Z0JBhehd8oc36dstxyXnwx7wRnDY5X3tQakV9J3STpBNzQHalhaXJvKudRQ
VC11LKYBIs5CUBnhY5zd6CmwUaUD27AzlKI0Mid9PvEbhO2Co4h56hl/oWxb
tU9BR49CNeORknLUo2s0SEgOX4zmYGuid/9z1rQdUx8y05BizkKDpuFHDhEH
JwUsB1/GeLus6fv5qTcWxVU2H8+glWBqmB+m3fUIBKBbuV8AY5wfGx4ySSW6
2dNvI0bCEa8BxQhyBCxsK4k8r1IOkdbjvrOtcLrEYhvSASAV3o2o3mvqcaiw
xT5H1D1xIox9GC1tF3td4sOh2TGy3+XGF+6bfsST9Dne/MHjY5/u3INQo2w5
2mvgruxWWRTHkUiST9j1ryHrCc+WF35C4T8ky93z07LQZ3bppWmfSiRlAXa3
4e96iLfDONXRRbgAvkao4j+WXo5LkJN4oPjpm6l0kbmlgWk5jDy3B6rnQ6z6
1NOWQ8XH9LWF5WQt8M8U4b9cttOpZpBOmQIZ5fjvTdYLZ7b7Jezk4BqsCTPm
HZs8lNlQqHD80WHE3oa7/CWKw/o2c12hJFNs8EGR5o5PI2pZ0Pgx59lM5oe8
KrkGbBn6cNw7sZrTs+K0wvF7UB6Po+nhHC55GoO1hshQCVhhNDcZ3k3CIyNu
2QRD40aKT3wklXQTHMwODqLa6zr8SMR6HW2PEFA65qkcovdFwBAY/VDLPYbu
JyFkxOew5kvDpwKILrH+dmQERhJxFr/IrQ4OgXmULMoXhweiAaunJBHpYASZ
u3SrWDfJ8geOAXebTl7C79XIq55YBHgirgQD5lqmymcIzUfHe17Yv+8rEu7W
sJ2FqNBATWHOY3IpT67GIr4p3VTvazwi0M+rigwKd3ZgtTEEnGGwHnTlsJQO
LMPPed+HwTuUpeo0zZkHsAtBmVruMQwSd7GZL2rmOOe4fUtLwIuG7lTb4mLS
meaKpcgb7CWjZrZ15HRKue8jW0OsmdrWoTRm37l4iLAwOD/BBie2knfEtA20
mUum6Mooxzvl6svwmJA41Ulv4eY0y/IZK3lkK6nAhk4YmSqvyI1S5btMhgaz
H7YWUPKuIeZ3pa3rEf/i+qcPcTDtX9O0eUddcq9M/6bRPO7Ie7dv/gdBJqz3
JZHunMZX6S+lZa8+eTIPbTI5xTgF10vvwVkxwkWhhy9lZAEjPZQrcZrCnVpb
j+ttcYttFA3gdxiHEpqusofVLV2Tq0RaqRqiOYr1+DuG9t4+888znVKJh/Eb
4htJ9IJA2Z1Oxp87qweK+3wrIiPgguoYwMKZkYq61OIRbkuQ+Lo9+6eVZuGs
D3H4tJ72CsHI3UiLdN9GiAHiCyVWOkl6V52MIOpfyIHmTj/46XWmkcXnVQlG
6iJExNinkmNG9s/U3XnE90CyUqqLQQ/4lhsc1ckbdF/xvf7AgKmSm0OJSfb6
AinAp6Zj+MXGdy9husZmMDWvIu+bPet4Hnw9az5pLjLlZ0304eBAuadrzbMN
39Kd2VDBPTDkiAnF2oNhwlMTdq/GomZuCK4d3kKc/ctSUftGlGMJIHz6o9nB
Q3we/H0Y5fnEpDW32Aios4YqvwLDmh+BDzH7rBnDwC1bPyI2vbEBPARqQEV9
jEGmG966ShRGYQ6jghcl2xrSe3lQaakluFqqS+3JDd0pzbpC+6vGcPk0V7ih
uMIHw3W31IYhdGbGDWKZSkKgBzQ1G1y/HouUyBbfDItyKGwsXCSGe0CdhbS4
HpymFabgkmdoeRfFZPC2hL+T5yDKVvntZPAsK35JQegnv08X2+vJ4NW2qmDn
/34Lh6lKb3eTgUUR4RSsCDKVI9vQ4O/zdXIGU5QuBkxLqM338FVT9rZd2RPt
+pnQzyxX2+Vy8H8AYCJiJHMtAQA=
</rfc> </rfc>
 End of changes. 79 change blocks. 
2434 lines changed or deleted 1784 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/