draft-ietf-core-echo-request-tag-13.txt		draft-ietf-core-echo-request-tag-14.txt
	CoRE Working Group C. Amsuess		CoRE Working Group C. Amsuess
	Internet-Draft		Internet-Draft
	Updates: 7252 (if approved) J. Mattsson		Updates: 7252 (if approved) J. Mattsson
	Intended status: Standards Track G. Selander		Intended status: Standards Track G. Selander
	Expires: 13 January 2022 Ericsson AB		Expires: 7 April 2022 Ericsson AB
	12 July 2021		4 October 2021
	CoAP: Echo, Request-Tag, and Token Processing		CoAP: Echo, Request-Tag, and Token Processing
	draft-ietf-core-echo-request-tag-13		draft-ietf-core-echo-request-tag-14
	Abstract		Abstract
	This document specifies enhancements to the Constrained Application		This document specifies enhancements to the Constrained Application
	Protocol (CoAP) that mitigate security issues in particular use		Protocol (CoAP) that mitigate security issues in particular use
	cases. The Echo option enables a CoAP server to verify the freshness		cases. The Echo option enables a CoAP server to verify the freshness
	of a request or to force a client to demonstrate reachability at its		of a request or to force a client to demonstrate reachability at its
	claimed network address. The Request-Tag option allows the CoAP		claimed network address. The Request-Tag option allows the CoAP
	server to match block-wise message fragments belonging to the same		server to match block-wise message fragments belonging to the same
	request. This document updates RFC 7252 with respect to the client		request. This document updates RFC 7252 with respect to the client
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 13 January 2022.		This Internet-Draft will expire on 7 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 3, line 6 ¶		skipping to change at page 3, line 6 ¶
	3.2.1. Request-Tag Option Format . . . . . . . . . . . . . . 16		3.2.1. Request-Tag Option Format . . . . . . . . . . . . . . 16
	3.3. Request-Tag Processing by Servers . . . . . . . . . . . . 17		3.3. Request-Tag Processing by Servers . . . . . . . . . . . . 17
	3.4. Setting the Request-Tag . . . . . . . . . . . . . . . . . 18		3.4. Setting the Request-Tag . . . . . . . . . . . . . . . . . 18
	3.5. Applications of the Request-Tag Option . . . . . . . . . 19		3.5. Applications of the Request-Tag Option . . . . . . . . . 19
	3.5.1. Body Integrity Based on Payload Integrity . . . . . . 19		3.5.1. Body Integrity Based on Payload Integrity . . . . . . 19
	3.5.2. Multiple Concurrent Block-wise Operations . . . . . . 20		3.5.2. Multiple Concurrent Block-wise Operations . . . . . . 20
	3.5.3. Simplified Block-Wise Handling for Constrained		3.5.3. Simplified Block-Wise Handling for Constrained
	Proxies . . . . . . . . . . . . . . . . . . . . . . . 21		Proxies . . . . . . . . . . . . . . . . . . . . . . . 21
	3.6. Rationale for the Option Properties . . . . . . . . . . . 21		3.6. Rationale for the Option Properties . . . . . . . . . . . 21
	3.7. Rationale for Introducing the Option . . . . . . . . . . 22		3.7. Rationale for Introducing the Option . . . . . . . . . . 21
	3.8. Block2 / ETag Processing . . . . . . . . . . . . . . . . 22		3.8. Block2 / ETag Processing . . . . . . . . . . . . . . . . 22
	4. Token Processing for Secure Request-Response Binding . . . . 22		4. Token Processing for Secure Request-Response Binding . . . . 22
	4.1. Request-Response Binding . . . . . . . . . . . . . . . . 22		4.1. Request-Response Binding . . . . . . . . . . . . . . . . 22
	4.2. Updated Token Processing Requirements for Clients . . . . 23		4.2. Updated Token Processing Requirements for Clients . . . . 23
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 23		5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	5.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 25		5.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 25
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26		6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
	8.1. Normative References . . . . . . . . . . . . . . . . . . 28		8.1. Normative References . . . . . . . . . . . . . . . . . . 28
	8.2. Informative References . . . . . . . . . . . . . . . . . 28		8.2. Informative References . . . . . . . . . . . . . . . . . 28
	Appendix A. Methods for Generating Echo Option Values . . . . . 30		Appendix A. Methods for Generating Echo Option Values . . . . . 30
	Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 32		Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 32
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 32		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 32
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
	1. Introduction		1. Introduction
	The initial Constrained Application Protocol (CoAP) suite of		The initial Constrained Application Protocol (CoAP) suite of
	specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed		specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed
	with the assumption that security could be provided on a separate		with the assumption that security could be provided on a separate
	layer, in particular by using DTLS ([RFC6347]). However, for some		layer, in particular by using DTLS ([RFC6347]). However, for some
	use cases, additional functionality or extra processing is needed to		use cases, additional functionality or extra processing is needed to
	support secure CoAP operations. This document specifies security		support secure CoAP operations. This document specifies security
	enhancements to the Constrained Application Protocol (CoAP).		enhancements to the Constrained Application Protocol (CoAP).
	skipping to change at page 10, line 16 ¶		skipping to change at page 10, line 16 ¶
	and state synchronizing), the Echo option value MUST be integrity		and state synchronizing), the Echo option value MUST be integrity
	protected between the intended endpoints, e.g. using DTLS, TLS, or an		protected between the intended endpoints, e.g. using DTLS, TLS, or an
	OSCORE Inner option ([RFC8613]). When used to demonstrate		OSCORE Inner option ([RFC8613]). When used to demonstrate
	reachability at a claimed network address, the Echo option SHOULD be		reachability at a claimed network address, the Echo option SHOULD be
	a MAC of the claimed address, but MAY be unprotected. Combining		a MAC of the claimed address, but MAY be unprotected. Combining
	different Echo applications can necessitate different choices, see		different Echo applications can necessitate different choices, see
	Appendix A item 2 for an example.		Appendix A item 2 for an example.
	An Echo option MAY be sent with a successful response, i.e., even		An Echo option MAY be sent with a successful response, i.e., even
	though the request satisfied any freshness requirements on the		though the request satisfied any freshness requirements on the
	operation. This is occasionally called a "preemptive" Echo value,		operation. This is called a "preemptive" Echo value, and useful when
	and useful when the server anticipates that the client will need to		the server anticipates that the client will need to demonstrate
	demonstrate freshness relative to the current response the near		freshness relative to the current response the near future.
	future.
	A CoAP-to-CoAP proxy MAY set an Echo option on responses, both on		A CoAP-to-CoAP proxy MAY set an Echo option on responses, both on
	forwarded ones that had no Echo option or ones generated by the proxy		forwarded ones that had no Echo option or ones generated by the proxy
	(from cache or as an error). If it does so, it MUST remove the Echo		(from cache or as an error). If it does so, it MUST remove the Echo
	option it recognizes as one generated by itself on follow-up		option it recognizes as one generated by itself on follow-up
	requests. When it receives an Echo option in a response, it MAY		requests. When it receives an Echo option in a response, it MAY
	forward it to the client (and, not recognizing it as an own in future		forward it to the client (and, not recognizing it as an own in future
	requests, relay it in the other direction as well) or process it on		requests, relay it in the other direction as well) or process it on
	its own. If it does so, it MUST ensure that the client's request was		its own. If it does so, it MUST ensure that the client's request was
	generated (or is re-generated) after the Echo value used to send to		generated (or is re-generated) after the Echo value used to send to
	skipping to change at page 11, line 44 ¶		skipping to change at page 11, line 44 ¶
	mechanism only provides a partial order on the messages'		mechanism only provides a partial order on the messages'
	processing.		processing.
	* If a server reboots during operation it may need to		* If a server reboots during operation it may need to
	synchronize state or time before continuing the interaction.		synchronize state or time before continuing the interaction.
	For example, with OSCORE it is possible to reuse a partly		For example, with OSCORE it is possible to reuse a partly
	persistently stored security context by synchronizing the		persistently stored security context by synchronizing the
	Partial IV (sequence number) using the Echo option as		Partial IV (sequence number) using the Echo option as
	specified in Section 7.5 of [RFC8613].		specified in Section 7.5 of [RFC8613].
	* A device joining a CoAP group communication [RFC7390]		* A device joining a CoAP group communication
	protected with OSCORE [I-D.ietf-core-oscore-groupcomm] may be		[I-D.ietf-core-groupcomm-bis] protected with OSCORE
	required to initially synchronize its replay window state with		[I-D.ietf-core-oscore-groupcomm] may be required to initially
	a client by using the Echo option in a unicast response to a		synchronize its replay window state with a client by using the
	multicast request. The client receiving the response with the		Echo option in a unicast response to a multicast request. The
	Echo option includes the Echo value in a subsequent unicast		client receiving the response with the Echo option includes
	request to the responding server.		the Echo value in a subsequent unicast request to the
			responding server.
	3. An attacker can perform a denial-of-service attack by putting a		3. An attacker can perform a denial-of-service attack by putting a
	victim's address in the source address of a CoAP request and		victim's address in the source address of a CoAP request and
	sending the request to a resource with a large amplification		sending the request to a resource with a large amplification
	factor. The amplification factor is the ratio between the size		factor. The amplification factor is the ratio between the size
	of the request and the total size of the response(s) to that		of the request and the total size of the response(s) to that
	request. A server that provides a large amplification factor to		request. A server that provides a large amplification factor to
	an unauthenticated peer SHOULD mitigate amplification attacks as		an unauthenticated peer SHOULD mitigate amplification attacks as
	described in Section 11.3 of [RFC7252]. One way to mitigate such		described in Section 11.3 of [RFC7252]. One way to mitigate such
	attacks is that the server responds to the alleged source address		attacks is that the server responds to the alleged source address
	skipping to change at page 13, line 41 ¶		skipping to change at page 13, line 41 ¶
	event whenever an Echo value is used. This makes the Echo value		event whenever an Echo value is used. This makes the Echo value
	effectively single-use.		effectively single-use.
	Event and time based freshness can be combined in a single Echo		Event and time based freshness can be combined in a single Echo
	value, e.g. by encrypting a timestamp with a key that changes with		value, e.g. by encrypting a timestamp with a key that changes with
	every event to obtain "usable once but only for 5 minutes"-style		every event to obtain "usable once but only for 5 minutes"-style
	semantics.		semantics.
	2.5.2. Authority over Used Information		2.5.2. Authority over Used Information
	The information extracted by the server from the request Echo value		Information conveyed to the server in the request Echo value has
	has different sources of truth depending on the application.		different authority depending on the application. Understanding who
	Understanding who or what is the authoritative source of that		or what is the authoritative source of that information helps the
	information helps the server implementer decide the necessary		server implementer decide the necessary protection of the Echo value.
	protection of the Echo value.
	If all that the server extracts is information which the client is		If all that is conveyed to the server is information which the client
	authorized to provide arbitrarily, (which is another way of saying		is authorized to provide arbitrarily, (which is another way of saying
	that the server has to trust the client on whatever Echo is used		that the server has to trust the client on whatever Echo is being
	for), then the server can issue Echo values that do not need to be		used for), then the server can issue Echo values that do not need to
	protected on their own. They still need to be covered by the		be protected on their own. They still need to be covered by the
	security protocol that covers the rest of the message, but the Echo		security protocol that covers the rest of the message, but the Echo
	value can be just short enough to be unique between this server and		value can be just short enough to be unique between this server and
	client.		client.
	For example, the client's OSCORE sender sequence number (as used in		For example, the client's OSCORE sender sequence number (as used in
	[RFC8613] Appendix B.1.2) is such information.		[RFC8613] Appendix B.1.2) is such information.
	In most other cases, there are properties extracted of which the		In most other cases, there is information conveyed for which the
	server is the authority ("The request must not be older than five		server is the authority ("The request must not be older than five
	minutes" is counted on the server's clock, not the client's) or which		minutes" is counted on the server's clock, not the client's) or which
	even involve the network (as when performing amplification		even involve the network (as when performing amplification
	mitigation). In these cases, the Echo value itself needs to be		mitigation). In these cases, the Echo value itself needs to be
	protected against forgery by the client, e.g. by using a sufficiently		protected against forgery by the client, e.g. by using a sufficiently
	large random value or a MAC as described in Appendix A items 1 and 2.		large random value or a MAC as described in Appendix A items 1 and 2.
	For some applications, the server may be able to trust the client to		For some applications, the server may be able to trust the client to
	also act as the authority (e.g. when using time based freshness		also act as the authority (e.g. when using time based freshness
	purely to mitigate request delay attacks); these need careful case-		purely to mitigate request delay attacks); these need careful case-
	skipping to change at page 14, line 46 ¶		skipping to change at page 14, line 46 ¶
	When the client is the sole authority over the synchronized property,		When the client is the sole authority over the synchronized property,
	the server can still use time or events to issue new Echo values.		the server can still use time or events to issue new Echo values.
	Then, the request's Echo value not so much proves the indicated		Then, the request's Echo value not so much proves the indicated
	freshness to the server, but reflects the client's intention to		freshness to the server, but reflects the client's intention to
	indicate reception of responses containing that value when sending		indicate reception of responses containing that value when sending
	the later ones.		the later ones.
	Note that a single Echo value can be used for multiple purposes (e.g.		Note that a single Echo value can be used for multiple purposes (e.g.
	to get both the sequence number information and perform amplification		to get both the sequence number information and perform amplification
	mitigation); then, the stricter requirements apply.		mitigation). In this case the stricter protection requirements
			apply.
	2.5.3. Protection by a Security Protocol		2.5.3. Protection by a Security Protocol
	For meaningful results, the Echo option needs to be used in		For meaningful results, the Echo option needs to be used in
	combination with a security protocol in almost all applications.		combination with a security protocol in almost all applications.
	When the information extracted by the server is only about a part of		When the information extracted by the server is only about a part of
	the system outside of any security protocol, then the Echo option can		the system outside of any security protocol, then the Echo option can
	also be used without a security protocol (in case of OSCORE, as an		also be used without a security protocol (in case of OSCORE, as an
	outer option).		outer option).
	skipping to change at page 19, line 48 ¶		skipping to change at page 19, line 48 ¶
	replayed.		replayed.
	When security services are provided by OSCORE, these confirmations		When security services are provided by OSCORE, these confirmations
	typically result either from the client receiving an OSCORE		typically result either from the client receiving an OSCORE
	response message matching the request (an empty ACK is		response message matching the request (an empty ACK is
	insufficient), or because the message's sequence number is old		insufficient), or because the message's sequence number is old
	enough to be outside the server's receive window.		enough to be outside the server's receive window.
	When security services are provided by DTLS, this can only be		When security services are provided by DTLS, this can only be
	confirmed if there was no CoAP retransmission of the request, the		confirmed if there was no CoAP retransmission of the request, the
	request was responded to, and the server performs replay		request was responded to, and the server uses replay protection.
	protection.
	Authors of other documents (e.g. applications of [RFC8613]) are		Authors of other documents (e.g. applications of [RFC8613]) are
	invited to mandate this subsection's behavior for clients that		invited to mandate this subsection's behavior for clients that
	execute block-wise interactions over secured transports. In this		execute block-wise interactions over secured transports. In this
	way, the server can rely on a conforming client to set the Request-		way, the server can rely on a conforming client to set the Request-
	Tag option when required, and thereby have confidence the integrity		Tag option when required, and thereby have confidence in the
	of the assembled body.		integrity of the assembled body.
	Note that this mechanism is implicitly implemented when the security		Note that this mechanism is implicitly implemented when the security
	layer guarantees ordered delivery (e.g. CoAP over TLS [RFC8323]).		layer guarantees ordered delivery (e.g. CoAP over TLS [RFC8323]).
	This is because with each message, any earlier message cannot be		This is because with each message, any earlier message cannot be
	replayed any more, so the client never needs to set the Request-Tag		replayed any more, so the client never needs to set the Request-Tag
	option unless it wants to perform concurrent operations.		option unless it wants to perform concurrent operations.
	Body integrity only makes sense in applications that have stateful		Body integrity only makes sense in applications that have stateful
	block-wise transfers. On applications where all the state is in the		block-wise transfers. On applications where all the state is in the
	application (e.g. because rather than POSTing a large representation		application (e.g. because rather than POSTing a large representation
	skipping to change at page 28, line 15 ¶		skipping to change at page 28, line 4 ¶
	| Number | Name | Reference |		| Number | Name | Reference |
	+--------+-------------+-------------------+		+--------+-------------+-------------------+
	| TBD252 | Echo | [[this document]] |		| TBD252 | Echo | [[this document]] |
	| | | |		| | | |
	| TBD292 | Request-Tag | [[this document]] |		| TBD292 | Request-Tag | [[this document]] |
	+--------+-------------+-------------------+		+--------+-------------+-------------------+
	Figure 5: CoAP Option Numbers		Figure 5: CoAP Option Numbers
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/rfc/rfc2119>.		<https://doi.org/10.17487/RFC2119>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <https://www.rfc-editor.org/rfc/rfc6347>.		January 2012, <https://doi.org/10.17487/RFC6347>.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,		Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014,		DOI 10.17487/RFC7252, June 2014,
	<https://www.rfc-editor.org/rfc/rfc7252>.		<https://doi.org/10.17487/RFC7252>.
	[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in		[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
	the Constrained Application Protocol (CoAP)", RFC 7959,		the Constrained Application Protocol (CoAP)", RFC 7959,
	DOI 10.17487/RFC7959, August 2016,		DOI 10.17487/RFC7959, August 2016,
	<https://www.rfc-editor.org/rfc/rfc7959>.		<https://doi.org/10.17487/RFC7959>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.		May 2017, <https://doi.org/10.17487/RFC8174>.
	[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early		[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
	Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September		Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
	2018, <https://www.rfc-editor.org/rfc/rfc8470>.		2018, <https://doi.org/10.17487/RFC8470>.
	[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,		[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security for Constrained RESTful Environments		"Object Security for Constrained RESTful Environments
	(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,		(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
	<https://www.rfc-editor.org/rfc/rfc8613>.		<https://doi.org/10.17487/RFC8613>.
	8.2. Informative References		8.2. Informative References
			[I-D.ietf-core-groupcomm-bis]
			Dijk, E., Wang, C., and M. Tiloca, "Group Communication
			for the Constrained Application Protocol (CoAP)", Work in
			Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
			04, 12 July 2021, <https://datatracker.ietf.org/doc/html/
			draft-ietf-core-groupcomm-bis-04>.
	[I-D.ietf-core-oscore-groupcomm]		[I-D.ietf-core-oscore-groupcomm]
	Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,		Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
	and J. Park, "Group OSCORE - Secure Group Communication		and J. Park, "Group OSCORE - Secure Group Communication
	for CoAP", Work in Progress, Internet-Draft, draft-ietf-		for CoAP", Work in Progress, Internet-Draft, draft-ietf-
	core-oscore-groupcomm-12, 12 July 2021,		core-oscore-groupcomm-12, 12 July 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-core-		<https://datatracker.ietf.org/doc/html/draft-ietf-core-
	oscore-groupcomm-12>.		oscore-groupcomm-12>.
	[I-D.irtf-pearg-numeric-ids-generation]		[I-D.irtf-pearg-numeric-ids-generation]
	Gont, F. and I. Arce, "On the Generation of Transient		Gont, F. and I. Arce, "On the Generation of Transient
	Numeric Identifiers", Work in Progress, Internet-Draft,		Numeric Identifiers", Work in Progress, Internet-Draft,
	draft-irtf-pearg-numeric-ids-generation-07, 2 February		draft-irtf-pearg-numeric-ids-generation-07, 2 February
	2021, <https://datatracker.ietf.org/doc/html/draft-irtf-		2021, <https://datatracker.ietf.org/doc/html/draft-irtf-
	pearg-numeric-ids-generation-07>.		pearg-numeric-ids-generation-07>.
	[I-D.mattsson-core-coap-attacks]		[I-D.mattsson-core-coap-attacks]
	Mattsson, J. P., Fornehed, J., Selander, G., Palombini,		Mattsson, J. P., Fornehed, J., Selander, G., Palombini,
	F., and C. Amsüss, "Summarizing Known Attacks on CoAP",		F., and C. Amsüss, "CoAP Attacks", Work in Progress,
	Work in Progress, Internet-Draft, draft-mattsson-core-		Internet-Draft, draft-mattsson-core-coap-attacks-01, 27
	coap-attacks-00, 16 May 2021,		July 2021, <https://datatracker.ietf.org/doc/html/draft-
	<https://datatracker.ietf.org/doc/html/draft-mattsson-		mattsson-core-coap-attacks-01>.
	core-coap-attacks-00>.
	[REST] Fielding, R., "Architectural Styles and the Design of		[REST] Fielding, R., "Architectural Styles and the Design of
	Network-based Software Architectures", 2000,		Network-based Software Architectures", 2000,
	<https://www.ics.uci.edu/~fielding/pubs/dissertation/		<https://www.ics.uci.edu/~fielding/pubs/dissertation/
	fielding_dissertation.pdf>.		fielding_dissertation.pdf>.
	[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
	the Constrained Application Protocol (CoAP)", RFC 7390,
	DOI 10.17487/RFC7390, October 2014,
	<https://www.rfc-editor.org/rfc/rfc7390>.
	[RFC7641] Hartke, K., "Observing Resources in the Constrained		[RFC7641] Hartke, K., "Observing Resources in the Constrained
	Application Protocol (CoAP)", RFC 7641,		Application Protocol (CoAP)", RFC 7641,
	DOI 10.17487/RFC7641, September 2015,		DOI 10.17487/RFC7641, September 2015,
	<https://www.rfc-editor.org/rfc/rfc7641>.		<https://doi.org/10.17487/RFC7641>.
	[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,		[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
	Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained		Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
	Application Protocol) over TCP, TLS, and WebSockets",		Application Protocol) over TCP, TLS, and WebSockets",
	RFC 8323, DOI 10.17487/RFC8323, February 2018,		RFC 8323, DOI 10.17487/RFC8323, February 2018,
	<https://www.rfc-editor.org/rfc/rfc8323>.		<https://doi.org/10.17487/RFC8323>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/rfc/rfc8446>.		<https://doi.org/10.17487/RFC8446>.
	[RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and		[RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and
	Stateless Clients in the Constrained Application Protocol		Stateless Clients in the Constrained Application Protocol
	(CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021,		(CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021,
	<https://www.rfc-editor.org/rfc/rfc8974>.		<https://doi.org/10.17487/RFC8974>.
	[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", RFC 9000,		Multiplexed and Secure Transport", RFC 9000,
	DOI 10.17487/RFC9000, May 2021,		DOI 10.17487/RFC9000, May 2021,
	<https://www.rfc-editor.org/rfc/rfc9000>.		<https://doi.org/10.17487/RFC9000>.
	Appendix A. Methods for Generating Echo Option Values		Appendix A. Methods for Generating Echo Option Values
	The content and structure of the Echo option value are implementation		The content and structure of the Echo option value are implementation
	specific and determined by the server. Two simple mechanisms for		specific and determined by the server. Two simple mechanisms for
	time-based freshness and one for event-based freshness are outlined		time-based freshness and one for event-based freshness are outlined
	in this section, the first is RECOMMENDED in general, and the second		in this section, the first is RECOMMENDED in general, and the second
	is RECOMMENDED in case the Echo option is encrypted between the		is RECOMMENDED in case the Echo option is encrypted between the
	client and the server.		client and the server.
	skipping to change at page 30, line 47 ¶		skipping to change at page 30, line 42 ¶
	security against an attacker guessing echo values is given by s = bit		security against an attacker guessing echo values is given by s = bit
	length of r - log2(n). The length of r and the maximum allowed n		length of r - log2(n). The length of r and the maximum allowed n
	should be set so that the security level is harmonized with other		should be set so that the security level is harmonized with other
	parts of the deployment, e.g., s >= 64. If the server loses time		parts of the deployment, e.g., s >= 64. If the server loses time
	continuity, e.g. due to reboot, the entries in the old list MUST be		continuity, e.g. due to reboot, the entries in the old list MUST be
	deleted.		deleted.
	Echo option value: random value r		Echo option value: random value r
	Server State: random value r, timestamp t0		Server State: random value r, timestamp t0
	This method is suitable both for time and for event base freshness		This method is suitable both for time- and for event-based freshness
	(e.g. by clearing the cache when an event occurs), and independent of		(e.g. by clearing the cache when an event occurs), and independent of
	the client authority.		the client authority.
	2. Integrity Protected Timestamp. The Echo option value is an		2. Integrity Protected Timestamp. The Echo option value is an
	integrity protected timestamp. The timestamp can have different		integrity protected timestamp. The timestamp can have different
	resolution and range. A 32-bit timestamp can e.g. give a resolution		resolution and range. A 32-bit timestamp can e.g. give a resolution
	of 1 second with a range of 136 years. The (pseudo-)random secret		of 1 second with a range of 136 years. The (pseudo-)random secret
	key is generated by the server and not shared with any other party.		key is generated by the server and not shared with any other party.
	The use of truncated HMAC-SHA-256 is RECOMMENDED. With a 32-bit		The use of truncated HMAC-SHA-256 is RECOMMENDED. With a 32-bit
	timestamp and a 64-bit MAC, the size of the Echo option value is 12		timestamp and a 64-bit MAC, the size of the Echo option value is 12
	bytes and the Server state is small and constant. The security		bytes and the Server state is small and constant. The security
	against an attacker guessing echo values is given by the MAC length.		against an attacker guessing echo values is given by the MAC length.
	If the server loses time continuity, e.g. due to reboot, the old key		If the server loses time continuity, e.g. due to reboot, the old key
	MUST be deleted and replaced by a new random secret key. Note that		MUST be deleted and replaced by a new random secret key. Note that
	the privacy considerations in Section 6 may apply to the timestamp.		the privacy considerations in Section 6 may apply to the timestamp.
	Therefore, it might be important to encrypt it. Depending on the		Therefore, it might be important to encrypt it. Depending on the
	choice of encryption algorithms, this may require a nonce to be		choice of encryption algorithms, this may require an initialization
	included in the Echo option value.		vector to be included in the Echo option value, see below.
	Echo option value: timestamp t0, MAC(k, t0)		Echo option value: timestamp t0, MAC(k, t0)
	Server State: secret key k		Server State: secret key k
	This method is suitable both for time and for event based freshness		This method is suitable both for time- and for event-based freshness
	(by the server remembering the time at which the event took place),		(by the server remembering the time at which the event took place),
	and independent of the client authority.		and independent of the client authority.
	If this method is used to additionally obtain network reachability of		If this method is used to additionally obtain network reachability of
	the client, the server MUST use the client's network address too,		the client, the server MUST use the client's network address too,
	e.g. as in "MAC(k, t0, apparent network address)".		e.g. as in MAC(k, t0, apparent network address).
	3. Persistent Counter. This can be used in OSCORE for sequence		3. Persistent Counter. This can be used in OSCORE for sequence
	number recovery per Appendix B.1.2 of [RFC8613]. The Echo option		number recovery per Appendix B.1.2 of [RFC8613]. The Echo option
	value is a simple counter without integrity protection of its own,		value is a simple counter without integrity protection of its own,
	serialized in uint format. The counter is incremented in a		serialized in uint format. The counter is incremented in a
	persistent way every time the state that needs to be synchronized is		persistent way every time the state that needs to be synchronized is
	changed (in the B.1.2 case: when a reboot indicates that volatile		changed (in the B.1.2 case: when a reboot indicates that volatile
	state may have been lost). An example of how such a persistent		state may have been lost). An example of how such a persistent
	counter can be implemented efficiently is the OSCORE server Sender		counter can be implemented efficiently is the OSCORE server Sender
	Sequence Number mechanism described in Appendix B.1.1 of [RFC8613].		Sequence Number mechanism described in Appendix B.1.1 of [RFC8613].
	skipping to change at page 31, line 52 ¶		skipping to change at page 31, line 44 ¶
	Echo option value: counter		Echo option value: counter
	Server State: counter		Server State: counter
	This method is suitable only if the client is the authority over the		This method is suitable only if the client is the authority over the
	synchronized property. Consequently, it cannot be used to show		synchronized property. Consequently, it cannot be used to show
	client aliveness. It provides statements from the client similar to		client aliveness. It provides statements from the client similar to
	event based freshness (but without a proof of freshness).		event based freshness (but without a proof of freshness).
	Other mechanisms complying with the security and privacy		Other mechanisms complying with the security and privacy
	considerations may be used. The use of encrypted timestamps in the		considerations may be used. The use of encrypted timestamps in the
	Echo option increases security, but typically requires an IV		Echo option provides additional protection, but typically requires an
	(Initialization Vector) to be included in the Echo option value,		initialization vector (a.k.a. nonce) as input to the encryption
	which adds overhead and makes the specification of such a mechanism		algorithm, which adds a slight complication to the procedure as well
	slightly more complicated than what is described here.		as overhead.
	Appendix B. Request-Tag Message Size Impact		Appendix B. Request-Tag Message Size Impact
	In absence of concurrent operations, the Request-Tag mechanism for		In absence of concurrent operations, the Request-Tag mechanism for
	body integrity (Section 3.5.1) incurs no overhead if no messages are		body integrity (Section 3.5.1) incurs no overhead if no messages are
	lost (more precisely: in OSCORE, if no operations are aborted due to		lost (more precisely: in OSCORE, if no operations are aborted due to
	repeated transmission failure; in DTLS, if no packets are lost and		repeated transmission failure; in DTLS, if no packets are lost and
	replay protection is active), or when block-wise request operations		replay protection is active), or when block-wise request operations
	happen rarely (in OSCORE, if there is always only one request block-		happen rarely (in OSCORE, if there is always only one request block-
	wise operation in the replay window).		wise operation in the replay window).
	skipping to change at page 32, line 42 ¶		skipping to change at page 32, line 39 ¶
	* In OSCORE, the sequence number can be artificially increased so		* In OSCORE, the sequence number can be artificially increased so
	that all lost messages are outside of the replay window by the		that all lost messages are outside of the replay window by the
	time the first request of the new operation gets processed, and		time the first request of the new operation gets processed, and
	all earlier operations can therefore be regarded as concluded.		all earlier operations can therefore be regarded as concluded.
	Appendix C. Change Log		Appendix C. Change Log
	[ The editor is asked to remove this section before publication. ]		[ The editor is asked to remove this section before publication. ]
			* Changes since draft-ietf-core-echo-request-tag-13
			- Minor editorial fixes.
			- Wording enhancements:
			o nonce -> initialization vector
			o information extracted by the sever -> information conveyed
			to the server
			- Acknowledgements updated.
			- Changelog for -13 added (previous upload just pointed to other
			resources).
			- Short title is "Echo, Request-Tag, and Token Processing" now
			instead of outdated acronym.
			- Informative reference to RFC 7390 is now to draft-ietf-core-
			groupcomm-bis
	* Changes since draft-ietf-core-echo-request-tag-12 (addressing		* Changes since draft-ietf-core-echo-request-tag-12 (addressing
	comments from IESG review)		comments from IESG review)
	See CoRE point-to-point responses at https://github.com/core-wg/		See CoRE point-to-point responses at https://github.com/core-wg/
	echo-request-tag/blob/master/point-to-point.md		echo-request-tag/blob/master/point-to-point.md
	(https://github.com/core-wg/echo-request-tag/blob/master/point-to-		(https://github.com/core-wg/echo-request-tag/blob/master/point-to-
	point.md) and on CoRE mailing list.		point.md) and on CoRE mailing list.
			- Add subsection "Characterization of Echo Applications".
			o Changes in applications and appendices to use the newly
			introduced terms.
			o In particular, some of the legitimization for using short
			Echo values was drawn from the applications being event
			based; the concept of the client being the "Authority over
			[the] Used Information" now legitimizes these more
			precisely.
			- Add subsection "Updated Amplification Mitigation Requirements
			for Servers". It contains the normative text updating RFC 7252
			w/rt recommended mitigation methods, which previously happened
			in passing.
			- Amplification mitigation:
			o Increase precision: Reachability check is performed once per
			endpoint (was: peer).
			o State that amplification factor applies to the sum of all
			(previously: "the size of the", implicitly, single) returned
			packets.
			o Fix odd wording around how the Echo value would "contain"
			the claimed address: was meant to contain in a cryptographic
			sense, now clarified in that a MAC is recommended
			- Define "preemptive Echo value" that was previously used without
			definition; another occurrence of the concept was simplified
			using the term.
			- Add considerations for the use of DTLS without replay
			protection.
			- Privacy considerations: Address concerns raised in various
			numeric-ids documents.
			- Explicitly state expected security modes for Echo applications
			and examples.
			- Fix of requirements for H-C proxies: They _MUST NOT_ relay
			unsafe requests. (Previously, it only said that they SHOULD
			use a particular method, but not clearly that some method is
			mandated.)
			- Clarify that state synchonization is an application of the
			freshness results in combination with some transported
			application data, and not an immediate result of using Echo
			alone.
			- Add text to tie together applications and suggested mechanisms
			- Restrict C-C proxy allowed behavior: Only safe requests
			(incorrectly said "idempotent") may be used to proactively
			populate the proxy's cache.
			- Justify some "SHOULD"s by outlining justification for different
			behavior.
			o Normatively require H-C proxies to process Echo if they're
			justified to do so, as no alternatives are available.
			- Reference updates:
			o QUIC is now RFC9000; precise section given as amplification
			reference.
			o Add note for RFC editor that RFC6347 can be upgraded to DTLS
			1.3 if C321 overtakes C280
			o Follow the core-coap-actuators to core-coap-attacks update
			o RFC8470 reference is now normative (as using what's defined
			there has been RECOMMENDED already)
			- Editorial fixes
			o Rewording of confusing sentences in amplification mitigation
			and inner-/outer Echo values
			o Replace "blacklist" terminology with "deny-list" where left
			after other changes
			o Removed sloppy use of Echo as a verb
			o Minor clarifications
			o Remove duplicate statements
			o Typography and spelling fixes
			- Fixes that are not editorial but minor
			o Freshness is about time, of which round-trip time
			(specialization now removed) is only a part.
			o Reference how HTTP _1.1_ does it when explaining token
			requirements, as that's an easily and widely understood
			baseline.
	* Changes since draft-ietf-core-echo-request-tag-11 (addressing		* Changes since draft-ietf-core-echo-request-tag-11 (addressing
	GenART, TSVART, OpsDir comments)		GenART, TSVART, OpsDir comments)
	- Explain the size permissible for responses before amplification		- Explain the size permissible for responses before amplification
	mitigation by referring to the QUIC draft for an OK factor, and		mitigation by referring to the QUIC draft for an OK factor, and
	giving the remaining numbers that led to it. The actual number		giving the remaining numbers that led to it. The actual number
	is reduced from 152 to 136 because the more conservative case		is reduced from 152 to 136 because the more conservative case
	of the attacker not sending a token is considered now.		of the attacker not sending a token is considered now.
	- Added a definition for "freshness"		- Added a definition for "freshness"
	- Give more concrete example values in figures 2 and 3 (based on		- Give more concrete example values in figures 2 and 3 (based on
	the appendix suggestions), highlighting the differences between		the appendix suggestions), highlighting the differences between
	skipping to change at page 38, line 27 ¶		skipping to change at page 41, line 7 ¶
	- The interaction between the new option and (cross) proxies is		- The interaction between the new option and (cross) proxies is
	now covered.		now covered.
	- Two messages being "Request-Tag matchable" was introduced to		- Two messages being "Request-Tag matchable" was introduced to
	replace the older concept of having a request tag value with		replace the older concept of having a request tag value with
	its slightly awkward equivalence definition.		its slightly awkward equivalence definition.
	Acknowledgments		Acknowledgments
	The authors want to thank Carsten Bormann, Francesca Palombini, and		The authors want to thank Carsten Bormann, Roman Danyliw, Benjamin
	Jim Schaad for providing valuable input to the draft.		Kaduk, Murray Kucherawy, Francesca Palombini and Jim Schaad for
			providing valuable input to the draft.
	Authors' Addresses		Authors' Addresses
	Christian Amsüss		Christian Amsüss
	Email: christian@amsuess.com		Email: christian@amsuess.com
	John Preuß Mattsson		John Preuß Mattsson
	Ericsson AB		Ericsson AB
End of changes. 39 change blocks.
	69 lines changed or deleted		194 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/