Sharon Goldberg writes: > My proposal is orthogonal to what is being discussed here. I believe it > can be implemented alongside Harlan's proposal in suggest-refid.
Agreed. > I want to emphasize that my proposal is backwards compatible and can be > implemented today without an extension field. Whereas Harlan's idea is > super clever but it requires both the client and the server to understand > an extension field. > > First off, to reiterate why I care about this, pretty much all the off-path > attacks that we and Cisco have done have the following first step: > > Query the target client. Get the response. Learn its refID. Now you know > the client's server. $Attack the server. (Potentially rinse and repeat if > the client moves to another server.) The bad guy can impersonate the client and "vex" the server, and the bad guy can also impersonate the server and "vex" the client. > Sure, mode 6 reveals this information but modern NTP configurations should > prevent remote IPs from launching mode 6 queries, as it is not only an > amplification vector and also leaks state making it easier to attack the > system. (See also Cisco's "origin leak" bug [1].) So I do not have a > "warm fuzzy" feeling when I see NTP leaking information. Especially since > most NTP traffic is not usually cryptographically protected. I think NTP > should leak less information, not more. > > My proposal offers a backwards compatible way for a system to limit the > information leaked in its reference ID. It solves the IPv6 refID collision > problem. And it seems to be compatible with what NTP is doing today. > > Some exceptions could be made for stratum 1 servers to broadcast to all > clients that your refID is GPS or some other external source, if this > really a problem. But we should be sure its really a problem, because > information leakage always makes it easier to launch attacks. The refid changes affect S2+ only, we'd leave S1 refids alone. > Much of this discussion has been regarding a future use case in which a > client had two IP addresses B and C. This client sends a query from > interface B and wants to make sure it is not in a timing loop with another > system A who is taking time from interface B. The timing loop issue has 2 aspects (at least). I'll talk about one of them now. One reason to avoid a timing loop has to do with sailing off into the weeds. I'm not sure how significant this case is anymore. If I only have 1 source of time, well, we know what that means. If that source of time only has me as their source of time then the timing loop stuff means we'll detect this immedately and we'll both go out-of-sync. But if we do not detect this loop, if A is at S2 then B is at S3. When we're down to no additional sources of time, at that point A will become S4 and B will be come S5, then it goes to S6/S7, ... until the machines go out of sync. In this case that will happen in 6 poll intervals. If there are no other sources of time available, then is it significant that the machines go out of sync after 1 or 2 poll intervals instead of 6? I'm using round numbers here. A semblance of order would be in place if the boxes were configured using orphan mode, or even local refclocks. So I'd really like to know exactly what the concerns are about this particular "failure mode". H -- > One could deal with this usecase using Harlan's proposal, but this does not > preclude my proposal running in parallel. To deal with this, the client "B > and C" uses Harlan's extension field to signal "if you take time from me, > put this nonce as your refID." If it decided to signal the *same* nonce > to all clients, it has explicitly taken on the risk than an attacker can > use this information as a first step in an attack, as I have described > above. If it signals a different nonce to all clients, then it is > protected from this. > > This non-backwards compatible feature would therefore only be used by > systems that need it, eg those that have two IP addresses. All other > systems could limit the amount of information being leaked in their refID > by using my proposal. > > Sharon > > [1] http://www.talosintel.com/reports/TALOS-2016-0078/ > > --001a1142b68e529239052fe28ce7 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > <div dir=3D"ltr"><div><div><div><div>My proposal is orthogonal to what is b= > eing discussed here.=C2=A0=C2=A0 I believe it can be implemented alongside = > Harlan's proposal in suggest-refid.<br><br>I want to emphasize that my = > proposal is backwards compatible and can be implemented today without an ex= > tension field.=C2=A0 Whereas Harlan's idea is super clever but it requi= > res both the client and the server to understand an extension field.<br></d= > iv><br>First off, to reiterate why I care about this, pretty much all the o= > ff-path attacks that we and Cisco have done have the following first step:<= > br><br></div>Query the target client. Get the response. Learn its refID. No= > w you know the client's server. $Attack the server. (Potentially rinse = > and repeat if the client moves to another server.)<br><br></div><div>Sure, = > mode 6 reveals this information but modern NTP configurations should preven= > t remote IPs from launching mode 6 queries, as it is not only an amplificat= > ion vector and also leaks state making it easier to attack the system.=C2= > =A0 (See also Cisco's "origin leak" bug [1].)=C2=A0 So I do n= > ot have a "warm fuzzy" feeling when I see NTP leaking information= > . Especially since most NTP traffic is not usually cryptographically protec= > ted.=C2=A0 I think NTP should leak less information, not more.<br><br></div= > ><div>My proposal offers a backwards compatible way for a system to limit t= > he information leaked in its reference ID. It solves the IPv6 refID collisi= > on problem.=C2=A0 And it seems to be compatible with what NTP is doing toda= > y.<br></div><div><div><br></div>Some exceptions could be made for stratum 1= > servers=20 > to broadcast to all clients that your refID is GPS or some other=20 > external source, if this really a problem.=C2=A0 But we should be sure its= > =20 > really a problem, because information leakage always makes it easier to=20 > launch attacks. <br><br></div><div>Much of this discussion has been regardi= > ng a future use case in which a client had two IP addresses B and C.=C2=A0= > =C2=A0 This client sends a query from interface B and wants to make sure it > is not in a timing loop with another system A who is taking time from=20 > interface B.=C2=A0 <br><br>One could deal with this usecase using Harlan= > 9;s proposal, but this does not preclude my proposal running in parallel.= > =C2=A0 To deal with this, the client "B and C"=C2=A0 uses Harlan&= > #39;s extension field to signal "if you take time from me, put this no= > nce as your refID."=C2=A0=C2=A0 If it decided to signal the *same* non= > ce to all clients, it has explicitly taken on the risk than an attacker can= > use this information as a first step in an attack, as I have described abo= > ve.=C2=A0 If it signals a different nonce to all clients, then it is protec= > ted from this.</div><br></div>This non-backwards compatible feature would t= > herefore only be used by systems that need it, eg those that have two IP ad= > dresses. All other systems could limit the amount of information being leak= > ed in their refID by using my proposal.<br><div><br><div>Sharon<br><br>[1] = > <a href=3D"http://www.talosintel.com/reports/TALOS-2016-0078/";>http://www.t= > alosintel.com/reports/TALOS-2016-0078/</a><br></div><br><div><br></div></di= > v></div> > > --001a1142b68e529239052fe28ce7-- > > --===============5243542199967168099== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > ntpwg mailing list > [email protected] > http://lists.ntp.org/listinfo/ntpwg > --===============5243542199967168099==-- > _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
