Network Time Security for the Unicast Mode of the Precision Time Protocol
draft-gerstung-nts4uptp-03

Document Type Active Internet-Draft (ntp WG)
Authors Heiko Gerstung  , Marius Rohde  , Doug Arnold 
Last updated 2021-06-11 (latest revision 2021-06-04)
Stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream WG state Candidate for WG Adoption
On Agenda ntp at IETF-111
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
NTP WG                                                       H. Gerstung
Internet-Draft                                                  M. Rohde
Intended status: Standards Track                               D. Arnold
Expires: 6 December 2021                                        Meinberg
                                                             4 June 2021

    Network Time Security for the Unicast Mode of the Precision Time
                                Protocol
                       draft-gerstung-nts4uptp-03

Abstract

   This memo specifies the application of Network Time Security, a
   mechanism for using Transport Layer Security (TLS) and Authenticated
   Encryption with Associated Data (AEAD) to provide cryptographic
   security for the unicast mode of the Precision Time Protocol.

   It is based on the 'Network Time Security for the Network Time
   Protocol' document RFC8915 and re-uses most of its mechanisms for
   providing a secure and robust key exchange solution for unicast PTP.
   Due to the different modes of operation, additional steps are
   required to secure unicast PTP communication between the PTP clients
   and unicast PTP servers.  In addition to defining the new record
   types and other required values to allow the utilization of the NTS
   key exchange sub protocol, there are a number of additional protocol
   enhancements and server-side requirements which are defined in this
   memo.

NOTE

   This document is work in progress

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Gerstung, et al.         Expires 6 December 2021                [Page 1]
Internet-Draft                  NTS4UPTP                       June 2021

   This Internet-Draft will expire on 6 December 2021.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Objectives  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Application of the NTS protocol to PTP  . . . . . . . . . . .   4
     3.1.  Phase 1: NTS-KE Phase . . . . . . . . . . . . . . . . . .   7
     3.2.  Phase 2: PTP Unicast Transmission Negotiation Phase . . .   7
     3.3.  Phase 3: PTP Unicast Packet Transmission Phase  . . . . .  12
   4.  New NTS record types  . . . . . . . . . . . . . . . . . . . .  13
     4.1.  Cookie for Unicast PTP  . . . . . . . . . . . . . . . . .  13
     4.2.  Unicast PTP Server Negotiation  . . . . . . . . . . . . .  13
   5.  The PTP client Table  . . . . . . . . . . . . . . . . . . . .  14
   6.  The NTS_TLV . . . . . . . . . . . . . . . . . . . . . . . . .  14
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
     8.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  17
     8.2.  General Security Features . . . . . . . . . . . . . . . .  18
   9.  Delay Attacks . . . . . . . . . . . . . . . . . . . . . . . .  19
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     11.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

Gerstung, et al.         Expires 6 December 2021                [Page 2]
Internet-Draft                  NTS4UPTP                       June 2021

1.  Introduction

   This memo specifies Network Time Security for unicast mode of the
   Precision Time Protocol (PTP).  It is based on [RFC8915] and applies
   the key exchange mechanism described there to PTP.  The Precision
   Time Protocol is standardized in [IEEE1588] and offers a number of
   different modes and mappings to communication protocols.  The
   security mechanisms described here provide a way to secure the
   unicast mode of PTP as specified in sub clause 16.1 of [IEEE1588].

   The PTP integrated security mechanism has been specified in sub
   clause 16.14 of [IEEE1588] and introduces an AUTHENTICATION TLV that
   carries all necessary information to enable the receiver of a PTP
   message to verify its integrity.  Although two different approaches
   are described in that sub clause (immediate and delayed security
   processing), NTS4UPTP only uses the immediate security processing.

   In addition to sub clause 16.14, Annex P of [IEEE1588] provides
   additional explanation and description of PTP security.  It is stated
   there that for key management it is assumed that a separate mechanism
   outside the context of PTP is used.  In P.2.1.2 the document clearly
   states that this assumption was made in relation to the security
   mechanism described in 16.14 and it goes on to discuss some Key
   management options and it names both manual and automatic key
   management as possible approaches.

   This memo describes a way to use the automatic key exchange mechanism
   as defined in [RFC8915] as the key management for unicast PTP.  The
   NTS-KE protocol has clearly been designed to support using it for
   multiple time synchronization protocols and this document is
   utilizing this support.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Objectives

   The objectives of NTS are defined in [RFC8915] and, with some
   exceptions, apply to NTS4UPTP as well.

   *  Identity: Through the use of a X.509 public key infrastructure,
      implementations can cryptographically establish the identity of
      the parties they are communicating with.

Gerstung, et al.         Expires 6 December 2021                [Page 3]
Internet-Draft                  NTS4UPTP                       June 2021

   *  Authentication: Implementations can cryptographically verify that
      any time synchronization packets are authentic, i.e., that they
      were produced by an identified party and have not been modified in
      transit.

   *  Replay prevention: clients and servers can detect when a received
      packet is a replay of a previous packet.

   *  Request-response consistency: clients can verify that a unicast
      PTP packet received from a server was sent in response to a
      particular request from the client.

   *  Non-amplification: Implementations (especially server
      implementations) can avoid acting as distributed denial-of-service
      (DDoS) amplifiers by never responding to a packet with one or more
      packets creating more traffic than the initiating packet.

   *  Scalability: Server implementations can serve large numbers of
      clients.

   *  Performance: NTS must not significantly degrade the quality of the
      time transfer.  The encryption and authentication used when
      actually transferring time should be lightweight.

   The following objectives of [RFC8915] are not met in this proposal:

   *  Confidentiality: Basic time synchronization data is considered
      nonconfidential and sent in the clear.  Despite this, NTS4NTP
      includes support for encrypting NTP extension fields.  NTS4UPTP
      does not offer this kind of support as it is not considered useful
      or required for unicast PTP implementations.

   *  Unlinkability: For mobile clients, NTS4NTP does not leak any
      information additional to NTP which would permit a passive
      adversary to determine that two packets sent over different
      networks came from the same client.  This objection cannot be
      achieved by unicast PTP because the protocol requires the server
      to keep a state for all its clients.  It is also not considered a
      requirement in most applications where unicast PTP is deployed.

3.  Application of the NTS protocol to PTP

   Unlike NTP [RFC5905] which uses a request-response communication
   approach, the unicast mode of PTP is applying a subscription based
   model.  Although [IEEE1588] allows unicast operation without
   negotiation this is rarely used.  For this reason only unicast PTP
   with negotiation is considered.  A PTP client (PTP Ordinary Clock, or
   synchronizing port of a PTP unicast Boundary Clock) sends a request

Gerstung, et al.         Expires 6 December 2021                [Page 4]
Internet-Draft                  NTS4UPTP                       June 2021

   for the transmission of packets to a PTP instance offering such a
   service.  This could be a PTP unicast Grandmaster instance or a PTP
   boundary clock.  Note that [IEEE1588] allows PTP Ports in a states
   other than master to accept unicast message grant requests and act as
   a unicast PTP master.  This option can be used for monitoring
   purposes.  In this memo we treat all unicast associations in the same
   way regardless of whether it is for purposes of time transfer or
   monitoring, and refer to the port that grants message contracts as a
   PTP server.

   A PTP server that receives a message grant request will then either
   accept the request or deny it, for example based on capacity
   considerations or its own operational state.  This sub protocol of
   IEEE 1588 is called unicast message negotiation, an optional feature
   defined in sub clause 16.1 of [IEEE1588].  Both the PTP client and
   the PTP server granting a request can cancel a subscription (referred
   to as contract in PTP) after it has been granted and each contract
   includes a duration after which the PTP instance stops sending
   packets automatically if the PTP client did not request a new
   contract before the old contract ended.

   This results in a 3-phase approach for PTP:

   *  Phase 1: NTS-KE Phase (Section 3.1)

   *  Phase 2: PTP Unicast Transmission Negotiation Phase (Section 3.2)

   *  Phase 3: PTP Unicast Packet Transmission Phase (Section 3.3)

   In a typical use-case, phase 1 is required to be performed at
   startup.  In phase 2 the PTP client and the PTP server will negotiate
   the transmission of PTP messages which will then be delivered by the
   PTP server in phase 3.  Whenever phase 3 ends, the PTP client must
   re-run phase 2 to re-request more packets.  Typically, PTP clients
   will re-run phase 2 before the active contract ends, i.e. they
   request a new transmission contract from the PTP server with a new
   duration before the active contract expires in order to secure a
   continuous flow of messages from the PTP server.

Gerstung, et al.         Expires 6 December 2021                [Page 5]
Internet-Draft                  NTS4UPTP                       June 2021

               NTS4UPTP Protocol Overview
                                                 +--------------+
                                                 |              |
                                             +-> | PTP server 1 |
                                             |   |              |
                      Shared cookie          |   +--------------+
   +---------------+  encryption parameters  |   +--------------+
   |               |                         |   |              |
   | NTS-KE Server | <-----------------------+-> | PTP server 2 |
   |               |                         |   |              |
   +---------------+                         |   +--------------+
        ^                                    |          .
        |                                    |          .
        | 1. Negotiate parameters,           |          .
        |    receive initial cookie,         |   +--------------+
        |    generate AEAD keys,             |   |              |
        |    and receive PTP server IP       +-> | PTP server N |
        |    addresses using "NTS Key            |              |
        |    Establishment" protocol.            +--------------+
        |                                              ^  ^
        |                                              |  |
        |                                              |  |
        |               2. Perform authenticated       |  |
        |                  unicast message negotiation |  |
        |                  using the MAC function of   |  |
        |                  the AEAD to calculate the   |  |
        |                  ICV in the                  |  |
        |                  AUTHENTICATION_TLV using    |  |
        |                  the S2C/C2S keys            |  |
        |                                              |  |
        |             +----------+                     |  |
        |             |  PTP     |                     |  |
        +-----------> |  Client  | <-------------------+  |
                      |          | <----------------------+
                      +----------+
                            3. PTP server sends unicast messages
                               as negotiated with PTP client using
                               the MAC function of the AEAD to
                               calculate the ICV in the
                               AUTHENTICATION_TLV using the S2C key;
                               Client sends DELAY_REQ messages using the
                               C2S key for the ICV

         Figure 1: Overview of High-Level Interactions in NTS4UPTP

   Phase 1 only needs to be re-run to avoid that the key lifetime
   expires, the PTP server stops responding or does not accept the
   cookie presented by the PTP client for any reasons.

Gerstung, et al.         Expires 6 December 2021                [Page 6]
Internet-Draft                  NTS4UPTP                       June 2021

3.1.  Phase 1: NTS-KE Phase

   In the NTS-KE Phase (Phase 1), the PTP client connects to the NTS-KE
   server via a secure TLS channel.  Two keys are generated based on the
   TLS data exchange, referred to as Server-to-Client key (S2C key) and
   Client-to-Server key (C2S key).  The NTS-KE server creates a cookie
   for the PTP client, which contains those two keys, the AEAD algorithm
   used and a Nonce.  The cookie is secured by encrypting this
   information with a master key K.  The master key is generated by a
   PTP server and sent to the KE server via a proprietary mechanism.
   The client therefore cannot decrypt a cookie as it does not know the
   master key.  After receiving the cookies and establishing the C2S and
   S2C keys, the TLS connection is closed.  This is identical to the
   NTS-KE phase as defined in [RFC8915] with the exception that the NTS-
   KE record type "next-protocol" points to PTP instead of NTP and two
   new NTS record types are introduced:

   *  "Cookie for Unicast PTP" provides the client with the cookie
      required to establish a valid NTS connection with the PTP server.
      This NTS record type is defined in Section 4.1.

   *  "PTP server Negotiation" tells the client which PTP server it MUST
      use.  This NTS record type is defined in Section 4.2.

   The MAC function of the AEAD algorithm will be used to create/
   calculate the ICV in the AUTHENTICATION_TLV as defined in subclause
   16.14 of [IEEE1588] (Integrated PTP Security).

   For providing the cookie, an NTS-KE server MUST use a new NTS record
   type (New Cookie for Unicast PTP), which is identical to the NTS
   record type 5 (New Cookie for NTPv4) as described in [RFC8915].

   The S2C key will be used in Phase 2 and 3 to calculate the ICV of the
   AUTHENTICATION_TLV for all PTP messages sent from the PTP server to
   the PTP client.  The C2S key will be used in Phase 2 and 3 to
   calculate the ICV of the AUTHENTICATION_TLV for all PTP messages sent
   from the PTP client to the PTP server.

   After the PTP client successfully completed Phase 1, it can enter
   Phase 2 by initiating the PTP unicast negotiation with the provided
   PTP server.

3.2.  Phase 2: PTP Unicast Transmission Negotiation Phase

   A unicast PTP client needs to establish a contract with a PTP server
   if it wants to receive SYNC and ANNOUNCE messages and to perform
   delay measurements by sending DELAY_REQ messages to the PTP server,
   which responds with DELAY_RESP messages.

Gerstung, et al.         Expires 6 December 2021                [Page 7]
Internet-Draft                  NTS4UPTP                       June 2021

   The mechanism to establish these contracts between PTP client and PTP
   server is described in subclause 16.1 of [IEEE1588] ("Unicast message
   negotiation").  The basic concept requires the PTP client to send a
   request for each specific message type to transmit that message at a
   specific rate for a specific duration.  The PTP server either grants
   the request or rejects it (for example due to capacity constraints).
   Each message type requires its own contract between a PTP client and
   a PTP server and there can only be one active contract per message
   type between the two nodes.

   According to [IEEE1588] PTP messages can be extended by adding one or
   more TLVs on the end of the PTP message, and [IEEE1588] defines a
   number of TLVs.  Here TLV stands for type-length-value.  A standards
   development organization can also define TLVs to support
   specifications for extending PTP.  In this case the TLV will be
   "ORGANIZATION_EXTENSION_PROPAGATE" or
   "ORGANIZATION_EXTENSION_DO_NOT_PROPAGATE" depending on whether a PTP
   Boundary Clock shall pass the TLV on or not.  This kind of TLV MUST
   include a field for with the organizationID and a field with the
   organizationSubType.  The latter MUST be unique among PTP TLVs
   defined by that organization.

   The nature of unicast PTP requires that a PTP server maintains a list
   of PTP clients with active contracts.  For NTS4UPTP, a server needs
   to store additional data.  The storage entity required for storing
   the additional data is referred to as the PTPCLTABLE (Section 5) in
   this document.

   In order to secure the PTP unicast transmission negotiation, PTP
   clients and servers use cookies and nonces, and protect the integrity
   of the PTP signaling messages with the integrated security mechanism
   based on the AUTHENTICATION_TLV described in [IEEE1588].  A PTP
   client initially requires a cookie for the first message it sends
   during this phase and will receive a nonce each time the PTP server
   sends a response.  The initial cookie for the first request of the
   client is provided by the NTS-KE server in the NTS-KE Phase.  For
   each consecutive message the PTP client sends, it MUST use the nonce
   received in the previous message from the PTP server and send that
   one back in the NONCE field of the NTS_TLV.

   Due to the fact, that the S2C/C2S key pair expires, the client is
   forced to get new keys from the NTS-KE server.  The client MAY do
   this at any time and MUST do it when receiving a NTS_INVALIDKEYS
   response from the PTP server.

   Nonces and cookies are not required in the third phase, in which the
   transmitted PTP messages are only secured with the
   AUTHENTICATION_TLV.  Packet rates in this phase can be very high, PTP

Gerstung, et al.         Expires 6 December 2021                [Page 8]
Internet-Draft                  NTS4UPTP                       June 2021

   for example allows for up to 128 SYNC packets per second sent by the
   PTP server to a client.  Due to the fact that PTP requires a client
   to successfully complete the negotiation phase, it is sufficient to
   protect the integrity of the messages in the transmission phase with
   the AUTHENTICATION_TLV.

   The unicast negotiation mechanism as specified in [IEEE1588] is
   carried out according to the standard, but with the following
   addition:

   *  The PTP client and the PTP server MUST add an NTS TLV and an
      AUTHENTICATION_TLV to all signaling messages

   *  The NTS_TLV (Section 6) in a message sent from the PTP client to
      the PTP server either carries the cookie that the client obtained
      during the last successfully completed NTS-KE Phase, or the last
      nonce provided by the PTP server in its response.  Additionally
      the ntsMsgId MUST be set to NTS_INIT for the first message sent to
      the PTP server after completing the NTS-KE phase and to
      NTS_REQUEST for all further messages.

   *  The AUTHENTICATION_TLV secures the
      REQUEST_UNICAST_TRANSMISSION_TLV and the NTS_TLV with an ICV which
      is calculated based on the MAC function of the AEAD algorithm and
      the C2S key that has been obtained during the NTS-KE phase

   *  All signaling messages from the PTP server to the PTP client MUST
      carry a new nonce and the ICV in the AUTHENTICATION_TLV is
      calculated based on the S2C key that the PTP server read from the
      decrypted cookie in the last NTS_INIT message from the client.

   All PTP messages in the packet negotiation phase that do not carry an
   AUTHENTICATION_TLV or in which the ICV is not correct MUST be ignored
   by the recipient.

   A PTPCLTABLE entry SHALL be stored at least for as long as the S2C/
   C2S key pair is valid, i.e. until KEY_PAIR_EXP has been reached.  The
   maximum lifetime of a key pair is defined in the configuration of the
   PTP server and the expiration date/time is calculated when the entry
   in this PTP client state storage is created (Expiration date/
   time=creation time of PTPCLTABLE record plus configured maximum
   lifetime).  The PTP server SHOULD erase entries from this table after
   the expiration time of the key pair has been reached.

   The PTP server, after receiving a signaling message, will perform the
   following steps:

Gerstung, et al.         Expires 6 December 2021                [Page 9]
Internet-Draft                  NTS4UPTP                       June 2021

   *  if the request contains an NTS_TLV with ntsMsgId == NTS_INIT, it
      decrypts the cookie with its master key K to obtain the two C2S
      and S2C keys, for all other ntsMsgId values it MUST perform a
      lookup into the PTPCLTABLE

   *  if the request contains an NTS_TLV with ntsMsgId == NTS_REQUEST,
      the nonce used in this signaling message is identical to the
      NEXT_NONCE stored for this client in the PTPCLTABLE

   *  if the request contains an NTS_TLV with ntsMsgId ==
      NTS_CHALLENGE_REQUEST, CHALLENGE_EXP has not been reached and the
      cookie used in this signaling message is identical to the
      CHALLENGE_NONCE stored for this client

   *  If either the cookie cannot be decrypted, no matching entry could
      be found in the PTPCLTABLE, the nonce does not match the
      NEXT_NONCE or the CHALLENGE_NONCE, the message MUST be ignored.
      In all other cases, the following additional checks MUST be
      performed:

      -  the ICV in the AUTHENTICATION_TLV is correct (using the C2S key
         from the provided cookie or from the matching entry in the
         PTPCLTABLE

      -  the key expiration date/time has not been reached

      If the CHALLENGE_NONCE check fails (only applicable when the
      ntsMsgId in the received message is NTS_CHALLENGE_RESPONSE), the
      message MUST be ignored.

      If the key expiration check fails, the request is denied and, by
      setting the key lifetime field of the NTS_TLV in the response to 0
      and the ntsMsgId to NTS_INVALIDKEYS, the client is told to obtain
      new keys and a new cookie from a NTS-KE server before it can
      establish a new contract with this PTP server.

   If no matching entry exists in the PTPCLTABLE, or if the checks above
   result require an NTS_CHALLENGE_REQUEST response, any active contract
   (if there is one) MUST NOT be changed, canceled or otherwise
   modified.  This is to avoid that an attacker sends an invalid request
   which stops the currently active contract and therefore successfully
   carries out a denial-of-service attack.

   When a PTP server receives a NTS_INIT message with a valid cookie,
   the following challenge/response procedure MUST be followed:

Gerstung, et al.         Expires 6 December 2021               [Page 10]
Internet-Draft                  NTS4UPTP                       June 2021

   *  The PTP server will deny the REQUEST_UNICAST_TRANSMISSION_TLV
      request and responds with an NTS_MessageId NTS_CHALLENGE_REQUEST
      and a nonce which it stores as the CHALLENGE_NONCE in the
      PTPCLTABLE.  The server will put the sequenceId from the PTP
      packet header of the request into the reqSeqId field of the
      NTS_TLV

   *  The client, after receiving the response with the
      NTS_CHALLENGE_REQUEST message ID SHALL check that the reqSeqId is
      identical to the sequenceId of the request it sent to the server.
      If this fails, the message MUST be ignored by the client.

   *  If the reqSeqId check is successful, the client resends the
      REQUEST_UNICAST_TRANSMISSION_TLV using a ntsMsgId of
      NTS_CHALLENGE_RESPONSE and MUST use the cookie it received with
      the NTS_CHALLENGE_REQUEST response.

   *  The server then checks that the cookie presented by the client in
      the NTS_CHALLENGE_RESPONSE response is identical to the
      CHALLENGE_NONCE.  If that is true, the client can be trusted and
      the REQUEST_UNICAST_TRANSMISSION_TLV included in this response is
      considered to be a valid and trusted request.

   After the successful verification of the request, the
   REQUEST_UNICAST_TRANSMISSION_TLV is processed according to
   [IEEE1588].

   In case the PTP server grants the request to the client, the process
   moves on to the 3rd phase, the packet transmission phase.  If the PTP
   server denies the request for whatever reason (i.e. it has no
   capacity or its state does not allow to reliably transmit the packets
   at the requested rate), it sends a unicast grant denial message, i.e.
   a PTP signaling message carrying a GRANT_UNICAST_TRANSMISSION TLV
   with the grant duration set to zero.

   If a PTP client receives a GRANT_UNICAST_TRANSMISSION_TLV containing
   an NTS_TLV with a correct ICV and a key lifetime set to 0, it MUST
   delete all cookies it holds for that PTP server as well as the S2C/
   C2S key pair and cease all communication until it re-ran phase 1 and
   obtained a new key pair and a new cookie.

Gerstung, et al.         Expires 6 December 2021               [Page 11]
Internet-Draft                  NTS4UPTP                       June 2021

   Using the "maximum key lifetime" configuration parameter, a PTP
   server operator can prioritize memory requirements and required
   network traffic volume.  A small maximum lifetime value results in
   PTPCLTABLE entries being deleted earlier, requiring more
   NTS_CHALLENGE_REQUEST exchanges between PTP client and PTP server.  A
   large value may result in requiring fewer such packet exchanges but
   increases the memory consumption because PTPCLTABLE entries have to
   be stored for a longer period of time.

3.3.  Phase 3: PTP Unicast Packet Transmission Phase

   When the transmission request has been granted by the PTP server for
   a specific messagetype/duration, for all messagetypes except delay
   responses the GM immediately starts transmitting the messages in the
   requested rate.  DELAY_RESP messages will be sent after the client
   sent a DELAY_REQ message.

   All unicast PTP messages sent by the PTP server to the PTP client due
   to an active contract SHALL be secured by an AUTHENTICATION_TLV that
   carries an ICV as described in [IEEE1588], subclause 16.14 (PTP
   Integrated Security).  The ICV is created using the MAC function of
   the AEAD algorithm and the S2C key established between the PTP client
   and the NTS-KE server during the NTS-KE phase.  All messages sent by
   the PTP client to the PTP server will be secured with the same
   mechanism, but using the C2S key.

   All PTP messages in the packet transmission phase that do not carry
   an AUTHENTICATION_TLV or in which the ICV is not correct MUST be
   ignored by the recipient.

   In order to establish a protection against replay attacks in this
   phase, both the PTP client and the PTP server MUST check that the
   sequenceId of an incoming message is larger than the sequenceId of
   the same PTP message type received in the previous message.  If an
   incoming message does not pass the sequenceId check, it MUST be
   ignored.  Both PTP client and PTP server SHOULD allow to configure
   the maximum difference between the sequenceId values of two
   consecutive messages of the same message type.  They MUST gracefully
   handle the rollover of a sequenceId, which is a unsigned int16 value
   (0-65535).

   To avoid that an attacker resends a PTP message with a sequenceId
   that has been obtained before the last rollover, additional integrity
   checks SHOULD be applied.  The maximum packet rate is 128 packets/
   second.  Therefore, for each PTP message type sent at the maximum
   rate, the sequenceId rollover happens every 512 seconds (8 minutes,
   32 seconds) as a minimum.  For SYNC, DELAY_REQ and ANNOUNCE messages
   the recipient SHOULD check that the originTimestamp in the packet

Gerstung, et al.         Expires 6 December 2021               [Page 12]
Internet-Draft                  NTS4UPTP                       June 2021

   does not differ more than 8 minutes from the originTimestamp of the
   previously received message.  For DELAY_RESP messages, the
   receiveTimestamp SHOULD be used instead.

   The packet transmission phase ends either when the contract expired
   or when either the PTP server or the PTP client cancels the contract.

4.  New NTS record types

4.1.  Cookie for Unicast PTP

   The content of this NTS record is identical to record type 5 as
   defined in 4.1.6 of [RFC8915].  However, a NTS-KE server MUST send
   exactly one record of this type when PTP is negotiated as a next
   protocol.

4.2.  Unicast PTP Server Negotiation

   The PTP server Negotiation record has a Record Type number of 8.  Its
   body consists of an ASCII-encoded [RFC0020] string.  The contents of
   the string SHALL be either an IPv4 address, an IPv6 address, or a
   fully qualified domain name (FQDN).  IPv4 addresses MUST be in dotted
   decimal notation.  IPv6 addresses MUST conform to the "Text
   Representation of Addresses" as specified in RFC 4291 [RFC4291] and
   MUST NOT include [RFC6874].  If a label contains at least one non-
   ASCII character, it is an internationalized domain name, and an
   A-LABEL MUST be used as defined in Section 2.3.2.1 of RFC 5890
   [RFC5890].  If the record contains a domain name, the recipient MUST
   treat it as a FQDN, e.g., by making sure it ends with a dot.

   When PTP is negotiated as a Next Protocol and this record is sent by
   the server, the body specifies the hostname or IP address of the PTP
   unicast server with which the client MUST associate and that will
   accept the supplied cookies.  If no record of this type is sent, the
   client SHALL interpret this as a directive to associate with a PTP
   server at the same IP address as the NTS-KE server.  Servers MUST NOT
   send more than one record of this type.  If the record contains a
   FQDN which resolves to multiple addresses, the client MUST choose at
   least one of the addresses the FQDN resolves to.  The client MAY
   choose to use more than one address to request synchronization
   services from multiple unicast PTP servers in parallel.

   When this record is sent by the client, it indicates that the client
   wishes to associate with the specified PTP server.  The NTS-KE server
   MAY incorporate this request when deciding which PTP server
   Negotiation records to respond with, but honoring the client's
   preference is OPTIONAL.  The client MUST NOT send more than one
   record of this type.

Gerstung, et al.         Expires 6 December 2021               [Page 13]
Internet-Draft                  NTS4UPTP                       June 2021

   If the client has sent a record of this type, the NTS-KE server
   SHOULD reply with the same record if it is valid and the server is
   able to supply cookies for it.  If the client has not sent any record
   of this type, the NTS-KE server SHOULD respond with either an PTP
   server address in the same family as the NTS-KE session or a FQDN
   that can be resolved to an address in that family, if such
   alternatives are available.

   Servers MAY set the Critical Bit on records of this type; clients
   SHOULD NOT.

5.  The PTP client Table

   The PTP server MUST store the following data for each PTP client in a
   NTS PTP client Table (PTPCLTABLE):

   *  the S2C/C2S key pair

   *  the time when the validity of this key pair expires (KEY_PAIR_EXP)

   *  the next nonce to be expected from the client (NEXT_NONCE)

   *  the nonce to be expected from the client in a
      NTS_CHALLENGE_RESPONSE message (CHALLENGE_NONCE)

   *  the time when the validity of the CHALLENGE_NONCE expires
      (CHALLENGE_EXP)

6.  The NTS_TLV

   The NTS_TLV contains:

   1.   tlvType: ORGANIZATION_EXTENSION_DO_NOT_PROPAGATE (8000 hex)

   2.   lengthField: number of octets in the value + 6

   3.   organizationID: IETF (=00005E hex)

   4.   organizationSubtype: TBD (needs to be assigned)

   5.   ntsMsgId: NTS Message Id (see below)

   6.   networkProtocol: Transport type (0x01=IPv4, 0x02=IPv6,
        0x03=Ethernet), unsigned int

   7.   tSrcAddr: Transport source address of the sender, e.g. the IP
        address or Ethernet MAC address, 16 octets

Gerstung, et al.         Expires 6 December 2021               [Page 14]
Internet-Draft                  NTS4UPTP                       June 2021

   8.   keyLifetime: Key Lifetime in seconds, unsigned int32

   9.   reqSeqId: sequenceId of the request, unsigned int16

   10.  nonce/cookie: a nonce or, if ntsMsgId == NTS_INIT, an NTS Cookie

   +---------------------------------------+--------+------------+
   |         Bits                          | Octets | TLV Offset |
   +----+----+----+----+----+----+----+----+        |            |
   | 0  | 1  | 2  | 3  | 4  | 5  | 6  | 7  |        |            |
   +----+----+----+----+----+----+----+----+--------+------------+
   |                    tlvType            |    2   |      0     |
   +---------------------------------------+--------+------------+
   |                  lengthField          |    2   |      2     |
   +---------------------------------------+--------+------------+
   |                organizationId         |    3   |      4     |
   +---------------------------------------+--------+------------+
   |              organizationSubType      |    3   |      7     |
   +---------------------------------------+--------+------------+
   |                   ntsMsgId            |    1   |     10     |
   +---------------------------------------+--------+------------+
   |               networkProtocol         |    1   |     11     |
   +---------------------------------------+--------+------------+
   |                   tSrcAddr            |   16   |     12     |
   +---------------------------------------+--------+------------+
   |                  keyLifetime          |    4   |     28     |
   +---------------------------------------+--------+------------+
   |                   reqSeqId            |    2   |     32     |
   +---------------------------------------+--------+------------+
   |                 nonce/cookie          |    n   |     34     |
   +---------------------------------------+--------+------------+

                          Figure 2: NTS TLV Format

   The networkProtocol field allows to detect which transport protocol
   is in use and therefore how to interprete the tSrcAddr field.  For an
   Ethernet MAC address, the 6 first octets of the tSrcAddr field are
   relevant, for an IPv4 address the first 4 octets are relevant and for
   an IPv6 address the full 16 octets are relevant.  The enumeration is
   corresponding to the networkProtocol field as defined in [IEEE1588].

   Please note that the size of the cookie depends on the chosen AEAD,
   it can therefore differ and has been placed at the end of the TLV.
   The lengthField allows a receipient to calculate the length of the
   cookie.

   The ntsMsgId field MUST contain one of the following values:

Gerstung, et al.         Expires 6 December 2021               [Page 15]
Internet-Draft                  NTS4UPTP                       June 2021

   *  0x01 NTS_INIT (for the first unicast negotiation message sent by
      the PTP client to the PTP server after completing a NTS-KE Phase
      in which the PTP client obtained a new key pair)

   *  0x02 NTS_REQUEST (for unicast negotiation messages sent by the PTP
      client to the PTP server)

   *  0x03 NTS_RESPONSE (for unicast negotiation messages sent by the
      PTP server to the PTP client)

   *  0x04 NTS_CHALLENGE_REQUEST (for messages sent by the PTP server to
      the PTP client in case of a challenge/response procedure)

   *  0x05 NTS_CHALLENGE_RESPONSE (for messages sent by the PTP client
      to the PTP server as a resonse to a NTS_CHALLENGE_REQUEST)

   *  0x06 NTS_INVALIDKEYS (for messages sent by the PTP server to the
      PTP client when the S2C/C2S key pair expired or whenever the PTP
      server wants to force the PTP client to re-run the NTS-KE Phase)

   The reqSeqId field MUST be set to 0 for all messages except those
   with a NTS_CHALLENGE_REQUEST message Id.  In that specific case the
   field MUST contain the sequenceId of the message to which this
   NTS_CHALLENGE_REQUEST is a response.

   When sending a REQUEST_UNICAST_TRANSMISSION_TLV, the PTP client will
   add the NTS_TLV containing a cookie for this PTP server.  The key
   lifetime SHALL always be set to 0 for all communication from the PTP
   client to the PTP server.

   When sending a GRANT_UNICAST_TRANSMISSION_TLV, the PTP server will
   add the NTS_TLV as well.  If the request of the client is granted
   (duration > 0), the NTS_TLV will contain a new cookie and the key
   lifetime field SHALL represent the number of seconds the C2S and S2C
   keys continue to be valid.

   The PTP server SHALL set a key lifetime of 0 when the lifetime of the
   S2C/C2S key pair expired.  This allows the PTP server to force the
   client to re-start and obtain fresh keys and cookies from the NTS-KE
   server.  When sending an NTS_TLV with the key lifetime set to 0, the
   PTP server SHALL use the S2C key of the expired key pair to form the
   ICV in the AUTHENTICATION_TLV, allowing the client to verify that the
   message has been sent by the PTP server.

Gerstung, et al.         Expires 6 December 2021               [Page 16]
Internet-Draft                  NTS4UPTP                       June 2021

   When a client receives any message with a valid ICV but a key
   lifetime of 0 in the NTS_TLV, it SHALL delete all cookies cease to
   send any messages to the PTP server and only restores communication
   with it after it obtained a new S2C/C2S key pair and a new set of
   cookies from the NTS-KE server.

7.  IANA Considerations

   RFC EDITOR: A new entry for Unicast PTP is required in the IANA
   Network Time Security Next Protocols Registry.  The authors propose
   to add an entry with the Protocol ID = 1, the Protocol Name =
   "Unicast Precision Time Protocol" and a Reference to this draft.
   Please remove this comment before publishing and replace it with the
   data for the newly created entry from IANA.

8.  Security Considerations

8.1.  Threat Model

   The procedures and mechanisms described in this draft protect against
   the following scenarios:

   *  Man-in-the-Middle (MITM) attack: All PTP nodes can verify that PTP
      messages received from another PTP server have not been modified
      in transit by an attacker.  This is achieved by verifying that the
      ICV in the AUTHENTICATION_TLV of every PTP message received is
      valid and has been created using the MAC function of the AEAD
      algorithm and the C2S or S2C key as established during the NTS-KE
      phase.

   *  Phase 2 Replay Attack (resending unmodified PTP unicast
      negotiation messages): PTP message integrity can be secured with
      the AUTHENTICATION_TLV.  However, with PTP this mechanism does not
      protect the transport protocol header and could therefore be used
      by an attacker to intercept a PTP message and then resending it
      using the same or a different source address.  Or it could be
      resend at a later time to repeat a request or cancel an active
      contract.  Resending it with the same address can be used to try
      and establish a contract for a unicast PTP client that is no
      longer requiring the service, requires the service in a different
      form (e.g. different message rates) or it can be used to cancel a
      contract (when resending a CANCEL_UNICAST_TRANSMISSION_TLV after
      the client established a new contract).  This can interrupt a
      required service for a PTP client or result in the PTP server
      unnecessarily consuming resources.  By storing the nonce that has
      been provided by the server and that MUST be used by the client in
      its next request (NEXT_NONCE in PTPCLTABLE), an unmodified resent
      REQUEST_UNICAST_TRANSMISSION_TLV will not be granted, despite the

Gerstung, et al.         Expires 6 December 2021               [Page 17]
Internet-Draft                  NTS4UPTP                       June 2021

      fact that the ICV in the AUTHENTICATION_TLV is valid.  T o provide
      a robust defense against replaying NTS_INIT messages, the
      challenge/response mechanism (NTS_CHALLENGE_REQUEST/
      NTS_CHALLENGE_RESPONSE) will require a PTP client to apply the
      correct C2S key and therefore protects against replaying a
      previously sent valid message with a cookie that has been
      encrypted with a still valid master key K.

   *  Phase 3 Replay Attack (resending unmodified PTP unicast messages):
      In Phase 3 the PTP server is sending PTP SYNC and ANNOUNCE
      messages to the PTP client and the PTP client is sending DELAY_REQ
      messages to the PTP server, which responds with DELAY_RESP
      messages.  An attacker could resend any of these packets.  For
      SYNC messages, that would result in the PTP client receiving "old
      time", i.e. the timestamps in such a message would be outdated and
      could disrupt time synchronization of the PTP client.  A resent
      ANNOUNCE message could carry outdated information and therefore
      could force the PTP client to drop this server as a valid time
      source or distrupt the protocol in other ways.  Resending
      DELAY_REQ messages could consume resources on the PTP server and,
      if the server would send DELAY_RESP message, on the PTP client as
      well.  The client could also be negatively affected by resent
      DELAY_RESP messages that carry outdated time.  A valid protection
      against such an attack is checking the sequenceId of each incoming
      message and by applying additional integrity checks to messages
      passing the sequenceId checks.  See Section 3.3 for a detailed
      description of how this can be achieved.

   *  Amplification Attack/Distributed Denial of Service: Resending a
      REQUEST_UNICAST_TRANSMISSION_TLV with a different source IP
      address could result in the PTP server sending PTP messages to IP
      adresses that do not expect and require receiving these messages.
      Due to the nature of unicast PTP, the traffic amplification
      porential is very high because one PTP signaling message
      containing a REQUEST_UNICAST_TRANSMISSION_TLV can generate
      thousands of PTP messages from the PTP server to the source IP
      address used in the request message.  This is mitigated by
      including the IP address of the originator of a message as a field
      (tSrcAddr) in the NTS_TLV.  The TLV as part of the PTP message is
      protected by the ICV in the AUTHENTICATION_TLV and therefore a
      modified source address can be detected.

8.2.  General Security Features

   In addtion to the above outlined protection mechanisms against
   specific attack scenarios, this draft also includes a generic
   security feature:

Gerstung, et al.         Expires 6 December 2021               [Page 18]
Internet-Draft                  NTS4UPTP                       June 2021

   *  Key Freshness: The expiration of C2S/S2C key pairs requires
      clients to obtain a new key pair in a configurable interval, which
      limits the time an attacker has to break those keys.

9.  Delay Attacks

   If an attacker gains control over a part of the network
   infrastructure on the path between clients and server, it could be
   possible to delay the forwarding of unicast PTP messages without
   modifying them.  Applying such a delay only in one direction (e.g.
   for SYNC packets sent from the server to the client) would create an
   asymmetry in the delay calculation and as a result the error in the
   delay calculation would cause a timing error on the client.  This
   kind of attack cannot be mitigated by NTS4UPTP as the cryptographic
   protection only allows to ensure the integrity of messages, which is
   not corrupted by a delay attack.

   In addition to securing the network infrastructure (i.e. routers and
   switches) against this threat, another possible mitigation strategy
   for the client is to check the calculated delay against a static
   limit (which could be configurable by the user or is defined by the
   requirements of the application) or a dynamic limit, which the client
   could determine periodically for example by applying suitable
   statistical methods to determine a change in the calculated delay
   that indicates that the potential time error would exceed the sync
   requirements of the application.

10.  Acknowledgements

   The authors would like to thank the following contributors for their
   valuable feedback:

   *  Martin Langer, MSc and Prof. Dr.-Ing. Rainer Bermbach, Ostfalia
      University

11.  References

11.1.  Normative References

   [RFC0020]  Cerf, V., "ASCII format for network interchange", STD 80,
              RFC 20, DOI 10.17487/RFC0020, October 1969,
              <https://www.rfc-editor.org/info/rfc20>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Gerstung, et al.         Expires 6 December 2021               [Page 19]
Internet-Draft                  NTS4UPTP                       June 2021

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

   [RFC8915]  Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
              Sundblad, "Network Time Security for the Network Time
              Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
              <https://www.rfc-editor.org/info/rfc8915>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

   [RFC6874]  Carpenter, B., Cheshire, S., and R. Hinden, "Representing
              IPv6 Zone Identifiers in Address Literals and Uniform
              Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874,
              February 2013, <https://www.rfc-editor.org/info/rfc6874>.

11.2.  Informative References

   [IEEE1588] IEEE, "IEEE Std 1588-2019 Standard for a Precision Clock
              Synchronization Protocol for Networked Measurement and
              Control", IEEE Standard 1588, 2019,
              <https://standards.ieee.org/content/ieee-standards/en/
              standard/1588-2019.html>.

Authors' Addresses

   Heiko Gerstung
   Meinberg Funkuhren GmbH&Co.KG
   Lange Wand 9
   31812 Bad Pyrmont
   Germany

   Phone: +49 5281 9309 0
   Email: heiko.gerstung@meinberg.de
   URI:   http://www.meinbergglobal.com/

   Marius Rohde
   Meinberg Funkuhren GmbH&Co.KG
   Lange Wand 9

Gerstung, et al.         Expires 6 December 2021               [Page 20]
Internet-Draft                  NTS4UPTP                       June 2021

   31812 Bad Pyrmont
   Germany

   Phone: +49 5281 9309 0
   Email: marius.rohde@meinberg.de
   URI:   http://www.meinbergglobal.com/

   Douglas Arnold
   Meinberg USA Inc.
   100 Stony Point Road Suite 110
   Santa Rosa,  CA 95401
   United States of America

   Phone: +1 877-PTP-1588
   Email: doug.arnold@meinberg-usa.com
   URI:   http://www.meinbergglobal.com/

Gerstung, et al.         Expires 6 December 2021               [Page 21]