Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing
draft-ietf-core-echo-request-tag-14

[Ballot comment]
I really like the changes made in the -13 overall; thank you for adding
in all the additional discussion.

I only have editorial/nit-level comments remaining.

Section 2.5.2

  The information extracted by the server from the request Echo value 
  has different sources of truth depending on the application.

I think that the "sources of truth" phrase might be a source of
confusion for some readers.
I'd consider something more like:

% The request Echo value conveys freshness information to the server,
% and the freshness is applied to some data or information related
% to the request.

which then transitions decently into "Understanding who or what is the
authoritative source of that information helps the server implementer
decide ..."

  If all that the server extracts is information which the client is
  authorized to provide arbitrarily, (which is another way of saying
  that the server has to trust the client on whatever Echo is used
  for), then the server can issue Echo values that do not need to be

(nit) I'd suggest "whatever Echo is being used for" (add "being")

  In most other cases, there are properties extracted of 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

[If my above suggestion is used, that removes the word "extracted", this
use of "extracted" should probably be reworded as well.]

Section 3.5.1

      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 performs replay
      protection.

(nit) I think the server would either "perform replay detection" or
"[provide/use] replay protection" -- performing protection is not a
common phrasing.

  way, the server can rely on a conforming client to set the Request-
  Tag option when required, and thereby have confidence the integrity
  of the assembled body.

(nit) "have confidence in"

Appendix A

  This method is suitable both for time and for event base freshness
  (e.g. by clearing the cache when an event occurs), and independent of
  the client authority.

(nit) "for time- and for event-based freshness" (and again a couple
paragraphs later)

[Ballot comment]
There are several SHOULDs (e.g., near the top of page 8, and again at the end of Section 2.3) that left me wondering why an implementer would do something other than what it says.  Since SHOULD offers a choice, some advice would be helpful here.  Otherwise, maybe those ought to be MUSTs.  I suggest giving them all a once-over to see if any such advice would be helpful to include.

[Ballot comment]
Thank you for working on this document; these mechanisms are important
and will help fill some long-standing gaps in CoAP operation.  That
said, I do have some fairly substantive comments that might result in
significant text changes.

While I recognize that there is going to be a spectrum of requirements
for determining freshness, I would have expected the far extreme of that
spectrum to include a strongly time-limited single-use cryptographic
nonce (akin to what the ACME protocol of RFC 8555 uses but with time
limit), as well as discussion of some points on the spectrum and which
ones might be more or less appropriate in various cases.  I do see some
discussion of different use cases, but not much about the tradeoffs
along the spectrum, and no discussion at all about the strongest
properties that it is possible to obtain with this mechanism.

In several places we mention that the Echo option enables a server to
"synchronize state", which to me is a confusing or misleading
characterization -- as I understand it, both additional (application)
protocol mechanism and constraints are required in order for state
synchronization to occur.  Specifically, the client has to be the
authority for the state in question, and the application protocol needs
to specifically indicate under what conditions and which state is to be
synchronized.  In essence, the Echo option provides a mechanism for
ensuring request freshness, and that mechanism is leveraged by the
application protocol to make a synchronzed transfer of state from client
to server.  But AFAICT it is not a generic state synchronization
mechanism, the state to be synchronized is not conveyed in the option
body, etc.  My preference would be to take "synchronize state" out of
the primary list of what is possible and mention it in a separate
sentence as something that can be constructed using the functionality
that the Echo option provides.

There are a couple places where we recommend (implicitly or explicitly)
a sequential counter in contexts that might otherwise use a randomized
value.  I think I mention them all in my section-by-section comments,
but in general the sequential counter might be placing too strong a
requirement on the value, and the considerations of
draft-gont-numeric-ids-sec-considerations seem relevant.

I think it would also be enlightening to have a comparison between the
anti-replay/freshness properties provided by the optional DTLS replay
protection mechanism and the Echo option.  I know they have differences,
but I think there is also some commonality, and giving readers guidance
on whether one vs the other suffices or both are needed could be useful.

Section 2.3

  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.  [...]

[just noting that IIUC the revised requirements on token generation made
later in this document are needed in order for this "resend the original
request" to be safe" ... I am not sure if it needs to be called out here
specifically, though.]

> The cache values MUST be different for all practical purposes.

Since we're at least advocating using crypto to enforce this property, I
think that "execpt with negligible probability" would be a more
conventional expression than "for all practical purposes".

I don't think the example of this in Figure 3 meets the requirements,
though, since the echo option value is just a counter that is easily
spoofable.

  [...] When used to demonstrate
  reachability at a claimed network address, the Echo option SHOULD
  contain the client's network address, but MAY be unprotected.

What does "contain" mean, here?  Plaintext?  That seems potentially
problematic; using it as an input to the MAC that is not transmitted (as
I mention later) is more conventional, in my understanding.

                            The CoAP client side of HTTP-to-CoAP
  proxies SHOULD respond to Echo challenges themselves if they know
  from the recent establishing of the connection that the HTTP request
  is fresh.  Otherwise, they SHOULD respond with 503 Service
  Unavailable, Retry-After: 0 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 [RFC8470]).  They
  MAY also use other mechanisms to establish freshness of the HTTP
  request that are not specified here.

Where is the MUST-level requirement to actually ensure freshness (by
whatever mechanism is available/appropriate)?

Section 2.4

      *  The same Echo value may be used for multiple actuation
          requests to the same server, as long as the total round-trip
          time since the Echo option value was generated is below the
          freshness threshold.

The "round-trip" in "total round-trip time" is a bit confusing to me,
since what's being described doesn't really seem like a round-trip
operation, rather a "get a thing, do some stuff, do some more stuff,
keep sending the echo option, send a particular request to the server
that we are talking about checking the freshness of", with the final
request not very correlated to the issuance event.

  2.  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 which is not the authority
      of the property being synchronized.  E.g. if access to a server
      resource is dependent on time, then server MUST NOT synchronize
      time with a client requesting access unless it is time authority
      for the server.

Also, disambiguating the final "it" seems like it would be worthwhile,
just in case, since this is rather important to get right.

      *  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, see
          Section 7.5 of [RFC8613].

In light of my toplevel comment, I'd suggest rewording this to clarify
that the protocol specified in RFC 8613 includes a mechanism for
resynchronizing the partial IV state, that uses the Echo option in a
specific controlled protocol interaction.

(A similar consideration would apply to the group communication example,
though it might be a little harder to write clearly.)

  3.  A server that sends large responses to unauthenticated peers
      SHOULD mitigate amplification attacks such as described in
      Section 11.3 of [RFC7252] (where an attacker would put a victim's
      address in the source address of a CoAP request).  The
      RECOMMENDED way to do this is to ask a client to Echo its request
      to verify its source address.  [...]

(editorial) this usage of "ask a client to Echo its request" seems
rather divorced from the actual mechanicis of the Echo option...in the
rest of the document (bar one other instance noted below) we restrain
ourselves to saying that the Echo option is what is echoed, divorced
from the containing request/response.

                                      This needs to be done only once
      per peer [...]

How is the "peer" identified in this case?  Is it tied to a single
(security) association, or the identity (if any) associated with that
security association, or IP address (and port?), or something else?
How long can/should the reachability information be cached for?

          reachability as described in Section 2.3.  The proxy MAY
          forward idempotent requests immediately to have a cached
          result available when the client's Echoed request arrives.

(The "Echoed request" phrasing again.)

Section 3.1

                                          In order for a security
  protocol to support CoAP operations over unreliable transports, it
  must allow out-of-order delivery of messages using e.g. a sliding
  replay window such as described in Section 4.1.2.6 of DTLS
  ([RFC6347]).

My understanding is that the requirement is only to allow out-of-order
delivery of messages (not necessarily including replay detection), so
the clause about the sliding window is not needed. here.

Section 3.2

  In essence, it is an implementation of the "proxy-safe elective
  option" used just to "vary the cache key" as suggested in [RFC7959]
  Section 2.4.

The referenced section of RFC 7959 covers Block2 operation, but my
understanding is that the Block1 operation (covered in Section 2.5 of
that same document) would be a more applicable reference.

Section 3.3

                                        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.

Where are those "some circumstances" enumerated?

Section 3.5.1

      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 sent to _any_
      endpoint address using the new operation's security context.

(editorial?) when I read this I feel like it's missing a clause --
consider those messages for the purposes of what operation?

  *  The client MUST NOT regard a block-wise request operation as
      concluded unless all of the messages the client previously sent in
      the operation have been confirmed by the message integrity
      protection mechanism, [...]

nit: confirmed as what?  Delivered?

      Typically, in OSCORE, these confirmations can result either from

nit: I suggest "When security services are provided by OSCORE, these
confirmations typically result from"

      In DTLS, this can only be confirmed if the request message was not
      retransmitted, and was responded to.

Similarly, this would be "When security services are provided by DTLS"
-- DTLS does include a native retransmission layer, but only for DTLS
handshake messages, so this phrasing is needlessly ambiguous as to
whether it is the CoAP request that got retransmitted.

  Authors of other documents (e.g. applications of [RFC8613]) are
  invited to mandate this 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 conclude on the integrity of the assembled
  body.

Could you clarify which client behavior would be mandated?  The overall
"body integrity based on payload integrity" procedures, or the specific
"typically, in OSCORE" behavior?

Also (nit), the phrasing "conclude on the integrity of" seems unusual to
me; I think the intent is more like "thereby have confidence in the
integrity of".

Section 3.5.2

  For those cases, Request-Tag is the proxy-safe elective option
  suggested in [RFC7959] Section 2.4 last paragraph.

(Per above, Section 2.5?)

Section 3.6

  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 Section 3.5.3 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.

Thanks for including this!  However, it wasn't clear to me from reading
https://tools.ietf.org/html/rfc7252#section-5.4.5 and this document
whether the order of repeated Request-Tag options was significant.
Some clarification might be helpful.

Section 3.7

  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 [I-D.mattsson-core-coap-actuators]
  Section 2.5.2.

(I agree that DTLS implementations largely don't expose sequence numbers
and that is unlikely to change.  But) I am not sure I fully understand
the scenario referenced in draft-mattsson-core-coap-actuators §2.5.2.
Perhaps it is not what was intended to be conveyed, but it seems like in
a setup that is tracking both sequence and fragment numbers, it would be
pretty easy to enforce that a fragment-0 block will only start a new
request if the sequence number is larger than the sequence number of the
current/previous blockwise request.  IIUC that would reject the
"withheld first block" as being too old.

Section 3.8

                    and MUST NOT use the same ETag value for different
  representations of a resource.

(side note) I was a little surprised that this was not already a
requirement, but I couldn't find an equivalent statement in a quick
review of RFC 7252.  (It's definitely correct that this is required
behavior to get the protection in question.)

Section 4.1

  In HTTPS, 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.  [...]

I believe this description applies to HTTP/1.1 over TLS, but not to
HTTP/2 or HTTP/3 (both of which provide other mechanisms for reliably
binding requests and responses in the form of stream IDs).

Section 4.2

  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.

I note that sequential assignment often has some additional undesirable
properties, as discussed in draft-gont-numeric-ids-sec-considerations.
Would a different method (e.g., one listed in
draft-irtf-pearg-numeric-ids-generation) provide the needed properties
with fewer side effects?
In particular, sequential increment is at odds with the "nontrivial,
randomized token" recommended for clients not using TLS (that is
intended to guard against spoofing of responses).
("use of a sequence number" and "a sequence number approach" also appear
in §5.1, if this is changed.)

Section 5

  The freshness assertion of the Echo option comes from the client
  reproducing the same value of the Echo option in a request as in a
  previous response.  [...]

nit/editorial: I suggest s/as in/as it received in/

                              However, this may not be an issue if the
  communication is integrity protected against third parties and the
  client is trusted not misusing this capability.  [...]

nit: s/trusted not misusing/trusted to not misuse/

                        See ([RFC8613], Appendix B.1.1) for issues and
  solution approaches for writing to nonvolatile memory.

nit: redundant word in "solution approaches"?

  For the purpose of generating timestamps for Echo a server MAY set a
  timer at reboot and use the time since reboot, in a unit such that
  different requests arrive at different times.  [...]

Something about this sentence confuses me, possibly around "in a unit".

Section 5.1

  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 blacklisted
  Tokens.

editorial: perhaps "unsafe to reuse" is more clear than "blacklisted"?

Section 6

This seems to be the first (and only) place where we use the term
"preemptive Echo values"; it might be worth a bit more exposition that
these are ones piggybacked on non-4.01 responses (assuming that's
correct, of course).

Section 8.1

I note that DTLS 1.3 is in IETF Last Call.  I did not notice anything in
this document that's specific to a DTLS version, which suggests that it
woudl be safe to change the reference according to relative publication
order of these documents.  It would be good for the authors to confirm
that at their leisure, so as to not be rushed into a decision if/when
the RFC Editor asks during their processing.

Section 8.2

I note that draft-mattsson-core-coap-actuators is referenced from
several locations (for useful additional discussion, to be clear), but
it is only an individual draft that expired almost two years ago.  Is
there any likelihood that it will ever progress to an RFC?

One might argue that "SHOULD use a 425 Too Early response" is enough to
promote RFC 8470 to being a normative reference (see
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/).

Section A

  2.  Integrity Protected Timestamp.  The Echo option value is an
  integrity protected timestamp.  The timestamp can have 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 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 Section 6 may apply to the timestamp.
  Therefore, it might be important to encrypt it.  Depending on the
  choice of encryption algorithms, this may require a nonce to be
  included in the Echo option value.

I note that a MAC construction allows additional information to be
covered under the MAC that is not sent alongside it, e.g., identity
information about the client to which the Echo option value is being
associated.  Are there common situations in which including such
additional contextual information under the MAC would be valuable (to
prevent an echo option value received on one connection from being
usable on a different one)?

  3.  Persistent Counter.  This is an event-based freshness method
  usable for state synchronization (for example after volatile state
  has been lost), and cannot be used for client aliveness.  It requires
  that the client can be trusted to not spuriously produce Echo values.

I have severe qualms about specifying a protocol mechcanism that relies
on trusting a client to this extent.  It seems to expose a lot of latent
risk; even if we think there should be mechanisms in place to protect
against that risk, they might fail, or the mechanism might get used
outside its intended context, etc.; if there are other mechanisms
available for similar cost that provide the needed properties it seems
more robust to suggest their use in place of the persistent counter.

[Ballot comment]
Thank you for writing this mitigation for draft-mattsson-core-coap-actuators.

** Section 5.  Per “As each pseudorandom number most only be used once …”, how will that be possible when echo values as small are 1-byte are possible?

** Section 5.
However, this may not be an issue if the
  communication is integrity protected against third parties and the
  client is trusted not misusing this capability. 

-- Why is the use of integrity presented as only a possibility here?  Didn’t Section 2.3 require it when assuring the freshness requirement – “When used to serve freshness requirements including client aliveness and state synchronizing), the Echo option value MUST be integrity protected between the intended endpoints ...”

-- Would it be clearer here to say that this is mitigation against an on-path attacker, not against rogue/compromised clients?

** Appendix A helpfully tries to lay out recommendations.  A few comments:

-- all of the recommendations here have option values much larger than the permitted minimum of 1-byte.  In addition to the recommendations, could the circumstances of the lower bound also be discussed

-- it would be helpful to explicitly state which methods apply to the specific use cases (client aliveness, request freshness, state synchronization, network  address reachability).  For example, method 3 (persistent counter) notes that it can be used for state synchronization but not client aliveness

[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated).

Eliot Lear (in copy) has also reviewed the document as IoT directorate reviewer at:
https://datatracker.ietf.org/doc/review-ietf-core-echo-request-tag-12-iotdir-telechat-lear-2021-02-05/
So, please address/reply to his comment.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 2.2 --
"The Echo option value is a challenge from the server to the client..." Just wondering whether "echo" is the right choice for the option as it is too close to ICMP_ECHO_REQUEST, why not "challenge" ?

I would have expected some statements related to non-idempotent requests (generic statement) and then specific examples such as actuators.

-- Section 2.2.1 --
Are the authors confident enough to state a minimum length of 1 octet ? If the intent of the document is to prevent replay attack, then I wonder whether one octet is enough... Unsure whether Section 5 (security considerations) addresses this issue correctly.

### Summary

Document Shepherd: Marco Tiloca
Area Director: Barry Leiba

The document considers the following security issues when using the CoAP protocol, even if together with a security protocol. These are especially severe in use cases involving actuators.

1. A server receiving a request is in general not able to verify when the client generated the request, which can be delayed or not fresh. This can further result in amplification attacks.

2. When using block-wise transfer, the integrity protection of a block does not extend to the whole request body. Interchanged blocks between different message bodies to the same resource may go undetected, so endangering multiple concurrent block-wise transfers.

3. A client may erroneously associate the wrong response to a request.

The document addresses the issues (1)(2) by defining the usage of two new CoAP options, namely Echo and Request-Tag; as well as the issue (3) by updating RFC 7252 to forbid non-secure reuse of Tokens in CoAP.

The document updates RFC 7252 also with respect to amplification mitigation, for which it recommends the use of the new Echo option.

The document is intended for Standards Track.

Version -12 addressed Last Call comments from GenART, TSVART and OpsDir, about providing clarifications and small fixes.

### Review and Consensus

The document has been discussed on multiple IETF meetings, and has gone through multiple expert reviews. Consensus has been reached on the content of this document and its need.

### Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

### Other Points

The document registers two new option numbers in the "CoAP Option Numbers" registry defined by RFC 7252, and provides detailed reasoning for the suggested values.

### Checklist

- [x] Does the shepherd stand behind the document and think the document is ready for publication?
- [x] Is the correct RFC type indicated in the title page header?
- [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
- [x] Is the intent of the document accurately and adequately explained in the introduction?
- [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
- [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
  'Note: There are 10 lines having 2 characters in excess each (see tables in Figure 1 and Figure 4). Their length will become within the limit when the RFC editor replaces the TBDxxx numbers with the ones assigned by IANA.'
- [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
- [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
- [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
- [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
- [x] If this is a "bis" document, have all of the errata been considered?
  'Does not apply'

**IANA** Considerations:

- [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
- [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
- [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
- [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
- [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
- [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
  'Does not apply'
- [x]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?
  'Does not apply'

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-core-echo-request-tag-11. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that upon approval of this document, there is a single action for IANA.

In the CoAP Option Numbers registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at

https://www.iana.org/assignments/core-parameters/

two new option numbers are to be registered:

Number: [ TBD-at-Registration ]
Name: Echo
Reference: [ RFC-to-be ]

Number: [ TBD-at-Registration ]
Name: Request-Tag
Reference: [ RFC-to-be ]

IANA notes that the authors of the current draft suggest the value 252 for Echo and 292 for Request-Tag. Both values are currently available, and IANA will attempt to comply with the wishes of the authors. However, value 292 is in the region of the registry governed by Specification Required (as defined by RFC 8126).

If that value is to be used, we will initiate the required expert review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

It should be noted that if the AD agrees and the WG chairs want to submit a request (to iana@iana.org) in accordance with RFC 7120, there is an early allocation process available for both values. An early allocation in the Specification Required range would still require expert approval.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-12-02):

From: The IESG
To: IETF-Announce
CC: marco.tiloca@ri.se, core-chairs@ietf.org, Marco Tiloca , core@ietf.org, barryleiba@gmail.com, draft-ietf-core-echo-request-tag@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (CoAP: Echo, Request-Tag, and Token Processing) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'CoAP: Echo, Request-Tag, and
Token Processing'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-12-02. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This 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 RFC7252 with respect to the client
  Token processing requirements, forbidding non-secure reuse of Tokens
  to ensure binding of response to request when CoAP is used with a
  security protocol, and with respect to amplification mitigation,
  where the use of Echo is now recommended.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/



No IPR declarations have been submitted directly on this I-D.

### Summary

Document Shepherd: Marco Tiloca
Area Director: Barry Leiba

The document considers the following security issues when using the CoAP protocol, even if together with a security protocol. These are especially severe in use cases involving actuators.

1. A server receiving a request is in general not able to verify when the client generated the request, which can be delayed or not fresh. This can further result in amplification attacks.

2. When using block-wise transfer, the integrity protection of a block does not extend to the whole request body. Interchanged blocks between different message bodies to the same resource may go undetected, so endangering multiple concurrent block-wise transfers.

3. A client may erroneously associate the wrong response to a request.

The document addresses the issues (1)(2) by defining the usage of two new CoAP options, namely Echo and Request-Tag; as well as the issue (3) by updating RFC 7252 to forbid non-secure reuse of Tokens in CoAP.

The document updates RFC 7252 also with respect to amplification mitigation, for which it recommends the use of the new Echo option.

The document is intended for Standards Track.

### Review and Consensus

The document has been discussed on multiple IETF meetings, and has gone through multiple expert reviews. Consensus has been reached on the content of this document and its need.

### Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

### Other Points

The document registers two new option numbers in the "CoAP Option Numbers" registry defined by RFC 7252, and provides detailed reasoning for the suggested values.

### Checklist

- [x] Does the shepherd stand behind the document and think the document is ready for publication?
- [x] Is the correct RFC type indicated in the title page header?
- [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
- [x] Is the intent of the document accurately and adequately explained in the introduction?
- [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
- [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
  'Note: There are 10 lines having 2 characters in excess each (see tables in Figure 1 and Figure 4). Their length will become within the limit when the RFC editor replaces the TBDxxx numbers with the ones assigned by IANA.'
- [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
- [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
- [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
- [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
- [x] If this is a "bis" document, have all of the errata been considered?
  'Does not apply'

**IANA** Considerations:

- [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
- [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
- [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
- [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
- [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
- [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
  'Does not apply'
- [x]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?
  'Does not apply'

### Summary

Document Shepherd: Marco Tiloca
Area Director: Barry Leiba

The document considers the following security issues when using the CoAP protocol, even if together with a security protocol. These are especially severe in use cases involving actuators.

1. A server receiving a request is in general not able to verify when the client generated the request, which can be delayed or not fresh. This can further result in amplification attacks.

2. When using block-wise transfer, the integrity protection of a block does not extend to the whole request body. Interchanged blocks between different message bodies to the same resource may go undetected, so endangering multiple concurrent block-wise transfers.

3. A client may erroneously associate the wrong response to a request.

The document addresses the issues (1)(2) by defining the usage of two new CoAP options, namely Echo and Request-Tag; as well as the issue (3) by updating RFC 7252 to forbid non-secure reuse of Tokens in CoAP.

The document updates RFC 7252 also with respect to amplification mitigation, for which it recommends the use of the new Echo option.

The document is intended for Standards Track.

### Review and Consensus

The document has been discussed on multiple IETF meetings, and has gone through multiple expert reviews. Consensus has been reached on the content of this document and its need.

### Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

### Other Points

The document registers two new option numbers in the "CoAP Option Numbers" registry defined by RFC 7252, and provides detailed reasoning for the suggested values.

### Checklist

- [x] Does the shepherd stand behind the document and think the document is ready for publication?
- [x] Is the correct RFC type indicated in the title page header?
- [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
- [x] Is the intent of the document accurately and adequately explained in the introduction?
- [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
- [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
  'Note: There are 10 lines having 2 characters in excess each (see tables in Figure 1 and Figure 4). Their length will become within the limit when the RFC editor replaces the TBDxxx numbers with the ones assigned by IANA.'
- [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
- [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
- [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
- [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
- [x] If this is a "bis" document, have all of the errata been considered?
  'Does not apply'

**IANA** Considerations:

- [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
- [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
- [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
- [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
- [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
- [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
  'Does not apply'
- [x]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?
  'Does not apply'