[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Time Protocol                                          M. Langer
Internet-Draft                                               R. Bermbach
Intended status: Standards Track                     Ostfalia University
Expires: September 9, 2021                                 March 8, 2021


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

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 September 9, 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 September 9, 2021               [Page 1]


Internet-Draft                   NTS4PTP                      March 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 . . . .   8
       2.1.2.  NTS Message Exchange for the Ticket-based Approach  .  10
     2.2.  General Topics  . . . . . . . . . . . . . . . . . . . . .  13
       2.2.1.  Key Update Process  . . . . . . . . . . . . . . . . .  13
       2.2.2.  Key Generation  . . . . . . . . . . . . . . . . . . .  16
       2.2.3.  Time Information of the KE Server . . . . . . . . . .  17
       2.2.4.  Certificates  . . . . . . . . . . . . . . . . . . . .  17
       2.2.5.  Upfront Configuration . . . . . . . . . . . . . . . .  18
         2.2.5.1.  Security Parameters . . . . . . . . . . . . . . .  18
         2.2.5.2.  Key Lifetimes . . . . . . . . . . . . . . . . . .  19
         2.2.5.3.  Certificates  . . . . . . . . . . . . . . . . . .  19
         2.2.5.4.  Authorization . . . . . . . . . . . . . . . . . .  19
         2.2.5.5.  Transparent Clocks  . . . . . . . . . . . . . . .  20
         2.2.5.6.  Start-up considerations . . . . . . . . . . . . .  21
     2.3.  Overview of NTS Messages and their Structure for Use with
           PTP . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
       2.3.1.  PTP Key Request Message . . . . . . . . . . . . . . .  23
       2.3.2.  PTP Key Grant Message . . . . . . . . . . . . . . . .  24
       2.3.3.  PTP Refusal Message . . . . . . . . . . . . . . . . .  26
       2.3.4.  PTP Registration Request Message  . . . . . . . . . .  27
       2.3.5.  PTP Registration Success Message  . . . . . . . . . .  28
       2.3.6.  PTP Registration Revoke Message . . . . . . . . . . .  29
   3.  NTS Messages for PTP  . . . . . . . . . . . . . . . . . . . .  30
     3.1.  NTS Message Types . . . . . . . . . . . . . . . . . . . .  31
     3.2.  NTS Records . . . . . . . . . . . . . . . . . . . . . . .  36
       3.2.1.  AEAD Algorithm Negotiation  . . . . . . . . . . . . .  36
       3.2.2.  Association Mode  . . . . . . . . . . . . . . . . . .  38
       3.2.3.  Current Parameters Container  . . . . . . . . . . . .  41
       3.2.4.  End of Message  . . . . . . . . . . . . . . . . . . .  43
       3.2.5.  Error . . . . . . . . . . . . . . . . . . . . . . . .  43
       3.2.6.  Grace Period  . . . . . . . . . . . . . . . . . . . .  44
       3.2.7.  Lifetime  . . . . . . . . . . . . . . . . . . . . . .  45
       3.2.8.  MAC Algorithm Negotiation . . . . . . . . . . . . . .  46
       3.2.9.  Next Parameters Container . . . . . . . . . . . . . .  48
       3.2.10. NTS Message Type  . . . . . . . . . . . . . . . . . .  49
       3.2.11. NTS Message Version . . . . . . . . . . . . . . . . .  49
       3.2.12. NTS Next Protocol Negotiation . . . . . . . . . . . .  50
       3.2.13. Requesting PTP Identity . . . . . . . . . . . . . . .  51
       3.2.14. Security Association  . . . . . . . . . . . . . . . .  53



Langer & Bermbach       Expires September 9, 2021               [Page 2]


Internet-Draft                   NTS4PTP                      March 2021


       3.2.15. Security Policies . . . . . . . . . . . . . . . . . .  54
       3.2.16. Ticket  . . . . . . . . . . . . . . . . . . . . . . .  56
       3.2.17. Ticket Container  . . . . . . . . . . . . . . . . . .  57
       3.2.18. Ticket Key  . . . . . . . . . . . . . . . . . . . . .  58
       3.2.19. Ticket Key ID . . . . . . . . . . . . . . . . . . . .  59
       3.2.20. Time until Update . . . . . . . . . . . . . . . . . .  60
     3.3.  Additional Mechanisms . . . . . . . . . . . . . . . . . .  61
       3.3.1.  AEAD Operation  . . . . . . . . . . . . . . . . . . .  61
       3.3.2.  SA/SP Management  . . . . . . . . . . . . . . . . . .  63
   4.  New TICKET TLV for PTP Messages . . . . . . . . . . . . . . .  64
   5.  AUTHENTICATION TLV Parameters . . . . . . . . . . . . . . . .  66
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  67
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  67
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  67
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  67
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  67
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  68
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  69

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 [RFC8915].  Its NTS Key Establishment sub-protocol is
   secured by the Transport Layer Security (TLS 1.3, IETF RFC 8446
   [RFC8446]) 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
   [Langer_et_al._2020] for immediate security processing complementing
   the exemplary GDOI proposal in the IEEE Std 1588-2019



Langer & Bermbach       Expires September 9, 2021               [Page 3]


Internet-Draft                   NTS4PTP                      March 2021


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



Langer & Bermbach       Expires September 9, 2021               [Page 4]


Internet-Draft                   NTS4PTP                      March 2021


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


































Langer & Bermbach       Expires September 9, 2021               [Page 5]


Internet-Draft                   NTS4PTP                      March 2021


   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

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

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

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



Langer & Bermbach       Expires September 9, 2021               [Page 6]


Internet-Draft                   NTS4PTP                      March 2021


      _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
   (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.






Langer & Bermbach       Expires September 9, 2021               [Page 7]


Internet-Draft                   NTS4PTP                      March 2021


   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,
   practically implementing a special group-based unicast communication
   mode, the group-of-2 (Go2) mode.










Langer & Bermbach       Expires September 9, 2021               [Page 8]


Internet-Draft                   NTS4PTP                      March 2021


   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
   in that mode is performed using multicast addresses.  If the latter
   is undesirable, unicast addresses can be used but the particular IP




Langer & Bermbach       Expires September 9, 2021               [Page 9]


Internet-Draft                   NTS4PTP                      March 2021


   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
   ([IEEE1588-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 September 9, 2021              [Page 10]


Internet-Draft                   NTS4PTP                      March 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 September 9, 2021              [Page 11]


Internet-Draft                   NTS4PTP                      March 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 September 9, 2021              [Page 12]


Internet-Draft                   NTS4PTP                      March 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 September 9, 2021              [Page 13]


Internet-Draft                   NTS4PTP                      March 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 September 9, 2021              [Page 14]


Internet-Draft                   NTS4PTP                      March 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 September 9, 2021              [Page 15]


Internet-Draft                   NTS4PTP                      March 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 September 9, 2021              [Page 16]


Internet-Draft                   NTS4PTP                      March 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 [RFC8915], 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 September 9, 2021              [Page 17]


Internet-Draft                   NTS4PTP                      March 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 September 9, 2021              [Page 18]


Internet-Draft                   NTS4PTP                      March 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 September 9, 2021              [Page 19]


Internet-Draft                   NTS4PTP                      March 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 September 9, 2021              [Page 20]


Internet-Draft                   NTS4PTP                      March 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 [RFC8915], 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 [RFC8915]:

      _"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
      _[RFC7301])_, 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
      _[RFC8446].

      _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 September 9, 2021              [Page 21]


Internet-Draft                   NTS4PTP                      March 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



Langer & Bermbach       Expires September 9, 2021              [Page 22]


Internet-Draft                   NTS4PTP                      March 2021


   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.

   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
























Langer & Bermbach       Expires September 9, 2021              [Page 23]


Internet-Draft                   NTS4PTP                      March 2021


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



Langer & Bermbach       Expires September 9, 2021              [Page 24]


Internet-Draft                   NTS4PTP                      March 2021


   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

   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.




















Langer & Bermbach       Expires September 9, 2021              [Page 25]


Internet-Draft                   NTS4PTP                      March 2021


   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 September 9, 2021              [Page 26]


Internet-Draft                   NTS4PTP                      March 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 September 9, 2021              [Page 27]


Internet-Draft                   NTS4PTP                      March 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 September 9, 2021              [Page 28]


Internet-Draft                   NTS4PTP                      March 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 September 9, 2021              [Page 29]


Internet-Draft                   NTS4PTP                      March 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 1 below and
   begin with Record Type 1024 (compare IETF RFC 8915 [RFC8915], 7.6.
   Network Time Security Key Establishment Record Types Registry).

   +-----------+-------------------------+-----------------------------+
   | NTS       | Description             | Reference                   |
   | Record    |                         |                             |
   | Types     |                         |                             |
   +-----------+-------------------------+-----------------------------+
   | 0         | End of Message          | [RFC8915], section 4.1.1,   |
   |           |                         | this document,              |
   |           |                         | Section 3.2.4               |
   | 1         | NTS Next Protocol       | [RFC8915], section 4.1.2,   |
   |           | Negotiation             | this document,              |
   |           |                         | Section 3.2.12              |
   | 2         | Error                   | [RFC8915], section 4.1.3,   |
   |           |                         | this document,              |
   |           |                         | Section 3.2.5               |
   | 3         | Warning                 | [RFC8915], section 4.1.4    |
   | 4         | AEAD Algorithm          | [RFC8915], section 4.1.5,   |
   |           | Negotiation             | this document,              |
   |           |                         | Section 3.2.1               |
   | 5         | New Cookie for NTPv4    | [RFC8915], section 4.1.6    |
   |           | (not needed for PTP)    |                             |
   | 6         | NTPv4 Server            | [RFC8915], section 4.1.7    |
   |           | Negotiation (not needed |                             |
   |           | for PTP)                |                             |
   | 7         | NTPv4 Port Negotiation  | [RFC8915], section 4.1.8    |
   |           | (not needed for PTP)    |                             |
   | 8 - 1023  | Reserved for NTP        |                             |
   |           |                         |                             |
   | 1024      | Association Mode        | This document,              |
   |           |                         | Section 3.2.2               |
   | 1025      | Current Parameters      | This document,              |
   |           | Container               | Section 3.2.3               |
   | 1026      | Grace Period            | This document,              |
   |           |                         | Section 3.2.6               |
   | 1027      | Lifetime                | This document,              |



Langer & Bermbach       Expires September 9, 2021              [Page 30]


Internet-Draft                   NTS4PTP                      March 2021


   |           |                         | Section 3.2.7               |
   | 1028      | MAC Algorithm           | This document,              |
   |           | Negotiation             | Section 3.2.8               |
   | 1029      | Next Parameters         | This document,              |
   |           | Container               | Section 3.2.9               |
   | 1030      | NTS Message Type        | This document,              |
   |           |                         | Section 3.2.10              |
   | 1031      | NTS Message Version     | This document,              |
   |           |                         | Section 3.2.11              |
   | 1032      | Requesting PTP Identity | This document,              |
   |           |                         | Section 3.2.13              |
   | 1033      | Security Association    | This document,              |
   |           |                         | Section 3.2.14              |
   | 1034      | Security Policies       | This document,              |
   |           |                         | Section 3.2.15              |
   | 1035      | Ticket                  | This document,              |
   |           |                         | Section 3.2.16              |
   | 1036      | Ticket Container        | This document,              |
   |           |                         | Section 3.2.17              |
   | 1037      | Ticket Key              | This document,              |
   |           |                         | Section 3.2.18              |
   | 1038      | Ticket Key ID           | This document,              |
   |           |                         | Section 3.2.19              |
   | 1039      | Time until Update       | This document,              |
   |           |                         | Section 3.2.20              |
   |           |                         |                             |
   | 1040 -    | Unassigned              |                             |
   | 16383     |                         |                             |
   | 16384 -   | Reserved for Private or | [RFC8915]                   |
   | 32767     | Experimental Use        |                             |
   +-----------+-------------------------+-----------------------------+

           Table 1: NTS Key Establishment record types registry

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.






Langer & Bermbach       Expires September 9, 2021              [Page 31]


Internet-Draft                   NTS4PTP                      March 2021


                             *PTP Key Request*

   +---------------------+---------------+-------+---------------------+
   | NTS Record Name     | Comm. Type*   |  Use  | Reference           |
   +---------------------+---------------+-------+---------------------+
   | NTS Next Protocol   | Multicast /   | mand. | This document,      |
   | Negotiation         | Unicast       |       | Section 3.2.12      |
   | NTS Message Version | Multicast /   | mand. | This document,      |
   |                     | Unicast       |       | Section 3.2.11      |
   | NTS Message Type    | Multicast /   | mand. | This document,      |
   |                     | Unicast       |       | Section 3.2.10      |
   | Association Mode    | Multicast /   | mand. | This document,      |
   |                     | Unicast       |       | Section 3.2.2       |
   | MAC Algorithm       | Unicast       |  opt. | This document,      |
   | Negotiation         |               |       | Section 3.2.8       |
   | Requesting PTP      | Unicast       | mand. | This document,      |
   | Identity            |               |       | Section 3.2.13      |
   | End of Message      | Multicast /   | mand. | This document,      |
   |                     | Unicast       |       | Section 3.2.4       |
   +---------------------+---------------+-------+---------------------+

     * The Communication Type column refers to the intended use of the
       particular record for the respective PTP communication mode.

         Table 2: Record structure of the PTP Key Request message

                              *PTP Key Grant*

   +-----------------+--------------+---------------+------------------+
   | NTS Record Name | Comm. Type   |      Use      | Reference        |
   +-----------------+--------------+---------------+------------------+
   | NTS Next        | Multicast /  |     mand.     | This document,   |
   | Protocol        | Unicast      |               | Section 3.2.12   |
   | Negotiation     |              |               |                  |
   | NTS Message     | Multicast /  |     mand.     | This document,   |
   | Version         | Unicast      |               | Section 3.2.11   |
   | NTS Message     | Multicast /  |     mand.     | This document,   |
   | Type            | Unicast      |               | Section 3.2.10   |
   | Current         | Multicast /  |     mand.     | This document,   |
   | Parameters      | Unicast      |               | Section 3.2.3    |
   | Container       |              |               |                  |
   | Next Parameters | Multicast /  |      opt.     | This document,   |
   | Container       | Unicast      | (conditional) | Section 3.2.9    |
   | End of Message  | Multicast /  |     mand.     | This document,   |
   |                 | Unicast      |               | Section 3.2.4    |
   +-----------------+--------------+---------------+------------------+

          Table 3: Record structure of the PTP Key Grant message



Langer & Bermbach       Expires September 9, 2021              [Page 32]


Internet-Draft                   NTS4PTP                      March 2021


   The structure of the respective container records (Current Parameters
   Container and Next Parameters Container) used in the PTP Key Grant
   message is given below:

   +----------------------+--------------+-------+---------------------+
   | NTS Record Name      | Comm. Type   |  Use  | Reference           |
   +----------------------+--------------+-------+---------------------+
   | Security Policies    | Multicast /  | mand. | This document,      |
   |                      | Unicast      |       | Section 3.2.15      |
   | Security Association | Multicast /  | mand. | This document,      |
   | (one or more)        | Unicast      |       | Section 3.2.14      |
   | Lifetime             | Multicast /  | mand. | This document,      |
   |                      | Unicast      |       | Section 3.2.7       |
   | Time until Update    | Multicast /  | mand. | This document,      |
   |                      | Unicast      |       | Section 3.2.20      |
   | Grace Period         | Multicast /  |  opt. | This document,      |
   |                      | Unicast      |       | Section 3.2.6       |
   | Ticket Key ID        | Unicast      | mand. | This document,      |
   |                      |              |       | Section 3.2.19      |
   | Ticket               | Unicast      | mand. | This document,      |
   |                      |              |       | Section 3.2.16      |
   +----------------------+--------------+-------+---------------------+

            Table 4: Record structure of the container records

   The encrypted Ticket Container within the Ticket record also includes
   a set of records listed below:

   +----------------------+--------------+-------+---------------------+
   | NTS Record Name      | Comm. Type   |  Use  | Reference           |
   +----------------------+--------------+-------+---------------------+
   | Requesting PTP       | Unicast      | mand. | This document,      |
   | Identity             |              |       | Section 3.2.13      |
   | Security Policies    | Multicast /  | mand. | This document,      |
   |                      | Unicast      |       | Section 3.2.15      |
   | Security Association | Multicast /  | mand. | This document,      |
   | (one or more)        | Unicast      |       | Section 3.2.14      |
   | Lifetime             | Multicast /  | mand. | This document,      |
   |                      | Unicast      |       | Section 3.2.7       |
   | Time until Update    | Multicast /  | mand. | This document,      |
   |                      | Unicast      |       | Section 3.2.20      |
   | Grace Period         | Multicast /  |  opt. | This document,      |
   |                      | Unicast      |       | Section 3.2.6       |
   +----------------------+--------------+-------+---------------------+

    Table 5: Record structure of the enctypted Ticket container record





Langer & Bermbach       Expires September 9, 2021              [Page 33]


Internet-Draft                   NTS4PTP                      March 2021


                               *PTP Refusal*

   +---------------------+---------------+-------+---------------------+
   | NTS Record Name     | Comm. Type    |  Use  | Reference           |
   +---------------------+---------------+-------+---------------------+
   | NTS Next Protocol   | Multicast /   | mand. | This document,      |
   | Negotiation         | Unicast       |       | Section 3.2.12      |
   | NTS Message Version | Multicast /   | mand. | This document,      |
   |                     | Unicast       |       | Section 3.2.11      |
   | NTS Message Type    | Multicast /   | mand. | This document,      |
   |                     | Unicast       |       | Section 3.2.10      |
   | Error               | Multicast /   | mand. | This document,      |
   |                     | Unicast       |       | Section 3.2.5       |
   | End of Message      | Multicast /   | mand. | This document,      |
   |                     | Unicast       |       | Section 3.2.4       |
   +---------------------+---------------+-------+---------------------+

           Table 6: Record structure of the PTP Refusal message

                        *PTP Registration Request*

   +---------------------+---------------+-------+---------------------+
   | NTS Record Name     | Comm. Type    |  Use  | Reference           |
   +---------------------+---------------+-------+---------------------+
   | NTS Next Protocol   | Multicast /   | mand. | This document,      |
   | Negotiation         | Unicast       |       | Section 3.2.12      |
   | NTS Message Version | Multicast /   | mand. | This document,      |
   |                     | Unicast       |       | Section 3.2.11      |
   | NTS Message Type    | Multicast /   | mand. | This document,      |
   |                     | Unicast       |       | Section 3.2.10      |
   | Requesting PTP      | Unicast       | mand. | This document,      |
   | Identity            |               |       | Section 3.2.13      |
   | AEAD Algorithm      | Unicast       | mand. | This document,      |
   | Negotiation         |               |       | Section 3.2.1       |
   | MAC Algorithm       | Unicast       |  opt. | This document,      |
   | Negotiation         |               |       | Section 3.2.8       |
   | End of Message      | Multicast /   | mand. | This document,      |
   |                     | Unicast       |       | Section 3.2.4       |
   +---------------------+---------------+-------+---------------------+

     Table 7: Record structure of the PTP Registration Request message










Langer & Bermbach       Expires September 9, 2021              [Page 34]


Internet-Draft                   NTS4PTP                      March 2021


                        *PTP Registration Success*

   +------------------+-------------+---------------+------------------+
   | NTS Record Name  | Comm. Type  |      Use      | Reference        |
   +------------------+-------------+---------------+------------------+
   | NTS Next         | Multicast / |     mand.     | This document,   |
   | Protocol         | Unicast     |               | Section 3.2.12   |
   | Negotiation      |             |               |                  |
   | NTS Message      | Multicast / |     mand.     | This document,   |
   | Version          | Unicast     |               | Section 3.2.11   |
   | NTS Message Type | Multicast / |     mand.     | This document,   |
   |                  | Unicast     |               | Section 3.2.10   |
   | Current          | Multicast / |     mand.     | This document,   |
   | Parameters       | Unicast     |               | Section 3.2.3    |
   | Container        |             |               |                  |
   | Next Parameters  | Multicast / |     mand.     | This document,   |
   | Container        | Unicast     | (conditional) | Section 3.2.9    |
   | End of Message   | Multicast / |     mand.     | This document,   |
   |                  | Unicast     |               | Section 3.2.4    |
   +------------------+-------------+---------------+------------------+

     Table 8: Record structure of the PTP Registration Success message

   The structure of the respective container records (Current Parameters
   Container and Next Parameters Container) used in the PTP Registration
   Success message is given below:

   +--------------------+---------------+-------+----------------------+
   | NTS Record Name    | Comm. Type    |  Use  | Reference            |
   +--------------------+---------------+-------+----------------------+
   | AEAD Algorithm     | Unicast       | mand. | This document,       |
   | Negotiation        |               |       | Section 3.2.1        |
   | Lifetime           | Multicast /   | mand. | This document,       |
   |                    | Unicast       |       | Section 3.2.7        |
   | Time until Update  | Multicast /   | mand. | This document,       |
   |                    | Unicast       |       | Section 3.2.20       |
   | Grace Period       | Multicast /   |  opt. | This document,       |
   |                    | Unicast       |       | Section 3.2.6        |
   | Ticket Key ID      | Unicast       | mand. | This document,       |
   |                    |               |       | Section 3.2.19       |
   | Ticket             | Unicast       | mand. | This document,       |
   |                    |               |       | Section 3.2.16       |
   +--------------------+---------------+-------+----------------------+

       Table 9: Record structure of the container records in th PTP
                       Regsitration Success message





Langer & Bermbach       Expires September 9, 2021              [Page 35]


Internet-Draft                   NTS4PTP                      March 2021


                         *PTP Registration Revoke*

   +---------------------+---------------+-------+---------------------+
   | NTS Record Name     | Comm. Type    |  Use  | Reference           |
   +---------------------+---------------+-------+---------------------+
   | NTS Next Protocol   | Multicast /   | mand. | This document,      |
   | Negotiation         | Unicast       |       | Section 3.2.12      |
   | NTS Message Version | Multicast /   | mand. | This document,      |
   |                     | Unicast       |       | Section 3.2.11      |
   | NTS Message Type    | Multicast /   | mand. | This document,      |
   |                     | Unicast       |       | Section 3.2.10      |
   | End of Message      | Multicast /   | mand. | This document,      |
   |                     | Unicast       |       | Section 3.2.4       |
   +---------------------+---------------+-------+---------------------+

     Table 10: Record structure of the PTP Registration Revoke message

3.2.  NTS Records

   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:

   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 Algorithm 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 [RFC8915], 4.1.5.

   Content and conditions:





Langer & Bermbach       Expires September 9, 2021              [Page 36]


Internet-Draft                   NTS4PTP                      March 2021


   o  The record has a Record Type number of 4 and the Critical Bit MAY
      be set.
   o  The record body contains a sequence of 16-bit unsigned integers in
      network byte order:

      *Supported AEAD Algorithms = {AEAD 1 || AEAD 2 || ...}*

   o  Each integer represents a numeric identifier of an AEAD algorithm
      registered by the IANA.  (https://www.iana.org/assignments/aead-
      parameters/aead-parameters.xhtml)
   o  Duplicate identifiers SHOULD NOT be included.
   o  Grantor and NTS-KE server MUST support at least the
      AEAD_AES_SIV_CMAC_256 algorithm.
   o  A list of recommended AEAD algorithms is shown in the following
      table.
   o  Other AEAD algorithms MAY also be used.

   +----------+------------------------+-------+-----------+-----------+
   | Numeric  | AEAD Algorithm         | Use   |    Key    | Reference |
   | ID       |                        |       |   Length  |           |
   |          |                        |       |  (Octets) |           |
   +----------+------------------------+-------+-----------+-----------+
   | 15       | AEAD_AES_SIV_CMAC_256  | Mand. |     16    | [RFC5297] |
   | 16       | AEAD_AES_SIV_CMAC_385  | Opt.  |     24    | [RFC5297] |
   | 18       | AEAD_AES_SIV_CMAC_512  | Opt.  |     32    | [RFC5297] |
   | 32 -     | Unassigned             |       |           |           |
   | 32767    |                        |       |           |           |
   | 32768 -  | Reserved for Private   |       |           | [RFC5116] |
   | 65535    | or Experimental Use    |       |           |           |
   +----------+------------------------+-------+-----------+-----------+

                         Table 11: AEAD algorithms

   o  In a PTP Registration Request message, this record MUST be
      contained exactly once.
   o  In this message at least the AEAD_AES_SIV_CMAC_256 algorithm MUST
      be included.
   o  If multiple AEAD algorithms are supported, the grantor SHOULD put
      the algorithm identifiers in descending priority in the record
      body.
   o  Strong algorithms with higher bit lengths SHOULD have higher
      priority.

   o  In a PTP Registration Success message, this record MUST be
      contained exactly once in the Current Parameters Container record
      and exactly once in the Next Parameters Container record.
   o  The Next Parameters Container MUST be present only during the
      update period.



Langer & Bermbach       Expires September 9, 2021              [Page 37]


Internet-Draft                   NTS4PTP                      March 2021


   o  The KE server SHOULD choose the highest priority AEAD algorithm
      from the request message that grantor and KE server support.
   o  The KE server MAY ignore the priority and choose a different
      algorithm that grantor and KE server support.
   o  In a PTP Registration Success message, this record MUST contain
      exactly one AEAD algorithm.
   o  The selected algorithm MAY differ in the Current Parameters
      Container and Next Parameters Container records.

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:

   o  In a PTP Key Request message, this record MUST be contained
      exactly once.
   o  The record has a Record Type number of 1024 and the Critical Bit
      MAY be set.
   o  The record body SHALL consist of two data fields:

                  +-------------------+--------+--------+
                  | Field             | Octets | Offset |
                  +-------------------+--------+--------+
                  | Association Type  |   2    |   0    |
                  | Association Value |   A    |   2    |
                  +-------------------+--------+--------+

                           Table 12: Association

   o  The Association Type is a 16-bit unsigned integer.
   o  The length of Association Value depends on the value of
      Association Type.
   o  All data in the fields are stored in network byte order.
   o  The type numbers of Association Type as well as the length and
      content of Association Value are shown in the following table and
      more details are given below.










Langer & Bermbach       Expires September 9, 2021              [Page 38]


Internet-Draft                   NTS4PTP                      March 2021


   +--------------+----------+-------------+----------------+----------+
   | Description  |  Assoc.  | Association | Association    |  Assoc.  |
   |              |   Type   | Mode        | Value Content  |  Value   |
   |              |  Number  |             |                |  Octets  |
   +--------------+----------+-------------+----------------+----------+
   | Group        |    0     | Multicast / | Group Number   |    5     |
   |              |          | Unicast*    |                |          |
   | IPv4         |    1     | Unicast     | IPv4 address   |    4     |
   |              |          |             | of the target  |          |
   |              |          |             | port           |          |
   | IPv6         |    2     | Unicast     | IPv6 address   |    16    |
   |              |          |             | of the target  |          |
   |              |          |             | port           |          |
   | 802.3        |    3     | Unicast     | MAC address of |    6     |
   |              |          |             | the target     |          |
   |              |          |             | port           |          |
   | PortIdentity |    4     | Unicast     | PortIdentity   |    10    |
   |              |          |             | of the target  |          |
   |              |          |             | PTP entity     |          |
   +--------------+----------+-------------+----------------+----------+

   Unicast*: predefined groups of two (Group-of-2, Go2, see Group entry
                                  below)

                        Table 13: Association Types

   Group:

   o  This association type allows a PTP instance to join a PTP
      multicast group.
   o  A group is identified by the PTP domain, the PTP profile (sdoId)
      and a sub-group attribute (see table below).
   o  The PTP domainNumber is an 8-bit unsigned integer in the closed
      range 0 to 255.
   o  The sdoId of a PTP domain is a 12-bit unsigned integer in the
      closed range 0 to 4095:

      *  The most significant 4 bits are named the majorSdoId.
      *  The least significant 8 bits are named the minorSdoId.
      *  Reference: IEEE Std 1588-2019, 7.1.1

      *sdoId = {majorSdoId || minorSdoId}*

   o  The subGroup is 16-bit unsigned integer, which allows the division
      of a PTP multicast network into separate groups, each with
      individual security parameters.
   o  This also allows manually configured unicast connections (Group-
      of-2), which can include transparent clocks as well.



Langer & Bermbach       Expires September 9, 2021              [Page 39]


Internet-Draft                   NTS4PTP                      March 2021


   o  The subGroup number is defined manually by the administrator.
   o  Access to the groups is controlled by authorization procedures of
      the PTP devices (see Section 2.2.5.4).
   o  If no subgroups are required (=multicast mode), this attribute
      MUST contain the value zero.

   o  The group number is eventually formed by concatenation of the
      following values:

      *group number = {domainNumber || 4 bit zero padding || sdoId ||
      subGroup}*

                           This is equvalent to:

      +---------------------+--------------------+--------+--------+
      |      Bits 7 - 4     |     Bits 3 - 0     | Octets | Offset |
      +---------------------+--------------------+--------+--------+
      | domainNumber (high) | domainNumber (low) |   1    |   0    |
      |     zero padding    |     majorSdoId     |   1    |   1    |
      |  minorSdoId (high)  |  minorSdoId (low)  |   1    |   2    |
      |   subgroup (high)   |   subGroup (low)   |   2    |   4    |
      +---------------------+--------------------+--------+--------+

                        Table 14: Group Association

   IPv4:

   o  This Association Type allows a requester to establish a PTP
      unicast connection to the desired grantor.
   o  The Association Value contains the IPv4 address of the target PTP
      entity.
   o  The total length is 4 octets.

   IPv6:

   o  This Association Type allows a requester to establish a PTP
      unicast connection to the desired grantor.
   o  The Association Value contains the IPv6 address of the target PTP
      entity.
   o  The total length is 16 octets.

   802.3:

   o  This Association Type allows a requester to establish a PTP
      unicast connection to the desired grantor.
   o  The Association Value contains the MAC address of the Ethernet
      port of the target PTP entity.
   o  The total length is 6 octets.



Langer & Bermbach       Expires September 9, 2021              [Page 40]


Internet-Draft                   NTS4PTP                      March 2021


   o  This method supports the 802.3 mode in PTP, where no UDP/IP stack
      is used.

   PortIdentity:

   o  This Association Type allows a requester to establish a PTP
      unicast connection to the desired grantor.
   o  The Association Value contains the PortIdentity of the target PTP
      entity.
   o  The total length is 10 octets.

   o  The PortIdentity consists of the attributes clockIdentity and
      portNumber:


      *PortIdentity = {clockIdentity || portNumber}*

   o  The clockIdentity is an 8 octet array and the portNumber is a
      16-bit unsigned integer.
   o  Source: IEEE Std 1588-2019, 5.3.5, 7.5

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:

   o  The record has a Record Type number of 1025 and the Critical Bit
      MAY be set.

   o  In a PTP Key Grant message, this record MUST be contained exactly
      once.
   o  The record body is defined as a set of records and MAY contain the
      following records:









Langer & Bermbach       Expires September 9, 2021              [Page 41]


Internet-Draft                   NTS4PTP                      March 2021


   +-----------------------+--------------+-------+--------------------+
   | NTS Record Name       | Comunication | Use   | Reference          |
   |                       | Type         |       |                    |
   +-----------------------+--------------+-------+--------------------+
   | Security Policies     | Multicast /  | Mand. | This document,     |
   |                       | Unicast      |       | Section 3.2.15     |
   | Security Associations | Multicast /  | Mand. | This document,     |
   | (one or more)         | Unicast      |       | Section 3.2.14     |
   | Lifetime              | Multicast /  | Mand. | This document,     |
   |                       | Unicast      |       | Section 3.2.7      |
   | Time until Update     | Multicast /  | Mand. | This document,     |
   |                       | Unicast      |       | Section 3.2.20     |
   | Grace Period          | Multicast /  | Opt.  | This document,     |
   |                       | Unicast      |       | Section 3.2.6      |
   | Ticket Key ID         | Unicast      | Mand. | This document,     |
   |                       |              |       | Section 3.2.19     |
   | Ticket                | Unicast      | Mand. | This document,     |
   |                       |              |       | Section 3.2.16     |
   +-----------------------+--------------+-------+--------------------+

     Table 15: Current Parameters Container for PTP Key Grant message

   o  The records Security Policies, Lifetime and Time until Update MUST
      be contained exactly once.
   o  The number of the Security Association records depends on the
      content of the Security Policies record (see Section 3.2.15).
   o  At least one Security Association record MUST be included.
   o  The Grace Period record is optional and MAY be absent.
   o  If it is present, it MUST be included exactly once.
   o  In order to establish a unicast connection with the PTP Key Grant
      message, the records Ticket Key ID and Ticket MUST be contained
      exactly once.
   o  If the requester wants to join a multicast group, the records
      Ticket Key ID and Ticket MUST NOT be included.

   o  In a PTP Registration Success message, the Current Parameters
      Container record MUST be contained exactly once.
   o  The record body MAY contain the following records:













Langer & Bermbach       Expires September 9, 2021              [Page 42]


Internet-Draft                   NTS4PTP                      March 2021


   +----------------------------+-------+------------------------------+
   | NTS Record Name            | Use   | Reference                    |
   +----------------------------+-------+------------------------------+
   | AEAD Algorithm Negotiation | Mand. | This document, Section 3.2.1 |
   | Lifetime                   | Mand. | This document, Section 3.2.7 |
   | Time until Update          | Mand. | This document,               |
   |                            |       | Section 3.2.20               |
   | Grace Period               | Opt.  | This document, Section 3.2.6 |
   | Ticket Key ID              | Mand. | This document,               |
   |                            |       | Section 3.2.19               |
   | Ticket                     | Mand. | This document,               |
   |                            |       | Section 3.2.16               |
   +----------------------------+-------+------------------------------+

    Table 16: Current Parameters Container for PTP Registration Success
                                  Message

   o  The records AEAD Algorithm Negotiation, Lifetime, Time until
      Update, Ticket Key ID and Ticket Key MUST be contained exactly
      once.
   o  The Grace Period record is optional and MAY be absent.
   o  If it is present, it MUST be included exactly once.

3.2.4.  End of Message

   The End of Message record is defined in IETF RFC8915 [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:

   o  The record has a Record Type number of 0 and a zero-length body.
   o  The Critical Bit MUST be set.
   o  This record MUST occur exactly once as the final record of every
      NTS request and response message.
   o  This record SHOULD NOT be included in the container records and
      MUST be ignored if present.
   o  See also: IETF RFC8915, 4.1.1

3.2.5.  Error

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




Langer & Bermbach       Expires September 9, 2021              [Page 43]


Internet-Draft                   NTS4PTP                      March 2021


       +---------------+------------------------------------------+
       | Error Code    | Description                              |
       +---------------+------------------------------------------+
       | 0             | Unrecognized Critical Record             |
       | 1             | Bad Request                              |
       | 2             | Internal Server Error                    |
       | 3             | Requester not Authorized                 |
       | 4             | Grantor not Registered                   |
       | 5 - 32767     | Unassigned                               |
       | 32768 - 65535 | Reserved for Private or Experimental Use |
       +---------------+------------------------------------------+

                           Table 17: Error Codes

   Content and conditions:

   o  The record has a Record Type number of 2 and body length of two
      octets consisting of an unsigned 16-bit integer in network byte
      order, denoting an error code.
   o  The Critical Bit MUST be set.

   o  The Error code 3 "Requester not Authorized" is sent by the KE
      server if the requester is not authorized to join the desired
      multicast group.
   o  This Error code MUST NOT be included as a response to PTP
      Registration Request message.

   o  The Error code 4 "Grantor not Registered" is sent by the KE server
      when the requester wants to establish a unicast connection to a
      grantor that is not registered with the KE server.
   o  This Error code MUST NOT be included as a response to a PTP Key
      Request message.

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:

   o  The record has a Record Type number of 1026 and the Critical Bit
      SHOULD NOT be set.
   o  The record body consists of a 16-bit unsigned integer in network
      byte order.
   o  This value contains the transition time in seconds in which an
      expired key MAY still be accepted.



Langer & Bermbach       Expires September 9, 2021              [Page 44]


Internet-Draft                   NTS4PTP                      March 2021


   o  A time of zero seconds is valid.
   o  If this optional record is absent, a default time of zero seconds
      is used unless a PTP profile defines something else.

   o  The Grace Period record MAY only appear as part of a PTP Key Grant
      or PTP Registration Success message.
   o  In a PTP Key Grant message, the Grace Period MAY be in the Current
      Parameters Container and Next Parameters Container records, as
      well as a part of the encrypted Ticket Container (if present).
   o  The Grace Period record MUST NOT appear more than once in each
      container or ticket.

   o  In a PTP Registration Success message, the Grace Period record MAY
      be present in the Current Parameters Container record as well as
      in the Next Parameters Container record.
   o  The Grace Period MUST NOT be included more than once in each of
      those container records.

   o  The Next Parameters Container MUST be present only during the
      update period.

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:

   o  The record has a Record Type number of 1027 and the Critical Bit
      MAY be set.
   o  The record body consists of a 32-bit unsigned integer in network
      byte order, denoting the expiration time of specific parameters in
      seconds.

   o  The maximum value is set by the NTS-KE administrator or the PTP
      profile.
   o  In conjunction with a PTP unicast establishment, the Lifetime of
      the unicast key, the ticket key and registration lifetime of a
      grantor with the KE server MUST be identical.

   o  The Lifetime record MAY only appear as part of a PTP Key Grant or
      PTP Registration Success message.
   o  In both messages, the Next Parameters Container MUST be present
      only during the update period.




Langer & Bermbach       Expires September 9, 2021              [Page 45]


Internet-Draft                   NTS4PTP                      March 2021


   o  In a PTP Key Grant message, the Lifetime record MUST be included
      exactly once in the Current Parameters Container and Next
      Parameters Container records, as well as in the encrypted Ticket
      Container (only present in a unicast PTP Key Grant message).
   o  In a PTP Registration Success message, the Lifetime MUST be
      included exactly once in both records, Current Parameters
      Container and Next Parameters Container.

   Notes:

   o  Requests during the currently running lifetime will receive
      respectively adapted count values.
   o  The lifetime is a counter that is decremented and marks the
      expiration of defined parameters when the value reaches zero.
   o  The realization is implementation-dependent and can be done for
      example by a secondly decrementing.
   o  It must be ensured that jumps (e.g. by adjustment of the local
      clock) are avoided.
   o  The use of a monotonic clock is suitable for this.
   o  Furthermore, it is to be considered which consequences the
      drifting of the local clock can cause.
   o  With sufficiently small values of the lifetime (<12 hours), this
      factor should be negligible.

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:

   o  The record has a Record Type number of 1028 and the Critical Bit
      MAY be set.
   o  The record body contains a sequence of 16-bit unsigned integers in
      network byte order.

      *Supported MAC Algorithms = {MAC 1 || MAC 2 || ...}*

   o  Each integer represents a MAC Algorithm Type defined in the table
      below.
   o  Duplicate identifiers SHOULD NOT be included.
   o  Each PTP node MUST support at least the HMAC-SHA256-128 algorithm.








Langer & Bermbach       Expires September 9, 2021              [Page 46]


Internet-Draft                   NTS4PTP                      March 2021


   +------------+---------------------+------------+-------------------+
   | MAC        | MAC Algorithm       | ICV Length | Reference         |
   | Algorithm  |                     |  (octets)  |                   |
   | Types      |                     |            |                   |
   +------------+---------------------+------------+-------------------+
   | 0          | HMAC-SHA256-128     |     16     | [FIPS-PUB-198-1], |
   |            |                     |            | [IEEE1588-2019]   |
   | 1          | HMAC-SHA256         |     32     | [FIPS-PUB-198-1]  |
   | 2          | AES-CMAC            |     16     | [RFC4493]         |
   | 3          | AES-GMAC-128        |     16     | [RFC4543]         |
   | 4          | AES-GMAC-192        |     24     | [RFC4543]         |
   | 5          | AES-GMAC-256        |     32     | [RFC4543]         |
   | 6 - 32767  | Unassigned          |            |                   |
   | 32768 -    | Reserved for        |            |                   |
   | 65535      | Private or          |            |                   |
   |            | Experimental Use    |            |                   |
   +------------+---------------------+------------+-------------------+

                         Table 18: MAC Algorithms

   In PTP multicast mode:

   o  This record is not necessary, since all PTP nodes in a multicast
      group MUST support the same MAC algorithm.
   o  Therefore, this record SHOULD NOT be included in a PTP Key Request
      massage and the NTS-KE server MUST ignore this record.
   o  Unless this is specified by a PTP profile, the HMAC-SHA256-128
      algorithm SHALL be used by default.

   In PTP unicast mode:

   o  In a PTP Key Request message, this record MAY be contained if the
      requester wants a unicast connection to a specific grantor.
   o  The requester MUST NOT send more than one record of this type.
   o  If this record is present, at least the HMAC-SHA256-128 MAC
      algorithm MUST be included.
   o  If multiple MAC algorithms are supported, the requester SHOULD put
      the desired algorithm identifiers in descending priority in the
      record body.
   o  Strong algorithms with higher bit lengths SHOULD have higher
      priority.
   o  The default MAC algorithm (HMAC-SHA256-128) MAY be omitted in the
      record.

   o  In a PTP Registration Request message, this record MUST be present
      and the grantor MUST include all supported MAC algorithms in any
      order.




Langer & Bermbach       Expires September 9, 2021              [Page 47]


Internet-Draft                   NTS4PTP                      March 2021


   o  The KE server selects the algorithm after receiving a PTP Key
      Request message in unicast mode.
   o  The KE server SHOULD choose the highest priority MAC algorithm
      from the request message that grantor and requester support.
   o  The KE server MAY ignore the priority and choose a different
      algorithm that grantor and requester support.
   o  If the MAC Algorithm Negotiation record is not within the PTP Key
      Request message, the KE server MUST choose the default algorithm
      HMAC-SHA256-128.

   Initialization Vector (IV)

   o  If GMAC is to be supported as a MAC algorithm, then an
      Initialization Vector (IV) must be constructed according to IETF
      RFC 4543, 3.1.
   o  Therefore, the IV MUST be eight octets long and MUST NOT be
      repeated for a specific key.
   o  This can be achieved, for example, by using a counter.

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:

   o  The record has a Record Type number of 1029 and the Critical Bit
      MAY be set.
   o  The record body is defined as a set of records.
   o  The structure of the record body and all conditions MUST be
      identical to the rules described in Section 3.2.3 of this
      document.

   o  In both the PTP Key Grant and PTP Registration Success message,
      this record MUST be contained exactly once during the update
      period.
   o  Outside the update period, this record MUST NOT be included.
   o  In multicast mode, this record MAY also be missing if the
      requester is to be explicitly excluded from a multicast group
      after the security parameter rotation process by the KE server.




Langer & Bermbach       Expires September 9, 2021              [Page 48]


Internet-Draft                   NTS4PTP                      March 2021


   o  The update period starts with the expiration of the Time until
      Update timer, which is stored in the Current Parameter Container
      record.
   o  In the PTP Key Grant and PTP Registration Success message, the
      expiration of the Lifetime marks the end of the update period.
   o  More details are described in Section 2.2.1.

3.2.10.  NTS Message Type

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

   Content and conditions:

   o  The record has a Record Type number of 1030 and the Critical Bit
      MUST be set.
   o  The record body is a 16-bit unsigned integer in network byte
      order, denoting the type of the current NTS message for PTP.
   o  The message types are defined in the following table.
   o  More details about the messages are described in Section 2.3

   +-------------------------+-----------------------------------------+
   | NTS Message Type Number | NTS Message Name                        |
   +-------------------------+-----------------------------------------+
   | 0                       | PTP Key Request                         |
   | 1                       | PTP Key Grant                           |
   | 2                       | PTP Refusal                             |
   | 3                       | PTP Registration Request                |
   | 4                       | PTP Registration Success                |
   | 5                       | PTP Registration Revoke                 |
   | 6 - 32767               | Unassigned                              |
   | 32768 - 65535           | Reserved for Private or Experimental    |
   |                         | Use                                     |
   +-------------------------+-----------------------------------------+

                    Table 19: NTS message type numbers

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:

   o  The record has a Record Type number of 1031 and the Critical Bit
      MUST be set.




Langer & Bermbach       Expires September 9, 2021              [Page 49]


Internet-Draft                   NTS4PTP                      March 2021


   o  The record body consists of a tuple of two 8-bit unsigned integers
      in network byte order.
   o  The first octet represents the major version and the second octet
      the minor version.

      *NTS Message Version = {major version || minor version}*

   o  The representable version is therefore in the range 0.0 to 255.255
      (e.g. v1.4 = 0104h).
   o  All NTS messages for PTPv2.1 described in this document are in
      version number 1.0.
   o  Thus the record body MUST match 0100h.

3.2.12.  NTS Next Protocol Negotiation

   The Next Protocol Negotiation record is defined in IETF RFC8915
   [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:

   o  The record has a Record Type number of 1 and the Critical Bit MUST
      be set.
   o  The record body consists of a sequence of 16-bit unsigned integers
      in network byte order.

      *Record body = {Protocol ID 1 || Protocol ID 2 || ...}*

   o  Each integer represents a Protocol ID from the IANA "Network Time
      Security Next Protocols" registry as shown in the table below.
   o  For NTS requests messages for PTPv2.1, only the Protocol ID for
      PTPv2.1 SHOULD be included.
   o  This prevents the mixing of records for different time protocols.








Langer & Bermbach       Expires September 9, 2021              [Page 50]


Internet-Draft                   NTS4PTP                      March 2021


   +-------------+--------------------------------------+--------------+
   | Protocol ID | Protocol Name                        | Reference    |
   +-------------+--------------------------------------+--------------+
   | 0           | Network Time Protocol version 4      | [RFC8915],   |
   |             | (NTPv4)                              | 7.7          |
   | 1           | Precision Time Protocol version 2.1  | This         |
   |             | (PTPv2.1)                            | document     |
   | 2 - 32767   | Unassigned                           |              |
   | 32768 -     | Reserved for Private or Experimental |              |
   | 65535       | Use                                  |              |
   +-------------+--------------------------------------+--------------+

                      Table 20: NTS next protocol IDs

   Possible NTP/PTP conflict:

   o  The support of multiple protocols in this record may lead to the
      problem that records in NTS messages can no longer be assigned to
      a specific time protocol.
   o  For example, an NTS request could include records for both NTP and
      PTP.
   o  However, NTS4NTP does not use NTS message types and the End of
      Message record is also not defined for the case of multiple NTS
      requests in one TLS message.
   o  This leads to the mixing of the records in the NTS messages.

   o  A countermeasure is the use of only a single time protocol in the
      NTS Next Protocol Negotiation record that explicitly assigns the
      NTS message to a specific time protocol.
   o  When using NTS-secured NTP and NTS-secured PTP, two separate NTS
      requests i.e. two separate TLS sessions MUST be made.

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:

   o  The record has a Record Type number of 1032 and the Critical Bit
      MAY be set.
   o  The record body consists of a set of Association Types together
      with their respective Association Values.





Langer & Bermbach       Expires September 9, 2021              [Page 51]


Internet-Draft                   NTS4PTP                      March 2021


                +---------------------+--------+---------+
                | Field               | Octets |  Offset |
                +---------------------+--------+---------+
                | Association Type 1  |   2    |    0    |
                | Association Value 1 |   A1   |    2    |
                | Association Type 2  |   2    |   A1+2  |
                | Association Value 2 |   A2   |   A1+4  |
                | Association Type n  |   A2   | A1+A2+4 |
                | Association Value n |   An   | A1+A2+6 |
                +---------------------+--------+---------+

                  Table 21: Requesting PTP identity list

   o  Structure and values are based on the contents defined in
      Section 3.2.2 of this document.

      *  Therefore, the Association Type is a 16-bit unsigned integer.
      *  The length and content of Association Value depends on the
         value of Association Type.
      *  All bytes are stored in network byte order and the rules in
         Section 3.2.2 MUST be followed.

   o  A Requesting PTP Identity record MUST contain at least one
      association tuple (type + value).
   o  This record can contain several association tuples in any order.
   o  It MUST NOT contain more than one association tuple of the same
      type.

   o  In a PTP Key Request message, this record MUST be contained
      exactly once in the unicast mode, which depends on the content of
      the Association Mode record of this message.
   o  In this case the Requesting PTP Identity record MUST contain
      exactly one association tuple.
   o  This association tuple MUST contain one identification feature of
      the PTP requestor (IPv4, IPv6, 802.3 or PortIdentity).
   o  The association tuple MUST NOT contain the Group association type
      0.

   o  In a PTP Key Grant message, this record MUST be contained exactly
      once in the encrypted Ticket Container.
   o  This record MUST contain exactly one association tuple.
   o  The record body MUST be identical to the Requesting PTP Identity
      record of the related PTP Key Request message.
   o  Therefore, the association tuple MUST NOT contain the Group
      association type 0.

   o  In a PTP Registration Request message, this record MUST be
      included exactly once.



Langer & Bermbach       Expires September 9, 2021              [Page 52]


Internet-Draft                   NTS4PTP                      March 2021


   o  The grantor SHOULD add the following association tuples as far as
      they are available: IPv4, IPv6, 802.3 and PortIdentity.
   o  The grantor MUST NOT include the Group association type 0.

   o  This allows a requester to be assigned to a grantor, regardless of
      whether the requester specifies IPv4, IPv6, 802.3 or the
      PortIdentity of the grantor in its PTP Key Request message.

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:

   o  The record has a Record Type number of 1033 and the Critical Bit
      MAY be set.
   o  The record body is a sequence of various parameters in network
      byte order and MUST be formatted according to the following table:

             +----------------------------+--------+--------+
             | Field                      | Octets | Offset |
             +----------------------------+--------+--------+
             | Security Parameter Pointer |   1    |   0    |
             | Integrity Algorithm Type   |   2    |   1    |
             | Key ID                     |   4    |   3    |
             | Key Length                 |   2    |   7    |
             | Key                        |   K    |   9    |
             +----------------------------+--------+--------+

                   Table 22: Security Association record

   o  In a PTP Key Grant message, the Security Association record MUST
      be included at least once in the Current Parameters Container
      record and the Next Parameters Container record.
   o  In unicast mode, the Security Association record MUST be included
      at least once in the encrypted Ticket Container as well.
   o  The Next Parameters Container record MUST be present only during
      the update period.
   o  The Ticket record MUST be present in unicast mode and MUST NOT be
      present in multicast mode.
   o  The number of Security Association records in the respective
      container or Ticket Container depends on the content of the
      associated Security Policies (see also Section 3.2.15).




Langer & Bermbach       Expires September 9, 2021              [Page 53]


Internet-Draft                   NTS4PTP                      March 2021


   Security Parameter Pointer

   o  The Security Parameter Pointer (SPP) is an 8-bit unsigned integer
      in the closed range 0 to 255.
   o  This value enables the mutual assignment of SA, SP and
      AUTHENTICATION TLVs.
   o  The generation and management of the SPP is controlled by the KE
      server (see Section 3.3.2).

   Integrity Algorithm Type

   o  This value is a 16-bit unsigned integer in network byte order.
   o  The possible values are equivalent to the MAC Algorithm Types from
      the table in Section 3.2.8.
   o  The value used depends on the negotiated or predefined MAC
      algorithm.

   Key ID

   o  The Key ID is a 32-bit unsigned integer in network byte order.
   o  The field length is oriented towards the structure of the
      AUTHENTICATION TLV.
   o  The generation and management of the Key ID is controlled by the
      KE server.
   o  The NTS-KE server MUST ensure that every Key ID is unique.

      *  The value can be either a random number or an enumeration.
      *  Previous Key IDs SHOULD NOT be reused for a certain number of
         rotation periods or a defined period of time (see Section 3.3).

   Key Length

   o  This value is a 16-bit unsigned integer in network byte order,
      denoting the length of the key.

   Key

   o  The value is a sequence of octets with a length of Key Length.
   o  This symmetric key is needed together with the MAC algorithm to
      calculate the ICV.
   o  It can be both a group key (multicast mode) or a unicast key
      (unicast mode).

3.2.15.  Security Policies

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




Langer & Bermbach       Expires September 9, 2021              [Page 54]


Internet-Draft                   NTS4PTP                      March 2021


   Content and conditions:

   o  The record has a Record Type number of 1034 and the Critical Bit
      MAY be set.
   o  The record body contains a sequence of tuples in network byte
      order:

      *Record body = {Security Policies = {tuple 1 || tuple 2 || tuple
      3 || tuple n}}*

   o  Each tuple has a length of 2 octets and consists of a sequence of
      a PTP Message Type and a Security Parameter Pointer.

             +-----------------------------+--------+--------+
             | Field                       | Octets | Offset |
             +-----------------------------+--------+--------+
             | PTP Message Type            |   1    |   0    |
             | Security Parameter pointers |   1    |   1    |
             +-----------------------------+--------+--------+

                      Table 23: Security Policy tuple

   o  The PTP Message Type is an 8-bit unsigned integer.
   o  The most significant 4 bits are zero-padded and the least
      significant 4 bits are the PTP message type:

   Structure of PTP Message Type (see also [IEEE1588-2019], 13.3.2.3,
   table 36):

                    +--------------+------------------+
                    | Bits 7 - 4   | Bits 3 - 0       |
                    +--------------+------------------+
                    | Zero Padding | PTP Message type |
                    +--------------+------------------+

                        Table 24: PTP Message Type

   o  The Security Parameter Pointer (SPP) is an 8-bit unsigned integer
      in the closed range 0 to 255.

   o  The record body MUST contain at least one tuple.
   o  A tuple associates a PTP message type with an SPP.
   o  Every PTP message type that is mentioned in the Security Policies
      record MUST be secured.
   o  Thus, a PTP message type that is not included in this record MUST
      NOT contain an AUTHENTICATION TLV and will not be secured.
   o  Multiple tuples with the same PTP message type MUST NOT be
      included.



Langer & Bermbach       Expires September 9, 2021              [Page 55]


Internet-Draft                   NTS4PTP                      March 2021


   o  Multiple tuples MAY use the same SPP to use a shared security
      association or an individual one.

   o  For the number of contained and different SPPs in the Security
      Policies record, the same number of security associations MUST be
      created.
   o  The number of security associations determines the number of
      Security Associations records in the respective container record
      (e.g.  Current Parameters Container).

   o  In a PTP Key Grant message, this record MUST be included exactly
      once each in the Current Parameters Container record, the Next
      Parameters Container record as well as the encrypted Ticket
      Container record.
   o  The Next Parameters Container record MUST be present only during
      the update period.
   o  The Ticket record MUST be present in unicast mode and MUST NOT be
      present in multicast mode.

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:

   o  The record has a Record Type number of 1035 and the Critical Bit
      MAY be set.
   o  The record body consists of several data fields and MUST be
      formatted as follows.

          +-----------------------------------+--------+--------+
          | Field                             | Octets | Offset |
          +-----------------------------------+--------+--------+
          | Nonce Length                      |   2    |   0    |
          | Nonce                             |   N    |   2    |
          | Encrypted Ticket Container Length |   2    |  N+2   |
          | Encrypted Ticket Container        |   C    |  N+4   |
          +-----------------------------------+--------+--------+

                  Table 25: Structure of a Ticket record





Langer & Bermbach       Expires September 9, 2021              [Page 56]


Internet-Draft                   NTS4PTP                      March 2021


   o  In a PTP Key Grant message, this record MUST be included exactly
      once each in the Current Parameters Container record and the Next
      Parameters Container record if the requester wants a unicast
      communication to a specific grantor.
   o  The Next Parameters Container record MUST be present only during
      the update period.

   Nonce Length

   o  This is a 16-bit unsigned integer in network byte order, denoting
      the length of the Nonce field.

   Nonce

   o  This field contains the Nonce needed for the AEAD operation.
   o  The length and conditions attached to the Nonce depend on the AEAD
      algorithm used.
   o  More details and conditions are described in Section 3.3.1.

   Encrypted Ticket Container Length

   o  This is a 16-bit unsigned integer in network byte order, denoting
      the length of the Encrypted Ticket Container field.

   Encrypted Ticket Container

   o  This field contains the output of the AEAD operation
      ("Ciphertext") after the encryption process of the respective
      Ticket Container record.
   o  The plaintext of this field is described in Section 3.2.17.
   o  More details about the AEAD process and the required input data
      are described in Section 3.3.1.

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:



Langer & Bermbach       Expires September 9, 2021              [Page 57]


Internet-Draft                   NTS4PTP                      March 2021


   o  The record has a Record Type number of 1036 and the Critical Bit
      MAY be set.
   o  The record body is defined as a set of records and MAY contain the
      following records.

   +-------------------------+----------------+------------------------+
   | NTS Record Name         |      Use       |       Reference        |
   +-------------------------+----------------+------------------------+
   | Requesting PTP Identity |     mand.      |     This document,     |
   |                         |                |     Section 3.2.13     |
   | Security Policies       |     mand.      |     This document,     |
   |                         |                |     Section 3.2.15     |
   | Security Association    |     mand.      |     This document,     |
   | (one or more)           |                |     Section 3.2.14     |
   | Lifetime                |     mand.      |     This document,     |
   |                         |                |     Section 3.2.7      |
   | Time until Update       |     mand.      |     This document,     |
   |                         |                |     Section 3.2.20     |
   | Grace Period            |      opt.      |     This document,     |
   |                         | (conditional)  |     Section 3.2.6      |
   +-------------------------+----------------+------------------------+

                 Table 26: Structure of a Ticket Container

   o  The records Requesting PTP Identity, Security Policies, Lifetime
      and Time until Update MUST be contained exactly once.
   o  The number of the Security Association records depends on the
      content of the Security Policies record (see Section 3.2.15).
   o  All records within this Ticket Container (except Requesting PTP
      Identity) MUST be identical to the records of the respective
      Current Parameter Container.
   o  All records within this Ticket Container (except Requesting PTP
      Identity) MUST be identical to the records of the respective Next
      Parameter Container.
   o  The presence of the Grace Period record also depends on the
      respective Current/Next Parameter container.
   o  If a Grace Period record is present in the Current/Next Parameter
      container, it MUST also be present in the respective Ticket
      Container.
   o  If it is not present, it MUST NOT be included in the Ticket
      Container.

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 September 9, 2021              [Page 58]


Internet-Draft                   NTS4PTP                      March 2021


   o  The record has a Record Type number of 1037 and the Critical Bit
      MAY be set.
   o  The record body consists of a sequence of octets holding the
      symmetric key for the AEAD function.
   o  The generation and length of the key MUST meet the requirement of
      the associated AEAD algorithm.

   o  In a PTP Registration Success message, this record MUST be
      included exactly once each in the Current Parameters Container
      record and the Next Parameters Container record.
   o  The Next Parameters Container record MUST be present only during
      the update period.

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:

   o  The record has a Record Type number of 1038 and the Critical Bit
      MAY be set.
   o  The record body consists of a 32-bit unsigned integer in network
      byte order.
   o  The generation and management of the ticket key ID is controlled
      by the NTS-KE server.
   o  The NTS-KE server must ensure that every ticket key has a unique
      number.

      *  The value is implementation dependent and MAY be either a
         random number, a hash value or an enumeration.
      *  Previous IDs SHOULD NOT be reused for a certain number of
         rotation periods or a defined period of time.
   o  In a PTP Key Grant message, this record MUST be included exactly
      once each in the Current Parameters Container record and the Next
      Parameters Container record if a unicast connection is to be
      established.
   o  If the requester wishes to join a multicast group, the Ticket Key
      ID record MUST NOT be included in the container records.
   o  In a PTP Registration Success message, this record MUST be
      included exactly once in the Current Parameters Container record
      and once in the Next Parameters Container record.
   o  The Next Parameters Container record MUST be present only during
      the update period.
   o  The Ticket record MUST be present in unicast mode and MUST NOT be
      present in multicast mode.





Langer & Bermbach       Expires September 9, 2021              [Page 59]


Internet-Draft                   NTS4PTP                      March 2021


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:

   o  The record has a Record Type number of 1039 and the Critical Bit
      MAY be set.
   o  The record body consists of a 32-bit unsigned integer in network
      byte order, denoting the begin of the update period in seconds.

   o  The value in the TuU MUST be less than the value in the associated
      Lifetime record (in the same container or ticket).
   o  If the value in the TuU is greater than zero in the Current
      Parameter Container, the corresponding message MUST NOT contain a
      Next Parameters Container.
   o  If the value in the TuU is zero in the Current Parameters
      Container, the corresponding NTS message MAY contain the Next
      Parameters Container record.

   o  The Time until Update record MAY only appear as part of a PTP Key
      Grant or PTP Registration Success message.
   o  In both messages, the Next Parameters Container MUST be present
      only during the update period.
   o  In a PTP Key Grant message, the Time until Update record MUST be
      included exactly once each in the Current Parameters Container and
      Next Parameters Container records, as well as in the encrypted
      Ticket Container (only present in a unicast PTP Key Grant
      message).
   o  In a PTP Registration Success message, the Time until Update MUST
      be included exactly once each in the Current Parameters Container
      and Next Parameters Container records.
   o  In both messages, the Next Parameters Container record MUST be
      present only during the update period.

   Notes:

   o  Requests during the currently running lifetime will receive
      respectively adapted count values for Time until Update.
   o  During the update period the value for TuU in the Current
      Parameters Container will be zero.





Langer & Bermbach       Expires September 9, 2021              [Page 60]


Internet-Draft                   NTS4PTP                      March 2021


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:

   o  The AEAD operation enables the integrity protection and the
      optional encryption of the given data, depending on the input
      parameters.
   o  While the structure of the AEAD output after the securing
      operation is determined by the negotiated AEAD algorithm, it
      usually contains an authentication tag in addition to the actual
      ciphertext.
   o  The authentication tag provides the integrity protection, whereas
      the ciphertext represents the encrypted data.
   o  The AEAD algorithms supported in this document (see Section 3.2.1)
      always return an authentication tag with a fixed length of 16
      octets.
   o  The size of the following ciphertext is equal to the length of the
      plaintext.
   o  The concatenation of authentication tag and ciphertext always form
      the unit "Ciphertext":

      *Ciphertext = {authentication tag || ciphertext}*

   o  Hint: The term "Ciphertext" is distinguished between upper and
      lower case letters.
   o  The following text always describes "Ciphertext".
   o  Separation of the information concatenated in Ciphertext is not
      necessary at any time.

   o  Six parameters are relevant for the execution of an AEAD
      operation:

      *  AEAD (...): is the AEAD algorithm itself
      *  A: Associated Data
      *  N: Nonce
      *  K: Key
      *  P: Plaintext
      *  C: Ciphertext
   o  The protection and encryption of the data is done as follows: C =
      AEAD (A, N, K, P)
   o  Therefore, the output of the AEAD function is the Ciphertext.




Langer & Bermbach       Expires September 9, 2021              [Page 61]


Internet-Draft                   NTS4PTP                      March 2021


   o  The verification and decryption of the data is done this way: P =
      AEAD (A, N, K, C)
   o  The output of the AEAD function is the Plaintext if the integrity
      verification is successful.

   AEAD algorithm and input/output values for the Ticket record:

   o  AEAD (...):

      *  The AEAD algorithm that is negotiated between grantor and NTS-
         KE server during the registration phase.
      *  A list of the AEAD algorithms considered in this document can
         be found in Section 3.2.1.
   o  Associated Data:

      *  The Associated Data is an optional AEAD parameter and can be of
         any length and content, as long as the AEAD algorithm does not
         give any further restrictions.
      *  In addition to the Plaintext, this associated data is also
         included in the integrity protection.
      *  When encrypting or decrypting the Ticket Container record, this
         parameter MUST remain empty.
   o  Nonce:

      *  Corresponds to the value from the Nonce field in the Ticket
         (Section 3.2.16).
      *  The requirements and conditions depend on the selected AEAD
         algorithm.
      *  For the AEAD algorithms defined in Section 3.2.1 (with numeric
         identifiers 15, 16, 17), a cryptographically secure random
         number MUST be used.
      *  Due to the block length of the internal AES algorithm, the
         Nonce SHOULD have a length of 16 octets.
   o  Key:

      *  This is the symmetric key required by the AEAD algorithm.
      *  The key length depends on the selected algorithm.
      *  When encrypting or decrypting the Ticket Container record, the
         ticket key MUST be used.
   o  Plaintext:

      *  This parameter contains the data to be encrypted and secured.
      *  For AEAD encryption, this corresponds to the Ticket Container
         record with all records inside.
      *  This is also the output of the AEAD operation after the
         decryption process.
   o  Ciphertext:




Langer & Bermbach       Expires September 9, 2021              [Page 62]


Internet-Draft                   NTS4PTP                      March 2021


      *  Corresponds to the value from the Encrypted Ticket Container
         field in the Ticket (Section 3.2.16).
      *  The Ciphertext is the output of the AEAD operation after the
         encryption process.
      *  This is also the input parameter for the AEAD decryption
         operation.

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:

   o  The structure and management of the Security Association Database
      (SAD) are implementation-dependent both on the NTS-KE server and
      on the PTP devices.
   o  An example of this, as well as other recommendations, are
      described in Annex B.
   o  A PTP device MUST contain exactly one SAD and Security Policy
      Database (SPD).
   o  For multicast and Group-of-2 connections, SPPs MUST NOT occur more
      than once in the SAD of a PTP device.
   o  For unicast connections, SPPs MAY occur more than once in the SAD
      of a PTP device.
   o  The NTS-KE server MUST ensure that SPPs can be uniquely assigned
      to a multicast group or unicast connection.
   o  This concerns both the NTS-KE server and all PTP devices assigned
      to the NTS-KE server.

   SPP generation:

      The generation of the SPP always takes place on the NTS-KE server
      and enables the identification of a corresponding SA.  The value
      of the SPP can be either a random number or an enumeration.  An
      SPP used in any multicast group MUST NOT occur in any other
      multicast group or unicast connection.  If a multicast group or
      unicast connection is removed by the NTS-KE server, the released
      SPPs MAY be reused for new groups or unicast connections.  Before
      reusing an SPP, the NTS-KE server MUST ensure that the SPP is no
      longer in use in the PTP network (e.g.  within Next Parameter).
      In different PTP devices, an SPP used in a unicast connection MAY
      also occur in another unicast connection, as long as they are not
      used in multicast groups.

   Key/Key ID generation:




Langer & Bermbach       Expires September 9, 2021              [Page 63]


Internet-Draft                   NTS4PTP                      March 2021


      The generation of the keys MUST be performed by using a
      Cryptographically Secure Pseudorandom Number Generator (CSPRNG) on
      the NTS-KE server (see also Section 2.2.2).  The length of the
      keys depends on the MAC algorithm used.  The generation and
      management of the Key ID is also controlled by the KE server.  The
      NTS-KE server MUST ensure that every Key ID is unique at least
      within an SA with multiple parameter sets.  The value of the Key
      ID is implementation dependent and MAY be either a random number,
      a hash value or an enumeration.  Key IDs of expired keys MAY be
      reused but SHOULD NOT be reused for a certain number of rotation
      periods or a defined period of time.  Before reusing a Key ID, the
      NTS-KE server MUST be ensured that the Key ID is no longer in use
      in the PTP network (e.g. within Next Parameter).

4.  New TICKET TLV for PTP Messages

   Once a PTP port is registered as a grantor for association in unicast
   mode another PTP port (requester) can associate with it by first
   requesting a key from the KE server with Association Type in the
   Association Mode record set to one of the values 1 to 4 (IPv4, IPv6,
   802.3 or PortIdentity), and Association Values to the related address
   of the registered port.  With the reception of the key grant the
   requester obtains the unicast key and the Ticket record containing
   the encrypted ticket container (see Section 2.1.2 and
   Section 3.2.16).  The ticket container (see Section 3.2.17) includes
   the identification of the requester, the SAs along with the unicast
   key as well as the Lifetime/Time until Update data.

   To provide the grantor with the security data, the requester sends a
   secured unicast request to the grantor, e.g. an Announce request (=
   Signaling message with a REQUEST_UNICAST_TRANSMISSION TLV with
   Announce as messageType in the TLV), which is secured with the
   unicast key.

   To accomplish that, the requester sends a newly defined TICKET TLV
   with the Ticket container embedded and the AUTHENTICATION TLV with
   the PTP unicast negotiation message.  The TICKET TLV must be
   positioned before the AUTHENTICATION TLV to include the TICKET TLV in
   the securing by the ICV.  The receiving grantor decrypts the Ticket
   container from the TICKET TLV getting access to the information
   therein.  With the contained unicast key, the grantor checks the
   requester identity and the authenticity of the request message.

   Thereafter all secured unicast messages between grantor and requester
   will use the unicast key for generating the ICV in the AUTHENTICATION
   TLV for authentication of the message until the unicast key expires.





Langer & Bermbach       Expires September 9, 2021              [Page 64]


Internet-Draft                   NTS4PTP                      March 2021


   If the requester's identity does not match with the Requesting PTP
   Identity record in the Ticket Container and/or the ICV in the
   AUTHENTICATION TLV is not identical to the generated ICV by the
   grantor, then the unicast request message shall be denied.

   The TICKET TLV structure is given in Table 27 below.

                    +---------------+--------+--------+
                    | Field         | Octets | Offset |
                    +---------------+--------+--------+
                    | tlvType       |   2    |   0    |
                    | lengthField   |   2    |   2    |
                    | Ticket record |   T    |   4    |
                    +---------------+--------+--------+

                   Table 27: Structure of the TICKET TLV

   To comply with the TLV structure of IEEE Std 1588-2019
   ([IEEE1588-2019], 14.1) the TICKET TLV is structured as presented in
   Table 27 with a newly defined tlvType, a respective length field and
   the Ticket record (see Section 3.2.16) containing the encrypted
   Ticket container.  Eventually it may be necessary to define the
   Ticket TLV externally to IEEE 1588 SA.  Then the structure should
   follow IEEE Std 1588-2019 ([IEEE1588-2019], 14.3) to define a new
   standard organization extension TLV as presented in Table 28 below.

                 +---------------------+--------+--------+
                 | Field               | Octets | Offset |
                 +---------------------+--------+--------+
                 | tlvType             |   2    |   0    |
                 | lengthField         |   2    |   2    |
                 | organizationId      |   3    |   4    |
                 | organizationSubType |   3    |   7    |
                 | Ticket record       |   T    |   10   |
                 +---------------------+--------+--------+

     Table 28: Structure of an organization extension TLV form for the
                                TICKET TLV

   To transport the TICKET TLV with the Ticket container embedded via
   the PTP unicast negotiation message two possible solutions exist:

   a.  The TICKET TLV can be added to the PTP message preceding the
       AUTHENTICATION TLV as shown in Figure 48 of IEEE Std 1588-2019
       ([IEEE1588-2019], 16.14.1.1).  For this solution, a completely
       new TICKET TLV for IEEE Std 1588-2019 needs to be defined.
   b.  In an alternative solution the TICKET TLV is send embedded in the
       RES field of the AUTHENTICATION TLV as shown in Figure 49 of IEEE



Langer & Bermbach       Expires September 9, 2021              [Page 65]


Internet-Draft                   NTS4PTP                      March 2021


       Std 1588-2019 ([IEEE1588-2019], 16.14.3).  In this case the RP
       flag in the secParamIndicator must be set.  As at the moment the
       use of the RES field is not permitted and the structure of the
       RES field is limited to UInteger (see [IEEE1588-2019], 16.14.3.8
       ) the new usage needs to be defined:

       _"16.14.3.8 RES (UInteger R): This field is optional.  If
       present, it shall have a data type of UInteger with a length of R
       octets.  For this edition, the value of RP in the
       secParamIndicator field shall be FALSE and the value of RP shall
       be 0."_

   Which solution is chosen is a political question, not a technical one
   and needs to be discussed in the IEEE 1588 SA.  The same applies to
   the format of the TICKET TLV (standard TLV or organization extension
   TLV).

5.  AUTHENTICATION TLV Parameters

   The AUTHENTICATION TLV is the heart of the integrated security
   mechanism (Prong A) for PTP.  It provides all necessary data for the
   processing of the security means.  The structure is shown in Table 29
   below (compare to Figure 49 of [IEEE1588-2019]).

   +-------------------+-------+---------------------------------------+
   | Field             |  Use  | Description                           |
   +-------------------+-------+---------------------------------------+
   | tlvType           | mand. | TLV Type                              |
   | lengthField       | mand. | TLV Length Information                |
   | SPP               | mand. | Security Parameter Pointer            |
   | secParamIndicator | mand. | Security Parameter Indicator          |
   | keyID             | mand. | Key Identifier or Current Key         |
   |                   |       | Disclosure Interval, depending on     |
   |                   |       | verification scheme                   |
   | disclosedKey      |  opt. | Disclosed key from previous interval  |
   | sequenceNo        |  opt. | Sequence number                       |
   | RES               |  opt. | Reserved                              |
   | ICV               | mand. | ICV based on algorithm OID            |
   +-------------------+-------+---------------------------------------+

               Table 29: Structure of the AUTHENTICATION TLV

   The tlvType is AUTHENTICATION and lengthField gives the length of the
   TLV.  When using the AUTHENTICATION TLV with NTS key management, the
   SPP and keyID will be provided by the KE server in the PTP Key Grant
   Message





Langer & Bermbach       Expires September 9, 2021              [Page 66]


Internet-Draft                   NTS4PTP                      March 2021


   The optional disclosedKey, sequenceNo, and RES (see discussion in
   chapter 3) fields are omitted.  So all of the flags in the
   SecParamIndicator are FALSE.

   ICV field contains the integrity check value of the particular PTP
   message calculated using the integrity algorithm defined by the key
   management.

6.  IANA Considerations

   Considerations should be made ...

   ...

7.  Security Considerations

   ...

8.  Acknowledgements

   The authors would like to thank ...

9.  References

9.1.  Normative References

   [FIPS-PUB-198-1]
              National Institute of Standards and Technology (NIST),
              "The Keyed-Hash Message Authentication Code (HMAC)",
              NIST FIPS PUB 198-1, 2008.

   [IEEE1588-2019]
              Institute of Electrical and Electronics Engineers - IEEE
              Standards Association, "IEEE Standard for a Precision
              Clock Synchronization Protocol for Networked Measurement
              and Control Systems", IEEE Standard 1588-2019, 2019.

   [ITU-T_X.509]
              International Telecommunication Union (ITU), "Information
              technology - Open systems interconnection - The Directory:
              Public-key and attribute certificate frameworks", ITU-T
              Recommendation X.509 (2008), November 2008.

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




Langer & Bermbach       Expires September 9, 2021              [Page 67]


Internet-Draft                   NTS4PTP                      March 2021


   [RFC4493]  Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
              AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
              2006, <https://www.rfc-editor.org/info/rfc4493>.

   [RFC4543]  McGrew, D. and J. Viega, "The Use of Galois Message
              Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
              DOI 10.17487/RFC4543, May 2006,
              <https://www.rfc-editor.org/info/rfc4543>.

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
              <https://www.rfc-editor.org/info/rfc5116>.

   [RFC5297]  Harkins, D., "Synthetic Initialization Vector (SIV)
              Authenticated Encryption Using the Advanced Encryption
              Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October
              2008, <https://www.rfc-editor.org/info/rfc5297>.

   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
              July 2014, <https://www.rfc-editor.org/info/rfc7301>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <https://www.rfc-editor.org/info/rfc7525>.

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

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

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

9.2.  Informative References








Langer & Bermbach       Expires September 9, 2021              [Page 68]


Internet-Draft                   NTS4PTP                      March 2021


   [Langer_et_al._2020]
              Langer, M., Heine, K., Sibold, D., and R. Bermbach, "A
              Network Time Security Based Automatic Key Management for
              PTPv2.1", 2020 IEEE 45th Conference on Local Computer
              Networks (LCN), Sydney, Australia,
              DOI 10.1109/LCN48667.2020.9314809, November 2020,
              <https://ieeexplore.ieee.org/document/9314809>.

Authors' Addresses

   Martin Langer
   Ostfalia University of Applied Sciences
   Salzdahlumer Strasse 46/48
   Wolfenbuettel  38302
   Germany

   Email: mart.langer@ostfalia.de


   Rainer Bermbach
   Ostfalia University of Applied Sciences
   Salzdahlumer Strasse 46/48
   Wolfenbuettel  38302
   Germany

   Email: r.bermbach@ostfalia.de

























Langer & Bermbach       Expires September 9, 2021              [Page 69]