draft-ietf-core-echo-request-tag-11.txt   draft-ietf-core-echo-request-tag-12.txt 
CoRE Working Group C. Amsuess CoRE Working Group C. Amsuess
Internet-Draft Internet-Draft
Updates: 7252 (if approved) J. Mattsson Updates: 7252 (if approved) J. Mattsson
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: May 6, 2021 Ericsson AB Expires: 5 August 2021 Ericsson AB
November 02, 2020 1 February 2021
CoAP: Echo, Request-Tag, and Token Processing CoAP: Echo, Request-Tag, and Token Processing
draft-ietf-core-echo-request-tag-11 draft-ietf-core-echo-request-tag-12
Abstract Abstract
This document specifies enhancements to the Constrained Application This document specifies enhancements to the Constrained Application
Protocol (CoAP) that mitigate security issues in particular use Protocol (CoAP) that mitigate security issues in particular use
cases. The Echo option enables a CoAP server to verify the freshness 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 of a request or to force a client to demonstrate reachability at its
claimed network address. The Request-Tag option allows the CoAP claimed network address. The Request-Tag option allows the CoAP
server to match block-wise message fragments belonging to the same server to match block-wise message fragments belonging to the same
request. This document updates RFC7252 with respect to the client request. This document updates RFC7252 with respect to the client
Token processing requirements, forbidding non-secure reuse of Tokens Token processing requirements, forbidding non-secure reuse of Tokens
to ensure binding of response to request when CoAP is used with a to ensure binding of response to request when CoAP is used with a
security protocol, and with respect to amplification mitigation, security protocol, and with respect to amplification mitigation,
where the use of Echo is now recommended. where the use of Echo is now recommended.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the CORE Working Group
mailing list (core@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/core/.
Source for this draft and an issue tracker can be found at
https://github.com/core-wg/echo-request-tag.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 6, 2021. This Internet-Draft will expire on 5 August 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Request Freshness and the Echo Option . . . . . . . . . . . . 4 2. Request Freshness and the Echo Option . . . . . . . . . . . . 5
2.1. Request Freshness . . . . . . . . . . . . . . . . . . . . 4 2.1. Request Freshness . . . . . . . . . . . . . . . . . . . . 5
2.2. The Echo Option . . . . . . . . . . . . . . . . . . . . . 5 2.2. The Echo Option . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Echo Option Format . . . . . . . . . . . . . . . . . 5 2.2.1. Echo Option Format . . . . . . . . . . . . . . . . . 6
2.3. Echo Processing . . . . . . . . . . . . . . . . . . . . . 6 2.3. Echo Processing . . . . . . . . . . . . . . . . . . . . . 7
2.4. Applications of the Echo Option . . . . . . . . . . . . . 10 2.4. Applications of the Echo Option . . . . . . . . . . . . . 10
3. Protecting Message Bodies using Request Tags . . . . . . . . 11 3. Protecting Message Bodies using Request Tags . . . . . . . . 12
3.1. Fragmented Message Body Integrity . . . . . . . . . . . . 11 3.1. Fragmented Message Body Integrity . . . . . . . . . . . . 12
3.2. The Request-Tag Option . . . . . . . . . . . . . . . . . 12 3.2. The Request-Tag Option . . . . . . . . . . . . . . . . . 13
3.2.1. Request-Tag Option Format . . . . . . . . . . . . . . 12 3.2.1. Request-Tag Option Format . . . . . . . . . . . . . . 13
3.3. Request-Tag Processing by Servers . . . . . . . . . . . . 13 3.3. Request-Tag Processing by Servers . . . . . . . . . . . . 14
3.4. Setting the Request-Tag . . . . . . . . . . . . . . . . . 14 3.4. Setting the Request-Tag . . . . . . . . . . . . . . . . . 15
3.5. Applications of the Request-Tag Option . . . . . . . . . 15 3.5. Applications of the Request-Tag Option . . . . . . . . . 16
3.5.1. Body Integrity Based on Payload Integrity . . . . . . 15 3.5.1. Body Integrity Based on Payload Integrity . . . . . . 16
3.5.2. Multiple Concurrent Block-wise Operations . . . . . . 16 3.5.2. Multiple Concurrent Block-wise Operations . . . . . . 17
3.5.3. Simplified Block-Wise Handling for Constrained 3.5.3. Simplified Block-Wise Handling for Constrained
Proxies . . . . . . . . . . . . . . . . . . . . . . . 17 Proxies . . . . . . . . . . . . . . . . . . . . . . . 18
3.6. Rationale for the Option Properties . . . . . . . . . . . 17 3.6. Rationale for the Option Properties . . . . . . . . . . . 18
3.7. Rationale for Introducing the Option . . . . . . . . . . 18 3.7. Rationale for Introducing the Option . . . . . . . . . . 19
3.8. Block2 / ETag Processing . . . . . . . . . . . . . . . . 18 3.8. Block2 / ETag Processing . . . . . . . . . . . . . . . . 19
4. Token Processing for Secure Request-Response Binding . . . . 18 4. Token Processing for Secure Request-Response Binding . . . . 19
4.1. Request-Response Binding . . . . . . . . . . . . . . . . 18 4.1. Request-Response Binding . . . . . . . . . . . . . . . . 19
4.2. Updated Token Processing Requirements for Clients . . . . 19 4.2. Updated Token Processing Requirements for Clients . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 5.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Methods for Generating Echo Option Values . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 26 Appendix A. Methods for Generating Echo Option Values . . . . . 26
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 27 Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 28
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
The initial Constrained Application Protocol (CoAP) suite of The initial Constrained Application Protocol (CoAP) suite of
specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed
with the assumption that security could be provided on a separate with the assumption that security could be provided on a separate
layer, in particular by using DTLS ([RFC6347]). However, for some layer, in particular by using DTLS ([RFC6347]). However, for some
use cases, additional functionality or extra processing is needed to use cases, additional functionality or extra processing is needed to
support secure CoAP operations. This document specifies security support secure CoAP operations. This document specifies security
enhancements to the Constrained Application Protocol (CoAP). enhancements to the Constrained Application Protocol (CoAP).
skipping to change at page 4, line 12 skipping to change at page 4, line 23
Like [RFC7252], this document is relying on the Representational Like [RFC7252], this document is relying on the Representational
State Transfer [REST] architecture of the Web. State Transfer [REST] architecture of the Web.
Unless otherwise specified, the terms "client" and "server" refer to Unless otherwise specified, the terms "client" and "server" refer to
"CoAP client" and "CoAP server", respectively, as defined in "CoAP client" and "CoAP server", respectively, as defined in
[RFC7252]. The term "origin server" is used as in [RFC7252]. The [RFC7252]. The term "origin server" is used as in [RFC7252]. The
term "origin client" is used in this document to denote the client term "origin client" is used in this document to denote the client
from which a request originates; to distinguish from clients in from which a request originates; to distinguish from clients in
proxies. proxies.
A message's "freshness" is a measure of when a message was sent on a
time scale 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; examplary uses are "no more than
one hour ago" or "after this server's last reboot".
The terms "payload" and "body" of a message are used as in [RFC7959]. The terms "payload" and "body" of a message are used as in [RFC7959].
The complete interchange of a request and a response body is called a The complete interchange of a request and a response body is called a
(REST) "operation". An operation fragmented using [RFC7959] is (REST) "operation". An operation fragmented using [RFC7959] is
called a "block-wise operation". A block-wise operation which is called a "block-wise operation". A block-wise operation which is
fragmenting the request body is called a "block-wise request fragmenting the request body is called a "block-wise request
operation". A block-wise operation which is fragmenting the response operation". A block-wise operation which is fragmenting the response
body is called a "block-wise response operation". body is called a "block-wise response operation".
Two request messages are said to be "matchable" if they occur between 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 the same endpoint pair, have the same code, and have the same set of
skipping to change at page 6, line 5 skipping to change at page 6, line 22
for methods and response codes defined to have a payload. The Echo for methods and response codes defined to have a payload. The Echo
option provides a convention to transfer freshness indicators that option provides a convention to transfer freshness indicators that
works for all methods and response codes. works for all methods and response codes.
2.2.1. Echo Option Format 2.2.1. Echo Option Format
The Echo Option is elective, safe-to-forward, not part of the cache- The Echo Option is elective, safe-to-forward, not part of the cache-
key, and not repeatable, see Figure 1, which extends Table 4 of key, and not repeatable, see Figure 1, which extends Table 4 of
[RFC7252]). [RFC7252]).
+--------+---+---+---+---+-------------+--------+------+---------+---+---+ +--------+---+---+---+---+-------------+--------+------+---------+
| No. | C | U | N | R | Name | Format | Len. | Default | E | U | | No. | C | U | N | R | Name | Format | Len. | Default |
+--------+---+---+---+---+-------------+--------+------+---------+---+---+ +--------+---+---+---+---+-------------+--------+------+---------+
| TBD252 | | | x | | Echo | opaque | 1-40 | (none) | x | x | | TBD252 | | | x | | Echo | opaque | 1-40 | (none) |
+--------+---+---+---+---+-------------+--------+------+---------+---+---+ +--------+---+---+---+---+-------------+--------+------+---------+
C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable, C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable
E = Encrypt and Integrity Protect (when using OSCORE)
Figure 1: Echo Option Summary Figure 1: Echo Option Summary
The Echo option value is generated by a server, and its content and The Echo option value is generated by a server, and its content and
structure are implementation specific. Different methods for structure are implementation specific. Different methods for
generating Echo option values are outlined in Appendix A. Clients generating Echo option values are outlined in Appendix A. Clients
and intermediaries MUST treat an Echo option value as opaque and make and intermediaries MUST treat an Echo option value as opaque and make
no assumptions about its content or structure. no assumptions about its content or structure.
When receiving an Echo option in a request, the server MUST be able When receiving an Echo option in a request, the server MUST be able
skipping to change at page 8, line 9 skipping to change at page 8, line 24
not processed further, and an error message MAY be sent. The error not processed further, and an error message MAY be sent. The error
message SHOULD include a new Echo option. message SHOULD include a new Echo option.
One way for the server to verify freshness is to bind the Echo value One way for the server to verify freshness is to bind the Echo value
to a specific point in time and verify that the request is not older 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 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 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 the time when the Echo option value was generated. An example
message flow is shown in Figure 2. message flow is shown in Figure 2.
Client Server Client Server
| | | |
+------>| Code: 0.03 (PUT) +------>| Code: 0.03 (PUT)
| PUT | Token: 0x41 | PUT | Token: 0x41
| | Uri-Path: lock | | Uri-Path: lock
| | Payload: 0 (Unlock) | | Payload: 0 (Unlock)
| | | |
|<------+ Code: 4.01 (Unauthorized) |<------+ Code: 4.01 (Unauthorized)
| 4.01 | Token: 0x41 | 4.01 | Token: 0x41
| | Echo: 0x437468756c687521 (t0) | | Echo: 0x00000009437468756c687521 (t0 = 9, +MAC)
| | | |
+------>| t1 Code: 0.03 (PUT) | ... | The round trips take 1 second, time is now t1 = 10.
| PUT | Token: 0x42 | |
| | Uri-Path: lock +------>| Code: 0.03 (PUT)
| | Echo: 0x437468756c687521 (t0) | PUT | Token: 0x42
| | Payload: 0 (Unlock) | | Uri-Path: lock
| | | | Echo: 0x00000009437468756c687521 (t0 = 9, +MAC)
|<------+ Code: 2.04 (Changed) | | Payload: 0 (Unlock)
| 2.04 | Token: 0x42 | |
| | | | Verify MAC, compare t1 - t0 = 1 < T => permitted.
| |
|<------+ Code: 2.04 (Changed)
| 2.04 | Token: 0x42
| |
Figure 2: Example Message Flow for Time-Based Freshness Figure 2: Example Message Flow for Time-Based Freshness using the
'Integrity Protected Timestamp' construction of Appendix A
Another way for the server to verify freshness is to maintain a cache 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 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 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 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 each event a new value is written into the cache. The cache values
MUST be different for all practical purposes. The server verifies MUST be different for all practical purposes. The server verifies
freshness by checking that e0 equals e1, where e0 is the cached value 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 when the Echo option value was generated, and e1 is the cached value
at the reception of the request. An example message flow is shown in at the reception of the request. An example message flow is shown in
Figure 3. Figure 3.
Client Server Client Server
| | | |
+------>| Code: 0.03 (PUT) +------>| Code: 0.03 (PUT)
| PUT | Token: 0x41 | PUT | Token: 0x41
| | Uri-Path: lock | | Uri-Path: lock
| | Payload: 0 (Unlock) | | Payload: 0 (Unlock)
| | | |
|<------+ Code: 4.01 (Unauthorized) |<------+ Code: 4.01 (Unauthorized)
| 4.01 | Token: 0x41 | 4.01 | Token: 0x41
| | Echo: 0x436F6D69632053616E73 (e0) | | Echo: 0x05 (e0 = 5, number of total lock
| | | | operations performed)
+------>| e1 Code: 0.03 (PUT) | |
| PUT | Token: 0x42 | ... | No alterations happen to the lock state, e1 has the
| | Uri-Path: lock | | same value e1 = 5.
| | Echo: 0x436F6D69632053616E73 (e0) | |
| | Payload: 0 (Unlock) +------>| Code: 0.03 (PUT)
| | | PUT | Token: 0x42
|<------+ Code: 2.04 (Changed) | | Uri-Path: lock
| 2.04 | Token: 0x42 | | Echo: 0x05
| | | | Payload: 0 (Unlock)
| |
| | Compare e1 = e0 => permitted.
| |
|<------+ Code: 2.04 (Changed)
| 2.04 | Token: 0x42
| | Echo: 0x06 (e2 = 6, to allow later locking
| | without more round-trips)
| |
Figure 3: Example Message Flow for Event-Based Freshness Figure 3: Example Message Flow for Event-Based Freshness using
the 'Persistent Counter' construction of Appendix A
When used to serve freshness requirements (including client aliveness When used to serve freshness requirements (including client aliveness
and state synchronizing), the Echo option value MUST be integrity and state synchronizing), the Echo option value MUST be integrity
protected between the intended endpoints, e.g. using DTLS, TLS, or an protected between the intended endpoints, e.g. using DTLS, TLS, or an
OSCORE Inner option ([RFC8613]). When used to demonstrate OSCORE Inner option ([RFC8613]). When used to demonstrate
reachability at a claimed network address, the Echo option SHOULD reachability at a claimed network address, the Echo option SHOULD
contain the client's network address, but MAY be unprotected. contain the client's network address, but MAY be unprotected.
A CoAP-to-CoAP proxy MAY set an Echo option on responses, both on 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 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 (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 option it recognizes as one generated by itself on follow-up
requests. When it receives an Echo option in a response, it may requests. When it receives an Echo option in a response, it MAY
forward it to the client (and, not recognizing it as an own in future forward it to the client (and, not recognizing it as an own in future
requests, relay it in the other direction as well) or process it on 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 its own. If it does so, it MUST ensure that the client's request was
generated (or is re-generated) after the Echo value used to send to generated (or is re-generated) after the Echo value used to send to
the server was first seen. (In most cases, this means that the proxy 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 value.) needs to ask the client to repeat the request with a new Echo value.)
The CoAP server side of CoAP-to-HTTP proxies MAY request freshness, The CoAP server side of CoAP-to-HTTP proxies MAY request freshness,
especially if they have reason to assume that access may require it 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 (e.g. because it is a PUT or POST); how this is determined is out of
skipping to change at page 11, line 28 skipping to change at page 12, line 5
* In the presence of a proxy, a server will not be able to * In the presence of a proxy, a server will not be able to
distinguish different origin client endpoints. Following from distinguish different origin client endpoints. Following from
the recommendation above, a proxy that sends large responses the recommendation above, a proxy that sends large responses
to unauthenticated peers SHOULD mitigate amplification to unauthenticated peers SHOULD mitigate amplification
attacks. The proxy SHOULD use Echo to verify origin attacks. The proxy SHOULD use Echo to verify origin
reachability as described in Section 2.3. The proxy MAY reachability as described in Section 2.3. The proxy MAY
forward idempotent requests immediately to have a cached forward idempotent requests immediately to have a cached
result available when the client's Echoed request arrives. result available when the client's Echoed request arrives.
* Amplification mitigation should be used when the response * Amplification mitigation is a trade-off between giving
would be more than three times the size of the request, leverage to an attacker and causing overheads. An
considering the complete frame on the wire as it is typically amplification factor of 3 (i.e., don't send more than three
sent across the Internet. In practice, this allows UDP data times the number of bytes received until the peer's address is
of at least 152 Bytes without further checks. confirmed) is considered acceptable for unconstrained
applications [I-D.ietf-quic-transport].
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 a 14 + 40 + 8 Bytes Ethernet, IP and UDP header 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 * When an Echo response is sent to mitigate amplification, it
MUST be sent as a piggybacked or Non-confirmable response, MUST be sent as a piggybacked or Non-confirmable response,
never as a separate one (which would cause amplification due never as a separate one (which would cause amplification due
to retransmission). to retransmission).
4. A server may want to use the request freshness provided by the 4. A server may want to use the request freshness provided by the
Echo to verify the aliveness of a client. Note that in a Echo to verify the aliveness of a client. Note that in a
deployment with hop-by-hop security and proxies, the server can deployment with hop-by-hop security and proxies, the server can
only verify aliveness of the closest proxy. only verify aliveness of the closest proxy.
skipping to change at page 13, line 5 skipping to change at page 14, line 5
In essence, it is an implementation of the "proxy-safe elective In essence, it is an implementation of the "proxy-safe elective
option" used just to "vary the cache key" as suggested in [RFC7959] option" used just to "vary the cache key" as suggested in [RFC7959]
Section 2.4. Section 2.4.
3.2.1. Request-Tag Option Format 3.2.1. Request-Tag Option Format
The Request-Tag option is not critical, is safe to forward, The Request-Tag option is not critical, is safe to forward,
repeatable, and part of the cache key, see Figure 4, which extends repeatable, and part of the cache key, see Figure 4, which extends
Table 4 of [RFC7252]). Table 4 of [RFC7252]).
+--------+---+---+---+---+-------------+--------+------+---------+---+---+ +--------+---+---+---+---+-------------+--------+------+---------+
| No. | C | U | N | R | Name | Format | Len. | Default | E | U | | No. | C | U | N | R | Name | Format | Len. | Default |
+--------+---+---+---+---+-------------+--------+------+---------+---+---+ +--------+---+---+---+---+-------------+--------+------+---------+
| TBD292 | | | | x | Request-Tag | opaque | 0-8 | (none) | x | x | | TBD292 | | | | x | Request-Tag | opaque | 0-8 | (none) |
+--------+---+---+---+---+-------------+--------+------+---------+---+---+ +--------+---+---+---+---+-------------+--------+------+---------+
C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable, C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable
E = Encrypt and Integrity Protect (when using OSCORE)
Figure 4: Request-Tag Option Summary Figure 4: Request-Tag Option Summary
Request-Tag, like the block options, is both a class E and a class U Request-Tag, like the block options, is both a class E and a class U
option in terms of OSCORE processing (see Section 4.1 of [RFC8613]): option in terms of OSCORE processing (see Section 4.1 of [RFC8613]):
The Request-Tag MAY be an Inner or Outer option. It influences the The Request-Tag MAY be an Inner or Outer option. It influences the
Inner or Outer block operation, respectively. The Inner and Outer Inner or Outer block operation, respectively. The Inner and Outer
values are therefore independent of each other. The Inner option is values are therefore independent of each other. The Inner option is
encrypted and integrity protected between client and server, and encrypted and integrity protected between client and server, and
provides message body identification in case of end-to-end provides message body identification in case of end-to-end
fragmentation of requests. The Outer option is visible to proxies fragmentation of requests. The Outer option is visible to proxies
and labels message bodies in case of hop-by-hop fragmentation of and labels message bodies in case of hop-by-hop fragmentation of
skipping to change at page 13, line 44 skipping to change at page 14, line 43
CoAP proxies can use Request-Tag on their CoAP sides; it is not CoAP proxies can use Request-Tag on their CoAP sides; it is not
applicable to HTTP requests. applicable to HTTP requests.
3.3. Request-Tag Processing by Servers 3.3. Request-Tag Processing by Servers
The Request-Tag option does not require any particular processing on The Request-Tag option does not require any particular processing on
the server side outside of the processing already necessary for any the server side outside of the processing already necessary for any
unknown elective proxy-safe cache-key option: The option varies the unknown elective proxy-safe cache-key option: The option varies the
properties that distinguish block-wise operations (which includes all properties that distinguish block-wise operations (which includes all
options except elective NoCacheKey and except Block1/2), and thus the options except elective NoCacheKey and except Block1/2), and thus the
server can not treat messages with a different list of Request-Tag server cannot treat messages with a different list of Request-Tag
options as belonging to the same operation. options as belonging to the same operation.
To keep utilizing the cache, a server (including proxies) MAY discard To keep utilizing the cache, a server (including proxies) MAY discard
the Request-Tag option from an assembled block-wise request when the Request-Tag option from an assembled block-wise request when
consulting its cache, as the option relates to the operation-on-the- consulting its cache, as the option relates to the operation-on-the-
wire and not its semantics. For example, a FETCH request with 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 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 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 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 about ETag in that it is formally part of the cache key, but
skipping to change at page 15, line 12 skipping to change at page 16, line 12
depends on the purpose, and is defined accordingly; see examples in depends on the purpose, and is defined accordingly; see examples in
Section 3.5. Section 3.5.
When Block1 and Block2 are combined in an operation, the Request-Tag When Block1 and Block2 are combined in an operation, the Request-Tag
of the Block1 phase is set in the Block2 phase as well for otherwise of the Block1 phase is set in the Block2 phase as well for otherwise
the request would have a different set of options and would not be the request would have a different set of options and would not be
recognized any more. recognized any more.
Clients are encouraged to generate compact messages. This means Clients are encouraged to generate compact messages. This means
sending messages without Request-Tag options whenever possible, and sending messages without Request-Tag options whenever possible, and
using short values when the absent option can not be recycled. using short values when the absent option cannot be recycled.
Note that Request-Tag options can be present in request messages that Note that Request-Tag options can be present in request messages that
carry no Block option (for example, because a Request-Tag unaware carry no Block option (for example, because a Request-Tag unaware
proxy reassembled them), and MUST be ignored in those. proxy reassembled them), and MUST be ignored in those.
The Request-Tag option MUST NOT be present in response messages. The Request-Tag option MUST NOT be present in response messages.
3.5. Applications of the Request-Tag Option 3.5. Applications of the Request-Tag Option
3.5.1. Body Integrity Based on Payload Integrity 3.5.1. Body Integrity Based on Payload Integrity
skipping to change at page 15, line 35 skipping to change at page 16, line 35
payloads, even if the individual messages are integrity protected, it payloads, even if the individual messages are integrity protected, it
is still possible for an attacker to maliciously replace a later is still possible for an attacker to maliciously replace a later
operation's blocks with an earlier operation's blocks (see operation's blocks with an earlier operation's blocks (see
Section 2.5 of [I-D.mattsson-core-coap-actuators]). Therefore, the Section 2.5 of [I-D.mattsson-core-coap-actuators]). Therefore, the
integrity protection of each block does not extend to the operation's integrity protection of each block does not extend to the operation's
request body. request body.
In order to gain that protection, use the Request-Tag mechanism as In order to gain that protection, use the Request-Tag mechanism as
follows: follows:
o The individual exchanges MUST be integrity protected end-to-end * The individual exchanges MUST be integrity protected end-to-end
between client and server. between client and server.
o The client MUST NOT recycle a request tag in a new operation * The client MUST NOT recycle a request tag in a new operation
unless the previous operation matchable to the new one has unless the previous operation matchable to the new one has
concluded. concluded.
If any future security mechanisms allow a block-wise transfer to If any future security mechanisms allow a block-wise transfer to
continue after an endpoint's details (like the IP address) have continue after an endpoint's details (like the IP address) have
changed, then the client MUST consider messages sent to _any_ changed, then the client MUST consider messages sent to _any_
endpoint address using the new operation's security context. endpoint address using the new operation's security context.
o The client MUST NOT regard a block-wise request operation as * The client MUST NOT regard a block-wise request operation as
concluded unless all of the messages the client previously sent in concluded unless all of the messages the client previously sent in
the operation have been confirmed by the message integrity the operation have been confirmed by the message integrity
protection mechanism, or the client can determine that the server protection mechanism, or the client can determine that the server
would not consider the messages to be valid if they were replayed. would not consider the messages to be valid if they were replayed.
Typically, in OSCORE, these confirmations can result either from Typically, in OSCORE, these confirmations can result either from
the client receiving an OSCORE response message matching the the client receiving an OSCORE response message matching the
request (an empty ACK is insufficient), or because the message's request (an empty ACK is insufficient), or because the message's
sequence number is old enough to be outside the server's receive sequence number is old enough to be outside the server's receive
window. window.
skipping to change at page 16, line 23 skipping to change at page 17, line 23
Authors of other documents (e.g. applications of [RFC8613]) are Authors of other documents (e.g. applications of [RFC8613]) are
invited to mandate this behavior for clients that execute block-wise invited to mandate this behavior for clients that execute block-wise
interactions over secured transports. In this way, the server can interactions over secured transports. In this way, the server can
rely on a conforming client to set the Request-Tag option when rely on a conforming client to set the Request-Tag option when
required, and thereby conclude on the integrity of the assembled required, and thereby conclude on the integrity of the assembled
body. body.
Note that this mechanism is implicitly implemented when the security Note that this mechanism is implicitly implemented when the security
layer guarantees ordered delivery (e.g. CoAP over TLS [RFC8323]). layer guarantees ordered delivery (e.g. CoAP over TLS [RFC8323]).
This is because with each message, any earlier message can not be This is because with each message, any earlier message cannot be
replayed any more, so the client never needs to set the Request-Tag replayed any more, so the client never needs to set the Request-Tag
option unless it wants to perform concurrent operations. option unless it wants to perform concurrent operations.
Body integrity only makes sense in applications that have stateful Body integrity only makes sense in applications that have stateful
block-wise transfers. On applications where all the state is in the block-wise transfers. On applications where all the state is in the
application (e.g. because rather than POSTing a large representation application (e.g. because rather than POSTing a large representation
to a collection in a stateful block-wise transfer, a collection item to a collection in a stateful block-wise transfer, a collection item
is created first, then written to once and available when written is created first, then written to once and available when written
completely), clients need not concern themselves with body integrity completely), clients need not concern themselves with body integrity
and thus the Request-Tag. and thus the Request-Tag.
skipping to change at page 16, line 49 skipping to change at page 17, line 49
in progress, which the new request should not cancel. A CoAP proxy in progress, which the new request should not cancel. A CoAP proxy
would be in such a situation when it forwards operations with the would be in such a situation when it forwards operations with the
same cache-key options but possibly different payloads. same cache-key options but possibly different payloads.
For those cases, Request-Tag is the proxy-safe elective option For those cases, Request-Tag is the proxy-safe elective option
suggested in [RFC7959] Section 2.4 last paragraph. suggested in [RFC7959] Section 2.4 last paragraph.
When initializing a new block-wise operation, a client has to look at When initializing a new block-wise operation, a client has to look at
other active operations: other active operations:
o If any of them is matchable to the new one, and the client neither * 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 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 a Request-Tag value (including the absent option) that is not in
use by the other matchable operations for the new operation. use by the other matchable operations for the new operation.
o Otherwise, it can start the new operation without setting the * Otherwise, it can start the new operation without setting the
Request-Tag option on it. Request-Tag option on it.
3.5.3. Simplified Block-Wise Handling for Constrained Proxies 3.5.3. Simplified Block-Wise Handling for Constrained Proxies
The Block options were defined to be unsafe to forward because a The Block options were defined to be unsafe to forward because a
proxy that would forward blocks as plain messages would risk mixing proxy that would forward blocks as plain messages would risk mixing
up clients' requests. up clients' requests.
In some cases, for example when forwarding block-wise request In some cases, for example when forwarding block-wise request
operations, appending a Request-Tag value unique to the client can operations, appending a Request-Tag value unique to the client can
satisfy the requirements on the proxy that come from the presence of satisfy the requirements on the proxy that come from the presence of
a block option. a block option.
This is particularly useful to proxies that strive for stateless This is particularly useful to proxies that strive for stateless
operation as described in [I-D.ietf-core-stateless] Section 4. operation as described in [RFC8974] Section 4.
The precise classification of cases in which such a Request-Tag The precise classification of cases in which such a Request-Tag
option is sufficient is not trivial, especially when both request and option is sufficient is not trivial, especially when both request and
response body are fragmented, and out of scope for this document. response body are fragmented, and out of scope for this document.
3.6. Rationale for the Option Properties 3.6. Rationale for the Option Properties
The Request-Tag option can be elective, because to servers unaware of The Request-Tag option can be elective, because to servers unaware of
the Request-Tag option, operations with differing request tags will the Request-Tag option, operations with differing request tags will
not be matchable. not be matchable.
skipping to change at page 21, line 34 skipping to change at page 22, line 34
associated with the wrong request is not trivial: The server may associated with the wrong request is not trivial: The server may
process requests in any order, and send multiple responses to the process requests in any order, and send multiple responses to the
same request. An attacker may block, delay, and reorder messages. same request. An attacker may block, delay, and reorder messages.
The use of a sequence number is therefore recommended when CoAP is The use of a sequence number is therefore recommended when CoAP is
used with a security protocol that does not provide bindings between used with a security protocol that does not provide bindings between
requests and responses such as DTLS or TLS. requests and responses such as DTLS or TLS.
For a generic response to a Confirmable request over DTLS, binding For a generic response to a Confirmable request over DTLS, binding
can only be claimed without out-of-band knowledge if can only be claimed without out-of-band knowledge if
o the original request was never retransmitted, * the original request was never retransmitted,
o the response was piggybacked in an Acknowledgement message (as a * the response was piggybacked in an Acknowledgement message (as a
Confirmable or Non-confirmable response may have been transmitted Confirmable or Non-confirmable response may have been transmitted
multiple times), and multiple times), and
o if observation was used, the same holds for the registration, all * if observation was used, the same holds for the registration, all
re-registrations, and the cancellation. re-registrations, and the cancellation.
(In addition, for observations, any responses using that Token and a (In addition, for observations, any responses using that Token and a
DTLS sequence number earlier than the cancellation Acknowledgement DTLS sequence number earlier than the cancellation Acknowledgement
message need to be discarded. This is typically not supported in message need to be discarded. This is typically not supported in
DTLS implementations.) DTLS implementations.)
In some setups, Tokens can be reused without the above constraints, In some setups, Tokens can be reused without the above constraints,
as a different component in the setup provides the associations: as a different component in the setup provides the associations:
o In CoAP over TLS, retransmissions are not handled by the CoAP * In CoAP over TLS, retransmissions are not handled by the CoAP
layer and behaves like a replay window size of 1. When a client layer and behaves like a replay window size of 1. When a client
is sending TLS-protected requests without Observe to a single is sending TLS-protected requests without Observe to a single
server, the client can reuse a Token as soon as the previous server, the client can reuse a Token as soon as the previous
response with that Token has been received. response with that Token has been received.
o Requests whose responses are cryptographically bound to the * Requests whose responses are cryptographically bound to the
requests (like in OSCORE) can reuse Tokens indefinitely. requests (like in OSCORE) can reuse Tokens indefinitely.
In all other cases, a sequence number approach is RECOMMENDED as per In all other cases, a sequence number approach is RECOMMENDED as per
Section 4. Section 4.
Tokens that cannot be reused need to be handled appropriately. This Tokens that cannot be reused need to be handled appropriately. This
could be solved by increasing the Token as soon as the currently used 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 Token cannot be reused, or by keeping a list of all blacklisted
Tokens. Tokens.
When the Token (or part of the Token) contains a sequence number, the 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 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 any collisions. This is especially true when the Token contains more
information than just the sequence number, e.g. serialized state as information than just the sequence number, e.g. serialized state as
in [I-D.ietf-core-stateless]. in [RFC8974].
6. Privacy Considerations 6. Privacy Considerations
Implementations SHOULD NOT put any privacy-sensitive information in Implementations SHOULD NOT put any privacy-sensitive information in
the Echo or Request-Tag option values. Unencrypted timestamps could the Echo or Request-Tag option values. Unencrypted timestamps could
reveal information about the server such as location or time since reveal information about the server such as location or time since
reboot, or that the server will accept expired certificates. reboot, or that the server will accept expired certificates.
Timestamps MAY be used if Echo is encrypted between the client and Timestamps MAY be used if Echo is encrypted between the client and
the server, e.g. in the case of DTLS without proxies or when using the server, e.g. in the case of DTLS without proxies or when using
OSCORE with an Inner Echo option. OSCORE with an Inner Echo option.
skipping to change at page 24, line 23 skipping to change at page 25, line 28
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Group OSCORE - Secure Group Communication for CoAP", "Group OSCORE - Secure Group Communication for CoAP", Work
draft-ietf-core-oscore-groupcomm-09 (work in progress), in Progress, Internet-Draft, draft-ietf-core-oscore-
June 2020. groupcomm-10, 2 November 2020, <http://www.ietf.org/
internet-drafts/draft-ietf-core-oscore-groupcomm-10.txt>.
[I-D.ietf-core-stateless] [I-D.ietf-quic-transport]
Hartke, K., "Extended Tokens and Stateless Clients in the Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
Constrained Application Protocol (CoAP)", draft-ietf-core- and Secure Transport", Work in Progress, Internet-Draft,
stateless-06 (work in progress), April 2020. draft-ietf-quic-transport-34, 14 January 2021,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-34.txt>.
[I-D.mattsson-core-coap-actuators] [I-D.mattsson-core-coap-actuators]
Mattsson, J., Fornehed, J., Selander, G., Palombini, F., Mattsson, J., Fornehed, J., Selander, G., Palombini, F.,
and C. Amsuess, "Controlling Actuators with CoAP", draft- and C. Amsuess, "Controlling Actuators with CoAP", Work in
mattsson-core-coap-actuators-06 (work in progress), Progress, Internet-Draft, draft-mattsson-core-coap-
September 2018. actuators-06, 17 September 2018, <http://www.ietf.org/
internet-drafts/draft-mattsson-core-coap-actuators-
06.txt>.
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", 2000, Network-based Software Architectures", 2000,
<https://www.ics.uci.edu/~fielding/pubs/dissertation/ <https://www.ics.uci.edu/~fielding/pubs/dissertation/
fielding_dissertation.pdf>. fielding_dissertation.pdf>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
the Constrained Application Protocol (CoAP)", RFC 7390, the Constrained Application Protocol (CoAP)", RFC 7390,
DOI 10.17487/RFC7390, October 2014, DOI 10.17487/RFC7390, October 2014,
<https://www.rfc-editor.org/info/rfc7390>. <https://www.rfc-editor.org/info/rfc7390>.
skipping to change at page 25, line 19 skipping to change at page 26, line 29
<https://www.rfc-editor.org/info/rfc8323>. <https://www.rfc-editor.org/info/rfc8323>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/info/rfc8470>. 2018, <https://www.rfc-editor.org/info/rfc8470>.
[RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and
Stateless Clients in the Constrained Application Protocol
(CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021,
<https://www.rfc-editor.org/info/rfc8974>.
Appendix A. Methods for Generating Echo Option Values Appendix A. Methods for Generating Echo Option Values
The content and structure of the Echo option value are implementation The content and structure of the Echo option value are implementation
specific and determined by the server. Two simple mechanisms for specific and determined by the server. Two simple mechanisms for
time-based freshness and one for event-based freshness are outlined time-based freshness and one for event-based freshness are outlined
in this section, the first is RECOMMENDED in general, and the second in this section, the first is RECOMMENDED in general, and the second
is RECOMMENDED in case the Echo option is encrypted between the is RECOMMENDED in case the Echo option is encrypted between the
client and the server. client and the server.
Different mechanisms have different tradeoffs between the size of the Different mechanisms have different tradeoffs between the size of the
skipping to change at page 26, line 39 skipping to change at page 28, line 7
indicates that volatile state may have been lost). An example of how indicates that volatile state may have been lost). An example of how
such a persistent counter can be implemented efficiently is the such a persistent counter can be implemented efficiently is the
OSCORE server Sender Sequence Number mechanism described in OSCORE server Sender Sequence Number mechanism described in
Appendix B.1.1 of [RFC8613]. Appendix B.1.1 of [RFC8613].
Echo option value: counter Echo option value: counter
Server State: counter Server State: counter
Other mechanisms complying with the security and privacy Other mechanisms complying with the security and privacy
considerations may be used. The use of encrypted timestamps in the considerations may be used. The use of encrypted timestamps in the
Echo option increases security, but typically requires an IV to be Echo option increases security, but typically requires an IV
included in the Echo option value, which adds overhead and makes the (Initialization Vector) to be included in the Echo option value,
specification of such a mechanism slightly more complicated than the which adds overhead and makes the specification of such a mechanism
two time-based mechanisms specified here. slightly more complicated than the two time-based mechanisms
specified here.
Appendix B. Request-Tag Message Size Impact Appendix B. Request-Tag Message Size Impact
In absence of concurrent operations, the Request-Tag mechanism for In absence of concurrent operations, the Request-Tag mechanism for
body integrity (Section 3.5.1) incurs no overhead if no messages are body integrity (Section 3.5.1) incurs no overhead if no messages are
lost (more precisely: in OSCORE, if no operations are aborted due to lost (more precisely: in OSCORE, if no operations are aborted due to
repeated transmission failure; in DTLS, if no packets are lost), or repeated transmission failure; in DTLS, if no packets are lost), or
when block-wise request operations happen rarely (in OSCORE, if there when block-wise request operations happen rarely (in OSCORE, if there
is always only one request block-wise operation in the replay is always only one request block-wise operation in the replay
window). window).
In those situations, no message has any Request-Tag option set, and In those situations, no message has any Request-Tag option set, and
that can be recycled indefinitely. that can be recycled indefinitely.
When the absence of a Request-Tag option can not be recycled any more When the absence of a Request-Tag option cannot be recycled any more
within a security context, the messages with a present but empty within a security context, the messages with a present but empty
Request-Tag option can be used (1 Byte overhead), and when that is Request-Tag option can be used (1 Byte overhead), and when that is
used-up, 256 values from one byte long options (2 Bytes overhead) are used-up, 256 values from one byte long options (2 Bytes overhead) are
available. available.
In situations where those overheads are unacceptable (e.g. because In situations where those overheads are unacceptable (e.g. because
the payloads are known to be at a fragmentation threshold), the the payloads are known to be at a fragmentation threshold), the
absent Request-Tag value can be made usable again: absent Request-Tag value can be made usable again:
o In DTLS, a new session can be established. * In DTLS, a new session can be established.
o In OSCORE, the sequence number can be artificially increased so * In OSCORE, the sequence number can be artificially increased so
that all lost messages are outside of the replay window by the that all lost messages are outside of the replay window by the
time the first request of the new operation gets processed, and time the first request of the new operation gets processed, and
all earlier operations can therefore be regarded as concluded. all earlier operations can therefore be regarded as concluded.
Appendix C. Change Log Appendix C. Change Log
[ The editor is asked to remove this section before publication. ] [ The editor is asked to remove this section before publication. ]
o Changes since draft-ietf-core-echo-request-tag-10 (Barry's * Changes since draft-ietf-core-echo-request-tag-11 (addressing
GenART, TSVART, OpsDir comments)
- Explain the size permissible for responses before amplification
mitigation by referring to the QUIC draft for an OK factor, and
giving the remaining numbers that led to it. The actual number
is reduced from 152 to 136 because the more conservative case
of the attacker not sending a token is considered now.
- Added a definition for "freshness"
- Give more concrete example values in figures 2 and 3 (based on
the appendix suggestions), highlighting the differences between
the figures by telling how they are processed in the examples.
- Figure with option summary: E/U columns removed (for duplicate
headers and generally not contributing)
- MAY capitalization changed for consistency.
- Editorial changes (IV acronym expanded, s/can not/cannot/g)
- Draft ietf-core-stateless has become RFC8974
* Changes since draft-ietf-core-echo-request-tag-10 (Barry's
comments) comments)
* Align terminology on attacker - Align terminology on attacker
* A number of clarifications and editorial fixes - A number of clarifications and editorial fixes
* Promote DTLS and OSCORE to normative references - Promote DTLS and OSCORE to normative references
* Add counter-based version to the Methods for Generating Echo - Add counter-based version to the Methods for Generating Echo
Option Values appendix Option Values appendix
* Use 64-bit randomness recommendation throughout (but keep it as - Use 64-bit randomness recommendation throughout (but keep it as
SHOULD so applications with strict requirements can reduce if SHOULD so applications with strict requirements can reduce if
if really needed) if really needed)
* Speling and Capitalization - Speling and Capitalization
o Changes since draft-ietf-core-echo-request-tag-09: * Changes since draft-ietf-core-echo-request-tag-09:
* Allow intermediaries to do Echo processing, provided they ask - Allow intermediaries to do Echo processing, provided they ask
at least as much freshness as they forward at least as much freshness as they forward
* Emphasize that clients can forget Echo to further discourage - Emphasize that clients can forget Echo to further discourage
abuse as cookies abuse as cookies
* Emphasize that RESTful application design can avoid the need - Emphasize that RESTful application design can avoid the need
for a Request-Tag for a Request-Tag
* Align with core-oscore-groupcomm-09 - Align with core-oscore-groupcomm-09
* Add interaction with HTTP Early Data / 425 Too Early - Add interaction with HTTP Early Data / 425 Too Early
* Abstract: Explicitly mention both updates to 7252 - Abstract: Explicitly mention both updates to 7252
* Change requested option number of Echo to 252 (previous - Change requested option number of Echo to 252 (previous
property calculation was erroneous) property calculation was erroneous)
o Changes since draft-ietf-core-echo-request-tag-08: * Changes since draft-ietf-core-echo-request-tag-08:
* Make amplification attack mitigation by Echo an RFC7252 - Make amplification attack mitigation by Echo an RFC7252
updating recommendation updating recommendation
* Give some more concrete guidance to that use case in terms of - Give some more concrete guidance to that use case in terms of
sizes and message types sizes and message types
* Allow short (1-3 byte) Echo values for deterministic cases, - Allow short (1-3 byte) Echo values for deterministic cases,
with according security considerations with according security considerations
* Point out the tricky parts around Request-Tag for stateless - Point out the tricky parts around Request-Tag for stateless
proxies, and make that purely an outlook example with out-of- proxies, and make that purely an outlook example with out-of-
scope details scope details
* Lift ban on Request-Tag options without Block1 (as they can - Lift ban on Request-Tag options without Block1 (as they can
legitimately be generated by an unaware proxy) legitimately be generated by an unaware proxy)
* Suggest concrete numbers for the options - Suggest concrete numbers for the options
o Changes since draft-ietf-core-echo-request-tag-07 (largely * Changes since draft-ietf-core-echo-request-tag-07 (largely
addressing Francesca's review): addressing Francesca's review):
* Request tag: Explicitly limit "MUST NOT recycle" requirement to - Request tag: Explicitly limit "MUST NOT recycle" requirement to
particular applications particular applications
* Token reuse: upper-case RECOMMEND sequence number approach - Token reuse: upper-case RECOMMEND sequence number approach
* Structure: Move per-topic introductions to respective chapters - Structure: Move per-topic introductions to respective chapters
(this avoids long jumps by the reader) (this avoids long jumps by the reader)
* Structure: Group Block2 / ETag section inside new fragmentation - Structure: Group Block2 / ETag section inside new fragmentation
(formerly Request-Tag) section (formerly Request-Tag) section
* More precise references into other documents - More precise references into other documents
- "concurrent operations": Emphasise that all here only matters
* "concurrent operations": Emphasise that all here only matters
between endpoint pairs between endpoint pairs
* Freshness: Generalize wording away from time-based freshness - Freshness: Generalize wording away from time-based freshness
* Echo: Emphasise that no binding between any particular pair of - Echo: Emphasise that no binding between any particular pair of
responses and requests is established responses and requests is established
* Echo: Add event-based example - Echo: Add event-based example
* Echo: Clarify when protection is needed - Echo: Clarify when protection is needed
* Request tag: Enhance wording around "not sufficient condition" - Request tag: Enhance wording around "not sufficient condition"
* Request tag: Explicitly state when a tag needs to be set - Request tag: Explicitly state when a tag needs to be set
* Request tag: Clarification about permissibility of leaving the - Request tag: Clarification about permissibility of leaving the
option absent option absent
* Security considerations: wall clock time -> system time (and - Security considerations: wall clock time -> system time (and
remove inaccurate explanations) remove inaccurate explanations)
* Token reuse: describe blacklisting in a more implementation- - Token reuse: describe blacklisting in a more implementation-
independent way independent way
o Changes since draft-ietf-core-echo-request-tag-06: * Changes since draft-ietf-core-echo-request-tag-06:
* Removed visible comment that should not be visible in Token - Removed visible comment that should not be visible in Token
reuse considerations. reuse considerations.
o Changes since draft-ietf-core-echo-request-tag-05: * Changes since draft-ietf-core-echo-request-tag-05:
* Add privacy considerations on cookie-style use of Echo values - Add privacy considerations on cookie-style use of Echo values
* Add security considerations for token reuse - Add security considerations for token reuse
* Add note in security considerations on use of nonvolatile - Add note in security considerations on use of nonvolatile
memory when dealing with pseudorandom numbers memory when dealing with pseudorandom numbers
* Appendix on echo generation: add a few words on up- and - Appendix on echo generation: add a few words on up- and
downsides of the encrypted timestamp alternative downsides of the encrypted timestamp alternative
* Clarifications around Outer Echo: - Clarifications around Outer Echo:
+ Could be generated by the origin server to prove network o Could be generated by the origin server to prove network
reachability (but for most applications it MUST be inner) reachability (but for most applications it MUST be inner)
+ Could be generated by intermediaries o Could be generated by intermediaries
o Is answered by the client to the endpoint from which it
+ Is answered by the client to the endpoint from which it
received it (ie. Outer if received as Outer) received it (ie. Outer if received as Outer)
* Clarification that a server can send Echo preemtively - Clarification that a server can send Echo preemtively
* Refer to stateless to explain what "more information than just - Refer to stateless to explain what "more information than just
the sequence number" could be the sequence number" could be
* Remove explanations around 0.00 empty messags - Remove explanations around 0.00 empty messags
* Rewordings: - Rewordings:
+ the attack: from "forging" to "guessing" o the attack: from "forging" to "guessing"
+ "freshness tokens" to "freshness indicators" (to avoid o "freshness tokens" to "freshness indicators" (to avoid
confusion with the Token) confusion with the Token)
* Editorial fixes: - Editorial fixes:
+ Abstract and introduction mention what is updated in RFC7252 o Abstract and introduction mention what is updated in RFC7252
+ Reference updates o Reference updates
+ Capitalization, spelling, terms from other documents o Capitalization, spelling, terms from other documents
o Changes since draft-ietf-core-echo-request-tag-04: * Changes since draft-ietf-core-echo-request-tag-04:
* Editorial fixes - Editorial fixes
+ Moved paragraph on collision-free encoding of data in the o Moved paragraph on collision-free encoding of data in the
Token to Security Considerations and rephrased it Token to Security Considerations and rephrased it
+ "easiest" -> "one easy" o "easiest" -> "one easy"
o Changes since draft-ietf-core-echo-request-tag-03: * Changes since draft-ietf-core-echo-request-tag-03:
* Mention Token processing changes in title - Mention Token processing changes in title
* Abstract reworded - Abstract reworded
* Clarify updates to Token processing - Clarify updates to Token processing
* Describe security levels from Echo length - Describe security levels from Echo length
* Allow non-monotonic clocks under certain conditions for
freshness
* Simplify freshness expressions - Allow non-monotonic clocks under certain conditions for
freshness
* Describe when a Request-Tag can be set - Simplify freshness expressions
- Describe when a Request-Tag can be set
* Add note on application-level freshness mechanisms - Add note on application-level freshness mechanisms
* Minor editorial changes - Minor editorial changes
o Changes since draft-ietf-core-echo-request-tag-02: * Changes since draft-ietf-core-echo-request-tag-02:
* Define "freshness" - Define "freshness"
* Note limitations of "aliveness" - Note limitations of "aliveness"
* Clarify proxy and OSCORE handling in presence of "echo" - Clarify proxy and OSCORE handling in presence of "echo"
* Clarify when Echo values may be reused - Clarify when Echo values may be reused
* Update security considerations - Update security considerations
* Various minor clarifications - Various minor clarifications
* Minor editorial changes - Minor editorial changes
o Major changes since draft-ietf-core-echo-request-tag-01: * Major changes since draft-ietf-core-echo-request-tag-01:
* Follow-up changes after the "relying on block-wise" change in - Follow-up changes after the "relying on block-wise" change in
-01: -01:
+ Simplify the description of Request-Tag and matchability o Simplify the description of Request-Tag and matchability
+ Do not update RFC7959 any more o Do not update RFC7959 any more
* Make Request-Tag repeatable. - Make Request-Tag repeatable.
* Add rationale on not relying purely on sequence numbers. - Add rationale on not relying purely on sequence numbers.
o Major changes since draft-ietf-core-echo-request-tag-00: * Major changes since draft-ietf-core-echo-request-tag-00:
* Reworded the Echo section. - Reworded the Echo section.
* Added rules for Token processing. - Added rules for Token processing.
* Added security considerations. - Added security considerations.
* Added actual IANA section. - Added actual IANA section.
* Made Request-Tag optional and safe-to-forward, relying on - Made Request-Tag optional and safe-to-forward, relying on
block-wise to treat it as part of the cache-key block-wise to treat it as part of the cache-key
* Dropped use case about OSCORE Outer-block-wise (the case went - Dropped use case about OSCORE Outer-block-wise (the case went
away when its Partial IV was moved into the Object-Security away when its Partial IV was moved into the Object-Security
option) option)
o Major changes since draft-amsuess-core-repeat-request-tag-00: * Major changes since draft-amsuess-core-repeat-request-tag-00:
* The option used for establishing freshness was renamed from - The option used for establishing freshness was renamed from
"Repeat" to "Echo" to reduce confusion about repeatable "Repeat" to "Echo" to reduce confusion about repeatable
options. options.
* The response code that goes with Echo was changed from 4.03 to - The response code that goes with Echo was changed from 4.03 to
4.01 because the client needs to provide better credentials. 4.01 because the client needs to provide better credentials.
* The interaction between the new option and (cross) proxies is - The interaction between the new option and (cross) proxies is
now covered. now covered.
* Two messages being "Request-Tag matchable" was introduced to - Two messages being "Request-Tag matchable" was introduced to
replace the older concept of having a request tag value with replace the older concept of having a request tag value with
its slightly awkward equivalence definition. its slightly awkward equivalence definition.
Acknowledgments Acknowledgments
The authors want to thank Carsten Bormann, Francesca Palombini, and The authors want to thank Carsten Bormann, Francesca Palombini, and
Jim Schaad for providing valuable input to the draft. Jim Schaad for providing valuable input to the draft.
Authors' Addresses Authors' Addresses
Christian Amsuess Christian Amsüss
Email: christian@amsuess.com Email: christian@amsuess.com
John Preuss Mattsson John Preuß Mattsson
Ericsson AB Ericsson AB
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
Goeran Selander Göran Selander
Ericsson AB Ericsson AB
Email: goran.selander@ericsson.com Email: goran.selander@ericsson.com
 End of changes. 144 change blocks. 
246 lines changed or deleted 318 lines changed or added

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