rfc9175v5.txt		rfc9175.txt
	Internet Engineering Task Force (IETF) C. Amsüss		Internet Engineering Task Force (IETF) C. Amsüss
	Request for Comments: 9175		Request for Comments: 9175
	Updates: 7252 J. Preuß Mattsson		Updates: 7252 J. Preuß Mattsson
	Category: Standards Track G. Selander		Category: Standards Track G. Selander
	ISSN: 2070-1721 Ericsson AB		ISSN: 2070-1721 Ericsson AB
	January 2022		February 2022
	Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token		Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token
	Processing		Processing
	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
	skipping to change at line 693 ¶		skipping to change at line 693 ¶
	does not support the detection of interchanged blocks between		does not support the detection of interchanged blocks between
	different message bodies to the same resource having the same block		different message bodies to the same resource having the same block
	number. This remains true even when CoAP is used together with a		number. This remains true even when CoAP is used together with a
	security protocol (such as DTLS or OSCORE) within the replay window		security protocol (such as DTLS or OSCORE) within the replay window
	[COAP-ATTACKS], which is a vulnerability of the block-wise		[COAP-ATTACKS], which is a vulnerability of the block-wise
	functionality of CoAP [RFC7959].		functionality of CoAP [RFC7959].
	A straightforward mitigation of mixing up blocks from different		A straightforward mitigation of mixing up blocks from different
	messages is to use unique identifiers for different message bodies,		messages is to use unique identifiers for different message bodies,
	which would provide equivalent protection to the case where the		which would provide equivalent protection to the case where the
	complete body fits into a single payload. The ETag Option [RFC7252],		complete body fits into a single payload. The ETag option [RFC7252],
	set by the CoAP server, identifies a response body fragmented using		set by the CoAP server, identifies a response body fragmented using
	the Block2 option.		the Block2 option.
	3.2. The Request-Tag Option		3.2. The Request-Tag Option
	This document defines the Request-Tag option for identifying request		This document defines the Request-Tag option for identifying request
	bodies, similar to ETag, but ephemeral and set by the CoAP client.		bodies, similar to ETag, but ephemeral and set by the CoAP client.
	The Request-Tag is intended for use as a short-lived identifier for		The Request-Tag is intended for use as a short-lived identifier for
	keeping apart distinct block-wise request operations on one resource		keeping apart distinct block-wise request operations on one resource
	from one client, addressing the issue described in Section 3.1. It		from one client, addressing the issue described in Section 3.1. It
	skipping to change at line 991 ¶		skipping to change at line 991 ¶
	depend on an attacker; a client can construct a wrong representation		depend on an attacker; a client can construct a wrong representation
	by assembling it from blocks from different resource states. That		by assembling it from blocks from different resource states. That
	can happen when a resource is modified during a transfer or when some		can happen when a resource is modified during a transfer or when some
	blocks are still valid in the client's cache.		blocks are still valid in the client's cache.
	Rules stating that response body reassembly is conditional on		Rules stating that response body reassembly is conditional on
	matching ETag values are already in place from Section 2.4 of		matching ETag values are already in place from Section 2.4 of
	[RFC7959].		[RFC7959].
	To gain protection equivalent to that described in Section 3.5.1, a		To gain protection equivalent to that described in Section 3.5.1, a
	server MUST use the Block2 option in conjunction with the ETag Option		server MUST use the Block2 option in conjunction with the ETag option
	([RFC7252], Section 5.10.6) and MUST NOT use the same ETag value for		([RFC7252], Section 5.10.6) and MUST NOT use the same ETag value for
	different representations of a resource.		different representations of a resource.
	4. Token Processing for Secure Request-Response Binding		4. Token Processing for Secure Request-Response Binding
	4.1. Request-Response Binding		4.1. Request-Response Binding
	A fundamental requirement of secure REST operations is that the		A fundamental requirement of secure REST operations is that the
	client can bind a response to a particular request. If this is not		client can bind a response to a particular request. If this is not
	ensured, a client may erroneously associate the wrong response to a		ensured, a client may erroneously associate the wrong response to a
	skipping to change at line 1273 ¶		skipping to change at line 1273 ¶
	[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,		[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security for Constrained RESTful Environments		"Object Security for Constrained RESTful Environments
	(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,		(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
	<https://www.rfc-editor.org/info/rfc8613>.		<https://www.rfc-editor.org/info/rfc8613>.
	8.2. Informative References		8.2. Informative References
	[COAP-ATTACKS]		[COAP-ATTACKS]
	Preuß Mattsson, J., Fornehed, J., Selander, G., Palombini,		Preuß Mattsson, J., Fornehed, J., Selander, G., Palombini,
	F., and C. Amsüss, "CoAP Attacks", Work in Progress,		F., and C. Amsüss, "Attacks on the Constrained Application
	Internet-Draft, draft-mattsson-core-coap-attacks-01, 27		Protocol (CoAP)", Work in Progress, Internet-Draft, draft-
	July 2021, <https://datatracker.ietf.org/doc/html/draft-		mattsson-core-coap-attacks-01, 27 July 2021,
	mattsson-core-coap-attacks-01>.		<https://datatracker.ietf.org/doc/html/draft-mattsson-
			core-coap-attacks-01>.
	[GROUP-COAP]		[GROUP-COAP]
	Dijk, E., Wang, C., and M. Tiloca, "Group Communication		Dijk, E., Wang, C., and M. Tiloca, "Group Communication
	for the Constrained Application Protocol (CoAP)", Work in		for the Constrained Application Protocol (CoAP)", Work in
	Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-		Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
	05, 25 October 2021,		05, 25 October 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-core-		<https://datatracker.ietf.org/doc/html/draft-ietf-core-
	groupcomm-bis-05>.		groupcomm-bis-05>.
	[GROUP-OSCORE]		[GROUP-OSCORE]
	skipping to change at line 1398 ¶		skipping to change at line 1399 ¶
	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 for both time-based and event-based		This method is suitable for both time-based and event-based
	freshness (by the server remembering the time at which the event		freshness (by the server remembering the time at which the event
	took place) and independent of the client authority.		took place) and independent of the client authority.
	If this method is used to additionally obtain network		If this method is used to additionally obtain network
	reachability of the client, the server MUST use the client's		reachability of the client, the server MUST use the client's
	network address too, e.g., as in MAC(k, t0, apparent network		network address too, e.g., as in MAC(k, t0, claimed network
	address).		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		number recovery, per Appendix B.1.2 of [RFC8613]. The Echo
	option value is a simple counter without integrity protection of		option value is a simple counter without integrity protection of
	its own, serialized in uint format. The counter is incremented		its own, serialized in uint format. The counter is incremented
	in a persistent way every time the state that needs to be		in a persistent way every time the state that needs to be
	synchronized is changed (in the case described in Appendix B.1.2		synchronized is changed (in the case described in Appendix B.1.2
	of [RFC8613], when a reboot indicates that volatile state may		of [RFC8613], when a reboot indicates that volatile state may
	have been lost). An example of how such a persistent counter can		have been lost). An example of how such a persistent counter can
End of changes. 5 change blocks.
	8 lines changed or deleted		9 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/