draft-ietf-core-echo-request-tag-06.txt		draft-ietf-core-echo-request-tag-07.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: March 21, 2020 Ericsson AB		Expires: March 22, 2020 Ericsson AB
	September 18, 2019		September 19, 2019
	CoAP: Echo, Request-Tag, and Token Processing		CoAP: Echo, Request-Tag, and Token Processing
	draft-ietf-core-echo-request-tag-06		draft-ietf-core-echo-request-tag-07
	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. The update to the client Token processing requirements of		request. The update to the client Token processing requirements of
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 March 21, 2020.		This Internet-Draft will expire on March 22, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 37 ¶		skipping to change at page 2, line 37 ¶
	3.4.1. Body Integrity Based on Payload Integrity . . . . . . 14		3.4.1. Body Integrity Based on Payload Integrity . . . . . . 14
	3.4.2. Multiple Concurrent Block-wise Operations . . . . . . 15		3.4.2. Multiple Concurrent Block-wise Operations . . . . . . 15
	3.4.3. Simplified Block-Wise Handling for Constrained		3.4.3. Simplified Block-Wise Handling for Constrained
	Proxies . . . . . . . . . . . . . . . . . . . . . . . 16		Proxies . . . . . . . . . . . . . . . . . . . . . . . 16
	3.5. Rationale for the Option Properties . . . . . . . . . . . 16		3.5. Rationale for the Option Properties . . . . . . . . . . . 16
	3.6. Rationale for Introducing the Option . . . . . . . . . . 16		3.6. Rationale for Introducing the Option . . . . . . . . . . 16
	4. Block2 / ETag Processing . . . . . . . . . . . . . . . . . . 17		4. Block2 / ETag Processing . . . . . . . . . . . . . . . . . . 17
	5. Token Processing . . . . . . . . . . . . . . . . . . . . . . 17		5. Token Processing . . . . . . . . . . . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17		6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	6.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 18		6.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 18
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	9.1. Normative References . . . . . . . . . . . . . . . . . . 20		9.1. Normative References . . . . . . . . . . . . . . . . . . 20
	9.2. Informative References . . . . . . . . . . . . . . . . . 21		9.2. Informative References . . . . . . . . . . . . . . . . . 21
	Appendix A. Methods for Generating Echo Option Values . . . . . 22		Appendix A. Methods for Generating Echo Option Values . . . . . 22
	Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 23		Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 23
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 24		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 24
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	skipping to change at page 19, line 32 ¶		skipping to change at page 19, line 32 ¶
	In some setups, Tokens can be reused without the above constraints,		In some setups, Tokens can be reused without the above constraints,
	as a different component in the setup provides the associations:		as a different component in the setup provides the associations:
	o In CoAP over TLS, retransmissions are not handled by the CoAP		o In CoAP over TLS, retransmissions are not handled by the CoAP
	layer and the replay window size is always exactly 1. When a		layer and the replay window size is always exactly 1. When a
	client is sending TLS protected requests without Observe to a		client is sending TLS protected requests without Observe to a
	single server, the client can reuse a Token as soon as the		single server, the client can reuse a Token as soon as the
	previous response with that Token has been received.		previous response with that Token has been received.
	o Requests whose responses are cryptographically bound to the		o Requests whose responses are cryptographically bound to the
	requests (like in OSCORE) can reuse Tokens indefinitely. <!-		requests (like in OSCORE) can reuse Tokens indefinitely.
	could be added but is probably not worth the lines of text
	o Requests whose responses reflect all the data in the request that
	is varied ofer reuses of the same token (for example, if a token
	is always used on a single path with the single query parameter
	"?t=X" for various values of X, then the response needs to contain
	X in a unique position) can share a token, provided the
	application does not rely on the freshness of the responses, or
	sends different requests all the time. ->
	In all other cases, a sequence number approach is recommended as per		In all other cases, a sequence number approach is recommended as per
	Section 5.		Section 5.
	Tokens that cannot be reused need to be blacklisted. This could be		Tokens that cannot be reused need to be blacklisted. This could be
	solved by increasing the Token as soon as the currently used Token		solved by increasing the Token as soon as the currently used Token
	cannot be reused, or by keeping a list of all blacklisted Tokens.		cannot be reused, or by keeping a list of all blacklisted Tokens.
	When the Token (or part of the Token) contains a sequence number, the		When the Token (or part of the Token) contains a sequence number, the
	encoding of the sequence number has to be chosen in a way to avoid		encoding of the sequence number has to be chosen in a way to avoid
	skipping to change at page 24, line 20 ¶		skipping to change at page 24, line 9 ¶
	o In OSCORE, the sequence number can be artificially increased so		o In OSCORE, the sequence number can be artificially increased so
	that all lost messages are outside of the replay window by the		that all lost messages are outside of the replay window by the
	time the first request of the new operation gets processed, and		time the first request of the new operation gets processed, and
	all earlier operations can therefore be regarded as concluded.		all earlier operations can therefore be regarded as concluded.
	Appendix C. Change Log		Appendix C. Change Log
	[ The editor is asked to remove this section before publication. ]		[ The editor is asked to remove this section before publication. ]
			o Changes since draft-ietf-core-echo-request-tag-06:
			* Removed visible comment that should not be visible in Token
			reuse considerations.
	o Changes since draft-ietf-core-echo-request-tag-05:		o Changes since draft-ietf-core-echo-request-tag-05:
	* Add privacy considerations on cookie-style use of Echo values		* Add privacy considerations on cookie-style use of Echo values
	* Add security considerations for token reuse		* Add security considerations for token reuse
	* Add note in security considerations on use of nonvolatile		* Add note in security considerations on use of nonvolatile
	memory when dealing with pseudorandom numbers		memory when dealing with pseudorandom numbers
	* Appendix on echo generation: add a few words on up- and		* Appendix on echo generation: add a few words on up- and
End of changes. 6 change blocks.
	15 lines changed or deleted		11 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/