< draft-ietf-ntp-data-minimization-00.txt		draft-ietf-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) A. Malhotra		Updates: 5905 (if approved) A. Malhotra
	Intended status: Standards Track Boston University		Intended status: Standards Track Boston University
	Expires: November 25, 2017 May 24, 2017		Expires: January 28, 2018 July 27, 2017
	NTP Client Data Minimization		NTP Client Data Minimization
	draft-ietf-ntp-data-minimization-00		draft-ietf-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 November 25, 2017.		This Internet-Draft will expire on January 28, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 14 ¶		skipping to change at page 2, line 14 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	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 . . . . . . . . . . . . 4		4.2. Transmit Timestamp Randomization . . . . . . . . . . . . 4
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4		6. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 4
	6.1. Normative References . . . . . . . . . . . . . . . . . . 4		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	6.2. Informative References . . . . . . . . . . . . . . . . . 5		7.1. Normative References . . . . . . . . . . . . . . . . . . 5
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5		7.2. Informative References . . . . . . . . . . . . . . . . . 5
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
	1. Introduction		1. Introduction
	Network Time Protocol (NTP) packets, as specified by RFC 5905		Network Time Protocol (NTP) packets, as specified by RFC 5905
	[RFC5905], carry a great deal of information about the state of the		[RFC5905], carry a great deal of information about the state of the
	NTP daemon which transmitted them. In the case of mode 4 packets		NTP daemon which transmitted them. In the case of mode 4 packets
	(responses sent from server to client), as well as in broadcast (mode		(responses sent from server to client), as well as in broadcast (mode
	5) and symmetric peering modes (mode 1/2), most of this information		5) and symmetric peering modes (mode 1/2), most of this information
	is essential for accurate and reliable time synchronizaton. However,		is essential for accurate and reliable time synchronizaton. However,
	in mode 3 packets (requests sent from client to server), most of		in mode 3 packets (requests sent from client to server), most of
	skipping to change at page 4, line 39 ¶		skipping to change at page 4, line 39 ¶
	packet was sent. This is suboptimal, because with so few random		packet was sent. This is suboptimal, because with so few random
	bits, an adversary sending spoofed packets at high volume will have a		bits, an adversary sending spoofed packets at high volume will have a
	good chance of correctly guessing a valid origin timestamp.		good chance of correctly guessing a valid origin timestamp.
	5. IANA Considerations		5. IANA Considerations
	[RFC EDITOR: DELETE PRIOR TO PUBLICATION]		[RFC EDITOR: DELETE PRIOR TO PUBLICATION]
	This memo introduces no new IANA considerations.		This memo introduces no new IANA considerations.
	6. References		6. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION
	6.1. Normative References		This section records the status of known implementations of the
			protocol defined by this specification at the time of posting of this
			Internet-Draft, and is based on a proposal described in RFC7942. The
			description of implementations in this section is intended to assist
			the IETF in its decision processes in progressing drafts to RFCs.
			Please note that the listing of any individual implementation here
			does not imply endorsement by the IETF. Furthermore, no effort has
			been spent to verify the information presented here that was supplied
			by IETF contributors. This is not intended as, and must not be
			construed to be, a catalog of available implementations or their
			features. Readers are advised to note that other implementations may
			exist.
			As of today the following vendors have produced an implementation of
			the NTP Client Data Minimization recommendations described in this
			document.
			OpenNTPD
			7. References
			7.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>.
	[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		7.2. Informative References
	[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,
	<http://www.rfc-editor.org/info/rfc4086>.		<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>.
			7.3. URIs
			[1] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ntpd/
			client.c?rev=1.1
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	The authors thank Prof. Sharon Goldberg and Miroslav Lichvar for		The authors would like to gratefully acknowledge Henning Brauer for
	calling attention to the issues addressed in this memo.		pioneering NTP data minimization techniques as early as June 2004 [1]
			as part of an NTP implementation for the OpenBSD Project.
			The authors would like to thank Prof. Sharon Goldberg and Miroslav
			Lichvar for encouraging standardisation of the approach 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.
	13 lines changed or deleted		45 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/