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.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/