Skip to main content

NTS4PTP - Key Management System for the Precision Time Protocol Based on the Network Time Security Protocol
draft-langer-ntp-nts-for-ptp-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Martin Langer , Rainer Bermbach
Last updated 2021-02-22
Replaced by draft-ietf-ntp-nts-for-ptp
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-langer-ntp-nts-for-ptp-00
Network Time Protocol                                          M. Langer
Internet-Draft                                               R. Bermbach
Intended status: Standards Track                     Ostfalia University
Expires: August 26, 2021                               February 22, 2021

NTS4PTP - Key Management System for the Precision Time Protocol Based on
                   the Network Time Security Protocol
                    draft-langer-ntp-nts-for-ptp-00

Abstract

   This document defines a key management service for automatic key
   management for the integrated security mechanism (Prong A) of IEEE
   Std 1588[TM]-2019 described there in Annex P.  It implements a key
   management for immediate security processing complementing the
   exemplary GDOI proposal in P.2.1.2.1.  The key management service is
   based on the "NTS Key Establishment" protocol defined in IETF RFC
   8915 for securing NTP, but works completely independent from NTP.

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."

   This Internet-Draft will expire on August 26, 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

Langer & Bermbach        Expires August 26, 2021                [Page 1]
Internet-Draft                   NTS4PTP                   February 2021

   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.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   3
   2.  Key Management Using Network Time Security  . . . . . . . . .   3
     2.1.  Principle Key Distribution Mechanism  . . . . . . . . . .   5
       2.1.1.  NTS Message Exchange for Group-based Approach . . . .   7
       2.1.2.  NTS Message Exchange for the Ticket-based Approach  .   9
     2.2.  General Topics  . . . . . . . . . . . . . . . . . . . . .  12
       2.2.1.  Key Update Process  . . . . . . . . . . . . . . . . .  12
       2.2.2.  Key Generation  . . . . . . . . . . . . . . . . . . .  15
       2.2.3.  Time Information of the KE Server . . . . . . . . . .  16
       2.2.4.  Certificates  . . . . . . . . . . . . . . . . . . . .  16
       2.2.5.  Upfront Configuration . . . . . . . . . . . . . . . .  17
     2.3.  Overview of NTS Messages and their Structure for Use with
           PTP . . . . . . . . . . . . . . . . . . . . . . . . . . .  20
       2.3.1.  PTP Key Request Message . . . . . . . . . . . . . . .  22
       2.3.2.  PTP Key Grant Message . . . . . . . . . . . . . . . .  23
       2.3.3.  PTP Refusal Message . . . . . . . . . . . . . . . . .  24
       2.3.4.  PTP Registration Request Message  . . . . . . . . . .  25
       2.3.5.  PTP Registration Success Message  . . . . . . . . . .  26
       2.3.6.  PTP Registration Revoke Message . . . . . . . . . . .  27
   3.  NTS Messages for PTP  . . . . . . . . . . . . . . . . . . . .  28
     3.1.  NTS Message Types . . . . . . . . . . . . . . . . . . . .  28
     3.2.  NTS Records . . . . . . . . . . . . . . . . . . . . . . .  28
       3.2.1.  AEAD Negotiation  . . . . . . . . . . . . . . . . . .  29
       3.2.2.  Association Mode  . . . . . . . . . . . . . . . . . .  29
       3.2.3.  Current Parameters Container  . . . . . . . . . . . .  29
       3.2.4.  End of Message  . . . . . . . . . . . . . . . . . . .  30
       3.2.5.  Error . . . . . . . . . . . . . . . . . . . . . . . .  30
       3.2.6.  Grace Period  . . . . . . . . . . . . . . . . . . . .  30
       3.2.7.  Lifetime  . . . . . . . . . . . . . . . . . . . . . .  30
       3.2.8.  MAC Algorithm Negotiation . . . . . . . . . . . . . .  31
       3.2.9.  Next Parameters Container . . . . . . . . . . . . . .  31
       3.2.10. NTS Message Type  . . . . . . . . . . . . . . . . . .  31
       3.2.11. NTS Message Version . . . . . . . . . . . . . . . . .  31
       3.2.12. NTS Next Protocol Negotiation . . . . . . . . . . . .  32
       3.2.13. Requesting PTP Identity . . . . . . . . . . . . . . .  32
       3.2.14. Security Association  . . . . . . . . . . . . . . . .  32
       3.2.15. Security Policies . . . . . . . . . . . . . . . . . .  32
       3.2.16. Ticket  . . . . . . . . . . . . . . . . . . . . . . .  33
       3.2.17. Ticket Container  . . . . . . . . . . . . . . . . . .  33
       3.2.18. Ticket Key  . . . . . . . . . . . . . . . . . . . . .  33
       3.2.19. Ticket Key ID . . . . . . . . . . . . . . . . . . . .  34
       3.2.20. Time until Update . . . . . . . . . . . . . . . . . .  34

Langer & Bermbach        Expires August 26, 2021                [Page 2]
Internet-Draft                   NTS4PTP                   February 2021

     3.3.  Additional Mechanisms . . . . . . . . . . . . . . . . . .  34
       3.3.1.  AEAD Operation  . . . . . . . . . . . . . . . . . . .  34
       3.3.2.  SA/SP Management  . . . . . . . . . . . . . . . . . .  34
   4.  New TICKET TLV for PTP Messages . . . . . . . . . . . . . . .  35
   5.  AUTHENTICATION TLV Parameters . . . . . . . . . . . . . . . .  35
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  35
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  35
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  35
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  35
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  36
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  36

1.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Key Management Using Network Time Security

   Many networks include both PTP and NTP at the same time.
   Furthermore, many time server appliances that are capable of acting
   as the Grandmaster of a PTP Network are also capable of acting as an
   NTP server.  For these reasons it is likely to be easier both for the
   time server manufacturer and the network operator if PTP and NTP use
   a key management system based on the same technology.  The Network
   Time Security (NTS) protocol was specified by the Internet
   Engineering Task Force (IETF) to protect the integrity of NTP
   messages (IETF RFC 8915).  Its NTS Key Establishment sub-protocol is
   secured by the Transport Layer Security (TLS 1.3, IETF RFC 8446)
   mechanism.  TLS is used to protect numerous popular network
   protocols, so it is present in many networks.  For example, HTTPS,
   the predominant secure web protocol uses TLS for security.  Since
   many PTP capable network appliances have management interfaces based
   on HTTPS, the manufacturers are already implementing TLS.  This
   document outlines how the NTS Key Establishment protocol of IETF RFC
   8915 can be expanded for use as a PTP key management mechanism [B58]
   for immediate security processing complementing the exemplary GDOI
   proposal in the IEEE Std 1588-2019.  As a key establishment server
   for NTP should be implemented stateless which is not necessary for
   PTP systems, suitable new NTS messages are to be defined in this
   document.

   Though the key management for PTP is based on the NTS Key
   Establishment protocol for NTP, it works completely independent of

Langer & Bermbach        Expires August 26, 2021                [Page 3]
Internet-Draft                   NTS4PTP                   February 2021

   NTP.  The key management system uses the procedures described in IETF
   RFC 8915 for the NTS-KE and expands it with new NTS messages for PTP.
   It may be applied in a Key Establishment server (KE server) that
   already manages NTP but can also be operated only handling KE for
   PTP.  Even when the PTP network is isolated from the Internet, a Key
   Establishment server can be installed in that network providing the
   PTP instances with necessary key and security parameters.

   The KE server may often be implemented as a separate unit.  It also
   may be collocated with a PTP instance, e.g. the Grandmaster.  In the
   latter case communication between the KE server program and the PTP
   instance program needs to be implemented in a secure way if TLS
   communication (e.g. via local host) is not or cannot be used.

   Using the expanded NTS Key Establishment protocol for the NTS key
   management for PTP, NTS4PTP provides two principle approaches
   specified in this document.

   1.  Group-based approach:

   o  Definition of one or more security groups in the PTP network,
   o  very suitable for PTP multicast mode and mixed multicast/unicast
      mode,
   o  suitable for unicast mode in small subgroups of very few
      participants (Group-of-2, Go2) but poor scaling and more
      administration work,

   2.  Ticket-based approach

   o  secured (end-to-end) PTP unicast communication between requester
      and grantor,
   o  no group binding necessary,
   o  very suitable for native PTP unicast mode, because of good
      scaling,
   o  a bit more complex NTS message handling.

   This document describes the structure and usage of these two
   approaches in their application as a key management system for the
   integrated security mechanism (Prong A) of IEEE Std 1588-2019.
   Section 2.1 starts with a description of the principle key
   distribution mechanism, continues with details of the various group-
   based options (Section 2.1.1) and the ticket-based unicast mode
   (Section 2.1.2) before it ends with more general topics in
   Section 2.2 for example the key update process and finally an
   overview of the newly defined NTS messages in Section 2.3.  Section 3
   gives all the details necessary to construct all records forming the
   particular NTS messages.  Section 4 depicts details of a TICKET TLV
   needed to transport encrypted security information in PTP unicast

Langer & Bermbach        Expires August 26, 2021                [Page 4]
Internet-Draft                   NTS4PTP                   February 2021

   requests.  The following Section 5 mentions specific parameters used
   in the PTP AUTHENTICATION TLV when working with the NTS4PTP key
   management system.  Section 6 and Section 7 discuss IANA respectively
   security considerations.

2.1.  Principle Key Distribution Mechanism

   A PTP instance requests a key from the server referred to as the Key
   Establishment server, or (NTS-) KE server.  Figure 1 describes the
   principle sequence which can be used for PTP multicast as well as PTP
   unicast operation.

   PTP Instance 1                    NTS-KE-Server

    |                                    |
    |<======== Open TLS Channel ========>|
    |                                    |
    |                                    |
    |                                    |
    |                                    |
    |========= PTP Key Request =========>| )
    |                                    | ) NTS messages
    |                                    | ) for PTP
    |                                    | ) key exchange
    |<======== PTP Key Grant ============| )
    |                                    |
    |                                    |
    |                                    |
    |                                    |
    |<======== Close TLS Channel =======>|
    |                                    |
    |                                    o
    |
    |
    |
    |                              PTP Instance 2/
    |                              PTP Network
    |
    |                                    |
    |                                    |
    |<---- Secured PTP Communication --->|
    |           using shared key         |
    |                                    |
    |                                    |
    V                                    V

                  Figure 1: NTS Key distribution sequence

Langer & Bermbach        Expires August 26, 2021                [Page 5]
Internet-Draft                   NTS4PTP                   February 2021

   The client connects to the KE server on the NTS TCP port (port number
   4460).  Then both parties perform a TLS handshake to establish a TLS
   1.3 communication channel.  No earlier TLS versions are allowed.  The
   details of the TLS handshake are specified in IETF RFC 8446.

   Implementations must conform to the rules stated in chapter 3 "TLS
   Profile for Network Time Security" of IETF RFC 8915".

   "Network Time Security makes use of TLS for NTS key establishment.

   Since the NTS protocol is new as of this publication, no backward-
   compatibility concerns exist to justify using obsolete, insecure, or
   otherwise broken TLS features or versions.

   Implementations MUST conform with RFC 7525 [RFC7525] or with a later
   revision of BCP 195.

   Implementations MUST NOT negotiate TLS versions earlier than 1.3
   [RFC8446] and MAY refuse to negotiate any TLS version that has been
   superseded by a later supported version.

   Use of the Application-Layer Protocol Negotiation Extension [RFC7301]
   is integral to NTS, and support for it is REQUIRED for
   interoperability ... "

   The TLS handshake accomplishes the following:.

   o  Negotiation of TLS version (only TLS 1.3 allowed), and
   o  negotiation of the cipher suite for the TLS session, and
   o  authentication of the TLS server (equivalent to the KE server)
      using a digital X.509 certificate,
   o  verification of the TLS client (PTP instance) using its digital
      X.509 certificate and
   o  the encryption of the subsequent information exchange between the
      TLS communication partners.

   TLS therefore enables peer authentication by certificates and
   provides authenticity, message integrity and confidentiality of
   following data transmitted over the TLS channel.

   TLS is a layer five protocol that runs on TCP over IP.  Therefore,
   PTP implementations that support NTS-based key management need to
   support TCP and IP (at least on a separate management port).

   Once the TLS session is established, the PTP instance will ask for a
   PTP key as well as the associated security parameters using the new
   NTS message PTP Key Request (see Section 2.3.1).  The NTS application
   of the KE server will respond with either a PTP Key Grant message

Langer & Bermbach        Expires August 26, 2021                [Page 6]
Internet-Draft                   NTS4PTP                   February 2021

   (see Section 2.3.2), or a PTP Refusal message (see Section 2.3.3).
   All messages are constructed from specific records as described in
   Section 3.2.

   When the Key Request message was responded with a PTP Key Grant or a
   PTP Refusal the TLS session will be closed with a close notify TLS
   message from both parties, the PTP instance and the key server.

   With the key and other information received, the PTP instance can
   take part in the secured PTP communication in the different modes of
   operation.

   After the reception of the first set of security parameters the PTP
   instance can resume the TLS session by including a TLS session ID,
   allowing the PTP instance to skip the TLS version and algorithm
   negotiations.  If resuming is used, a suitable lifetime for the TLS
   session key must be defined to not open the TLS connection for
   security threats.

   As the TLS session provides authentication, but not authorization
   additional means has to be used for the latter (see Section 2.2.5.4).

   As mentioned above, the NTS key management for PTP supports two
   principle methods, the group-based approach and the ticket-based
   approach which are described in the following sections below.

2.1.1.  NTS Message Exchange for Group-based Approach

   As described in Section 2.1, a PTP instance wanting to join a secured
   PTP communication in the group-based modes contacts the KE server
   inside a secured TLS connection with a PTP Key Request message (see
   Section 2.3.1) as shown in Figure 2.  The KE server answers with a
   PTP Key Grant message (see Section 2.3.2) with all the necessary data
   to join the group communication or with a PTP Refusal message (see
   Section 2.3.3) if the PTP instance is not allowed to join the group.
   This procedure is necessary for all parties which are or will be
   members of that PTP group including the Grandmaster and other special
   participants, e.g.  Transparent Clocks.  As mentioned above, this not
   only applies to multicast mode but also to mixed multicast/unicast
   mode (former hybrid mode) where the explicit unicast communication
   uses the multicast group key received from the KE server.  The group
   number for both modes is primarily generated by a concatenation of
   the PTP domain number and the PTP profile (sdoId), as described in
   Section 3.2.2.

   Additionally, besides multicast and mixed multicast/unicast mode, a
   group of two (or few more) PTP instances can be configured,

Langer & Bermbach        Expires August 26, 2021                [Page 7]
Internet-Draft                   NTS4PTP                   February 2021

   practically implementing a special group-based unicast communication
   mode, the group-of-2 (Go2) mode.

   Secured
   PTP Network       PTP Instance          NTS-KE-Server

    |                      |                     |
    |                      |         TLS:        |
    |                  TLS |== PTP Key Request =>| Response contains:
    |              secured |                     | GroupID, security
    |        communication |         TLS:        | parameters, group
    |                      |<== PTP Key Grant ===| key, validity
    |                      |                     | period etc.
    |                      |                     |
    |    Secured PTP:      |                     |
    |--- Announce -------->|  )                  |
    |                      |  )                  |
    |                      |  )                  |
    |    Secured PTP:      |  )                  |
    |-- Sync & Follow_Up ->|  )                  |
    |                      |  ) Secured          |
    |                      |  ) PTP messages     |
    |    Secured PTP:      |  ) using            |
    |<-- Delay_Req --------|  ) group key        |
    |                      |  )                  |
    |                      |  )                  |
    |    Secured PTP:      |  )                  |
    |--- Delay_Resp ------>|  )                  |
    |                      |  )                  |
    |                      |                     |
    V                      V                     V

   Legend:        TLS:       Authenticated & encrypted
             =============>  TLS communication

              Secured PTP:   Group key-authenticated
             ------------->  PTP communication

          Figure 2: Message exchange for the group-based approach

   This mode requires additional administration in advance defining
   groups-of-2 and supplying them with an additional attribute in
   addition to the group number mentioned for the other group-based
   modes - the subGroup attribute in the Association Mode record (see
   Section 3.2.2) of the PTP Key Request message.  So, addressing for
   Go2 is achieved by use of the group number derived from domain
   number, sdoId and the additional attribute subGroup.  Communication

Langer & Bermbach        Expires August 26, 2021                [Page 8]
Internet-Draft                   NTS4PTP                   February 2021

   in that mode is performed using multicast addresses.  If the latter
   is undesirable, unicast addresses can be used but the particular IP
   or MAC addresses of the communication partners need to be configured
   upfront, too.

   In spite of its specific name, Go2 allows more than two participants,
   for example additional Transparent Clocks.  All participants in that
   subgroup need to be configured respectively.  (To enable the KE
   server to supply the subgroup members with the particular security
   data the respective certificates may reflect permission to take part
   in the subgroup.  Else another authorization method is to be used.)

   Having predefined the Go2s the key management for this mode of
   operation follows the same procedure (see Figure 2) and uses the same
   NTS messages as the other group-based modes.  Both participants, the
   Group-of-2 requester and the respective grantor need to have received
   their security parameters including key etc. before secure PTP
   communication can take place.

   After the NTS key establishment messages for these group-based modes
   have been exchanged, the secured PTP communication can take place
   using the Security Association(s) communicated.

   The key management for these modes works relatively simple and needs
   only the above mentioned three NTS messages: PTP Key Request, PTP Key
   Grant or PTP Refusal.  The group number used for addressing is
   automatically derived from the configured attributes domain number
   and sdoID.

   Additionally, besides multicast and hybrid mode, a (multicast) group
   of two PTP instances can be configured, practically implementing a
   special unicast communication.

   The key management for these modes works relatively simple and needs
   only the above mentioned three NTS messages: PTP Key Request, PTP Key
   Grant or PTP Refusal.  The group number used for addressing is
   automatically derived from the configured attributes PTP domain
   number and sdoId.  For Go2, the attribute subGroup is additionally
   required.

2.1.2.  NTS Message Exchange for the Ticket-based Approach

   In (native) PTP unicast mode using unicast message negotiation (IEEE
   Std 1588-2019, 16.1) any potential instance (the grantor) which can
   be contacted by other PTP instances (the requesters) needs to
   register upfront with the KE server as depicted in Figure 3.

Langer & Bermbach        Expires August 26, 2021                [Page 9]
Internet-Draft                   NTS4PTP                   February 2021

        PTP Requester         NTS-KE-Server            PTP Grantor

                |                    |                     |
                |                    |         TLS:        |Grantor
                |       KE generates |<= PTP Registration =|registers
                |         ticket key |       Request       |upfront
                |                    |                     |
                |                    |        TLS:         |gets
                |           KE sends |== PTP Registration >|ticket
                |         ticket key |       Success       |key to
                |                    |                     |decrypt
                :                    :                     :tickets
                :                    ;                     :
    PTP instance|     TLS:           |                     |
   wants unicast|= PTP Key Request =>| KE generates        |
   communication|                    | and sends           |
                |                    | unicast key         |
                |     TLS:           | & encrypted         |
                |<= PTP Key Grant ===| ticket              |
                |                    |                     |
                |                    |                     |
                |                    |                     |decrypts
         Unicast|                    |                     |ticket,
         request|  Secured PTP:      |                     |extracts
        contains|- Announce Request ---------------------->|containing
          ticket|                    |                     |unicast key
                |                    |                     |
                |  Secured PTP:      |                     |Grantor uses
                |< Grant ----------------------------------|unicast key
                |                    |                     |
                |                    |                     |
                V                    V                     V

   Legend:        TLS:       Authenticated & encrypted
             =============>  TLS communication

              Secured PTP:   Unicast key-authenticated
             ------------->  PTP communication

         Figure 3: Message exchange for ticket-based unicast mode

   (Note: As any PTP instance may request unicast messages from any
   other instance the terms requester and grantor as used in the
   standard suit better than talking about slave resp. master.  In
   unicast PTP, the grantor is typically a PTP Port in the MASTER state,
   and the requester is typically a PTP Port in the SLAVE state, however

Langer & Bermbach        Expires August 26, 2021               [Page 10]
Internet-Draft                   NTS4PTP                   February 2021

   all PTP Ports are allowed to grant and request unicast PTP message
   contracts regardless of which state they are in.  A PTP port in
   MASTER state may be requester, a port in SLAVE state may be a
   grantor.)

   This registration is performed via a PTP Registration Request message
   (see Section 2.3.4).  The KE server answers with a PTP Registration
   Success message (see Section 2.3.5) or a PTP Refusal message (see
   Section 2.3.3).

   With the reception of the PTP Registration Success message the
   grantor holds a ticket key known only to the KE server and the
   registered grantor.  With this ticket key it can decrypt
   cryptographic information contained in a so-called ticket which
   enables secure unicast communication.

   As with the group-based approach, a PTP instance (the requester)
   wanting to start a secured PTP unicast communication with a specific
   grantor contacts the KE server sending a PTP Key Request message (see
   Section 2.3.1) as shown in Figure 3 using the TLS-secured NTS Key
   Establishment protocol.  The KE server answers with a PTP Key Grant
   message (see Section 2.3.2) with all the necessary data to begin the
   unicast communication with the desired partner or with a PTP Refusal
   message (see Section 2.3.3) if unicast communication with that
   instance is unavailable.

   The PTP Key Grant message includes a unicast key to secure the PTP
   message exchange with the desired grantor.  In addition, it contains
   the above mentioned encrypted ticket which the requester transmits in
   a special Ticket TLV (see Section 4) with the secured PTP message to
   the grantor.  The grantor receiving the PTP message decrypts the
   received ticket with its ticket key and extracts the containing
   security parameters, for example the unicast key used by the
   requester to secure the PTP message and the requester's identity.  In
   that way the grantor can check the received message, identify the
   requester and can use the unicast key for further secure PTP
   communication with the requester until the unicast key expires.

   After the NTS key establishment messages for the PTP unicast mode
   have been exchanged the secured PTP communication can take place
   using the Security Association(s) communicated.

   If a grantor is no longer at disposal for unicast mode during the
   lifetime of registration and ticket key, it sends a TLS-secured PTP
   Registration Revoke message (see Section 2.3.6) to the KE server, so
   requesters no longer receive PTP Key Grant messages for this grantor.

Langer & Bermbach        Expires August 26, 2021               [Page 11]
Internet-Draft                   NTS4PTP                   February 2021

   This unicast mode is a bit more complex than the Group-of-2 approach
   and eventually uses all six new NTS messages.  However, no subgroups
   have to be defined upfront.  Addressing a grantor, the requesting
   instance simply may use the grantor's IP, MAC address or PortIdentity
   attribute.

2.2.  General Topics

   This section describes more general topics like key update and key
   generation as well as discussion of the time information on the KE
   server, the use of certificates and topics concerning upfront
   configuration.

2.2.1.  Key Update Process

   All keys are equipped with parameters for a specific lifetime.
   Thereafter new key material has to be used.  The value in the
   Lifetime record given by the KE server in the respective NTS messages
   is specified in seconds which denote the remaining time until the key
   expires and are decremented down to zero.  So hard adjustments of the
   clock used have to be avoided.  Therefore the use of a monotonic
   clock is recommended.  Requests during the currently running lifetime
   will receive respectively adapted count values.

   The receiving instances may concede a Grace Time in the range of, for
   example 5 - 10 seconds where an old key is still accepted to handle
   internal delays gracefully.  The Grace Time may be defined in a PTP
   profile.  Additionally, the KE server can optionally be configured to
   inform about a grace time value generally to be used.

   New security parameters will be available after the Time until Update
   (TuU).  The Time until Update given by the KE server is specified in
   seconds which are decremented down to zero.  After that point in time
   until the end of the Lifetime of an associated key the PTP instances
   should connect to the KE server again, to receive new security
   parameters.  The actual point in time, when a PTP instance asks for
   new data, should be selected randomly in the update period - the time
   after TuU was decremented to zero and before the Lifetime is counted
   down completely - to avoid peak load on the KE server.  Figure 4
   presents an example of the key update mechanism.  A PTP instance
   sending a PTP Key Request to the KE server during the update period
   will receive the current security parameters (Current Parameters) as
   well as the security parameters of the following period (Next
   Parameters).  As with the lifetime, requests during the currently
   running lifetime will receive respectively adapted count values for
   the current TuU.

Langer & Bermbach        Expires August 26, 2021               [Page 12]
Internet-Draft                   NTS4PTP                   February 2021

   Lifetime and Time until Update allow a cyclic rotation of security
   parameters during the running operation.  This approach guarantees
   continuous secured PTP communication without interruption by key
   rotation.

   |12,389s (at time of key request)    0s|14,400s                   0s|
   +--------------------------------------+------------------...-------+
   |     Lifetime (curent parameters)     |  Lifetime (next parameters)|
   +-----------------------------+--------+------------------...-------+
   |         Time until Update   |  900s  |
   +-----------------------------+<------>|
   |11,489s (time of key req.) 0s| update |
                                   period
                                 |________|
                                      |
                                      V
                      Request and receive new parameters
                           at a random point in time

   Example:
   --------
   Lifetime (full):            14,400s = 4h
   Time unitil Update (full):  13,500s -> updated period: 900s = 15 min

    Figure 4: Example of the parameter rotation using Lifetime and Time
                     until Update in group-based mode

   The key rotation mechanism described also applies for the ticket-
   based approach.  As there are two keys, the ticket key and the
   unicast key, some details need to be explained (see Figure 5).  When
   the grantor registers with the KE server it receives the ticket key
   with the PTP Registration Success message together with the Lifetime
   and the respective Time until Update records.  The lifetime
   parameters also apply to the ticket a requester would receive.

   A requester wanting to communicate in unicast sends a PTP Key Request
   message with the particular parameters to the KE server.  In the
   response it receives a specific unicast key with Lifetime and TuU as
   well as the encrypted ticket containing all the necessary security
   information for the grantor.  The lifetime of the unicast key will
   end at the same point in time as the ticket key.  Requests during the
   currently running lifetime of the ticket key will receive
   respectively adapted count values.  The lifetime can be at most the
   remaining lifetime of the respective ticket key of the grantor.

Langer & Bermbach        Expires August 26, 2021               [Page 13]
Internet-Draft                   NTS4PTP                   February 2021

   Update process grantor:
   -----------------------

   (at time of registration success)
     |
   |14,400s                               0s |14,400s                0s|
   +--------------------------------------------------------...--------+
   |Lifetime (curr.ticket key)               |Lifetime (next ticket k.)|
   +-------------------------+------+--------+--------------...--------+
   |    Time until Update    | 300s |        :
   +-------------------------+<---->|        :
   |13,200s                0s|update|        :
     |                        period:        :
   (at time of                      :        :
    registration success)           :        :
                                    :        :
                                    :        :
   Update process requester:        :        :
   -------------------------        :        :
                                    :        :
   (at time of key grant)           :        :
         |                          :        :
       |12,389s                     :      0s|14,400s                0s|
       +-------------------------------------+-----------------...-----+
       |Lifetime (curent parameters)         | Lifetime (next params.) |
       +----------------------------+--------+-----------------...-----+
       |    Time until Update       |  900s  |
       +----------------------------+<------>|
       |11,489s                   0s| update |
         |                            period
   (at time of key grant)           |________|
                                         |
                                         V
                         Request and receive new parameters
                              at a random point in time

   Example:
   --------
   Lifetime (full):            14,400s = 4h
   Time unitil Update (full):
                 - requester   13,500s -> updated period: 900s = 15 min
   Time unitil Update (full):
                 - grantor:    13,200s = ToU of requester - 300s

    Figure 5: Example of the parameter rotation using Lifetime and Time
                     until Update in ticket-based mode

Langer & Bermbach        Expires August 26, 2021               [Page 14]
Internet-Draft                   NTS4PTP                   February 2021

   The TuU of the ticket key will end earlier than the TuU of associated
   unicast keys.  The grantor should re-register in its update period
   beginning after the Time until Update of the ticket key was
   decremented to zero and ending when an associated unicast key TuU is
   counted down.  As the grantor does not know how long its update
   period lasts it should re-register immediately after its TuU has
   ended.  (A profile or a general configuration may fix the length of a
   grantors' update period.  Then the grantor could re-register at a
   random point in time during its update period.  Because masters
   register asynchronously, their re-registration will also be
   asynchronous.  So typically, no peak load for the KE server will be
   generated.)  Its update period is a mere timing buffer for cases
   where re-registration will not work instantly.  The re-registration
   should be completed before any requester can start a PTP Key Request
   for ticket-based unicast mode.  This guarantees the availability of a
   new ticket.  When re-registering in its update period the grantor
   will receive together with the ticket key, etc., Lifetime and Time
   until Update of the current period as well as the parameters of the
   following period - similar to multicast keys.  (A registration during
   the TuU period will supply only current data, not parameters of the
   following period.  A late re-registration after the end of the
   current Lifetime will start a new period with respective full
   lifetime und update parameters.)

   A requester needs to ask for a new unicast key and ticket at the KE
   server during the update period for uninterrupted unicast
   communication possibility or else at any later point in time.  During
   the update period it will receive the Current Parameters as well as
   the Next Parameters.  Embedded in the respective data, it will
   receive the ticket for the grantor including the encrypted ticket.
   Each ticket carries the same security information as the respective
   Current Parameters or Next Parameters data structure.

   If a grantor does not have re-registered (in time or at all) when
   corresponding requesters try to get unicast keys, they will receive a
   PTP Refusal message.

   If a grantor has revoked his registration with a PTP Registration
   Revoke message, requesters will receive a PTP Refusal message when
   trying to update for a new unicast key.  No immediate key revoke
   mechanism exists.  The grantor should not grant respective unicast
   requests until the revoked key expires.

2.2.2.  Key Generation

   In all cases keys obtained by a secure random number generator shall
   be used.  The length of the keys depends on the MAC algorithm (see

Langer & Bermbach        Expires August 26, 2021               [Page 15]
Internet-Draft                   NTS4PTP                   February 2021

   also last subsection in Section 3.3.2) respectively the AEAD
   algorithm utilized.

2.2.3.  Time Information of the KE Server

   As the KE server embeds time duration information in the respective
   messages, its local time should be sufficiently precise to a maximum
   a few seconds compared to the controlled PTP network(s).  To avoid
   any dependencies, it should synchronize to a secure external time
   source, for example an NTS-secured NTP server.  The time information
   is also necessary to check the lifetime of certificates used.

2.2.4.  Certificates

   The authentication of the TLS communication parties is based on
   certificates issued by a trusted Certificate Authority (CA) that are
   utilized during the TLS handshake.  In classical TLS applications
   only servers are required to have them.  For the key management
   system described here, the PTP nodes also need certificates to allow
   only authorized and trusted devices to get the group key and join a
   secure PTP network.  (As TLS only authenticates the communication
   partners, authorization has to be managed by external means, see the
   topic "Authorization" in Section 2.2.5.4.)  The verification of a
   certificate always requires a loose time synchronicity, because they
   have a validity period.  This, however, reveals the well-known start-
   up problem, since secure time transfer itself requires valid
   certificates.  (See the discussion and proposals on this topic in
   IETF RFC 8915, chapter 8.5 "Initial Verification of Server
   certificates" which applies to client certificates in the PTP key
   management system, too.)

   Furthermore, some kind of Public Key Infrastructure (PKI) is
   necessary, which may be conceivable via the Online Certificate Status
   Protocol (OCSP) as well as offline via root CA certificates.

   The TLS communication parties must be equipped with a private key and
   a certificate in advance.  The certificate contains a digital
   signature of the CA as well as the public key of the sender.  The key
   pair is required to establish an authenticated and encrypted channel
   for the initial TLS phase.  Distribution and update of the
   certificates can be done manually or automatically.  However, it is
   important that they are issued by a trusted CA instance, which can be
   either local (private CA) or external (public CA).

   For the certificates the standard for X.509 [ITU-T X.509]
   certificates must be used.  Additional data in the certificates like
   domain, sdoId and/or subgroup attributes may help in authorizing.  In
   that case it should be noted that using the PTP device in another

Langer & Bermbach        Expires August 26, 2021               [Page 16]
Internet-Draft                   NTS4PTP                   February 2021

   network then implies to have a new certificate, too.  Working with
   certificates without authorization information would not have that
   disadvantage, but more configuring at the KE server would be
   necessary: which domain, sdoId and/or subgroup attributes belong to
   which certificate.

   As TLS is used to secure the NTS Key Establishment protocol a comment
   on the security of TLS seems reasonable.  A TLS 1.3 connection is
   considered secure today.  However, note that a DoS (Denial of
   Service) attack on the key server can prevent new connections or
   parameter updates for secure PTP communication.  A hijacked key
   management system is also critical, because it can completely disable
   the protection mechanism.  A redundant implementation of the key
   server is therefore essential for a robust system.  A further
   mitigation can be the limitation of the number of TLS requests of
   single PTP nodes to prevent flooding.  But such measures are out of
   the scope of this document.

2.2.5.  Upfront Configuration

   All PTP instances as well as the NTS-KE server need to be configured
   by the network administrator.  This applies to several fields of
   parameters.

2.2.5.1.  Security Parameters

   The cryptographic algorithm and associated parameters (the so-called
   Security Association(s) - SA) used for PTP keys are configured by
   network operators at the KE server.  This includes the Security
   Policies, i.e. which PTP messages are to be secured.  PTP instances
   that do not support the configured algorithms cannot operate with the
   security.  Since most PTP Networks are managed by a single
   organization, configuring the cryptographic algorithm (MAC) for ICV
   calculation is practical.  This prevents the need for the KE server
   and PTP instances to implement an NTS algorithm negotiation protocol.

   For the ticket-based approach the AEAD algorithms need to be
   specified which the PTP grantors and the KE server support and
   negotiate during the registration process.  Optionally, the MAC
   algorithm may be negotiated during a unicast PTP Key Request to allow
   faster or stronger algorithms, but a standard protocol supported by
   every instance should be defined.  Eventually, suitable algorithms
   may be defined in a respective profile.

Langer & Bermbach        Expires August 26, 2021               [Page 17]
Internet-Draft                   NTS4PTP                   February 2021

2.2.5.2.  Key Lifetimes

   Supplementary to the above mentioned SAs the desired key rotation
   periods, i.e. the lifetimes of keys resp. all security parameters
   need to be configured at the NTS-KE server.  This applies to the
   lifetime of a group key in the group-based approach as well as the
   lifetime of ticket key and unicast key in the ticket-based unicast
   approach (typically for every unicast pair in general or eventually
   specific for each requestor-grantor pair).  In addition, the
   corresponding Time until Update parameters need to be defined which
   (together with the lifetime) specify the relevant update period.  Any
   particular Lifetime and Time until Update are configured as time
   spans counted in seconds and start at the same point in time.

2.2.5.3.  Certificates

   The network administrator has to supply each PTP instance and the KE
   server with their X.509 certificates.  The TLS communication parties
   must be equipped with a private key and a certificate containing the
   public key in advance (see Section 2.2.4).

2.2.5.4.  Authorization

   The certificates provide authentication of the communication
   partners.  Normally, they do not contain authorization information.
   Authorization decides, which PTP instances are allowed to join a
   group (in any of the group-based modes) or may enter a unicast
   communication in the ticket-based approach and request the respective
   SA(s) and key.

   As mentioned, members of a group (multicast mode, mixed multicast/
   unicast mode) are identified by their domain and their sdoId.  PTP
   Domain and sdoId may be attributes in the certificates of the
   potential group members supplying additional authorization.  If not
   contained in the certificates extra authorization means are
   necessary.  (See also the discussion on advantages and disadvantages
   on certificates containing additional authorization data in
   Section 2.2.4.)

   If the special Group-of-2 mode is used, the optional subGroup
   parameter (i.e. the subgroup number) needs to be specified at all
   members of respective Go2s, upfront.  To enable the KE server to
   supply the subgroup members with the particular security data their
   respective certificates may reflect permission to take part in the
   subgroup.  Else another authorization method is to be used.

   In native unicast mode, any authenticated grantor that is member of
   the group used for multicast may request a registration for unicast

Langer & Bermbach        Expires August 26, 2021               [Page 18]
Internet-Draft                   NTS4PTP                   February 2021

   communication at the KE server.  If it is intended for unicast, this
   must be configured locally.  If no group authorization is available
   (e.g. pure unicast operation) another authentication scheme is
   necessary.

   In the same way, any requester (if configured for it locally) may
   request security data for a unicast connection with a specific
   grantor.  Only authentication at the KE server using its certificate
   and membership in the group used for multicast is needed.  If a
   unicast communication is not desired by the grantor, it should not
   grant a specific unicast request.  Again, if no group authorization
   is available (e.g. pure unicast operation) another authentication
   scheme is necessary.

   Authorization can be executed at least in some manual configuration.
   Probably the application of a standard access control system like
   Diameter, RADIUS or similar would be more appropriate.  Also role-
   based access control (RBAC), attribute-based access control (ABAC) or
   more flexible tools like Open Policy Agent (OPA) could help
   administering larger systems.  But details of the authorization of
   PTP instances lies out of scope of this document.

2.2.5.5.  Transparent Clocks

   Transparent Clocks (TC) need to be supplied with respective
   certificates, too.  For group-based modes they must be configured for
   the particular PTP domain and sdoId and eventually for the specific
   subgroup(s) when using Group-of-2.  They need to request for the
   relevant group key(s) at the KE server to allow secure use of the
   correctionField in a PTP message and generation of a corrected ICV.
   If TCs are used in ticket-based unicast mode, they need to be
   authorized for the particular unicast path.

   Authorization of TCs for the respective groups, subgroups and unicast
   connections is paramount.  Otherwise the security can easily be
   broken with attackers pretending to be TCs in the path.
   Authorization of TCs is necessary too in unicast communication, even
   if the normal unicast partners need not be especially authorized.

   Transparent clocks may notice that the communication runs secured.
   In the group-based approaches multicast mode and mixed multicast/
   unicast mode they construct the GroupID from domain and sdoId and
   request a group key from the KE server.  Similarly, they can use the
   additional subgroup attribute in Go2 mode for a (group) key request.
   Afterwards they can check the ICV of incoming messages, fill in the
   correction field and generate a new ICV for outgoing messages.  In
   ticket-based unicast mode a TC may notice a secured unicast request
   from a requester to the grantor and can request the unicast key from

Langer & Bermbach        Expires August 26, 2021               [Page 19]
Internet-Draft                   NTS4PTP                   February 2021

   the KE server to make use of the correction field afterwards.  As
   mentioned above upfront authentication and authorization of the
   particular TCs is paramount not to open the secured communication to
   attackers.

2.2.5.6.  Start-up considerations

   At start-up of a single PTP instance or the complete PTP network some
   issues have to be considered.

   At least loose time synchronization is necessary to allow for
   authentication using the certificates.  See the discussion and
   proposals on this topic in IETF RFC 8915, chapter 8.5 "Initial
   Verification of Server certificates" which applies to client
   certificates in the PTP key management system, too.

   Similarly to a key re-request during an update period, key requests
   should be started at a random point in time after start-up to avoid
   peak load on the NTS-KE server.  Every grantor must register with the
   KE server before requesters can request a unicast key (and ticket).

2.3.  Overview of NTS Messages and their Structure for Use with PTP

   Section 2.1 described the principle communication sequences for PTP
   Key Request, PTP Registration Request and corresponding response
   messages.  All messages follow the "NTS Key Establishment Process"
   stated in the first part (until the description of Fig. 3 starts) of
   chapter 4 of IETF RFC 8915:

   "The NTS key establishment protocol is conducted via TCP port 4460.
   The two endpoints carry out a TLS handshake in conformance with
   Section 3, with the client offering (via an ALPN extension[RFC
   7301]), and the server accepting, an application-layer protocol of
   "ntske/1".  Immediately following a successful handshake, the client
   SHALL send a single request as Application Data encapsulated in the
   TLS-protected channel.  Then, the server SHALL send a single
   response.  After sending their respective request and response, the
   client and server SHALL send TLS "close_notify" alerts in accordance
   with Section 6.1 of RFC 8446.

   The client's request and the server's response each SHALL consist of
   a sequence of records formatted according to Figure 6.  The request
   and a non-error response each SHALL include exactly one NTS Next
   Protocol Negotiation record.  The sequence SHALL be terminated by a
   "End of Message" record.  The requirement that all NTS-KE messages be
   terminated by an End of Message record makes them self-delimiting.

Langer & Bermbach        Expires August 26, 2021               [Page 20]
Internet-Draft                   NTS4PTP                   February 2021

   Clients and servers MAY enforce length limits on requests and
   responses, however, servers MUST accept requests of at least 1024
   octets and clients SHOULD accept responses of at least 65536 octets.

   The fields of an NTS-KE record are defined as follows:

      C (Critical Bit): Determines the disposition of unrecognized
      Record Types.  Implementations which receive a record with an
      unrecognized Record Type MUST ignore the record if the Critical
      Bit is 0 and MUST treat it as an error if the Critical Bit is 1
      (see Section 4.1.3).
      Record Type Number: A 15-bit integer in network byte order.  The
      semantics of record types 0-7 are specified in this memo.
      Additional type numbers SHALL be tracked through the IANA Network
      Time Security Key Establishment Record Types registry.
      Body Length: The length of the Record Body field, in octets, as a
      16-bit integer in network byte order.  Record bodies MAY have any
      representable length and need not be aligned to a word boundary.
      Record Body: The syntax and semantics of this field SHALL be
      determined by the Record Type.

   For clarity regarding bit-endianness: the Critical Bit is the most-
   significant bit of the first octet.  In the C programming language,
   given a network buffer `unsigned char b[]` containing an NTS-KE
   record, the critical bit is `b[0] >> 7` while the record type is
   `((b[0] & 0x7f) << 8) + b[1]`."

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|         Record Type         |          Body Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                                                               :
   :                           Record Body                         :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 6: NTS-KE Record format

   Thus, all NTS messages consist of a sequence of records, each
   containing a Critical Bit C, the Record Type, the Body Length and the
   Record Body, see Figure 6.  More details on record structure as well
   as the specific records used here are given in Section 3 and
   respective subsections there.  So-called container records (short:
   container) themselves comprise a set of records in the record body
   that serve a specific purpose, e.g. the Current Parameter container.

Langer & Bermbach        Expires August 26, 2021               [Page 21]
Internet-Draft                   NTS4PTP                   February 2021

   The records contained in a message may follow in arbitrary sequence
   (though nothing speaks against using the sequence given in the record
   descriptions), only the End of Message record has to be the last one
   in the sequence indicating the end of the current message.  Container
   records do not include an End of Message record.

   The NTS key management for PTP is based on six new NTS messages:

   o  PTP Key Request message (see Section 2.3.1)
   o  PTP Key Grant message (see Section 2.3.2)
   o  PTP Refusal message (see Section 2.3.3)
   o  PTP Registration Request message (see Section 2.3.4)
   o  PTP Registration Grant message (see Section 2.3.5)
   o  PTP Registration Revoke message (see Section 2.3.6)

   The following sections describe the principle structure of those new
   NTS messages for the PTP key management.  More details especially on
   the records the messages are built of and their types, sizes,
   requirements and restrictions are given in Section 3.2.

2.3.1.  PTP Key Request Message

   PTP Key Request
   +========================================+==========================+
   | Record                                 | Exemplary body contents  |
   +========================================+==========================+
   | NTS Next Protocol Negotiation          | PTPv2.1                  |
   +----------------------------------------+--------------------------+
   | NTS Message Version                    | 1.0                      |
   +----------------------------------------+--------------------------+
   | NTS Message Type                       | PTP Key Grant            |
   +----------------------------------------+--------------------------+
   | Current Parameters                     | set of Records {...}     |
   +----------------------------------------+--------------------------+
   | MAC Algorithm Negotiation (optional)   | {CMAC || HMAC}           |
   +----------------------------------------+--------------------------+
   | Requesting PTP Identity (Unicast only) | data set {...}           |
   +----------------------------------------+--------------------------+
   | End of Message                         |                          |
   +========================================+==========================+

             Figure 7: Structure of a PTP Key Request message

   Figure 7 shows the record structure of a PTP Key Request message.  In
   the right column typical values are shown as examples.  Detailed
   information on types, sizes etc. is given in Section 3.2.  The
   message starts with the NTS Next Protocol Negotiation record which in

Langer & Bermbach        Expires August 26, 2021               [Page 22]
Internet-Draft                   NTS4PTP                   February 2021

   this application always holds PTPv2.1.  Currently, the following NTS
   Message Version record always contains 1.0.  The next record
   characterizes the message type, in this case PTP Key Request.  The
   Association Mode record describes the mode how the PTP instance wants
   to communicate: In the group-based approach the desired group number
   (plus eventually the subgroup attribute) is given.  For ticket-based
   unicast communication the Association Mode contains the
   identification of the desired grantor, for example IPv4 and its IP
   address.

   If there is an option to choose from additional MAC algorithms, then
   an optional record follows presenting the supported algorithms from
   which the KE server may choose.  In ticket-based unicast mode, the
   Requesting PTP Identity record gives the data of the identification
   of the applying requester, for example IPv4 and its IP address.  The
   messages always end with an End of Message record.

2.3.2.  PTP Key Grant Message

   Figure 8 shows the record structure of a PTP Key Grant message.  In
   the right column typical values are shown as examples.  Detailed
   information on types, sizes etc. is given in Section 3.2.  The
   message starts with the NTS Next Protocol Negotiation record which in
   this application always holds PTPv2.1.  Currently, the following NTS
   Message Version record always contains 1.0.  The next record
   characterizes the message type, in this case PTP Key Grant.

   PTP Key Grant
   +=======================================+===========================+
   | Record                                | Exemplary body contents   |
   +=======================================+===========================+
   | NTS Next Protocol Negotiation         | PTPv2.1                   |
   +---------------------------------------+---------------------------+
   | NTS Message Version                   | 1.0                       |
   +---------------------------------------+---------------------------+
   | NTS Message Type                      | PTP Key Grant             |
   +---------------------------------------+---------------------------+
   | Current Parameters                    | set of Records {...}      |
   +---------------------------------------+---------------------------+
   | Next Parameters                       | set of Records {...}      |
   +---------------------------------------+---------------------------+
   | End of Message                        |                           |
   +=======================================+===========================+

              Figure 8: Structure of a PTP Key Grant message

Langer & Bermbach        Expires August 26, 2021               [Page 23]
Internet-Draft                   NTS4PTP                   February 2021

   The following Current Parameters record is a container record
   containing in separate records all the security data needed to join
   and communicate in the secured PTP communication during the current
   validity period.  Figure 9 gives an example of data contained in that
   record.  For more details on the records contained in the Current
   Parameters container see Section 3.2.3.

   Current Parameters Container record (PTP Key Grant)
   +==============================+===================================+
   | Record                       | Exemplary body contents           |
   +==============================+========+==========================+
   | Security Policies            |{(PTPmsg1||SPP:1)||(PTPmsg2||SPP:)}|
   +------------------------------+-----------------------------------+
   | Security Association         | data set for SPP:1 {...}          |
   +------------------------------+-----------------------------------+
   | [Security Association]       | data set for SPP:2 {...}          |
   +------------------------------+-----------------------------------+
   | Lifetime                     | 1560s (=0h 26min)                 |
   +------------------------------+-----------------------------------+
   | Time until pdate             | 0s                                |
   +------------------------------+-----------------------------------+
   | Grace Period (optional)      | 10 seconds                        |
   +------------------------------+-----------------------------------+
   | Ticket Key ID (Unicast only) | 156                               |
   +------------------------------+-----------------------------------+
   | Ticket (Unicast only)        | data set {...}                    |
   +==============================+===================================+

   Figure 9: Exemplary contents of a Current Parameters Container record
                        of a PTP Key Grant message

   If the request lies inside the update interval (i.e.  TuU = 0,
   compare Figure 9), a Next Parameters Container record is appended
   giving all the security data needed in the upcoming validity period.
   Its structure follows the same composition as the Current Parameters
   record (in the ticked-based approach also including the Ticket Key ID
   record and the Ticket record).  The messages always end with an End
   of Message record.

2.3.3.  PTP Refusal Message

   The message starts with the NTS Next Protocol Negotiation record
   which in this application always holds PTPv2.1.  Currently, the
   following NTS Message Version record always contains 1.0.  The next
   record characterizes the message type, in this case PTP Refusal, see
   Figure 10.  The Error record contains information about the reason of
   refusal.  The messages always end with an End of Message record.

Langer & Bermbach        Expires August 26, 2021               [Page 24]
Internet-Draft                   NTS4PTP                   February 2021

   PTP Refusal
   +================================+=================================+
   | Record                         | Exemplary body contents         |
   +================================+=================================+
   | NTS Next Protocol Negotiation  | PTPv2.1                         |
   +--------------------------------+---------------------------------+
   | NTS Message Version            | 1.0                             |
   +--------------------------------+---------------------------------+
   | NTS Message Type               | PTP Refusal                     |
   +--------------------------------+---------------------------------+
   | Error                          | Association Port not registered |
   +--------------------------------+---------------------------------+
   | End of Message                 |                                 |
   +================================+=================================+

               Figure 10: Structure of a PTP Refusal message

2.3.4.  PTP Registration Request Message

   PTP Registration Request
   +======================================+==========================+
   | Record                               | Exemplary body contents  |
   +======================================+==========================+
   | NTS Next Protocol Negotiation        | PTPv2.1                  |
   +--------------------------------------+--------------------------+
   | NTS Message Version                  | 1.0                      |
   +--------------------------------------+--------------------------+
   | NTS Message Type                     | PTP Registration Request |
   +--------------------------------------+--------------------------+
   | Requesting PTP Identity              | data set {...}           |
   +--------------------------------------+--------------------------+
   | AEAD Algorithm Negotiation           | {AEAD_512 || AEAD_256}   |
   +--------------------------------------+--------------------------+
   | MAC Algorithm Negotiation (optional) | {CMAC || HMAC}           |
   +--------------------------------------+--------------------------+
   | End of Message                       |                          |
   +======================================+==========================+

        Figure 11: Structure of a PTP Registration Request message

   The message starts with the NTS Next Protocol Negotiation record
   which in this application always holds PTPv2.1.  Currently, the
   following NTS Message Version record always contains 1.0.  The next
   record characterizes the message type, in this case PTP Registration
   Request, see Figure 11.

Langer & Bermbach        Expires August 26, 2021               [Page 25]
Internet-Draft                   NTS4PTP                   February 2021

   The Requesting PTP Identity record gives the addresses of the grantor
   requesting registration whereas the following AEAD Algorithm
   Negotiation record indicates which algorithms for encryption of the
   ticket the requester supports.

   If there is an option to choose from additional MAC algorithms, then
   an optional record follows presenting all the grantor's supported
   algorithms from which the KE server may choose.  The messages always
   end with an End of Message record.

2.3.5.  PTP Registration Success Message

   PTP Registration Success
   +====================================+============================+
   | Record                             | Exemplary body contents    |
   +====================================+============================+
   | NTS Next Protocol Negotiation      | PTPv2.1                    |
   +------------------------------------+----------------------------+
   | NTS Message Version                | 1.0                        |
   +------------------------------------+----------------------------+
   | NTS Message Type                   | PTP Registration Success   |
   +------------------------------------+----------------------------+
   | Current Parameters                 | set of Records {...}       |
   +------------------------------------+----------------------------+
   | Next Parameters                    | set of Records {...}       |
   +------------------------------------+----------------------------+
   | End of Message                     |                            |
   +====================================+============================+

        Figure 12: Structure of a PTP Registration Success message

   The message starts with the NTS Next Protocol Negotiation record
   which in this application always holds PTPv2.1.  Currently, the
   following NTS Message Version record always contains 1.0.  The next
   record characterizes the message type, in this case PTP Registration
   Success, see Figure 12.

   The following Current Parameters record is a container record
   containing in separate records all the security data needed to join
   and communicate in the secured PTP communication during the current
   validity period.  Figure 13 gives an example of data contained in
   that container as a response to PTP Registration Request.  For more
   details on the records contained in the Current Parameters container
   see Section 3.2.3.

Langer & Bermbach        Expires August 26, 2021               [Page 26]
Internet-Draft                   NTS4PTP                   February 2021

   Current Parameters Container record (PTP Registration Success)
   +==================================+========+=====================+
   | Record                           | Exemplary body contents      |
   +==================================+==============================+
   | AEAD Algorithm Negotiation       | AEAD_CMAC_512                |
   +----------------------------------+------------------------------+
   | Lifetime                         | 2,460s (=0h 41min)           |
   +----------------------------------+------------------------------+
   | Time until pdate                 | 0s                           |
   +----------------------------------+------------------------------+
   | Ticket Key                       | {binary data}                |
   +----------------------------------+------------------------------+
   | Ticket Key ID                    | 278                          |
   +----------------------------------+------------------------------+
   | Grace Period (optional)          | 10 seconds                   |
   +==================================+========+=====================+

      Figure 13: Exemplary contents of a Current Parameters Container
               record of a PTP Registration Success message

   If the registration request lies inside the update interval a Next
   Parameters Container record is appended giving all the security data
   needed in the upcoming validity period.  Its structure follows the
   same composition as the Current Parameters record.  The messages
   always end with an End of Message record.

2.3.6.  PTP Registration Revoke Message

   PTP Registration Revoke
   +===================================+=============================+
   | Record                            | Exemplary body contents     |
   +===================================+=============================+
   | NTS Next Protocol Negotiation     | PTPv2.1                     |
   +-----------------------------------+-----------------------------+
   | NTS Message Version               | 1.0                         |
   +-----------------------------------+-----------------------------+
   | NTS Message Type                  | PTP Registration Revoke     |
   +-----------------------------------+-----------------------------+
   | End of Message                    |                             |
   +===================================+=============================+

         Figure 14: Structure of a PTP Registration Revoke message

   The message starts with the NTS Next Protocol Negotiation record
   which in this application always holds PTPv2.1.  Currently, the
   following NTS Message Version record always contains 1.0.  The next

Langer & Bermbach        Expires August 26, 2021               [Page 27]
Internet-Draft                   NTS4PTP                   February 2021

   record characterizes the message type, in this case PTP Registration
   Revoke, see Figure 14.  The messages always end with an End of
   Message record.

3.  NTS Messages for PTP

   This chapter covers the structure of the NTS messages and the details
   of the respective payload.  The individual parameters are transmitted
   by NTS records, which are described in more detail in Section 3.2.
   In addition to the NTS records defined for NTP in IETF RFC8915,
   further records are required, which are listed in Table 2 and begin
   with Record Type 1024 (compare IETF RFC 8915, 7.6 Table: NTS Next
   Protocol Negotiation IDs).

3.1.  NTS Message Types

   This section repeats the composition of the specific NTS messages for
   the PTP key management in overview form.  The specification of the
   respective records from which the messages are constructed follows in
   Section 3.2.  The reference column in the tables refer to the
   specific subsections.

   The NTS messages must contain the records given for the particular
   message though not necessarily in the same sequence indicated.  Only
   the End of Message record is mandatory the final record.

   NOTE: Currently the NTS messages are not repeated here.  For the
   structure of the six NTS messages see Figures 7, 8, 10-12, 14.

3.2.  NTS Records

   NOTE: The detailed content of the NTS records defined as well as all
   necessary conditions of their usage are already specified.  Due to
   time constraints, they could not yet be transferred into the XML
   format.  So, currently they are missing in the descriptions below.

   The following subsections describe the specific NTS records used to
   construct the NTS messages for the PTP key management system in
   detail.  They appear in alphabetic sequence of their individual
   names.  See Section 3.1 for the application of the records in the
   respective messages.

   Note: For easier editing of the content, most of the descriptions in
   the following subsections are written as bullet points.

   Global rules:

Langer & Bermbach        Expires August 26, 2021               [Page 28]
Internet-Draft                   NTS4PTP                   February 2021

   o  The NTS Next Protocol Negotiation record MUST offer (at least)
      Protocol ID 1 for "PTPv2.1" (see Section 3.2.12).
   o  The NTS Message Version record MUST be v1.0.
   o  Note: Records must be used only in the mentioned messages.  Not
      elsewhere.
   o  The notational conventions of Section 1 MUST be followed.

3.2.1.  AEAD Negotiation

   This record is required in unicast mode and enables the negotiation
   of the AEAD algorithm needed to encrypt and decrypt the ticket.  The
   negotiation takes place between the PTP grantor and the NTS-KE server
   by using the NTS registration messages.  The structure and properties
   follow the record defined in IETF RFC 8915, 4.1.5.

   Content and conditions:

   ...

3.2.2.  Association Mode

   This record enables the NTS-KE server to distinguish between a group
   based request (multicast, mixed multicast/unicast, Group-of-2) or a
   unicast request.  A multicast request carries a group number, while a
   unicast request contains an identification attribute of the grantor
   (e.g.  IP address or PortIdentity).

   Content and conditions:

   ...

3.2.3.  Current Parameters Container

   This record is a simple container that can carry an arbitrary number
   of NTS records.  It holds all security parameters relevant for the
   current validity period.  The content as well as further conditions
   are defined by the respective NTS messages.  The order of the
   included records is arbitrary and the parsing rules are so far
   identical with the NTS message.  One exception: An End of Message
   record SHOULD NOT be present and MUST be ignored.  When the parser
   reaches the end of the Record Body quantified by the Body Length, all
   embedded records have been processed.

   Content and conditions:

   ...

Langer & Bermbach        Expires August 26, 2021               [Page 29]
Internet-Draft                   NTS4PTP                   February 2021

3.2.4.  End of Message

   The End of Message record is defined in IETF RFC8915, 4.

   "The record sequence in an NTS message SHALL be terminated by an "End
   of Message" record.  The requirement that all NTS-KE messages be
   terminated by an End of Message record makes them self-delimiting."

   Content and conditions:

   ...

3.2.5.  Error

   The Error record is defined in IETF RFC8915, 4.1.3.  In addition to
   the Error codes 0 to 2 specified there the following Error codes are
   defined:

   Content and conditions:

   ...

3.2.6.  Grace Period

   The Grace Period determines the time period in which expired security
   parameters may still be accepted.  It allows the verification of PTP
   messages, which have been secured with the previous key at the
   rotation time of the security parameters.

   Content and conditions:

   ...

3.2.7.  Lifetime

   This record specifies the lifetime of a defined set of parameters.
   The value contained in this record is counted down by the receiver of
   the NTS message every second.  When the value reaches zero, the
   parameters associated with this record are considered to have
   expired.

   Content and conditions:

   ...

Langer & Bermbach        Expires August 26, 2021               [Page 30]
Internet-Draft                   NTS4PTP                   February 2021

3.2.8.  MAC Algorithm Negotiation

   This optional record allows free negotiation of the MAC algorithm
   needed to generate the ICV.  Since multicast groups are restricted to
   a shared algorithm, this record is only used in unicast mode.

   Content and conditions:

   ...

3.2.9.  Next Parameters Container

   This record is a simple container that can carry an arbitrary number
   of NTS records.  It holds all security parameters relevant for the
   upcoming validity period.  The content as well as further conditions
   are defined by the respective NTS messages.  The order of the
   included records is arbitrary and the parsing rules are so far
   identical with the NTS message.  One exception: An End of Message
   record SHOULD NOT be present and MUST be ignored.  When the parser
   reaches the end of the Record Body quantified by the Body Length, all
   embedded records have been processed.

   Content and conditions:

   ...

3.2.10.  NTS Message Type

   This record enables the distinction between different NTS message
   types for PTP.

   Content and conditions:

   ...

3.2.11.  NTS Message Version

   This record enables the distinction between different NTS message
   versions for PTP.  It provides the possibility to update or extend
   the NTS messages in future specifications.

   Content and conditions:

   ...

Langer & Bermbach        Expires August 26, 2021               [Page 31]
Internet-Draft                   NTS4PTP                   February 2021

3.2.12.  NTS Next Protocol Negotiation

   The Next Protocol Negotiation record is defined in IETF RFC8915,
   4.1.2:

   "The Protocol IDs listed in the client's NTS Next Protocol
   Negotiation record denote those protocols that the client wishes to
   speak using the key material established through this NTS-KE server
   session.  Protocol IDs listed in the NTS-KE server's response MUST
   comprise a subset of those listed in the request and denote those
   protocols that the NTP server is willing and able to speak using the
   key material established through this NTS-KE server session.  The
   client MAY proceed with one or more of them.  The request MUST list
   at least one protocol, but the response MAY be empty."

   Content and conditions:

   ...

3.2.13.  Requesting PTP Identity

   This record allows the KE server to associate an NTS unicast request
   of a requester with a registered grantor based on their address or
   identifier (e.g.: IP address or PortIdentity).  Furthermore, this
   record allows the grantor to verify the origin of a secured PTP
   message that is currently transmitting a ticket.

   Content and conditions:

   ...

3.2.14.  Security Association

   This record contains the information "how" specific PTP message types
   must be secured.  It comprises all dynamic (negotiable) values
   necessary to construct the AUTHENTICATION TLV (IEEE Std 1588-2019,
   16.14.3).  Static values and flags, such as the secParamIndicator,
   are described in more detail in Section 5.

   Content and conditions:

   ...

3.2.15.  Security Policies

   This record contains the information "which" PTP message types must
   be secured.

Langer & Bermbach        Expires August 26, 2021               [Page 32]
Internet-Draft                   NTS4PTP                   February 2021

   Content and conditions:

   ...

3.2.16.  Ticket

   This record contains the parameters of the selected AEAD algorithm,
   as well as an encrypted Ticket Container record.  The encrypted
   record contains all the necessary security parameters that the
   grantor needs for a secured PTP unicast connection to the requester.
   The ticket container is encrypted by the NTS-KE server with the
   symmetric ticket key which is also known to the grantor.  The
   requester is not able to decrypt the ticket container.

   Content and conditions:

   ...

3.2.17.  Ticket Container

   This record is a simple container that can carry an arbitrary number
   of NTS records.  It contains all relevant security parameters that a
   grantor needs for a secured unicast connection.  The order of the
   included records is arbitrary and the parsing rules are so far
   identical with the NTS message.  One exception: An End of Message
   record SHOULD NOT be present and MUST be ignored.  When the parser
   reaches the end of the Record Body quantified by the Body Length, all
   embedded records have been processed.  The Ticket Container record
   serves as input parameter for the AEAD operation (see Section 3.2.1)
   and is transmitted encrypted within the Ticket record (see
   Section 3.2.16).

   Content and conditions:

   ...

3.2.18.  Ticket Key

   This record contains the ticket key, which together with an AEAD
   algorithm is used to encrypt and decrypt the ticket.

   Content and conditions:

   ...

Langer & Bermbach        Expires August 26, 2021               [Page 33]
Internet-Draft                   NTS4PTP                   February 2021

3.2.19.  Ticket Key ID

   The Ticket Key ID record is a unique identifier that allows a grantor
   to identify the associated ticket key.

   Content and conditions:

   ...

3.2.20.  Time until Update

   The Time until Update (TuU) record specifies the point in time at
   which new security parameters are available.  The value contained in
   this record is counted down by the receiver of the NTS message every
   second.  When the value reaches zero, the update period begins and
   NTS response messages typically contain the Next Parameter Container
   record for a certain period of time (see also Section 2.2.1).

   Content and conditions:

   ...

3.3.  Additional Mechanisms

   This section provides information about the use of the negotiated
   AEAD algorithm as well as the generation of the security policy
   pointers.

3.3.1.  AEAD Operation

   General information about AEAD:

   ...

3.3.2.  SA/SP Management

   This section describes the requirements and recommendations attached
   to SA/SP management, as well as details about the generation of
   identifiers.

   Requirements for the Security Association Database management:

   ...

Langer & Bermbach        Expires August 26, 2021               [Page 34]
Internet-Draft                   NTS4PTP                   February 2021

4.  New TICKET TLV for PTP Messages

   ...

5.  AUTHENTICATION TLV Parameters

   ...

6.  IANA Considerations

   Considerations should be made ...

   ...

7.  Security Considerations

   ...

8.  Acknowledgements

   The authors would like to thank ...

9.  References

9.1.  Normative References

   [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>.

   [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>.

   [RFC7808]  Douglass, M. and C. Daboo, "Time Zone Data Distribution
              Service", RFC 7808, DOI 10.17487/RFC7808, March 2016,
              <https://www.rfc-editor.org/info/rfc7808>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Langer & Bermbach        Expires August 26, 2021               [Page 35]
Internet-Draft                   NTS4PTP                   February 2021

9.2.  Informative References

   [IEEE-1588-2008]
              "IEEE Standard for a Precision Clock Synchronization
              Protocol for Networked Measurement and Control Systems",
              n.d..

   [ntppool]  "pool.ntp.org: the internet cluster of ntp servers", n.d.,
              <https://www.ntppool.org>.

Authors' Addresses

   Martin Langer
   Ostfalia University of Applied Sciences

   Email: mart.langer@ostfalia.de

   Rainer Bermbach
   Ostfalia University of Applied Sciences

   Email: r.bermbach@ostfalia.de

Langer & Bermbach        Expires August 26, 2021               [Page 36]