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

Heiko Gerstung <> Mon, 08 March 2021 16:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49F013A2D3A for <>; Mon, 8 Mar 2021 08:23:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xxkM7_WjKkql for <>; Mon, 8 Mar 2021 08:23:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE99F3A2D3C for <>; Mon, 8 Mar 2021 08:23:48 -0800 (PST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 3645F71C11C2; Mon, 8 Mar 2021 17:23:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1615220625; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=k+QuvXSTNj5I0P1AZ6B/V3xpZ0SeGLSt+XhrTSCTBDc=; b=GYHdat+B90ynDOEOiMVn6aRoqDq1hxETJSsTpc+IsyCjakEzii4kSJdyThRY6lx7duxUtH mVyXow5dpoC81TnlwYXb0z7l9TY66oNeYxiRhQ6dXL/OdPlrbAHpQ2r6wfxOkz7OJe1aHd poE9DyUcJJUF3o+jD4Vdn/aw4BJR0NrAjmENW1NNz63s6gGhw5zeSFEXfE4yjwTUhFbTvQ qO49C1BQvX7yhQt2YarvBEWwYnCz8IWDhg46EmVmpwY4yWMpKfGcA0EiK0JcY3bT9wBqup VCXHyev6Tm41GQnE8NlvPGogw3e/ski5kQ6cXqwNt6QfumYWOQ15rWnYbDzRpg==
Received: from ( []) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Mon, 8 Mar 2021 17:23:44 +0100 (CET)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.46.21021202
Date: Mon, 8 Mar 2021 17:23:42 +0100
Message-ID: <>
Thread-Topic: [Ntp] Comments on draft-langer-ntp-nts-for-ptp
References: <> <> <> <YEYHHhIrYv4ZhTkl@localhost> <> <YEYhUyx1r6aAO1Xi@localhost> <> <YEZKAbw2xc2yvDis@localhost>
In-Reply-To: <YEZKAbw2xc2yvDis@localhost>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+NmUxZmZlYTJhY2NhZTU2Mg==
From: Heiko Gerstung <>
To: Miroslav Lichvar <>
Cc: Watson Ladd <>, NTP WG <>, "Langer, Martin" <>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----8711576E8664E6E1507DB889000C41F8"
Archived-At: <>
Subject: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Mar 2021 16:23:51 -0000

Hi Miroslav,

I agree that an expiration date inside the cookie would not help and it would still be an attack vector before it expires.

I would see a chance to avoid replay attacks by using the Sequence Id of the unicast negotiation messages and store this Id in the same space where we store the active subscription datat (i.e. how many packets of which type to which sender for how long) and make sure that I store this "last used sequence id for this client" together with that subscription data. A client then needs to ensure that it always uses a higher sequency id when sending signal messages (e.g. when either canceling a subscription or requesting a new one) in the future. The server would have to store the client/last_seq_id_used/C2S_KEY data even after the subscription got canceled or expired and there was no renewal. For how long this information needs to be stored is probably something to investigate. This is only a problem if a client never comes back and the unicast GM could simply delete all those outdated entries in its database when its master key rotated twice. 

As soon as that client renews its subscription using the same C2S_KEY and a higher sequence Id, the last_seq_id_used will be updated on the server side (together with the updated subscription data). 

If the client crashes and does not know anything about the last_seq_id_used of its former self or in the case it starts for the very first time and there is no last_seq_id_used on the server for it, that should not be a problem because such a client would (re)run NTS-KE and obtain a new C2S_KEY in the process. When it subscribes to the unicast GM afterwards, an existing record will be overwritten because of the new C2S_KEY and the last_seq_id_used will be reset to the seq_id of this new unicast transmission request. If there is no record for this client, one will be created. 

Best Regards,

Heiko Gerstung 
Managing Director 
MEINBERG® Funkuhren GmbH & Co. KG 
Lange Wand 9 
D-31812 Bad Pyrmont, Germany 
Phone: +49 (0)5281 9309-404 
Fax: +49 (0)5281 9309-9404 
Amtsgericht Hannover 17HRA 100322 
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 
Do not miss our Time Synchronization Blog:
Connect via LinkedIn:

Am 08.03.21, 17:00 schrieb "Miroslav Lichvar" <>:

    On Mon, Mar 08, 2021 at 02:31:04PM +0100, Heiko Gerstung wrote:
    > >    If you don't have any client-specific state on the server (and
    > >    hardcode the address in the cookie), how do you prevent replay
    > >    attacks, e.g. canceling a previous request, or changing the message
    > >    rate to a previous value, or requesting unicast transmissions for
    > >    clients that no longer exist to cause a DoS attack on the server?
    > Not sure what you mean with "hardcode the address in the cookie", 

    That the client's address is included in the cookie to prevent
    replaying from other addresses.

    > but in order to change the message rate or cancel a unicast transmission, an NTS4PTP client would have to present a valid cookie. Replay attacks could be prevented by adding an expiration field into the cookie after which a GM will not accept it anymore. 

    I don't see how could that work.

    How would the server know when will be the cookie used? Even if it had
    only one cookie, it could be used at any time, e.g. to cancel the
    grant when it is shutting down. If it was started soon again, that
    cookie which authenticated the cancelation request would still be

    Miroslav Lichvar