[Ntp] NTS4UPTP Draft

[Heiko Gerstung <[e-mail]>]

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:

https://datatracker.ietf.org/doc/draft-gerstung-nts4uptp/

 

Best Regards,  

    Heiko

 

 


-- 

Heiko Gerstung 

Managing Director 

 

MEINBERG® Funkuhren GmbH & Co. KG 

Lange Wand 9 

D-31812 Bad Pyrmont, Germany 

Phone: [phone] 

Fax: [phone] 

 

Amtsgericht Hannover 17HRA 100322 

Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 

 

Email: 

[e-mail]

Web: 

Deutsch https://www.meinberg.de

English https://www.meinbergglobal.com

 

Do not miss our Time Synchronization Blog: 

https://blog.meinbergglobal.com

 

Connect via LinkedIn: 

https://www.linkedin.com/in/heikogerstung