[Ntp] NTS4UPTP Draft

Heiko Gerstung <heiko.gerstung@meinberg.de> Wed, 05 May 2021 12:03 UTC

Return-Path: <heiko.gerstung@meinberg.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D99E03A1520 for <ntp@ietfa.amsl.com>; Wed, 5 May 2021 05:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Status: No, score=-4.398 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=meinberg.de
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wukQ14YZuyjU for <ntp@ietfa.amsl.com>; Wed, 5 May 2021 05:03:06 -0700 (PDT)
Received: from server1a.meinberg.de (server1a.meinberg.de []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40ADC3A14DD for <ntp@ietf.org>; Wed, 5 May 2021 05:03:06 -0700 (PDT)
Received: from seppmail.py.meinberg.de (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id 5B95771C0CD4; Wed, 5 May 2021 14:03:04 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1620216184; 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; bh=evUJv5M3rIGG1JZ1TTrp2RZjg12TiWSOV3gOHAkAgTM=; b=UuMyRWiY0CaFYcMfNnJ6IB0uTN6MQywAPk7JhlRy6tP7zjcdE7e2w5C+KfyhDtQFyZkoJ8 voRZIsGLrrvpbTZnuYJK3hR0AfsOJ+LeZVvmyGGi90egW2x3IAgcEZRkn0ixz/Jt2wIHtJ TF0r/TvW5Io/5eIsxM/QVg0CXCNK1CmR9rJe+37C3OL5Td/mgmm26CIMHLDQu++ZqJpdQR VMzC6M7w87J/lOzwS9vDAMRMa8NFH8MKgyQd63AAyuBONWv3lbs5SVCQ7qSO541i+DCTtl gRK720AMbBiCyOA7BSEXJALGC/aSXZVJJYscCJ1oFTpwMh3XoZgFRVpI5Kfl4A==
Received: from srv-kerioconnect.py.meinberg.de (srv-kerioconnect.py.meinberg.de []) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by seppmail.py.meinberg.de (Postfix) with ESMTPS; Wed, 5 May 2021 14:03:03 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.48.21041102
Date: Wed, 5 May 2021 14:03:01 +0200
Message-ID: <8AD05B86-7D88-4C09-AEE4-4ABBFBCA167D@meinberg.de>
Thread-Topic: NTS4UPTP Draft
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+Nzc3YzJlM2FkNGYwMmM3ZQ==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: "ntp@ietf.org" <ntp@ietf.org>
Cc: Marius Rohde <marius.rohde@meinberg.de>, Doug Arnold <doug.arnold@meinberg-usa.com>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----649A8E25A82B7EE27E02EBF2F1588E61"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/LR8YDKdOHRjnTU0pkoL9NPm7DIU>
Subject: [Ntp] NTS4UPTP Draft
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, 05 May 2021 12:03:17 -0000

Hi All,


as announced a few weeks ago, I would like to propose an alternative approach to bringing NTS based security to PTP by starting with a standard that only covers unicast PTP only, allowing it to stay very close to the NTS4NTP standard (RFC8915) in the protocol used between the NTS-KE server and a client. Although I know that multicast PTP is by far the most prevalent version used in real world deployments today, I believe that the unicast mode allows to be secured more effectively and will probably gain ground when there is a way to protect it as described in our attached draft. 


Our draft is describing a 3-phase approach, with phase 1 being identical to the NTS-KE phase of RFC8915, except for three things:
it obviously works with a different next_protocol value
it introduces a new NTS-KE record type “PTP server negotiation” (and a record type for the initial cookie)
it always only provides one single cookie to the client

The second phase is the PTP unicast negotiation phase in which a PTP client requests a packet transmission for a specified period of time from a PTP server. In this phase, a cookie is only used for the first message, all further messages use nonces in the communication between the PTP server and the PTP client. The keys established in phase 1 (S2C and C2S) are used to calculate the ICV of the AUTHENTICATION_TLV for all PTP messages exchanged between client and server in this phase. The MAC function of the AEAD is used for calculating the ICV.


In the third phase, the PTP server sends packets with (typically) a high rate to the client for the requested/granted duration and the PTP client sends delay requests to the server (to which it responds with delay responses). All messages exchanged in this phase are only secured with the integrated PTP security mechanism, using the AUTHENTICATION_TLV with the ICV being calculated based on the MAC function of the AEAD and using the S2C key (for message sent by the server) and the C2S key (for messages sent by the client).


A challenge-response-like mechanism has been added to protect against replay attacks, i.e. a message resent by an attacker would trigger a challenge to be send and requires a valid response before changing/interrupting/canceling or creating a new contract between the PTP client and the server. This is only used for the initial message which carries the cookie. All further messages between PTP client and server will be protected against replay attacks by the nonce, which the server puts in its message to the client and which the client has to send back in the following message. 


It also provides protection for the transport layer. The reason for this is that the AUTHENTICATION_TLV and its ICV do not cover the transport header (e.g. you can easily resend a packet from a different IP address). 


Doug promised to create an overview of the architecture and concepts of this draft, he will post that as soon as possible. If you do not have the time to read the draft, just wait for his “executive summary”. 


I am very much looking forward to feedback and comments and discussions. 


The draft has been posted and is available from here:



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 





Deutsch https://www.meinberg.de

English https://www.meinbergglobal.com


Do not miss our Time Synchronization Blog: 



Connect via LinkedIn: