idnits 2.17.1 draft-langer-ntp-nts-for-ptp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([TM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2021) is 1142 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 983 -- Looks like a reference, but probably isn't: '1' on line 983 == Unused Reference: 'RFC7301' is defined on line 3084, but no explicit reference was found in the text == Unused Reference: 'RFC7525' is defined on line 3089, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-PUB-198-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588-2019' ** Downref: Normative reference to an Informational RFC: RFC 4493 ** Downref: Normative reference to an Informational RFC: RFC 5297 ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Time Protocol M. Langer 3 Internet-Draft R. Bermbach 4 Intended status: Standards Track Ostfalia University 5 Expires: September 9, 2021 March 8, 2021 7 NTS4PTP - Key Management System for the Precision Time Protocol Based on 8 the Network Time Security Protocol 9 draft-langer-ntp-nts-for-ptp-01 11 Abstract 13 This document defines a key management service for automatic key 14 management for the integrated security mechanism (Prong A) of IEEE 15 Std 1588[TM]-2019 described there in Annex P. It implements a key 16 management for immediate security processing complementing the 17 exemplary GDOI proposal in P.2.1.2.1. The key management service is 18 based on the "NTS Key Establishment" protocol defined in IETF RFC 19 8915 for securing NTP, but works completely independent from NTP. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 9, 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 56 2. Key Management Using Network Time Security . . . . . . . . . 3 57 2.1. Principle Key Distribution Mechanism . . . . . . . . . . 5 58 2.1.1. NTS Message Exchange for Group-based Approach . . . . 8 59 2.1.2. NTS Message Exchange for the Ticket-based Approach . 10 60 2.2. General Topics . . . . . . . . . . . . . . . . . . . . . 13 61 2.2.1. Key Update Process . . . . . . . . . . . . . . . . . 13 62 2.2.2. Key Generation . . . . . . . . . . . . . . . . . . . 16 63 2.2.3. Time Information of the KE Server . . . . . . . . . . 17 64 2.2.4. Certificates . . . . . . . . . . . . . . . . . . . . 17 65 2.2.5. Upfront Configuration . . . . . . . . . . . . . . . . 18 66 2.2.5.1. Security Parameters . . . . . . . . . . . . . . . 18 67 2.2.5.2. Key Lifetimes . . . . . . . . . . . . . . . . . . 19 68 2.2.5.3. Certificates . . . . . . . . . . . . . . . . . . 19 69 2.2.5.4. Authorization . . . . . . . . . . . . . . . . . . 19 70 2.2.5.5. Transparent Clocks . . . . . . . . . . . . . . . 20 71 2.2.5.6. Start-up considerations . . . . . . . . . . . . . 21 72 2.3. Overview of NTS Messages and their Structure for Use with 73 PTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 74 2.3.1. PTP Key Request Message . . . . . . . . . . . . . . . 23 75 2.3.2. PTP Key Grant Message . . . . . . . . . . . . . . . . 24 76 2.3.3. PTP Refusal Message . . . . . . . . . . . . . . . . . 26 77 2.3.4. PTP Registration Request Message . . . . . . . . . . 27 78 2.3.5. PTP Registration Success Message . . . . . . . . . . 28 79 2.3.6. PTP Registration Revoke Message . . . . . . . . . . . 29 80 3. NTS Messages for PTP . . . . . . . . . . . . . . . . . . . . 30 81 3.1. NTS Message Types . . . . . . . . . . . . . . . . . . . . 31 82 3.2. NTS Records . . . . . . . . . . . . . . . . . . . . . . . 36 83 3.2.1. AEAD Algorithm Negotiation . . . . . . . . . . . . . 36 84 3.2.2. Association Mode . . . . . . . . . . . . . . . . . . 38 85 3.2.3. Current Parameters Container . . . . . . . . . . . . 41 86 3.2.4. End of Message . . . . . . . . . . . . . . . . . . . 43 87 3.2.5. Error . . . . . . . . . . . . . . . . . . . . . . . . 43 88 3.2.6. Grace Period . . . . . . . . . . . . . . . . . . . . 44 89 3.2.7. Lifetime . . . . . . . . . . . . . . . . . . . . . . 45 90 3.2.8. MAC Algorithm Negotiation . . . . . . . . . . . . . . 46 91 3.2.9. Next Parameters Container . . . . . . . . . . . . . . 48 92 3.2.10. NTS Message Type . . . . . . . . . . . . . . . . . . 49 93 3.2.11. NTS Message Version . . . . . . . . . . . . . . . . . 49 94 3.2.12. NTS Next Protocol Negotiation . . . . . . . . . . . . 50 95 3.2.13. Requesting PTP Identity . . . . . . . . . . . . . . . 51 96 3.2.14. Security Association . . . . . . . . . . . . . . . . 53 97 3.2.15. Security Policies . . . . . . . . . . . . . . . . . . 54 98 3.2.16. Ticket . . . . . . . . . . . . . . . . . . . . . . . 56 99 3.2.17. Ticket Container . . . . . . . . . . . . . . . . . . 57 100 3.2.18. Ticket Key . . . . . . . . . . . . . . . . . . . . . 58 101 3.2.19. Ticket Key ID . . . . . . . . . . . . . . . . . . . . 59 102 3.2.20. Time until Update . . . . . . . . . . . . . . . . . . 60 103 3.3. Additional Mechanisms . . . . . . . . . . . . . . . . . . 61 104 3.3.1. AEAD Operation . . . . . . . . . . . . . . . . . . . 61 105 3.3.2. SA/SP Management . . . . . . . . . . . . . . . . . . 63 106 4. New TICKET TLV for PTP Messages . . . . . . . . . . . . . . . 64 107 5. AUTHENTICATION TLV Parameters . . . . . . . . . . . . . . . . 66 108 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 109 7. Security Considerations . . . . . . . . . . . . . . . . . . . 67 110 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 67 111 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 112 9.1. Normative References . . . . . . . . . . . . . . . . . . 67 113 9.2. Informative References . . . . . . . . . . . . . . . . . 68 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 116 1. Notational Conventions 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 2. Key Management Using Network Time Security 126 Many networks include both PTP and NTP at the same time. 127 Furthermore, many time server appliances that are capable of acting 128 as the Grandmaster of a PTP Network are also capable of acting as an 129 NTP server. For these reasons it is likely to be easier both for the 130 time server manufacturer and the network operator if PTP and NTP use 131 a key management system based on the same technology. The Network 132 Time Security (NTS) protocol was specified by the Internet 133 Engineering Task Force (IETF) to protect the integrity of NTP 134 messages [RFC8915]. Its NTS Key Establishment sub-protocol is 135 secured by the Transport Layer Security (TLS 1.3, IETF RFC 8446 136 [RFC8446]) mechanism. TLS is used to protect numerous popular 137 network protocols, so it is present in many networks. For example, 138 HTTPS, the predominant secure web protocol uses TLS for security. 139 Since many PTP capable network appliances have management interfaces 140 based on HTTPS, the manufacturers are already implementing TLS. This 141 document outlines how the NTS Key Establishment protocol of IETF RFC 142 8915 can be expanded for use as a PTP key management mechanism 143 [Langer_et_al._2020] for immediate security processing complementing 144 the exemplary GDOI proposal in the IEEE Std 1588-2019 146 [IEEE1588-2019]. As a key establishment server for NTP should be 147 implemented stateless which is not necessary for PTP systems, 148 suitable new NTS messages are to be defined in this document. 150 Though the key management for PTP is based on the NTS Key 151 Establishment protocol for NTP, it works completely independent of 152 NTP. The key management system uses the procedures described in IETF 153 RFC 8915 for the NTS-KE and expands it with new NTS messages for PTP. 154 It may be applied in a Key Establishment server (KE server) that 155 already manages NTP but can also be operated only handling KE for 156 PTP. Even when the PTP network is isolated from the Internet, a Key 157 Establishment server can be installed in that network providing the 158 PTP instances with necessary key and security parameters. 160 The KE server may often be implemented as a separate unit. It also 161 may be collocated with a PTP instance, e.g. the Grandmaster. In the 162 latter case communication between the KE server program and the PTP 163 instance program needs to be implemented in a secure way if TLS 164 communication (e.g. via local host) is not or cannot be used. 166 Using the expanded NTS Key Establishment protocol for the NTS key 167 management for PTP, NTS4PTP provides two principle approaches 168 specified in this document. 170 1. Group-based approach: 172 o Definition of one or more security groups in the PTP network, 173 o very suitable for PTP multicast mode and mixed multicast/unicast 174 mode, 175 o suitable for unicast mode in small subgroups of very few 176 participants (Group-of-2, Go2) but poor scaling and more 177 administration work, 179 2. Ticket-based approach 181 o secured (end-to-end) PTP unicast communication between requester 182 and grantor, 183 o no group binding necessary, 184 o very suitable for native PTP unicast mode, because of good 185 scaling, 186 o a bit more complex NTS message handling. 188 This document describes the structure and usage of these two 189 approaches in their application as a key management system for the 190 integrated security mechanism (Prong A) of IEEE Std 1588-2019. 191 Section 2.1 starts with a description of the principle key 192 distribution mechanism, continues with details of the various group- 193 based options (Section 2.1.1) and the ticket-based unicast mode 194 (Section 2.1.2) before it ends with more general topics in 195 Section 2.2 for example the key update process and finally an 196 overview of the newly defined NTS messages in Section 2.3. Section 3 197 gives all the details necessary to construct all records forming the 198 particular NTS messages. Section 4 depicts details of a TICKET TLV 199 needed to transport encrypted security information in PTP unicast 200 requests. The following Section 5 mentions specific parameters used 201 in the PTP AUTHENTICATION TLV when working with the NTS4PTP key 202 management system. Section 6 and Section 7 discuss IANA respectively 203 security considerations. 205 2.1. Principle Key Distribution Mechanism 207 A PTP instance requests a key from the server referred to as the Key 208 Establishment server, or (NTS-) KE server. Figure 1 describes the 209 principle sequence which can be used for PTP multicast as well as PTP 210 unicast operation. 212 PTP Instance 1 NTS-KE-Server 214 | | 215 |<======== Open TLS Channel ========>| 216 | | 217 | | 218 | | 219 | | 220 |========= PTP Key Request =========>| ) 221 | | ) NTS messages 222 | | ) for PTP 223 | | ) key exchange 224 |<======== PTP Key Grant ============| ) 225 | | 226 | | 227 | | 228 | | 229 |<======== Close TLS Channel =======>| 230 | | 231 | o 232 | 233 | 234 | 235 | PTP Instance 2/ 236 | PTP Network 237 | 238 | | 239 | | 240 |<---- Secured PTP Communication --->| 241 | using shared key | 242 | | 243 | | 244 V V 246 Figure 1: NTS Key distribution sequence 248 The client connects to the KE server on the NTS TCP port (port number 249 4460). Then both parties perform a TLS handshake to establish a TLS 250 1.3 communication channel. No earlier TLS versions are allowed. The 251 details of the TLS handshake are specified in IETF RFC 8446 252 [RFC8446]. 254 Implementations must conform to the rules stated in chapter 3 "TLS 255 Profile for Network Time Security" of IETF RFC 8915 [RFC8915]: 257 _"Network Time Security makes use of TLS for NTS key 258 establishment._ 259 _Since the NTS protocol is new as of this publication, no 260 backward-compatibility concerns exist to justify using obsolete, 261 insecure, or otherwise broken TLS features or versions._ 263 _Implementations MUST conform with RFC 7525 _ [RFC7525]_ or with a 264 later revision of BCP 195. _ 266 _Implementations MUST NOT negotiate TLS versions earlier than 1.3 267 _[RFC8446]_ and MAY refuse to negotiate any TLS version that has 268 been superseded by a later supported version._ 270 _Use of the Application-Layer Protocol Negotiation Extension 271 _[RFC7301]_ is integral to NTS, and support for it is REQUIRED for 272 interoperability ... "_ 274 The TLS handshake accomplishes the following: 276 o Negotiation of TLS version (only TLS 1.3 allowed), and 277 o negotiation of the cipher suite for the TLS session, and 278 o authentication of the TLS server (equivalent to the KE server) 279 using a digital X.509 certificate, 280 o verification of the TLS client (PTP instance) using its digital 281 X.509 certificate and 282 o the encryption of the subsequent information exchange between the 283 TLS communication partners. 285 TLS therefore enables peer authentication by certificates and 286 provides authenticity, message integrity and confidentiality of 287 following data transmitted over the TLS channel. 289 TLS is a layer five protocol that runs on TCP over IP. Therefore, 290 PTP implementations that support NTS-based key management need to 291 support TCP and IP (at least on a separate management port). 293 Once the TLS session is established, the PTP instance will ask for a 294 PTP key as well as the associated security parameters using the new 295 NTS message PTP Key Request (see Section 2.3.1). The NTS application 296 of the KE server will respond with either a PTP Key Grant message 297 (see Section 2.3.2), or a PTP Refusal message (see Section 2.3.3). 298 All messages are constructed from specific records as described in 299 Section 3.2. 301 When the Key Request message was responded with a PTP Key Grant or a 302 PTP Refusal the TLS session will be closed with a close notify TLS 303 message from both parties, the PTP instance and the key server. 305 With the key and other information received, the PTP instance can 306 take part in the secured PTP communication in the different modes of 307 operation. 309 After the reception of the first set of security parameters the PTP 310 instance can resume the TLS session by including a TLS session ID, 311 allowing the PTP instance to skip the TLS version and algorithm 312 negotiations. If resuming is used, a suitable lifetime for the TLS 313 session key must be defined to not open the TLS connection for 314 security threats. 316 As the TLS session provides authentication, but not authorization 317 additional means has to be used for the latter (see Section 2.2.5.4). 319 As mentioned above, the NTS key management for PTP supports two 320 principle methods, the group-based approach and the ticket-based 321 approach which are described in the following sections below. 323 2.1.1. NTS Message Exchange for Group-based Approach 325 As described in Section 2.1, a PTP instance wanting to join a secured 326 PTP communication in the group-based modes contacts the KE server 327 inside a secured TLS connection with a PTP Key Request message (see 328 Section 2.3.1) as shown in Figure 2. The KE server answers with a 329 PTP Key Grant message (see Section 2.3.2) with all the necessary data 330 to join the group communication or with a PTP Refusal message (see 331 Section 2.3.3) if the PTP instance is not allowed to join the group. 332 This procedure is necessary for all parties which are or will be 333 members of that PTP group including the Grandmaster and other special 334 participants, e.g. Transparent Clocks. As mentioned above, this not 335 only applies to multicast mode but also to mixed multicast/unicast 336 mode (former hybrid mode) where the explicit unicast communication 337 uses the multicast group key received from the KE server. The group 338 number for both modes is primarily generated by a concatenation of 339 the PTP domain number and the PTP profile (sdoId), as described in 340 Section 3.2.2. 342 Additionally, besides multicast and mixed multicast/unicast mode, a 343 group of two (or few more) PTP instances can be configured, 344 practically implementing a special group-based unicast communication 345 mode, the group-of-2 (Go2) mode. 347 Secured 348 PTP Network PTP Instance NTS-KE-Server 350 | | | 351 | | TLS: | 352 | TLS |== PTP Key Request =>| Response contains: 353 | secured | | GroupID, security 354 | communication | TLS: | parameters, group 355 | |<== PTP Key Grant ===| key, validity 356 | | | period etc. 357 | | | 358 | Secured PTP: | | 359 |--- Announce -------->| ) | 360 | | ) | 361 | | ) | 362 | Secured PTP: | ) | 363 |-- Sync & Follow_Up ->| ) | 364 | | ) Secured | 365 | | ) PTP messages | 366 | Secured PTP: | ) using | 367 |<-- Delay_Req --------| ) group key | 368 | | ) | 369 | | ) | 370 | Secured PTP: | ) | 371 |--- Delay_Resp ------>| ) | 372 | | ) | 373 | | | 374 V V V 376 Legend: TLS: Authenticated & encrypted 377 =============> TLS communication 379 Secured PTP: Group key-authenticated 380 -------------> PTP communication 382 Figure 2: Message exchange for the group-based approach 384 This mode requires additional administration in advance defining 385 groups-of-2 and supplying them with an additional attribute in 386 addition to the group number mentioned for the other group-based 387 modes - the subGroup attribute in the Association Mode record (see 388 Section 3.2.2) of the PTP Key Request message. So, addressing for 389 Go2 is achieved by use of the group number derived from domain 390 number, sdoId and the additional attribute subGroup. Communication 391 in that mode is performed using multicast addresses. If the latter 392 is undesirable, unicast addresses can be used but the particular IP 393 or MAC addresses of the communication partners need to be configured 394 upfront, too. 396 In spite of its specific name, Go2 allows more than two participants, 397 for example additional Transparent Clocks. All participants in that 398 subgroup need to be configured respectively. (To enable the KE 399 server to supply the subgroup members with the particular security 400 data the respective certificates may reflect permission to take part 401 in the subgroup. Else another authorization method is to be used.) 403 Having predefined the Go2s the key management for this mode of 404 operation follows the same procedure (see Figure 2) and uses the same 405 NTS messages as the other group-based modes. Both participants, the 406 Group-of-2 requester and the respective grantor need to have received 407 their security parameters including key etc. before secure PTP 408 communication can take place. 410 After the NTS key establishment messages for these group-based modes 411 have been exchanged, the secured PTP communication can take place 412 using the Security Association(s) communicated. 414 The key management for these modes works relatively simple and needs 415 only the above mentioned three NTS messages: PTP Key Request, PTP Key 416 Grant or PTP Refusal. The group number used for addressing is 417 automatically derived from the configured attributes domain number 418 and sdoID. 420 Additionally, besides multicast and hybrid mode, a (multicast) group 421 of two PTP instances can be configured, practically implementing a 422 special unicast communication. 424 The key management for these modes works relatively simple and needs 425 only the above mentioned three NTS messages: PTP Key Request, PTP Key 426 Grant or PTP Refusal. The group number used for addressing is 427 automatically derived from the configured attributes PTP domain 428 number and sdoId. For Go2, the attribute subGroup is additionally 429 required. 431 2.1.2. NTS Message Exchange for the Ticket-based Approach 433 In (native) PTP unicast mode using unicast message negotiation 434 ([IEEE1588-2019], 16.1) any potential instance (the grantor) which 435 can be contacted by other PTP instances (the requesters) needs to 436 register upfront with the KE server as depicted in Figure 3. 438 PTP Requester NTS-KE-Server PTP Grantor 440 | | | 441 | | TLS: |Grantor 442 | KE generates |<= PTP Registration =|registers 443 | ticket key | Request |upfront 444 | | | 445 | | TLS: |gets 446 | KE sends |== PTP Registration >|ticket 447 | ticket key | Success |key to 448 | | |decrypt 449 : : :tickets 450 : ; : 451 PTP instance| TLS: | | 452 wants unicast|= PTP Key Request =>| KE generates | 453 communication| | and sends | 454 | | unicast key | 455 | TLS: | & encrypted | 456 |<= PTP Key Grant ===| ticket | 457 | | | 458 | | | 459 | | |decrypts 460 Unicast| | |ticket, 461 request| Secured PTP: | |extracts 462 contains|- Announce Request ---------------------->|containing 463 ticket| | |unicast key 464 | | | 465 | Secured PTP: | |Grantor uses 466 |< Grant ----------------------------------|unicast key 467 | | | 468 | | | 469 V V V 471 Legend: TLS: Authenticated & encrypted 472 =============> TLS communication 474 Secured PTP: Unicast key-authenticated 475 -------------> PTP communication 477 Figure 3: Message exchange for ticket-based unicast mode 479 (Note: As any PTP instance may request unicast messages from any 480 other instance the terms requester and grantor as used in the 481 standard suit better than talking about slave resp. master. In 482 unicast PTP, the grantor is typically a PTP Port in the MASTER state, 483 and the requester is typically a PTP Port in the SLAVE state, however 484 all PTP Ports are allowed to grant and request unicast PTP message 485 contracts regardless of which state they are in. A PTP port in 486 MASTER state may be requester, a port in SLAVE state may be a 487 grantor.) 489 This registration is performed via a PTP Registration Request message 490 (see Section 2.3.4). The KE server answers with a PTP Registration 491 Success message (see Section 2.3.5) or a PTP Refusal message (see 492 Section 2.3.3). 494 With the reception of the PTP Registration Success message the 495 grantor holds a ticket key known only to the KE server and the 496 registered grantor. With this ticket key it can decrypt 497 cryptographic information contained in a so-called ticket which 498 enables secure unicast communication. 500 As with the group-based approach, a PTP instance (the requester) 501 wanting to start a secured PTP unicast communication with a specific 502 grantor contacts the KE server sending a PTP Key Request message (see 503 Section 2.3.1) as shown in Figure 3 using the TLS-secured NTS Key 504 Establishment protocol. The KE server answers with a PTP Key Grant 505 message (see Section 2.3.2) with all the necessary data to begin the 506 unicast communication with the desired partner or with a PTP Refusal 507 message (see Section 2.3.3) if unicast communication with that 508 instance is unavailable. 510 The PTP Key Grant message includes a unicast key to secure the PTP 511 message exchange with the desired grantor. In addition, it contains 512 the above mentioned encrypted ticket which the requester transmits in 513 a special Ticket TLV (see Section 4) with the secured PTP message to 514 the grantor. The grantor receiving the PTP message decrypts the 515 received ticket with its ticket key and extracts the containing 516 security parameters, for example the unicast key used by the 517 requester to secure the PTP message and the requester's identity. In 518 that way the grantor can check the received message, identify the 519 requester and can use the unicast key for further secure PTP 520 communication with the requester until the unicast key expires. 522 After the NTS key establishment messages for the PTP unicast mode 523 have been exchanged the secured PTP communication can take place 524 using the Security Association(s) communicated. 526 If a grantor is no longer at disposal for unicast mode during the 527 lifetime of registration and ticket key, it sends a TLS-secured PTP 528 Registration Revoke message (see Section 2.3.6) to the KE server, so 529 requesters no longer receive PTP Key Grant messages for this grantor. 531 This unicast mode is a bit more complex than the Group-of-2 approach 532 and eventually uses all six new NTS messages. However, no subgroups 533 have to be defined upfront. Addressing a grantor, the requesting 534 instance simply may use the grantor's IP, MAC address or PortIdentity 535 attribute. 537 2.2. General Topics 539 This section describes more general topics like key update and key 540 generation as well as discussion of the time information on the KE 541 server, the use of certificates and topics concerning upfront 542 configuration. 544 2.2.1. Key Update Process 546 All keys are equipped with parameters for a specific lifetime. 547 Thereafter new key material has to be used. The value in the 548 Lifetime record given by the KE server in the respective NTS messages 549 is specified in seconds which denote the remaining time until the key 550 expires and are decremented down to zero. So hard adjustments of the 551 clock used have to be avoided. Therefore the use of a monotonic 552 clock is recommended. Requests during the currently running lifetime 553 will receive respectively adapted count values. 555 The receiving instances may concede a Grace Time in the range of, for 556 example 5 - 10 seconds where an old key is still accepted to handle 557 internal delays gracefully. The Grace Time may be defined in a PTP 558 profile. Additionally, the KE server can optionally be configured to 559 inform about a grace time value generally to be used. 561 New security parameters will be available after the Time until Update 562 (TuU). The Time until Update given by the KE server is specified in 563 seconds which are decremented down to zero. After that point in time 564 until the end of the Lifetime of an associated key the PTP instances 565 should connect to the KE server again, to receive new security 566 parameters. The actual point in time, when a PTP instance asks for 567 new data, should be selected randomly in the update period - the time 568 after TuU was decremented to zero and before the Lifetime is counted 569 down completely - to avoid peak load on the KE server. Figure 4 570 presents an example of the key update mechanism. A PTP instance 571 sending a PTP Key Request to the KE server during the update period 572 will receive the current security parameters (Current Parameters) as 573 well as the security parameters of the following period (Next 574 Parameters). As with the lifetime, requests during the currently 575 running lifetime will receive respectively adapted count values for 576 the current TuU. 578 Lifetime and Time until Update allow a cyclic rotation of security 579 parameters during the running operation. This approach guarantees 580 continuous secured PTP communication without interruption by key 581 rotation. 583 |12,389s (at time of key request) 0s|14,400s 0s| 584 +--------------------------------------+------------------...-------+ 585 | Lifetime (curent parameters) | Lifetime (next parameters)| 586 +-----------------------------+--------+------------------...-------+ 587 | Time until Update | 900s | 588 +-----------------------------+<------>| 589 |11,489s (time of key req.) 0s| update | 590 period 591 |________| 592 | 593 V 594 Request and receive new parameters 595 at a random point in time 597 Example: 598 -------- 599 Lifetime (full): 14,400s = 4h 600 Time unitil Update (full): 13,500s -> updated period: 900s = 15 min 602 Figure 4: Example of the parameter rotation using Lifetime and Time 603 until Update in group-based mode 605 The key rotation mechanism described also applies for the ticket- 606 based approach. As there are two keys, the ticket key and the 607 unicast key, some details need to be explained (see Figure 5). When 608 the grantor registers with the KE server it receives the ticket key 609 with the PTP Registration Success message together with the Lifetime 610 and the respective Time until Update records. The lifetime 611 parameters also apply to the ticket a requester would receive. 613 A requester wanting to communicate in unicast sends a PTP Key Request 614 message with the particular parameters to the KE server. In the 615 response it receives a specific unicast key with Lifetime and TuU as 616 well as the encrypted ticket containing all the necessary security 617 information for the grantor. The lifetime of the unicast key will 618 end at the same point in time as the ticket key. Requests during the 619 currently running lifetime of the ticket key will receive 620 respectively adapted count values. The lifetime can be at most the 621 remaining lifetime of the respective ticket key of the grantor. 623 Update process grantor: 624 ----------------------- 626 (at time of registration success) 627 | 628 |14,400s 0s |14,400s 0s| 629 +--------------------------------------------------------...--------+ 630 |Lifetime (curr.ticket key) |Lifetime (next ticket k.)| 631 +-------------------------+------+--------+--------------...--------+ 632 | Time until Update | 300s | : 633 +-------------------------+<---->| : 634 |13,200s 0s|update| : 635 | period: : 636 (at time of : : 637 registration success) : : 638 : : 639 : : 640 Update process requester: : : 641 ------------------------- : : 642 : : 643 (at time of key grant) : : 644 | : : 645 |12,389s : 0s|14,400s 0s| 646 +-------------------------------------+-----------------...-----+ 647 |Lifetime (curent parameters) | Lifetime (next params.) | 648 +----------------------------+--------+-----------------...-----+ 649 | Time until Update | 900s | 650 +----------------------------+<------>| 651 |11,489s 0s| update | 652 | period 653 (at time of key grant) |________| 654 | 655 V 656 Request and receive new parameters 657 at a random point in time 659 Example: 660 -------- 661 Lifetime (full): 14,400s = 4h 662 Time unitil Update (full): 663 - requester 13,500s -> updated period: 900s = 15 min 664 Time unitil Update (full): 665 - grantor: 13,200s = ToU of requester - 300s 667 Figure 5: Example of the parameter rotation using Lifetime and Time 668 until Update in ticket-based mode 670 The TuU of the ticket key will end earlier than the TuU of associated 671 unicast keys. The grantor should re-register in its update period 672 beginning after the Time until Update of the ticket key was 673 decremented to zero and ending when an associated unicast key TuU is 674 counted down. As the grantor does not know how long its update 675 period lasts it should re-register immediately after its TuU has 676 ended. (A profile or a general configuration may fix the length of a 677 grantors' update period. Then the grantor could re-register at a 678 random point in time during its update period. Because masters 679 register asynchronously, their re-registration will also be 680 asynchronous. So typically, no peak load for the KE server will be 681 generated.) Its update period is a mere timing buffer for cases 682 where re-registration will not work instantly. The re-registration 683 should be completed before any requester can start a PTP Key Request 684 for ticket-based unicast mode. This guarantees the availability of a 685 new ticket. When re-registering in its update period the grantor 686 will receive together with the ticket key, etc., Lifetime and Time 687 until Update of the current period as well as the parameters of the 688 following period - similar to multicast keys. (A registration during 689 the TuU period will supply only current data, not parameters of the 690 following period. A late re-registration after the end of the 691 current Lifetime will start a new period with respective full 692 lifetime und update parameters.) 694 A requester needs to ask for a new unicast key and ticket at the KE 695 server during the update period for uninterrupted unicast 696 communication possibility or else at any later point in time. During 697 the update period it will receive the Current Parameters as well as 698 the Next Parameters. Embedded in the respective data, it will 699 receive the ticket for the grantor including the encrypted ticket. 700 Each ticket carries the same security information as the respective 701 Current Parameters or Next Parameters data structure. 703 If a grantor does not have re-registered (in time or at all) when 704 corresponding requesters try to get unicast keys, they will receive a 705 PTP Refusal message. 707 If a grantor has revoked his registration with a PTP Registration 708 Revoke message, requesters will receive a PTP Refusal message when 709 trying to update for a new unicast key. No immediate key revoke 710 mechanism exists. The grantor should not grant respective unicast 711 requests until the revoked key expires. 713 2.2.2. Key Generation 715 In all cases keys obtained by a secure random number generator shall 716 be used. The length of the keys depends on the MAC algorithm (see 717 also last subsection in Section 3.3.2) respectively the AEAD 718 algorithm utilized. 720 2.2.3. Time Information of the KE Server 722 As the KE server embeds time duration information in the respective 723 messages, its local time should be sufficiently precise to a maximum 724 a few seconds compared to the controlled PTP network(s). To avoid 725 any dependencies, it should synchronize to a secure external time 726 source, for example an NTS-secured NTP server. The time information 727 is also necessary to check the lifetime of certificates used. 729 2.2.4. Certificates 731 The authentication of the TLS communication parties is based on 732 certificates issued by a trusted Certificate Authority (CA) that are 733 utilized during the TLS handshake. In classical TLS applications 734 only servers are required to have them. For the key management 735 system described here, the PTP nodes also need certificates to allow 736 only authorized and trusted devices to get the group key and join a 737 secure PTP network. (As TLS only authenticates the communication 738 partners, authorization has to be managed by external means, see the 739 topic "Authorization" in Section 2.2.5.4.) The verification of a 740 certificate always requires a loose time synchronicity, because they 741 have a validity period. This, however, reveals the well-known start- 742 up problem, since secure time transfer itself requires valid 743 certificates. (See the discussion and proposals on this topic in 744 IETF RFC 8915 [RFC8915], chapter 8.5 "Initial Verification of Server 745 certificates" which applies to client certificates in the PTP key 746 management system, too.) 748 Furthermore, some kind of Public Key Infrastructure (PKI) is 749 necessary, which may be conceivable via the Online Certificate Status 750 Protocol (OCSP) as well as offline via root CA certificates. 752 The TLS communication parties must be equipped with a private key and 753 a certificate in advance. The certificate contains a digital 754 signature of the CA as well as the public key of the sender. The key 755 pair is required to establish an authenticated and encrypted channel 756 for the initial TLS phase. Distribution and update of the 757 certificates can be done manually or automatically. However, it is 758 important that they are issued by a trusted CA instance, which can be 759 either local (private CA) or external (public CA). 761 For the certificates the standard for X.509 [ITU-T_X.509] 762 certificates must be used. Additional data in the certificates like 763 domain, sdoId and/or subgroup attributes may help in authorizing. In 764 that case it should be noted that using the PTP device in another 765 network then implies to have a new certificate, too. Working with 766 certificates without authorization information would not have that 767 disadvantage, but more configuring at the KE server would be 768 necessary: which domain, sdoId and/or subgroup attributes belong to 769 which certificate. 771 As TLS is used to secure the NTS Key Establishment protocol a comment 772 on the security of TLS seems reasonable. A TLS 1.3 connection is 773 considered secure today. However, note that a DoS (Denial of 774 Service) attack on the key server can prevent new connections or 775 parameter updates for secure PTP communication. A hijacked key 776 management system is also critical, because it can completely disable 777 the protection mechanism. A redundant implementation of the key 778 server is therefore essential for a robust system. A further 779 mitigation can be the limitation of the number of TLS requests of 780 single PTP nodes to prevent flooding. But such measures are out of 781 the scope of this document. 783 2.2.5. Upfront Configuration 785 All PTP instances as well as the NTS-KE server need to be configured 786 by the network administrator. This applies to several fields of 787 parameters. 789 2.2.5.1. Security Parameters 791 The cryptographic algorithm and associated parameters (the so-called 792 Security Association(s) - SA) used for PTP keys are configured by 793 network operators at the KE server. This includes the Security 794 Policies, i.e. which PTP messages are to be secured. PTP instances 795 that do not support the configured algorithms cannot operate with the 796 security. Since most PTP Networks are managed by a single 797 organization, configuring the cryptographic algorithm (MAC) for ICV 798 calculation is practical. This prevents the need for the KE server 799 and PTP instances to implement an NTS algorithm negotiation protocol. 801 For the ticket-based approach the AEAD algorithms need to be 802 specified which the PTP grantors and the KE server support and 803 negotiate during the registration process. Optionally, the MAC 804 algorithm may be negotiated during a unicast PTP Key Request to allow 805 faster or stronger algorithms, but a standard protocol supported by 806 every instance should be defined. Eventually, suitable algorithms 807 may be defined in a respective profile. 809 2.2.5.2. Key Lifetimes 811 Supplementary to the above mentioned SAs the desired key rotation 812 periods, i.e. the lifetimes of keys resp. all security parameters 813 need to be configured at the NTS-KE server. This applies to the 814 lifetime of a group key in the group-based approach as well as the 815 lifetime of ticket key and unicast key in the ticket-based unicast 816 approach (typically for every unicast pair in general or eventually 817 specific for each requestor-grantor pair). In addition, the 818 corresponding Time until Update parameters need to be defined which 819 (together with the lifetime) specify the relevant update period. Any 820 particular Lifetime and Time until Update are configured as time 821 spans counted in seconds and start at the same point in time. 823 2.2.5.3. Certificates 825 The network administrator has to supply each PTP instance and the KE 826 server with their X.509 certificates. The TLS communication parties 827 must be equipped with a private key and a certificate containing the 828 public key in advance (see Section 2.2.4). 830 2.2.5.4. Authorization 832 The certificates provide authentication of the communication 833 partners. Normally, they do not contain authorization information. 834 Authorization decides, which PTP instances are allowed to join a 835 group (in any of the group-based modes) or may enter a unicast 836 communication in the ticket-based approach and request the respective 837 SA(s) and key. 839 As mentioned, members of a group (multicast mode, mixed multicast/ 840 unicast mode) are identified by their domain and their sdoId. PTP 841 Domain and sdoId may be attributes in the certificates of the 842 potential group members supplying additional authorization. If not 843 contained in the certificates extra authorization means are 844 necessary. (See also the discussion on advantages and disadvantages 845 on certificates containing additional authorization data in 846 Section 2.2.4.) 848 If the special Group-of-2 mode is used, the optional subGroup 849 parameter (i.e. the subgroup number) needs to be specified at all 850 members of respective Go2s, upfront. To enable the KE server to 851 supply the subgroup members with the particular security data their 852 respective certificates may reflect permission to take part in the 853 subgroup. Else another authorization method is to be used. 855 In native unicast mode, any authenticated grantor that is member of 856 the group used for multicast may request a registration for unicast 857 communication at the KE server. If it is intended for unicast, this 858 must be configured locally. If no group authorization is available 859 (e.g. pure unicast operation) another authentication scheme is 860 necessary. 862 In the same way, any requester (if configured for it locally) may 863 request security data for a unicast connection with a specific 864 grantor. Only authentication at the KE server using its certificate 865 and membership in the group used for multicast is needed. If a 866 unicast communication is not desired by the grantor, it should not 867 grant a specific unicast request. Again, if no group authorization 868 is available (e.g. pure unicast operation) another authentication 869 scheme is necessary. 871 Authorization can be executed at least in some manual configuration. 872 Probably the application of a standard access control system like 873 Diameter, RADIUS or similar would be more appropriate. Also role- 874 based access control (RBAC), attribute-based access control (ABAC) or 875 more flexible tools like Open Policy Agent (OPA) could help 876 administering larger systems. But details of the authorization of 877 PTP instances lies out of scope of this document. 879 2.2.5.5. Transparent Clocks 881 Transparent Clocks (TC) need to be supplied with respective 882 certificates, too. For group-based modes they must be configured for 883 the particular PTP domain and sdoId and eventually for the specific 884 subgroup(s) when using Group-of-2. They need to request for the 885 relevant group key(s) at the KE server to allow secure use of the 886 correctionField in a PTP message and generation of a corrected ICV. 887 If TCs are used in ticket-based unicast mode, they need to be 888 authorized for the particular unicast path. 890 Authorization of TCs for the respective groups, subgroups and unicast 891 connections is paramount. Otherwise the security can easily be 892 broken with attackers pretending to be TCs in the path. 893 Authorization of TCs is necessary too in unicast communication, even 894 if the normal unicast partners need not be especially authorized. 896 Transparent clocks may notice that the communication runs secured. 897 In the group-based approaches multicast mode and mixed multicast/ 898 unicast mode they construct the GroupID from domain and sdoId and 899 request a group key from the KE server. Similarly, they can use the 900 additional subgroup attribute in Go2 mode for a (group) key request. 901 Afterwards they can check the ICV of incoming messages, fill in the 902 correction field and generate a new ICV for outgoing messages. In 903 ticket-based unicast mode a TC may notice a secured unicast request 904 from a requester to the grantor and can request the unicast key from 905 the KE server to make use of the correction field afterwards. As 906 mentioned above upfront authentication and authorization of the 907 particular TCs is paramount not to open the secured communication to 908 attackers. 910 2.2.5.6. Start-up considerations 912 At start-up of a single PTP instance or the complete PTP network some 913 issues have to be considered. 915 At least loose time synchronization is necessary to allow for 916 authentication using the certificates. See the discussion and 917 proposals on this topic in IETF RFC 8915 [RFC8915], chapter 8.5 918 "Initial Verification of Server certificates" which applies to client 919 certificates in the PTP key management system, too. 921 Similarly to a key re-request during an update period, key requests 922 should be started at a random point in time after start-up to avoid 923 peak load on the NTS-KE server. Every grantor must register with the 924 KE server before requesters can request a unicast key (and ticket). 926 2.3. Overview of NTS Messages and their Structure for Use with PTP 928 Section 2.1 described the principle communication sequences for PTP 929 Key Request, PTP Registration Request and corresponding response 930 messages. All messages follow the "NTS Key Establishment Process" 931 stated in the first part (until the description of Fig. 3 starts) of 932 chapter 4 of IETF RFC 8915 [RFC8915]: 934 _"The NTS key establishment protocol is conducted via TCP port 935 4460. The two endpoints carry out a TLS handshake in conformance 936 with Section 3, with the client offering (via an ALPN extension 937 _[RFC7301])_, and the server accepting, an application-layer 938 protocol of "ntske/1". Immediately following a successful 939 handshake, the client SHALL send a single request as Application 940 Data encapsulated in the TLS-protected channel. Then, the server 941 SHALL send a single response. After sending their respective 942 request and response, the client and server SHALL send TLS 943 "close_notify" alerts in accordance with Section 6.1 of RFC 8446 944 _[RFC8446]. 946 _The client's request and the server's response each SHALL consist 947 of a sequence of records formatted according to_ Figure 6_. The 948 request and a non-error response each SHALL include exactly one 949 NTS Next Protocol Negotiation record. The sequence SHALL be 950 terminated by a "End of Message" record. The requirement that all 951 NTS-KE messages be terminated by an End of Message record makes 952 them self-delimiting._ 953 _Clients and servers MAY enforce length limits on requests and 954 responses, however, servers MUST accept requests of at least 1024 955 octets and clients SHOULD accept responses of at least 65536 956 octets._ 958 _The fields of an NTS-KE record are defined as follows:_ 960 _C (Critical Bit): Determines the disposition of unrecognized 961 Record Types. Implementations which receive a record with an 962 unrecognized Record Type MUST ignore the record if the Critical 963 Bit is 0 and MUST treat it as an error if the Critical Bit is 1 964 (see Section 4.1.3)._ 966 _Record Type Number: A 15-bit integer in network byte order. 967 The semantics of record types 0-7 are specified in this memo. 968 Additional type numbers SHALL be tracked through the IANA 969 Network Time Security Key Establishment Record Types registry._ 971 _Body Length: The length of the Record Body field, in octets, 972 as a 16-bit integer in network byte order. Record bodies MAY 973 have any representable length and need not be aligned to a word 974 boundary._ 976 _Record Body: The syntax and semantics of this field SHALL be 977 determined by the Record Type._ 979 _For clarity regarding bit-endianness: the Critical Bit is the 980 most-significant bit of the first octet. In the C programming 981 language, given a network buffer `unsigned char b[]` containing an 982 NTS-KE record, the critical bit is `b[0] >> 7` while the record 983 type is `((b[0] & 0x7f) << 8) + b[1]`."_ 985 0 1 2 3 986 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 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 |C| Record Type | Body Length | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | | 991 : : 992 : Record Body : 993 | | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 Figure 6: NTS-KE Record format 998 Thus, all NTS messages consist of a sequence of records, each 999 containing a Critical Bit C, the Record Type, the Body Length and the 1000 Record Body, see Figure 6. More details on record structure as well 1001 as the specific records used here are given in Section 3 and 1002 respective subsections there. So-called container records (short: 1003 container) themselves comprise a set of records in the record body 1004 that serve a specific purpose, e.g. the Current Parameter container. 1006 The records contained in a message may follow in arbitrary sequence 1007 (though nothing speaks against using the sequence given in the record 1008 descriptions), only the End of Message record has to be the last one 1009 in the sequence indicating the end of the current message. Container 1010 records do not include an End of Message record. 1012 The NTS key management for PTP is based on six new NTS messages: 1014 o PTP Key Request message (see Section 2.3.1) 1015 o PTP Key Grant message (see Section 2.3.2) 1016 o PTP Refusal message (see Section 2.3.3) 1017 o PTP Registration Request message (see Section 2.3.4) 1018 o PTP Registration Grant message (see Section 2.3.5) 1019 o PTP Registration Revoke message (see Section 2.3.6) 1021 The following sections describe the principle structure of those new 1022 NTS messages for the PTP key management. More details especially on 1023 the records the messages are built of and their types, sizes, 1024 requirements and restrictions are given in Section 3.2. 1026 2.3.1. PTP Key Request Message 1027 PTP Key Request 1028 +========================================+==========================+ 1029 | Record | Exemplary body contents | 1030 +========================================+==========================+ 1031 | NTS Next Protocol Negotiation | PTPv2.1 | 1032 +----------------------------------------+--------------------------+ 1033 | NTS Message Version | 1.0 | 1034 +----------------------------------------+--------------------------+ 1035 | NTS Message Type | PTP Key Grant | 1036 +----------------------------------------+--------------------------+ 1037 | Current Parameters | set of Records {...} | 1038 +----------------------------------------+--------------------------+ 1039 | MAC Algorithm Negotiation (optional) | {CMAC || HMAC} | 1040 +----------------------------------------+--------------------------+ 1041 | Requesting PTP Identity (Unicast only) | data set {...} | 1042 +----------------------------------------+--------------------------+ 1043 | End of Message | | 1044 +========================================+==========================+ 1046 Figure 7: Structure of a PTP Key Request message 1048 Figure 7 shows the record structure of a PTP Key Request message. In 1049 the right column typical values are shown as examples. Detailed 1050 information on types, sizes etc. is given in Section 3.2. The 1051 message starts with the NTS Next Protocol Negotiation record which in 1052 this application always holds PTPv2.1. Currently, the following NTS 1053 Message Version record always contains 1.0. The next record 1054 characterizes the message type, in this case PTP Key Request. The 1055 Association Mode record describes the mode how the PTP instance wants 1056 to communicate: In the group-based approach the desired group number 1057 (plus eventually the subgroup attribute) is given. For ticket-based 1058 unicast communication the Association Mode contains the 1059 identification of the desired grantor, for example IPv4 and its IP 1060 address. 1062 If there is an option to choose from additional MAC algorithms, then 1063 an optional record follows presenting the supported algorithms from 1064 which the KE server may choose. In ticket-based unicast mode, the 1065 Requesting PTP Identity record gives the data of the identification 1066 of the applying requester, for example IPv4 and its IP address. The 1067 messages always end with an End of Message record. 1069 2.3.2. PTP Key Grant Message 1071 Figure 8 shows the record structure of a PTP Key Grant message. In 1072 the right column typical values are shown as examples. Detailed 1073 information on types, sizes etc. is given in Section 3.2. The 1074 message starts with the NTS Next Protocol Negotiation record which in 1075 this application always holds PTPv2.1. Currently, the following NTS 1076 Message Version record always contains 1.0. The next record 1077 characterizes the message type, in this case PTP Key Grant. 1079 PTP Key Grant 1080 +=======================================+===========================+ 1081 | Record | Exemplary body contents | 1082 +=======================================+===========================+ 1083 | NTS Next Protocol Negotiation | PTPv2.1 | 1084 +---------------------------------------+---------------------------+ 1085 | NTS Message Version | 1.0 | 1086 +---------------------------------------+---------------------------+ 1087 | NTS Message Type | PTP Key Grant | 1088 +---------------------------------------+---------------------------+ 1089 | Current Parameters | set of Records {...} | 1090 +---------------------------------------+---------------------------+ 1091 | Next Parameters | set of Records {...} | 1092 +---------------------------------------+---------------------------+ 1093 | End of Message | | 1094 +=======================================+===========================+ 1096 Figure 8: Structure of a PTP Key Grant message 1098 The following Current Parameters record is a container record 1099 containing in separate records all the security data needed to join 1100 and communicate in the secured PTP communication during the current 1101 validity period. Figure 9 gives an example of data contained in that 1102 record. For more details on the records contained in the Current 1103 Parameters container see Section 3.2.3. 1105 Current Parameters Container record (PTP Key Grant) 1106 +==============================+===================================+ 1107 | Record | Exemplary body contents | 1108 +==============================+========+==========================+ 1109 | Security Policies |{(PTPmsg1||SPP:1)||(PTPmsg2||SPP:)}| 1110 +------------------------------+-----------------------------------+ 1111 | Security Association | data set for SPP:1 {...} | 1112 +------------------------------+-----------------------------------+ 1113 | [Security Association] | data set for SPP:2 {...} | 1114 +------------------------------+-----------------------------------+ 1115 | Lifetime | 1560s (=0h 26min) | 1116 +------------------------------+-----------------------------------+ 1117 | Time until pdate | 0s | 1118 +------------------------------+-----------------------------------+ 1119 | Grace Period (optional) | 10 seconds | 1120 +------------------------------+-----------------------------------+ 1121 | Ticket Key ID (Unicast only) | 156 | 1122 +------------------------------+-----------------------------------+ 1123 | Ticket (Unicast only) | data set {...} | 1124 +==============================+===================================+ 1126 Figure 9: Exemplary contents of a Current Parameters Container record 1127 of a PTP Key Grant message 1129 If the request lies inside the update interval (i.e. TuU = 0, 1130 compare Figure 9), a Next Parameters Container record is appended 1131 giving all the security data needed in the upcoming validity period. 1132 Its structure follows the same composition as the Current Parameters 1133 record (in the ticked-based approach also including the Ticket Key ID 1134 record and the Ticket record). The messages always end with an End 1135 of Message record. 1137 2.3.3. PTP Refusal Message 1139 The message starts with the NTS Next Protocol Negotiation record 1140 which in this application always holds PTPv2.1. Currently, the 1141 following NTS Message Version record always contains 1.0. The next 1142 record characterizes the message type, in this case PTP Refusal, see 1143 Figure 10. The Error record contains information about the reason of 1144 refusal. The messages always end with an End of Message record. 1146 PTP Refusal 1147 +================================+=================================+ 1148 | Record | Exemplary body contents | 1149 +================================+=================================+ 1150 | NTS Next Protocol Negotiation | PTPv2.1 | 1151 +--------------------------------+---------------------------------+ 1152 | NTS Message Version | 1.0 | 1153 +--------------------------------+---------------------------------+ 1154 | NTS Message Type | PTP Refusal | 1155 +--------------------------------+---------------------------------+ 1156 | Error | Association Port not registered | 1157 +--------------------------------+---------------------------------+ 1158 | End of Message | | 1159 +================================+=================================+ 1161 Figure 10: Structure of a PTP Refusal message 1163 2.3.4. PTP Registration Request Message 1165 PTP Registration Request 1166 +======================================+==========================+ 1167 | Record | Exemplary body contents | 1168 +======================================+==========================+ 1169 | NTS Next Protocol Negotiation | PTPv2.1 | 1170 +--------------------------------------+--------------------------+ 1171 | NTS Message Version | 1.0 | 1172 +--------------------------------------+--------------------------+ 1173 | NTS Message Type | PTP Registration Request | 1174 +--------------------------------------+--------------------------+ 1175 | Requesting PTP Identity | data set {...} | 1176 +--------------------------------------+--------------------------+ 1177 | AEAD Algorithm Negotiation | {AEAD_512 || AEAD_256} | 1178 +--------------------------------------+--------------------------+ 1179 | MAC Algorithm Negotiation (optional) | {CMAC || HMAC} | 1180 +--------------------------------------+--------------------------+ 1181 | End of Message | | 1182 +======================================+==========================+ 1184 Figure 11: Structure of a PTP Registration Request message 1186 The message starts with the NTS Next Protocol Negotiation record 1187 which in this application always holds PTPv2.1. Currently, the 1188 following NTS Message Version record always contains 1.0. The next 1189 record characterizes the message type, in this case PTP Registration 1190 Request, see Figure 11. 1192 The Requesting PTP Identity record gives the addresses of the grantor 1193 requesting registration whereas the following AEAD Algorithm 1194 Negotiation record indicates which algorithms for encryption of the 1195 ticket the requester supports. 1197 If there is an option to choose from additional MAC algorithms, then 1198 an optional record follows presenting all the grantor's supported 1199 algorithms from which the KE server may choose. The messages always 1200 end with an End of Message record. 1202 2.3.5. PTP Registration Success Message 1204 PTP Registration Success 1205 +====================================+============================+ 1206 | Record | Exemplary body contents | 1207 +====================================+============================+ 1208 | NTS Next Protocol Negotiation | PTPv2.1 | 1209 +------------------------------------+----------------------------+ 1210 | NTS Message Version | 1.0 | 1211 +------------------------------------+----------------------------+ 1212 | NTS Message Type | PTP Registration Success | 1213 +------------------------------------+----------------------------+ 1214 | Current Parameters | set of Records {...} | 1215 +------------------------------------+----------------------------+ 1216 | Next Parameters | set of Records {...} | 1217 +------------------------------------+----------------------------+ 1218 | End of Message | | 1219 +====================================+============================+ 1221 Figure 12: Structure of a PTP Registration Success message 1223 The message starts with the NTS Next Protocol Negotiation record 1224 which in this application always holds PTPv2.1. Currently, the 1225 following NTS Message Version record always contains 1.0. The next 1226 record characterizes the message type, in this case PTP Registration 1227 Success, see Figure 12. 1229 The following Current Parameters record is a container record 1230 containing in separate records all the security data needed to join 1231 and communicate in the secured PTP communication during the current 1232 validity period. Figure 13 gives an example of data contained in 1233 that container as a response to PTP Registration Request. For more 1234 details on the records contained in the Current Parameters container 1235 see Section 3.2.3. 1237 Current Parameters Container record (PTP Registration Success) 1238 +==================================+========+=====================+ 1239 | Record | Exemplary body contents | 1240 +==================================+==============================+ 1241 | AEAD Algorithm Negotiation | AEAD_CMAC_512 | 1242 +----------------------------------+------------------------------+ 1243 | Lifetime | 2,460s (=0h 41min) | 1244 +----------------------------------+------------------------------+ 1245 | Time until pdate | 0s | 1246 +----------------------------------+------------------------------+ 1247 | Ticket Key | {binary data} | 1248 +----------------------------------+------------------------------+ 1249 | Ticket Key ID | 278 | 1250 +----------------------------------+------------------------------+ 1251 | Grace Period (optional) | 10 seconds | 1252 +==================================+========+=====================+ 1254 Figure 13: Exemplary contents of a Current Parameters Container 1255 record of a PTP Registration Success message 1257 If the registration request lies inside the update interval a Next 1258 Parameters Container record is appended giving all the security data 1259 needed in the upcoming validity period. Its structure follows the 1260 same composition as the Current Parameters record. The messages 1261 always end with an End of Message record. 1263 2.3.6. PTP Registration Revoke Message 1265 PTP Registration Revoke 1266 +===================================+=============================+ 1267 | Record | Exemplary body contents | 1268 +===================================+=============================+ 1269 | NTS Next Protocol Negotiation | PTPv2.1 | 1270 +-----------------------------------+-----------------------------+ 1271 | NTS Message Version | 1.0 | 1272 +-----------------------------------+-----------------------------+ 1273 | NTS Message Type | PTP Registration Revoke | 1274 +-----------------------------------+-----------------------------+ 1275 | End of Message | | 1276 +===================================+=============================+ 1278 Figure 14: Structure of a PTP Registration Revoke message 1280 The message starts with the NTS Next Protocol Negotiation record 1281 which in this application always holds PTPv2.1. Currently, the 1282 following NTS Message Version record always contains 1.0. The next 1283 record characterizes the message type, in this case PTP Registration 1284 Revoke, see Figure 14. The messages always end with an End of 1285 Message record. 1287 3. NTS Messages for PTP 1289 This chapter covers the structure of the NTS messages and the details 1290 of the respective payload. The individual parameters are transmitted 1291 by NTS records, which are described in more detail in Section 3.2. 1292 In addition to the NTS records defined for NTP in IETF RFC8915, 1293 further records are required, which are listed in Table 1 below and 1294 begin with Record Type 1024 (compare IETF RFC 8915 [RFC8915], 7.6. 1295 Network Time Security Key Establishment Record Types Registry). 1297 +-----------+-------------------------+-----------------------------+ 1298 | NTS | Description | Reference | 1299 | Record | | | 1300 | Types | | | 1301 +-----------+-------------------------+-----------------------------+ 1302 | 0 | End of Message | [RFC8915], section 4.1.1, | 1303 | | | this document, | 1304 | | | Section 3.2.4 | 1305 | 1 | NTS Next Protocol | [RFC8915], section 4.1.2, | 1306 | | Negotiation | this document, | 1307 | | | Section 3.2.12 | 1308 | 2 | Error | [RFC8915], section 4.1.3, | 1309 | | | this document, | 1310 | | | Section 3.2.5 | 1311 | 3 | Warning | [RFC8915], section 4.1.4 | 1312 | 4 | AEAD Algorithm | [RFC8915], section 4.1.5, | 1313 | | Negotiation | this document, | 1314 | | | Section 3.2.1 | 1315 | 5 | New Cookie for NTPv4 | [RFC8915], section 4.1.6 | 1316 | | (not needed for PTP) | | 1317 | 6 | NTPv4 Server | [RFC8915], section 4.1.7 | 1318 | | Negotiation (not needed | | 1319 | | for PTP) | | 1320 | 7 | NTPv4 Port Negotiation | [RFC8915], section 4.1.8 | 1321 | | (not needed for PTP) | | 1322 | 8 - 1023 | Reserved for NTP | | 1323 | | | | 1324 | 1024 | Association Mode | This document, | 1325 | | | Section 3.2.2 | 1326 | 1025 | Current Parameters | This document, | 1327 | | Container | Section 3.2.3 | 1328 | 1026 | Grace Period | This document, | 1329 | | | Section 3.2.6 | 1330 | 1027 | Lifetime | This document, | 1331 | | | Section 3.2.7 | 1332 | 1028 | MAC Algorithm | This document, | 1333 | | Negotiation | Section 3.2.8 | 1334 | 1029 | Next Parameters | This document, | 1335 | | Container | Section 3.2.9 | 1336 | 1030 | NTS Message Type | This document, | 1337 | | | Section 3.2.10 | 1338 | 1031 | NTS Message Version | This document, | 1339 | | | Section 3.2.11 | 1340 | 1032 | Requesting PTP Identity | This document, | 1341 | | | Section 3.2.13 | 1342 | 1033 | Security Association | This document, | 1343 | | | Section 3.2.14 | 1344 | 1034 | Security Policies | This document, | 1345 | | | Section 3.2.15 | 1346 | 1035 | Ticket | This document, | 1347 | | | Section 3.2.16 | 1348 | 1036 | Ticket Container | This document, | 1349 | | | Section 3.2.17 | 1350 | 1037 | Ticket Key | This document, | 1351 | | | Section 3.2.18 | 1352 | 1038 | Ticket Key ID | This document, | 1353 | | | Section 3.2.19 | 1354 | 1039 | Time until Update | This document, | 1355 | | | Section 3.2.20 | 1356 | | | | 1357 | 1040 - | Unassigned | | 1358 | 16383 | | | 1359 | 16384 - | Reserved for Private or | [RFC8915] | 1360 | 32767 | Experimental Use | | 1361 +-----------+-------------------------+-----------------------------+ 1363 Table 1: NTS Key Establishment record types registry 1365 3.1. NTS Message Types 1367 This section repeats the composition of the specific NTS messages for 1368 the PTP key management in overview form. The specification of the 1369 respective records from which the messages are constructed follows in 1370 Section 3.2. The reference column in the tables refer to the 1371 specific subsections. 1373 The NTS messages must contain the records given for the particular 1374 message though not necessarily in the same sequence indicated. Only 1375 the End of Message record is mandatory the final record. 1377 *PTP Key Request* 1379 +---------------------+---------------+-------+---------------------+ 1380 | NTS Record Name | Comm. Type* | Use | Reference | 1381 +---------------------+---------------+-------+---------------------+ 1382 | NTS Next Protocol | Multicast / | mand. | This document, | 1383 | Negotiation | Unicast | | Section 3.2.12 | 1384 | NTS Message Version | Multicast / | mand. | This document, | 1385 | | Unicast | | Section 3.2.11 | 1386 | NTS Message Type | Multicast / | mand. | This document, | 1387 | | Unicast | | Section 3.2.10 | 1388 | Association Mode | Multicast / | mand. | This document, | 1389 | | Unicast | | Section 3.2.2 | 1390 | MAC Algorithm | Unicast | opt. | This document, | 1391 | Negotiation | | | Section 3.2.8 | 1392 | Requesting PTP | Unicast | mand. | This document, | 1393 | Identity | | | Section 3.2.13 | 1394 | End of Message | Multicast / | mand. | This document, | 1395 | | Unicast | | Section 3.2.4 | 1396 +---------------------+---------------+-------+---------------------+ 1398 * The Communication Type column refers to the intended use of the 1399 particular record for the respective PTP communication mode. 1401 Table 2: Record structure of the PTP Key Request message 1403 *PTP Key Grant* 1405 +-----------------+--------------+---------------+------------------+ 1406 | NTS Record Name | Comm. Type | Use | Reference | 1407 +-----------------+--------------+---------------+------------------+ 1408 | NTS Next | Multicast / | mand. | This document, | 1409 | Protocol | Unicast | | Section 3.2.12 | 1410 | Negotiation | | | | 1411 | NTS Message | Multicast / | mand. | This document, | 1412 | Version | Unicast | | Section 3.2.11 | 1413 | NTS Message | Multicast / | mand. | This document, | 1414 | Type | Unicast | | Section 3.2.10 | 1415 | Current | Multicast / | mand. | This document, | 1416 | Parameters | Unicast | | Section 3.2.3 | 1417 | Container | | | | 1418 | Next Parameters | Multicast / | opt. | This document, | 1419 | Container | Unicast | (conditional) | Section 3.2.9 | 1420 | End of Message | Multicast / | mand. | This document, | 1421 | | Unicast | | Section 3.2.4 | 1422 +-----------------+--------------+---------------+------------------+ 1424 Table 3: Record structure of the PTP Key Grant message 1426 The structure of the respective container records (Current Parameters 1427 Container and Next Parameters Container) used in the PTP Key Grant 1428 message is given below: 1430 +----------------------+--------------+-------+---------------------+ 1431 | NTS Record Name | Comm. Type | Use | Reference | 1432 +----------------------+--------------+-------+---------------------+ 1433 | Security Policies | Multicast / | mand. | This document, | 1434 | | Unicast | | Section 3.2.15 | 1435 | Security Association | Multicast / | mand. | This document, | 1436 | (one or more) | Unicast | | Section 3.2.14 | 1437 | Lifetime | Multicast / | mand. | This document, | 1438 | | Unicast | | Section 3.2.7 | 1439 | Time until Update | Multicast / | mand. | This document, | 1440 | | Unicast | | Section 3.2.20 | 1441 | Grace Period | Multicast / | opt. | This document, | 1442 | | Unicast | | Section 3.2.6 | 1443 | Ticket Key ID | Unicast | mand. | This document, | 1444 | | | | Section 3.2.19 | 1445 | Ticket | Unicast | mand. | This document, | 1446 | | | | Section 3.2.16 | 1447 +----------------------+--------------+-------+---------------------+ 1449 Table 4: Record structure of the container records 1451 The encrypted Ticket Container within the Ticket record also includes 1452 a set of records listed below: 1454 +----------------------+--------------+-------+---------------------+ 1455 | NTS Record Name | Comm. Type | Use | Reference | 1456 +----------------------+--------------+-------+---------------------+ 1457 | Requesting PTP | Unicast | mand. | This document, | 1458 | Identity | | | Section 3.2.13 | 1459 | Security Policies | Multicast / | mand. | This document, | 1460 | | Unicast | | Section 3.2.15 | 1461 | Security Association | Multicast / | mand. | This document, | 1462 | (one or more) | Unicast | | Section 3.2.14 | 1463 | Lifetime | Multicast / | mand. | This document, | 1464 | | Unicast | | Section 3.2.7 | 1465 | Time until Update | Multicast / | mand. | This document, | 1466 | | Unicast | | Section 3.2.20 | 1467 | Grace Period | Multicast / | opt. | This document, | 1468 | | Unicast | | Section 3.2.6 | 1469 +----------------------+--------------+-------+---------------------+ 1471 Table 5: Record structure of the enctypted Ticket container record 1472 *PTP Refusal* 1474 +---------------------+---------------+-------+---------------------+ 1475 | NTS Record Name | Comm. Type | Use | Reference | 1476 +---------------------+---------------+-------+---------------------+ 1477 | NTS Next Protocol | Multicast / | mand. | This document, | 1478 | Negotiation | Unicast | | Section 3.2.12 | 1479 | NTS Message Version | Multicast / | mand. | This document, | 1480 | | Unicast | | Section 3.2.11 | 1481 | NTS Message Type | Multicast / | mand. | This document, | 1482 | | Unicast | | Section 3.2.10 | 1483 | Error | Multicast / | mand. | This document, | 1484 | | Unicast | | Section 3.2.5 | 1485 | End of Message | Multicast / | mand. | This document, | 1486 | | Unicast | | Section 3.2.4 | 1487 +---------------------+---------------+-------+---------------------+ 1489 Table 6: Record structure of the PTP Refusal message 1491 *PTP Registration Request* 1493 +---------------------+---------------+-------+---------------------+ 1494 | NTS Record Name | Comm. Type | Use | Reference | 1495 +---------------------+---------------+-------+---------------------+ 1496 | NTS Next Protocol | Multicast / | mand. | This document, | 1497 | Negotiation | Unicast | | Section 3.2.12 | 1498 | NTS Message Version | Multicast / | mand. | This document, | 1499 | | Unicast | | Section 3.2.11 | 1500 | NTS Message Type | Multicast / | mand. | This document, | 1501 | | Unicast | | Section 3.2.10 | 1502 | Requesting PTP | Unicast | mand. | This document, | 1503 | Identity | | | Section 3.2.13 | 1504 | AEAD Algorithm | Unicast | mand. | This document, | 1505 | Negotiation | | | Section 3.2.1 | 1506 | MAC Algorithm | Unicast | opt. | This document, | 1507 | Negotiation | | | Section 3.2.8 | 1508 | End of Message | Multicast / | mand. | This document, | 1509 | | Unicast | | Section 3.2.4 | 1510 +---------------------+---------------+-------+---------------------+ 1512 Table 7: Record structure of the PTP Registration Request message 1513 *PTP Registration Success* 1515 +------------------+-------------+---------------+------------------+ 1516 | NTS Record Name | Comm. Type | Use | Reference | 1517 +------------------+-------------+---------------+------------------+ 1518 | NTS Next | Multicast / | mand. | This document, | 1519 | Protocol | Unicast | | Section 3.2.12 | 1520 | Negotiation | | | | 1521 | NTS Message | Multicast / | mand. | This document, | 1522 | Version | Unicast | | Section 3.2.11 | 1523 | NTS Message Type | Multicast / | mand. | This document, | 1524 | | Unicast | | Section 3.2.10 | 1525 | Current | Multicast / | mand. | This document, | 1526 | Parameters | Unicast | | Section 3.2.3 | 1527 | Container | | | | 1528 | Next Parameters | Multicast / | mand. | This document, | 1529 | Container | Unicast | (conditional) | Section 3.2.9 | 1530 | End of Message | Multicast / | mand. | This document, | 1531 | | Unicast | | Section 3.2.4 | 1532 +------------------+-------------+---------------+------------------+ 1534 Table 8: Record structure of the PTP Registration Success message 1536 The structure of the respective container records (Current Parameters 1537 Container and Next Parameters Container) used in the PTP Registration 1538 Success message is given below: 1540 +--------------------+---------------+-------+----------------------+ 1541 | NTS Record Name | Comm. Type | Use | Reference | 1542 +--------------------+---------------+-------+----------------------+ 1543 | AEAD Algorithm | Unicast | mand. | This document, | 1544 | Negotiation | | | Section 3.2.1 | 1545 | Lifetime | Multicast / | mand. | This document, | 1546 | | Unicast | | Section 3.2.7 | 1547 | Time until Update | Multicast / | mand. | This document, | 1548 | | Unicast | | Section 3.2.20 | 1549 | Grace Period | Multicast / | opt. | This document, | 1550 | | Unicast | | Section 3.2.6 | 1551 | Ticket Key ID | Unicast | mand. | This document, | 1552 | | | | Section 3.2.19 | 1553 | Ticket | Unicast | mand. | This document, | 1554 | | | | Section 3.2.16 | 1555 +--------------------+---------------+-------+----------------------+ 1557 Table 9: Record structure of the container records in th PTP 1558 Regsitration Success message 1559 *PTP Registration Revoke* 1561 +---------------------+---------------+-------+---------------------+ 1562 | NTS Record Name | Comm. Type | Use | Reference | 1563 +---------------------+---------------+-------+---------------------+ 1564 | NTS Next Protocol | Multicast / | mand. | This document, | 1565 | Negotiation | Unicast | | Section 3.2.12 | 1566 | NTS Message Version | Multicast / | mand. | This document, | 1567 | | Unicast | | Section 3.2.11 | 1568 | NTS Message Type | Multicast / | mand. | This document, | 1569 | | Unicast | | Section 3.2.10 | 1570 | End of Message | Multicast / | mand. | This document, | 1571 | | Unicast | | Section 3.2.4 | 1572 +---------------------+---------------+-------+---------------------+ 1574 Table 10: Record structure of the PTP Registration Revoke message 1576 3.2. NTS Records 1578 The following subsections describe the specific NTS records used to 1579 construct the NTS messages for the PTP key management system in 1580 detail. They appear in alphabetic sequence of their individual 1581 names. See Section 3.1 for the application of the records in the 1582 respective messages. 1584 Note: For easier editing of the content, most of the descriptions in 1585 the following subsections are written as bullet points. 1587 Global rules: 1589 o The NTS Next Protocol Negotiation record MUST offer (at least) 1590 Protocol ID 1 for "PTPv2.1" (see Section 3.2.12). 1591 o The NTS Message Version record MUST be v1.0. 1592 o Note: Records must be used only in the mentioned messages. Not 1593 elsewhere. 1594 o The notational conventions of Section 1 MUST be followed. 1596 3.2.1. AEAD Algorithm Negotiation 1598 This record is required in unicast mode and enables the negotiation 1599 of the AEAD algorithm needed to encrypt and decrypt the ticket. The 1600 negotiation takes place between the PTP grantor and the NTS-KE server 1601 by using the NTS registration messages. The structure and properties 1602 follow the record defined in IETF RFC 8915 [RFC8915], 4.1.5. 1604 Content and conditions: 1606 o The record has a Record Type number of 4 and the Critical Bit MAY 1607 be set. 1608 o The record body contains a sequence of 16-bit unsigned integers in 1609 network byte order: 1611 *Supported AEAD Algorithms = {AEAD 1 || AEAD 2 || ...}* 1613 o Each integer represents a numeric identifier of an AEAD algorithm 1614 registered by the IANA. (https://www.iana.org/assignments/aead- 1615 parameters/aead-parameters.xhtml) 1616 o Duplicate identifiers SHOULD NOT be included. 1617 o Grantor and NTS-KE server MUST support at least the 1618 AEAD_AES_SIV_CMAC_256 algorithm. 1619 o A list of recommended AEAD algorithms is shown in the following 1620 table. 1621 o Other AEAD algorithms MAY also be used. 1623 +----------+------------------------+-------+-----------+-----------+ 1624 | Numeric | AEAD Algorithm | Use | Key | Reference | 1625 | ID | | | Length | | 1626 | | | | (Octets) | | 1627 +----------+------------------------+-------+-----------+-----------+ 1628 | 15 | AEAD_AES_SIV_CMAC_256 | Mand. | 16 | [RFC5297] | 1629 | 16 | AEAD_AES_SIV_CMAC_385 | Opt. | 24 | [RFC5297] | 1630 | 18 | AEAD_AES_SIV_CMAC_512 | Opt. | 32 | [RFC5297] | 1631 | 32 - | Unassigned | | | | 1632 | 32767 | | | | | 1633 | 32768 - | Reserved for Private | | | [RFC5116] | 1634 | 65535 | or Experimental Use | | | | 1635 +----------+------------------------+-------+-----------+-----------+ 1637 Table 11: AEAD algorithms 1639 o In a PTP Registration Request message, this record MUST be 1640 contained exactly once. 1641 o In this message at least the AEAD_AES_SIV_CMAC_256 algorithm MUST 1642 be included. 1643 o If multiple AEAD algorithms are supported, the grantor SHOULD put 1644 the algorithm identifiers in descending priority in the record 1645 body. 1646 o Strong algorithms with higher bit lengths SHOULD have higher 1647 priority. 1649 o In a PTP Registration Success message, this record MUST be 1650 contained exactly once in the Current Parameters Container record 1651 and exactly once in the Next Parameters Container record. 1652 o The Next Parameters Container MUST be present only during the 1653 update period. 1655 o The KE server SHOULD choose the highest priority AEAD algorithm 1656 from the request message that grantor and KE server support. 1657 o The KE server MAY ignore the priority and choose a different 1658 algorithm that grantor and KE server support. 1659 o In a PTP Registration Success message, this record MUST contain 1660 exactly one AEAD algorithm. 1661 o The selected algorithm MAY differ in the Current Parameters 1662 Container and Next Parameters Container records. 1664 3.2.2. Association Mode 1666 This record enables the NTS-KE server to distinguish between a group 1667 based request (multicast, mixed multicast/unicast, Group-of-2) or a 1668 unicast request. A multicast request carries a group number, while a 1669 unicast request contains an identification attribute of the grantor 1670 (e.g. IP address or PortIdentity). 1672 Content and conditions: 1674 o In a PTP Key Request message, this record MUST be contained 1675 exactly once. 1676 o The record has a Record Type number of 1024 and the Critical Bit 1677 MAY be set. 1678 o The record body SHALL consist of two data fields: 1680 +-------------------+--------+--------+ 1681 | Field | Octets | Offset | 1682 +-------------------+--------+--------+ 1683 | Association Type | 2 | 0 | 1684 | Association Value | A | 2 | 1685 +-------------------+--------+--------+ 1687 Table 12: Association 1689 o The Association Type is a 16-bit unsigned integer. 1690 o The length of Association Value depends on the value of 1691 Association Type. 1692 o All data in the fields are stored in network byte order. 1693 o The type numbers of Association Type as well as the length and 1694 content of Association Value are shown in the following table and 1695 more details are given below. 1697 +--------------+----------+-------------+----------------+----------+ 1698 | Description | Assoc. | Association | Association | Assoc. | 1699 | | Type | Mode | Value Content | Value | 1700 | | Number | | | Octets | 1701 +--------------+----------+-------------+----------------+----------+ 1702 | Group | 0 | Multicast / | Group Number | 5 | 1703 | | | Unicast* | | | 1704 | IPv4 | 1 | Unicast | IPv4 address | 4 | 1705 | | | | of the target | | 1706 | | | | port | | 1707 | IPv6 | 2 | Unicast | IPv6 address | 16 | 1708 | | | | of the target | | 1709 | | | | port | | 1710 | 802.3 | 3 | Unicast | MAC address of | 6 | 1711 | | | | the target | | 1712 | | | | port | | 1713 | PortIdentity | 4 | Unicast | PortIdentity | 10 | 1714 | | | | of the target | | 1715 | | | | PTP entity | | 1716 +--------------+----------+-------------+----------------+----------+ 1718 Unicast*: predefined groups of two (Group-of-2, Go2, see Group entry 1719 below) 1721 Table 13: Association Types 1723 Group: 1725 o This association type allows a PTP instance to join a PTP 1726 multicast group. 1727 o A group is identified by the PTP domain, the PTP profile (sdoId) 1728 and a sub-group attribute (see table below). 1729 o The PTP domainNumber is an 8-bit unsigned integer in the closed 1730 range 0 to 255. 1731 o The sdoId of a PTP domain is a 12-bit unsigned integer in the 1732 closed range 0 to 4095: 1734 * The most significant 4 bits are named the majorSdoId. 1735 * The least significant 8 bits are named the minorSdoId. 1736 * Reference: IEEE Std 1588-2019, 7.1.1 1738 *sdoId = {majorSdoId || minorSdoId}* 1740 o The subGroup is 16-bit unsigned integer, which allows the division 1741 of a PTP multicast network into separate groups, each with 1742 individual security parameters. 1743 o This also allows manually configured unicast connections (Group- 1744 of-2), which can include transparent clocks as well. 1746 o The subGroup number is defined manually by the administrator. 1747 o Access to the groups is controlled by authorization procedures of 1748 the PTP devices (see Section 2.2.5.4). 1749 o If no subgroups are required (=multicast mode), this attribute 1750 MUST contain the value zero. 1752 o The group number is eventually formed by concatenation of the 1753 following values: 1755 *group number = {domainNumber || 4 bit zero padding || sdoId || 1756 subGroup}* 1758 This is equvalent to: 1760 +---------------------+--------------------+--------+--------+ 1761 | Bits 7 - 4 | Bits 3 - 0 | Octets | Offset | 1762 +---------------------+--------------------+--------+--------+ 1763 | domainNumber (high) | domainNumber (low) | 1 | 0 | 1764 | zero padding | majorSdoId | 1 | 1 | 1765 | minorSdoId (high) | minorSdoId (low) | 1 | 2 | 1766 | subgroup (high) | subGroup (low) | 2 | 4 | 1767 +---------------------+--------------------+--------+--------+ 1769 Table 14: Group Association 1771 IPv4: 1773 o This Association Type allows a requester to establish a PTP 1774 unicast connection to the desired grantor. 1775 o The Association Value contains the IPv4 address of the target PTP 1776 entity. 1777 o The total length is 4 octets. 1779 IPv6: 1781 o This Association Type allows a requester to establish a PTP 1782 unicast connection to the desired grantor. 1783 o The Association Value contains the IPv6 address of the target PTP 1784 entity. 1785 o The total length is 16 octets. 1787 802.3: 1789 o This Association Type allows a requester to establish a PTP 1790 unicast connection to the desired grantor. 1791 o The Association Value contains the MAC address of the Ethernet 1792 port of the target PTP entity. 1793 o The total length is 6 octets. 1795 o This method supports the 802.3 mode in PTP, where no UDP/IP stack 1796 is used. 1798 PortIdentity: 1800 o This Association Type allows a requester to establish a PTP 1801 unicast connection to the desired grantor. 1802 o The Association Value contains the PortIdentity of the target PTP 1803 entity. 1804 o The total length is 10 octets. 1806 o The PortIdentity consists of the attributes clockIdentity and 1807 portNumber: 1809 *PortIdentity = {clockIdentity || portNumber}* 1811 o The clockIdentity is an 8 octet array and the portNumber is a 1812 16-bit unsigned integer. 1813 o Source: IEEE Std 1588-2019, 5.3.5, 7.5 1815 3.2.3. Current Parameters Container 1817 This record is a simple container that can carry an arbitrary number 1818 of NTS records. It holds all security parameters relevant for the 1819 current validity period. The content as well as further conditions 1820 are defined by the respective NTS messages. The order of the 1821 included records is arbitrary and the parsing rules are so far 1822 identical with the NTS message. One exception: An End of Message 1823 record SHOULD NOT be present and MUST be ignored. When the parser 1824 reaches the end of the Record Body quantified by the Body Length, all 1825 embedded records have been processed. 1827 Content and conditions: 1829 o The record has a Record Type number of 1025 and the Critical Bit 1830 MAY be set. 1832 o In a PTP Key Grant message, this record MUST be contained exactly 1833 once. 1834 o The record body is defined as a set of records and MAY contain the 1835 following records: 1837 +-----------------------+--------------+-------+--------------------+ 1838 | NTS Record Name | Comunication | Use | Reference | 1839 | | Type | | | 1840 +-----------------------+--------------+-------+--------------------+ 1841 | Security Policies | Multicast / | Mand. | This document, | 1842 | | Unicast | | Section 3.2.15 | 1843 | Security Associations | Multicast / | Mand. | This document, | 1844 | (one or more) | Unicast | | Section 3.2.14 | 1845 | Lifetime | Multicast / | Mand. | This document, | 1846 | | Unicast | | Section 3.2.7 | 1847 | Time until Update | Multicast / | Mand. | This document, | 1848 | | Unicast | | Section 3.2.20 | 1849 | Grace Period | Multicast / | Opt. | This document, | 1850 | | Unicast | | Section 3.2.6 | 1851 | Ticket Key ID | Unicast | Mand. | This document, | 1852 | | | | Section 3.2.19 | 1853 | Ticket | Unicast | Mand. | This document, | 1854 | | | | Section 3.2.16 | 1855 +-----------------------+--------------+-------+--------------------+ 1857 Table 15: Current Parameters Container for PTP Key Grant message 1859 o The records Security Policies, Lifetime and Time until Update MUST 1860 be contained exactly once. 1861 o The number of the Security Association records depends on the 1862 content of the Security Policies record (see Section 3.2.15). 1863 o At least one Security Association record MUST be included. 1864 o The Grace Period record is optional and MAY be absent. 1865 o If it is present, it MUST be included exactly once. 1866 o In order to establish a unicast connection with the PTP Key Grant 1867 message, the records Ticket Key ID and Ticket MUST be contained 1868 exactly once. 1869 o If the requester wants to join a multicast group, the records 1870 Ticket Key ID and Ticket MUST NOT be included. 1872 o In a PTP Registration Success message, the Current Parameters 1873 Container record MUST be contained exactly once. 1874 o The record body MAY contain the following records: 1876 +----------------------------+-------+------------------------------+ 1877 | NTS Record Name | Use | Reference | 1878 +----------------------------+-------+------------------------------+ 1879 | AEAD Algorithm Negotiation | Mand. | This document, Section 3.2.1 | 1880 | Lifetime | Mand. | This document, Section 3.2.7 | 1881 | Time until Update | Mand. | This document, | 1882 | | | Section 3.2.20 | 1883 | Grace Period | Opt. | This document, Section 3.2.6 | 1884 | Ticket Key ID | Mand. | This document, | 1885 | | | Section 3.2.19 | 1886 | Ticket | Mand. | This document, | 1887 | | | Section 3.2.16 | 1888 +----------------------------+-------+------------------------------+ 1890 Table 16: Current Parameters Container for PTP Registration Success 1891 Message 1893 o The records AEAD Algorithm Negotiation, Lifetime, Time until 1894 Update, Ticket Key ID and Ticket Key MUST be contained exactly 1895 once. 1896 o The Grace Period record is optional and MAY be absent. 1897 o If it is present, it MUST be included exactly once. 1899 3.2.4. End of Message 1901 The End of Message record is defined in IETF RFC8915 [RFC8915], 4: 1903 _"The record sequence in an NTS message SHALL be terminated by an 1904 "End of Message" record. The requirement that all NTS-KE messages 1905 be terminated by an End of Message record makes them self- 1906 delimiting."_ 1908 Content and conditions: 1910 o The record has a Record Type number of 0 and a zero-length body. 1911 o The Critical Bit MUST be set. 1912 o This record MUST occur exactly once as the final record of every 1913 NTS request and response message. 1914 o This record SHOULD NOT be included in the container records and 1915 MUST be ignored if present. 1916 o See also: IETF RFC8915, 4.1.1 1918 3.2.5. Error 1920 The Error record is defined in IETF RFC8915 [RFC8915], 4.1.3. In 1921 addition to the Error codes 0 to 2 specified there the following 1922 Error codes 3 to 4 are defined: 1924 +---------------+------------------------------------------+ 1925 | Error Code | Description | 1926 +---------------+------------------------------------------+ 1927 | 0 | Unrecognized Critical Record | 1928 | 1 | Bad Request | 1929 | 2 | Internal Server Error | 1930 | 3 | Requester not Authorized | 1931 | 4 | Grantor not Registered | 1932 | 5 - 32767 | Unassigned | 1933 | 32768 - 65535 | Reserved for Private or Experimental Use | 1934 +---------------+------------------------------------------+ 1936 Table 17: Error Codes 1938 Content and conditions: 1940 o The record has a Record Type number of 2 and body length of two 1941 octets consisting of an unsigned 16-bit integer in network byte 1942 order, denoting an error code. 1943 o The Critical Bit MUST be set. 1945 o The Error code 3 "Requester not Authorized" is sent by the KE 1946 server if the requester is not authorized to join the desired 1947 multicast group. 1948 o This Error code MUST NOT be included as a response to PTP 1949 Registration Request message. 1951 o The Error code 4 "Grantor not Registered" is sent by the KE server 1952 when the requester wants to establish a unicast connection to a 1953 grantor that is not registered with the KE server. 1954 o This Error code MUST NOT be included as a response to a PTP Key 1955 Request message. 1957 3.2.6. Grace Period 1959 The Grace Period determines the time period in which expired security 1960 parameters may still be accepted. It allows the verification of PTP 1961 messages, which have been secured with the previous key at the 1962 rotation time of the security parameters. 1964 Content and conditions: 1966 o The record has a Record Type number of 1026 and the Critical Bit 1967 SHOULD NOT be set. 1968 o The record body consists of a 16-bit unsigned integer in network 1969 byte order. 1970 o This value contains the transition time in seconds in which an 1971 expired key MAY still be accepted. 1973 o A time of zero seconds is valid. 1974 o If this optional record is absent, a default time of zero seconds 1975 is used unless a PTP profile defines something else. 1977 o The Grace Period record MAY only appear as part of a PTP Key Grant 1978 or PTP Registration Success message. 1979 o In a PTP Key Grant message, the Grace Period MAY be in the Current 1980 Parameters Container and Next Parameters Container records, as 1981 well as a part of the encrypted Ticket Container (if present). 1982 o The Grace Period record MUST NOT appear more than once in each 1983 container or ticket. 1985 o In a PTP Registration Success message, the Grace Period record MAY 1986 be present in the Current Parameters Container record as well as 1987 in the Next Parameters Container record. 1988 o The Grace Period MUST NOT be included more than once in each of 1989 those container records. 1991 o The Next Parameters Container MUST be present only during the 1992 update period. 1994 3.2.7. Lifetime 1996 This record specifies the lifetime of a defined set of parameters. 1997 The value contained in this record is counted down by the receiver of 1998 the NTS message every second. When the value reaches zero, the 1999 parameters associated with this record are considered to have 2000 expired. 2002 Content and conditions: 2004 o The record has a Record Type number of 1027 and the Critical Bit 2005 MAY be set. 2006 o The record body consists of a 32-bit unsigned integer in network 2007 byte order, denoting the expiration time of specific parameters in 2008 seconds. 2010 o The maximum value is set by the NTS-KE administrator or the PTP 2011 profile. 2012 o In conjunction with a PTP unicast establishment, the Lifetime of 2013 the unicast key, the ticket key and registration lifetime of a 2014 grantor with the KE server MUST be identical. 2016 o The Lifetime record MAY only appear as part of a PTP Key Grant or 2017 PTP Registration Success message. 2018 o In both messages, the Next Parameters Container MUST be present 2019 only during the update period. 2021 o In a PTP Key Grant message, the Lifetime record MUST be included 2022 exactly once in the Current Parameters Container and Next 2023 Parameters Container records, as well as in the encrypted Ticket 2024 Container (only present in a unicast PTP Key Grant message). 2025 o In a PTP Registration Success message, the Lifetime MUST be 2026 included exactly once in both records, Current Parameters 2027 Container and Next Parameters Container. 2029 Notes: 2031 o Requests during the currently running lifetime will receive 2032 respectively adapted count values. 2033 o The lifetime is a counter that is decremented and marks the 2034 expiration of defined parameters when the value reaches zero. 2035 o The realization is implementation-dependent and can be done for 2036 example by a secondly decrementing. 2037 o It must be ensured that jumps (e.g. by adjustment of the local 2038 clock) are avoided. 2039 o The use of a monotonic clock is suitable for this. 2040 o Furthermore, it is to be considered which consequences the 2041 drifting of the local clock can cause. 2042 o With sufficiently small values of the lifetime (<12 hours), this 2043 factor should be negligible. 2045 3.2.8. MAC Algorithm Negotiation 2047 This optional record allows free negotiation of the MAC algorithm 2048 needed to generate the ICV. Since multicast groups are restricted to 2049 a shared algorithm, this record is only used in unicast mode. 2051 Content and conditions: 2053 o The record has a Record Type number of 1028 and the Critical Bit 2054 MAY be set. 2055 o The record body contains a sequence of 16-bit unsigned integers in 2056 network byte order. 2058 *Supported MAC Algorithms = {MAC 1 || MAC 2 || ...}* 2060 o Each integer represents a MAC Algorithm Type defined in the table 2061 below. 2062 o Duplicate identifiers SHOULD NOT be included. 2063 o Each PTP node MUST support at least the HMAC-SHA256-128 algorithm. 2065 +------------+---------------------+------------+-------------------+ 2066 | MAC | MAC Algorithm | ICV Length | Reference | 2067 | Algorithm | | (octets) | | 2068 | Types | | | | 2069 +------------+---------------------+------------+-------------------+ 2070 | 0 | HMAC-SHA256-128 | 16 | [FIPS-PUB-198-1], | 2071 | | | | [IEEE1588-2019] | 2072 | 1 | HMAC-SHA256 | 32 | [FIPS-PUB-198-1] | 2073 | 2 | AES-CMAC | 16 | [RFC4493] | 2074 | 3 | AES-GMAC-128 | 16 | [RFC4543] | 2075 | 4 | AES-GMAC-192 | 24 | [RFC4543] | 2076 | 5 | AES-GMAC-256 | 32 | [RFC4543] | 2077 | 6 - 32767 | Unassigned | | | 2078 | 32768 - | Reserved for | | | 2079 | 65535 | Private or | | | 2080 | | Experimental Use | | | 2081 +------------+---------------------+------------+-------------------+ 2083 Table 18: MAC Algorithms 2085 In PTP multicast mode: 2087 o This record is not necessary, since all PTP nodes in a multicast 2088 group MUST support the same MAC algorithm. 2089 o Therefore, this record SHOULD NOT be included in a PTP Key Request 2090 massage and the NTS-KE server MUST ignore this record. 2091 o Unless this is specified by a PTP profile, the HMAC-SHA256-128 2092 algorithm SHALL be used by default. 2094 In PTP unicast mode: 2096 o In a PTP Key Request message, this record MAY be contained if the 2097 requester wants a unicast connection to a specific grantor. 2098 o The requester MUST NOT send more than one record of this type. 2099 o If this record is present, at least the HMAC-SHA256-128 MAC 2100 algorithm MUST be included. 2101 o If multiple MAC algorithms are supported, the requester SHOULD put 2102 the desired algorithm identifiers in descending priority in the 2103 record body. 2104 o Strong algorithms with higher bit lengths SHOULD have higher 2105 priority. 2106 o The default MAC algorithm (HMAC-SHA256-128) MAY be omitted in the 2107 record. 2109 o In a PTP Registration Request message, this record MUST be present 2110 and the grantor MUST include all supported MAC algorithms in any 2111 order. 2113 o The KE server selects the algorithm after receiving a PTP Key 2114 Request message in unicast mode. 2115 o The KE server SHOULD choose the highest priority MAC algorithm 2116 from the request message that grantor and requester support. 2117 o The KE server MAY ignore the priority and choose a different 2118 algorithm that grantor and requester support. 2119 o If the MAC Algorithm Negotiation record is not within the PTP Key 2120 Request message, the KE server MUST choose the default algorithm 2121 HMAC-SHA256-128. 2123 Initialization Vector (IV) 2125 o If GMAC is to be supported as a MAC algorithm, then an 2126 Initialization Vector (IV) must be constructed according to IETF 2127 RFC 4543, 3.1. 2128 o Therefore, the IV MUST be eight octets long and MUST NOT be 2129 repeated for a specific key. 2130 o This can be achieved, for example, by using a counter. 2132 3.2.9. Next Parameters Container 2134 This record is a simple container that can carry an arbitrary number 2135 of NTS records. It holds all security parameters relevant for the 2136 upcoming validity period. The content as well as further conditions 2137 are defined by the respective NTS messages. The order of the 2138 included records is arbitrary and the parsing rules are so far 2139 identical with the NTS message. One exception: An End of Message 2140 record SHOULD NOT be present and MUST be ignored. When the parser 2141 reaches the end of the Record Body quantified by the Body Length, all 2142 embedded records have been processed. 2144 Content and conditions: 2146 o The record has a Record Type number of 1029 and the Critical Bit 2147 MAY be set. 2148 o The record body is defined as a set of records. 2149 o The structure of the record body and all conditions MUST be 2150 identical to the rules described in Section 3.2.3 of this 2151 document. 2153 o In both the PTP Key Grant and PTP Registration Success message, 2154 this record MUST be contained exactly once during the update 2155 period. 2156 o Outside the update period, this record MUST NOT be included. 2157 o In multicast mode, this record MAY also be missing if the 2158 requester is to be explicitly excluded from a multicast group 2159 after the security parameter rotation process by the KE server. 2161 o The update period starts with the expiration of the Time until 2162 Update timer, which is stored in the Current Parameter Container 2163 record. 2164 o In the PTP Key Grant and PTP Registration Success message, the 2165 expiration of the Lifetime marks the end of the update period. 2166 o More details are described in Section 2.2.1. 2168 3.2.10. NTS Message Type 2170 This record enables the distinction between different NTS message 2171 types for PTP. 2173 Content and conditions: 2175 o The record has a Record Type number of 1030 and the Critical Bit 2176 MUST be set. 2177 o The record body is a 16-bit unsigned integer in network byte 2178 order, denoting the type of the current NTS message for PTP. 2179 o The message types are defined in the following table. 2180 o More details about the messages are described in Section 2.3 2182 +-------------------------+-----------------------------------------+ 2183 | NTS Message Type Number | NTS Message Name | 2184 +-------------------------+-----------------------------------------+ 2185 | 0 | PTP Key Request | 2186 | 1 | PTP Key Grant | 2187 | 2 | PTP Refusal | 2188 | 3 | PTP Registration Request | 2189 | 4 | PTP Registration Success | 2190 | 5 | PTP Registration Revoke | 2191 | 6 - 32767 | Unassigned | 2192 | 32768 - 65535 | Reserved for Private or Experimental | 2193 | | Use | 2194 +-------------------------+-----------------------------------------+ 2196 Table 19: NTS message type numbers 2198 3.2.11. NTS Message Version 2200 This record enables the distinction between different NTS message 2201 versions for PTP. It provides the possibility to update or extend 2202 the NTS messages in future specifications. 2204 Content and conditions: 2206 o The record has a Record Type number of 1031 and the Critical Bit 2207 MUST be set. 2209 o The record body consists of a tuple of two 8-bit unsigned integers 2210 in network byte order. 2211 o The first octet represents the major version and the second octet 2212 the minor version. 2214 *NTS Message Version = {major version || minor version}* 2216 o The representable version is therefore in the range 0.0 to 255.255 2217 (e.g. v1.4 = 0104h). 2218 o All NTS messages for PTPv2.1 described in this document are in 2219 version number 1.0. 2220 o Thus the record body MUST match 0100h. 2222 3.2.12. NTS Next Protocol Negotiation 2224 The Next Protocol Negotiation record is defined in IETF RFC8915 2225 [RFC8915], 4.1.2: 2227 _"The Protocol IDs listed in the client's NTS Next Protocol 2228 Negotiation record denote those protocols that the client wishes 2229 to speak using the key material established through this NTS-KE 2230 server session. Protocol IDs listed in the NTS-KE server's 2231 response MUST comprise a subset of those listed in the request and 2232 denote those protocols that the NTP server is willing and able to 2233 speak using the key material established through this NTS-KE 2234 server session. The client MAY proceed with one or more of them. 2235 The request MUST list at least one protocol, but the response MAY 2236 be empty."_ 2238 Content and conditions: 2240 o The record has a Record Type number of 1 and the Critical Bit MUST 2241 be set. 2242 o The record body consists of a sequence of 16-bit unsigned integers 2243 in network byte order. 2245 *Record body = {Protocol ID 1 || Protocol ID 2 || ...}* 2247 o Each integer represents a Protocol ID from the IANA "Network Time 2248 Security Next Protocols" registry as shown in the table below. 2249 o For NTS requests messages for PTPv2.1, only the Protocol ID for 2250 PTPv2.1 SHOULD be included. 2251 o This prevents the mixing of records for different time protocols. 2253 +-------------+--------------------------------------+--------------+ 2254 | Protocol ID | Protocol Name | Reference | 2255 +-------------+--------------------------------------+--------------+ 2256 | 0 | Network Time Protocol version 4 | [RFC8915], | 2257 | | (NTPv4) | 7.7 | 2258 | 1 | Precision Time Protocol version 2.1 | This | 2259 | | (PTPv2.1) | document | 2260 | 2 - 32767 | Unassigned | | 2261 | 32768 - | Reserved for Private or Experimental | | 2262 | 65535 | Use | | 2263 +-------------+--------------------------------------+--------------+ 2265 Table 20: NTS next protocol IDs 2267 Possible NTP/PTP conflict: 2269 o The support of multiple protocols in this record may lead to the 2270 problem that records in NTS messages can no longer be assigned to 2271 a specific time protocol. 2272 o For example, an NTS request could include records for both NTP and 2273 PTP. 2274 o However, NTS4NTP does not use NTS message types and the End of 2275 Message record is also not defined for the case of multiple NTS 2276 requests in one TLS message. 2277 o This leads to the mixing of the records in the NTS messages. 2279 o A countermeasure is the use of only a single time protocol in the 2280 NTS Next Protocol Negotiation record that explicitly assigns the 2281 NTS message to a specific time protocol. 2282 o When using NTS-secured NTP and NTS-secured PTP, two separate NTS 2283 requests i.e. two separate TLS sessions MUST be made. 2285 3.2.13. Requesting PTP Identity 2287 This record allows the KE server to associate an NTS unicast request 2288 of a requester with a registered grantor based on their address or 2289 identifier (e.g.: IP address or PortIdentity). Furthermore, this 2290 record allows the grantor to verify the origin of a secured PTP 2291 message that is currently transmitting a ticket. 2293 Content and conditions: 2295 o The record has a Record Type number of 1032 and the Critical Bit 2296 MAY be set. 2297 o The record body consists of a set of Association Types together 2298 with their respective Association Values. 2300 +---------------------+--------+---------+ 2301 | Field | Octets | Offset | 2302 +---------------------+--------+---------+ 2303 | Association Type 1 | 2 | 0 | 2304 | Association Value 1 | A1 | 2 | 2305 | Association Type 2 | 2 | A1+2 | 2306 | Association Value 2 | A2 | A1+4 | 2307 | Association Type n | A2 | A1+A2+4 | 2308 | Association Value n | An | A1+A2+6 | 2309 +---------------------+--------+---------+ 2311 Table 21: Requesting PTP identity list 2313 o Structure and values are based on the contents defined in 2314 Section 3.2.2 of this document. 2316 * Therefore, the Association Type is a 16-bit unsigned integer. 2317 * The length and content of Association Value depends on the 2318 value of Association Type. 2319 * All bytes are stored in network byte order and the rules in 2320 Section 3.2.2 MUST be followed. 2322 o A Requesting PTP Identity record MUST contain at least one 2323 association tuple (type + value). 2324 o This record can contain several association tuples in any order. 2325 o It MUST NOT contain more than one association tuple of the same 2326 type. 2328 o In a PTP Key Request message, this record MUST be contained 2329 exactly once in the unicast mode, which depends on the content of 2330 the Association Mode record of this message. 2331 o In this case the Requesting PTP Identity record MUST contain 2332 exactly one association tuple. 2333 o This association tuple MUST contain one identification feature of 2334 the PTP requestor (IPv4, IPv6, 802.3 or PortIdentity). 2335 o The association tuple MUST NOT contain the Group association type 2336 0. 2338 o In a PTP Key Grant message, this record MUST be contained exactly 2339 once in the encrypted Ticket Container. 2340 o This record MUST contain exactly one association tuple. 2341 o The record body MUST be identical to the Requesting PTP Identity 2342 record of the related PTP Key Request message. 2343 o Therefore, the association tuple MUST NOT contain the Group 2344 association type 0. 2346 o In a PTP Registration Request message, this record MUST be 2347 included exactly once. 2349 o The grantor SHOULD add the following association tuples as far as 2350 they are available: IPv4, IPv6, 802.3 and PortIdentity. 2351 o The grantor MUST NOT include the Group association type 0. 2353 o This allows a requester to be assigned to a grantor, regardless of 2354 whether the requester specifies IPv4, IPv6, 802.3 or the 2355 PortIdentity of the grantor in its PTP Key Request message. 2357 3.2.14. Security Association 2359 This record contains the information "how" specific PTP message types 2360 must be secured. It comprises all dynamic (negotiable) values 2361 necessary to construct the AUTHENTICATION TLV (IEEE Std 1588-2019, 2362 16.14.3). Static values and flags, such as the secParamIndicator, 2363 are described in more detail in Section 5. 2365 Content and conditions: 2367 o The record has a Record Type number of 1033 and the Critical Bit 2368 MAY be set. 2369 o The record body is a sequence of various parameters in network 2370 byte order and MUST be formatted according to the following table: 2372 +----------------------------+--------+--------+ 2373 | Field | Octets | Offset | 2374 +----------------------------+--------+--------+ 2375 | Security Parameter Pointer | 1 | 0 | 2376 | Integrity Algorithm Type | 2 | 1 | 2377 | Key ID | 4 | 3 | 2378 | Key Length | 2 | 7 | 2379 | Key | K | 9 | 2380 +----------------------------+--------+--------+ 2382 Table 22: Security Association record 2384 o In a PTP Key Grant message, the Security Association record MUST 2385 be included at least once in the Current Parameters Container 2386 record and the Next Parameters Container record. 2387 o In unicast mode, the Security Association record MUST be included 2388 at least once in the encrypted Ticket Container as well. 2389 o The Next Parameters Container record MUST be present only during 2390 the update period. 2391 o The Ticket record MUST be present in unicast mode and MUST NOT be 2392 present in multicast mode. 2393 o The number of Security Association records in the respective 2394 container or Ticket Container depends on the content of the 2395 associated Security Policies (see also Section 3.2.15). 2397 Security Parameter Pointer 2399 o The Security Parameter Pointer (SPP) is an 8-bit unsigned integer 2400 in the closed range 0 to 255. 2401 o This value enables the mutual assignment of SA, SP and 2402 AUTHENTICATION TLVs. 2403 o The generation and management of the SPP is controlled by the KE 2404 server (see Section 3.3.2). 2406 Integrity Algorithm Type 2408 o This value is a 16-bit unsigned integer in network byte order. 2409 o The possible values are equivalent to the MAC Algorithm Types from 2410 the table in Section 3.2.8. 2411 o The value used depends on the negotiated or predefined MAC 2412 algorithm. 2414 Key ID 2416 o The Key ID is a 32-bit unsigned integer in network byte order. 2417 o The field length is oriented towards the structure of the 2418 AUTHENTICATION TLV. 2419 o The generation and management of the Key ID is controlled by the 2420 KE server. 2421 o The NTS-KE server MUST ensure that every Key ID is unique. 2423 * The value can be either a random number or an enumeration. 2424 * Previous Key IDs SHOULD NOT be reused for a certain number of 2425 rotation periods or a defined period of time (see Section 3.3). 2427 Key Length 2429 o This value is a 16-bit unsigned integer in network byte order, 2430 denoting the length of the key. 2432 Key 2434 o The value is a sequence of octets with a length of Key Length. 2435 o This symmetric key is needed together with the MAC algorithm to 2436 calculate the ICV. 2437 o It can be both a group key (multicast mode) or a unicast key 2438 (unicast mode). 2440 3.2.15. Security Policies 2442 This record contains the information "which" PTP message types must 2443 be secured. 2445 Content and conditions: 2447 o The record has a Record Type number of 1034 and the Critical Bit 2448 MAY be set. 2449 o The record body contains a sequence of tuples in network byte 2450 order: 2452 *Record body = {Security Policies = {tuple 1 || tuple 2 || tuple 2453 3 || tuple n}}* 2455 o Each tuple has a length of 2 octets and consists of a sequence of 2456 a PTP Message Type and a Security Parameter Pointer. 2458 +-----------------------------+--------+--------+ 2459 | Field | Octets | Offset | 2460 +-----------------------------+--------+--------+ 2461 | PTP Message Type | 1 | 0 | 2462 | Security Parameter pointers | 1 | 1 | 2463 +-----------------------------+--------+--------+ 2465 Table 23: Security Policy tuple 2467 o The PTP Message Type is an 8-bit unsigned integer. 2468 o The most significant 4 bits are zero-padded and the least 2469 significant 4 bits are the PTP message type: 2471 Structure of PTP Message Type (see also [IEEE1588-2019], 13.3.2.3, 2472 table 36): 2474 +--------------+------------------+ 2475 | Bits 7 - 4 | Bits 3 - 0 | 2476 +--------------+------------------+ 2477 | Zero Padding | PTP Message type | 2478 +--------------+------------------+ 2480 Table 24: PTP Message Type 2482 o The Security Parameter Pointer (SPP) is an 8-bit unsigned integer 2483 in the closed range 0 to 255. 2485 o The record body MUST contain at least one tuple. 2486 o A tuple associates a PTP message type with an SPP. 2487 o Every PTP message type that is mentioned in the Security Policies 2488 record MUST be secured. 2489 o Thus, a PTP message type that is not included in this record MUST 2490 NOT contain an AUTHENTICATION TLV and will not be secured. 2491 o Multiple tuples with the same PTP message type MUST NOT be 2492 included. 2494 o Multiple tuples MAY use the same SPP to use a shared security 2495 association or an individual one. 2497 o For the number of contained and different SPPs in the Security 2498 Policies record, the same number of security associations MUST be 2499 created. 2500 o The number of security associations determines the number of 2501 Security Associations records in the respective container record 2502 (e.g. Current Parameters Container). 2504 o In a PTP Key Grant message, this record MUST be included exactly 2505 once each in the Current Parameters Container record, the Next 2506 Parameters Container record as well as the encrypted Ticket 2507 Container record. 2508 o The Next Parameters Container record MUST be present only during 2509 the update period. 2510 o The Ticket record MUST be present in unicast mode and MUST NOT be 2511 present in multicast mode. 2513 3.2.16. Ticket 2515 This record contains the parameters of the selected AEAD algorithm, 2516 as well as an encrypted Ticket Container record. The encrypted 2517 record contains all the necessary security parameters that the 2518 grantor needs for a secured PTP unicast connection to the requester. 2519 The ticket container is encrypted by the NTS-KE server with the 2520 symmetric ticket key which is also known to the grantor. The 2521 requester is not able to decrypt the ticket container. 2523 Content and conditions: 2525 o The record has a Record Type number of 1035 and the Critical Bit 2526 MAY be set. 2527 o The record body consists of several data fields and MUST be 2528 formatted as follows. 2530 +-----------------------------------+--------+--------+ 2531 | Field | Octets | Offset | 2532 +-----------------------------------+--------+--------+ 2533 | Nonce Length | 2 | 0 | 2534 | Nonce | N | 2 | 2535 | Encrypted Ticket Container Length | 2 | N+2 | 2536 | Encrypted Ticket Container | C | N+4 | 2537 +-----------------------------------+--------+--------+ 2539 Table 25: Structure of a Ticket record 2541 o In a PTP Key Grant message, this record MUST be included exactly 2542 once each in the Current Parameters Container record and the Next 2543 Parameters Container record if the requester wants a unicast 2544 communication to a specific grantor. 2545 o The Next Parameters Container record MUST be present only during 2546 the update period. 2548 Nonce Length 2550 o This is a 16-bit unsigned integer in network byte order, denoting 2551 the length of the Nonce field. 2553 Nonce 2555 o This field contains the Nonce needed for the AEAD operation. 2556 o The length and conditions attached to the Nonce depend on the AEAD 2557 algorithm used. 2558 o More details and conditions are described in Section 3.3.1. 2560 Encrypted Ticket Container Length 2562 o This is a 16-bit unsigned integer in network byte order, denoting 2563 the length of the Encrypted Ticket Container field. 2565 Encrypted Ticket Container 2567 o This field contains the output of the AEAD operation 2568 ("Ciphertext") after the encryption process of the respective 2569 Ticket Container record. 2570 o The plaintext of this field is described in Section 3.2.17. 2571 o More details about the AEAD process and the required input data 2572 are described in Section 3.3.1. 2574 3.2.17. Ticket Container 2576 This record is a simple container that can carry an arbitrary number 2577 of NTS records. It contains all relevant security parameters that a 2578 grantor needs for a secured unicast connection. The order of the 2579 included records is arbitrary and the parsing rules are so far 2580 identical with the NTS message. One exception: An End of Message 2581 record SHOULD NOT be present and MUST be ignored. When the parser 2582 reaches the end of the Record Body quantified by the Body Length, all 2583 embedded records have been processed. The Ticket Container record 2584 serves as input parameter for the AEAD operation (see Section 3.2.1) 2585 and is transmitted encrypted within the Ticket record (see 2586 Section 3.2.16). 2588 Content and conditions: 2590 o The record has a Record Type number of 1036 and the Critical Bit 2591 MAY be set. 2592 o The record body is defined as a set of records and MAY contain the 2593 following records. 2595 +-------------------------+----------------+------------------------+ 2596 | NTS Record Name | Use | Reference | 2597 +-------------------------+----------------+------------------------+ 2598 | Requesting PTP Identity | mand. | This document, | 2599 | | | Section 3.2.13 | 2600 | Security Policies | mand. | This document, | 2601 | | | Section 3.2.15 | 2602 | Security Association | mand. | This document, | 2603 | (one or more) | | Section 3.2.14 | 2604 | Lifetime | mand. | This document, | 2605 | | | Section 3.2.7 | 2606 | Time until Update | mand. | This document, | 2607 | | | Section 3.2.20 | 2608 | Grace Period | opt. | This document, | 2609 | | (conditional) | Section 3.2.6 | 2610 +-------------------------+----------------+------------------------+ 2612 Table 26: Structure of a Ticket Container 2614 o The records Requesting PTP Identity, Security Policies, Lifetime 2615 and Time until Update MUST be contained exactly once. 2616 o The number of the Security Association records depends on the 2617 content of the Security Policies record (see Section 3.2.15). 2618 o All records within this Ticket Container (except Requesting PTP 2619 Identity) MUST be identical to the records of the respective 2620 Current Parameter Container. 2621 o All records within this Ticket Container (except Requesting PTP 2622 Identity) MUST be identical to the records of the respective Next 2623 Parameter Container. 2624 o The presence of the Grace Period record also depends on the 2625 respective Current/Next Parameter container. 2626 o If a Grace Period record is present in the Current/Next Parameter 2627 container, it MUST also be present in the respective Ticket 2628 Container. 2629 o If it is not present, it MUST NOT be included in the Ticket 2630 Container. 2632 3.2.18. Ticket Key 2634 This record contains the ticket key, which together with an AEAD 2635 algorithm is used to encrypt and decrypt the ticket. 2637 Content and conditions: 2639 o The record has a Record Type number of 1037 and the Critical Bit 2640 MAY be set. 2641 o The record body consists of a sequence of octets holding the 2642 symmetric key for the AEAD function. 2643 o The generation and length of the key MUST meet the requirement of 2644 the associated AEAD algorithm. 2646 o In a PTP Registration Success message, this record MUST be 2647 included exactly once each in the Current Parameters Container 2648 record and the Next Parameters Container record. 2649 o The Next Parameters Container record MUST be present only during 2650 the update period. 2652 3.2.19. Ticket Key ID 2654 The Ticket Key ID record is a unique identifier that allows a grantor 2655 to identify the associated ticket key. 2657 Content and conditions: 2659 o The record has a Record Type number of 1038 and the Critical Bit 2660 MAY be set. 2661 o The record body consists of a 32-bit unsigned integer in network 2662 byte order. 2663 o The generation and management of the ticket key ID is controlled 2664 by the NTS-KE server. 2665 o The NTS-KE server must ensure that every ticket key has a unique 2666 number. 2668 * The value is implementation dependent and MAY be either a 2669 random number, a hash value or an enumeration. 2670 * Previous IDs SHOULD NOT be reused for a certain number of 2671 rotation periods or a defined period of time. 2672 o In a PTP Key Grant message, this record MUST be included exactly 2673 once each in the Current Parameters Container record and the Next 2674 Parameters Container record if a unicast connection is to be 2675 established. 2676 o If the requester wishes to join a multicast group, the Ticket Key 2677 ID record MUST NOT be included in the container records. 2678 o In a PTP Registration Success message, this record MUST be 2679 included exactly once in the Current Parameters Container record 2680 and once in the Next Parameters Container record. 2681 o The Next Parameters Container record MUST be present only during 2682 the update period. 2683 o The Ticket record MUST be present in unicast mode and MUST NOT be 2684 present in multicast mode. 2686 3.2.20. Time until Update 2688 The Time until Update (TuU) record specifies the point in time at 2689 which new security parameters are available. The value contained in 2690 this record is counted down by the receiver of the NTS message every 2691 second. When the value reaches zero, the update period begins and 2692 NTS response messages typically contain the Next Parameter Container 2693 record for a certain period of time (see also Section 2.2.1). 2695 Content and conditions: 2697 o The record has a Record Type number of 1039 and the Critical Bit 2698 MAY be set. 2699 o The record body consists of a 32-bit unsigned integer in network 2700 byte order, denoting the begin of the update period in seconds. 2702 o The value in the TuU MUST be less than the value in the associated 2703 Lifetime record (in the same container or ticket). 2704 o If the value in the TuU is greater than zero in the Current 2705 Parameter Container, the corresponding message MUST NOT contain a 2706 Next Parameters Container. 2707 o If the value in the TuU is zero in the Current Parameters 2708 Container, the corresponding NTS message MAY contain the Next 2709 Parameters Container record. 2711 o The Time until Update record MAY only appear as part of a PTP Key 2712 Grant or PTP Registration Success message. 2713 o In both messages, the Next Parameters Container MUST be present 2714 only during the update period. 2715 o In a PTP Key Grant message, the Time until Update record MUST be 2716 included exactly once each in the Current Parameters Container and 2717 Next Parameters Container records, as well as in the encrypted 2718 Ticket Container (only present in a unicast PTP Key Grant 2719 message). 2720 o In a PTP Registration Success message, the Time until Update MUST 2721 be included exactly once each in the Current Parameters Container 2722 and Next Parameters Container records. 2723 o In both messages, the Next Parameters Container record MUST be 2724 present only during the update period. 2726 Notes: 2728 o Requests during the currently running lifetime will receive 2729 respectively adapted count values for Time until Update. 2730 o During the update period the value for TuU in the Current 2731 Parameters Container will be zero. 2733 3.3. Additional Mechanisms 2735 This section provides information about the use of the negotiated 2736 AEAD algorithm as well as the generation of the security policy 2737 pointers. 2739 3.3.1. AEAD Operation 2741 General information about AEAD: 2743 o The AEAD operation enables the integrity protection and the 2744 optional encryption of the given data, depending on the input 2745 parameters. 2746 o While the structure of the AEAD output after the securing 2747 operation is determined by the negotiated AEAD algorithm, it 2748 usually contains an authentication tag in addition to the actual 2749 ciphertext. 2750 o The authentication tag provides the integrity protection, whereas 2751 the ciphertext represents the encrypted data. 2752 o The AEAD algorithms supported in this document (see Section 3.2.1) 2753 always return an authentication tag with a fixed length of 16 2754 octets. 2755 o The size of the following ciphertext is equal to the length of the 2756 plaintext. 2757 o The concatenation of authentication tag and ciphertext always form 2758 the unit "Ciphertext": 2760 *Ciphertext = {authentication tag || ciphertext}* 2762 o Hint: The term "Ciphertext" is distinguished between upper and 2763 lower case letters. 2764 o The following text always describes "Ciphertext". 2765 o Separation of the information concatenated in Ciphertext is not 2766 necessary at any time. 2768 o Six parameters are relevant for the execution of an AEAD 2769 operation: 2771 * AEAD (...): is the AEAD algorithm itself 2772 * A: Associated Data 2773 * N: Nonce 2774 * K: Key 2775 * P: Plaintext 2776 * C: Ciphertext 2777 o The protection and encryption of the data is done as follows: C = 2778 AEAD (A, N, K, P) 2779 o Therefore, the output of the AEAD function is the Ciphertext. 2781 o The verification and decryption of the data is done this way: P = 2782 AEAD (A, N, K, C) 2783 o The output of the AEAD function is the Plaintext if the integrity 2784 verification is successful. 2786 AEAD algorithm and input/output values for the Ticket record: 2788 o AEAD (...): 2790 * The AEAD algorithm that is negotiated between grantor and NTS- 2791 KE server during the registration phase. 2792 * A list of the AEAD algorithms considered in this document can 2793 be found in Section 3.2.1. 2794 o Associated Data: 2796 * The Associated Data is an optional AEAD parameter and can be of 2797 any length and content, as long as the AEAD algorithm does not 2798 give any further restrictions. 2799 * In addition to the Plaintext, this associated data is also 2800 included in the integrity protection. 2801 * When encrypting or decrypting the Ticket Container record, this 2802 parameter MUST remain empty. 2803 o Nonce: 2805 * Corresponds to the value from the Nonce field in the Ticket 2806 (Section 3.2.16). 2807 * The requirements and conditions depend on the selected AEAD 2808 algorithm. 2809 * For the AEAD algorithms defined in Section 3.2.1 (with numeric 2810 identifiers 15, 16, 17), a cryptographically secure random 2811 number MUST be used. 2812 * Due to the block length of the internal AES algorithm, the 2813 Nonce SHOULD have a length of 16 octets. 2814 o Key: 2816 * This is the symmetric key required by the AEAD algorithm. 2817 * The key length depends on the selected algorithm. 2818 * When encrypting or decrypting the Ticket Container record, the 2819 ticket key MUST be used. 2820 o Plaintext: 2822 * This parameter contains the data to be encrypted and secured. 2823 * For AEAD encryption, this corresponds to the Ticket Container 2824 record with all records inside. 2825 * This is also the output of the AEAD operation after the 2826 decryption process. 2827 o Ciphertext: 2829 * Corresponds to the value from the Encrypted Ticket Container 2830 field in the Ticket (Section 3.2.16). 2831 * The Ciphertext is the output of the AEAD operation after the 2832 encryption process. 2833 * This is also the input parameter for the AEAD decryption 2834 operation. 2836 3.3.2. SA/SP Management 2838 This section describes the requirements and recommendations attached 2839 to SA/SP management, as well as details about the generation of 2840 identifiers. 2842 Requirements for the Security Association Database management: 2844 o The structure and management of the Security Association Database 2845 (SAD) are implementation-dependent both on the NTS-KE server and 2846 on the PTP devices. 2847 o An example of this, as well as other recommendations, are 2848 described in Annex B. 2849 o A PTP device MUST contain exactly one SAD and Security Policy 2850 Database (SPD). 2851 o For multicast and Group-of-2 connections, SPPs MUST NOT occur more 2852 than once in the SAD of a PTP device. 2853 o For unicast connections, SPPs MAY occur more than once in the SAD 2854 of a PTP device. 2855 o The NTS-KE server MUST ensure that SPPs can be uniquely assigned 2856 to a multicast group or unicast connection. 2857 o This concerns both the NTS-KE server and all PTP devices assigned 2858 to the NTS-KE server. 2860 SPP generation: 2862 The generation of the SPP always takes place on the NTS-KE server 2863 and enables the identification of a corresponding SA. The value 2864 of the SPP can be either a random number or an enumeration. An 2865 SPP used in any multicast group MUST NOT occur in any other 2866 multicast group or unicast connection. If a multicast group or 2867 unicast connection is removed by the NTS-KE server, the released 2868 SPPs MAY be reused for new groups or unicast connections. Before 2869 reusing an SPP, the NTS-KE server MUST ensure that the SPP is no 2870 longer in use in the PTP network (e.g. within Next Parameter). 2871 In different PTP devices, an SPP used in a unicast connection MAY 2872 also occur in another unicast connection, as long as they are not 2873 used in multicast groups. 2875 Key/Key ID generation: 2877 The generation of the keys MUST be performed by using a 2878 Cryptographically Secure Pseudorandom Number Generator (CSPRNG) on 2879 the NTS-KE server (see also Section 2.2.2). The length of the 2880 keys depends on the MAC algorithm used. The generation and 2881 management of the Key ID is also controlled by the KE server. The 2882 NTS-KE server MUST ensure that every Key ID is unique at least 2883 within an SA with multiple parameter sets. The value of the Key 2884 ID is implementation dependent and MAY be either a random number, 2885 a hash value or an enumeration. Key IDs of expired keys MAY be 2886 reused but SHOULD NOT be reused for a certain number of rotation 2887 periods or a defined period of time. Before reusing a Key ID, the 2888 NTS-KE server MUST be ensured that the Key ID is no longer in use 2889 in the PTP network (e.g. within Next Parameter). 2891 4. New TICKET TLV for PTP Messages 2893 Once a PTP port is registered as a grantor for association in unicast 2894 mode another PTP port (requester) can associate with it by first 2895 requesting a key from the KE server with Association Type in the 2896 Association Mode record set to one of the values 1 to 4 (IPv4, IPv6, 2897 802.3 or PortIdentity), and Association Values to the related address 2898 of the registered port. With the reception of the key grant the 2899 requester obtains the unicast key and the Ticket record containing 2900 the encrypted ticket container (see Section 2.1.2 and 2901 Section 3.2.16). The ticket container (see Section 3.2.17) includes 2902 the identification of the requester, the SAs along with the unicast 2903 key as well as the Lifetime/Time until Update data. 2905 To provide the grantor with the security data, the requester sends a 2906 secured unicast request to the grantor, e.g. an Announce request (= 2907 Signaling message with a REQUEST_UNICAST_TRANSMISSION TLV with 2908 Announce as messageType in the TLV), which is secured with the 2909 unicast key. 2911 To accomplish that, the requester sends a newly defined TICKET TLV 2912 with the Ticket container embedded and the AUTHENTICATION TLV with 2913 the PTP unicast negotiation message. The TICKET TLV must be 2914 positioned before the AUTHENTICATION TLV to include the TICKET TLV in 2915 the securing by the ICV. The receiving grantor decrypts the Ticket 2916 container from the TICKET TLV getting access to the information 2917 therein. With the contained unicast key, the grantor checks the 2918 requester identity and the authenticity of the request message. 2920 Thereafter all secured unicast messages between grantor and requester 2921 will use the unicast key for generating the ICV in the AUTHENTICATION 2922 TLV for authentication of the message until the unicast key expires. 2924 If the requester's identity does not match with the Requesting PTP 2925 Identity record in the Ticket Container and/or the ICV in the 2926 AUTHENTICATION TLV is not identical to the generated ICV by the 2927 grantor, then the unicast request message shall be denied. 2929 The TICKET TLV structure is given in Table 27 below. 2931 +---------------+--------+--------+ 2932 | Field | Octets | Offset | 2933 +---------------+--------+--------+ 2934 | tlvType | 2 | 0 | 2935 | lengthField | 2 | 2 | 2936 | Ticket record | T | 4 | 2937 +---------------+--------+--------+ 2939 Table 27: Structure of the TICKET TLV 2941 To comply with the TLV structure of IEEE Std 1588-2019 2942 ([IEEE1588-2019], 14.1) the TICKET TLV is structured as presented in 2943 Table 27 with a newly defined tlvType, a respective length field and 2944 the Ticket record (see Section 3.2.16) containing the encrypted 2945 Ticket container. Eventually it may be necessary to define the 2946 Ticket TLV externally to IEEE 1588 SA. Then the structure should 2947 follow IEEE Std 1588-2019 ([IEEE1588-2019], 14.3) to define a new 2948 standard organization extension TLV as presented in Table 28 below. 2950 +---------------------+--------+--------+ 2951 | Field | Octets | Offset | 2952 +---------------------+--------+--------+ 2953 | tlvType | 2 | 0 | 2954 | lengthField | 2 | 2 | 2955 | organizationId | 3 | 4 | 2956 | organizationSubType | 3 | 7 | 2957 | Ticket record | T | 10 | 2958 +---------------------+--------+--------+ 2960 Table 28: Structure of an organization extension TLV form for the 2961 TICKET TLV 2963 To transport the TICKET TLV with the Ticket container embedded via 2964 the PTP unicast negotiation message two possible solutions exist: 2966 a. The TICKET TLV can be added to the PTP message preceding the 2967 AUTHENTICATION TLV as shown in Figure 48 of IEEE Std 1588-2019 2968 ([IEEE1588-2019], 16.14.1.1). For this solution, a completely 2969 new TICKET TLV for IEEE Std 1588-2019 needs to be defined. 2970 b. In an alternative solution the TICKET TLV is send embedded in the 2971 RES field of the AUTHENTICATION TLV as shown in Figure 49 of IEEE 2972 Std 1588-2019 ([IEEE1588-2019], 16.14.3). In this case the RP 2973 flag in the secParamIndicator must be set. As at the moment the 2974 use of the RES field is not permitted and the structure of the 2975 RES field is limited to UInteger (see [IEEE1588-2019], 16.14.3.8 2976 ) the new usage needs to be defined: 2978 _"16.14.3.8 RES (UInteger R): This field is optional. If 2979 present, it shall have a data type of UInteger with a length of R 2980 octets. For this edition, the value of RP in the 2981 secParamIndicator field shall be FALSE and the value of RP shall 2982 be 0."_ 2984 Which solution is chosen is a political question, not a technical one 2985 and needs to be discussed in the IEEE 1588 SA. The same applies to 2986 the format of the TICKET TLV (standard TLV or organization extension 2987 TLV). 2989 5. AUTHENTICATION TLV Parameters 2991 The AUTHENTICATION TLV is the heart of the integrated security 2992 mechanism (Prong A) for PTP. It provides all necessary data for the 2993 processing of the security means. The structure is shown in Table 29 2994 below (compare to Figure 49 of [IEEE1588-2019]). 2996 +-------------------+-------+---------------------------------------+ 2997 | Field | Use | Description | 2998 +-------------------+-------+---------------------------------------+ 2999 | tlvType | mand. | TLV Type | 3000 | lengthField | mand. | TLV Length Information | 3001 | SPP | mand. | Security Parameter Pointer | 3002 | secParamIndicator | mand. | Security Parameter Indicator | 3003 | keyID | mand. | Key Identifier or Current Key | 3004 | | | Disclosure Interval, depending on | 3005 | | | verification scheme | 3006 | disclosedKey | opt. | Disclosed key from previous interval | 3007 | sequenceNo | opt. | Sequence number | 3008 | RES | opt. | Reserved | 3009 | ICV | mand. | ICV based on algorithm OID | 3010 +-------------------+-------+---------------------------------------+ 3012 Table 29: Structure of the AUTHENTICATION TLV 3014 The tlvType is AUTHENTICATION and lengthField gives the length of the 3015 TLV. When using the AUTHENTICATION TLV with NTS key management, the 3016 SPP and keyID will be provided by the KE server in the PTP Key Grant 3017 Message 3018 The optional disclosedKey, sequenceNo, and RES (see discussion in 3019 chapter 3) fields are omitted. So all of the flags in the 3020 SecParamIndicator are FALSE. 3022 ICV field contains the integrity check value of the particular PTP 3023 message calculated using the integrity algorithm defined by the key 3024 management. 3026 6. IANA Considerations 3028 Considerations should be made ... 3030 ... 3032 7. Security Considerations 3034 ... 3036 8. Acknowledgements 3038 The authors would like to thank ... 3040 9. References 3042 9.1. Normative References 3044 [FIPS-PUB-198-1] 3045 National Institute of Standards and Technology (NIST), 3046 "The Keyed-Hash Message Authentication Code (HMAC)", 3047 NIST FIPS PUB 198-1, 2008. 3049 [IEEE1588-2019] 3050 Institute of Electrical and Electronics Engineers - IEEE 3051 Standards Association, "IEEE Standard for a Precision 3052 Clock Synchronization Protocol for Networked Measurement 3053 and Control Systems", IEEE Standard 1588-2019, 2019. 3055 [ITU-T_X.509] 3056 International Telecommunication Union (ITU), "Information 3057 technology - Open systems interconnection - The Directory: 3058 Public-key and attribute certificate frameworks", ITU-T 3059 Recommendation X.509 (2008), November 2008. 3061 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3062 Requirement Levels", BCP 14, RFC 2119, 3063 DOI 10.17487/RFC2119, March 1997, 3064 . 3066 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 3067 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 3068 2006, . 3070 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 3071 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 3072 DOI 10.17487/RFC4543, May 2006, 3073 . 3075 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 3076 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 3077 . 3079 [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) 3080 Authenticated Encryption Using the Advanced Encryption 3081 Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 3082 2008, . 3084 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 3085 "Transport Layer Security (TLS) Application-Layer Protocol 3086 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 3087 July 2014, . 3089 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 3090 "Recommendations for Secure Use of Transport Layer 3091 Security (TLS) and Datagram Transport Layer Security 3092 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 3093 2015, . 3095 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3096 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3097 May 2017, . 3099 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3100 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3101 . 3103 [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 3104 Sundblad, "Network Time Security for the Network Time 3105 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 3106 . 3108 9.2. Informative References 3110 [Langer_et_al._2020] 3111 Langer, M., Heine, K., Sibold, D., and R. Bermbach, "A 3112 Network Time Security Based Automatic Key Management for 3113 PTPv2.1", 2020 IEEE 45th Conference on Local Computer 3114 Networks (LCN), Sydney, Australia, 3115 DOI 10.1109/LCN48667.2020.9314809, November 2020, 3116 . 3118 Authors' Addresses 3120 Martin Langer 3121 Ostfalia University of Applied Sciences 3122 Salzdahlumer Strasse 46/48 3123 Wolfenbuettel 38302 3124 Germany 3126 Email: mart.langer@ostfalia.de 3128 Rainer Bermbach 3129 Ostfalia University of Applied Sciences 3130 Salzdahlumer Strasse 46/48 3131 Wolfenbuettel 38302 3132 Germany 3134 Email: r.bermbach@ostfalia.de