idnits 2.17.1 draft-ietf-ntp-data-minimization-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. -- The draft header indicates that this document updates RFC5905, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5905, updated by this document, for RFC5378 checks: 2005-07-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 25, 2019) is 1830 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 246 -- Obsolete informational reference (is this intentional?): RFC 2030 (Obsoleted by RFC 4330) -- Obsolete informational reference (is this intentional?): RFC 6528 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Franke 3 Internet-Draft Akamai 4 Updates: 5905 (if approved) A. Malhotra 5 Intended status: Standards Track Boston University 6 Expires: September 26, 2019 March 25, 2019 8 NTP Client Data Minimization 9 draft-ietf-ntp-data-minimization-04 11 Abstract 13 This memo proposes backward-compatible updates to the Network Time 14 Protocol to strip unnecessary identifying information from client 15 requests and to improve resilience against blind spoofing of 16 unauthenticated server responses. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 26, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 54 3. Client Packet Format . . . . . . . . . . . . . . . . . . . . 2 55 4. Security and Privacy Considerations . . . . . . . . . . . . . 3 56 4.1. Data Minimization . . . . . . . . . . . . . . . . . . . . 3 57 4.2. Transmit Timestamp Randomization . . . . . . . . . . . . 4 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 6. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 4 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 7.2. Informative References . . . . . . . . . . . . . . . . . 5 63 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 Network Time Protocol (NTP) packets, as specified by RFC 5905 69 [RFC5905], carry a great deal of information about the state of the 70 NTP daemon which transmitted them. In the case of mode 4 packets 71 (responses sent from server to client), as well as in broadcast (mode 72 5) and symmetric peering modes (mode 1/2), most of this information 73 is essential for accurate and reliable time synchronizaton. However, 74 in mode 3 packets (requests sent from client to server), most of 75 these fields serve no purpose. Server implementations never need to 76 inspect them, and they can achieve nothing by doing so. Populating 77 these fields with accurate information is harmful to privacy of 78 clients because it allows a passive observer to fingerprint clients 79 and track them as they move across networks. 81 This memo updates RFC 5905 to redact unnecessary data from mode 3 82 packets. This is a fully backwards-compatible proposal. It calls 83 for no changes on the server side, and clients which implement these 84 updates will remain fully interoperable with existing servers. 86 2. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 3. Client Packet Format 94 In every client-mode packet sent by a Network Time Protocol [RFC5905] 95 implementation: 97 The first octet, which contains the leap indicator, version 98 number, and mode fields, SHOULD be set to 0x23 (LI = 0, VN = 4, 99 Mode = 3). 101 The Transmit Timestamp field SHOULD be set uniformly at random, 102 generated by a mechanism suitable for cryptographic purposes. 103 [RFC4086] provides guidance on the generation of random values. 105 The Poll field SHOULD be set to either the actual polling interval 106 as specified by RFC 5905 or zero. 108 The Precision field SHOULD be set to 0x20. 110 All other header fields, specifically the Stratum, Root Delay, 111 Root Dispersion, Reference ID, Reference Timestamp, Origin 112 Timestamp, and Receive Timestamp, SHOULD be set to zero. 114 Servers MUST allow client packets to conform to the above 115 recommendations. This requirement shall not be construed so as to 116 prohibit servers from rejecting conforming packets for unrelated 117 reasons, such as access control or rate limiting. 119 4. Security and Privacy Considerations 121 4.1. Data Minimization 123 Zeroing out unused fields in client requests prevents disclosure of 124 information that can be used for fingerprinting [RFC6973]. 126 While populating any of these fields with authentic data reveals at 127 least some identifying information about the client, the Origin 128 Timestamp and Receive Timestamp fields constitute a particularly 129 severe information leak. RFC 5905 calls for clients to copy the 130 transmit timestamp and destination timestamp of the server's most 131 recent response into the origin timestamp and receive timestamp 132 (respectively) of their next request to that server. Therefore, when 133 a client moves between networks, a passive observer of both network 134 paths can determine with high confidence that the old and new IP 135 addresses belong to the same system by noticing that the transmit 136 timestamp of a response sent to the old IP matches the origin 137 timestamp of a request sent from the new one. 139 Zeroing the poll field is made optional (MAY rather than SHOULD) so 140 as not to preclude future development of schemes wherein the server 141 uses information about the client's current poll interval in order to 142 recommend adjustments back to the client. Putting accurate 143 information into this field has no significant impact on privacy 144 since an observer can already obtain this information simply by 145 observing the actual interval between requests. 147 4.2. Transmit Timestamp Randomization 149 While this memo calls for most fields in client packets to be set to 150 zero, the transmit timestamp SHOULD be randomized. This decision is 151 motivated by security as well as privacy. 153 NTP servers copy the transmit timestamp from the client's request 154 into the origin timestamp of the response; this memo calls for no 155 change in this behavior. Clients discard any response whose origin 156 timestamp does not match the transmit timestamp of any request 157 currently in flight. 159 In the absence of cryptographic authentication, verification of 160 origin timestamps is clients' primary defense against blind spoofing 161 of NTP responses. It is therefore important that clients' transmit 162 timestamps be unpredictable. Their role in this regard is closely 163 analagous to that of TCP Initial Sequence Numbers [RFC6528]. 165 The traditional behavior of the NTP reference implementation is to 166 randomize only a few (typically 10-15 depending on the precision of 167 the system clock) low-order bits of transmit timestamp, with all 168 higher bits representing the system time, as measured just before the 169 packet was sent. This is suboptimal, because with so few random 170 bits, an adversary sending spoofed packets at high volume will have a 171 good chance of correctly guessing a valid origin timestamp. 173 5. IANA Considerations 175 [RFC EDITOR: DELETE PRIOR TO PUBLICATION] 177 This memo introduces no new IANA considerations. 179 6. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 181 This section records the status of known implementations of the 182 protocol defined by this specification at the time of posting of this 183 Internet-Draft, and is based on a proposal described in RFC7942. The 184 description of implementations in this section is intended to assist 185 the IETF in its decision processes in progressing drafts to RFCs. 186 Please note that the listing of any individual implementation here 187 does not imply endorsement by the IETF. Furthermore, no effort has 188 been spent to verify the information presented here that was supplied 189 by IETF contributors. This is not intended as, and must not be 190 construed to be, a catalog of available implementations or their 191 features. Readers are advised to note that other implementations may 192 exist. 194 As of today the following vendors have produced an implementation of 195 the NTP Client Data Minimization recommendations described in this 196 document. 198 OpenNTPD 200 7. References 202 7.1. Normative References 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, 206 DOI 10.17487/RFC2119, March 1997, 207 . 209 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 210 "Network Time Protocol Version 4: Protocol and Algorithms 211 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 212 . 214 7.2. Informative References 216 [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 217 for IPv4, IPv6 and OSI", RFC 2030, DOI 10.17487/RFC2030, 218 October 1996, . 220 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 221 "Randomness Requirements for Security", BCP 106, RFC 4086, 222 DOI 10.17487/RFC4086, June 2005, 223 . 225 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 226 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 227 2012, . 229 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 230 Morris, J., Hansen, M., and R. Smith, "Privacy 231 Considerations for Internet Protocols", RFC 6973, 232 DOI 10.17487/RFC6973, July 2013, 233 . 235 7.3. URIs 237 [1] https://github.com/openbsd/src/ 238 commit/1346900e6d0ac3aeb0e3f9eb60b94c66586978c6 240 Appendix A. Acknowledgements 242 The possibility of minimizing data in client packets was described in 243 RFC 2030 [RFC2030]. The authors would like to acknowledge Alexander 244 Guy for pioneering the idea of randomization of all bits of the 245 transmit timestamp in the rdate program of the OpenBSD project as 246 early as May 2004 [1]. 248 The authors would also like to thank Prof. Sharon Goldberg and 249 Miroslav Lichvar for encouraging standardisation of the approach 250 described in this document. 252 Authors' Addresses 254 Daniel Fox Franke 255 Akamai Technologies, Inc. 256 150 Broadway 257 Cambridge, MA 02142 258 United States 260 Email: dafranke@akamai.com 261 URI: https://www.dfranke.us 263 Aanchal Malhotra 264 Boston University 265 111 Cummington St 266 Boston, MA/ 02215 267 United States 269 Email: aanchal4@bu.edu