draft-ietf-core-echo-request-tag-04.txt		draft-ietf-core-echo-request-tag-05.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: September 25, 2019 Ericsson AB		Expires: November 7, 2019 Ericsson AB
	March 24, 2019		May 06, 2019
	CoAP: Echo, Request-Tag, and Token Processing		CoAP: Echo, Request-Tag, and Token Processing
	draft-ietf-core-echo-request-tag-04		draft-ietf-core-echo-request-tag-05
	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 updated Token processing requirements for clients		request. The updated Token processing requirements for clients
	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 September 25, 2019.		This Internet-Draft will expire on November 7, 2019.
	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 41 ¶		skipping to change at page 2, line 41 ¶
	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
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.1. Normative References . . . . . . . . . . . . . . . . . . 19		9.1. Normative References . . . . . . . . . . . . . . . . . . 19
	9.2. Informative References . . . . . . . . . . . . . . . . . 19		9.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. Methods for Generating Echo Option Values . . . . . 20		Appendix A. Methods for Generating Echo Option Values . . . . . 21
	Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 22		Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 22
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 22		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 22
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	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
	skipping to change at page 5, line 29 ¶		skipping to change at page 5, line 29 ¶
	value and does not give stricter guidelines than that the tokens		value and does not give stricter guidelines than that the tokens
	currently "in use" SHOULD (not SHALL) be unique. If used with a		currently "in use" SHOULD (not SHALL) be unique. If used with a
	security protocol not providing bindings between requests and		security protocol not providing bindings between requests and
	responses (e.g. DTLS and TLS) token reuse may result in situations		responses (e.g. DTLS and TLS) token reuse may result in situations
	where a client matches a response to the wrong request. Note that		where a client matches a response to the wrong request. Note that
	mismatches can also happen for other reasons than a malicious		mismatches can also happen for other reasons than a malicious
	attacker, e.g. delayed delivery or a server sending notifications to		attacker, e.g. delayed delivery or a server sending notifications to
	an uninterested client.		an uninterested client.
	A straightforward mitigation is to mandate clients to not reuse		A straightforward mitigation is to mandate clients to not reuse
	tokens until the traffic keys have been replaced. The easiest way to		tokens until the traffic keys have been replaced. One easy way to
	accomplish this is to implement the token as a counter starting at		accomplish this is to implement the token as a counter starting at
	zero for each new or rekeyed secure connection. This document		zero for each new or rekeyed secure connection. This document
	updates the Token processing in [RFC7252] to always assure a		updates the Token processing in [RFC7252] to always assure a
	cryptographically secure binding of responses to requests for secure		cryptographically secure binding of responses to requests for secure
	REST operations like "coaps".		REST operations like "coaps".
	1.4. Terminology		1.4. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	skipping to change at page 17, line 33 ¶		skipping to change at page 17, line 33 ¶
	As described in Section 1.3, the client must be able to verify that a		As described in Section 1.3, the client must be able to verify that a
	response corresponds to a particular request. This section updates		response corresponds to a particular request. This section updates
	the CoAP Token processing requirements for clients. The Token		the CoAP Token processing requirements for clients. The Token
	processing for servers is not updated. Token processing in		processing for servers is not updated. Token processing in
	Section 5.3.1 of [RFC7252] is updated by adding the following text:		Section 5.3.1 of [RFC7252] is updated by adding the following text:
	When CoAP is used with a security protocol not providing bindings		When CoAP is used with a security protocol not providing bindings
	between requests and responses, the tokens have cryptographic		between requests and responses, the tokens have cryptographic
	importance. The client MUST make sure that tokens are not used in a		importance. The client MUST make sure that tokens are not used in a
	way so that responses risk being associated with the wrong request.		way so that responses risk being associated with the wrong request.
	The easiest way to accomplish this is to implement the Token (or part		One easy way to accomplish this is to implement the Token (or part of
	of the Token) as a sequence number starting at zero for each new or		the Token) as a sequence number starting at zero for each new or
	rekeyed secure connection, this approach SHOULD be followed. To		rekeyed secure connection, this approach SHOULD be followed.
	avoid collisions the sequence number can be encoded with a fixed
	length or with some length-value encoding.
	6. Security Considerations		6. Security Considerations
	The availability of a secure pseudorandom number generator and truly		The availability of a secure pseudorandom number generator and truly
	random seeds are essential for the security of the Echo option. If		random seeds are essential for the security of the Echo option. If
	no true random number generator is available, a truly random seed		no true random number generator is available, a truly random seed
	must be provided from an external source.		must be provided from an external source.
	A single active Echo value with 64 (pseudo-)random bits gives the		A single active Echo value with 64 (pseudo-)random bits gives the
	same theoretical security level against forgeries as a 64-bit MAC (as		same theoretical security level against forgeries as a 64-bit MAC (as
	skipping to change at page 18, line 42 ¶		skipping to change at page 18, line 41 ¶
	Servers MAY reset the timer at certain times and MAY generate a		Servers MAY reset the timer at certain times and MAY generate a
	random offset applied to all timestamps. When resetting the timer,		random offset applied to all timestamps. When resetting the timer,
	the server MUST reject all Echo values that was created before the		the server MUST reject all Echo values that was created before the
	reset.		reset.
	Servers that use the List of Cached Random Values and Timestamps		Servers that use the List of Cached Random Values and Timestamps
	method described in Appendix A may be vulnerable to resource		method described in Appendix A may be vulnerable to resource
	exhaustion attacks. One way to minimize state is to use the		exhaustion attacks. One way to minimize state is to use the
	Integrity Protected Timestamp method described in Appendix A.		Integrity Protected Timestamp method described in Appendix A.
			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).
	7. Privacy Considerations		7. Privacy Considerations
	Implementations SHOULD NOT put any privacy sensitive information in		Implementations SHOULD NOT put any privacy sensitive information in
	the Echo or Request-Tag option values. Unencrypted timestamps MAY		the Echo or Request-Tag option values. Unencrypted timestamps MAY
	reveal information about the server such as location or time since		reveal information about the server such as location or time since
	reboot. The use of wall clock time is not allowed (see Section 6)		reboot. The use of wall clock time is not allowed (see Section 6)
	and there also privacy reasons, e.g. it may reveal that the server		and there also privacy reasons, e.g. it may reveal that the server
	will accept expired certificates. Timestamps MAY be used if Echo is		will accept expired certificates. Timestamps MAY be used if Echo is
	encrypted between the client and the server, e.g. in the case of DTLS		encrypted between the client and the server, e.g. in the case of DTLS
	without proxies or when using OSCORE with an Inner Echo option.		without proxies or when using OSCORE with an Inner Echo option.
	skipping to change at page 22, line 40 ¶		skipping to change at page 22, line 45 ¶
	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-04:
			* Editorial fixes
			+ Moved paragraph on collision-free encoding of data in the
			token to Security Considerations and rephrased it
			+ "easiest" -> "one easy"
	o Changes since draft-ietf-core-echo-request-tag-03:		o Changes since draft-ietf-core-echo-request-tag-03:
	* Mention token processing changes in title		* Mention token processing changes in title
	* Abstract reworded		* Abstract reworded
	* Clarify updates to token processing		* Clarify updates to token processing
	* Describe security levels from Echo length		* Describe security levels from Echo length
End of changes. 8 change blocks.
	11 lines changed or deleted		23 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/