Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processingchristian@amsuess.comEricsson ABjohn.mattsson@ericsson.comEricsson ABgoran.selander@ericsson.com
ART
CoREOSCOREblock-wiseDTLSfreshnessdelaydenial-of-serviceamplificationMessage Body IntegrityConcurrent Block-WiseRequest-Response BindingToken ReuseThis document specifies enhancements to the Constrained Application Protocol
(CoAP) that mitigate security issues in particular use cases. The Echo option enables
a CoAP server to verify the freshness of a request or to force a client to
demonstrate reachability at its claimed network address. The Request-Tag option
allows the CoAP server to match block-wise message fragments belonging to the same
request. This document updates RFC 7252 with respect to the following: processing
requirements for client Tokens, forbidding non-secure reuse of Tokens to ensure response-to-request binding when CoAP is used with a security protocol, and
amplification mitigation (where the use of the Echo option is now recommended).Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Terminology
. Request Freshness and the Echo Option
. Request Freshness
. The Echo Option
. Echo Option Format
. Echo Processing
. Applications of the Echo Option
. Characterization of Echo Applications
. Time-Based versus Event-Based Freshness
. Authority over Used Information
. Protection by a Security Protocol
. Updated Amplification Mitigation Requirements for Servers
. Protecting Message Bodies Using Request Tags
. Fragmented Message Body Integrity
. The Request-Tag Option
. Request-Tag Option Format
. Request-Tag Processing by Servers
. Setting the Request-Tag
. Applications of the Request-Tag Option
. Body Integrity Based on Payload Integrity
. Multiple Concurrent Block-Wise Operations
. Simplified Block-Wise Handling for Constrained Proxies
. Rationale for the Option Properties
. Rationale for Introducing the Option
. Block2 and ETag Processing
. Token Processing for Secure Request-Response Binding
. Request-Response Binding
. Updated Token Processing Requirements for Clients
. Security Considerations
. Token Reuse
. Privacy Considerations
. IANA Considerations
. References
. Normative References
. Informative References
. Methods for Generating Echo Option Values
. Request-Tag Message Size Impact
Acknowledgements
Authors' Addresses
IntroductionThe initial suite of specifications for the Constrained Application Protocol (CoAP)
(, , and
) was designed with the assumption that
security could be provided on a separate layer, in particular, by using DTLS . However, for some use cases, additional
functionality or extra processing is needed to support secure CoAP operations. This
document specifies security enhancements to CoAP.This document specifies two CoAP options, the Echo option and the Request-Tag
option. The Echo option enables a CoAP server to verify the freshness of a request,
which can be used to synchronize state, or to force a client to demonstrate
reachability at its claimed network address. The Request-Tag option allows the CoAP
server to match message fragments belonging to the same request, fragmented using the
CoAP block-wise transfer mechanism, which mitigates attacks and enables concurrent
block-wise operations. These options in themselves do not replace the need for a
security protocol; they specify the format and processing of data that, when
integrity protected using, e.g., DTLS , TLS
, or Object Security for Constrained
RESTful Environments (OSCORE) , provide the additional security features.This document updates with a
recommendation that servers use the Echo option to mitigate amplification attacks.The document also updates the Token processing requirements for clients specified
in . The updated processing forbids
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 client may
erroneously associate the wrong response to a request.Each of the following sections provides a more-detailed introduction to the topic
at hand in its first subsection.Terminology
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are
to be interpreted as
described in BCP 14 when, and only when, they appear in all capitals, as shown
here.
Like , this document relies
on the Representational State Transfer
architecture of the Web.Unless otherwise specified, the terms "client" and "server" refer to "CoAP
client" and "CoAP server", respectively, as defined in .A message's "freshness" is a measure of when a message was sent on a timescale
of the recipient. A server that receives a request can either verify that the
request is fresh or determine that it cannot be verified that the request is fresh.
What is considered a fresh message is application dependent;
exemplary uses are "no more than 42 seconds ago" or "after this server's last
reboot".The terms "payload" and "body" of a message are used as in . The complete interchange of a request and a
response body is called a (REST) "operation". An operation fragmented using is called a "block-wise operation". A
block-wise operation that is fragmenting the request body is called a "block-wise
request operation". A block-wise operation that is fragmenting the response body
is called a "block-wise response operation".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 request
messages are matchable.Two matchable block-wise request operations are said to be "concurrent" if a
block of
the second request is exchanged even though the client still intends to exchange
further blocks in the first operation. (Concurrent block-wise request operations
from a single endpoint are impossible with the options of -- see the last paragraphs of Sections and -- because the second operation's block overwrites any state
of the first exchange.)The Echo and Request-Tag options are defined in this document.Request Freshness and the Echo OptionRequest FreshnessA CoAP server receiving a request is, in general, not able to verify when the
request was sent by the CoAP client. This remains true even if the request was
protected with a security protocol, such as DTLS. This makes CoAP requests
vulnerable to certain delay attacks that are particularly perilous in the case of
actuators . Some
attacks can be mitigated by establishing fresh session keys, e.g., performing a DTLS
handshake for each request, but, in general, this is not a solution suitable for
constrained environments, for example, due to increased message overhead and
latency. Additionally, if there are proxies, fresh DTLS session keys between 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.A straightforward mitigation of potential delayed requests is that the CoAP
server rejects a request the first time it appears and asks the CoAP client to
prove that it intended to make the request at this point in time.The Echo OptionThis document defines the Echo option, a lightweight challenge-response
mechanism for CoAP that enables a CoAP server to verify the freshness of a request.
A fresh request is one whose age has not yet exceeded the freshness requirements
set by the server. The freshness requirements are application specific and may vary
based on resource, method, and parameters outside of CoAP, such as policies. The
Echo option value is a challenge from the server to the client included in a CoAP
response and echoed back to the server in one or more CoAP requests.This mechanism is not only important in the case of actuators, or other use
cases where the CoAP operations require freshness of requests, but also in general
for synchronizing state between a CoAP client and server, cryptographically
verifying
the aliveness of the client or forcing a client to demonstrate reachability at its
claimed network address. The same functionality can be provided by echoing
freshness indicators in CoAP payloads, but this only works for methods and 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.Echo Option FormatThe Echo option is elective, safe to forward, not part of the cache-key, and
not repeatable (see , which extends
Table 4 of ).
Echo Option Summary
No.
C
U
N
R
Name
Format
Length
Default
252
x
Echo
opaque
1-40
(none)
C=Critical, U=Unsafe, N=NoCacheKey, R=RepeatableThe Echo option value is generated by a server, and its content and structure
are implementation specific. Different methods for generating Echo option values
are outlined in . Clients and
intermediaries MUST treat an Echo option value as opaque and make
no assumptions about its content or structure.When receiving an Echo option in a request, the server MUST be
able to verify that the Echo option value (a) was generated by the server or some
other party that the server trusts and (b) fulfills the freshness requirements
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 server can
determine that the request is not older than the Echo option value.When the Echo option is used with OSCORE , it MAY be an Inner or Outer option, and the
Inner and Outer values are independent. OSCORE servers MUST only
produce Inner Echo options unless they are merely testing for reachability 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 protected 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 encryption
(like TLS between client and proxy) is used.Echo ProcessingThe Echo option MAY be included in any request or response (see
for different applications).The application decides under what conditions a CoAP request to a resource is
required to be fresh. These conditions can, for example, include what resource is
requested, the request method and other data in the request, and conditions in the
environment, such as the state of the server or the time of the day.If a certain request is required to be fresh, the request does not contain a
fresh Echo option value, and the server cannot verify the freshness of the request
in some other way, the server MUST NOT process the request further
and SHOULD send a 4.01 (Unauthorized) response with an Echo option.
The server MAY include the same Echo option value in several
different response messages and to different clients. Examples of this could be
time-based freshness (when several responses are sent closely after each other) or
event-based freshness (with no event taking place between the responses).The server may use request freshness provided by the Echo option to verify the
aliveness of a client or to synchronize state. The server may also include the Echo
option in a response to force a client to demonstrate reachability at its claimed
network address. Note that the Echo option does not bind a request to any
particular previous response but provides an indication that the client had access
to the previous response at the time when it created the request.Upon receiving a 4.01 (Unauthorized) response with the Echo option, the client
SHOULD resend the original request with the addition of an Echo
option with the received Echo option value. The client MAY send a
different request compared to the original request. Upon receiving any other
response with the Echo option, the client SHOULD echo the Echo
option value in the next request to the server. The client MAY
include the same Echo option value in several different requests to the server or
discard it at any time (especially to avoid tracking; see ).A client MUST only send Echo option values to endpoints it
received them
from (where, as defined in , the security association is part of the endpoint). In
OSCORE processing, that means sending Echo option values from Outer options (or
from non-OSCORE responses) back in Outer options and sending those from Inner
options in Inner options in the same security context.Upon receiving a request with the Echo option, the server determines if the
request is required to be fresh. If not, the Echo option MAY be
ignored. If the request is required to be fresh and the server cannot verify the
freshness of the request in some other way, the server MUST use the
Echo option to verify that the request is fresh. If the server cannot verify that
the request is fresh, the request is not processed further, and an error message
MAY be sent. The error message SHOULD include a new
Echo option.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 certain
threshold T. The server can verify this by checking that (t1 - t0) < 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 .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 application. In the
following, we assume the cache size is 1, in which case, freshness is defined as
"no new event has taken place". At each event, a new value is written into the
cache. The cache values MUST be different or chosen in a way 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 value at the
reception of the request. An example message flow over DTLS is shown in .When used to serve freshness requirements (including client aliveness and state
synchronizing), the Echo option value MUST be integrity protected
between the intended endpoints, e.g., using DTLS, TLS, or an OSCORE Inner option
.
When used to demonstrate reachability
at a claimed network address, the Echo option SHOULD be a Message
Authentication Code (MAC) of the
claimed address but MAY be unprotected. Combining different Echo
applications can necessitate different choices; see , item 2 for an example.An Echo option MAY be sent with a successful response, i.e., even though
the request satisfied any freshness requirements on the operation. This is called a
"preemptive" Echo option value and is useful when the server anticipates that the client
will need to demonstrate freshness relative to the current response in the near future.A CoAP-to-CoAP proxy MAY set an Echo option on responses, both on
forwarded ones that had no Echo option or ones generated by the proxy (from cache
or as an error). If it does so, it MUST remove the Echo option it
recognizes as one generated by itself on follow-up requests. When it receives an
Echo option in a response, it MAY forward it to the client (and, not
recognizing it as its own in future requests, relay it in the other direction as
well) or process it on its own. If it does so, it MUST ensure that
the client's request was generated (or is regenerated) after the Echo option 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 value.)The CoAP server side of CoAP-to-HTTP proxies MAY request
freshness, especially if they have reason to assume that access may require it
(e.g., because it is a PUT or POST); how this is determined is out of scope for this
document. The CoAP client side of HTTP-to-CoAP proxies MUST respond
to Echo challenges itself if the proxy knows from the recent establishing of the
connection that the HTTP request is fresh. Otherwise, it MUST NOT
repeat an unsafe request and SHOULD respond with a 503 (Service
Unavailable) with a Retry-After value of 0 seconds and terminate any underlying
Keep-Alive connection. If
the HTTP request arrived in early data, the proxy SHOULD use a 425
(Too Early) response instead (see ). The
proxy MAY also use other mechanisms to establish freshness of the
HTTP request that are not specified here.Applications of the Echo OptionUnless otherwise noted, all these applications require a security protocol to be
used and the Echo option to be protected by it.
Actuation requests often require freshness guarantees to avoid accidental or
malicious delayed actuator actions. In general, all unsafe methods (e.g.,
POST, PUT, and DELETE) may require freshness guarantees for secure operation.
The same Echo option value may be used for multiple actuation requests
to the
same server, as long as the total time since the Echo option value was
generated is below the freshness threshold.
For actuator applications with low delay tolerance, to avoid additional
round trips for multiple requests in rapid sequence, the server may send
preemptive Echo option values in successful requests, irrespectively of
whether or not the
request contained an Echo option. The client then uses the Echo option
with the new value in the next actuation request, and the server compares the
receive time accordingly.
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
property with a client that is not the authority of the property being
synchronized. For example, if access to a server resource is dependent on time,
then the server MUST NOT synchronize time with a client
requesting access unless the client is a time authority for the server. 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 messages the
Echo option value is sent in; the Echo mechanism only provides a partial order
on the messages' processing.
If a server reboots during operation, it may need to synchronize
state or
time before continuing the interaction. For example, with OSCORE, it is
possible to reuse a partly persistently stored security context by
synchronizing the Partial IV (sequence number) using the Echo option, as
specified in .
A device joining a CoAP group communication protected with OSCORE
may be
required to initially synchronize its replay window state with a client by
using the Echo option in a unicast response to a multicast request. The
client receiving the response with the Echo option includes the Echo option
value in a subsequent unicast request to the responding server.
An attacker can perform a denial-of-service attack by putting a victim's
address in the source address of a CoAP request and sending the request to a
resource with a large amplification factor. The amplification factor is the
ratio between the size of the request and the total size of the response(s) to
that request. A server that provides a large amplification factor to an
unauthenticated peer SHOULD mitigate amplification attacks, as
described in . One way
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 message (e.g.,
4.01 (Unauthorized)), thereby requesting the client to verify its source
address. This
needs to be done only once per endpoint and limits the range of potential
victims from the general Internet to endpoints that have been previously in
contact with the server. For this application, the Echo option can be used in
messages that are not integrity protected, for example, during discovery. (This
is formally recommended in .)
In the presence of a proxy, a server will not be able to distinguish
different origin client endpoints, i.e., the client from which a request
originates. Following from the recommendation above, a
proxy that provides a large amplification factor to unauthenticated peers
SHOULD mitigate amplification attacks. The proxy
SHOULD use the Echo option to verify origin reachability, as
described in
. The proxy MAY
forward safe requests immediately to have a cached result available when the
client's repeated request arrives.
Amplification mitigation is a trade-off between giving leverage to an
attacker and causing overhead. An amplification factor of 3 (i.e., don't
send more than three times the number of bytes received until the peer's
address is confirmed) is considered acceptable for unconstrained
applications in .When that limit is applied and no further context is available, a safe
default is sending initial responses no larger than 136 bytes in CoAP
serialization. (The number is assuming Ethernet, IP, and UDP headers of
14, 40, and 8 bytes, respectively, with 4 bytes added for the CoAP 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.
When an Echo response is sent to mitigate amplification, it
MUST be sent as a piggybacked or Non-confirmable response,
never as a separate one (which would cause amplification due to
retransmission).
A server may want to use the request freshness provided by the Echo option
to verify the aliveness of a client. Note that, in a deployment with hop-by-hop
security and proxies, the server can only verify aliveness of the closest
proxy.
Characterization of Echo ApplicationsUse cases for the Echo option can be characterized by several criteria that help
determine the required properties of the Echo option value. These criteria apply
both to those listed in and any novel
applications. They provide rationale for the statements in the former and guidance
for the latter.Time-Based versus Event-Based FreshnessThe property a client demonstrates by sending an Echo option value is that the
request was sent after a certain point in time or after some event happened on
the server.When events are counted, they form something that can be used as a monotonic
but very non-uniform time line. With highly regular events and low-resolution
time, the distinction between time-based and event-based freshness can be blurred:
"no longer than a month ago" is similar to "since the last full moon".In an extreme form of event-based freshness,
the server can place an event whenever an Echo option value is used.
This makes the Echo option value effectively single use.Event-based and time-based freshness can be combined in a single Echo option
value,
e.g., by encrypting a timestamp with a key that changes with every event
to obtain semantics in the style of "usable once but only for 5 minutes".Authority over Used InformationInformation conveyed to the server in the request Echo option value has
different
authority depending on the application. Understanding who or what is the
authoritative source of that information helps the server implementor decide the
necessary protection of the Echo option value.If all that is conveyed to the server is information that the client is
authorized to provide arbitrarily (which is another way of saying that the
server has to trust the client on whatever the Echo option is being used for),
then the server can issue Echo option values that do not need to be protected on
their own. They still need to be covered by the security protocol that covers
the rest of the message, but the Echo option value can be just short enough to
be unique between this server and client.For example, the client's OSCORE Sender Sequence Number (as used in ) is such information.In most other cases, there is information conveyed for which the server is the
authority ("the request must not be older than five minutes" is counted on the
server's clock, not the client's) or which even involve the network (as when
performing amplification mitigation). In these cases, the Echo option value
itself needs
to be protected against forgery by the client, e.g., by using a sufficiently
large, random value or a MAC, as described in , items 1 and 2.For some applications, the server may be able to trust the client to also act
as the authority (e.g., when using time-based freshness purely to mitigate request
delay attacks); these need careful case-by-case evaluation.
To issue Echo option values without integrity protection of its own, the server needs to trust the
client to never produce requests with attacker-controlled Echo option values.
The provisions of (saying that an
Echo option value may only be sent as received from the same server) allow that.
The requirement stated there for the client to treat the Echo option value as
opaque
holds for these applications like for all others.When the client is the sole authority over the synchronized property,
the server can still use time or events to issue new Echo option values.
Then, the request's Echo option value not so much proves the indicated freshness
to the
server but reflects the client's intention to indicate reception of responses
containing that value when sending the later ones.Note that a single Echo option value can be used for multiple purposes (e.g.,
to both get
the sequence number information and perform amplification mitigation). In
this case, the stricter protection requirements apply.Protection by a Security ProtocolFor meaningful results, the Echo option needs to be used in combination with a
security protocol in almost all applications.When the information extracted by the server is only about a part of the
system outside of any security protocol, then the Echo option can also be used
without a security protocol (in case of OSCORE, as an Outer option).The only known application satisfying this requirement is network address
reachability, where unprotected Echo option values are used both by servers
(e.g., during
setup of a security context) and proxies (which do not necessarily have a
security association with their clients) for amplification mitigation.Updated Amplification Mitigation Requirements for ServersThis section updates the amplification mitigation requirements for servers in
to recommend the use of the Echo option to
mitigate amplification attacks. The requirements for clients are not updated. is updated by adding the
following text:
A CoAP server SHOULD mitigate potential amplification
attacks by responding to unauthenticated clients with 4.01 (Unauthorized) including
an Echo option, as described in item 3 in of RFC 9175.
Protecting Message Bodies Using Request TagsFragmented Message Body IntegrityCoAP was designed to work over unreliable transports, such as UDP, and includes
a lightweight reliability feature to handle messages that are lost or arrive out
of order. In order for a security protocol to support CoAP operations over
unreliable transports, it must allow out-of-order delivery of messages.The block-wise transfer mechanism
extends CoAP by defining the transfer of a large resource representation (CoAP
message body) as a sequence of blocks (CoAP message payloads). The mechanism uses a
pair of CoAP options, Block1 and Block2, pertaining to the request and response
payload, respectively. The block-wise functionality does not support the detection
of interchanged blocks between different message bodies to the same resource 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 , which is a
vulnerability of the block-wise functionality of CoAP .A straightforward mitigation of mixing up blocks from different messages 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 , set by the CoAP server,
identifies a response body fragmented using the Block2 option.The Request-Tag OptionThis document defines the Request-Tag option for identifying request bodies,
similar to ETag, but ephemeral and set by the CoAP client. The Request-Tag is
intended for use as a short-lived identifier for keeping apart distinct block-wise
request operations on one resource from one client, addressing the issue described
in . It enables the receiving server to
reliably assemble request payloads (blocks) to their message bodies and, if it
chooses to support it, to reliably process simultaneous block-wise request
operations on a single resource. The requests must be integrity protected if they
should protect against interchange of blocks between different message bodies. The
Request-Tag option is mainly used in requests that carry the Block1 option and in
Block2 requests following these.In essence, it is an implementation of the "proxy-safe elective option" used
just to "vary the cache key", as suggested in .Request-Tag Option FormatThe Request-Tag option is elective, safe to forward, repeatable, and
part of the cache key (see , which
extends Table 4 of ).
Request-Tag Option Summary
No.
C
U
N
R
Name
Format
Length
Default
292
x
Request-Tag
opaque
0-8
(none)
C=Critical, U=Unsafe, N=NoCacheKey, R=RepeatableRequest-Tag, like the Block options, is both a class E and a class U option in
terms of OSCORE processing (see ). The Request-Tag MAY be an Inner or Outer option.
It influences the Inner or Outer block operations, respectively. The Inner 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. The Outer
option is visible to proxies and labels message bodies in case of hop-by-hop
fragmentation of requests.The Request-Tag option is only used in the request messages of block-wise
operations.The Request-Tag mechanism can be applied independently on the server and
client sides of CoAP-to-CoAP proxies, as are the Block options. However, given it
is safe to forward, a proxy is free to just forward it when processing 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.Request-Tag Processing by ServersThe Request-Tag option does not require any particular processing on the server
side outside of the processing already necessary for any unknown elective
proxy-safe cache-key option. The option varies the properties that distinguish
block-wise operations (which includes all options except Block1, Block2, and all
operations that are elective NoCacheKey). Thus, the server cannot treat messages
with a different list of Request-Tag options as belonging to the same operation.
To keep utilizing the cache, a server (including proxies) MAY
discard the Request-Tag option from an assembled block-wise request when consulting
its cache, as the option relates to the operation on the wire and not its semantics.
For example, a FETCH request with the same body as an older one can be served from
the cache if the older's Max-Age has not expired yet, even if the second operation
uses a Request-Tag and the first did not. (This is similar to the situation about
ETag in that it is formally part of the cache key, but implementations that are
aware of its meaning can cache more efficiently (see ).A server receiving a Request-Tag MUST treat it as opaque and make
no assumptions about its content or structure.Two messages carrying the same Request-Tag is a necessary but not sufficient
condition for being part of the same operation. For one, a server may still treat
them as independent messages when it sends 2.01 (Created) and 2.04 (Changed)
responses for every block.
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 request and the
same Request-Tag under some circumstances. Likewise, that results in the new
message not being part of the old operation.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 operation by
replying with 5.03 (Service Unavailable) and a Max-Age indicating how long 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 Entity
Incomplete) to later blocks on the first operation.Setting the Request-TagFor each separate block-wise request operation, the client can choose a
Request-Tag value or choose not to set a Request-Tag. It needs to be set to the
same value (or unset) in all messages belonging to the same operation; otherwise,
they are treated as separate operations by the server.Starting a request operation matchable to a previous operation and even using
the same Request-Tag value is called "request tag recycling". The absence of a
Request-Tag option is viewed as a value distinct from all values with a single
Request-Tag option set; starting a request operation matchable to a previous
operation where neither has a Request-Tag option therefore constitutes request tag
recycling just as well (also called "recycling the absent option").Clients that use Request-Tag for a particular purpose (like in ) MUST NOT recycle a
request tag unless the first operation has concluded. What constitutes a
concluded
operation depends on the purpose and is defined accordingly; see examples in .When Block1 and Block2 are combined in an operation, the Request-Tag of the
Block1 phase is set in the Block2 phase as well; otherwise, the request would
have a different set of options and would not be recognized any more.Clients are encouraged to generate compact messages. This means sending messages
without Request-Tag options whenever possible and using short values when the
absent option cannot be recycled.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 reassembled them).The Request-Tag option MUST NOT be present in response
messages.Applications of the Request-Tag OptionBody Integrity Based on Payload IntegrityWhen a client fragments a request body into multiple message payloads, even if
the individual messages are integrity protected, it is still possible for an
attacker to maliciously replace a later operation's blocks with an earlier
operation's blocks (see ). Therefore, the integrity protection of each
block does not extend to the operation's request body.In order to gain that protection, use the Request-Tag mechanism as follows:
The individual exchanges MUST be integrity protected
end to end between the client and server.
The client MUST NOT recycle a request tag in a new
operation unless the previous operation matchable to the new one has concluded. If any future security mechanisms allow a block-wise transfer to continue
after an endpoint's details (like the IP address) have changed, then
the client MUST consider messages matchable if they were sent
to any endpoint address using the new operation's security
context.
The client MUST NOT regard a block-wise request operation
as concluded unless all of the messages the client has sent in the operation
would be regarded as invalid by the server if they were replayed.When security services are provided by OSCORE, these confirmations
typically result either from the client receiving an OSCORE response message
matching the request (an empty Acknowledgement (ACK) is insufficient) or
because the message's
sequence number is old enough to be outside the server's receive window.When security services are provided by DTLS, this can only be confirmed if
there was no CoAP retransmission of the request, the request was responded
to, and the server uses replay protection.
Authors of other documents (e.g., applications of ) are invited to mandate this subsection's behavior for clients
that execute block-wise interactions over secured transports. In this way, the
server can rely on a conforming client to set the Request-Tag option when
required and thereby have confidence in the integrity of the assembled body.Note that this mechanism is implicitly implemented when the security layer
guarantees ordered delivery (e.g., CoAP over TLS ). This is because, with each message, any earlier message
cannot be replayed any more, so the client never needs to set the Request-Tag
option unless it wants to perform concurrent operations.Body integrity only makes sense in applications that have stateful block-wise
transfers. On applications where all the state is in the application (e.g.,
because rather than POSTing a large representation to a collection in a stateful
block-wise transfer, a collection item is created first, then written to once and
available when written completely), clients need not concern themselves with body
integrity and thus the Request-Tag.Body integrity is largely independent from replay protection. When no replay
protection is available (it is optional in DTLS), a full block-wise operation 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, without replay
protection, recycling is not possible.Multiple Concurrent Block-Wise OperationsCoAP clients, especially CoAP proxies, may initiate a block-wise request
operation to a resource, to which a previous one is already in progress, which
the new request should not cancel. A CoAP proxy would be in such a situation when
it forwards operations with the same cache-key options but possibly different
payloads.For those cases, Request-Tag is the proxy-safe elective option suggested in
the last paragraph of
.When initializing a new block-wise operation, a client has to look at other
active operations:
If any of them is matchable to the new one, and the client neither wants to
cancel the old one nor postpone the new one, it can pick a Request-Tag value
(including the absent option) that is not in use by the other matchable
operations for the new operation.
Otherwise, it can start the new operation without setting the Request-Tag
option on it.
Simplified Block-Wise Handling for Constrained ProxiesThe Block options were defined to be unsafe to forward because a proxy that
would forward blocks as plain messages would risk mixing up clients' requests.In some cases, for example, when forwarding block-wise request operations,
appending a Request-Tag value unique to the client can satisfy the requirements
on the proxy that come from the presence of a Block option.This is particularly useful to proxies that strive for stateless operations,
as described in .The precise classification of cases in which such a Request-Tag option is
sufficient is not trivial, especially when both request and response body are
fragmented, and is out of scope for this document.Rationale for the Option PropertiesThe Request-Tag option can be elective, because to servers unaware of the
Request-Tag option, operations with differing request tags will not be
matchable.The Request-Tag option can be safe to forward but part of the cache key, because
proxies unaware of the Request-Tag option will consider operations with differing
request tags unmatchable but can still forward them.The Request-Tag option is repeatable because this easily allows several cascaded
stateless proxies to each put in an origin address. They can perform the steps of
without the need to create an option
value that is the concatenation of the received option and their own value
and can simply add a new Request-Tag option unconditionally.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 understanding of which
blocks could be composed according to .Rationale for Introducing the OptionAn alternative that was considered to the Request-Tag option for coping with the
problem of fragmented message body integrity () was to update to say
that blocks could only be assembled if their fragments' order corresponded to the
sequence numbers.That approach would have been difficult to roll out reliably on DTLS,
where many implementations do not expose sequence numbers, and would still not
prevent attacks like in .Block2 and ETag ProcessingThe same security properties as in can be obtained for block-wise response operations. The threat
model here does not depend on an attacker; a client can construct a wrong
representation by assembling it from blocks from different resource states. That
can happen when a resource is modified during a transfer or when some blocks are
still valid in the client's cache.Rules stating that response body reassembly is conditional on matching ETag
values are already in place from .To gain protection equivalent to that described in , a server MUST use the Block2 option in
conjunction with the ETag option () and MUST NOT use the same ETag value for
different representations of a resource.Token Processing for Secure Request-Response BindingRequest-Response BindingA fundamental requirement of secure REST operations is that the client can bind
a response to a particular request. If this is not ensured, a client may
erroneously associate the wrong response to a request. The wrong response may be an
old response for the same resource or a response for a completely different
resource (e.g., see ). For example, a request for the alarm status "GET /status" may be
associated to a prior response "on", instead of the correct response "off".In HTTP/1.1, this type of binding is always assured by the ordered and reliable
delivery, as well as mandating that the server sends responses in the same order
that the requests were received. The same is not true for CoAP, where the server (or
an attacker) can return responses in any order and where there can be any number of
responses to a request (e.g., see ). In
CoAP, concurrent requests are differentiated by their Token. Note that the CoAP
Message ID cannot be used for this purpose since those are typically different for
the REST request and corresponding response in case of "separate response" (see
).CoAP does not treat the Token as a
cryptographically important value and does not give stricter guidelines than that
the Tokens currently "in use" SHOULD (not SHALL) be
unique. If used with a security protocol not providing bindings between requests
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 delivery or a
server sending notifications to an uninterested client.A straightforward mitigation is to mandate clients to not reuse Tokens until the
traffic keys have been replaced. The following section formalizes that.Updated Token Processing Requirements for ClientsAs described in , the client must
be able to verify that a response corresponds to a particular request. This section
updates the Token processing requirements for clients in to always assure a cryptographically secure binding of responses
to requests for secure REST operations like "coaps". The Token processing for
servers is not updated. Token processing in is updated by adding the following text:
When CoAP is used with a security protocol not providing bindings between
requests and responses, the Tokens have cryptographic importance. The client
MUST make sure that Tokens are not used in a way so that responses
risk being associated with the wrong request.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 connection.
This approach SHOULD be followed.
Security ConsiderationsThe freshness assertion of the Echo option comes from the client reproducing the
same value of the Echo option in a request as it received in a previous response. If
the Echo option value is a large random number, then there is a high probability
that the request is generated after having seen the response. If the Echo option
value of the response can be guessed, e.g., if based on a small random number or a
counter (see ), then it is possible to
compose a request with the right Echo option value ahead of time. Using guessable
Echo option values is only permissible in a narrow set of cases described in . Echo option values MUST
be set by the CoAP server such that the risk associated with unintended reuse can be
managed.If uniqueness of the Echo option value is based on randomness, then the
availability of a
secure pseudorandom number generator and truly random seeds are essential for the
security of the Echo option. If no true random number generator is available, a truly
random seed must be provided from an external source. As each pseudorandom number
must only be used once, an implementation needs to get a new truly random seed after
reboot or continuously store the state in nonvolatile memory. See for issues and approaches for
writing to nonvolatile memory.A single active Echo option value with 64 (pseudo)random bits gives the same theoretical
security level as a 64-bit MAC (as used in, e.g., AES_128_CCM_8). If a random unique
Echo option value is intended, the Echo option value SHOULD contain 64
(pseudo)random bits that are not predictable for any other party than the server. A
server MAY use different security levels for different use cases
(client aliveness, request freshness, state synchronization, network address
reachability, etc.).The security provided by the Echo and Request-Tag options depends on the security
protocol used. CoAP and HTTP proxies require (D)TLS to be terminated at the proxies.
The proxies are therefore able to manipulate, inject, delete, or reorder options or
packets. The security claims in such architectures only hold under the assumption
that all intermediaries are fully trusted and have not been compromised.Echo option values without the protection of randomness or a MAC are limited to cases
when the client is the trusted source of all derived properties (as per ). Using them needs per-application
consideration of both the impact of a malicious client and of implementation 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 MUST NOT be
used unless the Echo option values in the request are integrity protected, as per .Servers SHOULD use a monotonic clock to generate timestamps and
compute round-trip times. Use of non-monotonic clocks is not secure, as the 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 MAY be used as long as they have deviations 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.An attacker may be able to affect the server's system time in various ways, such as
setting up a fake NTP server or broadcasting false time signals to radio-controlled
clocks.For the purpose of generating timestamps for the Echo option, a server
MAY set
a timer at reboot and use the time since reboot, choosing the granularity such that
different requests arrive at different times. Servers MAY
intermittently reset the timer and MAY generate a random offset
applied to all timestamps. When resetting the timer, the server MUST
reject all Echo option values that were created before the reset.Servers that use the "List of Cached Random Values and Timestamps" method described
in may be vulnerable to resource
exhaustion attacks. One way to minimize the state is to use the "Integrity-Protected
Timestamp" method described in .Token ReuseReusing Tokens in a way so that responses are guaranteed to not be associated
with the wrong request is not trivial. The server may process requests in any
order and send multiple responses to the same request. An attacker may block,
delay, and reorder messages. The use of a sequence number is therefore recommended
when CoAP is used with a security protocol that does not provide bindings between
requests and responses, such as DTLS or TLS.For a generic response to a Confirmable request over DTLS, binding can only be
claimed without out-of-band knowledge if:
the original request was never retransmitted and
the response was piggybacked in an Acknowledgement message (as a Confirmable
or Non-confirmable response may have been transmitted multiple times).
If observation was used, the same holds for the registration, all
reregistrations, and the cancellation.(In addition, for observations, any responses using that Token and a DTLS
sequence number earlier than the cancellation Acknowledgement message need to be
discarded. This is typically not supported in DTLS implementations.)In some setups, Tokens can be reused without the above constraints, as a
different component in the setup provides the associations:
In CoAP over TLS, retransmissions are not handled by the CoAP layer and
behave like a replay window size of 1. When a client is sending TLS-protected
requests without Observe to a single server, the client can reuse a Token as soon
as the previous response with that Token has been received.
Requests whose responses are cryptographically bound to the requests (like in
OSCORE) can reuse Tokens indefinitely.
In all other cases, a sequence number approach is RECOMMENDED, as
per .Tokens that cannot be reused need to be handled appropriately. This could be
solved by increasing the Token as soon as the currently used Token cannot be
reused or by keeping a list of all Tokens unsuitable for reuse.When the Token (or part of the Token) contains a sequence number, the 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 sequence
number, e.g., the serialized state, as in .Privacy ConsiderationsImplementations SHOULD NOT put any privacy-sensitive information in
the Echo or Request-Tag option values. Unencrypted timestamps could reveal
information about the server, such as location, time since reboot, or that the
server will accept expired certificates. Timestamps MAY be used if
the Echo option is encrypted between the client and the server, e.g., in the case of
DTLS without
proxies or when using OSCORE with an Inner Echo option.Like HTTP cookies, the Echo option could potentially be abused as a tracking
mechanism that identifies a client across requests. This is especially true for
preemptive Echo option values. Servers MUST NOT use the Echo option to
correlate requests for other purposes than freshness and reachability. Clients only
send Echo option values to the same server from which the values were received. Compared to
HTTP, CoAP clients are often authenticated and non-mobile, and servers can therefore
often correlate requests based on the security context, the client credentials, or
the network address. Especially when the Echo option increases a server's ability to
correlate requests, clients MAY discard all preemptive Echo option values.Publicly visible generated identifiers, even when opaque (as all defined in this
document are), can leak information as described in . To avoid 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 variation ensures
that no matchable requests are created by different clients.) When an unprotected
Echo option is used to demonstrate reachability, the recommended mechanism of keeps the effects to a minimum.IANA ConsiderationsIANA has added the following option numbers to the "CoAP Option Numbers"
registry defined by :
Additions to CoAP Option Numbers Registry
Number
Name
Reference
252
Echo
RFC 9175
292
Request-Tag
RFC 9175
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Datagram Transport Layer Security Version 1.2This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]The Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.Block-Wise Transfers in the Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In 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 Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Using Early Data in HTTPUsing TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay.Object Security for Constrained RESTful Environments (OSCORE)This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.Informative ReferencesAttacks on the Constrained Application Protocol (CoAP)Ericsson ABEricsson ABEricsson ABEricsson ABEnergy Harvesting SolutionsWork in ProgressGroup Communication for the Constrained Application Protocol (CoAP)IoTconsultancy.nlInterDigitalRISE AB This document specifies the use of the Constrained Application
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 RFC 7390, while it updates RFC 7252 and RFC 7641.
Work in ProgressGroup OSCORE - Secure Group Communication for CoAPRISE ABEricsson ABEricsson ABEricsson ABUniversitaet Duisburg-EssenWork in ProgressOn the Generation of Transient Numeric IdentifiersEdgeUnoQuarkslab This document performs an analysis of the security and privacy
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.
Work in ProgressArchitectural Styles and the Design of Network-based Software ArchitecturesObserving Resources in the Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a RESTful application 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 extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve 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 sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.CoAP (Constrained Application Protocol) over TCP, TLS, and WebSocketsThe 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.Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. 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.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)This document provides considerations for alleviating Constrained Application Protocol (CoAP) clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths. This document updates RFCs 7252 and 8323 with an extended definition of the "TKL" field in the CoAP message header.QUIC: A UDP-Based Multiplexed and Secure TransportThis document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.Methods for Generating Echo Option ValuesThe content and structure of the Echo option value are implementation specific and
determined by the server. Two simple mechanisms for time-based freshness and one for
event-based freshness are outlined in this appendix. The "List of Cached Random
Values and Timestamps" mechanism is
RECOMMENDED in general. The "Integrity-Protected Timestamp"
mechanism is RECOMMENDED
in case the Echo option is encrypted between the client and the server.Different mechanisms have different trade-offs between the size of the Echo option
value, the amount of server state, the amount of computation, and the security
properties offered. A server MAY use different methods and security
levels for different use cases (client aliveness, request freshness, state
synchronization, network address reachability, etc.).
List of Cached Random Values and Timestamps. The Echo option value is a
(pseudo)random byte string called r. The server caches a list containing the
random byte strings and their initial transmission times. Assuming 72-bit random
values
and 32-bit timestamps, the size of the Echo option value is 9 bytes and the
amount of server state is 13n bytes, where n is the number of active Echo option
values. The security against an attacker guessing Echo option values is given by
s = bit
length of r - log2(n). The length of r and the maximum allowed n should be set so
that the security level is harmonized with other parts of the deployment, e.g., s
>= 64. If the server loses time continuity, e.g., due to reboot, the entries
in the old list MUST be deleted.
Echo option value:
random value r
Server State:
random value r, timestamp t0
This method is suitable for both time-based and event-based freshness (e.g.,
by clearing the cache when an event occurs) and is independent of the client
authority.
Integrity-Protected Timestamp. The Echo option value is an
integrity-protected
timestamp. The timestamp can have a different resolution and range. A 32-bit
timestamp can, e.g., give a resolution of 1 second with a range of 136 years. The
(pseudo)random secret key is generated by the server and not shared with any
other party. The use of truncated HMAC-SHA-256 is RECOMMENDED.
With a 32-bit timestamp and a 64-bit MAC, the size of the Echo option value is 12
bytes, and the server state is small and constant. The security against an
attacker guessing Echo option values is given by the MAC length. If the server loses
time continuity, e.g., due to reboot, the old key MUST be deleted
and replaced by a new random secret key. Note that the privacy considerations in
may apply to the timestamp.
Therefore, it might be important to encrypt it. Depending on the choice of
encryption algorithms, this may require an initialization vector to be included
in the Echo option value (see below).
Echo option value:
timestamp t0, MAC(k, t0)
Server State:
secret key k
This method is suitable for both time-based and event-based freshness (by the
server remembering the time at which the event took place) and independent of
the client authority.If this method is used to additionally obtain network reachability of the
client, the server MUST use the client's network address too, e.g.,
as in MAC(k, t0, claimed network address).
Persistent Counter. This can be used in OSCORE for sequence number recovery,
per . The Echo option
value is a simple counter without integrity protection of its own, serialized in
uint format. The counter is incremented in a persistent way every time the state
that needs to be synchronized is changed (in the case described in , 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 Sender
Sequence Number mechanism described in .
Echo option value:
counter
Server State:
counter
This method is suitable only if the client is the authority over the
synchronized property. Consequently, it cannot be used to show client aliveness.
It provides statements from the client similar to event-based freshness (but
without a proof of freshness).
Other mechanisms complying with the security and privacy considerations may be
used. The use of encrypted timestamps in the Echo option provides additional
protection but typically requires an initialization vector (a.k.a. nonce) as
input to the encryption algorithm, which adds a slight complication to the
procedure as well as overhead.Request-Tag Message Size ImpactIn absence of concurrent operations, the Request-Tag mechanism for body integrity
() incurs no overhead if no messages
are lost (more precisely, in OSCORE, if no operations are aborted due to repeated
transmission failure and, in DTLS, if no packets are lost and replay protection is
active) or when block-wise request operations happen rarely (in OSCORE, if there is
always only one request block-wise operation in the replay window).In those situations, no message has any Request-Tag option set, and the
Request-Tag value can be recycled indefinitely.When the absence of a Request-Tag option cannot be recycled any more within 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.In situations where that overhead is unacceptable (e.g., because the payloads
are known to be at a fragmentation threshold), the absent Request-Tag value can be
made usable again:
In DTLS, a new session can be established.
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 request of the new
operation gets processed, and all earlier operations can therefore be regarded as
concluded.
AcknowledgementsThe authors want to thank , , , , , and
for providing valuable input to the document.Authors' Addresseschristian@amsuess.comEricsson ABjohn.mattsson@ericsson.comEricsson ABgoran.selander@ericsson.com