< draft-ietf-ntp-data-minimization-02.txt		draft-ietf-ntp-data-minimization-03.txt >
	Network Working Group D. Franke		Network Working Group D. Franke
	Internet-Draft Akamai		Internet-Draft Akamai
	Updates: 5905 (if approved) A. Malhotra		Updates: 5905 (if approved) A. Malhotra
	Intended status: Standards Track Boston University		Intended status: Standards Track Boston University
	Expires: January 1, 2019 June 30, 2018		Expires: March 6, 2019 September 2, 2018
	NTP Client Data Minimization		NTP Client Data Minimization
	draft-ietf-ntp-data-minimization-02		draft-ietf-ntp-data-minimization-03
	Abstract		Abstract
	This memo proposes backward-compatible updates to the Network Time		This memo proposes backward-compatible updates to the Network Time
	Protocol to strip unnecessary identifying information from client		Protocol to strip unnecessary identifying information from client
	requests and to improve resilience against blind spoofing of		requests and to improve resilience against blind spoofing of
	unauthenticated server responses.		unauthenticated server responses.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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 January 1, 2019.		This Internet-Draft will expire on March 6, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 3, line 13 ¶		skipping to change at page 3, line 13 ¶
	implementation:		implementation:
	The first octet, which contains the leap indicator, version		The first octet, which contains the leap indicator, version
	number, and mode fields, SHOULD be set to 0x23 (LI = 0, VN = 4,		number, and mode fields, SHOULD be set to 0x23 (LI = 0, VN = 4,
	Mode = 3).		Mode = 3).
	The Transmit Timestamp field SHOULD be set uniformly at random,		The Transmit Timestamp field SHOULD be set uniformly at random,
	generated by a mechanism suitable for cryptographic purposes.		generated by a mechanism suitable for cryptographic purposes.
	[RFC4086] provides guidance on the generation of random values.		[RFC4086] provides guidance on the generation of random values.
	The Poll field MAY be set to the actual polling interval as		The Poll field SHOULD be set to either the actual polling interval
	specified by RFC 5905, or else MAY be set to zero.		as specified by RFC 5905 or zero.
	The Precision field SHOULD be set to 0x20.		The Precision field SHOULD be set to 0x20.
	All other header fields, specifically the Stratum, Root Delay,		All other header fields, specifically the Stratum, Root Delay,
	Root Dispersion, Reference ID, Reference Timestamp, Origin		Root Dispersion, Reference ID, Reference Timestamp, Origin
	Timestamp, and Receive Timestamp, SHOULD be set to zero.		Timestamp, and Receive Timestamp, SHOULD be set to zero.
	Servers MUST allow client packets to conform to the above		Servers MUST allow client packets to conform to the above
	recommendations. This requirement shall not be construed so as to		recommendations. This requirement shall not be construed so as to
	prohibit servers from rejecting conforming packets for unrelated		prohibit servers from rejecting conforming packets for unrelated
	skipping to change at page 4, line 10 ¶		skipping to change at page 4, line 10 ¶
	as not to preclude future development of schemes wherein the server		as not to preclude future development of schemes wherein the server
	uses information about the client's current poll interval in order to		uses information about the client's current poll interval in order to
	recommend adjustments back to the client. Putting accurate		recommend adjustments back to the client. Putting accurate
	information into this field has no significant impact on privacy		information into this field has no significant impact on privacy
	since an observer can already obtain this information simply by		since an observer can already obtain this information simply by
	observing the actual interval between requests.		observing the actual interval between requests.
	4.2. Transmit Timestamp Randomization		4.2. Transmit Timestamp Randomization
	While this memo calls for most fields in client packets to be set to		While this memo calls for most fields in client packets to be set to
	zero, the transmit timestamp is randomized. This decision is		zero, the transmit timestamp SHOULD be randomized. This decision is
	motivated by security as well as privacy.		motivated by security as well as privacy.
	NTP servers copy the transmit timestamp from the client's request		NTP servers copy the transmit timestamp from the client's request
	into the origin timestamp of the response; this memo calls for no		into the origin timestamp of the response; this memo calls for no
	change in this behavior. Clients discard any response whose origin		change in this behavior. Clients discard any response whose origin
	timestamp does not match the transmit timestamp of any request		timestamp does not match the transmit timestamp of any request
	currently in flight.		currently in flight.
	In the absence of cryptographic authentication, verification of		In the absence of cryptographic authentication, verification of
	origin timestamps is clients' primary defense against blind spoofing		origin timestamps is clients' primary defense against blind spoofing
	skipping to change at page 5, line 29 ¶		skipping to change at page 5, line 29 ¶
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,		[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
	"Network Time Protocol Version 4: Protocol and Algorithms		"Network Time Protocol Version 4: Protocol and Algorithms
	Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,		Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
	<https://www.rfc-editor.org/info/rfc5905>.		<https://www.rfc-editor.org/info/rfc5905>.
	7.2. Informative References		7.2. Informative References
			[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
			for IPv4, IPv6 and OSI", RFC 2030, DOI 10.17487/RFC2030,
			October 1996, <https://www.rfc-editor.org/info/rfc2030>.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,		DOI 10.17487/RFC4086, June 2005,
	<https://www.rfc-editor.org/info/rfc4086>.		<https://www.rfc-editor.org/info/rfc4086>.
	[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence		[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
	Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February		Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
	2012, <https://www.rfc-editor.org/info/rfc6528>.		2012, <https://www.rfc-editor.org/info/rfc6528>.
	[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,		[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
	Morris, J., Hansen, M., and R. Smith, "Privacy		Morris, J., Hansen, M., and R. Smith, "Privacy
	Considerations for Internet Protocols", RFC 6973,		Considerations for Internet Protocols", RFC 6973,
	DOI 10.17487/RFC6973, July 2013,		DOI 10.17487/RFC6973, July 2013,
	<https://www.rfc-editor.org/info/rfc6973>.		<https://www.rfc-editor.org/info/rfc6973>.
	7.3. URIs		7.3. URIs
	[1] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ntpd/		[1] https://github.com/openbsd/src/
	client.c?rev=1.1		commit/1346900e6d0ac3aeb0e3f9eb60b94c66586978c6
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	The authors would like to gratefully acknowledge Henning Brauer for		The possibility of minimizing data in client packets was described in
	pioneering NTP data minimization techniques as early as June 2004 [1]		RFC 2030 [RFC2030]. The authors would like to acknowledge Alexander
	as part of an NTP implementation for the OpenBSD Project.		Guy for pioneering the idea of randomization of all bits of the
			transmit timestamp in the rdate program of the OpenBSD project as
			early as May 2004 [1].
	The authors would like to thank Prof. Sharon Goldberg and Miroslav		The authors would also like to thank Prof. Sharon Goldberg and
	Lichvar for encouraging standardisation of the approach described in		Miroslav Lichvar for encouraging standardisation of the approach
	this document.		described in this document.
	Authors' Addresses		Authors' Addresses
	Daniel Fox Franke		Daniel Fox Franke
	Akamai Technologies, Inc.		Akamai Technologies, Inc.
	150 Broadway		150 Broadway
	Cambridge, MA 02142		Cambridge, MA 02142
	United States		United States
	Email: dafranke@akamai.com		Email: dafranke@akamai.com
End of changes. 9 change blocks.
	14 lines changed or deleted		20 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/