idnits 2.17.1 draft-stenn-ntp-not-you-refid-00.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC5905], [NDSS16]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2016) is 2820 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Goldberg 3 Internet-Draft Boston University 4 Intended status: Standards Track H. Stenn 5 Expires: January 9, 2017 Network Time Foundation 6 July 8, 2016 8 Network Time Protocol Not You REFID 9 draft-stenn-ntp-not-you-refid-00 11 Abstract 13 NTP has been widely used through several revisions, with the latest 14 being RFC 5905 [RFC5905]. A core component of the protocol and the 15 algoritms is the Reference ID, or REFID, which is used to identify 16 the source of time used for synchronization (aka the "system peer"). 17 Traditionally, when the source of time was another system, the REFID 18 was the IPv4 address of that other system. The purpose of the REFID 19 is to prevent a one-degree "timing loop": where if A has several 20 timing sources that include B, if B decides to get its time from A, 21 then A should not then decide to get its time from B. The REFID is 22 therefore a vital core-component of the base NTP packet. If a 23 system's REFID is the IPv4 address of its time source, then with a 24 simple query a remote attacker can learn the target's REFID. The 25 remote attacker can then try to use that information to send spoofed 26 NTP packets to the target or the target's time source, attempting to 27 cause a disruption in time service [NDSS16]. Since the core purpose 28 of the REFID is to prevent a one-degree timing loop, this proposal is 29 a backward-compatible way to limit the amount of information that is 30 leaked in the REFID. Specifically, it allows the prevention of one- 31 degree timing loops by allowing a system A to reveal to a querying 32 system B that B is not A's time source, but without revealing the 33 actual time source to which A is synchronized. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 9, 2017. 51 Copyright Notice 53 Copyright (c) 2016 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 70 2. The REFID . . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. The Not-You REFID . . . . . . . . . . . . . . . . . . . . . . 4 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 76 6.2. Informative References . . . . . . . . . . . . . . . . . 5 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 79 1. Introduction 81 NTP has been widely used through several revisions, with the latest 82 being RFC 5905 [RFC5905]. A core component of the protocol and the 83 algoritms is the Reference ID, or REFID, which is used to identify 84 the source of time used for synchronization. Traditionally, when the 85 source of time was another system, the REFID was the IPv4 address of 86 that other system. If the source of time was using IPv6 for its 87 connection, then a 4 octet digest value of the IPv6 address was used 88 as the REFID. The purpose of the REFID is to prevent a one-degree 89 timing loop, where if A has several timing sources that include B, if 90 B decides to get its time from A, then A should not then decide to 91 get its time from B. 93 Recently it was observed in [NDSS16] that a remote attacker can query 94 a target system to learn its time source from the REFID included in 95 target's response packet. The remote attacker can then use this 96 information to send spoofed packets to the target or its time source, 97 in an attempt to disrupt time service. The REFID thus unnecessarily 98 leaks information about a target's time server to remote attackers. 99 The best way to mitigate this vulnerability is to decouple the IP 100 address of the time source from the REFID. To do this, a system can 101 use an otherwise-impossible value for its REFID, called the "not-you" 102 value, when it believes that a querying system is not its time 103 source. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 2. The REFID 113 The interpretation of a REFID is based on the stratum, as documented 114 in RFC 5905 [RFC5905], section 7.3, "Packet Header Variables". The 115 core reason for the REFID in the NTP Protocol is to prevent a degree- 116 one timing loop, where server B decides to follow A as its time 117 source, and A then decides to follow B as its time source. 119 At Stratum 2+, which will be the case if two servers A and B are 120 exchanging timing information, then if server B follows A as its time 121 source, A's address will be B's REFID. When A uses IPv4, the default 122 REFID is A's IPv4 address. When A uses IPv6, the default REFID is a 123 four-octet digest of A's IPv6 address. Now, if A queries B for its 124 time, then A will learn that B is using A as its time source by 125 observing A's address in the REFID field of the response packet sent 126 by B. Thus, A will not select B as a potential time source, since 127 this would cause a timing loop. 129 However, this mechanism also allows a third-party C to learn that A 130 is the time source that is being used by B. When A is using IPv4, C 131 can learn this by querying B for its time, and observing that the 132 REFID in B's response is the IPv4 address of A. Meanwhile, when A is 133 using IPv6, then C can again query B for its time, and then can use 134 an offline dictionary attack to determine the IPv6 address that 135 corresponds to the digest value in the response sent by B. C could 136 construct the necessary dictionary by compiling a list of publically 137 accessible IPv6 servers. Remote attackers can use this technique to 138 identify the time sources used by a target, and then send spoofed 139 packets to the target or its time source in order to disrupt time 140 service as was done e.g., in [NDSS16] or [CVE-2015-8138]. 142 3. The Not-You REFID 144 This proposal allows the one-degree loop detection to work while 145 keeping potentially abusable information from being disclosed to 146 uninterested parties. It does this by returning the normal REFID to 147 queries that come from an address that the current system believes is 148 its time source (aka its "system peer"), and otherwise returning a 149 special IP address that is interpreted to mean "not you". The "not 150 you" IP address is 127.127.127.127 when the query is made from an 151 IPv4 address, or when the query is made from an IPv6 address whose 152 four-octect hash does not equal 127.127.127.127. The "not you" IP 153 address is 127.127.127.128 when the query is made from an address 154 whose four-octect hash equals to 127.127.127.127. 156 Note that this mechanism is transparent to the party that sends 157 timing queries. A querying system that uses IPv4 continues to check 158 that its IPv4 address does not appear in the REFID before deciding 159 whether to take time from the current system. A querying system that 160 uses IPv6 continues to check that the four-octet hash of its IPv6 161 address does not appear in the REFID before deciding whether to take 162 time from the current system. 164 This proposal will hide the current system's system peer from 165 querying systems that the current system believes are not the current 166 system's system peer. Note well, however, that the current system 167 will return the "not you" value to a query from its system peer if 168 the system peer sends its query from an unexpected IP address. 170 4. Security Considerations 172 Many systems running NTP are configured to return responses to timing 173 queries by default. These responses contain a REFID field, which 174 generally reveals the address of the system's time source. This 175 behavior can be exploited by remote attackers who wish to first learn 176 the address of a target's time source, and then attack the target 177 and/or its time source. As such, this proposal is designed to harden 178 NTP against these attacks by limiting the amount of information 179 leaked in the REFID field. 181 5. Acknowledgements 183 The authors wish to acknowledge useful discussions with Aanchal 184 Malhotra and Matthew Van Gundy. 186 6. References 188 6.1. Normative References 190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 191 Requirement Levels", BCP 14, RFC 2119, 192 DOI 10.17487/RFC2119, March 1997, 193 . 195 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 196 "Network Time Protocol Version 4: Protocol and Algorithms 197 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 198 . 200 6.2. Informative References 202 [CVE-2015-8138] 203 Van Gundy, M. and J. Gardner, "Network Time Protocol 204 Origin Timestamp Check Impersonation Vulnerability (CVE- 205 2015-8138)", in TALOS VULNERABILITY REPORT (TALOS- 206 2016-0077), 2016. 208 [NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 209 "Attacking the Network Time Protocol", in ISOC Network and 210 Distributed System Security Symposium 2016 (NDSS'16), 211 2016. 213 Authors' Addresses 215 Sharon Goldberg 216 Boston University 217 111 Cummington St 218 Boston, MA 02215 219 US 221 Email: goldbe@cs.bu.edu 223 Harlan Stenn 224 Network Time Foundation 225 P.O. Box 918 226 Talent, OR 97540 227 US 229 Email: stenn@nwtime.org