idnits 2.17.1 draft-gerstung-nts4uptp-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (4 June 2021) is 1050 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NTP WG H. Gerstung 3 Internet-Draft M. Rohde 4 Intended status: Standards Track D. Arnold 5 Expires: 6 December 2021 Meinberg 6 4 June 2021 8 Network Time Security for the Unicast Mode of the Precision Time 9 Protocol 10 draft-gerstung-nts4uptp-03 12 Abstract 14 This memo specifies the application of Network Time Security, a 15 mechanism for using Transport Layer Security (TLS) and Authenticated 16 Encryption with Associated Data (AEAD) to provide cryptographic 17 security for the unicast mode of the Precision Time Protocol. 19 It is based on the 'Network Time Security for the Network Time 20 Protocol' document RFC8915 and re-uses most of its mechanisms for 21 providing a secure and robust key exchange solution for unicast PTP. 22 Due to the different modes of operation, additional steps are 23 required to secure unicast PTP communication between the PTP clients 24 and unicast PTP servers. In addition to defining the new record 25 types and other required values to allow the utilization of the NTS 26 key exchange sub protocol, there are a number of additional protocol 27 enhancements and server-side requirements which are defined in this 28 memo. 30 NOTE 32 This document is work in progress 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 6 December 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Application of the NTS protocol to PTP . . . . . . . . . . . 4 70 3.1. Phase 1: NTS-KE Phase . . . . . . . . . . . . . . . . . . 7 71 3.2. Phase 2: PTP Unicast Transmission Negotiation Phase . . . 7 72 3.3. Phase 3: PTP Unicast Packet Transmission Phase . . . . . 12 73 4. New NTS record types . . . . . . . . . . . . . . . . . . . . 13 74 4.1. Cookie for Unicast PTP . . . . . . . . . . . . . . . . . 13 75 4.2. Unicast PTP Server Negotiation . . . . . . . . . . . . . 13 76 5. The PTP client Table . . . . . . . . . . . . . . . . . . . . 14 77 6. The NTS_TLV . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 8.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 17 81 8.2. General Security Features . . . . . . . . . . . . . . . . 18 82 9. Delay Attacks . . . . . . . . . . . . . . . . . . . . . . . . 19 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 86 11.2. Informative References . . . . . . . . . . . . . . . . . 20 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 89 1. Introduction 91 This memo specifies Network Time Security for unicast mode of the 92 Precision Time Protocol (PTP). It is based on [RFC8915] and applies 93 the key exchange mechanism described there to PTP. The Precision 94 Time Protocol is standardized in [IEEE1588] and offers a number of 95 different modes and mappings to communication protocols. The 96 security mechanisms described here provide a way to secure the 97 unicast mode of PTP as specified in sub clause 16.1 of [IEEE1588]. 99 The PTP integrated security mechanism has been specified in sub 100 clause 16.14 of [IEEE1588] and introduces an AUTHENTICATION TLV that 101 carries all necessary information to enable the receiver of a PTP 102 message to verify its integrity. Although two different approaches 103 are described in that sub clause (immediate and delayed security 104 processing), NTS4UPTP only uses the immediate security processing. 106 In addition to sub clause 16.14, Annex P of [IEEE1588] provides 107 additional explanation and description of PTP security. It is stated 108 there that for key management it is assumed that a separate mechanism 109 outside the context of PTP is used. In P.2.1.2 the document clearly 110 states that this assumption was made in relation to the security 111 mechanism described in 16.14 and it goes on to discuss some Key 112 management options and it names both manual and automatic key 113 management as possible approaches. 115 This memo describes a way to use the automatic key exchange mechanism 116 as defined in [RFC8915] as the key management for unicast PTP. The 117 NTS-KE protocol has clearly been designed to support using it for 118 multiple time synchronization protocols and this document is 119 utilizing this support. 121 1.1. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 2. Objectives 129 The objectives of NTS are defined in [RFC8915] and, with some 130 exceptions, apply to NTS4UPTP as well. 132 * Identity: Through the use of a X.509 public key infrastructure, 133 implementations can cryptographically establish the identity of 134 the parties they are communicating with. 136 * Authentication: Implementations can cryptographically verify that 137 any time synchronization packets are authentic, i.e., that they 138 were produced by an identified party and have not been modified in 139 transit. 141 * Replay prevention: clients and servers can detect when a received 142 packet is a replay of a previous packet. 144 * Request-response consistency: clients can verify that a unicast 145 PTP packet received from a server was sent in response to a 146 particular request from the client. 148 * Non-amplification: Implementations (especially server 149 implementations) can avoid acting as distributed denial-of-service 150 (DDoS) amplifiers by never responding to a packet with one or more 151 packets creating more traffic than the initiating packet. 153 * Scalability: Server implementations can serve large numbers of 154 clients. 156 * Performance: NTS must not significantly degrade the quality of the 157 time transfer. The encryption and authentication used when 158 actually transferring time should be lightweight. 160 The following objectives of [RFC8915] are not met in this proposal: 162 * Confidentiality: Basic time synchronization data is considered 163 nonconfidential and sent in the clear. Despite this, NTS4NTP 164 includes support for encrypting NTP extension fields. NTS4UPTP 165 does not offer this kind of support as it is not considered useful 166 or required for unicast PTP implementations. 168 * Unlinkability: For mobile clients, NTS4NTP does not leak any 169 information additional to NTP which would permit a passive 170 adversary to determine that two packets sent over different 171 networks came from the same client. This objection cannot be 172 achieved by unicast PTP because the protocol requires the server 173 to keep a state for all its clients. It is also not considered a 174 requirement in most applications where unicast PTP is deployed. 176 3. Application of the NTS protocol to PTP 178 Unlike NTP [RFC5905] which uses a request-response communication 179 approach, the unicast mode of PTP is applying a subscription based 180 model. Although [IEEE1588] allows unicast operation without 181 negotiation this is rarely used. For this reason only unicast PTP 182 with negotiation is considered. A PTP client (PTP Ordinary Clock, or 183 synchronizing port of a PTP unicast Boundary Clock) sends a request 184 for the transmission of packets to a PTP instance offering such a 185 service. This could be a PTP unicast Grandmaster instance or a PTP 186 boundary clock. Note that [IEEE1588] allows PTP Ports in a states 187 other than master to accept unicast message grant requests and act as 188 a unicast PTP master. This option can be used for monitoring 189 purposes. In this memo we treat all unicast associations in the same 190 way regardless of whether it is for purposes of time transfer or 191 monitoring, and refer to the port that grants message contracts as a 192 PTP server. 194 A PTP server that receives a message grant request will then either 195 accept the request or deny it, for example based on capacity 196 considerations or its own operational state. This sub protocol of 197 IEEE 1588 is called unicast message negotiation, an optional feature 198 defined in sub clause 16.1 of [IEEE1588]. Both the PTP client and 199 the PTP server granting a request can cancel a subscription (referred 200 to as contract in PTP) after it has been granted and each contract 201 includes a duration after which the PTP instance stops sending 202 packets automatically if the PTP client did not request a new 203 contract before the old contract ended. 205 This results in a 3-phase approach for PTP: 207 * Phase 1: NTS-KE Phase (Section 3.1) 209 * Phase 2: PTP Unicast Transmission Negotiation Phase (Section 3.2) 211 * Phase 3: PTP Unicast Packet Transmission Phase (Section 3.3) 213 In a typical use-case, phase 1 is required to be performed at 214 startup. In phase 2 the PTP client and the PTP server will negotiate 215 the transmission of PTP messages which will then be delivered by the 216 PTP server in phase 3. Whenever phase 3 ends, the PTP client must 217 re-run phase 2 to re-request more packets. Typically, PTP clients 218 will re-run phase 2 before the active contract ends, i.e. they 219 request a new transmission contract from the PTP server with a new 220 duration before the active contract expires in order to secure a 221 continuous flow of messages from the PTP server. 223 NTS4UPTP Protocol Overview 224 +--------------+ 225 | | 226 +-> | PTP server 1 | 227 | | | 228 Shared cookie | +--------------+ 229 +---------------+ encryption parameters | +--------------+ 230 | | | | | 231 | NTS-KE Server | <-----------------------+-> | PTP server 2 | 232 | | | | | 233 +---------------+ | +--------------+ 234 ^ | . 235 | | . 236 | 1. Negotiate parameters, | . 237 | receive initial cookie, | +--------------+ 238 | generate AEAD keys, | | | 239 | and receive PTP server IP +-> | PTP server N | 240 | addresses using "NTS Key | | 241 | Establishment" protocol. +--------------+ 242 | ^ ^ 243 | | | 244 | | | 245 | 2. Perform authenticated | | 246 | unicast message negotiation | | 247 | using the MAC function of | | 248 | the AEAD to calculate the | | 249 | ICV in the | | 250 | AUTHENTICATION_TLV using | | 251 | the S2C/C2S keys | | 252 | | | 253 | +----------+ | | 254 | | PTP | | | 255 +-----------> | Client | <-------------------+ | 256 | | <----------------------+ 257 +----------+ 258 3. PTP server sends unicast messages 259 as negotiated with PTP client using 260 the MAC function of the AEAD to 261 calculate the ICV in the 262 AUTHENTICATION_TLV using the S2C key; 263 Client sends DELAY_REQ messages using the 264 C2S key for the ICV 266 Figure 1: Overview of High-Level Interactions in NTS4UPTP 268 Phase 1 only needs to be re-run to avoid that the key lifetime 269 expires, the PTP server stops responding or does not accept the 270 cookie presented by the PTP client for any reasons. 272 3.1. Phase 1: NTS-KE Phase 274 In the NTS-KE Phase (Phase 1), the PTP client connects to the NTS-KE 275 server via a secure TLS channel. Two keys are generated based on the 276 TLS data exchange, referred to as Server-to-Client key (S2C key) and 277 Client-to-Server key (C2S key). The NTS-KE server creates a cookie 278 for the PTP client, which contains those two keys, the AEAD algorithm 279 used and a Nonce. The cookie is secured by encrypting this 280 information with a master key K. The master key is generated by a 281 PTP server and sent to the KE server via a proprietary mechanism. 282 The client therefore cannot decrypt a cookie as it does not know the 283 master key. After receiving the cookies and establishing the C2S and 284 S2C keys, the TLS connection is closed. This is identical to the 285 NTS-KE phase as defined in [RFC8915] with the exception that the NTS- 286 KE record type "next-protocol" points to PTP instead of NTP and two 287 new NTS record types are introduced: 289 * "Cookie for Unicast PTP" provides the client with the cookie 290 required to establish a valid NTS connection with the PTP server. 291 This NTS record type is defined in Section 4.1. 293 * "PTP server Negotiation" tells the client which PTP server it MUST 294 use. This NTS record type is defined in Section 4.2. 296 The MAC function of the AEAD algorithm will be used to create/ 297 calculate the ICV in the AUTHENTICATION_TLV as defined in subclause 298 16.14 of [IEEE1588] (Integrated PTP Security). 300 For providing the cookie, an NTS-KE server MUST use a new NTS record 301 type (New Cookie for Unicast PTP), which is identical to the NTS 302 record type 5 (New Cookie for NTPv4) as described in [RFC8915]. 304 The S2C key will be used in Phase 2 and 3 to calculate the ICV of the 305 AUTHENTICATION_TLV for all PTP messages sent from the PTP server to 306 the PTP client. The C2S key will be used in Phase 2 and 3 to 307 calculate the ICV of the AUTHENTICATION_TLV for all PTP messages sent 308 from the PTP client to the PTP server. 310 After the PTP client successfully completed Phase 1, it can enter 311 Phase 2 by initiating the PTP unicast negotiation with the provided 312 PTP server. 314 3.2. Phase 2: PTP Unicast Transmission Negotiation Phase 316 A unicast PTP client needs to establish a contract with a PTP server 317 if it wants to receive SYNC and ANNOUNCE messages and to perform 318 delay measurements by sending DELAY_REQ messages to the PTP server, 319 which responds with DELAY_RESP messages. 321 The mechanism to establish these contracts between PTP client and PTP 322 server is described in subclause 16.1 of [IEEE1588] ("Unicast message 323 negotiation"). The basic concept requires the PTP client to send a 324 request for each specific message type to transmit that message at a 325 specific rate for a specific duration. The PTP server either grants 326 the request or rejects it (for example due to capacity constraints). 327 Each message type requires its own contract between a PTP client and 328 a PTP server and there can only be one active contract per message 329 type between the two nodes. 331 According to [IEEE1588] PTP messages can be extended by adding one or 332 more TLVs on the end of the PTP message, and [IEEE1588] defines a 333 number of TLVs. Here TLV stands for type-length-value. A standards 334 development organization can also define TLVs to support 335 specifications for extending PTP. In this case the TLV will be 336 "ORGANIZATION_EXTENSION_PROPAGATE" or 337 "ORGANIZATION_EXTENSION_DO_NOT_PROPAGATE" depending on whether a PTP 338 Boundary Clock shall pass the TLV on or not. This kind of TLV MUST 339 include a field for with the organizationID and a field with the 340 organizationSubType. The latter MUST be unique among PTP TLVs 341 defined by that organization. 343 The nature of unicast PTP requires that a PTP server maintains a list 344 of PTP clients with active contracts. For NTS4UPTP, a server needs 345 to store additional data. The storage entity required for storing 346 the additional data is referred to as the PTPCLTABLE (Section 5) in 347 this document. 349 In order to secure the PTP unicast transmission negotiation, PTP 350 clients and servers use cookies and nonces, and protect the integrity 351 of the PTP signaling messages with the integrated security mechanism 352 based on the AUTHENTICATION_TLV described in [IEEE1588]. A PTP 353 client initially requires a cookie for the first message it sends 354 during this phase and will receive a nonce each time the PTP server 355 sends a response. The initial cookie for the first request of the 356 client is provided by the NTS-KE server in the NTS-KE Phase. For 357 each consecutive message the PTP client sends, it MUST use the nonce 358 received in the previous message from the PTP server and send that 359 one back in the NONCE field of the NTS_TLV. 361 Due to the fact, that the S2C/C2S key pair expires, the client is 362 forced to get new keys from the NTS-KE server. The client MAY do 363 this at any time and MUST do it when receiving a NTS_INVALIDKEYS 364 response from the PTP server. 366 Nonces and cookies are not required in the third phase, in which the 367 transmitted PTP messages are only secured with the 368 AUTHENTICATION_TLV. Packet rates in this phase can be very high, PTP 369 for example allows for up to 128 SYNC packets per second sent by the 370 PTP server to a client. Due to the fact that PTP requires a client 371 to successfully complete the negotiation phase, it is sufficient to 372 protect the integrity of the messages in the transmission phase with 373 the AUTHENTICATION_TLV. 375 The unicast negotiation mechanism as specified in [IEEE1588] is 376 carried out according to the standard, but with the following 377 addition: 379 * The PTP client and the PTP server MUST add an NTS TLV and an 380 AUTHENTICATION_TLV to all signaling messages 382 * The NTS_TLV (Section 6) in a message sent from the PTP client to 383 the PTP server either carries the cookie that the client obtained 384 during the last successfully completed NTS-KE Phase, or the last 385 nonce provided by the PTP server in its response. Additionally 386 the ntsMsgId MUST be set to NTS_INIT for the first message sent to 387 the PTP server after completing the NTS-KE phase and to 388 NTS_REQUEST for all further messages. 390 * The AUTHENTICATION_TLV secures the 391 REQUEST_UNICAST_TRANSMISSION_TLV and the NTS_TLV with an ICV which 392 is calculated based on the MAC function of the AEAD algorithm and 393 the C2S key that has been obtained during the NTS-KE phase 395 * All signaling messages from the PTP server to the PTP client MUST 396 carry a new nonce and the ICV in the AUTHENTICATION_TLV is 397 calculated based on the S2C key that the PTP server read from the 398 decrypted cookie in the last NTS_INIT message from the client. 400 All PTP messages in the packet negotiation phase that do not carry an 401 AUTHENTICATION_TLV or in which the ICV is not correct MUST be ignored 402 by the recipient. 404 A PTPCLTABLE entry SHALL be stored at least for as long as the S2C/ 405 C2S key pair is valid, i.e. until KEY_PAIR_EXP has been reached. The 406 maximum lifetime of a key pair is defined in the configuration of the 407 PTP server and the expiration date/time is calculated when the entry 408 in this PTP client state storage is created (Expiration date/ 409 time=creation time of PTPCLTABLE record plus configured maximum 410 lifetime). The PTP server SHOULD erase entries from this table after 411 the expiration time of the key pair has been reached. 413 The PTP server, after receiving a signaling message, will perform the 414 following steps: 416 * if the request contains an NTS_TLV with ntsMsgId == NTS_INIT, it 417 decrypts the cookie with its master key K to obtain the two C2S 418 and S2C keys, for all other ntsMsgId values it MUST perform a 419 lookup into the PTPCLTABLE 421 * if the request contains an NTS_TLV with ntsMsgId == NTS_REQUEST, 422 the nonce used in this signaling message is identical to the 423 NEXT_NONCE stored for this client in the PTPCLTABLE 425 * if the request contains an NTS_TLV with ntsMsgId == 426 NTS_CHALLENGE_REQUEST, CHALLENGE_EXP has not been reached and the 427 cookie used in this signaling message is identical to the 428 CHALLENGE_NONCE stored for this client 430 * If either the cookie cannot be decrypted, no matching entry could 431 be found in the PTPCLTABLE, the nonce does not match the 432 NEXT_NONCE or the CHALLENGE_NONCE, the message MUST be ignored. 433 In all other cases, the following additional checks MUST be 434 performed: 436 - the ICV in the AUTHENTICATION_TLV is correct (using the C2S key 437 from the provided cookie or from the matching entry in the 438 PTPCLTABLE 440 - the key expiration date/time has not been reached 442 If the CHALLENGE_NONCE check fails (only applicable when the 443 ntsMsgId in the received message is NTS_CHALLENGE_RESPONSE), the 444 message MUST be ignored. 446 If the key expiration check fails, the request is denied and, by 447 setting the key lifetime field of the NTS_TLV in the response to 0 448 and the ntsMsgId to NTS_INVALIDKEYS, the client is told to obtain 449 new keys and a new cookie from a NTS-KE server before it can 450 establish a new contract with this PTP server. 452 If no matching entry exists in the PTPCLTABLE, or if the checks above 453 result require an NTS_CHALLENGE_REQUEST response, any active contract 454 (if there is one) MUST NOT be changed, canceled or otherwise 455 modified. This is to avoid that an attacker sends an invalid request 456 which stops the currently active contract and therefore successfully 457 carries out a denial-of-service attack. 459 When a PTP server receives a NTS_INIT message with a valid cookie, 460 the following challenge/response procedure MUST be followed: 462 * The PTP server will deny the REQUEST_UNICAST_TRANSMISSION_TLV 463 request and responds with an NTS_MessageId NTS_CHALLENGE_REQUEST 464 and a nonce which it stores as the CHALLENGE_NONCE in the 465 PTPCLTABLE. The server will put the sequenceId from the PTP 466 packet header of the request into the reqSeqId field of the 467 NTS_TLV 469 * The client, after receiving the response with the 470 NTS_CHALLENGE_REQUEST message ID SHALL check that the reqSeqId is 471 identical to the sequenceId of the request it sent to the server. 472 If this fails, the message MUST be ignored by the client. 474 * If the reqSeqId check is successful, the client resends the 475 REQUEST_UNICAST_TRANSMISSION_TLV using a ntsMsgId of 476 NTS_CHALLENGE_RESPONSE and MUST use the cookie it received with 477 the NTS_CHALLENGE_REQUEST response. 479 * The server then checks that the cookie presented by the client in 480 the NTS_CHALLENGE_RESPONSE response is identical to the 481 CHALLENGE_NONCE. If that is true, the client can be trusted and 482 the REQUEST_UNICAST_TRANSMISSION_TLV included in this response is 483 considered to be a valid and trusted request. 485 After the successful verification of the request, the 486 REQUEST_UNICAST_TRANSMISSION_TLV is processed according to 487 [IEEE1588]. 489 In case the PTP server grants the request to the client, the process 490 moves on to the 3rd phase, the packet transmission phase. If the PTP 491 server denies the request for whatever reason (i.e. it has no 492 capacity or its state does not allow to reliably transmit the packets 493 at the requested rate), it sends a unicast grant denial message, i.e. 494 a PTP signaling message carrying a GRANT_UNICAST_TRANSMISSION TLV 495 with the grant duration set to zero. 497 If a PTP client receives a GRANT_UNICAST_TRANSMISSION_TLV containing 498 an NTS_TLV with a correct ICV and a key lifetime set to 0, it MUST 499 delete all cookies it holds for that PTP server as well as the S2C/ 500 C2S key pair and cease all communication until it re-ran phase 1 and 501 obtained a new key pair and a new cookie. 503 Using the "maximum key lifetime" configuration parameter, a PTP 504 server operator can prioritize memory requirements and required 505 network traffic volume. A small maximum lifetime value results in 506 PTPCLTABLE entries being deleted earlier, requiring more 507 NTS_CHALLENGE_REQUEST exchanges between PTP client and PTP server. A 508 large value may result in requiring fewer such packet exchanges but 509 increases the memory consumption because PTPCLTABLE entries have to 510 be stored for a longer period of time. 512 3.3. Phase 3: PTP Unicast Packet Transmission Phase 514 When the transmission request has been granted by the PTP server for 515 a specific messagetype/duration, for all messagetypes except delay 516 responses the GM immediately starts transmitting the messages in the 517 requested rate. DELAY_RESP messages will be sent after the client 518 sent a DELAY_REQ message. 520 All unicast PTP messages sent by the PTP server to the PTP client due 521 to an active contract SHALL be secured by an AUTHENTICATION_TLV that 522 carries an ICV as described in [IEEE1588], subclause 16.14 (PTP 523 Integrated Security). The ICV is created using the MAC function of 524 the AEAD algorithm and the S2C key established between the PTP client 525 and the NTS-KE server during the NTS-KE phase. All messages sent by 526 the PTP client to the PTP server will be secured with the same 527 mechanism, but using the C2S key. 529 All PTP messages in the packet transmission phase that do not carry 530 an AUTHENTICATION_TLV or in which the ICV is not correct MUST be 531 ignored by the recipient. 533 In order to establish a protection against replay attacks in this 534 phase, both the PTP client and the PTP server MUST check that the 535 sequenceId of an incoming message is larger than the sequenceId of 536 the same PTP message type received in the previous message. If an 537 incoming message does not pass the sequenceId check, it MUST be 538 ignored. Both PTP client and PTP server SHOULD allow to configure 539 the maximum difference between the sequenceId values of two 540 consecutive messages of the same message type. They MUST gracefully 541 handle the rollover of a sequenceId, which is a unsigned int16 value 542 (0-65535). 544 To avoid that an attacker resends a PTP message with a sequenceId 545 that has been obtained before the last rollover, additional integrity 546 checks SHOULD be applied. The maximum packet rate is 128 packets/ 547 second. Therefore, for each PTP message type sent at the maximum 548 rate, the sequenceId rollover happens every 512 seconds (8 minutes, 549 32 seconds) as a minimum. For SYNC, DELAY_REQ and ANNOUNCE messages 550 the recipient SHOULD check that the originTimestamp in the packet 551 does not differ more than 8 minutes from the originTimestamp of the 552 previously received message. For DELAY_RESP messages, the 553 receiveTimestamp SHOULD be used instead. 555 The packet transmission phase ends either when the contract expired 556 or when either the PTP server or the PTP client cancels the contract. 558 4. New NTS record types 560 4.1. Cookie for Unicast PTP 562 The content of this NTS record is identical to record type 5 as 563 defined in 4.1.6 of [RFC8915]. However, a NTS-KE server MUST send 564 exactly one record of this type when PTP is negotiated as a next 565 protocol. 567 4.2. Unicast PTP Server Negotiation 569 The PTP server Negotiation record has a Record Type number of 8. Its 570 body consists of an ASCII-encoded [RFC0020] string. The contents of 571 the string SHALL be either an IPv4 address, an IPv6 address, or a 572 fully qualified domain name (FQDN). IPv4 addresses MUST be in dotted 573 decimal notation. IPv6 addresses MUST conform to the "Text 574 Representation of Addresses" as specified in RFC 4291 [RFC4291] and 575 MUST NOT include [RFC6874]. If a label contains at least one non- 576 ASCII character, it is an internationalized domain name, and an 577 A-LABEL MUST be used as defined in Section 2.3.2.1 of RFC 5890 578 [RFC5890]. If the record contains a domain name, the recipient MUST 579 treat it as a FQDN, e.g., by making sure it ends with a dot. 581 When PTP is negotiated as a Next Protocol and this record is sent by 582 the server, the body specifies the hostname or IP address of the PTP 583 unicast server with which the client MUST associate and that will 584 accept the supplied cookies. If no record of this type is sent, the 585 client SHALL interpret this as a directive to associate with a PTP 586 server at the same IP address as the NTS-KE server. Servers MUST NOT 587 send more than one record of this type. If the record contains a 588 FQDN which resolves to multiple addresses, the client MUST choose at 589 least one of the addresses the FQDN resolves to. The client MAY 590 choose to use more than one address to request synchronization 591 services from multiple unicast PTP servers in parallel. 593 When this record is sent by the client, it indicates that the client 594 wishes to associate with the specified PTP server. The NTS-KE server 595 MAY incorporate this request when deciding which PTP server 596 Negotiation records to respond with, but honoring the client's 597 preference is OPTIONAL. The client MUST NOT send more than one 598 record of this type. 600 If the client has sent a record of this type, the NTS-KE server 601 SHOULD reply with the same record if it is valid and the server is 602 able to supply cookies for it. If the client has not sent any record 603 of this type, the NTS-KE server SHOULD respond with either an PTP 604 server address in the same family as the NTS-KE session or a FQDN 605 that can be resolved to an address in that family, if such 606 alternatives are available. 608 Servers MAY set the Critical Bit on records of this type; clients 609 SHOULD NOT. 611 5. The PTP client Table 613 The PTP server MUST store the following data for each PTP client in a 614 NTS PTP client Table (PTPCLTABLE): 616 * the S2C/C2S key pair 618 * the time when the validity of this key pair expires (KEY_PAIR_EXP) 620 * the next nonce to be expected from the client (NEXT_NONCE) 622 * the nonce to be expected from the client in a 623 NTS_CHALLENGE_RESPONSE message (CHALLENGE_NONCE) 625 * the time when the validity of the CHALLENGE_NONCE expires 626 (CHALLENGE_EXP) 628 6. The NTS_TLV 630 The NTS_TLV contains: 632 1. tlvType: ORGANIZATION_EXTENSION_DO_NOT_PROPAGATE (8000 hex) 634 2. lengthField: number of octets in the value + 6 636 3. organizationID: IETF (=00005E hex) 638 4. organizationSubtype: TBD (needs to be assigned) 640 5. ntsMsgId: NTS Message Id (see below) 642 6. networkProtocol: Transport type (0x01=IPv4, 0x02=IPv6, 643 0x03=Ethernet), unsigned int 645 7. tSrcAddr: Transport source address of the sender, e.g. the IP 646 address or Ethernet MAC address, 16 octets 648 8. keyLifetime: Key Lifetime in seconds, unsigned int32 650 9. reqSeqId: sequenceId of the request, unsigned int16 652 10. nonce/cookie: a nonce or, if ntsMsgId == NTS_INIT, an NTS Cookie 654 +---------------------------------------+--------+------------+ 655 | Bits | Octets | TLV Offset | 656 +----+----+----+----+----+----+----+----+ | | 657 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | | | 658 +----+----+----+----+----+----+----+----+--------+------------+ 659 | tlvType | 2 | 0 | 660 +---------------------------------------+--------+------------+ 661 | lengthField | 2 | 2 | 662 +---------------------------------------+--------+------------+ 663 | organizationId | 3 | 4 | 664 +---------------------------------------+--------+------------+ 665 | organizationSubType | 3 | 7 | 666 +---------------------------------------+--------+------------+ 667 | ntsMsgId | 1 | 10 | 668 +---------------------------------------+--------+------------+ 669 | networkProtocol | 1 | 11 | 670 +---------------------------------------+--------+------------+ 671 | tSrcAddr | 16 | 12 | 672 +---------------------------------------+--------+------------+ 673 | keyLifetime | 4 | 28 | 674 +---------------------------------------+--------+------------+ 675 | reqSeqId | 2 | 32 | 676 +---------------------------------------+--------+------------+ 677 | nonce/cookie | n | 34 | 678 +---------------------------------------+--------+------------+ 680 Figure 2: NTS TLV Format 682 The networkProtocol field allows to detect which transport protocol 683 is in use and therefore how to interprete the tSrcAddr field. For an 684 Ethernet MAC address, the 6 first octets of the tSrcAddr field are 685 relevant, for an IPv4 address the first 4 octets are relevant and for 686 an IPv6 address the full 16 octets are relevant. The enumeration is 687 corresponding to the networkProtocol field as defined in [IEEE1588]. 689 Please note that the size of the cookie depends on the chosen AEAD, 690 it can therefore differ and has been placed at the end of the TLV. 691 The lengthField allows a receipient to calculate the length of the 692 cookie. 694 The ntsMsgId field MUST contain one of the following values: 696 * 0x01 NTS_INIT (for the first unicast negotiation message sent by 697 the PTP client to the PTP server after completing a NTS-KE Phase 698 in which the PTP client obtained a new key pair) 700 * 0x02 NTS_REQUEST (for unicast negotiation messages sent by the PTP 701 client to the PTP server) 703 * 0x03 NTS_RESPONSE (for unicast negotiation messages sent by the 704 PTP server to the PTP client) 706 * 0x04 NTS_CHALLENGE_REQUEST (for messages sent by the PTP server to 707 the PTP client in case of a challenge/response procedure) 709 * 0x05 NTS_CHALLENGE_RESPONSE (for messages sent by the PTP client 710 to the PTP server as a resonse to a NTS_CHALLENGE_REQUEST) 712 * 0x06 NTS_INVALIDKEYS (for messages sent by the PTP server to the 713 PTP client when the S2C/C2S key pair expired or whenever the PTP 714 server wants to force the PTP client to re-run the NTS-KE Phase) 716 The reqSeqId field MUST be set to 0 for all messages except those 717 with a NTS_CHALLENGE_REQUEST message Id. In that specific case the 718 field MUST contain the sequenceId of the message to which this 719 NTS_CHALLENGE_REQUEST is a response. 721 When sending a REQUEST_UNICAST_TRANSMISSION_TLV, the PTP client will 722 add the NTS_TLV containing a cookie for this PTP server. The key 723 lifetime SHALL always be set to 0 for all communication from the PTP 724 client to the PTP server. 726 When sending a GRANT_UNICAST_TRANSMISSION_TLV, the PTP server will 727 add the NTS_TLV as well. If the request of the client is granted 728 (duration > 0), the NTS_TLV will contain a new cookie and the key 729 lifetime field SHALL represent the number of seconds the C2S and S2C 730 keys continue to be valid. 732 The PTP server SHALL set a key lifetime of 0 when the lifetime of the 733 S2C/C2S key pair expired. This allows the PTP server to force the 734 client to re-start and obtain fresh keys and cookies from the NTS-KE 735 server. When sending an NTS_TLV with the key lifetime set to 0, the 736 PTP server SHALL use the S2C key of the expired key pair to form the 737 ICV in the AUTHENTICATION_TLV, allowing the client to verify that the 738 message has been sent by the PTP server. 740 When a client receives any message with a valid ICV but a key 741 lifetime of 0 in the NTS_TLV, it SHALL delete all cookies cease to 742 send any messages to the PTP server and only restores communication 743 with it after it obtained a new S2C/C2S key pair and a new set of 744 cookies from the NTS-KE server. 746 7. IANA Considerations 748 RFC EDITOR: A new entry for Unicast PTP is required in the IANA 749 Network Time Security Next Protocols Registry. The authors propose 750 to add an entry with the Protocol ID = 1, the Protocol Name = 751 "Unicast Precision Time Protocol" and a Reference to this draft. 752 Please remove this comment before publishing and replace it with the 753 data for the newly created entry from IANA. 755 8. Security Considerations 757 8.1. Threat Model 759 The procedures and mechanisms described in this draft protect against 760 the following scenarios: 762 * Man-in-the-Middle (MITM) attack: All PTP nodes can verify that PTP 763 messages received from another PTP server have not been modified 764 in transit by an attacker. This is achieved by verifying that the 765 ICV in the AUTHENTICATION_TLV of every PTP message received is 766 valid and has been created using the MAC function of the AEAD 767 algorithm and the C2S or S2C key as established during the NTS-KE 768 phase. 770 * Phase 2 Replay Attack (resending unmodified PTP unicast 771 negotiation messages): PTP message integrity can be secured with 772 the AUTHENTICATION_TLV. However, with PTP this mechanism does not 773 protect the transport protocol header and could therefore be used 774 by an attacker to intercept a PTP message and then resending it 775 using the same or a different source address. Or it could be 776 resend at a later time to repeat a request or cancel an active 777 contract. Resending it with the same address can be used to try 778 and establish a contract for a unicast PTP client that is no 779 longer requiring the service, requires the service in a different 780 form (e.g. different message rates) or it can be used to cancel a 781 contract (when resending a CANCEL_UNICAST_TRANSMISSION_TLV after 782 the client established a new contract). This can interrupt a 783 required service for a PTP client or result in the PTP server 784 unnecessarily consuming resources. By storing the nonce that has 785 been provided by the server and that MUST be used by the client in 786 its next request (NEXT_NONCE in PTPCLTABLE), an unmodified resent 787 REQUEST_UNICAST_TRANSMISSION_TLV will not be granted, despite the 788 fact that the ICV in the AUTHENTICATION_TLV is valid. T o provide 789 a robust defense against replaying NTS_INIT messages, the 790 challenge/response mechanism (NTS_CHALLENGE_REQUEST/ 791 NTS_CHALLENGE_RESPONSE) will require a PTP client to apply the 792 correct C2S key and therefore protects against replaying a 793 previously sent valid message with a cookie that has been 794 encrypted with a still valid master key K. 796 * Phase 3 Replay Attack (resending unmodified PTP unicast messages): 797 In Phase 3 the PTP server is sending PTP SYNC and ANNOUNCE 798 messages to the PTP client and the PTP client is sending DELAY_REQ 799 messages to the PTP server, which responds with DELAY_RESP 800 messages. An attacker could resend any of these packets. For 801 SYNC messages, that would result in the PTP client receiving "old 802 time", i.e. the timestamps in such a message would be outdated and 803 could disrupt time synchronization of the PTP client. A resent 804 ANNOUNCE message could carry outdated information and therefore 805 could force the PTP client to drop this server as a valid time 806 source or distrupt the protocol in other ways. Resending 807 DELAY_REQ messages could consume resources on the PTP server and, 808 if the server would send DELAY_RESP message, on the PTP client as 809 well. The client could also be negatively affected by resent 810 DELAY_RESP messages that carry outdated time. A valid protection 811 against such an attack is checking the sequenceId of each incoming 812 message and by applying additional integrity checks to messages 813 passing the sequenceId checks. See Section 3.3 for a detailed 814 description of how this can be achieved. 816 * Amplification Attack/Distributed Denial of Service: Resending a 817 REQUEST_UNICAST_TRANSMISSION_TLV with a different source IP 818 address could result in the PTP server sending PTP messages to IP 819 adresses that do not expect and require receiving these messages. 820 Due to the nature of unicast PTP, the traffic amplification 821 porential is very high because one PTP signaling message 822 containing a REQUEST_UNICAST_TRANSMISSION_TLV can generate 823 thousands of PTP messages from the PTP server to the source IP 824 address used in the request message. This is mitigated by 825 including the IP address of the originator of a message as a field 826 (tSrcAddr) in the NTS_TLV. The TLV as part of the PTP message is 827 protected by the ICV in the AUTHENTICATION_TLV and therefore a 828 modified source address can be detected. 830 8.2. General Security Features 832 In addtion to the above outlined protection mechanisms against 833 specific attack scenarios, this draft also includes a generic 834 security feature: 836 * Key Freshness: The expiration of C2S/S2C key pairs requires 837 clients to obtain a new key pair in a configurable interval, which 838 limits the time an attacker has to break those keys. 840 9. Delay Attacks 842 If an attacker gains control over a part of the network 843 infrastructure on the path between clients and server, it could be 844 possible to delay the forwarding of unicast PTP messages without 845 modifying them. Applying such a delay only in one direction (e.g. 846 for SYNC packets sent from the server to the client) would create an 847 asymmetry in the delay calculation and as a result the error in the 848 delay calculation would cause a timing error on the client. This 849 kind of attack cannot be mitigated by NTS4UPTP as the cryptographic 850 protection only allows to ensure the integrity of messages, which is 851 not corrupted by a delay attack. 853 In addition to securing the network infrastructure (i.e. routers and 854 switches) against this threat, another possible mitigation strategy 855 for the client is to check the calculated delay against a static 856 limit (which could be configurable by the user or is defined by the 857 requirements of the application) or a dynamic limit, which the client 858 could determine periodically for example by applying suitable 859 statistical methods to determine a change in the calculated delay 860 that indicates that the potential time error would exceed the sync 861 requirements of the application. 863 10. Acknowledgements 865 The authors would like to thank the following contributors for their 866 valuable feedback: 868 * Martin Langer, MSc and Prof. Dr.-Ing. Rainer Bermbach, Ostfalia 869 University 871 11. References 873 11.1. Normative References 875 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 876 RFC 20, DOI 10.17487/RFC0020, October 1969, 877 . 879 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 880 Requirement Levels", BCP 14, RFC 2119, 881 DOI 10.17487/RFC2119, March 1997, 882 . 884 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 885 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 886 2006, . 888 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 889 "Network Time Protocol Version 4: Protocol and Algorithms 890 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 891 . 893 [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 894 Sundblad, "Network Time Security for the Network Time 895 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 896 . 898 [RFC5890] Klensin, J., "Internationalized Domain Names for 899 Applications (IDNA): Definitions and Document Framework", 900 RFC 5890, DOI 10.17487/RFC5890, August 2010, 901 . 903 [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing 904 IPv6 Zone Identifiers in Address Literals and Uniform 905 Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, 906 February 2013, . 908 11.2. Informative References 910 [IEEE1588] IEEE, "IEEE Std 1588-2019 Standard for a Precision Clock 911 Synchronization Protocol for Networked Measurement and 912 Control", IEEE Standard 1588, 2019, 913 . 916 Authors' Addresses 918 Heiko Gerstung 919 Meinberg Funkuhren GmbH&Co.KG 920 Lange Wand 9 921 31812 Bad Pyrmont 922 Germany 924 Phone: +49 5281 9309 0 925 Email: heiko.gerstung@meinberg.de 926 URI: http://www.meinbergglobal.com/ 928 Marius Rohde 929 Meinberg Funkuhren GmbH&Co.KG 930 Lange Wand 9 931 31812 Bad Pyrmont 932 Germany 934 Phone: +49 5281 9309 0 935 Email: marius.rohde@meinberg.de 936 URI: http://www.meinbergglobal.com/ 938 Douglas Arnold 939 Meinberg USA Inc. 940 100 Stony Point Road Suite 110 941 Santa Rosa, CA 95401 942 United States of America 944 Phone: +1 877-PTP-1588 945 Email: doug.arnold@meinberg-usa.com 946 URI: http://www.meinbergglobal.com/