Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

Hal Murray <hmurray@megapathdsl.net> Mon, 08 March 2021 11:53 UTC

Return-Path: <hmurray@megapathdsl.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 3B4EF3A0C5B for <ntp@ietfa.amsl.com>; Mon, 8 Mar 2021 03:53:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.137
X-Spam-Level: *
X-Spam-Status: No, score=1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HDRS_LCASE=0.1, HELO_DYNAMIC_IPADDR=1.951, RCVD_IN_DNSWL_BLOCKED=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 f6F4xeDp8Jbe for <ntp@ietfa.amsl.com>; Mon, 8 Mar 2021 03:53:54 -0800 (PST)
Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id AB7303A0C49 for <ntp@ietf.org>; Mon, 8 Mar 2021 03:53:54 -0800 (PST)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 64D4E40605C; Mon, 8 Mar 2021 03:53:53 -0800 (PST)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: Heiko Gerstung <heiko.gerstung=40meinberg.de@dmarc.ietf.org>
cc: Hal Murray <hmurray@megapathdsl.net>, NTP WG <ntp@ietf.org>
From: Hal Murray <hmurray@megapathdsl.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 08 Mar 2021 03:53:53 -0800
Message-Id: <20210308115353.64D4E40605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/SngMZw2I2N0LQov-fiPoqsMtEGM>
Subject: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp
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: Mon, 08 Mar 2021 11:53:56 -0000

heiko.gerstung=40meinberg.de@dmarc.ietf.org said:
> The question is how often we need to change the S2C and C2S keys to avoid
> that some MITM gets enough time to break the keys before they change. As 
> far as I understood, those keys are part of the cookie and could change in
> every cookie. That would result in the NTS/PTP client to use a different
> key after every successful unicast negotiation... 

The S2C and C2S keys are in the cookie so the NTP server doesn't have to 
maintain any per-client state.  For NTP, they don't change without the client 
going back to the KE server.

The numbers are such that the MITM doesn't see enough traffic over the 
lifetime of a client to worry the crypto guys.

The keys in the cookie are encrypted with the NTP server's cookie-key.  That 
key gets used on all the traffic to the server.  That's a different set of 
MITM numbers.  The cookie-key gets rotated daily.

I know close to nothing about PTP.  If you are willing to have enough 
per-client state on the PTP server, there is no need to have cookies.

If your unicast traffic is periodic from the server rather than a response to 
a client request, then you need a counter or such to prevent replay attacks.

If your unicast traffic is high enough volume, then you need a re-keying 
mechanism to get a new S2C.


-- 
These are my opinions.  I hate spam.