Re: [Ntp] New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)

[Fernando Gont <[e-mail]>]

On 29/5/19 04:42, Danny Mayer wrote:
> 
> On 5/29/19 12:18 AM, Fernando Gont wrote:
>> On 28/5/19 23:20, Majdi S. Abbas wrote:
>>> Randomizing the source port is pointless.  As Danny has noted, t1
>>> already acts as a 2^64 nonce on each client mode chime request.  This
>>> sufficiently hardens the unauthenticated case to an off path
>>> attacker.  If additional security is required, authentication (via
>>> classic PSK, or NTS modes) should be used.
>> Using predictable numeric identifiers is a bad habit. We have plenty of
>> history in this area and, as noted, it's quite interesting to see folks
>> pushing in this direction in 2019, when the tendency has been to
>> actually move away from predictable numeric IDs (TCP ISNs, transport
>> protocol numbers, DNS TxIDs, Frag IDs, etc.).
>>
>> Using predictable port numbers makes it easy for an attacker to infer
>> the "session id". You are just considering one possible attack scenario.
>>
> You are totally missing the point. The port numbers don't make NTP
> vulnerable. The "session id" does not exist here. 

Attackers need to know the four-tuple that was employed by the query.
That's a prerequisite for attacking NTP. When you *unnecessarily* employ
a predictable port on the client side, you are making the attacker's
life easier. Period.



> Instead NTP has an
> origin timestamp that an off-path attacker does not have access to.

That's *not* "instead". Port numbers identify the transport protocol
instance. The org timestamp is an protocol specific value.

What you're saying is the equivalent that we should not randomize TCP
source ports because we also do TCP ISN randomization. And such logic is
very flawed, of course.



> RFC6056 was probably developed as a result of the Kaminsky attack on DNS
> and the way we fixed that.

It wasn't.


> I noticed a number of people mentioned in
> that RFC who were involved in those changes. It doesn't say so but that
> RFC addresses shortcomings in those protocols that have small or
> non-existent nonces which is not the case for NTP. 

Huh? You are mixing up transport layer with app layer. Again: using
predictable numeric IDs is a bad idea.


NO matter what you do at upper layers, you shouldn't use predictable
numeric IDs. I can't believe that we are discussing this in 2019.



>>> Per session randomization doesn't resolve these issues -- the stated
>>> rationale for both the draft and filed CVE is hardening to off path
>>> attacks, which we've just covered.
>> If tomorrow a flaw were found in an NTP implementation, that happened
>> e.g. prior to the validation of the origin timestamp, I guess you are
>> going to argue that "that was out of scope"?
>>
> There is no session validation since this is UDP not TCP. A flaw in an
> NTP implementation that did not check that the timestamp matched would
> be a bug in that implementation and randomizing the source port is not
> going to change that. Furthermore the client needs the origin timestamp
> to find the match in its local memory in order to process the incoming
> packet. if it cannot find it, it will ignore the packet.

You missed my example. I was referring to, e.g. o possible a bug in the
NTP implementation, present *prior* to the validation of the org
timestamp (e.g., processing of malformed packet, etc.).


-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492