Re: [Ntp] Antwort: Re: Symmetric mode

Danny Mayer <mayer@pdmconsulting.net> Sat, 24 September 2022 23:20 UTC

Return-Path: <mayer@pdmconsulting.net>
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 EC09CC14F74E for <ntp@ietfa.amsl.com>; Sat, 24 Sep 2022 16:20:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGDZl_hvn8KH for <ntp@ietfa.amsl.com>; Sat, 24 Sep 2022 16:20:40 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA00C14EB1E for <ntp@ietf.org>; Sat, 24 Sep 2022 16:20:38 -0700 (PDT)
Received: from [192.168.1.156] (pool-108-26-202-2.bstnma.fios.verizon.net [108.26.202.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4MZlPL13HyzMNbj; Sat, 24 Sep 2022 23:20:38 +0000 (UTC)
Message-ID: <9eac8a08-80d7-0d23-940a-d00c4bb2382f@pdmconsulting.net>
Date: Sat, 24 Sep 2022 19:20:36 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.0
Content-Language: en-US
To: Miroslav Lichvar <mlichvar@redhat.com>
Cc: kristof.teichel=40ptb.de@dmarc.ietf.org, ntp@ietf.org
References: <880b8ec4-e112-e2e2-f48c-c940064bc749@pdmconsulting.net> <mayer@pdmconsulting.net> <796c33e6-02dc-0665-c8a2-a143f9100bdd@pdmconsulting.net> <20220919024614.4AB8328C1E2@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <YygwAeTMeSHXXk6t@localhost> <OF42F0D0F6.E94FA935-ONC12588C3.005225C3-C12588C3.0054DC8B@ptb.de> <d13df0b6-7c47-820e-5dbd-21dd7e2d4801@pdmconsulting.net> <YywRhCmTD4mt8KTy@localhost>
From: Danny Mayer <mayer@pdmconsulting.net>
In-Reply-To: <YywRhCmTD4mt8KTy@localhost>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/sAj4Bcftj7Nwy2JnrkeHMx9EUZU>
Subject: Re: [Ntp] Antwort: Re: Symmetric mode
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <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: Sat, 24 Sep 2022 23:20:45 -0000

On 9/22/22 3:40 AM, Miroslav Lichvar wrote:
> On Wed, Sep 21, 2022 at 07:30:06PM -0400, Danny Mayer wrote:
>>> Again, could you qualify which of these statements you disagree with
>>> and/or how so?
>> Symmetric peer associations are not ephemeral since both sides keep
>> information of each other the same way that any client does.
> Quoting from RFC 5905:
>    Ephemeral associations are mobilized upon the arrival of a
>    packet and are demobilized upon error or timeout.
You forget that a symmetric peer knows about the other peer and it keeps 
that information. It's not really ephemeral since as a client of that 
other node it keeps the information of that peer.
>> An attacker
>> cannot really replay an authenticated message as it would be rejected as
>> already received.
> The peer doesn't know if a received message is a new one or it was
> already sent before by one of the peers. It doesn't have an infinite
> storage and there can be messages lost in the network.
When a peer is acting as the client it knows if it already has received 
the message. If the peer is acting as the server then it acts as if 
that's a new request from a client and responds appropriately.
>
> ntpd remembers only the last received packet. You can replay any
> previous message from the other peer, or the peer's own messages (last
> or previous).
No, as explained above.
>
>> I'm not sure what is meant by limiting IP addresses to
>> prevent that since a replay attack would have to use the same IP address to
>> send the packet.
> The IP addresses and ports are not included in the data authenticated
> by the NTP MAC. You can replay an authenticated NTP messages from any
> address and any port.
First of all you know what IP addresses you are peering with, so that 
wouldn't work anyway. I assume that you are talking about the peer 
acting as a client so if it's a replay attack it wouldn't work as the 
peer acting as a client has already received the packet so it would 
discard the replay packet.
> If you restrict a key to an address and port, the advantage of the
> ephemeral association over persistent association is lost.
I'm not sure what you mean.
>   And if you
> specify the other peer on both ends, you can just as well use the
> client/server mode. It will double the NTP traffic, but it will be
> more secure.

No, that's not true. Symmetric peer mode uses the same number of packets 
as client/server and as I said above it's no more vulnerable than 
client/server.

Danny