idnits 2.17.1 draft-ietf-tictoc-security-requirements-12.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 (September 3, 2014) is 3516 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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. -------------------------------------------------------------------------------- 1 TICTOC Working Group T. Mizrahi 2 Internet Draft Marvell 3 Intended status: Informational 4 Expires: March 2015 September 3, 2014 6 Security Requirements of Time Protocols 7 in Packet Switched Networks 8 draft-ietf-tictoc-security-requirements-12.txt 10 Abstract 12 As time and frequency distribution protocols are becoming 13 increasingly common and widely deployed, concern about their exposure 14 to various security threats is increasing. This document defines a 15 set of security requirements for time protocols, focusing on the 16 Precision Time Protocol (PTP) and the Network Time Protocol (NTP). 17 This document also discusses the security impacts of time protocol 18 practices, the performance implications of external security 19 practices on time protocols and the dependencies between other 20 security services and time synchronization. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on March 3, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction ................................................. 3 63 2. Conventions Used in this Document ............................ 5 64 2.1. Terminology ............................................. 5 65 2.2. Abbreviations ........................................... 5 66 2.3. Common Terminology for PTP and NTP ...................... 6 67 2.4. Terms used in this Document ............................. 6 68 3. Security Threats ............................................. 7 69 3.1. Threat Model ............................................ 7 70 3.1.1. Internal vs. External Attackers .................... 7 71 3.1.2. Man in the Middle (MITM) vs. Packet Injector ....... 8 72 3.2. Threat Analysis.......................................... 8 73 3.2.1. Packet Manipulation ................................ 8 74 3.2.2. Spoofing ........................................... 9 75 3.2.3. Replay Attack ...................................... 9 76 3.2.4. Rogue Master Attack ................................ 9 77 3.2.5. Packet Interception and Removal ................... 10 78 3.2.6. Packet Delay Manipulation ......................... 10 79 3.2.7. L2/L3 DoS Attacks ................................. 10 80 3.2.8. Cryptographic Performance Attacks ................. 10 81 3.2.9. DoS Attacks against the Time Protocol ............. 10 82 3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud) . 11 83 3.2.11. Exploiting Vulnerabilities in the Time Protocol .. 11 84 3.2.12. Network Reconnaissance ........................... 11 85 3.3. Threat Analysis Summary ................................ 11 86 4. Requirement Levels .......................................... 13 87 5. Security Requirements ....................................... 14 88 5.1. Clock Identity Authentication and Authorization ........ 14 89 5.1.1. Authentication and Authorization of Masters ....... 15 90 5.1.2. Recursive Authentication and Authorization of Masters 91 (Chain of Trust) ......................................... 16 92 5.1.3. Authentication and Authorization of Slaves ........ 17 93 5.1.4. PTP: Authentication and Authorization of P2P TCs by the 94 Master ................................................... 17 95 5.1.5. PTP: Authentication and Authorization of Control 96 Messages ................................................. 18 97 5.2. Protocol Packet Integrity .............................. 19 98 5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 20 99 5.2.1.1. Hop-by-Hop Integrity Protection .............. 20 100 5.2.1.2. End-to-End Integrity Protection .............. 20 101 5.3. Spoofing Prevention .................................... 21 102 5.4. Availability ........................................... 22 103 5.5. Replay Protection ...................................... 22 104 5.6. Cryptographic Keys and Security Associations ........... 23 105 5.6.1. Key Freshness ..................................... 23 106 5.6.2. Security Association .............................. 23 107 5.6.3. Unicast and Multicast Associations ................ 24 108 5.7. Performance ............................................ 25 109 5.8. Confidentiality......................................... 26 110 5.9. Protection against Packet Delay and Interception Attacks 26 111 5.10. Combining Secured with Unsecured Nodes ................ 27 112 5.10.1. Secure Mode ...................................... 27 113 5.10.2. Hybrid Mode ...................................... 28 114 6. Summary of Requirements ..................................... 29 115 7. Additional security implications ............................ 30 116 7.1. Security and on-the-fly Timestamping ................... 31 117 7.2. PTP: Security and Two-Step Timestamping ................ 31 118 7.3. Intermediate Clocks .................................... 31 119 7.4. External Security Protocols and Time Protocols.......... 32 120 7.5. External Security Services Requiring Time .............. 33 121 7.5.1. Timestamped Certificates .......................... 33 122 7.5.2. Time Changes and Replay Attacks ................... 33 123 8. Issues for Further Discussion ............................... 33 124 9. Security Considerations ..................................... 34 125 10. IANA Considerations......................................... 34 126 11. Acknowledgments ............................................ 34 127 12. References ................................................. 34 128 12.1. Normative References .................................. 34 129 12.2. Informative References ................................ 34 130 13. Contributing Authors ....................................... 36 132 1. Introduction 134 As time protocols are becoming increasingly common and widely 135 deployed, concern about the resulting exposure to various security 136 threats is increasing. If a time protocol is compromised, the 137 applications it serves are prone to a range of possible attacks 138 including Denial-of-Service (DoS) or incorrect behavior. 140 This document discusses the security aspects of time distribution 141 protocols in packet networks, and focuses on the two most common 142 protocols, the Network Time Protocol [NTPv4] and the Precision Time 143 Protocol (PTP) [IEEE1588]. Note, that although PTP was not defined by 144 the IETF, it is one of the two most common time protocols and hence 145 it is included in the discussion. 147 The Network Time Protocol was defined with an inherent security 148 protocol; [NTPv4] defines a security protocol that is based on a 149 symmetric key authentication scheme, and [AutoKey] presents an 150 alternative security protocol, based on a public key authentication 151 scheme. [IEEE1588] includes an experimental security protocol, 152 defined in Annex K of the standard, but this Annex was never 153 formalized into a fully defined security protocol. 155 While NTP includes an inherent security protocol, the absence of a 156 standard security solution for PTP undoubtedly contributed to the 157 wide deployment of unsecured time synchronization solutions. However, 158 in some cases security mechanisms may not be strictly necessary, 159 e.g., due to other security practices in place, or due to the 160 architecture of the network. A time synchronization security 161 solution, much like any security solution, is comprised of various 162 building blocks, and must be carefully tailored for the specific 163 system it is deployed in. Based on a system-specific threat 164 assessment, the benefits of a security solution must be weighed 165 against the potential risks, and based on this tradeoff an optimal 166 security solution can be selected. 168 The target audience of this document includes: 170 o Timing and networking equipment vendors - can benefit from this 171 document by deriving the security features that should be 172 supported in the time/networking equipment. 174 o Standard development organizations - can use the requirements 175 defined in this document when specifying security mechanisms for a 176 time protocol. 178 o Network operators - can use this document as a reference when 179 designing the network and its security architecture. As stated 180 above, the requirements in this document may be deployed 181 selectively based on a careful per-system threat analysis. 183 This document attempts to add clarity to the time protocol security 184 requirements discussion by addressing a series of questions: 186 (1) What are the threats that need to be addressed for the time 187 protocol, and thus what security services need to be provided? (e.g. 188 a malicious NTP server or PTP master) 190 (2) What external security practices impact the security and 191 performance of time keeping, and what can be done to mitigate these 192 impacts? (e.g. an IPsec tunnel in the time protocol traffic path) 194 (3) What are the security impacts of time protocol practices? (e.g. 195 on-the-fly modification of timestamps) 197 (4) What are the dependencies between other security services and 198 time protocols? (e.g. which comes first - the certificate or the 199 timestamp?) 201 In light of the questions above, this document defines a set of 202 requirements for security solutions for time protocols, focusing on 203 PTP and NTP. 205 2. Conventions Used in this Document 207 2.1. Terminology 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in [KEYWORDS]. 213 This document describes security requirements, and thus requirements 214 are phrased in the document in the form "the security mechanism 215 MUST/SHOULD/...". Note, that the phrasing does not imply that this 216 document defines a specific security mechanism, but defines the 217 requirements with which every security mechanism should comply. 219 2.2. Abbreviations 221 BC Boundary Clock [IEEE1588] 223 DoS Denial of Service 225 MITM Man In The Middle 227 NTP Network Time Protocol [NTPv4] 229 OC Ordinary Clock [IEEE1588] 231 P2P TC Peer-to-Peer Transparent Clock [IEEE1588] 232 PTP Precision Time Protocol [IEEE1588] 234 TC Transparent Clock [IEEE1588] 236 2.3. Common Terminology for PTP and NTP 238 This document refers to both PTP and NTP. For the sake of 239 consistency, throughout the document the term "master" applies to 240 both a PTP master and an NTP server. Similarly, the term "slave" 241 applies to both PTP slaves and NTP clients. The term "protocol 242 packets" refers generically to PTP and NTP messages. 244 2.4. Terms used in this Document 246 o Clock - A node participating in the protocol (either PTP or NTP). 247 A clock can be a master, a slave, or an intermediate clock (see 248 corresponding definitions below). 250 o Control packets - Packets used by the protocol to exchange 251 information between clocks that is not strictly related to the 252 time. NTP uses NTP Control Messages. PTP uses Announce, Signaling 253 and Management messages. 255 o End-to-end security - A security approach where secured packets 256 sent from a source to a destination are not modified by 257 intermediate nodes, allowing the destination to authenticate the 258 source of the packets, and to verify their integrity. 259 In the context of confidentiality, end-to-end encryption 260 guarantees that intermediate nodes cannot eavesdrop to en-route 261 packets. However, as discussed in Section 5. , confidentiality is 262 not a strict requirement in this document. 264 o Grandmaster - A master that receives time information from a 265 locally attached clock device, and not through the network. A 266 grandmaster distributes its time to other clocks in the network. 268 o Hop-by-hop security - A security approach where secured packets 269 sent from a source to a destination may be modified by 270 intermediate nodes. In this approach intermediate nodes share the 271 encryption key with the source and destination, allowing them to 272 re-encrypt or re-authenticate modified packets before relaying 273 them to the destination. 275 o Intermediate clock - A clock that receives timing information from 276 a master, and sends timing information to other clocks. 277 In NTP this term refers to an NTP server that is not a Stratum 1 278 server. In PTP this term refers to a BC or a TC. 280 o Master - A clock that generates timing information to other clocks 281 in the network. 282 In NTP 'master' refers to an NTP server. In PTP 'master' refers to 283 a master OC (aka grandmaster) or to a port of a BC that is in the 284 master state. 286 o Protocol packets - Packets used by the time protocol. The 287 terminology used in this document distinguishes between time 288 packets and control packets. 290 o Secured clock - A clock that supports a security mechanism that 291 complies to the requirements in this document. 293 o Slave - A clock that receives timing information from a master. In 294 NTP 'slave' refers to an NTP client. In PTP 'slave' refers to a 295 slave OC, or to a port of a BC that is in the slave state. 297 o Time packets - Protocol packets carrying time information. 299 o Unsecured clock - A clock that does not support a security 300 mechanism according to the requirements in this document. 302 3. Security Threats 304 This section discusses the possible attacker types and analyzes 305 various attacks against time protocols. 307 The literature is rich with security threats of time protocols, e.g., 308 [Traps], [AutoKey], [TimeSec], [SecPTP], and [SecSen]. The threat 309 analysis in this document is mostly based on [TimeSec]. 311 3.1. Threat Model 313 A time protocol can be attacked by various types of attackers. 315 The analysis in this document classifies attackers according to 2 316 criteria, as described in Section 3.1.1. and Section 3.1.2. 318 3.1.1. Internal vs. External Attackers 320 In the context of internal and external attackers, the underlying 321 assumption is that the time protocol is secured either by an 322 encryption or an authentication mechanism, or both. 324 Internal attackers either have access to a trusted segment of the 325 network, or possess the encryption or authentication keys. An 326 internal attack can also be performed by exploiting vulnerabilities 327 in devices; for example, by installing malware, or obtaining 328 credentials to reconfigure the device. Thus, an internal attacker can 329 maliciously tamper with legitimate traffic in the network, as well as 330 generate its own traffic and make it appear legitimate to its 331 attacked nodes. 333 Note that internal attacks are a special case of Byzantine failures, 334 where a node in the system may fail in arbitrary ways; by crashing, 335 by omitting messages, or by malicious behavior. This document focuses 336 on nodes that demonstrate malicious behavior. 338 External attackers, on the other hand, do not have the keys, and have 339 access only to the encrypted or authenticated traffic. 341 Obviously, in the absence of a security mechanism there is no 342 distinction between internal and external attackers, since all 343 attackers are internal in practice. 345 3.1.2. Man in the Middle (MITM) vs. Packet Injector 347 MITM attackers are located in a position that allows interception and 348 modification of in-flight protocol packets. It is assumed that an 349 MITM attacker has physical access to a segment of the network, or has 350 gained control of one of the nodes in the network. 352 A traffic injector is not located in an MITM position, but can attack 353 by generating protocol packets. An injector can reside either within 354 the attacked network, or on an external network that is connected to 355 the attacked network. An injector can also potentially eavesdrop on 356 protocol packets sent as multicast, record them and replay them 357 later. 359 3.2. Threat Analysis 361 3.2.1. Packet Manipulation 363 A packet manipulation attack results when an MITM attacker receives 364 timing protocol packets, alters them and relays them to their 365 destination, allowing the attacker to maliciously tamper with the 366 protocol. This can result in a situation where the time protocol is 367 apparently operational but providing intentionally inaccurate 368 information. 370 3.2.2. Spoofing 372 In spoofing, an injector masquerades as a legitimate node in the 373 network by generating and transmitting protocol packets or control 374 packets. Two typical examples of spoofing attacks: 376 o An attacker can impersonate the master, allowing malicious 377 distribution of false timing information. 379 o An attacker can impersonate a legitimate clock, a slave or an 380 intermediate clock, by sending malicious messages to the master, 381 causing the master to respond to the legitimate clock with 382 protocol packets that are based on the spoofed messages. 383 Consequently, the delay computations of the legitimate clock are 384 based on false information. 386 As with packet manipulation, this attack can result in a situation 387 where the time protocol is apparently operational but providing 388 intentionally inaccurate information. 390 3.2.3. Replay Attack 392 In a replay attack, an attacker records protocol packets and replays 393 them at a later time without any modification. This can also result 394 in a situation where the time protocol is apparently operational but 395 providing intentionally inaccurate information. 397 3.2.4. Rogue Master Attack 399 In a rogue master attack, an attacker causes other nodes in the 400 network to believe it is a legitimate master. As opposed to the 401 spoofing attack, in the Rogue Master attack the attacker does not 402 fake its identity, but rather manipulates the master election process 403 using malicious control packets. For example, in PTP, an attacker can 404 manipulate the Best Master Clock Algorithm (BMCA), and cause other 405 nodes in the network to believe it is the most eligible candidate to 406 be a grandmaster. 408 In PTP, a possible variant of this attack is the rogue TC/BC attack. 409 Similar to the rogue master attack, an attacker can cause victims to 410 believe it is a legitimate TC or BC, allowing the attacker to 411 manipulate the time information forwarded to the victims. 413 3.2.5. Packet Interception and Removal 415 A packet interception and removal attack results when an MITM 416 attacker intercepts and drops protocol packets, preventing the 417 destination node from receiving some or all of the protocol packets. 419 3.2.6. Packet Delay Manipulation 421 In a packet delay manipulation scenario, an MITM attacker receives 422 protocol packets, and relays them to their destination after adding a 423 maliciously computed delay. The attacker can use various delay attack 424 strategies; the added delay can be constant, jittered, or slowly 425 wandering. Each of these strategies has a different impact, but they 426 all effectively manipulate the attacked clock. 428 Note that the victim still receives one copy of each packet, contrary 429 to the replay attack, where some or all of the packets may be 430 received by the victim more than once. 432 3.2.7. L2/L3 DoS Attacks 434 There are many possible Layer 2 and Layer 3 DoS attacks, e.g., IP 435 spoofing, ARP spoofing [Hack], MAC flooding [Anatomy], and many 436 others. As the target's availability is compromised, the timing 437 protocol is affected accordingly. 439 3.2.8. Cryptographic Performance Attacks 441 In cryptographic performance attacks, an attacker transmits fake 442 protocol packets, causing high utilization of the cryptographic 443 engine at the receiver, which attempts to verify the integrity of 444 these fake packets. 446 This DoS attack is applicable to all encryption and authentication 447 protocols. However, when the time protocol uses a dedicated security 448 mechanism implemented in a dedicated cryptographic engine, this 449 attack can be applied to cause DoS specifically to the time protocol. 451 3.2.9. DoS Attacks against the Time Protocol 453 An attacker can attack a clock by sending an excessive number of time 454 protocol packets, thus degrading the victim's performance. This 455 attack can be implemented, for example, using the attacks described 456 in Section 3.2.2. and Section 3.2.4. 458 3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud) 460 Grandmasters receive their time from an external accurate time 461 source, such as an atomic clock or a GPS clock, and then distribute 462 this time to the slaves using the time protocol. 464 Time source attack are aimed at the accurate time source of the 465 grandmaster. For example, if the grandmaster uses a GPS based clock 466 as its reference source, an attacker can jam the reception of the GPS 467 signal, or transmit a signal similar to one from a GPS satellite, 468 causing the grandmaster to use a false reference time. 470 Note that this attack is outside the scope of the time protocol. 471 While various security measures can be taken to mitigate this attack, 472 these measures are outside the scope of the security requirements 473 defined in this document. 475 3.2.11. Exploiting Vulnerabilities in the Time Protocol 477 Time protocols can be attacked by exploiting vulnerabilities in the 478 protocol, implementation bugs, or misconfigurations (e.g., 479 [NTPDDoS]). It should be noted that such attacks cannot typically be 480 mitigated by security mechanisms. However, when a new vulnerability 481 is discovered, operators should react as soon as possible, and take 482 the necessary measures to address it. 484 3.2.12. Network Reconnaissance 486 An attacker can exploit the time protocol to collect information such 487 as addresses and locations of nodes that take part in the protocol. 488 Reconnaissance can be applied either by passively eavesdropping to 489 protocol packets, or by sending malicious packets and gathering 490 information from the responses. By eavesdropping to a time protocol, 491 an attacker can learn the network latencies, which provide 492 information about the network topology and node locations. 494 Moreover, properties such as the frequency of the protocol packets, 495 or the exact times at which they are sent can allow fingerprinting of 496 specific nodes; thus, protocol packets from a node can be identified 497 even if network addresses are hidden or encrypted. 499 3.3. Threat Analysis Summary 501 The two key factors to a threat analysis are the impact and the 502 likelihood of each of the analyzed attacks. 504 Table 1 summarizes the security attacks presented in Section 3.2. 505 For each attack, the table specifies its impact, and its 506 applicability to each of the attacker types presented in Section 3.1. 508 Table 1 clearly shows the distinction between external and internal 509 attackers, and motivates the usage of authentication and integrity 510 protection, significantly reducing the impact of external attackers. 512 The Impact column provides an intuitive measure of the severity of 513 each attack, and the relevant Attacker Type columns provide an 514 intuition about how difficult each attack is to implement, and hence 515 about the likelihood of each attack. 517 The impact column in Table 1 can have one of 3 values: 519 o DoS - the attack causes denial of service to the attacked node, 520 the impact of which is not restricted to the time protocol. 522 o Accuracy degradation - the attack yields a degradation in the 523 slave accuracy, but does not completely compromise the slaves' 524 time and frequency. 526 o False time - slaves align to a false time or frequency value due 527 to the attack. Note that if the time protocol aligns to a false 528 time, it may cause DoS to other applications that rely on accurate 529 time. However, for the purpose of the analysis in this section we 530 distinguish this implication from 'DoS', which refers to a DoS 531 attack that is not necessarily aimed at the time protocol. 532 All attacks that have a '+' for 'False Time' implicitly have a '+' 533 for 'Accuracy Degradation'. 534 Note, that 'False Time' necessarily implies 'Accuracy 535 Degradation'. However, two different terms are used, indicating 536 two levels of severity. 538 The Attacker Type columns refer to the 4 possible combinations of the 539 attacker types defined in Section 3.1. 541 +-----------------------------+-------------------++-------------------+ 542 | Attack | Impact || Attacker Type | 543 | +-----+--------+----++---------+---------+ 544 | |False|Accuracy| ||Internal |External | 545 | |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.| 546 +-----------------------------+-----+--------+----++----+----+----+----+ 547 |Manipulation | + | | || + | | | | 548 +-----------------------------+-----+--------+----++----+----+----+----+ 549 |Spoofing | + | | || + | + | | | 550 +-----------------------------+-----+--------+----++----+----+----+----+ 551 |Replay attack | + | | || + | + | | | 552 +-----------------------------+-----+--------+----++----+----+----+----+ 553 |Rogue master attack | + | | || + | + | | | 554 +-----------------------------+-----+--------+----++----+----+----+----+ 555 |Interception and removal | | + | + || + | | + | | 556 +-----------------------------+-----+--------+----++----+----+----+----+ 557 |Packet delay manipulation | + | | || + | | + | | 558 +-----------------------------+-----+--------+----++----+----+----+----+ 559 |L2/L3 DoS attacks | | | + || + | + | + | + | 560 +-----------------------------+-----+--------+----++----+----+----+----+ 561 |Crypt. performance attacks | | | + || + | + | + | + | 562 +-----------------------------+-----+--------+----++----+----+----+----+ 563 |Time protocol DoS attacks | | | + || + | + | | | 564 +-----------------------------+-----+--------+----++----+----+----+----+ 565 |Master time source attack | + | | || + | + | + | + | 566 |(e.g., GPS spoofing) | | | || | | | | 567 +-----------------------------+-----+--------+----++----+----+----+----+ 568 Table 1 Threat Analysis - Summary 570 The threats discussed in this section provide the background for the 571 security requirements presented in Section 5. 573 4. Requirement Levels 575 The security requirements are presented in Section 5. Each 576 requirement is defined with a requirement level, in accordance with 577 the requirement levels defined in Section 2.1. 579 The requirement levels in this document are affected by the following 580 factors: 582 o Impact: 583 The possible impact of not implementing the requirement, as 584 illustrated in the 'impact' column of Table 1. 585 For example, a requirement that addresses a threat that can be 586 implemented by an external injector is typically a 'MUST', since 587 the threat can be implemented by all the attacker types analyzed 588 in Section 3.1. 590 o Difficulty of the corresponding attack: 591 The level of difficulty of the possible attacks that become 592 possible by not implementing the requirement. The level of 593 difficulty is reflected in the 'Attacker Type' column of Table 1. 594 For example, a requirement that addresses a threat that only 595 compromises the availability of the protocol is typically no more 596 than a 'SHOULD'. 598 o Practical considerations: 599 Various practical factors that may affect the requirement. 600 For example, if a requirement is very difficult to implement, or 601 is applicable to very specific scenarios, these factors may reduce 602 the requirement level. 604 Section 5. lists the requirements. For each requirement there is a 605 short explanation detailing the reason for its requirement level. 607 5. Security Requirements 609 This section defines a set of security requirements. These 610 requirements are phrased in the form "the security mechanism 611 MUST/SHOULD/MAY...". However, this document does not specify how 612 these requirements can be met. While these requirements can be 613 satisfied by defining explicit security mechanisms for time 614 protocols, at least a subset of the requirements can be met by 615 applying common security practices to the network or by using 616 existing security protocols, such as [IPsec] or [MACsec]. Thus, 617 security solutions that address these requirements are outside the 618 scope of this document. 620 5.1. Clock Identity Authentication and Authorization 622 Requirement 624 The security mechanism MUST support authentication. 626 Requirement 628 The security mechanism MUST support authorization. 630 Requirement Level 632 The requirements in this subsection address the spoofing attack 633 (Section 3.2.2.), and the rogue master attack (Section 3.2.4.). 635 The requirement level of these requirements is 'MUST' since in the 636 absence of these requirements the protocol is exposed to attacks that 637 are easy to implement and have a high impact. 639 Discussion 641 Authentication refers to verifying the identity of the peer clock. 642 Authorization, on the other hand, refers to verifying that the peer 643 clock is permitted to play the role that it plays in the protocol. 644 For example, some nodes may be permitted to be masters, while other 645 nodes are only permitted to be slaves or TCs. 647 Authentication is typically implemented by means of a cryptographic 648 signature, allowing to verify the identity of the sender. 649 Authorization requires clocks to maintain a list of authorized 650 clocks, or a "black list" of clocks that should be denied service or 651 revoked. 653 It is noted that while the security mechanism is required to provide 654 an authorization mechanism, the deployment of such a mechanism 655 depends on the nature of the network. For example, a network that 656 deploys PTP may consist of a set of identical OCs, where all clocks 657 are equally permitted to be a master. In such a network an 658 authorization mechanism may not be necessary. 660 The following subsections describe 5 distinct cases of clock 661 authentication. 663 5.1.1. Authentication and Authorization of Masters 665 Requirement 667 The security mechanism MUST support an authentication mechanism, 668 allowing slaves to authenticate the identity of masters. 670 Requirement 672 The authentication mechanism MUST allow slaves to verify that the 673 authenticated master is authorized to be a master. 675 Requirement Level 677 The requirements in this subsection address the spoofing attack 678 (Section 3.2.2.), and the rogue master attack (Section 3.2.4.). 680 The requirement level of these requirements is 'MUST' since in the 681 absence of these requirements the protocol is exposed to attacks that 682 are easy to implement and have a high impact. 684 Discussion 686 Clocks authenticate masters in order to ensure the authenticity of 687 the time source. It is important for a slave to verify the identity 688 of the master, as well as to verify that the master is indeed 689 authorized to be a master. 691 5.1.2. Recursive Authentication and Authorization of Masters (Chain of 692 Trust) 694 Requirement 696 The security mechanism MUST support recursive authentication and 697 authorization of the master, to be used in cases where time 698 information is conveyed through intermediate clocks. 700 Requirement Level 702 The requirement in this subsection addresses the spoofing attack 703 (Section 3.2.2.), and the rogue master attack (Section 3.2.4.). 705 The requirement level of this requirement is 'MUST' since in the 706 absence of this requirement the protocol is exposed to attacks that 707 are easy to implement and have a high impact. 709 Discussion 711 In some cases a slave is connected to an intermediate clock, that is 712 not the primary time source. For example, in PTP a slave can be 713 connected to a Boundary Clock (BC) or a Transparent Clock (TC), which 714 in turn is connected to a grandmaster. A similar example in NTP is 715 when a client is connected to a stratum 2 server, which is connected 716 to a stratum 1 server. In both the PTP and the NTP cases, the slave 717 authenticates the intermediate clock, and the intermediate clock 718 authenticates the grandmaster. This recursive authentication process 719 is referred to in [AutoKey] as proventication. 721 Specifically in PTP, this requirement implies that if a slave 722 receives time information through a TC, it must authenticate the TC 723 it is attached to, as well as authenticate the master it receives the 724 time information from, as per Section 5.1.1. Similarly, if a TC 725 receives time information through an attached TC, it must 726 authenticate the attached TC. 728 5.1.3. Authentication and Authorization of Slaves 730 Requirement 732 The security mechanism MAY provide a means for a master to 733 authenticate its slaves. 735 Requirement 737 The security mechanism MAY provide a means for a master to verify 738 that the sender of a protocol packet is authorized to send a packet 739 of this type. 741 Requirement Level 743 The requirement in this subsection prevents DoS attacks against the 744 master (Section 3.2.9.). 746 The requirement level of this requirement is 'MAY' since: 748 o Its low impact, i.e., in the absence of this requirement the 749 protocol is only exposed to DoS. 751 o Practical considerations: requiring an NTP server to authenticate 752 its clients may significantly impose on the server's performance. 754 Note that while the requirement level of this requirement is 'MAY', 755 the requirement in Section 5.1.1. is 'MUST'; the security mechanism 756 must provide a means for authentication and authorization, with an 757 emphasis on the master. Authentication and authorization of slaves is 758 specified in this subsection as 'MAY'. 760 Discussion 762 Slaves and intermediate clocks are authenticated by masters in order 763 to verify that they are authorized to receive timing services from 764 the master. 766 Authentication of slaves prevents unauthorized clocks from receiving 767 time services. Preventing the master from serving unauthorized clocks 768 can help in mitigating DoS attacks against the master. Note that the 769 authentication of slaves might put a higher load on the master than 770 serving the unauthorized clock, and hence this requirement is a MAY. 772 5.1.4. PTP: Authentication and Authorization of P2P TCs by the Master 774 Requirement 775 The security mechanism for PTP MAY provide a means for a master to 776 authenticate the identity of the P2P TCs directly connected to it. 778 Requirement 780 The security mechanism for PTP MAY provide a means for a master to 781 verify that P2P TCs directly connected to it are authorized to be 782 TCs. 784 Requirement Level 786 The requirement in this subsection prevents DoS attacks against the 787 master (Section 3.2.9.). 789 The requirement level of this requirement is 'MAY' for the same 790 reasons specified in Section 5.1.3. 792 Discussion 794 P2P TCs that are one hop from the master use the PDelay_Req and 795 PDelay_Resp handshake to compute the link delay between the master 796 and TC. These TCs are authenticated by the master. 798 Authentication of TCs, much like authentication of slaves, reduces 799 unnecessary load on the master and peer TCs, by preventing the master 800 from serving unauthorized clocks. 802 5.1.5. PTP: Authentication and Authorization of Control Messages 804 Requirement 806 The security mechanism for PTP MUST support authentication of 807 Announce messages. The authentication mechanism MUST also verify that 808 the sender is authorized to be a master. 810 Requirement 812 The security mechanism for PTP MUST support authentication and 813 authorization of Management messages. 815 Requirement 817 The security mechanism MAY support authentication and authorization 818 of Signaling messages. 820 Requirement Level 821 The requirements in this subsection address the spoofing attack 822 (Section 3.2.2.), and the rogue master attack (Section 3.2.4.). 824 The requirement level of the first two requirements is 'MUST' since 825 in the absence of these requirements the protocol is exposed to 826 attacks that are easy to implement and have a high impact. 828 The requirement level of the third requirement is 'MAY' since its 829 impact greatly depends on the application for which the Signaling 830 messages are used for. 832 Discussion 834 Master election is performed in PTP using the Best Master Clock 835 Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock 836 attributes using Announce messages, and the best master is elected 837 based on the information gathered from all the candidates. Announce 838 messages must be authenticated in order to prevent rogue master 839 attacks (Section 3.2.4.). Note, that this subsection specifies a 840 requirement that is not necessarily included in Section 5.1.1. or in 841 Section 5.1.3. , since the BMCA is initiated before clocks have been 842 defined as masters or slaves. 844 Management messages are used to monitor or configure PTP clocks. 845 Malicious usage of Management messages enables various attacks, such 846 as the rogue master attack, or DoS attack. 848 Signaling messages are used by PTP clocks to exchange information 849 that is not strictly related to time information or to master 850 selection, such as unicast negotiation. Authentication and 851 authorization of Signaling message may be required in some systems, 852 depending on the application these messages are used for. 854 5.2. Protocol Packet Integrity 856 Requirement 858 The security mechanism MUST protect the integrity of protocol 859 packets. 861 Requirement Level 863 The requirement in this subsection addresses the packet manipulation 864 attack (Section 3.2.1.). 866 The requirement level of this requirement is 'MUST' since in the 867 absence of this requirement the protocol is exposed to attacks that 868 are easy to implement and have high impact. 870 Discussion 872 While Section 5.1. refers to ensuring the identity an authorization 873 of the source of a protocol packet, this subsection refers to 874 ensuring that the packet arrived intact. The integrity protection 875 mechanism ensures the authenticity and completeness of data from the 876 data originator. 878 Integrity protection is typically implemented by means of an 879 Integrity Check Value (ICV) that is included in protocol packets and 880 is verified by the receiver. 882 5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 884 Specifically in PTP, when protocol packets are subject to 885 modification by TCs, the integrity protection can be enforced in one 886 of two approaches, end-to-end or hop-by-hop. 888 5.2.1.1. Hop-by-Hop Integrity Protection 890 Each hop that needs to modify a protocol packet: 892 o Verifies its integrity. 894 o Modifies the packet, i.e., modifies the correctionField. 895 Note: Transparent Clocks (TCs) improve the end-to-end accuracy by 896 updating a "correctionField" (clause 6.5 in [IEEE1588]) in the PTP 897 packet by adding the latency caused by the current TC. 899 o Re-generates the integrity protection, e.g., re-computes a Message 900 Authentication Code. 902 In the hop-by-hop approach, the integrity of protocol packets is 903 protected by induction on the path from the originator to the 904 receiver. 906 This approach is simple, but allows rogue TCs to modify protocol 907 packets. 909 5.2.1.2. End-to-End Integrity Protection 911 In this approach, the integrity protection is maintained on the path 912 from the originator of a protocol packet to the receiver. This allows 913 the receiver to directly validate the protocol packet without the 914 ability of intermediate TCs to manipulate the packet. 916 Since TCs need to modify the correctionField, a separate integrity 917 protection mechanism is used specifically for the correctionField. 919 The end-to-end approach limits the TC's impact to the correctionField 920 alone, while the rest of the protocol packet is protected on an end- 921 to-end basis. It should be noted that this approach is more difficult 922 to implement than the hop-by-hop approach, as it requires the 923 correctionField to be protected separately from the other fields of 924 the packet, possibly using different cryptographic mechanisms and 925 keys. 927 5.3. Spoofing Prevention 929 Requirement 931 The security mechanism MUST provide a means to prevent master 932 spoofing. 934 Requirement 936 The security mechanism MUST provide a means to prevent slave 937 spoofing. 939 Requirement 941 PTP: The security mechanism MUST provide a means to prevent P2P TC 942 spoofing. 944 Requirement Level 946 The requirements in this subsection address spoofing attacks (Section 947 3.2.2.). As described in Section 3.2.2. , when these requirements 948 are not met, the attack may have a high impact, causing slaves to 949 rely on false time information. Thus, the requirement level is 950 'MUST'. 952 Discussion 954 Spoofing attacks may take various different forms, and can 955 potentially cause significant impact. In a master spoofing attack, 956 the attacker causes slaves to receive false information about the 957 current time by masquerading as the master. 959 By spoofing a slave or an intermediate node (the second example of 960 Section 3.2.2.), an attacker can tamper with the slaves' delay 961 computations. These attacks can be mitigated by an authentication 962 mechanism (Section 5.1.3. and 5.1.4.), or by other means, for 963 example, a PTP Delay_Req can include a Message Authentication Code 964 (MAC) that is included in the corresponding Delay_Resp message, 965 allowing the slave to verify that the Delay_Resp was not sent in 966 response to a spoofed message. 968 5.4. Availability 970 Requirement 972 The security mechanism SHOULD include measures to mitigate DoS 973 attacks against the time protocol. 975 Requirement Level 977 The requirement in this subsection prevents DoS attacks against the 978 protocol (Section 3.2.9.). 980 The requirement level of this requirement is 'SHOULD' due to its low 981 impact, i.e., in the absence of this requirement the protocol is only 982 exposed to DoS. 984 Discussion 986 The protocol availability can be compromised by several different 987 attacks. An attacker can inject protocol packets to implement the 988 spoofing attack (Section 3.2.2.) or the rogue master attack (Section 989 3.2.4.), causing DoS to the victim (Section 3.2.9.). 991 An authentication mechanism (Section 5.1.) limits these attacks 992 strictly to internal attackers, and thus prevents external attackers 993 from performing them. Hence, the requirements of Section 5.1. can be 994 used to mitigate this attack. Note, that Section 5.1. addresses a 995 wider range of threats, whereas the current section is focused on 996 availability. 998 The DoS attacks described in Section 3.2.7. are performed at lower 999 layers than the time protocol layer, and are thus outside the scope 1000 of the security requirements defined in this document. 1002 5.5. Replay Protection 1004 Requirement 1005 The security mechanism MUST include a replay prevention mechanism. 1007 Requirement Level 1009 The requirement in this subsection prevents replay attacks (Section 1010 3.2.3.). 1012 The requirement level of this requirement is 'MUST' since in the 1013 absence of this requirement the protocol is exposed to attacks that 1014 are easy to implement and have a high impact. 1016 Discussion 1018 The replay attack (Section 3.2.3.) can compromise both the integrity 1019 and availability of the protocol. Common encryption and 1020 authentication mechanisms include replay prevention mechanisms that 1021 typically use a monotonously increasing packet sequence number. 1023 5.6. Cryptographic Keys and Security Associations 1025 5.6.1. Key Freshness 1027 Requirement 1029 The security mechanism MUST provide a means to refresh the 1030 cryptographic keys. 1032 The cryptographic keys MUST be refreshed frequently. 1034 Requirement Level 1036 The requirement level of this requirement is 'MUST' since key 1037 freshness is an essential property for cryptographic algorithms, as 1038 discussed below. 1040 Discussion 1042 Key freshness guarantees that both sides share a common updated 1043 secret key. It also helps in preventing replay attacks. Thus, it is 1044 important for keys to be refreshed frequently. Note that the term 1045 'frequently' is used without a quantitative requirement, as the 1046 precise frequency requirement should be considered on a per-system 1047 basis, based on the threats and system requirements. 1049 5.6.2. Security Association 1051 Requirement 1052 The security protocol SHOULD support a security association protocol 1053 where: 1055 o Two or more clocks authenticate each other. 1057 o The clocks generate and agree on a cryptographic session key. 1059 Requirement 1061 Each instance of the association protocol SHOULD produce a different 1062 session key. 1064 Requirement Level 1066 The requirement level of this requirement is 'SHOULD' since it may be 1067 expensive in terms of performance, especially in low-cost clocks. 1069 Discussion 1071 The security requirements in Section 5.1. and Section 5.2. require 1072 usage of cryptographic mechanisms, deploying cryptographic keys. A 1073 security association (e.g., [IPsec]) is an important building block 1074 in these mechanisms. 1076 It should be noted that in some cases different security association 1077 mechanisms may be used at different levels of clock hierarchies. For 1078 example, the association between a Stratum 2 clock and a Stratum 3 1079 clock in NTP may have different characteristics than an association 1080 between two clocks at the same stratum level. On a related note, in 1081 some cases a hybrid solution may be used, where a subset of the 1082 network is not secured at all (see Section 5.10.2.). 1084 5.6.3. Unicast and Multicast Associations 1086 Requirement 1088 The security mechanism SHOULD support security association protocols 1089 for unicast and for multicast associations. 1091 Requirement Level 1093 The requirement level of this requirement is 'SHOULD' since it may be 1094 expensive in terms of performance, especially for low-cost clocks. 1096 Discussion 1097 A unicast protocol requires an association protocol between two 1098 clocks, whereas a multicast protocol requires an association protocol 1099 among two or more clocks, where one of the clocks is a master. 1101 5.7. Performance 1103 Requirement 1105 The security mechanism MUST be designed in such a way that it does 1106 not significantly degrade the quality of the time transfer. 1108 Requirement 1110 The mechanism SHOULD minimize computational load. 1112 Requirement 1114 The mechanism SHOULD minimize storage requirements of client state in 1115 the master. 1117 Requirement 1119 The mechanism SHOULD minimize the bandwidth overhead required by the 1120 security protocol. 1122 Requirement Level 1124 While the quality of the time transfer is clearly a 'MUST', the other 1125 3 performance requirements are 'SHOULD', since some systems may be 1126 more sensitive to resource consumption than others, and hence these 1127 requirements should be considered on a per-system basis. 1129 Discussion 1131 Performance efficiency is important since client restrictions often 1132 dictate a low processing and memory footprint, and because the server 1133 may have extensive fan-out. 1135 Note that the performance requirements refer to a time-protocol- 1136 specific security mechanism. In systems where a security protocol is 1137 used for other types of traffic as well, this document does not place 1138 any performance requirements on the security protocol performance. 1139 For example, if IPsec encryption is used for securing all information 1140 between the master and slave node, including information that is not 1141 part of the time protocol, the requirements in this subsection are 1142 not necessarily applicable. 1144 5.8. Confidentiality 1146 Requirement 1148 The security mechanism MAY provide confidentiality protection of the 1149 protocol packets. 1151 Requirement Level 1153 The requirement level of this requirement is 'MAY' since the absence 1154 of this requirement does not expose the protocol to severe threats, 1155 as discussed below. 1157 Discussion 1159 In the context of time protocols, confidentiality is typically of low 1160 importance, since timing information is typically not considered 1161 secret information. 1163 Confidentiality can play an important role when service providers 1164 charge their customers for time synchronization services, and thus an 1165 encryption mechanism can prevent eavesdroppers from obtaining the 1166 service without payment. Note that these cases are, for now, rather 1167 esoteric. 1169 Confidentiality can also prevent an MITM attacker from identifying 1170 protocol packets. Thus, confidentiality can assist in protecting the 1171 timing protocol against MITM attacks such as packet delay (Section 1172 3.2.6.), manipulation and interception and removal attacks. Note, 1173 that time protocols have predictable behavior even after encryption, 1174 such as packet transmission rates and packet lengths. Additional 1175 measures can be taken to mitigate encrypted traffic analysis by 1176 random padding of encrypted packets and by adding random dummy 1177 packets. Nevertheless, encryption does not prevent such MITM attacks, 1178 but rather makes these attacks more difficult to implement. 1180 5.9. Protection against Packet Delay and Interception Attacks 1182 Requirement 1184 The security mechanism MUST include means to protect the protocol 1185 from MITM attacks that degrade the clock accuracy. 1187 Requirement Level 1188 The requirements in this subsection address MITM attacks such as the 1189 packet delay attack (Section 3.2.6.) and packet interception attacks 1190 (Section 3.2.5. and Section 3.2.1.). 1192 The requirement level of this requirement is 'MUST'. In the absence 1193 of this requirement the protocol is exposed to attacks that are easy 1194 to implement and have a high impact. Note that in the absence of this 1195 requirement, the impact is similar to packet manipulation attacks 1196 (Section 3.2.1.), and thus this requirement has the same requirement 1197 level as integrity protection (Section 5.2.). 1199 It is noted that the implementation of this requirement depends on 1200 the topology and properties of the system. 1202 Discussion 1204 While this document does not define specific security solutions, we 1205 note that common practices for protection against MITM attacks use 1206 redundant masters (e.g. [NTPv4]), or redundant paths between the 1207 master and slave (e.g. [DelayAtt]). If one of the time sources 1208 indicates a time value that is significantly different than the other 1209 sources, it is assumed to be erroneous or under attack, and is 1210 therefore ignored. 1212 Thus, MITM attack prevention derives a requirement from the security 1213 mechanism, and a requirement from the network topology. While the 1214 security mechanism should support the ability to detect delay 1215 attacks, it is noted that in some networks it is not possible to 1216 provide the redundancy needed for such a detection mechanism. 1218 5.10. Combining Secured with Unsecured Nodes 1220 Integrating a security mechanism into a time synchronized system is a 1221 complex and expensive process, and hence in some cases may require 1222 incremental deployment, where new equipment supports the security 1223 mechanism, and is required to interoperate with legacy equipment 1224 without the security features. 1226 5.10.1. Secure Mode 1228 Requirement 1230 The security mechanism MUST support a secure mode, where only secured 1231 clocks are permitted to take part in the time protocol. In this mode 1232 every protocol packet received from an unsecured clock MUST be 1233 discarded. 1235 Requirement Level 1237 The requirement level of this requirement is 'MUST' since the full 1238 capacity of the security requirements defined in this document can 1239 only be achieved in secure mode. 1241 Discussion 1243 While the requirement in this subsection is similar to the one in 1244 5.1. , it refers to the secure mode, as opposed to the hybrid mode 1245 presented in the next subsection. 1247 5.10.2. Hybrid Mode 1249 Requirement 1251 The security protocol SHOULD support a hybrid mode, where both 1252 secured and unsecured clocks are permitted to take part in the 1253 protocol. 1255 Requirement Level 1257 The requirement level of this requirement is a 'SHOULD'; on one hand 1258 hybrid mode enables a gradual transition from unsecured to secured 1259 mode, which is especially important in large-scaled deployments. On 1260 the other hand, hybrid mode is not required in all systems; this 1261 document recommends to deploy the 'Secure Mode' described in Section 1262 5.10.1. where possible. 1264 Discussion 1266 The hybrid mode allows both secured and unsecured clocks to take part 1267 in the time protocol. NTP, for example, allows a mixture of secured 1268 and unsecured nodes. 1270 Requirement 1272 A master in the hybrid mode SHOULD be a secured clock. 1274 A secured slave in the hybrid mode SHOULD discard all protocol 1275 packets received from unsecured clocks. 1277 Requirement Level 1279 The requirement level of this requirement is a 'SHOULD', since it may 1280 not be applicable to all deployments. For example, a hybrid network 1281 may require the usage of unsecured masters or TCs. 1283 Discussion 1285 This requirement ensures that the existence of unsecured clocks does 1286 not compromise the security provided to secured clocks. Hence, 1287 secured slaves only "trust" protocol packets received from a secured 1288 clock. 1290 An unsecured slave can receive protocol packets either from unsecured 1291 clocks, or from secured clocks. Note that the latter does not apply 1292 when encryption is used. When integrity protection is used, the 1293 unsecured slave can receive secured packets ignoring the integrity 1294 protection. 1296 Note that the security scheme in [NTPv4] with [AutoKey] does not 1297 satisfy this requirement, since nodes prefer the server with the most 1298 accurate clock, which is not necessarily the server that supports 1299 authentication. For example, a stratum 2 server is connected to two 1300 stratum 1 servers, Server A, supporting authentication, and server B, 1301 without authentication. If server B has a more accurate clock than A, 1302 the stratum 2 server chooses server B, in spite of the fact it does 1303 not support authentication. 1305 6. Summary of Requirements 1307 +-----------+---------------------------------------------+--------+ 1308 | Section | Requirement | Type | 1309 +-----------+---------------------------------------------+--------+ 1310 | 5.1. | Authentication & authorization of sender. | MUST | 1311 | +---------------------------------------------+--------+ 1312 | | Authentication & authorization of master. | MUST | 1313 | +---------------------------------------------+--------+ 1314 | | Recursive authentication & authorization. | MUST | 1315 | +---------------------------------------------+--------+ 1316 | | Authentication & authorization of slaves. | MAY | 1317 | +---------------------------------------------+--------+ 1318 | | PTP: Authentication & authorization of | MAY | 1319 | | P2P TCs by master. | | 1320 | +---------------------------------------------+--------+ 1321 | | PTP: Authentication & authorization of | MUST | 1322 | | Announce messages. | | 1323 | +---------------------------------------------+--------+ 1324 | | PTP: Authentication & authorization of | MUST | 1325 | | Management messages. | | 1326 | +---------------------------------------------+--------+ 1327 | | PTP: Authentication & authorization of | MAY | 1328 | | Signaling messages. | | 1329 +-----------+---------------------------------------------+--------+ 1330 | 5.2. | Integrity protection. | MUST | 1331 +-----------+---------------------------------------------+--------+ 1332 | 5.3. | Spoofing prevention. | MUST | 1333 +-----------+---------------------------------------------+--------+ 1334 | 5.4. | Protection from DoS attacks against the | SHOULD | 1335 | | time protocol. | | 1336 +-----------+---------------------------------------------+--------+ 1337 | 5.5. | Replay protection. | MUST | 1338 +-----------+---------------------------------------------+--------+ 1339 | 5.6. | Key freshness. | MUST | 1340 | +---------------------------------------------+--------+ 1341 | | Security association. | SHOULD | 1342 | +---------------------------------------------+--------+ 1343 | | Unicast and multicast associations. | SHOULD | 1344 +-----------+---------------------------------------------+--------+ 1345 | 5.7. | Performance: no degradation in quality of | MUST | 1346 | | time transfer. | | 1347 | +---------------------------------------------+--------+ 1348 | | Performance: computation load. | SHOULD | 1349 | +---------------------------------------------+--------+ 1350 | | Performance: storage. | SHOULD | 1351 | +---------------------------------------------+--------+ 1352 | | Performance: bandwidth. | SHOULD | 1353 +-----------+---------------------------------------------+--------+ 1354 | 5.8. | Confidentiality protection. | MAY | 1355 +-----------+---------------------------------------------+--------+ 1356 | 5.9. | Protection against delay and interception | MUST | 1357 | | attacks. | | 1358 +-----------+---------------------------------------------+--------+ 1359 | 5.10. | Secure mode. | MUST | 1360 | +---------------------------------------------+--------+ 1361 | | Hybrid mode. | SHOULD | 1362 +-----------+---------------------------------------------+--------+ 1363 Table 2 Summary of Security Requirements 1365 7. Additional security implications 1367 This section discusses additional implications of the interaction 1368 between time protocols and security mechanisms. 1370 This section refers to time protocol security mechanisms, as well as 1371 to "external" security mechanisms, i.e., security mechanisms that are 1372 not strictly related to the time protocol. 1374 7.1. Security and on-the-fly Timestamping 1376 Time protocols often require that protocol packets be modified during 1377 transmission. Both NTP and PTP in one-step mode require clocks to 1378 modify protocol packets based on the time of transmission and/or 1379 reception. 1381 In the presence of a security mechanism, whether encryption or 1382 integrity protection: 1384 o During transmission the encryption and/or integrity protection 1385 MUST be applied after integrating the timestamp into the packet. 1387 To allow high accuracy, timestamping is typically performed as close 1388 to the transmission or reception time as possible. However, since the 1389 security engine must be placed between the timestamping function and 1390 the physical interface, it may introduce non-deterministic latency 1391 that causes accuracy degradation. These performance aspects have been 1392 analyzed in literature, e.g., [1588IPsec] and [Tunnel]. 1394 7.2. PTP: Security and Two-Step Timestamping 1396 PTP supports a two-step mode of operation, where the time of 1397 transmission of protocol packets is communicated without modifying 1398 the packets. As opposed to one-step mode, two-step timestamping can 1399 be performed without the requirement to encrypt after timestamping. 1401 Note that if an encryption mechanism such as IPsec is used, it 1402 presents a challenge to the timestamping mechanism, since time 1403 protocol packets are encrypted when traversing the physical 1404 interface, and are thus impossible to identify. A possible solution 1405 to this problem [IPsecSync] is to include an indication in the 1406 encryption header that identifies time protocol packets. 1408 7.3. Intermediate Clocks 1410 A time protocol allows slaves to receive time information from an 1411 accurate time source. Time information is sent over a path that often 1412 traverses one or more intermediate clocks. 1414 o In NTP, time information originated from a stratum 1 server can be 1415 distributed to stratum 2 servers, and in turn distributed from the 1416 stratum 2 servers to NTP clients. In this case, the stratum 2 1417 servers are a layer of intermediate clocks. These intermediate 1418 clocks are referred to as "secondary servers" in [NTPv4]. 1420 o In PTP, BCs and TCs are intermediate nodes used to improve the 1421 accuracy of time information conveyed between the grandmaster and 1422 the slaves. 1424 A common rule of thumb in network security is that end-to-end 1425 security is the best policy, as it secures the entire path between 1426 the data originator and its receiver. The usage of intermediate nodes 1427 implies that if a security mechanism is deployed in the network, a 1428 hop-by-hop security scheme must be used, since intermediate nodes 1429 must be able to send time information to the slaves, or to modify 1430 time information sent through them. 1432 This inherent property of using intermediate clocks increases the 1433 system's exposure to internal threats, as there is a large number of 1434 nodes that possess the security keys. 1436 Thus, there is a tradeoff between the achievable clock accuracy of a 1437 system, and the robustness of its security solution. On one hand high 1438 clock accuracy calls for hop-by-hop involvement in the protocol, also 1439 known as on-path support. On the other hand, a robust security 1440 solution calls for end-to-end data protection. 1442 7.4. External Security Protocols and Time Protocols 1444 Time protocols are often deployed in systems that use security 1445 mechanisms and protocols. 1447 A typical example is the 3GPP Femtocell network [3GPP], where IPsec 1448 is used for securing traffic between a Femtocell and the Femto 1449 Gateway. In some cases, all traffic between these two nodes may be 1450 secured by IPsec, including the time protocol traffic. This use-case 1451 is thoroughly discussed in [IPsecSync]. 1453 Another typical example is the usage of MACsec encryption ([MACsec]) 1454 in L2 networks that deploy time synchronization [AvbAssum]. 1456 The usage of external security mechanisms may affect time protocols 1457 as follows: 1459 o Timestamping accuracy can be affected, as described in 7.1. 1461 o If traffic is secured between two nodes in the network, no 1462 intermediate clocks can be used between these two nodes. In the 1463 [3GPP] example, if traffic between the Femtocell and the Femto 1464 Gateway is encrypted, then time protocol packets are necessarily 1465 transported over the underlying network without modification, and 1466 thus cannot enjoy the improved accuracy provided by intermediate 1467 clock nodes. 1469 7.5. External Security Services Requiring Time 1471 Cryptographic protocols often use time as an important factor in the 1472 cryptographic algorithm. If a time protocol is compromised, it may 1473 consequently expose the security protocols that rely on it to various 1474 attacks. Two examples are presented in this section. 1476 7.5.1. Timestamped Certificates 1478 Certificate validation requires the sender and receiver to be roughly 1479 time synchronized. Thus, synchronization is required for establishing 1480 security protocols such as IKEv2 and TLS. Other authentication and 1481 key exchange mechanisms, such as Kerberos, also require the parties 1482 involved to be synchronized [Kerb]. 1484 An even stronger interdependence between a time protocol and a 1485 security mechanism is defined in [AutoKey], which defines mutual 1486 dependence between the acquired time information, and the 1487 authentication protocol that secures it. This bootstrapping behavior 1488 results from the fact that trusting the received time information 1489 requires a valid certificate, and validating a certificate requires 1490 knowledge of the time. 1492 7.5.2. Time Changes and Replay Attacks 1494 A successful attack on a time protocol may cause the attacked clocks 1495 to go back in time. The erroneous time may expose cryptographic 1496 algorithms that rely on time, as a node may use a key that was 1497 already used in the past and has expired. 1499 8. Issues for Further Discussion 1501 The Key distribution is outside the scope of this document. Although 1502 this is an essential element of any security system, it is outside 1503 the scope of this document. 1505 9. Security Considerations 1507 The security considerations of network timing protocols are presented 1508 throughout this document. 1510 10. IANA Considerations 1512 There are no new IANA considerations implied by this document. 1514 11. Acknowledgments 1516 The authors gratefully acknowledge Stefano Ruffini, Doug Arnold, 1517 Kevin Gross, Dieter Sibold, Dan Grossman, Laurent Montini, Russell 1518 Smiley, Shawn Emery, Dan Romascanu, Stephen Farrell, Kathleen 1519 Moriarty, and Joel Jaeggli for their thorough review and helpful 1520 comments. The authors would also like to thank members of the TICTOC 1521 WG for providing feedback on the TICTOC mailing list. 1523 This document was prepared using 2-Word-v2.0.template.dot. 1525 12. References 1527 12.1. Normative References 1529 [IEEE1588] IEEE TC 9 Instrumentation and Measurement Society, 1530 "1588 IEEE Standard for a Precision Clock 1531 Synchronization Protocol for Networked Measurement and 1532 Control Systems Version 2", IEEE Standard, 2008. 1534 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1535 Requirement Levels", BCP 14, RFC 2119, March 1997. 1537 [NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W., 1538 "Network Time Protocol Version 4: Protocol and 1539 Algorithms Specification", RFC 5905, June 2010. 1541 12.2. Informative References 1543 [1588IPsec] A. Treytl, B. Hirschler, "Securing IEEE 1588 by IPsec 1544 tunnels - An analysis", in Proceedings of 2010 1545 International Symposium for Precision Clock 1546 Synchronization for Measurement, Control and 1547 Communication, ISPCS 2010, pp. 83-90, 2010. 1549 [3GPP] 3GPP, "Security of Home Node B (HNB) / Home evolved 1550 Node B (HeNB)", 3GPP TS 33.320 10.4.0 (work in 1551 progress), 2011. 1553 [Anatomy] C. Nachreiner, "Anatomy of an ARP Poisoning Attack", 1554 2003. 1556 [AutoKey] Haberman, B., Mills, D., "Network Time Protocol 1557 Version 4: Autokey Specification", RFC 5906, June 1558 2010. 1560 [AvbAssum] D. Pannell, "Audio Video Bridging Gen 2 Assumptions", 1561 IEEE 802.1 AVB Plenary, work in progress, May 2012. 1563 [DelayAtt] T. Mizrahi, "A Game Theoretic Analysis of Delay 1564 Attacks against Time Synchronization Protocols", 1565 accepted, to appear in Proceedings of the 1566 International IEEE Symposium on Precision Clock 1567 Synchronization for Measurement, Control and 1568 Communication, ISPCS, 2012. 1570 [Hack] S. McClure, J. Scambray, G. Kurtz, Kurtz, "Hacking 1571 exposed: network security secrets and solutions", 1572 McGraw-Hill, 2009. 1574 [IPsec] S. Kent, K. Seo, "Security Architecture for the 1575 Internet Protocol", IETF, RFC 4301, 2005. 1577 [IPsecSync] Y. Xu, "IPsec security for packet based 1578 synchronization", IETF, draft-xu-tictoc-ipsec- 1579 security-for-synchronization (work in progress), 2011. 1581 [Kerb] S. Sakane, K. Kamada, M. Thomas, J. Vilhuber, 1582 "Kerberized Internet Negotiation of Keys (KINK)", 1583 2006. 1585 [MACsec] IEEE 802.1AE-2006, "IEEE Standard for Local and 1586 Metropolitan Area Networks - Media Access Control 1587 (MAC) Security", 2006. 1589 [NTPDDoS] "Attackers use NTP reflection in huge DDoS attack", 1590 TICTOC mail archive, 2014. 1592 [SecPTP] J. Tsang, K. Beznosov, "A security analysis of the 1593 precise time protocol (short paper)," 8th 1594 International Conference on Information and 1595 Communication Security (ICICS 2006), pp. 50-59, 2006. 1597 [SecSen] S. Ganeriwal, C. Popper, S. Capkun, M. B. Srivastava, 1598 "Secure Time Synchronization in Sensor Networks", ACM 1599 Trans. Info. and Sys. Sec., Volume 11, Issue 4, July 1600 2008. 1602 [TimeSec] T. Mizrahi, "Time synchronization security using IPsec 1603 and MACsec", ISPCS 2011, pp. 38-43, 2011. 1605 [Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R., 1606 "Traps and pitfalls in secure clock synchronization" 1607 in Proceedings of 2007 International Symposium for 1608 Precision Clock Synchronization for Measurement, 1609 Control and Communication, ISPCS 2007, pp. 18-24, 1610 2007. 1612 [Tunnel] A. Treytl, B. Hirschler, and T. Sauter, "Secure 1613 tunneling of high precision clock synchronisation 1614 protocols and other timestamped data", in Proceedings 1615 of the 8th IEEE International Workshop on Factory 1616 Communication Systems (WFCS), vol. ISBN 978-1-4244- 1617 5461-7, pp. 303-313, 2010. 1619 13. Contributing Authors 1621 Karen O'Donoghue 1622 ISOC 1624 Email: odonoghue@isoc.org 1626 Authors' Addresses 1628 Tal Mizrahi 1629 Marvell 1630 6 Hamada St. 1631 Yokneam, 20692 Israel 1633 Email: talmi@marvell.com