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

Miroslav Lichvar <mlichvar@redhat.com> Wed, 29 May 2019 10:06 UTC

Return-Path: <mlichvar@redhat.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4452E12017E for <ntp@ietfa.amsl.com>; Wed, 29 May 2019 03:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_gM942PIMIR for <ntp@ietfa.amsl.com>; Wed, 29 May 2019 03:06:39 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAFA112002E for <ntp@ietf.org>; Wed, 29 May 2019 03:06:39 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EB7A83179B47; Wed, 29 May 2019 10:06:25 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1FF71600C4; Wed, 29 May 2019 10:06:24 +0000 (UTC)
Date: Wed, 29 May 2019 12:06:23 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
Cc: "ntp@ietf.org" <ntp@ietf.org>, Danny Mayer <mayer@ntp.org>
Message-ID: <20190529100623.GH11346@localhost>
References: <155841904754.12856.3727925672753047210.idtracker@ietfa.amsl.com> <9d21f083-4cba-1dd1-f5bb-c95984d3127b@si6networks.com> <9d74c6e3-244e-fdd7-184a-0572f4f144cd@ntp.org> <25275d68-8c18-1616-f226-dffe7e21091e@si6networks.com> <20190528174208.11253a67@rellim.com> <1a133133-5d6a-ca96-6c15-73e6933baffc@si6networks.com> <2794A95B-B118-40BD-AD60-DCB50CC32717@latt.net> <f03dbfbd-007a-fa81-f846-85079a59dddd@si6networks.com> <c4384ecc-2711-3479-df21-d6533f438418@ntp.org> <5CEE4B90020000A1000317F4@gwsmtp.uni-regensburg.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5CEE4B90020000A1000317F4@gwsmtp.uni-regensburg.de>
User-Agent: Mutt/1.11.3 (2019-02-01)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Wed, 29 May 2019 10:06:34 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/aky6JZcBvJTm8U88K8yvkBTw2D4>
Subject: Re: [Ntp] Antw: Re: New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2019 10:06:42 -0000

On Wed, May 29, 2019 at 11:06:24AM +0200, Ulrich Windl wrote:
> >>> Danny Mayer <mayer@ntp.org> schrieb am 29.05.2019 um 10:42 in Nachricht
> > You are totally missing the point. The port numbers don't make NTP
> > vulnerable. The "session id" does not exist here. Instead NTP has an
> > origin timestamp that an off‑path attacker does not have access to. Even
> > if it did, then the origin timestamp is wildly different each time it's
> > sent and is not predictable. This is a 64‑bit nonce.
> 
> ...of which about 30 bits are random (assuming the attacker knows what time it
> is and packets take less than one second to travel)...

I assume this whole discussion is about clients not using fully random
transmit timestamps (as specified in the data minimization draft).

30 bits is not that much. A typical NTP client running on a modern
computer can receive and process few hundred thousands packets per
second. This means it would accept a spoofed response in less than an
hour (assuming most of genuine responses from the server are dropped
in the network or socket). With 14 extra bits of entropy from the
source port it would be a year. That's a significant improvement.

In reality, I think it's quite a bit less than 30 bits. If we assume
the clock is accurate to 1 millisecond, it's only about 22 bits worth
of guessing. Then there are other things that may make this even
easier.

The client may be using a fixed 1-second timer to schedule its
transmissions and it may also be running as a stratum-2 server,
leaking the receive timestamp as the reference timestamp and leaking
the delay as root delay, which make the transmit/origin timestamp even
more predictable.

-- 
Miroslav Lichvar