Re: [Ntp] New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)
Danny Mayer <mayer@ntp.org> Wed, 29 May 2019 08:42 UTC
Return-Path: <mayer@ntp.org>
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 3983212017D for <ntp@ietfa.amsl.com>; Wed, 29 May 2019 01:42:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] 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 wqyAUXks1Tq4 for <ntp@ietfa.amsl.com>; Wed, 29 May 2019 01:42:15 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0253F120199 for <ntp@ietf.org>; Wed, 29 May 2019 01:42:14 -0700 (PDT)
Received: from [10.10.10.122] (pool-71-174-223-53.bstnma.east.verizon.net [71.174.223.53]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 45DPN51XYwzL7T for <ntp@ietf.org>; Wed, 29 May 2019 08:42:13 +0000 (UTC)
To: ntp@ietf.org
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>
From: Danny Mayer <mayer@ntp.org>
Message-ID: <c4384ecc-2711-3479-df21-d6533f438418@ntp.org>
Date: Wed, 29 May 2019 04:42:11 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <f03dbfbd-007a-fa81-f846-85079a59dddd@si6networks.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/jWMzxNk4h90kueYZeD6r8Qw0cvo>
Subject: Re: [Ntp] 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 08:42:28 -0000
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. 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. RFC6056 was probably developed as a result of the Kaminsky attack on DNS and the way we fixed that. 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. Since you were one of the authors I presume you know that. I discussed NTP with Paul Vixie at the time and we agreed that because of the nonce it would not be vulnerable like DNS was. Since you claim that having well-known source ports is a vulnerability, how does an off-path attacker know the server IP addresses that it is using to get the timestamps? Accepting that, please provide in detail how the off-path attacker is able to set up the origin timestamp so that the client will accept it. You MUST be able to do this for the attack to succeed. Remember that 64-bit timestamps are wildly different each time a request goes out. If you cannot do this you have no case. Note that replay attacks fail too since the client has already processed a given origin timestamp. > >> 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. Danny
- [Ntp] New rev of the NTP port randomization I-D (… Fernando Gont
- Re: [Ntp] New rev of the NTP port randomization I… Danny Mayer
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] New rev of the NTP port randomization I… Gary E. Miller
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] New rev of the NTP port randomization I… Majdi S. Abbas
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] New rev of the NTP port randomization I… Harlan Stenn
- Re: [Ntp] New rev of the NTP port randomization I… Harlan Stenn
- Re: [Ntp] New rev of the NTP port randomization I… tglassey@earthlink.net
- Re: [Ntp] New rev of the NTP port randomization I… tglassey@earthlink.net
- Re: [Ntp] New rev of the NTP port randomization I… Harlan Stenn
- Re: [Ntp] New rev of the NTP port randomization I… Harlan Stenn
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] New rev of the NTP port randomization I… Miroslav Lichvar
- Re: [Ntp] New rev of the NTP port randomization I… Harlan Stenn
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] New rev of the NTP port randomization I… Danny Mayer
- Re: [Ntp] New rev of the NTP port randomization I… Danny Mayer
- Re: [Ntp] New rev of the NTP port randomization I… Danny Mayer
- [Ntp] Antw: Re: New rev of the NTP port randomiza… Ulrich Windl
- [Ntp] Antw: Re: New rev of the NTP port randomiza… Ulrich Windl
- Re: [Ntp] New rev of the NTP port randomization I… Harlan Stenn
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] Antw: Re: New rev of the NTP port rando… Harlan Stenn
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] Antw: Re: New rev of the NTP port rando… Miroslav Lichvar
- Re: [Ntp] New rev of the NTP port randomization I… Harlan Stenn
- Re: [Ntp] Antw: Re: Antw: Re: New rev of the NTP … Ulrich Windl
- Re: [Ntp] Antw: Re: New rev of the NTP port rando… Harlan Stenn
- Re: [Ntp] Antw: Re: Antw: Re: New rev of the NTP … Harlan Stenn
- Re: [Ntp] Antw: Re: Antw: Re: New rev of the NTP … Hal Murray
- Re: [Ntp] Antw: Re: Antw: Re: New rev of the NTP … Harlan Stenn
- Re: [Ntp] New rev of the NTP port randomization I… tglassey@earthlink.net
- Re: [Ntp] New rev of the NTP port randomization I… tglassey@earthlink.net
- Re: [Ntp] Antw: Re: Antw: Re: New rev of the NTP … Hal Murray
- Re: [Ntp] New rev of the NTP port randomization I… Danny Mayer
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] New rev of the NTP port randomization I… Harlan Stenn
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] New rev of the NTP port randomization I… Watson Ladd
- Re: [Ntp] New rev of the NTP port randomization I… Ask Bjørn Hansen
- Re: [Ntp] Antw: Re: Antw: Re: New rev of the NTP … tglassey@earthlink.net
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- [Ntp] Antw: Re: New rev of the NTP port randomiza… Ulrich Windl
- Re: [Ntp] New rev of the NTP port randomization I… Miroslav Lichvar
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] New rev of the NTP port randomization I… Harlan Stenn
- Re: [Ntp] Antw: Re: Antw: Re: New rev of the NTP … Tony Finch
- [Ntp] New rev of the NTP port randomization I-D (… Loganaden Velvindron
- Re: [Ntp] New rev of the NTP port randomization I… Fernando Gont
- Re: [Ntp] New rev of the NTP port randomization I… Aanchal Malhotra