NTS4PTP - Network Time Security for the Precision Time Protocol

2.5.1. Key Update Process

The security parameters update process is an important part of NTS4PTP. It keeps the keys up to date, allows for both, runtime security policy changes and easy group control. The rotation operation allows uninterrupted PTP operation in multicast as well as unicast mode.¶

The update mechanism is based on the Validity Period record in the NTS response messages, which includes the three values lifetime, update period (UP) and grace period (GP), see Figure 5. The lifetime parameter specifies the validity period of the security parameters (e.g., security association (SA) and ticket) in seconds, which is counted down. This value can range from a few minutes to a few days. (Due to the design of the replay protection, a maximum lifetime of up to 388 days is possible, but should not be exploited, see Section 5.1). After the validity period has expired, the security parameters may no longer be used to secure PTP messages and must be deleted soon after.¶

New security parameters are available on the NTS-KE server during the update period, a time span before the expiry of the lifetime. The length of the update period is therefore always shorter than the full lifetime and is typically in the range of a few minutes.¶

The grace period also helps to ensure uninterrupted key rotation. This value defines a period of time after the lifetime expiry during which the expired security parameters continue to be accepted. The grace period covers a few seconds at most and is only intended to compensate for runtime delays in the network during the update process. A maximum grace period of 5 seconds is recommended. The respective values of the three parameters are defined by the administrator and can also be specified by a corresponding PTP profile.¶

|12,389s (@time of key request)  0s|14,400s                   0s|
+----------------------------------+------------------...-------+
| Lifetime (current parameters)    |  Lifetime (next parameters)|
+-------------------------+--------+------------------...-------+
                          |  300s  |  3s  |
                          |<------>|<---->|
                          | update |grace |
                          | period |period|
                          |________|______|
                               |       |
                               V       V
 Request and receive new parameters   Still accepting
          at a random point in time   old parameters

Example:
--------
lifetime (full): 14,400s = 4h
update period:      300s = 5min
grace period:         3s

As the value for lifetime is specified in seconds which denote the remaining time and is decremented down to zero, hard adjustments of the clock used have to be avoided. Therefore, the use of a monotonic clock is recommended. Requests during the currently running validity period will receive respectively adapted count values.¶

The Validity Period record (see Section 4.2.18) with its parameters lifetime, update period and grace period is contained in a so-called Current Parameters container record. Together with other security parameters this container record is always present in a PTP Key respectively Registration Response message. During the update period the response message additionally comprises the Next Parameters container record, which holds the new lifetime etc. starting at the end of the current lifetime as well as the other security parameters of the upcoming lifetime cycle.¶

Any PTP client sending a PTP Key Request to the NTS-KE server, be it in GrM to receive the group SA or be it in TiM asking for the unicast SA (unicast key etc. and encrypted ticket), will receive the Current Parameters container record where lifetime includes the remaining time to run rather than the full. Requesting during the update period the response includes also the new lifetime value etc. in the Next Parameters container record. The new lifetime is the full value of the validity starting at the end of the current lifetime and update period. After the old lifetime has expired, only the new parameters (including lifetime, update period and grace period) have to be used. Merely during the grace period, the old SA will be accepted to cope with smaller delays in the PTP communication.¶

All PTP clients are obliged to connect to the NTS-KE server during the update period to allow for uninterrupted secured PTP operation. To avoid peak load on the NTS-KE server all clients SHOULD choose a random starting time during the update period.¶

In TiM the unicast grantors execute the NTS-TSR protocol to register with the NTS-KE server. The rotation sequence (see Figure 6) and the behavior of the PTP Registration Response message is almost identical to the NTS-KE protocol. The main difference here is that the update period has to start earlier so that a grantor has re-registered before requesters ask for new security parameters at the NTS-KE server.¶

As the difference between the start of the requester’s update period and the beginning of the update period of the grantor is not communicated, the grantor should contact the NTS-KE server directly after the start of its update period. However, since the rotation periods occur at different times for multiple grantors, no load peaks occur here either.¶

If a grantor does not re-register in time, requesters asking for a key etc. may not receive a Next Parameters container record, as no new SA is available at that point. So, requesters need to try again later.¶

As unicast contracts in TiM run independently of the update cycle, a special situation may occur. If the remaining lifetime is short, the grantor decides whether it grants any contract longer than the remaining lifetime or not. If a unicast contract is to be extended within the update period and the requester already owns the new ticket, it can already apply the upcoming security parameters here. This corresponds to some kind of negative grace period (pre-validity use of upcoming security parameters) and allows the requester to negotiate the full time for the unicast contract with the grantor.¶

If a grantor has revoked his registration with a PTP Registration Revoke message, requesters will receive a PTP Key Response message with an error code when trying to update for a new unicast key. No immediate key revoke mechanism exists. The grantor SHOULD NOT grant respective unicast requests during the remaining lifetime of the revoked key.¶

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

(@time of registration response)
  |
|14,400s                          0s |14,400s                 0s|
+---------------------------------------------------...---------+
|Lifetime (current ticket key)       |Lifetime (next ticket key)|
+----------------------+------+------+--------------...---------+
                       |     480s    |
                       |<----------->|
                       |   update    |
                       |   period    |
                       |_____________|
                       |      :      :
                       V      :      :
              Re-registration :      :
                              :      :
                              :      :
Update process requester:     :      :
-------------------------     :      :
                              :      :
    |12,389s (@time of key request)0s|14,400s                 0s|
    +--------------------------------+----------------...-------+
    | Lifetime (current parameters)  |Lifetime (next parameters)|
    +-------------------------+------+------+---------...-------+
                              | 300s |   3s |
                              |<---->|<---->|
                              |update|grace |
                              |period|period|
                              |______|______|
                                 |       |
                                 V       V
 Request and receive new parameters    Still accepting
          at a random point in time    old parameters

Example:
--------
lifetime (full):        14,400s = 4h
update period grantor:     480s = 8min
update period requester:   300s = 5min
grace period:                3s

2.5.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 cryptographic algorithm used (see also last subsection in Section 5.3).¶

2.5.3. Time Information of the NTS-KE server

As the NTS-KE server embeds time duration information in the respective messages, its local time should be accurate to within 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.5.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.5.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], Section 8.5 “Initial Verification of Server certificates” which applies to client and server 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, IETF RFC 6960) [RFC6960] 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 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 NTS-KE server would be necessary: which domain, sdoId and/or subgroup attributes belong to which certificate.¶

As TLS is used to secure both sub-protocols, the NTS-KE and the NTS-TSR 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.5.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.¶

4.2.1. AEAD Algorithm Negotiation

Used in NTS-TSR protocol¶

This record is required in Ticket-based mode (TiM) 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], Section 4.1.5.¶

Content and conditions:¶

• The record has a Record Type number of 4 and the Critical Bit MAY be set.¶

• The Record Body contains a sequence of 16-bit unsigned integers in network byte order:¶

  Supported AEAD Algorithms = {AEAD 1 || AEAD 2 || …}¶

• Each integer represents a numeric identifier of an AEAD algorithm registered by the IANA [IANA_AEAD].¶

• Duplicate identifiers SHOULD NOT be included.¶

• Grantor and NTS-KE server MUST support at least the AEAD_AES_SIV_CMAC_256 algorithm.¶

• A list of recommended AEAD algorithms is shown in the following Table 13.¶

• Other AEAD algorithms MAY also be used.¶

• In a PTP Registration Request message, this record MUST be contained exactly once.¶

• In that message at least the AEAD_AES_SIV_CMAC_256 algorithm MUST be included.¶

• If multiple AEAD algorithms are supported, the grantor SHOULD put the algorithm identifiers in descending priority in the Record Body.¶

• Strong algorithms with higher bit lengths SHOULD have higher priority.¶

• In a PTP Registration Response message, this record MUST be contained exactly once in the Current Parameters container record and exactly once in the Next Parameters container record.¶

• The Next Parameters container record MUST be present only during the update period.¶

• The NTS-KE server SHOULD choose the highest priority AEAD algorithm from the request message that grantor and NTS-KE server support.¶

• The NTS-KE server MAY ignore the priority and choose a different algorithm that grantor and NTS-KE server support.¶

• In a PTP Registration Response message, this record MUST contain exactly one AEAD algorithm.¶

• The selected algorithm MAY differ in the corresponding Current Parameters container record and Next Parameters container record.¶

4.2.2. Association Mode

Used in NTS-KE protocol¶

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

• In a PTP Key Request message, this record MUST be contained exactly once.¶

• The record has a Record Type number of 1024 and the Critical Bit MAY be set.¶

• The Record Body SHALL consist of one association tuple:¶

• The Association Type is a 16-bit unsigned integer.¶

• The length of Association Value depends on the value of Association Type.¶

• All data in the fields are stored in network byte order.¶

• The type numbers of Association Type (tbd. by IANA) as well as the length and content of Association Value are shown in the following table and more details are given below.¶

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

Group:¶

• This Association Type allows a PTP instance to join a PTP multicast group.¶

• A group is identified by the PTP domain, the PTP profile (sdoId) and a sub-group attribute (see table below).¶

• The PTP domainNumber is an 8-bit unsigned integer in the closed range 0 to 255.¶

• 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, Section 7.1.1¶

  sdoId = {majorSdoId || minorSdoId}¶

• The subGroup is 16-bit unsigned integer, which allows the division of a PTP multicast network into separate groups, each with individual security parameters.¶

• This also allows manually configured unicast connections (Group-of-2), which can include transparent clocks as well.¶

• The subGroup number is defined manually by the administrator.¶

• Access to the groups is controlled by authorization procedures of the PTP devices (see Section 2.5.5.4).¶

• If no subgroups are needed, this attribute MUST contain the value zero.¶

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

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

This is equivalent to:¶

IPv4:¶

• This Association Type allows a requester to establish a PTP unicast connection to the desired grantor.¶

• The Association Value contains the IPv4 address of the target PTP entity.¶

• The total length is 4 octets.¶

IPv6:¶

• This Association Type allows a requester to establish a PTP unicast connection to the desired grantor.¶

• The Association Value contains the IPv6 address of the target PTP entity.¶

• The total length is 16 octets.¶

802.3:¶

• This Association Type allows a requester to establish a PTP unicast connection to the desired grantor.¶

• The Association Value contains the MAC address of the Ethernet port of the target PTP entity.¶

• The total length is 6 octets.¶

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

PortIdentity:¶

• This Association Type allows a requester to establish a PTP unicast connection to the desired grantor.¶

• The Association Value contains the PortIdentity of the target PTP entity.¶

• The total length is 10 octets.¶

• The PortIdentity consists of the attributes clockIdentity and portNumber:¶

  PortIdentity = {clockIdentity || portNumber}¶

• The clockIdentity is an 8 octet array and the portNumber is a 16-bit unsigned integer.¶

• Source: IEEE Std 1588-2019, Sections 5.3.5 and 7.5¶

4.2.3. Current Parameters

Used in NTS-KE and NTS-TSR protocol¶

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

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

• In a PTP Key Response message, this record MUST be contained exactly once.¶

• The Record Body is defined as a set of records and MAY contain the following records:¶

• The records Security Association and Validity Period MUST be contained exactly once.¶

• Additionally, the records PTP Time Server and Ticket MUST be included exactly once if the client wants a unicast connection in TiM and MUST NOT be included if the client wants to join a multicast group in GrM.¶

• In a PTP Registration Response message, the Current Parameters container record MUST be contained exactly once.¶

• The Record Body MUST contain the following records exactly:¶

4.2.4. End of Message

Used in NTS-KE and NTS-TSR protocol¶

The End of Message record is defined in IETF RFC 8915 [RFC8915], Section 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:¶

• The record has a Record Type number of 0 and a zero-length body.¶

• The Critical Bit MUST be set.¶

• This record MUST occur exactly once as the final record of every NTS message.¶

• This record SHOULD NOT be included in the container records and MUST be ignored if present.¶

• See also: IETF RFC 8915, Section 4.1.1¶

4.2.5. Error

Used in NTS-KE and NTS-TSR protocol¶

The Error record is defined in IETF RFC 8915 [RFC8915], Section 4.1.3. In addition to the Error codes 0 to 2 specified there the following Error codes 3 to 4 (tbd. by IANA) are shown below:¶

Content and conditions:¶

• 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.¶

• The Critical Bit MUST be set.¶

• The Error code 3 "Not Authorized" is sent by the NTS-KE server if the requester is not authorized to join the desired multicast group or if a grantor is prohibited to register with the NTS-KE server.¶

• The Error record MUST NOT be included in a PTP Registration Request message.¶

• The Error code 4 "Grantor not Registered" is sent by the NTS-KE server when the requester wants to establish a unicast connection to a grantor that is not registered with the NTS-KE server.¶

• The Error record MUST NOT be included in a PTP Key Request message.¶

4.2.6. Heartbeat Timeout

Used in NTS-TSR protocol¶

This record provides the NTS-KE server the capability to monitor the availability of the registered grantors. If this optional record is used, the registered grantors SHOULD send a PTP Heartbeat message to the NTS-KE server before the timeout expires.¶

Content and conditions:¶

• The record has a Record Type number of 1026 and the Critical Bit SHOULD NOT be set.¶

• The Record Body consists of a 16-bit unsigned integer in network byte order and denotes the heartbeat timeout in seconds.¶

• The timeout set by the NTS-KE server MUST NOT be less than 1s.¶

• The timeout starts at the NTS-KE server with the generation of the Registration Response message.¶

• Grantors that receive an invalid value as a heartbeat timeout MUST ignore this record and MUST NOT send heartbeat messages.¶

• Grantors that receive a valid value SHOULD send a PTP Heartbeat message to the NTS-KE server before the timeout has elapsed.¶

• The grantors SHOULD keep the heartbeat intervals and MAY also send heartbeat messages more frequently.¶

• After transmitting a heartbeat from the grantor to the NTS-KE server, both sides reset the timeout to the start value and let the time count down again.¶

• If this timeout is exceeded without receiving a heartbeat message or several heartbeats are missing in a row, the NTS-KE server MAY delete the grantor from its registration list, so that a new registration of the grantor is necessary.¶

• Grantors that are not (or no longer) registered with a NTS-KE server MUST NOT send heartbeat messages and NTS-KE servers MUST discard heartbeat messages from non-registered grantors.¶

• NTS-KE servers MAY respond in such cases with a Registration Response message containing error code 4 "Grantor not Registered".¶

4.2.7. Next Parameters

Used in NTS-KE and NTS-TSR protocol¶

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

• The record has a Record Type number of 1027 and the Critical Bit MAY be set.¶

• The Record Body is defined as a set of records.¶

• The structure of the record body and all conditions MUST be identical to the rules described in Section 4.2.3 of this document.¶

• In both the PTP Key Response and PTP Registration Response message, this record MUST be contained exactly once during the update period.¶

• Outside the update period, this record MUST NOT be included.¶

• In GrM, this record MAY also be missing if the requesting client is to be explicitly excluded from a multicast group after the security parameter rotation process by the NTS-KE server.¶

• More details are described in Section 2.5.1.¶

4.2.8. NTS Next Protocol Negotiation

Used in NTS-KE protocol¶

The Next Protocol Negotiation record is defined in IETF RFC 8915 [RFC8915], Section 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:¶

• The record has a Record Type number of 1 and the Critical Bit MUST be set.¶

• The Record Body consists of a sequence of 16-bit unsigned integers in network byte order.¶

  Record body = {Protocol ID 1 || Protocol ID 2 || …}¶

• Each integer represents a Protocol ID from the IANA "Network Time Security Next Protocols" registry (tbd.) as shown in the table below.¶

• For NTS request messages for PTPv2.1 (NTS-KE protocol merely), only the Protocol ID for PTPv2.1 SHOULD be included.¶

• This prevents the mixing of records for different time protocols.¶

Possible NTP/PTP conflict:¶

• 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.¶

• For example, an NTS request could include records for both NTP and PTP.¶

• However, NTS for NTP 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.¶

• This leads to the mixing of the records in the NTS messages.¶

• 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.¶

• When using NTS-secured NTP and NTS-secured PTP, two separate NTS requests i.e., two separate TLS sessions MUST be made.¶

4.2.9. NTS Message Type

Used in NTS-TSR protocol¶

This record enables the distinction between different NTS message types and message versions for the NTS-TSR protocol. It MUST be included exactly once in each NTS message in the NTS-TSR protocol.¶

Content and conditions:¶

• The record has a Record Type number of 1028 and the Critical Bit MUST be set.¶

• The Record Body MUST consist of three data fields:¶

• The Message Type field is a 16-bit unsigned integer in network byte order, denoting the type of the current NTS message.¶

• The following values (tbd. by IANA) are defined for the Message Type:¶

• The Message Version consists of a tuple of two 8-bit unsigned integers in network byte order:¶

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

• The representable version is therefore in the range 0.0 to 255.255 (e.g., v1.4 = 0104h).¶

• All NTS messages for PTPv2.1 described in this document are in version number 1.0.¶

• Thus the Message Version MUST match 0100h.¶

4.2.10. PTP Time Server

Used in NTS-KE and NTS-TSR protocol¶

The PTP Time Server record is used exclusively in TiM (PTP unicast connection) and signals to the client (PTP requester) for which grantor the security parameters are valid. This record is used both, in the NTS-KE protocol in the PTP Key Response, and in NTS-TSR protocol in the PTP Registration Request message.¶

Content and conditions:¶

• The record has a Record Type number of 1029 and the Critical Bit MAY be set.¶

• The record body consists of a set of association values constructed of the data tuple which forms the record body of the Association Mode record described in Section 4.2.2 (Association Mode).¶

• The structure of the record body and all conditions MUST be identical to the rules described in Section 4.2.2 (Association Mode) of this document, with the following exceptions:¶

• In a PTP Key Response message, this record MUST be contained exactly once within a container record (e.g., Current Parameters container record).¶

• The PTP Time Server record contains a list of all available addresses of the grantor assigned by the NTS-KE server.¶

• This MUST be one of the following association types: IPv4, IPv6, MAC address, as well as the PortIdentity of the grantor.¶

• It MUST NOT be the association type Group.¶

• The list SHALL contain only one of each association type.¶

• This allows the client to change the PTP transport mode (e.g., from IPv4 to IEEE 802.3) without performing a new NTS request.¶

• The list in the PTP Time Server record MUST NOT contain the Association Type number 0 (multicast group) and MUST contain at least one entry.¶

• The NTS-KE server SHOULD provide the grantor addresses requested by the client in the PTP Key Request message, but MAY also assign a different grantor to the client.¶

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

• The grantor MUST enter all network addresses that are supported for a unicast connection.¶

• This can be an IPv4, IPv6, MAC address, as well as the PortIdentity.¶

• The list in the PTP Time Server record MUST NOT contain the Association Type number 0 (multicast group) and MUST contain at least the PortIdentity.¶

• The PortIdentity is especially needed by the NTS-KE server to identify the correct PTP instance (the grantor) in case of a PTP Registration Revoke message.¶

4.2.11. Security Association

Used in NTS-KE protocol¶

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, Section 16.14.3). Static values and flags, such as the secParamIndicator, are described in more detail in Section 7.¶

Content and conditions:¶

• The record has a Record Type number of 1030 and the Critical Bit MAY be set.¶

• The Record Body is a sequence of various parameters in network byte order and MUST be formatted according to the following table:¶

• In a PTP Key Response message, the Security Association record MUST be included exactly once in the Current Parameters container record and the Next Parameters container record.¶

• The Next Parameters container record MUST be present only during the update period.¶

• In TiM, the Security Association record MUST be included exactly once in the encrypted Ticket as well.¶

Security Parameter Pointer¶

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

• This value enables the mutual assignment of SA, SP and AUTHENTICATION TLVs.¶

• The generation and management of the SPP is controlled by the NTS-KE server (see Section 5.3).¶

Integrity Algorithm Type¶

• This value is a 16-bit unsigned integer in network byte order.¶

• The possible values are equivalent to the MAC algorithm types from the table in Section 4.2.14.¶

• The value used depends on the negotiated or predefined MAC algorithm.¶

Key ID¶

• The key ID is a 32-bit unsigned integer in network byte order.¶

• The field length is oriented towards the structure of the AUTHENTICATION TLV.¶

• The generation and management of the key ID is controlled by the NTS-KE server.¶

• The NTS-KE server MUST ensure that every key ID is unique.¶

  • Previous key IDs SHOULD NOT be reused for a certain number of rotation periods or a defined period of time (see Section 5.3).¶

Key Length¶

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

Key¶

• The value is a sequence of octets with a length of Key Length.¶

• This symmetric key is needed together with the MAC algorithm to calculate the ICV.¶

• It can be both a group key (GrM) or a unicast key (TiM).¶

4.2.12. Source PortIdentity

Used in NTS-KE and NTS-TSR protocol¶

This record contains a PTP PortIdentity and serves as an identifier. In a PTP Key Request message, it enables the unique assignment of the NTS request to the PTP instance of the sender, since the request may have been sent to the NTS-KE server via a management port.¶

The PortIdentity is embedded in the PTP Key Response message within the ticket to bind it to the PTP requester. Grantors can verify that the ticket comes from the correct sender when it is received and before it is decrypted, to prevent possible crypto-performance attacks. In a PTP registration Revoke message this record enables the assignment of the grantor at the NTS-KE server to revoke an existing registration. This is necessary because requesting PTP devices may have multiple independent PTP ports and possibly multiple registrations with the KE.¶

Content and conditions:¶

• The record has a Record Type number of 1031 and the Critical Bit MAY be set.¶

• The record contains the PTP PortIdentity of the sender in network byte order, with a total length of 10 octets.¶

• In a PTP Key Request message, this record MUST be included exactly once if the client intends a unicast request in TiM and MUST NOT be included if the client intends to join a multicast group/Go2 (= GrM).¶

• In a PTP Registration Revoke message, this record MUST be included exactly once.¶

• The PortIdentity consists of the attributes clockIdentity and portNumber:¶

  PortIdentity = {clockIdentity || portNumber}¶

• The clockIdentity is an 8-octet array and the portNumber is a 16-bit unsigned integer (source: [IEEE1588-2019], Sections 5.3.5 and 7.5)¶

4.2.13. Status

Used in NTS-TSR protocol¶

The Status record is an optional record that represents the current load of the grantor if status type is 0. It allows the NTS-KE server to improve load balancing when assigning grantors to the requesting PTP clients in TiM. The content of the record is designed in such a way that it can also transmit other information (e.g., manufacturer-related information).¶

Content and conditions:¶

• The record has a Record Type number of 1032 and the Critical Bit SHOULD NOT be set.¶

• The Record Body MUST consist of two data fields:¶

• The Status Type is a 16-bit unsigned integer in network byte order, denoting the content of the Status Data field.¶

• The Status Data field is a sequence of octets in network byte order whose length, content and structure is determined by the Status Type field.¶

• The following values are currently set:¶

• With Status Type 0 (tbd. by IANA) the value designates the grantor load percentage (0% - 100%).¶

• The NTS-KE server shall ignore values greater than 100.¶

• In a PTP Heartbeat message this record MAY be contained once or several times.¶

• If multiple status records are included, the status type MUST NOT occur twice.¶

• The NTS-KE server MAY use the status record for optimizations and MAY also ignore them.¶

4.2.14. Supported MAC Algorithms

Used in NTS-KE and NTS-TSR protocol¶

This 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 used mandatorily in a PTP Registration Request message and MAY be used (optionally) in a PTP Key Request message.¶

Content and conditions:¶

• The record has a Record Type number of 1033 and the Critical Bit MAY be set.¶

• The Record Body contains a sequence of 16-bit unsigned integers in network byte order.¶

  Supported MAC Algorithms = {MAC 1 || MAC 2 || …}¶

• Each integer (tbd. by IANA) represents a MAC Algorithm Type defined in the table below.¶

• Duplicate identifiers SHOULD NOT be included.¶

• Each PTP node MUST support at least the HMAC-SHA256-128 algorithm.¶

In Group-based mode (GrM):¶

• This record is not necessary, since all PTP nodes in a multicast group MUST support the same MAC algorithm.¶

• Therefore, this record SHOULD NOT be included in a PTP Key Request message and the NTS-KE server MUST ignore this record if the Association Type in the Association Mode record is 0 (= multicast group).¶

• Unless this is specified otherwise by a PTP profile, the HMAC-SHA256-128 algorithm SHALL be used by default.¶

In Ticket-based mode (TiM):¶

• In a PTP Key Request message, this record MAY be contained if the requester wants a unicast connection (TiM, not Go2) to a specific grantor.¶

• The requester MUST NOT send more than one record of this type.¶

• If this record is present, at least the HMAC-SHA256-128 MAC algorithm MUST be included.¶

• If multiple MAC algorithms are supported, the requester SHOULD put the desired algorithm identifiers in descending priority in the record body.¶

• Strong algorithms with higher bit lengths SHOULD have higher priority.¶

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

• The NTS-KE server selects the algorithm after receiving a PTP Key Request message in unicast mode.¶

• The NTS-KE server SHOULD choose the highest priority MAC algorithm from the request message that grantor and requester support.¶

• The NTS-KE server MAY ignore the priority and choose a different algorithm that grantor and requester support.¶

• If the MAC Algorithm Negotiation record is not within the PTP Key Request message, the NTS-KE server MUST choose the default algorithm HMAC-SHA256-128.¶

Initialization Vector (IV)¶

• If GMAC is to be supported as a MAC algorithm, then an Initialization Vector (IV) must be constructed according to IETF RFC 4543 [RFC4543], Section 3.1.¶

• Therefore, the IV MUST be eight octets long and MUST NOT be repeated for a specific key.¶

• This can be achieved, for example, by using a counter.¶

4.2.15. Ticket

Used in NTS-KE protocol¶

This record contains the parameters of the negotiated AEAD algorithm chosen between the grantor and the NTS-KE server, as well as an encrypted security association. The record contains all the necessary security parameters that the grantor needs for a secured PTP unicast connection to the requester. The ticket 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 encrypted security association within the ticket.¶

Content and conditions:¶

• The record has a Record Type number of 1034 and the Critical Bit MAY be set.¶

• The Record Body consists of several data fields and MUST be formatted as follows.¶

• In a PTP Key Response message, this record MUST be included exactly once each in the Current Parameters container record and the Next Parameters container record if the requesting client wants a unicast communication to a specific grantor in TiM.¶

• The Next Parameters container record MUST be present only during the update period.¶

Ticket Key ID¶

• This is a 32-bit unsigned integer in network byte order, denoting the key ID of the ticket key.¶

• The value is set by the NTS-KE server and is valid for the respective validity period.¶

• See also Section 4.2.17 for more details.¶

Source PortIdentity¶

• This 10-octet long field contains the identical Source PortIdentity of the PTP client from the PTP Key Request message.¶

Nonce Length¶

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

Nonce¶

• This field contains the Nonce needed for the AEAD operation.¶

• The length and conditions attached to the Nonce depend on the AEAD algorithm used.¶

• More details and conditions are described in Section 5.2.¶

Encrypted SA Length¶

• This is a 16-bit unsigned integer in network byte order, denoting the length of the Encrypted Security Association field in octets.¶

Encrypted Security Association¶

• This field contains the output of the AEAD operation (“Ciphertext”) after the encryption process of the respective Record Body of the respective Security Association record.¶

• The plaintext of this field is described in Section 4.2.11.¶

• More details about the AEAD process and the required input data are described in Section 5.2.¶

4.2.16. Ticket Key

Used in NTS-TSR protocol¶

This record contains the ticket key, which together with an AEAD algorithm is used to encrypt and decrypt the ticket payload (content of the Encrypted Security Association field in the Ticket record).¶

Content and conditions:¶

• The record has a Record Type number of 1035 and the Critical Bit MAY be set.¶

• The Record Body consists of a sequence of octets holding the symmetric key for the AEAD function.¶

• The generation and length of the key MUST meet the requirements of the associated AEAD algorithm.¶

• In a PTP Registration Response message, this record MUST be included exactly once each in the Current Parameters container record and the Next Parameters container record.¶

• The Next Parameters container record MUST be present only during the update period.¶

4.2.17. Ticket Key ID

Used in NTS-TSR protocol¶

The Ticket Key ID record is a unique identifier that allows a grantor to identify the associated ticket key. The NTS-KE server is responsible for generating this key ID, which is also unique to the PTP network and incremented at each rotation period. The associated key is known only to the NTS-KE server and grantor, and is generated and exchanged during the registration phase of the grantor. All tickets generated by the NTS-KE server for the corresponding grantor in this validity period using the same ticket key ID.¶

Content and conditions:¶

• The record has a Record Type number of 1036 and the Critical Bit MAY be set.¶

• The Record Body consists of a 32-bit unsigned integer in network byte order.¶

• The generation and management of the ticket key ID is controlled by the NTS-KE server.¶

• The NTS-KE server must ensure that every ticket key has a unique number.¶

  • The value is implementation dependent and MAY be an enumeration.¶

  • Previous IDs SHOULD NOT be reused for a certain number of rotation periods or a defined period of time.¶

• In a PTP Registration Response message, this record MUST be included exactly once in the Current Parameters container record and once in the Next Parameters container record.¶

• The Next Parameters container record MUST be present only during the update period.¶

• The Ticket record MUST be present in TiM and MUST NOT be present in GrM.¶

4.2.18. Validity Period

Used in NTS-KE and NTS-TSR protocol¶

This record contains the validity information of the respective security parameters (see also Section 2.5.1).¶

Content and conditions:¶

• In a PTP Key Response as well as in the PTP Registration Response message, this record MUST be included exactly once each in the Current Parameters container record and the Next Parameters container record.¶

• The record has a Record Type number of 1037 and the Critical Bit MAY be set.¶

• The Record Body MUST consist of three data fields:¶

Lifetime¶

• The Lifetime is a 32-bit unsigned integer in network byte order.¶

• If this record is within a Current Parameters container record, it shows the remaining lifetime of the security parameters for the current validity period in seconds.¶

• If this record is within a Next Parameters container record, it shows the total lifetime of the security parameters for the next validity period in seconds.¶

• The counting down of the Next Parameters lifetime starts as soon as the remaining lifetime of the Current Parameters reaches 0s.¶

• The maximum value is set by the NTS-KE administrator or the PTP profile.¶

• In conjunction with a PTP unicast establishment in TiM, the lifetime of the unicast key (within the Security Association record), the ticket key and registration lifetime of a grantor with the NTS-KE server MUST be identical.¶

Update Period¶

• The Update Period is a 32-bit unsigned integer in network byte order.¶

• It specifies how many seconds before the lifetime expires the update period starts.¶

• Unlike the lifetime, this is a fixed value that is not counted down.¶

• The Update Period value MUST NOT be greater than the full Lifetime.¶

• Recommended is an Update Period of 120s-300s if the full Lifetime is 900s or longer.¶

• If the value of the Update Period in the Current Parameters container record is greater than the Lifetime, then the key update process has started.¶

• The presence or absence of the Next Parameters container record is specified in Section 4.2.7.¶

Grace Period¶

• The Grace Period is a 32-bit unsigned integer in network byte order.¶

• It defines how many seconds expired security parameters MUST still be accepted.¶

• This allows the verification of incoming PTP messages that were still on the network and secured with the old parameters.¶

• The Grace Period value MUST NOT be greater than the Update Period.¶

• Recommended is a Grace Period of 0 to 5 seconds.¶

Notes:¶

• Requests during the currently running lifetime will receive respectively adapted count values.¶

• The lifetime is a counter that is decremented and marks the expiration of defined parameters when the value reaches zero.¶

• The realization is implementation-dependent and can be done for example by a secondly decrementing.¶

• It MUST be ensured that jumps (e.g., by adjustment of the local clock) are avoided.¶

• The use of a monotonic clock is suitable for this.¶

• Furthermore, it is to be considered which consequences the drifting of the local clock can cause.¶

• With sufficiently small values of the lifetime (<12 hours), this factor should be negligible.¶