< draft-dfranke-ntp-data-minimization-00.txt		draft-dfranke-ntp-data-minimization-01.txt >
	Network Working Group D. Franke		Network Working Group D. Franke
	Internet-Draft Akamai		Internet-Draft Akamai
	Updates: 5905 (if approved) October 17, 2016		Updates: 5905 (if approved) A. Malhotra
	Intended status: Standards Track		Intended status: Standards Track Boston University
	Expires: April 20, 2017		Expires: May 2, 2017 October 29, 2016
	NTP Client Data Minimization		NTP Client Data Minimization
	draft-dfranke-ntp-data-minimization-00		draft-dfranke-ntp-data-minimization-01
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 April 20, 2017.		This Internet-Draft will expire on May 2, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 18 ¶		skipping to change at page 2, line 18 ¶
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
	3. Client Packet Format . . . . . . . . . . . . . . . . . . . . 2		3. Client Packet Format . . . . . . . . . . . . . . . . . . . . 2
	4. Security and Privacy Considerations . . . . . . . . . . . . . 3		4. Security and Privacy Considerations . . . . . . . . . . . . . 3
	4.1. Data Minimization . . . . . . . . . . . . . . . . . . . . 3		4.1. Data Minimization . . . . . . . . . . . . . . . . . . . . 3
	4.2. Transmit Timestamp Randomization . . . . . . . . . . . . 3		4.2. Transmit Timestamp Randomization . . . . . . . . . . . . 3
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
	6.1. Normative References . . . . . . . . . . . . . . . . . . 4		6.1. Normative References . . . . . . . . . . . . . . . . . . 4
	6.2. Informative References . . . . . . . . . . . . . . . . . 4		6.2. Informative References . . . . . . . . . . . . . . . . . 4
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
	1. Introduction		1. Introduction
	Network Time Protocol packets, as specified by RFC 5905 [RFC5905],		Network Time Protocol (NTP) packets, as specified by RFC 5905
	carry a great deal of information about the state of the NTP daemon		[RFC5905], carry a great deal of information about the state of the
	which transmitted them. In the case of mode 4 packets (responses		NTP daemon which transmitted them. In the case of mode 4 packets
	sent from server to client), as well as in broadcast and symmetric		(responses sent from server to client), as well as in broadcast (mode
	modes, most of this information is essential for accurate and		5) and symmetric peering modes (mode 1/2), most of this information
	reliable time synchronizaton. However, in mode 3 packets (requests		is essential for accurate and reliable time synchronizaton. However,
	sent from client to server), these fields serve no purpose. Server		in mode 3 packets (requests sent from client to server), most of
	implementations never need to inspect them, and they can achieve		these fields serve no purpose. Server implementations never need to
	nothing by doing so. Populating these fields with accurate		inspect them, and they can achieve nothing by doing so. Populating
	information is harmful to privacy because it allows a passive		these fields with accurate information is harmful to privacy of
	observer to fingerprint clients and track them as they move across		clients because it allows a passive observer to fingerprint clients
	networks.		and track them as they move across networks.
	This memo updates RFC 5905 to redact unnecessary data from mode 3		This memo updates RFC 5905 to redact unnecessary data from mode 3
	packets. It calls for no changes on the server side, and clients		packets. This is a fully backwards-compatible proposal. It calls
	which implement these updates will remain fully interoperable with		for no changes on the server side, and clients which implement these
	existing servers.		updates will remain fully interoperable with existing servers.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	3. Client Packet Format		3. Client Packet Format
	In every client-mode packet sent by a Network Time Protocol [RFC5905]		In every client-mode packet sent by a Network Time Protocol [RFC5905]
	implementation:		implementation:
	The first octet, which contains the leap indicator, version		The first octet, which contains the leap indicator, version
	number, and mode fields, SHALL be set to 0x23 (LI = 0, VN = 4,		number, and mode fields, SHALL be set to 0x23 (LI = 0, VN = 4,
	Mode = 3).		Mode = 3).
	The Transmit Timestamp field SHALL be set uniformly at random,		The Transmit Timestamp field SHALL 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.
	All other header fields, specifically the Stratum, Poll,		The Poll field MAY be set to the actual polling interval as
	Precision, Root Delay, Root Dispersion, Reference ID, Reference		specified by RFC 5905, or else MAY be set to zero.
	Timestamp, Origin Timestamp, and Receive Timestamp, SHALL be set
	to zero.		All other header fields, specifically the Stratum, Precision, Root
			Delay, Root Dispersion, Reference ID, Reference Timestamp, Origin
			Timestamp, and Receive Timestamp, SHALL be set to zero.
	4. Security and Privacy Considerations		4. Security and Privacy Considerations
	4.1. Data Minimization		4.1. Data Minimization
	Zeroing out unused fields in client requests prevents disclosure of		Zeroing out unused fields in client requests prevents disclosure of
	information that can be used for fingerprinting [RFC6973].		information that can be used for fingerprinting [RFC6973].
	While populating any of these fields with authentic data reveals at		While populating any of these fields with authentic data reveals at
	least some identifying information about the client, the Origin		least some identifying information about the client, the Origin
	skipping to change at page 3, line 38 ¶		skipping to change at page 3, line 40 ¶
	severe information leak. RFC 5905 calls for clients to copy the		severe information leak. RFC 5905 calls for clients to copy the
	transmit timestamp and destination timestamp of the server's most		transmit timestamp and destination timestamp of the server's most
	recent response into the origin timestamp and receive timestamp		recent response into the origin timestamp and receive timestamp
	(respectively) of their next request to that server. Therefore, when		(respectively) of their next request to that server. Therefore, when
	a client moves between networks, a passive observer of both network		a client moves between networks, a passive observer of both network
	paths can determine with high confidence that the old and new IP		paths can determine with high confidence that the old and new IP
	addresses belong to the same system by noticing that the transmit		addresses belong to the same system by noticing that the transmit
	timestamp of a response sent to the old IP matches the origin		timestamp of a response sent to the old IP matches the origin
	timestamp of a request sent from the new one.		timestamp of a request sent from the new one.
			Zeroing the poll field is made optional because this field conveys no
			information that an observer could not otherwise obtain simply by
			observing the actual interval between requests. Since in the NTP
			reference implementation servers copy the poll field from the
			client's request into their response, if clients rely on the value of
			the poll field in the response then zeroing the poll field of the
			request may result in adverse behavior.
	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 is 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
	skipping to change at page 4, line 30 ¶		skipping to change at page 4, line 40 ¶
	6. References		6. References
	6.1. Normative References		6.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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,
	<http://www.rfc-editor.org/info/rfc4086>.
	[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,
	<http://www.rfc-editor.org/info/rfc5905>.		<http://www.rfc-editor.org/info/rfc5905>.
	6.2. Informative References		6.2. Informative References
			[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
			"Randomness Requirements for Security", BCP 106, RFC 4086,
			DOI 10.17487/RFC4086, June 2005,
			<http://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, <http://www.rfc-editor.org/info/rfc6528>.		2012, <http://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,
	<http://www.rfc-editor.org/info/rfc6973>.		<http://www.rfc-editor.org/info/rfc6973>.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	The author thanks Prof. Sharon Goldberg, Miroslav Lichvar, and		The authors thank Prof. Sharon Goldberg and Miroslav Lichvar for
	Aanchal Malhotra for calling attention to the issues addressed in		calling attention to the issues addressed in this memo.
	this memo.
	Author's Address		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
	URI: https://www.dfranke.us		URI: https://www.dfranke.us
			Aanchal Malhotra
			Boston University
			111 Cummington St
			Boston, MA 02215
			United States
			Email: aanchal4@bu.edu
End of changes. 13 change blocks.
	34 lines changed or deleted		43 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/