Many different attacks have been reported as part of revelations associated with pervasive surveillance.  Some of the reported attacks <del> involved compromising smart cards, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards.  Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved.  However, the danger of resourceful attackers for these systems is still a concern. </del>  This specification is an optional extension to the EAP-AKA' authentication method which was defined in RFC9048.  The extension, Many different attacks have been reported as part of revelations associated with pervasive surveillance.  Some of the reported attacks <del> involved compromising smart cards, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards.  Such attacks are conceivable, for instance, during the manufacturing process of cards, or during the transfer of cards and associated information to the operator.  Since the publication of reports about such attacks, manufacturing and provisioning processes have gained much scrutiny and have improved. </del>  However, the danger of resourceful attackers attempting to gain information about SIM cards is still a concern.  They are a high- Curve Diffie-Hellman (ECDH) exchange RFC7748.  In EAP-AKA' FS this exchange is run in an ephemeral manner, i.e., both sides generate temporary keys as specified in RFC7748.  This method is referred to <del> as ECDHE, where the last 'E' stands for Ephemeral. </del>  The enhancements in the EAP-AKA' FS protocol are compatible with the signaling flow and other basic structures of both AKA and EAP-AKA'. The possibility of attacks against key storage offered in SIM or other smart cards has been a known threat.  But as the discussion in <del> attacks shows, the likelihood of practically feasible attacks has increased.  Many of these attacks can be best dealt with improved processes, e.g., limiting the access to the key material within the factory or personnel, etc.  But not all attacks can be entirely ruled out for well-resourced adversaries, irrespective of what the technical algorithms and protection measures are. </del>  This extension can provide assistance in situations where there is a danger of attacks against the key material on SIM cards by <del> adversaries that can not or who are unwilling to mount active attacks against large number of sessions.  This extension is most useful when used in a context where EAP keys are used without further mixing that can provide Forward Secrecy.  For instance, when used with IKEv2 RFC7296, the session keys produced by IKEv2 have this property, so better characteristics of EAP keys is not that useful.  However, typical link layer usage of EAP does not involve running Diffie- Hellman, so using EAP to authenticate access to a network is one situation where the extension defined in this document can be helpful. </del>  This extension generates keying material using the ECDHE exchange in order to gain the FS property.  This means that once an EAP-AKA' MUST forget not only the ephemeral keys used by the connection but also any information that could be used to recompute those keys.  The following security properties of EAP-AKA' are impacted through this extension: control, and (b) identifiable for the purposes of blocking the affected subscribers.  8. This extension of EAP-AKA' shares its attribute space and subtypes

Not sure the attacks actually attacked the smart cards. Changed to "smart card supply chain" in the abstract and intro. This is very much related to zero trust principles. added a sentence about this. Any modern standard track EAP method should provide mandatory client identity protection. Copied the text from EAP-TLS 1.3 Motivation for the chosen curves is missing. Added link to the definition of SUCI encryption in appendix C.3.4. of TS 33.501 Added more text in security consideration on the attacks an attacker can do. Added more text in security consideration on frequent use of ECDHE.
Great! There's one typo but I'll fix it.

Many different attacks have been reported as part of revelations associated with pervasive surveillance.  Some of the reported attacks  <ins> involved compromising the smart card supply chain, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards.  Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved.  However, the danger of resourceful attackers for these systems is still a concern.  Always assuming breach such as key compromise and minimizing the impact of breach are essential zero-trust principles. </ins> This specification is an optional extension to the EAP-AKA' authentication method which was defined in RFC9048.  The extension, Many different attacks have been reported as part of revelations associated with pervasive surveillance.  Some of the reported attacks  <ins> involved compromising the smart card supply chain, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards.  Such attacks are conceivable, for instance, during the manufacturing process of cards, or during the transfer of cards and associated information to the operator. Since the publication of reports about such attacks, manufacturing and provisioning processes have gained much scrutiny and have improved. </ins> However, the danger of resourceful attackers attempting to gain information about SIM cards is still a concern.  They are a high- Curve Diffie-Hellman (ECDH) exchange RFC7748.  In EAP-AKA' FS this exchange is run in an ephemeral manner, i.e., both sides generate temporary keys as specified in RFC7748.  This method is referred to  <ins> as ECDHE, where the last 'E' stands for Ephemeral.  The two intially registered elliptic curves and their wire format is chosen to alging with the elliptic curves and formats specified for Subscription Concealed Identi er (SUCI) encryption in Appendix C.3.4 of 3GPP TS 33.501 </ins> The enhancements in the EAP-AKA' FS protocol are compatible with the signaling flow and other basic structures of both AKA and EAP-AKA'. The possibility of attacks against key storage offered in SIM or other smart cards has been a known threat.  But as the discussion in  <ins> attacks shows, the likelihood of practically feasible attacks such as breaches in the smart card supply chain has increased.  Many of these attacks can be best dealt with improved processes, e.g., limiting the access to the key material within the factory or personnel, etc.  But not all attacks can be entirely ruled out for well-resourced adversaries, irrespective of what the technical algorithms and protection measures are.  Always assuming breach such as key compromise and minimizing the impact of breach are essential zero- trust principles. If a mechanism without forward secrecy such as (5G-AKA, EAP- AKAa€™) is used the effects of key compromise are devastating.  The serious consequences of breach somewhere in the supply chain or after delivery that are possible when 5G-AKA or EAP- AKA' is used but not when something with forward secrecy like EAP- AKA-FS is used are: 1.  A passive attacker can eavesdrop (decrypt) all future 5G communication (control and user plane both directions), 2.  A passive attacker can decrypt 5G communication that they previously recorded in the past (control and user plane both directions), and 3.  An active attacker can impersonate UE and Network and inject messages in an ongoing 5G connection between the real UE and the real network (control and user plane both directions). Best practice security today is to mandate forward secrecy (as is done in WPA3, EAP-TLS 1.3, EAP-TTLS 1.3, etc).  It is RECOMMENDED to long term completely phase out AKA without FS. </ins> This extension can provide assistance in situations where there is a danger of attacks against the key material on SIM cards by  <ins> adversaries that cannot or who are unwilling to mount active attacks against large number of sessions.  The extension also provides protection against active attacks as they are forced to be a Man-In- The-Middle (MITM) during the AKA run and subsequent communication between the parties.  Without forward secrecy an an active attacker that has compromised the long-term key can inject messages in an connection betwen the real Peer and the real server without being a man-in-the-middle.  This extension is most useful when used in a context where EAP keys are used without further mixing that can provide Forward Secrecy.  For instance, when used with IKEv2 RFC7296, the session keys produced by IKEv2 have this property, so better characteristics of EAP keys is not that useful.  However, typical link layer usage of EAP does not involve running Diffie-Hellman, so using EAP to authenticate access to a network is one situation where the extension defined in this document can be helpful. </ins> This extension generates keying material using the ECDHE exchange in order to gain the FS property.  This means that once an EAP-AKA' MUST forget not only the ephemeral keys used by the connection but also any information that could be used to recompute those keys. <ins> Using EAP-AKA' FS once provides forward secrecy.  Forward secrecy limits the effect of key leakage in one direction (compromise of a key at time T2 does not compromise some key at time T1 where T1 < T2).  Protection in the other direction (compromise at time T1 does not compromise keys at time T2) can be achieved by rerunning ECDHE frequentle.  If a long-term authentication key has been compromised, rerunning EAP-AKA' FS gives protection against passive attackers. Using the terms in {{RFC7624}}, forward secrecy without rerunning ECDHE does not stop an attacker from doing static key exfiltration. Frequently rerunning EC(DHE) forces an attacker to do dynamic key exfiltration (or content exfiltration). </ins> The following security properties of EAP-AKA' are impacted through this extension: control, and (b) identifiable for the purposes of blocking the affected subscribers. <ins> 7.1. Best practice privacy today is to mandate client identity protection as is done in EAP-TLS 1.3, EAP-TTLS 1.3, etc.  A client supporting EAP-AKA' FS MUST NOT send its username (or any other permanent identifiers) in cleartext in the Identity Response (or any message used instead of the Identity Response) </ins> 8. This extension of EAP-AKA' shares its attribute space and subtypes


even if a quantum computer of sufficient size and power to exploit elliptic curve cryptography will exist.  Deployments that need to consider risks decades into the future should transition to Post- <del> Quantum Cryptography (PQC) in the not-too-distant future.  Many other systems should take a slower wait-and-see approach where PQC is phased in when the quantum threat is more imminent.  Current PQC algorithms have limitations compared to Elliptic Curve Cryptography (ECC) and the data sizes would be problematic in many constrained IoT systems.  If a Cryptographically Relevant Quantum Computer (CRQC) is built it could recover the SHARED_SECRET from the ECDHE public keys in a matter of hours. </del>  Symmetric algorithms used in EAP-AKA' FS such as HMAC-SHA-256 and the algorithms use to generate AT_AUTN and AT_RES are practically secure

Karl: The PQ considerations are quite generic and does not really say anything about the security properties of this specific protocol (it even mentions constrained IoT). For example, it could instead talk about specifics of this protocol, e.g., Secrecy: the CK'/IK' goes into the derivation of the output keys, so even if a PQ adversary can compute the joint DH-key, then I assume only the FS property gets broken (possibly). The adversary would still not be able to break the symmetric key parts, so the established key would still be secret, right? Authentication: By the same argument: if symmetric key crypto would still be safe PQ, then the adversary won't be able to disrupt authentication and do impersonation attacks, I assume.
I like your angle on PQ. We need exact text though.
This sounds like good changes

even if a quantum computer of sufficient size and power to exploit elliptic curve cryptography will exist.  Deployments that need to consider risks decades into the future should transition to Post-  <ins> Quantum Cryptography (PQC) in the not-too-distant future.  Other systems may employ PQC when the quantum threat is more imminent. Current PQC algorithms have limitations compared to Elliptic Curve Cryptography (ECC) and the data sizes could be problematic for some constrained systems.  If a Cryptographically Relevant Quantum Computer (CRQC) is built it could recover the SHARED_SECRET from the ECDHE public keys. This would not affect the ability of EAP-AKA' (with or without this extension) to authenticate properly, however.  As symmetric key cryptography is safe even if CRQCs are built, an adversary still will not be able to disrupt authentication as it requires computing a correct AT_MAC value.  This computation requires the K_aut key which is based on MK and, ultimately, CK' and IK', but not SHARED_SECRET. Other output keys do include SHARED_SECRET via MK_ECDHE, but still include also CK' and IK' which are entirely based on symmetricy cryptography.  As a result, an adversary with a quantum computer still cannot compute the other output keys either. However, if the adversary has also obtained knowledge of the secrets associated with the SIM card, they could then compute CK', IK', and SHARED_SECRET, and any derived output keys.  This means that the the introduction of a powerful enough quantum computer would enable subverting this protocol extension, making it necessary to update the current ECC algorithms in this specification to PQC algorithms.  This specification does not add such algorithms, but a future specification may do that. </ins> Symmetric algorithms used in EAP-AKA' FS such as HMAC-SHA-256 and the algorithms use to generate AT_AUTN and AT_RES are practically secure


Forward Secrecy for EAP-AKA' is achieved by using an Elliptic Curve Diffie-Hellman (ECDH) exchange RFC7748.  To provide FS, the exchange must be run in an ephemeral manner, i.e., both sides generate <del> temporary keys as specified in e.g., RFC7748.  This method is referred to as ECDHE, where the last 'E' stands for Ephemeral.  The two initially registered elliptic curves and their wire format is chosen to align with the elliptic curves and formats specified for </del>  Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4 of 3GPP TS 33.501 TS.33.501.

Karl: Why is this "e.g." inserted in section 5? "generate temporary keys as specified in e.g., [RFC7748]" It sounds non-deterministic. If using RFC7748 is an option that can be negotiated or need to be pre-established, then maybe we could write something like: "according to the negotiated ciphersuite, e.g. [7748]." If the sentence is more describing a general way of how one would go about designing FS here, then perhaps something like: "To provide FS, a key exchange must run in an ephemeral manner...".
I think you are right. The text is a bit sloppy (but I don’t think it has changed in a while). I like your first formulation. Once you know the ciphersuite this is all specified & determined.
Will make a PR
Solution merged to the base.

Forward Secrecy for EAP-AKA' is achieved by using an Elliptic Curve Diffie-Hellman (ECDH) exchange RFC7748.  To provide FS, the exchange must be run in an ephemeral manner, i.e., both sides generate  <ins> temporary keys according to the negotiated ciphersuite, e.g., for X25519 this is done as specified in RFC7748.  This method is referred to as ECDHE, where the last 'E' stands for Ephemeral.  The two initially registered elliptic curves and their wire format is chosen to align with the elliptic curves and formats specified for </ins> Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4 of 3GPP TS 33.501 TS.33.501.


essential zero-trust principles. This specification updates RFC 9048, the EAP-AKA' authentication <del> method, with an optional extension.  The extension, when negotiated, provides Forward Secrecy for the session key generated as a part of the authentication run in EAP-AKA'.  This prevents an attacker who has gained access to the long-term pre-shared secret in a SIM card from being able to decrypt any past communications.  In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions.  This forces attackers to use active attacks instead. </del>  1.

Can you NAME review (and Karl)?
... since 9048 did not obsolete 5448
That is is good question. I changed "updates" from RFC 5448 to RFC 9048 as the document do not even mention RFC 5448 except in the Acknowledgments. Updating increases visability and makes it easier to find the EAP-AKA'-FS document. If it updates 5448 some more mentioning of 5448 would be needed in the introduction
Closing, fix merged to the document.

essential zero-trust principles. This specification updates RFC 9048, the EAP-AKA' authentication  <ins> method, with an optional extension.  Similarly, this specification also updates the earlier version of the EAP-AKA' specification in RFC 5448.  The extension, when negotiated, provides Forward Secrecy for the session key generated as a part of the authentication run in EAP- AKA'.  This prevents an attacker who has gained access to the long- term pre-shared secret in a SIM card from being able to decrypt any past communications.  In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions.  This forces attackers to use active attacks instead. </ins> 1.


generation function, if the Forward Secrecy extension is taken into use.  It will also at the same time indicate the used or desired ECDHE group.  A new attribute is needed to carry this information, as <del> AT_KDF carries the legacy KDF value which is still used together with the forward secrecy KDF value.  The legacy KDF value is also used by </del>  those EAP peers that cannot or do not want to use this extension.  The format of the AT_KDF_FS attribute is shown below. The fields are as follows:

I'm flying later today and unsure about how much I can do on Monday. I will need to deploy this change and submit the draft.
ATKDF carries the legacy KDF value for those EAP peers that cannot or do not want to use this extension. Gives the impression that ATKDF is ignored when ATKDFFS is used... Gives the impression that they are used together... The Specification is clear on how to derive keys when ATKDF in {1} and ATKDF_FS in {1,2} but does not give any descriptions on how other combinations are supposed to work.
I don't know how this is supposed to work but there are several options for how they are used together. ATKDF is completely ignored when ATKDFFS is used. ATKDF determines how to derive MK, Kaut, Kre ATKDFFS determines how to derive MKECDHE, Kre, MSK, EMSK Like 2. but the PRF used in deriving MKECDHE is determined by ATKDF.
Reasons that this need to be specified is. If someone specifies ATKDF = 2. How would that work with EAP-AKA' FS If someone wants to specify a PQC KEM for ATKDF_FS. Exactly what should they specify.
Ok this seems like a fair issues. Thanks for spotting this.
I see two options. Either we are (a) trying to be clever and split what impacts what (MK, K_aut) vs. everything else or (b) we only specify a specific combination (KDF=1 + FS=1 or 2) and explicitly say that future specs need to specify how new KDF or FS algorithms can be combined with others. Both have some drawbacks ... not sure we always want to have the same split in option a. And option b leaves out a lot of room for future extensions to forget to do this. Maybe go for option b? I will try to make a PR.
I am fine with b. The PR should make clear that this updates RFC 9048 with this new requirement.
Ok
A PR has been proposed: URL
Solved per the PR so that I can submit the draft (may not be able to work on Monday due to travel).

generation function, if the Forward Secrecy extension is taken into use.  It will also at the same time indicate the used or desired ECDHE group.  A new attribute is needed to carry this information, as  <ins> AT_KDF carries the basic KDF value which is still used together with the forward secrecy KDF value.  The basic KDF value is also used by </ins> those EAP peers that cannot or do not want to use this extension. <ins> This specification only specifies the behaviour relating to the following combinations of basic KDF values and forward secrecy KDF values: The basic KDF value in AT_KDF is 1, as specified in RFC5448 and RFC9048, and the forward secrecy KDF values in AT_KDF_FS are 1 or 2, as specified below and in kdf2. Any future specifications that add either new basic KDF or new forward secrecy KDF values need to specify how they are treated and what combinations are allowed.  This requirement is an update to how RFC5448 and RFC9048 may be extended in the future. </ins> The format of the AT_KDF_FS attribute is shown below. The fields are as follows:


echo-state to minimize the memory impact of having many unanswered Echo responses.  2.3. Actuation requests often require freshness guarantees to avoid

This opens up questions in URL Closes: URL
Like OSCOAP asked that new options declare themselves E or U, the HTTP mapping document asked for clarification what a cross proxy should do. Looks like both Repeat and Request-Tag are never expressed in HTTP, and that a cross proxy needs to repeat the request or run an operation with a Request-Tag just as a CoAP client; a CH proxy (CoAP server) needs to use its own discretion on when to ask for a Repeat.

echo-state to minimize the memory impact of having many unanswered Echo responses. <ins> CoAP-CoAP proxies MUST relay the Echo option unmodified, and SHOULD NOT cache responses when a Echo option is present in request or response for more than the exchange.  CoAP-HTTP proxies MAY request freshness, especially if they have reason to assume that access may require it (eg. because it is a PUT or POST); how this is determined is out of scope for this document.  HTTP-CoAP-Proxies SHOULD respond to Echo challenges themselves, as they know that the HTTP request is fresh, and can not forward the option anyway. </ins> 2.3. Actuation requests often require freshness guarantees to avoid


Abstract <del> This document defines two optional extensions to the Constrained Application Protocol (CoAP): the Echo option and the Request-Tag option.  Each of these options when integrity protected, such as with DTLS or OSCORE, protects against certain attacks on CoAP message exchanges. The Echo option enables a CoAP server to verify the freshness of a request by requiring the CoAP client to make another request and include a server-provided challenge.  The Request-Tag option allows the CoAP server to match message fragments belonging to the same request message, fragmented using the CoAP Block-Wise Transfer mechanism.  This document also specifies additional processing requirements on Block1 and Block2 options. </del>  1. <del> The initial CoAP suite of specifications (RFC7252, RFC7641, RFC7959) was designed with the assumption that security could be provided on a separate layer, in particular by using DTLS (RFC6347).  However, for some use cases, additional functionality or extra processing is needed to support secure CoAP operations. </del>  This document specifies two server-oriented CoAP options, the Echo <del> option and the Request-Tag option, addressing the security features request freshness and fragmented message body integrity, respectively.  These options in themselves do not replace the need for a security protocol; they specify the format and processing of data which, when integrity protected in a message, e.g. using DTLS (RFC6347) or OSCORE (I-D.ietf-core-object-security), provide those security features.  The Request-Tag option and also the ETag option are mandatory to use with Block1 and Block2, respectively, to secure blockwise operations with multiple representations of a particular resource as is specified in this document. Additional applications of the options are introduced.  For example, Echo can be used to mitigate amplification attacks. </del>  1.1. <del> A CoAP server receiving a request may not be able to verify when the request was sent by the CoAP client.  This remains true even if the request was protected with a security protocol, such as DTLS.  This makes CoAP requests vulnerable to certain delay attacks which are particularly incriminating in the case of actuators (I-D.mattsson- core-coap-actuators).  Some attacks are possible to mitigate by establishing fresh session keys (e.g. performing the DTLS handshake) for each actuation, but in general this is not a solution suitable for constrained environments. </del>  A straightforward mitigation of potential delayed requests is that the CoAP server rejects a request the first time it appears and asks freshness of a request.  This mechanism is not only important in the case of actuators, or other use cases where the CoAP operations require freshness of requests, but also in general for synchronizing <del> state between CoAP client and server. </del>  1.2. a pair of CoAP options, Block1 and Block2, pertaining to the request and response payload, respectively.  The blockwise functionality does not support the detection of interchanged blocks between different <del> message bodies to the same endpoint having the same block number. </del>  This remains true even when CoAP is used together with a security protocol such as DTLS or OSCORE, within the replay window (I- D.mattsson-core-coap-actuators), which is a vulnerability of CoAP 1.3.  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. "CoAP client" and "CoAP server", respectively, as defined in RFC7252. The terms "payload" and "body" of a message are used as in RFC7959. <del> The complete interchange of a request and a response body is called a </del>  (REST) "operation".  An operation fragmented using RFC7959 is called <del> a "blockwise operation".  A blockwise operation which is fragmenting the request body is called a "blockwise request operation".  A blockwise operation which is fragmenting the response body is called a "blockwise response operation". </del>  Two blockwise operations between the same endpoint pair on the same resource are said to be "concurrent" if a block of the second request The Echo option is a server-driven challenge-response mechanism for CoAP.  The Echo option value is a challenge from the server to the <del> client included in a CoAP response and echoed in a CoAP request. </del>  2.1. The Echo Option is elective, safe-to-forward, not part of the cache- key, and not repeatable, see echo-table. <del> The value of the Echo option MUST be a (pseudo-)random bit string of a length of at least 64 bits.  A new (pseudo-)random bit string MUST be generated by the server for each use of the Echo option. </del>  2.2. <del> It is important to identify under what conditions a CoAP request to a </del>  resource is required to be fresh.  These conditions can for example include what resource is requested, the request method and other data in the request, and conditions in the environment such as the state of the server or the time of the day. <del> A server MAY include the Echo option in a response.  The Echo option MUST NOT be used with empty CoAP requests (i.e.  Code=0.00).  If the server receives a request which has freshness requirements, and the request does not contain the Echo option, the server SHOULD send a 4.01 Unauthorized response with a Echo option.  The server SHOULD cache the transmitted Echo option value and the response transmit time (here denoted t0). Upon receiving a response with the Echo option within the EXCHANGE_LIFETIME (RFC7252) of the original request, the client SHOULD echo the Echo option with the same value in a new request to the server.  Upon receiving a 4.01 Unauthorized response with the Echo option in response to a request within the EXCHANGE_LIFETIME of the original request, the client SHOULD resend the original request. The client MAY send a different request compared to the original request. If the server receives a request which has freshness requirements, and the request contains the Echo option, the server MUST verify that the option value equals a cached value; otherwise the request is not processed further.  The server MUST calculate the round-trip time RTT = (t1 - t0), where t1 is the request receive time.  The server MUST only accept requests with a round-trip time below a certain threshold T, i.e. RTT < T, otherwise the request is not processed further, and an error message MAY be sent.  The threshold T is application specific, its value depends e.g. on the freshness requirements of the request.  An example message flow is illustrated in echo-figure. When used to serve freshness requirements, CoAP messages containing the Echo option MUST be integrity protected, e.g. using DTLS or OSCORE (I-D.ietf-core-object-security). If the server loses time synchronization, e.g. due to reboot, it MUST delete all cached Echo option values and response transmission times. Constrained server implementations can use the mechanisms outlined in echo-state to minimize the memory impact of having many unanswered Echo responses. CoAP-CoAP proxies MUST relay the Echo option unmodified, and SHOULD NOT cache responses when a Echo option is present in request or response for more than the exchange.  CoAP-HTTP proxies MAY request freshness, especially if they have reason to assume that access may require it (eg. because it is a PUT or POST); how this is determined is out of scope for this document.  HTTP-CoAP-Proxies SHOULD respond </del>  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- <del> After: 0 and terminate any underlying Keep-Alive connection.  It MAY also use other mechanisms to establish freshness of the HTTP request that are not specified here. </del>  2.3. Actuation requests often require freshness guarantees to avoid <del> accidental or malicious delayed actuator actions. </del>  To avoid additional roundtrips for applications with multiple actuator requests in rapid sequence between the same client and If a server reboots during operation it may need to synchronize state with requesting clients before continuing the interaction. <del> For example, with OSCORE it is possible to reuse a persistently stored security context by synchronizing the Partial IV (sequence number) using the Echo option. </del>  When a device joins a multicast/broadcast group the device may need to synchronize state or time with the sender to ensure that Section 11.3 of RFC7252 (where an attacker would put a victim's address in the source address of a CoAP request).  For this purpose, the server MAY ask a client to Echo its request to verify <del> its source address.  This needs to be done only once per peer, and </del>  limits the range of potential victims from the general Internet to endpoints that have been previously in contact with the server. For this application, the Echo option can be used in messages that are not integrity protected, for example during discovery.  3. The Request-Tag is intended for use as a short-lived identifier for body. Note that this mechanism is implicitly implemented when the security <del> layer guarantees ordered delivery (e.g.  CoAP over TLS I- D.tschofenig-core-coap-tcp-tls).  This is because with each message, any earlier operation can be regarded as concluded by the client, so it never needs to set the Request-Tag option unless it wants to perform concurrent operations. </del>  3.3.2. 5. <del> [TBD: Fill out the option templates for Echo and Request-Tag] </del>  6. <del> Servers that store a Echo challenge per client can be attacked for resource exhaustion, and should consider minimizing the state kept per client, e.g. using a mechanism as described in echo-state. </del>

I did quite a lot of changes to the Echo parts as discussed earlier. The Echo parts are now clearer updated in requirements and general processing, and example implementations for Token Option Values. I wrote a reasonably long security consideration chapter and added the missing IANA section. I added updated Token handling which requires some changes to abstract and introduction. Removed some definitions that were not used. I have not touched the Request-Tag parts except for maybe some editorials.
I think you should already have write access to the repository; if you can't just push your changes, I'm afraid you'll have to ask Carsten to add you to the team at URL I'm merging this now to get things on, and am trying to add some fixes today still to upload this evening's state before the cut-off. A suggestion w/rt the pull request branches: could you just add commits rather than appending them (unless you're changing around in the same place)? That'd make it much easier to update one's mental model of the document.
The terms "blockwise request operation" and "blockwise response operation" are used (the former frequently, the latter only once), so I've reverted the line that drops them to their previous state in 382c308f3.

Abstract  <ins> This document specifies several security enhancements to the Constrained Application Protocol (CoAP).  Two optional extensions are defined: the Echo option and the Request-Tag option.  Each of these options provide additional features to CoAP and protects against certain attacks.  The document also updates the processing requirements on the Block options and the Token.  The updated Token processing ensures secure binding of responses to requests. </ins> 1.  <ins> The initial Constrained Application Protocol (CoAP) suite of specifications (RFC7252, RFC7641, and RFC7959) was designed with the assumption that security could be provided on a separate layer, in particular by using DTLS (RFC6347).  However, for some use cases, additional functionality or extra processing is needed to support secure CoAP operations.  This document specifies several security enhancements to the Constrained Application Protocol (CoAP). </ins> This document specifies two server-oriented CoAP options, the Echo  <ins> option and the Request-Tag option, mainly addressing the security features request freshness and fragmented message body integrity, respectively.  The Echo option enables a CoAP server to verify the freshness of a request, verify the aliveness of a client, synchronize state, or force a client to demonstrate reachability at its apparent network address.  The Request-Tag option allows the CoAP server to match message fragments belonging to the same request, fragmented using the CoAP Block-Wise Transfer mechanism, which mitigates attacks and enables concurrent blockwise operations.  These options in themselves do not replace the need for a security protocol; they specify the format and processing of data which, when integrity protected using e.g.  DTLS (RFC6347), TLS (RFC5246), or OSCORE (I- D.ietf-core-object-security), provide the additional security features. The document also updates the processing requirements on the Block1 option, the Block2 option, and the Token.  The updated blockwise processing secure blockwise operations with multiple representations of a particular resource.  The updated Token processing ensures secure binding of responses to requests. </ins> 1.1.  <ins> A CoAP server receiving a request is in general not able to verify when the request was sent by the CoAP client.  This remains true even if the request was protected with a security protocol, such as DTLS. This makes CoAP requests vulnerable to certain delay attacks which are particularly incriminating in the case of actuators (I- D.mattsson-core-coap-actuators).  Some attacks are possible to mitigate by establishing fresh session keys (e.g. performing the DTLS handshake) for each actuation, but in general this is not a solution suitable for constrained environments. </ins> A straightforward mitigation of potential delayed requests is that the CoAP server rejects a request the first time it appears and asks freshness of a request.  This mechanism is not only important in the case of actuators, or other use cases where the CoAP operations require freshness of requests, but also in general for synchronizing  <ins> state between CoAP client and server and to verify aliveness of the client. </ins> 1.2. a pair of CoAP options, Block1 and Block2, pertaining to the request and response payload, respectively.  The blockwise functionality does not support the detection of interchanged blocks between different  <ins> message bodies to the same resource having the same block number. </ins> This remains true even when CoAP is used together with a security protocol such as DTLS or OSCORE, within the replay window (I- D.mattsson-core-coap-actuators), which is a vulnerability of CoAP 1.3. <ins> A fundamental requirement of secure REST operations is that the client can bind a response to a particular request.  In HTTPS this is assured by the ordered and reliable delivery as well as mandating that the server sends responses in the same order that the requests were received. The same is not true for CoAP where the server can return responses in any order.  Concurrent requests are instead differentiated by their Token.  Unfortunately, CoAP RFC7252 does not treat Token as a cryptographically important value and does not give stricter guidelines than that the tokens currently "in use" SHOULD (not SHALL) be unique.  If used with security protocol not providing bindings between requests and responses (e.g.  DTLS and TLS) token reuse may result in situations where a client matches a response to the wrong request (see e.g.  Section 2.3 of I-D.mattsson-core-coap-actuators). Note that mismatches can also happen for other reasons than a malicious attacker, e.g. delayed delivery or a server sending notifications to an uninterested client. A straightforward mitigation is to mandate clients to never reuse tokens until the traffic keys have been replaced.  As there may be any number of responses to a request (see e.g.  RFC7641), the easiest way to accomplish this is to implement the token as a counter and never reuse any tokens at all.  This document updates the Token processing in RFC7252 to always assure a cryptographically secure binding of responses to requests. 1.4. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. "CoAP client" and "CoAP server", respectively, as defined in RFC7252. The terms "payload" and "body" of a message are used as in RFC7959.  <ins> The complete interchange of a request and a response is called a </ins> (REST) "operation".  An operation fragmented using RFC7959 is called  <ins> a "blockwise operation". </ins> Two blockwise operations between the same endpoint pair on the same resource are said to be "concurrent" if a block of the second request The Echo option is a server-driven challenge-response mechanism for CoAP.  The Echo option value is a challenge from the server to the  <ins> client included in a CoAP response and echoed in one or more CoAP request. </ins> 2.1. The Echo Option is elective, safe-to-forward, not part of the cache- key, and not repeatable, see echo-table.  <ins> [Note to RFC editor: If this document is not released together with OSCORE but before it, the following paragraph and the "E" column above need to move into OSCORE.] The Echo option value is generated by the server, and its content and structure are implementation specific.  Different methods for generating Echo option values are outlined in echo-state.  Clients and intermediaries MUST treat an Echo option value as opaque and make no assumptions about its content or structure. When receiving an Echo option in a request, the server MUST be able to verify that the Echo option value was generated by the server as well as the point in time when the Echo option value was generated. </ins> 2.2.  <ins> The Echo option MAY be included in any request or response (see echo- app for different applications), but the Echo option MUST NOT be used with empty CoAP requests (i.e.  Code=0.00). If the server receives a request which has freshness requirements, the request does not contain a fresh Echo option value, and the server cannot verify the freshness of the request in some other way, the server MUST NOT process the request further and SHOULD send a 4.01 Unauthorized response with an Echo option. The application decides under what conditions a CoAP request to a </ins> resource is required to be fresh.  These conditions can for example include what resource is requested, the request method and other data in the request, and conditions in the environment such as the state of the server or the time of the day.  <ins> The server may also include the Echo option in a response to verify the aliveness of a client, to synchronize state, or to force a client to demonstrate reachability at their apparent network address. Upon receiving a 4.01 Unauthorized response with the Echo option, the client SHOULD resend the original request with the addition of an Echo option with the received Echo option value.  The client MAY send a different request compared to the original request.  Upon receiving any other response with the Echo option, the client SHOULD echo the Echo option value in a next request to the server.  The client MAY include the same Echo option value in several different requests to the server. Upon receiving a request with the Echo option, the server determines if the request has freshness requirement.  If the request does not have freshness requirements, the Echo option MAY be ignored.  If the request has freshness requirements and the server cannot verify the freshness of the request in some other way, the server MUST verify that the Echo option value was generated by the server; otherwise the request is not processed further.  The server MUST then calculate the round-trip time RTT = (t1 - t0), where t1 is the request receive time and t0 is the transmit time of the response that included the specific Echo option value.  The server MUST only accept requests with a round-trip time below a certain threshold T, i.e. RTT < T, otherwise the request is not processed further, and an error message MAY be sent.  The threshold T is application specific, its value depends e.g. on the freshness requirements of the request.  An example message flow is illustrated in echo-figure. When used to serve freshness requirements (including client aliveness and state synchronizing), CoAP requests containing the Echo option MUST be integrity protected, e.g. using DTLS, TLS, or OSCORE (I- D.ietf-core-object-security).  When used to demonstrate reachability at their apparent network address, the Echo option MAY be used without protection. Note that the server does not have to synchronize the time used for the Echo timestamps with any other party.  If the server loses time synchronization, e.g. due to reboot, it MUST reject all Echo values that was created before time synchronization was lost. CoAP-CoAP proxies MUST relay the Echo option unmodified.  The CoAP server side of CoAP-HTTP proxies MAY request freshness, especially if they have reason to assume that access may require it (e.g. because it is a PUT or POST); how this is determined is out of scope for this document.  The CoAP client side of HTTP-CoAP-Proxies SHOULD respond </ins> 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-  <ins> After: 0 and terminate any underlying Keep-Alive connection.  They MAY also use other mechanisms to establish freshness of the HTTP request that are not specified here. </ins> 2.3. Actuation requests often require freshness guarantees to avoid  <ins> accidental or malicious delayed actuator actions.  In general, all non-safe methods (e.g.  POST, PUT, DELETE) may require freshness guarantees for secure operation. </ins> To avoid additional roundtrips for applications with multiple actuator requests in rapid sequence between the same client and If a server reboots during operation it may need to synchronize state with requesting clients before continuing the interaction.  <ins> 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. </ins> When a device joins a multicast/broadcast group the device may need to synchronize state or time with the sender to ensure that Section 11.3 of RFC7252 (where an attacker would put a victim's address in the source address of a CoAP request).  For this purpose, the server MAY ask a client to Echo its request to verify  <ins> its source address.  This needs to be done only once per peer and </ins> limits the range of potential victims from the general Internet to endpoints that have been previously in contact with the server. For this application, the Echo option can be used in messages that are not integrity protected, for example during discovery. <ins> A server may want to verify the aliveness of a client by responding with an Echo option. </ins> 3. The Request-Tag is intended for use as a short-lived identifier for body. Note that this mechanism is implicitly implemented when the security  <ins> layer guarantees ordered delivery (e.g.  CoAP over TLS RFC8323). This is because with each message, any earlier operation can be regarded as concluded by the client, so it never needs to set the Request-Tag option unless it wants to perform concurrent operations. </ins> 3.3.2. 5.  <ins> This section updates the Token processing in Section 5.3.1 of RFC7252 by adding the following text: When CoAP is used with a security protocol not providing bindings between requests and responses, the client MUST NOT reuse tokens until the traffic keys have been replaced.  The easiest way to accomplish this is to implement the Token as a counter, this approach SHOULD be followed. </ins> 6.  <ins> This document adds the following option numbers to the "CoAP Option Numbers" registry defined by RFC7252: 7. Servers SHOULD NOT put any privacy sensitive information in the Echo or Request-Tag option values.  Unencrypted timestamps MAY reveal information about the server such as its system time or location. Servers MUST use a monotonic clock to generate timestamps and compute round-trip times.  Servers SHOULD NOT use their system time for timestamps, as system time is often not monotonic, may reveal that the server will accept expired certificates, or reveal the server's location.  Use of non-monotonic clocks is not secure as the server will accept expired Echo option values if the clock is moved backward.  The server will also reject fresh Echo option values if the clock is moved forward.  An attacker may be able to affect the server's system time in various ways such as setting up a fake NTP server or broadcasting false time signals to radio-controlled clocks. Servers SHOULD use the time since reboot measured in some unit of time.  Servers MAY reset the timer periodically even when not rebooting. The availability of a secure pseudorandom number generator and truly random seeds are essential for the security of the Echo option.  If no true random number generator is available, a truly random seed must be provided from an external source. An Echo value with 64 (pseudo-)random bits gives the same theoretical security level against forgeries as a 64-bit MAC (as used in e.g. AES_128_CCM_8).  In practice, forgery of an Echo option value is much harder as an attacker must also forge the MAC in the security protocol.  The Echo option value MUST contain 32 (pseudo-)random bits that are not predictable for any other party than the server, and SHOULD contain 64 (pseudo-)random bits.  A server MAY use different security levels for different uses cases (client aliveness, request freshness, state synchronization, network address reachability, etc.). The security provided by the Echo and Request-Tag options depends on the security protocol used.  CoAP and HTTP proxies require (D)TLS to be terminated at the proxies.  The proxies are therefore able to manipulate, inject, delete, or reorder options or packets.  The security claims in such architectures only hold under the assumption that all intermediaries are fully trusted and have not been compromised. Servers that use the List of Cached Random Values and Timestamps method described in echo-state may be vulnerable to resource exhaustion attacks.  On way to minimizing state is to use the Integrity Protected Timestamp method described in echo-state. </ins>


that the Echo option value was generated by the server; otherwise the request is not processed further.  The server MUST then calculate the round-trip time RTT = (t1 - t0), where t1 is the request receive time <del> and t0 is the transmit time of the response that included the specific Echo option value.  The server MUST only accept requests with a round-trip time below a certain threshold T, i.e. RTT < T, otherwise the request is not processed further, and an error message MAY be sent.  The threshold T is application specific, its value </del>  depends e.g. on the freshness requirements of the request.  An example message flow is illustrated in echo-figure.

Clarifications based on Jim's review. "t0 is the time when the Echo option value was generated." "If the server cannot verify that the Echo option value was generated by the server or the round-trip time is not below the threshold the request is not processed further, and an error message MAY be sent. The error message SHOULD include a new Echo option."

that the Echo option value was generated by the server; otherwise the request is not processed further.  The server MUST then calculate the round-trip time RTT = (t1 - t0), where t1 is the request receive time  <ins> and t0 is the time when the Echo option value was generated.  The server MUST only accept requests with a round-trip time below a certain threshold T, i.e. RTT < T.  If the server cannot verify that the Echo option value was generated by the server or the round-trip time is not below the threshold the request is not processed further, and an error message MAY be sent.  The error message SHOULD include a new Echo option.  The threshold T is application specific, its value </ins> depends e.g. on the freshness requirements of the request.  An example message flow is illustrated in echo-figure.


The document also updates the processing requirements on the Token. The updated processing ensures secure binding of responses to <del> requests. </del>  1.1. When CoAP is used with a security protocol not providing bindings between requests and responses, the client MUST NOT reuse tokens <del> until the AEAD keys have been replaced.  The easiest way to </del>  accomplish this is to implement the Token as a counter, this approach SHOULD be followed.

"AEAD keys" -> "traffic keys" In (D)TLS, the algorithms may be other types than AEAD. "thus mitigating error cases and attacks where the client may erroneously associate the wrong response to a request." Some more text about this in the intro, the current text was very barebone.

The document also updates the processing requirements on the Token. The updated processing ensures secure binding of responses to  <ins> requests, thus mitigating error cases and attacks where the client may erroneously associate the wrong response to a request. </ins> 1.1. When CoAP is used with a security protocol not providing bindings between requests and responses, the client MUST NOT reuse tokens  <ins> until the traffic keys have been replaced.  The easiest way to </ins> accomplish this is to implement the Token as a counter, this approach SHOULD be followed.


sending messages without Request-Tag options whenever possible, and using short values when the absent option can not be recycled.  3.4. 3.4.1.

Changes in response to Carsten's comments Disposition: Will merge soon if nobody objects.
Updated to match the changes to master

sending messages without Request-Tag options whenever possible, and using short values when the absent option can not be recycled. <ins> The Request-Tag options MAY be present in request messages that carry a Block2 option even if those messages are not part of a blockwise request operation (this is to allow the operation described in simpleproxy).  The Request-Tag option MUST NOT be present in response messages, and MUST NOT be present if neither the Block1 nor the Block2 option is present. </ins> 3.4. 3.4.1.


importance.  The client MUST make sure that tokens are not used in a way so that responses risk being associated with the wrong request. One easy way to accomplish this is to implement the Token (or part of <del> the Token) as a sequence number for each connection, starting at zero and reset to zero after rekeying, this approach SHOULD be followed. To avoid collisions the sequence number can be encoded with a fixed length or with some length-value encoding. </del>  6. exhaustion attacks.  One way to minimize state is to use the Integrity Protected Timestamp method described in echo-state.  7. Implementations SHOULD NOT put any privacy sensitive information in

"the encoding of the sequence number has to be chosen . . ." Replace "has to" with "MUST"? (I merged now and proposed the commit in the master branch)
I had to resolve a conflict before merging. Hope I did that right.

importance.  The client MUST make sure that tokens are not used in a way so that responses risk being associated with the wrong request. One easy way to accomplish this is to implement the Token (or part of  <ins> the Token) as a sequence number starting at zero for each new or rekeyed secure connection, this approach SHOULD be followed. </ins> 6. exhaustion attacks.  One way to minimize state is to use the Integrity Protected Timestamp method described in echo-state. <ins> When the Token (or part of the Token) contains a sequence number, the encoding of the sequence number has to be chosen in a way to avoid any collisions.  This is especially true when the Token contains more information than just the sequence number (e.g. serialized state). </ins> 7. Implementations SHOULD NOT put any privacy sensitive information in


state between CoAP client and server, verify aliveness of the client, or force a client to demonstrate reachability at its claimed network address.  The same functionality can be provided by echoing freshness <del> tokens in CoAP payloads, but this only works for methods and response codes defined to have a payload.  The Echo option provides a convention to transfer freshness tokens that works for all methods and response codes. </del>  1.2. req-fresh.  The Echo option value is a challenge from the server to the client included in a CoAP response and echoed back to the server in one or more CoAP requests.  The Echo option provides a convention <del> to transfer freshness Tokens that works for all CoAP methods and </del>  response codes. 2.1.

With those, any open issues I'm aware of except the single words from and the larger discussion or are resolved from my PoV.
s/freshness tokens/freshness indicators/ : Amended by a proposed term to solve the remaining point in -- feel free to change to something different, it's just a shortcut suggestion.
"freshness indicators": OK with John, 0.00 OK, endpoints with security associations OK
"Block-Wise" vs. "block-wise" vs. "blockwise" "Token" vs. "Token" I think it should be Token. "freshness tokens" I think we should rewrite "freshness tokens" to that the word "token" is only used for the CoAP Token.
The Token and block-wise have been addressed in your f9abfe02595c19a6f5d37f88a29cfafa59a3254a. Any candidates for "freshness tokens" replacement? "freshness indicators" maybe?
I tried to add security considerations for token reuse to the PR. Please review, this is not trivial. Token reuse for DTLS seem hard if not impossible to do securely. I don't find Token reuse with DTLS possible to do securely..... am I missing something? Token reuse for TLS without Observer and without Groups communication seems quite easy. Do we need to say something about Group communication? Do we need to say something about stateless tokens? I think the current requirements on integrity protection and replay protection protection in the stateless draft should be enough.
I think John refers to e49ff36
Taken care of in the version -07
While not designed for that, the Echo option can be abused as mechanism like HTTP's Cookie (especially when preemptive Echo values are passed around), and I'm pretty sure we don't want that. We should at least point that out somewhere, and say that servers MUST NOT abuse it (however to phrase that -- "use Echo to correlate requests for other purposes than showing frechness and reachability"?). For actual mitigation, we could recommend (or even demand?) that clients only send preemptive Echo values on the same endpoint (5-tuple) on which they were received -- so that if their address changes, no Echo value will leak identity.
To still allow Echo in OSCORE groupcom (new server asks for Echo, client repeats it in next multicast, others ignore it), we could limit that mitigation to unauthenticated use cases (as the client has a known persistable identity with OSCORE anyway).
Yes, this should definitely be a privacy consideration.
I wrote some initial text for the privacy consideration regarding this. Please revieew, modify and add things. Should we have any considerations for group OSCORE? of should we let draft-dijk-core-groupcomm-bis and group OSCORE discuss that. Echo Request is hopefully published before them.
I think John refers to this commit: bcceb8a
I'm almost happy with it, the last word I'm unhappy with is being addressed in an upcoming commit that closes it by drawing on a solution to the "the spec does not say anything regarding taking echo from (no-security, DTLS, [...]) and using it in (no-security, DTLS, [...])" comment,

state between CoAP client and server, verify aliveness of the client, or force a client to demonstrate reachability at its claimed network address.  The same functionality can be provided by echoing freshness  <ins> indicators in CoAP payloads, but this only works for methods and response codes defined to have a payload.  The Echo option provides a convention to transfer freshness indicators that works for all methods and response codes. </ins> 1.2. req-fresh.  The Echo option value is a challenge from the server to the client included in a CoAP response and echoed back to the server in one or more CoAP requests.  The Echo option provides a convention  <ins> to transfer freshness indicators that works for all CoAP methods and </ins> response codes. 2.1.


the original request was never retransmitted, <del> the response was piggybacked in an Acknowledgement message (a confirmable response may have been transmitted multiple times), and </del>  if observation was used, the same holds for the registration, all re-registrations, and the cancellation.

This is my take on , pointing to the cases when it's possible to reuse tokens, at the same time discouraging it for all other cases. The acceptable cases are the ones identified in the last authors' call, and TLS and OSCORE I've added in a potential third case in source comments; it's still something we can dig up if people ask for more comprehensive exceptions, but there's so many things that can go wrong that I'd rather not have it in.
Thanks, merged. I did put in a clarification on the f81c97221a1f0e7571ad06811a8b713659741336 edit -- acutally both CON and NON would be unusable.
I tried to add security considerations for token reuse to the PR. Please review, this is not trivial. Token reuse for DTLS seem hard if not impossible to do securely. I don't find Token reuse with DTLS possible to do securely..... am I missing something? Token reuse for TLS without Observer and without Groups communication seems quite easy. Do we need to say something about Group communication? Do we need to say something about stateless tokens? I think the current requirements on integrity protection and replay protection protection in the stateless draft should be enough.
I think John refers to e49ff36
Taken care of in the version -07

the original request was never retransmitted,  <ins> the response was piggybacked in an Acknowledgement message (as a confirmable or non-confirmable response may have been transmitted multiple times), and </ins> if observation was used, the same holds for the registration, all re-registrations, and the cancellation.


option SHOULD contain the client's network address, but MAY be unprotected. <del> A CoAP-to-CoAP proxy MAY respond to requests with 4.01 with an Echo option to ensure the client's reachability at its claimed address, and MUST remove the Echo option it recognizes as one generated by itself on follow-up requests.  However, it MUST relay the Echo option of responses unmodified, and MUST relay the Echo option of requests it does not recognize as generated by itself unmodified. </del>  The CoAP server side of CoAP-to-HTTP proxies MAY request freshness, especially if they have reason to assume that access may require it

... and clarify that client aliveness is a cryptographic property. This is in response to comments about the conflict between "OSCORE servers MUST ONLY produce Inner" and "Echo option [...] MAY be unprotected". Contributes-To: URL
Sounds good.
I just noticed there as c09eeaf8088bc62110ea4f8f66199105651e6d90 on this stack as well and (hopefully) simplified that into 456a6f4b28cfc309938511f11dfbc87da25408d7, please have a look there.
Good, looks like an improvement.
“CoAP-to-CoAP proxy MAY set an Echo option on responses, both on forwarded ones that had no Echo option or ones generated by the proxy (from cache or as an error).” I assume a proxy having a cache can generate it’s own requests as well. In these cases the proxy should be allowed to behave like any other client. The current text “However, it MUST relay the Echo option of responses unmodified” kind of give the idea that proxys cannot remove the Echo values.
(from today's telco) "client aliveness" questions lead to the question of who is the client, and from there to which endpoints are involved. From RFC7252's endpoint definition, the security association is part of it. So there are two endpoints involved, the hop-by-hop endpoint (which has no security, or possibly the security of a wrapping DTLS connection) and the end-to-end endpoint (which is OSCORE protected), which may or may not reside on the same host. Different positions of the Echo option relate to communication with different endpoints. It'd be easier to describe the Echo option behavior if that distinction were made explicit in OSCORE, and I don't want to introduce too much of new concepts in here where they don't belong -- finding text to address that might be tricky. (Once words are found to describe that in the Echo text, we'll also have the words to talk about the independent alivenesses of the endpoints, and say that for cryptographically showing "client aliveness" (that's a term there), the aliveness of the inner endpoint must be shown).
I've written up to address the issue we received comments on. On the topic of endpoints, I found that the text already clearly separates the use case of "client aliveness" and "network reachability"; I've added a word on the aliveness being a cryptographic property and not just another word for the network address being in service, which is hopefully enough for the confusion that has arisen. No need to make things more complicated by pointing out the two server endpoints that are still around there: we never talk of properties that either can have (client aliveness is about the protected endpoint, network reachability is about the unprotected one). If you're happy with , I think we can close this.
Taken care of with

option SHOULD contain the client's network address, but MAY be unprotected.  <ins> CoAP-to-CoAP proxy MAY respond to requests with an Echo option, but MUST remove the Echo option it recognizes as one generated by itself on follow-up requests.  However, it MUST relay the Echo option of responses unmodified, and MUST relay the Echo option of requests it does not recognize as generated by itself unmodified.  A CoAP-to-CoAP proxy MAY however add an Echo Option to a response that does not have an Echo Option. </ins> The CoAP server side of CoAP-to-HTTP proxies MAY request freshness, especially if they have reason to assume that access may require it


Two matchable block-wise operations are said to be "concurrent" if a block of the second request is exchanged even though the client still intends to exchange further blocks in the first operation. <del> (Concurrent block-wise request operations are impossible with the options of RFC7959 because the second operation's block overwrites </del>  any state of the first exchange.). The Echo and Request-Tag options are defined in this document. assumptions about its content or structure. Two messages carrying the same Request-Tag is a necessary but not <del> sufficient condition for being part of the same operation.  They can still be treated as independent messages by the server (e.g. when it sends 2.01/2.04 responses for every block), or initiate a new operation (overwriting kept context) when the later message carries Block1 number 0. </del>  As it has always been, a server that can only serve a limited number of block-wise operations at the same time can delay the start of the 3.3. For each separate block-wise request operation, the client can choose <del> a Request-Tag value, or choose not to set a Request-Tag.  Starting a request operation matchable to a previous operation and even using the same Request-Tag value is called request tag recycling.  The absence of a Request-Tag option is viewed as a value distinct from all values with a single Request-Tag option set; starting a request operation matchable to a previous operation where neither has a Request-Tag option therefore constitutes request tag recycling just as well (also called "recycling the absent option"). Clients MUST NOT recycle a request tag unless the first operation has concluded.  What constitutes a concluded operation depends on the application, and is outlined individually in req-tag-applications. </del>  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 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 <del> a Request-Tag value that is not in use by the other matchable operations for the new operation. </del>  Otherwise, it can start the new operation without setting the Request-Tag option on it.

Also includes changes to a paragraph that will be Section 3 after the pending intro-shoving. Rationale as in the review response mail: Reference made more precise, "from a single endpopoint" added. Split up into separate sentences for better clarity. That requirement was already kind of conditional on the client using Request-Tag for a particular purpose -- for otherwise the "unless concluded" clause makes no sense, for that's defined by the purpose. Rephrased to pull in the purpose before the MUST and make that explicit. The "that support Request-Tag" comment should be obsolete by hat, for only who supports it can use it for something. (We did, in the chat earlier, consider asking the WG whether that'd all mean that we're updating RFC7959, but as we're now back to "If you want to achieve X, do Y" wording, I don't see necessity for such an update). Added to the initial (now split up) paragraph of that section. Explicitly included as an option now. (Would have been even easier if there were a once-and-for-all definition of a "request-tag value" that can be absent or have the option's data, but that had long-winded wording in the last version that was in, and still might be mistaken by readers that don't have the precise definition at hand).
Looks good.

Two matchable block-wise operations are said to be "concurrent" if a block of the second request is exchanged even though the client still intends to exchange further blocks in the first operation.  <ins> (Concurrent block-wise request operations from a single endpoint are impossible with the options of RFC7959 (see the last paragraphs of Sections 2.4 and 2.5) because the second operation's block overwrites </ins> any state of the first exchange.). The Echo and Request-Tag options are defined in this document. assumptions about its content or structure. Two messages carrying the same Request-Tag is a necessary but not  <ins> sufficient condition for being part of the same operation.  For one, a server may still treat them as independent messages when it sends 2.01/2.04 responses for every block.  Also, a client that lost interest in an old operation but wants to start over can overwrite the server's old state with a new initial (num=0) Block1 request and the same Request-Tag under some circumstances.  Likewise, that results in the new message not being part of he old operation. </ins> As it has always been, a server that can only serve a limited number of block-wise operations at the same time can delay the start of the 3.3. For each separate block-wise request operation, the client can choose  <ins> a Request-Tag value, or choose not to set a Request-Tag.  It needs to be set to the same value (or unset) in all messages belonging to the same operation, as otherwise they are treated as separate operations by the server. Starting a request operation matchable to a previous operation and even using the same Request-Tag value is called request tag recycling.  The absence of a Request-Tag option is viewed as a value distinct from all values with a single Request-Tag option set; starting a request operation matchable to a previous operation where neither has a Request-Tag option therefore constitutes request tag recycling just as well (also called "recycling the absent option"). Clients that use Request-Tag for a particular purpose (like in req- tag-applications) MUST NOT recycle a request tag unless the first operation has concluded.  What constitutes a concluded operation depends on that purpose, and is defined there. </ins> 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 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  <ins> a Request-Tag value (including the absent option) that is not in use by the other matchable operations for the new operation. </ins> Otherwise, it can start the new operation without setting the Request-Tag option on it.


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 <del> claimed network address.  The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request.  The update to the client Token processing requirements of RFC 7252 forbids non-secure reuse of Tokens to ensure binding of responses to requests when CoAP is used with security. </del>  1. (RFC6347), TLS (RFC8446), or OSCORE (RFC8613), provide the additional security features.  The document also updates the Token processing requirements for clients specified in RFC7252.  The updated processing forbids non- secure reuse of Tokens to ensure binding of responses to requests 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 <del> address in the source address of a CoAP request).  For this purpose, a server MAY ask a client to Echo its request to verify </del>  its source address.  This needs to be done only once per peer and limits the range of potential victims from the general Internet to endpoints that have been previously in contact with the server. distinguish different origin client endpoints.  Following from the recommendation above, a proxy that sends large responses to unauthenticated peers SHOULD mitigate amplification attacks. <del> The proxy MAY use Echo to verify origin reachability as </del>  described in echo-proc.  The proxy MAY forward idempotent requests immediately to have a cached result available when the client's Echoed request arrives.  A server may want to use the request freshness provided by the Echo to verify the aliveness of a client.  Note that in a deployment with hop-by-hop security and proxies, the server can

I take URL as a mandate to make Echo mitigation of amplification issues a more prominent point in ERT. (It wasn't intended as an update, as the SHOULD mentioned there is just a copy of the original 7252 SHOULD and we "provide one way", but no objections from me either). Along that I'd offer concrete size numbers, and a note that this really needs piggy-backed responses. Unless objected to, I'd take this into the next version of ERT (as soon as I have processed any other pending comments if there still are any). In draft-ietf-core-echo-request-tag-URL, Section 2.4 item 3 places a SHOULD on a "server that sends large responses to unauthenticated peers” to mitigate the amplification threat using the Echo Option procedure. draft-ietf-core-echo-request-tag already is flagged to update RFC7252, but this is called out in the abstract and introduction only for Token processing. The SHOULD in Section 2.4 item 3 is a bit hidden for my taste. My esteemed co-chair pointed out to me that we don’t really advertise a mitigation for the substantial amplification opportunities posed by those installations that do not translate the discussion in Section 11.3 of RFC 7252 into active behavior. There are now people out there that believe CoAP ranks with DNS and NTP in the DDoS threat generated. Would the CoRE WG be fine with expanding the “updates 7252” text in draft-ietf-core-echo-request-tag to also include recommending this mitigation? If you have a position on this, please reply to the list (or to the chairs) by March 2nd. Grüße, Carsten

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  <ins> claimed network address; it is now the recommeded way to mitigate amplification attacks.  The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. The update to the client Token processing requirements of RFC 7252 forbids non-secure reuse of Tokens to ensure binding of responses to requests when CoAP is used with security. </ins> 1. (RFC6347), TLS (RFC8446), or OSCORE (RFC8613), provide the additional security features. <ins> This document updates RFC7252 with a recommendation that servers use the Echo option to mitigate amplification attacks. </ins> The document also updates the Token processing requirements for clients specified in RFC7252.  The updated processing forbids non- secure reuse of Tokens to ensure binding of responses to requests 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  <ins> 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 </ins> its source address.  This needs to be done only once per peer and limits the range of potential victims from the general Internet to endpoints that have been previously in contact with the server. distinguish different origin client endpoints.  Following from the recommendation above, a proxy that sends large responses to unauthenticated peers SHOULD mitigate amplification attacks.  <ins> The proxy SHOULD use Echo to verify origin reachability as </ins> described in echo-proc.  The proxy MAY forward idempotent requests immediately to have a cached result available when the client's Echoed request arrives. <ins> Amplification mitigation should be used when the the response would be more than three times the size of the request, considering the complete frame on the wire as it is typically sent across the Internet.  In practice, this allows UDP data of at least 152 Bytes without further checks. When an Echo response is sent to mitigate amplification, it MUST be sent as a piggybacked or non-confirmable response, never as a separate one (which would cause amplification due to retransmission). </ins> A server may want to use the request freshness provided by the Echo to verify the aliveness of a client.  Note that in a deployment with hop-by-hop security and proxies, the server can


using short values when the absent option can not be recycled. The Request-Tag options MAY be present in request messages that carry <del> a Block2 option even if those messages are not part of a blockwise request operation (this is to allow the operation described in simpleproxy).  The Request-Tag option MUST NOT be present in response messages, and MUST NOT be present if neither the Block1 nor the Block2 option is present. </del>  3.5.

(because they can be created as a consequence of Request-Tag being safe-to-forward), but make them no-ops. as that's the last item in there.
Closed following Francesca's mail at URL
See URL Hi, I have taken some time to review draft-ietf-core-echo-request-tag-07. Thank you for this document. As a summary, I think the draft is needed, well written, and on the right track. I have a couple of suggestions about structure of the document, up to the authors to take them or leave them. I also have additional questions/open points, which instead need answering and might need clarification text in the document. For some points in the document I have some proposal text to improve readability, based on my understanding. Finally, I have compiled a list of nits and will soon make a PR for it. Move the Terminology section (current section 1.4) as section 1.1 (under Introduction). Current sections 1.1, 1.2, 1.3 are very useful background sections about the problem this document sets out to solve. I do not see why they need to be in this order, for readability I would have: 1.1 as new section 2.1, moving the text in 2. to the current 2.1 (that would become 2.2); 1.2 as new section 3.1, moving the text in 3. to current 3.1 (new 3.2); 1.3 as new section 5.1, old 5. text becoming 5.2. This will require mainly copy-paste and minor introductory text in sections 2, 3, and 5. The goal with this restructuring would be to help keep the 3 parallel topics in focus (Echo options, Request Tag option, Token update), without having to switch from one to the other. Move appendix A to the main body: there is already RECOMMENDED text, it would fit to have that as the last subsection of the Echo section. Section 1.4 " (Concurrent block-wise request operations are impossible with the options of [RFC7959] because the second operation's block overwrites any state of the first exchange.). " I believe this is true, but could you point to the section that states that? I didn't manage to find it while checking. Section 2.1 " When receiving an Echo option in a request, the server MUST be able to verify when the Echo option value was generated. This implies that the server MUST be able to verify that the Echo option value was generated by the server or some other party that the server trusts. " I don't necessarily agree with the "This implies", would just replace with "and". These are two parallel requirements. Section 2.1 : event-based freshness is mentioned, but no example of it is given of how that would work with the echo option, while the time based one is quite clear thanks to the example in Figure 2. Would it be possible to add one for an event based as well? Section 2.2 " The server MAY include the same Echo option value in several different responses and to different clients. " First, I was confused about this: I wondered if "different responses" referred to different response codes or actual responses. I think the answer is both is correct, but here you meant actual responses; this would need more discussion on why re-using the same option value is OK (i.e. highlight this is not a binding of response to next request, it just provides freshness). If that is already done elsewhere, I missed it. Section 2.2 "... the server MUST use the Echo option to verify that the request is fresh enough. " A RECOMMENDED way of specifying "fresh enough" would be good, to help implementers. For time based, it would be enough to point to Figure 2. For event based, I don't know. Section 2.2 " When used to serve freshness requirements (including client aliveness and state synchronizing), CoAP messages containing the Echo option MUST be integrity protected between the intended endpoints, e.g. using DTLS, TLS, or an OSCORE Inner option ([RFC8613]). " Why do the both messages (request and response) need to be integrity protected? Also Inner option is not used for protecting CoAP messages, but options. So I am a bit confused if here you meant option (which is a different discussion) or message. Also the following sentence ("when used to demonstrate...") belongs with the discussion about the option being Inner or Outer (Section 2.1 4th par), rather than here where we are talking about the message. Section 2.3 " the authority of the property " can you explain this terminology? Section 3.2 " They can still be treated as independent messages by the server (e.g. when it sends 2.01/2.04 responses for every block), or initiate a new operation (overwriting kept context) when the later message carries Block1 number 0. " I have a hard time parsing/understanding this paragraph, particularly from "or initiate..." Section 3.2 I am not sure it is said anywhere what the server should do if it supports the Request-Tag option and it receives it in a non-blockwise message... I guess just discard, but it would be good to explicitely state. Also, could this option be used for something else? For example, I am thinking of Observe operations, re-registration... Does not need to be defined here, but if we MANDATE that it can only be used with blockwise, we are practically stopping any other use that might come up... Section 3.3 " Clients MUST NOT recycle a request tag unless the first operation has concluded. " in the case where a client supports but does not use Request-Tag, this implies "concurrent block operations without Request-Tag are not allowed". If that is the case, I would like that to be stated explicitely. (also minor, I'd like to add "that support Request-Tag" after "Clients") Section 3.3 The last sentence gives some requirements about where the Request-Tag option can/musty be used per message. I felt the document was missing on usage requirements (e.g. if it is set, it MUST be set for all requests for a specific operation) Section 3.4.2 " When initializing a new block-wise operation, a client has to look at other active operations: o If any of them is matchable to the new one, and the client neither wants to cancel the old one nor postpone the new one, it can pick a Request-Tag value that is not in use by the other matchable operations for the new operation. o Otherwise, it can start the new operation without setting the Request-Tag option on it. " Does not cover the fact that Request-Tag can be omitted if that is a different from the other matchable operations. ("pick a new value" excludes it) Section 3.4.3 I believe this section is missing something on the lines of: "Proxies that are aware of this specification can modify their implementation to simply forward block operations." Would you agree? Section 6 Missing references/terminology for monotonic and wall clock. Section 6.1 cought a couple of normative text not being normative: "message must be discarded" "approach is recommended" "need to be blacklisted" Any particular reason why? Thanks, Francesca
Sounds good to me. And as you pointed out we don't see use other cases right now, anyway. Thanks for addressing my comments. Francesca On 03/03/2020, 13:26, "Christian Amsüss" wrote: Hello Francesca and group, this is the only remaining open discussion point from that review as far as I can tell, but can be closed now as well: A Request-Tag unaware proxy may legitimately reassemble a previously fragmented request-tagged message, creating a legitimate Request-Tag carrying block-free message, so that's being changed to "and MUST be ignored in those" cases. (As request-tagged requests can happen by proxies, that might rule out some of the uses cases.) Kind regards Christian To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom

using short values when the absent option can not be recycled. The Request-Tag options MAY be present in request messages that carry  <ins> no Block option (for example, because a Request-Tag unaware proxy reassembled them), and MUST be ignored in those. The Request-Tag option MUST NOT be present in response messages. </ins> 3.5.


5. The availability of a secure pseudorandom number generator and truly <del> random seeds are essential for the security of the Echo option.  If no true random number generator is available, a truly random seed must be provided from an external source.  As each pseudoranom number must only be used once, an implementation need to get a new truly random seed after reboot, or continously store state in nonvolatile memory, see (RFC8613, Appendix B.1.1) for issues and solution approaches for writing to nonvolatile memory. </del>  A single active Echo value with 64 (pseudo-)random bits gives the same theoretical security level as a 64-bit MAC (as used in e.g. <del> AES_128_CCM_8).  The Echo option value MUST contain 32 (pseudo-)random bits that are not predictable for any other party than the server, and SHOULD contain 64 (pseudo-)random bits.  A server MAY use different security levels for different uses cases (client aliveness, request freshness, state synchronization, network address reachability, etc.). </del>  The security provided by the Echo and Request-Tag options depends on the security protocol used.  CoAP and HTTP proxies require (D)TLS to that all intermediaries are fully trusted and have not been compromised.  Servers SHOULD use a monotonic clock to generate timestamps and compute round-trip times.  Use of non-monotonic clocks is not secure as the server will accept expired Echo option values if the clock is

Closes: URL The numeric part is trivial, the security implications (the use case for short Echo values has a different threat model than what's previously in seccons) is not.
As previously discussed in private mail: For the OSCORE state recovery use case, putting a new sequence number in the Echo option is good enough, and that can be short.

5. The availability of a secure pseudorandom number generator and truly  <ins> random seeds are essential for the security of the Echo option (except when using counting Echo values).  If no true random number generator is available, a truly random seed must be provided from an external source.  As each pseudoranom number must only be used once, an implementation need to get a new truly random seed after reboot, or continously store state in nonvolatile memory, see (RFC8613, Appendix B.1.1) for issues and solution approaches for writing to nonvolatile memory. </ins> A single active Echo value with 64 (pseudo-)random bits gives the same theoretical security level as a 64-bit MAC (as used in e.g.  <ins> AES_128_CCM_8).  Unless a counting Echo value is used, the Echo option value MUST contain 32 (pseudo-)random bits that are not predictable for any other party than the server, and SHOULD contain 64 (pseudo-)random bits.  A server MAY use different security levels for different uses cases (client aliveness, request freshness, state synchronization, network address reachability, etc.). </ins> The security provided by the Echo and Request-Tag options depends on the security protocol used.  CoAP and HTTP proxies require (D)TLS to that all intermediaries are fully trusted and have not been compromised. <ins> Counting Echo values can only be used to show freshness relative to numbered events, and are the legitimate case for Echo values shorter than four bytes, which are not necessarily secret.  They MUST only be used when the request Echo values are integrity protected. </ins> Servers SHOULD use a monotonic clock to generate timestamps and compute round-trip times.  Use of non-monotonic clocks is not secure as the server will accept expired Echo option values if the clock is


proxy that would forward blocks as plain messages would risk mixing up clients' requests. <del> The Request-Tag option provides a very simple way for a proxy to keep them separate: if it appends a Request-Tag that is particular to the requesting endpoint to all request carrying any Block option, it does not need to keep track of any further block state. </del>  This is particularly useful to proxies that strive for stateless <del> operation as described in I-D.ietf-core-stateless Section 3.1. </del>  3.6.

The previous statement was overreaching, see discussion at URL
Context at URL probable conclusion "stateless proxies can only process Block1 cases trivially, everything else needs further exploration"
Not Our Problem thanks to URL, and put out of scope in URL On 2020-03-06, at 16:55, Christian Amsüss wrote: Actually, I believe this is material for neither. You don’t need ERT to solve this problem, and it is a similar problem even if stateless is not in use, so we should write this up in general. Grüße, Carsten
Hello CoRE, handling blockwise in a stateless fashion is hard, and previous discussion[1] stalled a bit. My current impression is that both echo-request-tag and stateless-proxy expect the other document to say how it's actualy done (and both documents should be released soon), and nobody is quite sure what can be said at all. There is one pretty clear-cut case where "the simple thing" works: Client sends request with Block1 partial data, and the proxy attaches Request-Tag identifying the original client. Even the pure Block2 case is a bit doubtful -- I think that a stateless proxy could just forward safe requests with Block2 in request and/or response as long as there is no Block1 around, but I'm not sure. When Block1+Block2 comes in, it gets tricky, because a) some argument is needed that a Request-Tag makes sense at all with Block2 (it does, as it can be a legitimate leftover from a reassembly, and can't be changed when going from the Block1 to the Block2 phase), and b) the proxy can't statelessly determine whether a late POST with Block2:n message should have a Request-Tag (as it might belong to a POST Block1:m messagee that had one), or not (because it might belong to a POST with no mention of a Block option and thus no Request-Tag) -- at least not without Request-Tagging every message which is clearly excessive. I think that a bit more than the clear-cut case can be salvaged, but honestly am not much driven to make a scenario work for which our best example is a SOAP exchange. So, questions to the group: Which document should the procedure and limitations be described in (I'd suggest stateless, as the Block2 case needs reasoning that's unrelated to Request-Tag), and are there any better ideas than "Sorry, no stateless forwarding" for Block1+Block2 or non-safe Block2? KR Christian [1]: URL To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
It is intended for Block1, but spills into the Block2 phase due to RFC7959 Section 2.7's description of the block-2-phase requests as "similar to the requests in the Block1 phase [without] the Block1 Options and [including] a Block2 request option with non-zero NUM". The Block1 operation may have created state on the server, and the later requests may be only accessible if the block-matching-relevant options of the Block2-phase requests are the same as the earlier ones. From that, I'd assume the use of Request-Tag to be suitable there. How that relates to single-message unsafe requests with blockwise response bodies (eg. empty POSTs) I'm unsure, but a stateless proxy would send a Request-Tag on some of the messages as it can't tell them apart from the above case. KR c To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom

proxy that would forward blocks as plain messages would risk mixing up clients' requests.  <ins> In some cases, for example when forwarding block-wise request operations, appending a Request-Tag value unique to the client can satisfy the requirements on the proxy that come from the presence of a block option. </ins> This is particularly useful to proxies that strive for stateless  <ins> operation as described in I-D.ietf-core-stateless Section 4. The precise classification of cases in which such a Request-Tag option is sufficient is not trivial, especially when both request and response body are fragmented, and out of scope for this document. </ins> 3.6.


requests immediately to have a cached result available when the client's Echoed request arrives. <del> Amplification mitigation should be used when the response would be more than three times the size of the request, considering the complete frame on the wire as it is typically sent across the Internet.  In practice, this allows UDP data of at least 152 Bytes without further checks. </del>  When an Echo response is sent to mitigate amplification, it MUST be sent as a piggybacked or Non-confirmable response,

Closes: URL Not tagging any of you for reviewers because that's a topic that primarily I was active on, but still not merging right away in case you want to chime in.
In the response to URL I promised better wording for the 152 bytes -- but let's see whether anything gets back there first. As Carsten pointed out, this is the derived number from the "three times" part, also accounting for the remainder of the UDP packet. Assuming an attacker wants to maximize the amplification possible by the factor 3, they will send 14 octets Ethernet header 40 octets IP header 8 octets UDP header 4 octets CoAP header 8 octets of token allowsing the server to send Σ 3 = 222 octets. Subtracting everything in the response including the UDP header, that gives 160 octets of UDP data. Given the token is variable length data of up to 8 octets the server implementer can't easily take into account, that leaves 152 octets. (Granted, that last step doesn't follow from the wording, and I'm looing to sharpen that). Having some hard number there (and I'm happy to use better ways to come up with one) is important because for generic server applications, the transports may not be known and the implementer would have to make assumptions; we can't do much more, but at least ours get solid review.
In the course of this, we'll also have to give a citation for the "x 3" (currently URL)
Follow-up note to be factored into the resolution:

requests immediately to have a cached result available when the client's Echoed request arrives.  <ins> Amplification mitigation is a trade-off between giving leverage to an attacker and causing overheads.  An amplification factor of 3 (i.e., don't send more than three times the number of bytes received until the peer's address is confirmed) is considered acceptable for unconstrained applications 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. </ins> When an Echo response is sent to mitigate amplification, it MUST be sent as a piggybacked or Non-confirmable response,


client" is used in this document to denote the client from which a request originates; to distinguish from clients in proxies.  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 (REST) "operation".  An operation fragmented using RFC7959 is called

Closes: URL The text is a mixture of the suggestions of .
From Ines' Genart review: NAME and NAME do you know of established references we could use there to avoid rolling our own definition?
Hi, Googling a bit, I think we might need to define this ourselves. Found some papers and presentations taking about freshness, but they did not define it well. Found a very mathematical definition in some other paper that we do not want to use. I suggest something like this: Freshness is a measure of the time since time since the message was sent. What is considered a fresh message is application dependent. The Echo mechanism specified in this document allow a server to calculate an upper bound for when the message was encrypted. With this bound, the server can either verify that the message is fresh (fresher than some application defined limit) or determine that it cannot be verified that the message is fresh. Cheers, John
Maybe we can slim that down and avoid talking of time too much (because yes it's time even in the event-based case, but a very odd discrete time, so might confuse people): Would that work for you?

client" is used in this document to denote the client from which a request originates; to distinguish from clients in proxies. <ins> 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". </ins> 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 (REST) "operation".  An operation fragmented using RFC7959 is called