idnits 2.17.1 draft-ietf-tictoc-security-requirements-08.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 == Line 871 has weird spacing: '...equires the...' == Line 873 has weird spacing: '... the packet...' -- The document date (April 30, 2014) is 3648 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TICTOC Working Group Tal Mizrahi 2 Internet Draft Marvell 3 Intended status: Informational 4 Expires: October 2014 April 30, 2014 6 Security Requirements of Time Protocols 7 in Packet Switched Networks 8 draft-ietf-tictoc-security-requirements-08.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 October 30, 2014. 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 ...................... 5 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 ........................................... 8 75 3.2.3. Replay Attack ...................................... 9 76 3.2.4. Rogue Master Attack ................................ 9 77 3.2.5. Packet Interception and Removal .................... 9 78 3.2.6. Packet Delay Manipulation .......................... 9 79 3.2.7. L2/L3 DoS Attacks .................................. 9 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) . 10 83 3.3. Threat Analysis Summary ................................ 10 84 4. Requirement Levels .......................................... 12 85 5. Security Requirements ....................................... 13 86 5.1. Clock Identity Authentication and Authorization ........ 13 87 5.1.1. Authentication and Authorization of Masters ....... 14 88 5.1.2. Recursive Authentication and Authorization of Masters 89 (Chain of Trust) ......................................... 15 90 5.1.3. Authentication and Authorization of Slaves ........ 15 91 5.1.4. PTP: Authentication and Authorization of P2P TCs by the 92 Master ................................................... 16 93 5.1.5. PTP: Authentication and Authorization of Control 94 Messages ................................................. 17 95 5.2. Protocol Packet Integrity .............................. 18 96 5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 19 97 5.2.1.1. Hop-by-Hop Integrity Protection .............. 19 98 5.2.1.2. End-to-End Integrity Protection .............. 19 99 5.3. Spoofing Prevention .................................... 20 100 5.4. Availability ........................................... 20 101 5.5. Replay Protection ...................................... 21 102 5.6. Cryptographic Keys and Security Associations ........... 22 103 5.6.1. Key Freshness ..................................... 22 104 5.6.2. Security Association .............................. 22 105 5.6.3. Unicast and Multicast Associations ................ 23 106 5.7. Performance ............................................ 23 107 5.8. Confidentiality......................................... 24 108 5.9. Protection against Packet Delay and Interception Attacks 25 109 5.10. Combining Secured with Unsecured Nodes ................ 25 110 5.10.1. Secure Mode ...................................... 26 111 5.10.2. Hybrid Mode ...................................... 26 112 6. Summary of Requirements ..................................... 27 113 7. Additional security implications ............................ 29 114 7.1. Security and on-the-fly Timestamping ................... 29 115 7.2. PTP: Security and Two-Step Timestamping ................ 29 116 7.3. Intermediate Clocks .................................... 30 117 7.4. External Security Protocols and Time Protocols.......... 30 118 7.5. External Security Services Requiring Time .............. 31 119 7.5.1. Timestamped Certificates .......................... 31 120 7.5.2. Time Changes and Replay Attacks ................... 31 121 8. Issues for Further Discussion ............................... 31 122 9. Security Considerations ..................................... 32 123 10. IANA Considerations......................................... 32 124 11. Acknowledgments ............................................ 32 125 12. References ................................................. 32 126 12.1. Normative References .................................. 32 127 12.2. Informative References ................................ 32 128 13. Contributing Authors ....................................... 34 130 1. Introduction 132 As time protocols are becoming increasingly common and widely 133 deployed, concern about the resulting exposure to various security 134 threats is increasing. If a time protocol is compromised, the 135 applications it serves are prone to a range of possible attacks 136 including Denial-of-Service (DoS) or incorrect behavior. 138 This document focuses on the security aspects of the Precision Time 139 Protocol (PTP) [IEEE1588] and the Network Time Protocol [NTPv4]. The 140 Network Time Protocol was defined with an inherent security protocol, 141 defined in [NTPv4] and in [AutoKey]. [IEEE1588] includes an 142 experimental security protocol, defined in Annex K of the standard, 143 but this Annex was never formalized into a fully defined security 144 protocol. 146 While NTP includes an inherent security protocol, the absence of a 147 standard security solution for PTP undoubtedly contributed to the 148 wide deployment of unsecured time synchronization solutions. However, 149 in some cases security mechanisms may not be strictly necessary, 150 e.g., due to other security practices in place, or due to the 151 architecture of the network. A time synchronization security 152 solution, much like any security solution, is comprised of various 153 building blocks, and must be carefully tailored for the specific 154 system it is deployed in. Based on a system-specific threat 155 assessment, the benefits of a security solution must be weighed 156 against the potential risks, and based on this tradeoff an optimal 157 security solution can be selected. 159 The target audience of this document includes: 161 o Timing and networking equipment vendors - can benefit from this 162 document by deriving the security features that should be 163 supported in the time/networking equipment. 165 o Standard development organizations - can use the requirements 166 defined in this document when specifying security mechanisms for a 167 time protocol. 169 o Network operators - can use this document as a reference when 170 designing the network and its security architecture. As stated 171 above, the requirements in this document may be deployed 172 selectively based on a careful per-system threat analysis. 174 This document attempts to add clarity to the time protocol security 175 requirements discussion by addressing a series of questions: 177 (1) What are the threats that need to be addressed for the time 178 protocol, and thus what security services need to be provided? (e.g. 179 a malicious NTP server or PTP master) 181 (2) What external security practices impact the security and 182 performance of time keeping, and what can be done to mitigate these 183 impacts? (e.g. an IPsec tunnel in the time protocol traffic path) 184 (3) What are the security impacts of time protocol practices? (e.g. 185 on-the-fly modification of timestamps) 187 (4) What are the dependencies between other security services and 188 time protocols? (e.g. which comes first - the certificate or the 189 timestamp?) 191 In light of the questions above, this document defines a set of 192 requirements for security solutions for time protocols, focusing on 193 PTP and NTP. 195 2. Conventions Used in this Document 197 2.1. Terminology 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 201 document are to be interpreted as described in [KEYWORDS]. 203 This document describes security requirements, and thus requirements 204 are phrased in the document in the form "the security mechanism 205 MUST/SHOULD/...". Note, that the phrasing does not imply that this 206 document defines a specific security mechanism, but defines the 207 requirements with which every security mechanism should comply. 209 2.2. Abbreviations 211 BC Boundary Clock [IEEE1588] 213 DoS Denial of Service 215 MITM Man In The Middle 217 NTP Network Time Protocol [NTPv4] 219 OC Ordinary Clock [IEEE1588] 221 P2P TC Peer-to-Peer Transparent Clock [IEEE1588] 223 PTP Precision Time Protocol [IEEE1588] 225 TC Transparent Clock [IEEE1588] 227 2.3. Common Terminology for PTP and NTP 229 This document refers to both PTP and NTP. For the sake of 230 consistency, throughout the document the term "master" applies to 231 both a PTP master and an NTP server. Similarly, the term "slave" 232 applies to both PTP slaves and NTP clients. The term "protocol 233 packets" refers generically to PTP and NTP messages. 235 2.4. Terms used in this Document 237 o Clock - A node participating in the protocol (either PTP or NTP). 238 A clock can be a master, a slave, or an intermediate clock (see 239 corresponding definitions below). 241 o Control packets - Packets used by the protocol to exchange 242 information between clocks that is not strictly related to the 243 time. NTP uses NTP Control Messages. PTP uses Announce, Signaling 244 and Management messages. 246 o End-to-end security - A security approach where secured packets 247 sent from a source to a destination is not modified by 248 intermediate nodes. 250 o Grandmaster - A master that receives time information from a 251 locally attached clock device, and not through the network. A 252 grandmaster distributes its time to other clocks in the network. 254 o Hop-by-hop security - A security approach where secured packets 255 sent from a source to a destination may be modified by 256 intermediate nodes. In this approach intermediate nodes share the 257 encryption key with the source and destination, allowing them to 258 re-encrypt or re-authenticate modified packets before relaying 259 them to the destination. 261 o Intermediate clock - A clock that receives timing information from 262 a master, and sends timing information to other clocks. 263 In NTP this term refers to an NTP server that is not a Stratum 1 264 server. In PTP this term refers to a BC or a TC. 266 o Master - A clock that generates timing information to other clocks 267 in the network. 268 In NTP 'master' refers to an NTP server. In PTP 'master' refers to 269 a master OC (aka grandmaster) or to a port of a BC that is in the 270 master state. 272 o Protocol packets - Packets used by the time protocol. The 273 terminology used in this document distinguishes between time 274 packets and control packets. 276 o Secured clock - A clock that supports a security mechanism that 277 complies to the requirements in this document. 279 o Slave - A clock that receives timing information from a master. In 280 NTP 'slave' refers to an NTP client. In PTP 'slave' refers to a 281 slave OC, or to a port of a BC that is in the slave state. 283 o Time packets - Protocol packets carrying time information. 285 o Unsecured clock - A clock that does not support a security 286 mechanism according to the requirements in this document. 288 3. Security Threats 290 This section discusses the possible attacker types and analyzes 291 various attacks against time protocols. 293 The literature is rich with security threats of time protocols, e.g., 294 [Traps], [AutoKey], [TM], [SecPTP], and [SecSen]. The threat analysis 295 in this document is mostly based on [TM]. 297 3.1. Threat Model 299 A time protocol can be attacked by various types of attackers. 301 The analysis in this document classifies attackers according to 2 302 criteria, as described in Section 3.1.1. and Section 3.1.2. 304 3.1.1. Internal vs. External Attackers 306 In the context of internal and external attackers, the underlying 307 assumption is that the time protocol is secured either by an 308 encryption or an authentication mechanism, or both. 310 Internal attackers either have access to a trusted segment of the 311 network, or possess the encryption or authentication keys. An 312 internal attack can also be performed by exploiting vulnerabilities 313 in devices; for example, by installing malware, or obtaining 314 credentials to reconfigure the device. Thus, an internal attacker can 315 maliciously tamper with legitimate traffic in the network, as well as 316 generate its own traffic and make it appear legitimate to its 317 attacked nodes. 319 External attackers, on the other hand, do not have the keys, and have 320 access only to the encrypted or authenticated traffic. 322 Obviously, in the absence of a security mechanism there is no 323 distinction between internal and external attackers, since all 324 attackers are internal in practice. 326 3.1.2. Man in the Middle (MITM) vs. Packet Injector 328 MITM attackers are located in a position that allows interception and 329 modification of in-flight protocol packets. It is assumed that an 330 MITM attacker has physical access to a segment of the network, or has 331 gained control of one of the nodes in the network. 333 A traffic injector is not located in an MITM position, but can attack 334 by generating protocol packets. An injector can reside either within 335 the attacked network, or on an external network that is connected to 336 the attacked network. An injector can also potentially eavesdrop on 337 protocol packets sent as multicast, record them and replay them 338 later. 340 3.2. Threat Analysis 342 3.2.1. Packet Manipulation 344 A packet manipulation attack results when an MITM attacker receives 345 timing protocol packets, alters them and relays them to their 346 destination, allowing the attacker to maliciously tamper with the 347 protocol. This can result in a situation where the time protocol is 348 apparently operational but providing intentionally inaccurate 349 information. 351 3.2.2. Spoofing 353 In spoofing, an injector masquerades as a legitimate node in the 354 network by generating and transmitting protocol packets or control 355 packets. Two typical examples of spoofing attacks: 357 o An attacker can impersonate the master, allowing malicious 358 distribution of false timing information. 360 o An attacker can impersonate a legitimate clock, a slave or an 361 intermediate clock, by sending malicious messages to the master, 362 causing the master to respond to the legitimate clock with 363 protocol packets that are based on the spoofed messages. 364 Consequently, the delay computations of the legitimate clock are 365 based on false information. 367 As with packet manipulation, this attack can result in a situation 368 where the time protocol is apparently operational but providing 369 intentionally inaccurate information. 371 3.2.3. Replay Attack 373 In a replay attack, an attacker records protocol packets and replays 374 them at a later time without any modification. This can also result 375 in a situation where the time protocol is apparently operational but 376 providing intentionally inaccurate information. 378 3.2.4. Rogue Master Attack 380 In a rogue master attack, an attacker causes other nodes in the 381 network to believe it is a legitimate master. As opposed to the 382 spoofing attack, in the Rogue Master attack the attacker does not 383 fake its identity, but rather manipulates the master election process 384 using malicious control packets. For example, in PTP, an attacker can 385 manipulate the Best Master Clock Algorithm (BMCA), and cause other 386 nodes in the network to believe it is the most eligible candidate to 387 be a grandmaster. 389 In PTP, a possible variant of this attack is the rogue TC/BC attack. 390 Similar to the rogue master attack, an attacker can cause victims to 391 believe it is a legitimate TC or BC, allowing the attacker to 392 manipulate the time information forwarded to the victims. 394 3.2.5. Packet Interception and Removal 396 A packet interception and removal attack results when an MITM 397 attacker intercepts and drops protocol packets, preventing the 398 destination node from receiving some or all of the protocol packets. 400 3.2.6. Packet Delay Manipulation 402 In a packet delay manipulation scenario, an MITM attacker receives 403 protocol packets, and relays them to their destination after adding a 404 maliciously computed delay. The attacker can use various delay attack 405 strategies; the added delay can be constant, jittered, or slowly 406 wandering. Each of these strategies has a different impact, but they 407 all effectively manipulate the attacked clock. 409 Note that the victim still receives one copy of each packet, contrary 410 to the replay attack, where some or all of the packets may be 411 received by the victim more than once. 413 3.2.7. L2/L3 DoS Attacks 415 There are many possible Layer 2 and Layer 3 DoS attacks. As the 416 target's availability is compromised, the timing protocol is affected 417 accordingly. 419 3.2.8. Cryptographic Performance Attacks 421 In cryptographic performance attacks, an attacker transmits fake 422 protocol packets, causing high utilization of the cryptographic 423 engine at the receiver, which attempts to verify the integrity of 424 these fake packets. 426 This DoS attack is applicable to all encryption and authentication 427 protocols. However, when the time protocol uses a dedicated security 428 mechanism implemented in a dedicated cryptographic engine, this 429 attack can be applied to cause DoS specifically to the time protocol 431 3.2.9. DoS Attacks against the Time Protocol 433 An attacker can attack a clock by sending an excessive number of time 434 protocol packets, thus degrading the victim's performance. This 435 attack can be implemented, for example, using the attacks described 436 in Section 3.2.2. and Section 3.2.4. 438 3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud) 440 Grandmasters receive their time from an external accurate time 441 source, such as an atomic clock or a GPS clock, and then distribute 442 this time to the slaves using the time protocol. 444 Time source attack are aimed at the accurate time source of the 445 grandmaster. For example, if the grandmaster uses a GPS based clock 446 as its reference source, an attacker can jam the reception of the GPS 447 signal, or transmit a signal similar to one from a GPS satellite, 448 causing the grandmaster to use a false reference time. 450 Note that this attack is outside the scope of the time protocol. 451 While various security measures can be taken to mitigate this attack, 452 these measures are outside the scope of the security requirements 453 defined in this document. 455 3.3. Threat Analysis Summary 457 The two key factors to a threat analysis are the impact and the 458 likelihood of each of the analyzed attacks. 460 Table 1 summarizes the security attacks presented in Section 3.2. 461 For each attack, the table specifies its impact, and its 462 applicability to each of the attacker types presented in Section 3.1. 464 Table 1 clearly shows the distinction between external and internal 465 attackers, and motivates the usage of authentication and integrity 466 protection, significantly reducing the impact of external attackers. 468 The Impact column provides an intuitive measure of the severity of 469 each attack, and the relevant Attacker Type columns provide an 470 intuition about how difficult each attack is to implement, and hence 471 about the likelihood of each attack. 473 The impact column in Table 1 can have one of 3 values: 475 o DoS - the attack causes denial of service to the attacked node, 476 the impact of which is not restricted to the time protocol. 478 o Accuracy degradation - the attack yields a degradation in the 479 slave accuracy, but does not completely compromise the slaves' 480 time and frequency. 482 o False time - slaves align to a false time or frequency value due 483 to the attack. Note that if the time protocol aligns to a false 484 time, it may cause DoS to other applications that rely on accurate 485 time. However, for the purpose of the analysis in this section we 486 distinguish this implication from 'DoS', which refers to a DoS 487 attack that is not necessarily aimed at the time protocol. 488 All attacks that have a '+' for 'False Time' implicitly have a '+' 489 for 'Accuracy Degradation'. 491 The Attacker Type columns refer to the 4 possible combinations of the 492 attacker types defined in Section 3.1. 494 +-----------------------------+-------------------++-------------------+ 495 | Attack | Impact || Attacker Type | 496 | +-----+--------+----++---------+---------+ 497 | |False|Accuracy| ||Internal |External | 498 | |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.| 499 +-----------------------------+-----+--------+----++----+----+----+----+ 500 |Manipulation | + | | || + | | | | 501 +-----------------------------+-----+--------+----++----+----+----+----+ 502 |Spoofing | + | | || + | + | | | 503 +-----------------------------+-----+--------+----++----+----+----+----+ 504 |Replay attack | + | | || + | + | | | 505 +-----------------------------+-----+--------+----++----+----+----+----+ 506 |Rogue master attack | + | | || + | + | | | 507 +-----------------------------+-----+--------+----++----+----+----+----+ 508 |Interception and removal | | + | + || + | | + | | 509 +-----------------------------+-----+--------+----++----+----+----+----+ 510 |Packet delay manipulation | + | | || + | | + | | 511 +-----------------------------+-----+--------+----++----+----+----+----+ 512 |L2/L3 DoS attacks | | | + || + | + | + | + | 513 +-----------------------------+-----+--------+----++----+----+----+----+ 514 |Crypt. performance attacks | | | + || + | + | + | + | 515 +-----------------------------+-----+--------+----++----+----+----+----+ 516 |Time protocol DoS attacks | | | + || + | + | | | 517 +-----------------------------+-----+--------+----++----+----+----+----+ 518 |Master time source attack | + | | || + | + | + | + | 519 |(e.g., GPS spoofing) | | | || | | | | 520 +-----------------------------+-----+--------+----++----+----+----+----+ 521 Table 1 Threat Analysis - Summary 523 The threats discussed in this section provide the background for the 524 security requirements presented in Section 5. 526 4. Requirement Levels 528 The security requirements are presented in Section 5. Each 529 requirement is defined with a requirement level, in accordance with 530 the requirement levels defined in Section 2.1. 532 The requirement levels in this document are affected by the following 533 factors: 535 o Impact: 536 The possible impact of not implementing the requirement, as 537 illustrated in the 'impact' column of Table 1. 538 For example, a requirement that addresses a threat that can be 539 implemented by an external injector is typically a 'MUST', since 540 the threat can be implemented by all the attacker types analyzed 541 in Section 3.1. 543 o Difficulty of the corresponding attack: 544 The level of difficulty of the possible attacks that become 545 possible by not implementing the requirement. The level of 546 difficulty is reflected in the 'Attacker Type' column of Table 1. 547 For example, a requirement that addresses a threat that only 548 compromises the availability of the protocol is typically no more 549 than a 'SHOULD'. 551 o Practical considerations: 552 Various practical factors that may affect the requirement. 553 For example, if a requirement is very difficult to implement, or 554 is applicable to very specific scenarios, these factors may reduce 555 the requirement level. 557 Section 5. lists the requirements. For each requirement there is a 558 short explanation detailing the reason for its requirement level. 560 5. Security Requirements 562 This section defines a set of security requirements. These 563 requirements are phrased in the form "the security mechanism 564 MUST/SHOULD/MAY...". However, this document does not specify how 565 these requirements can be met. While these requirements can be 566 satisfied by defining explicit security mechanisms for time 567 protocols, at least a subset of the requirements can be met by 568 applying common security practices to the network or by using 569 existing security protocols, such as [IPsec] or [MACsec]. Thus, 570 security solutions that address these requirements are outside the 571 scope of this document. 573 5.1. Clock Identity Authentication and Authorization 575 Requirement 577 The security mechanism MUST support authentication. 579 Requirement 581 The security mechanism MUST support authorization. 583 Requirement Level 585 The requirements in this subsection address the spoofing attack 586 (Section 3.2.2.), and the rogue master attack (Section 3.2.4.). 588 The requirement level of these requirements is 'MUST' since in the 589 absence of these requirements the protocol is exposed to attacks that 590 are easy to implement and have a high impact. 592 Discussion 594 Authentication refers to verifying the identity of the peer clock. 595 Authorization, on the other hand, refers to verifying that the peer 596 clock is permitted to play the role that it plays in the protocol. 598 For example, some nodes may be permitted to be masters, while other 599 nodes are only permitted to be slaves or TCs. 601 Authorization requires clocks to maintain a list of authorized 602 clocks, or a "black list" of clocks that should be denied service or 603 revoked. 605 It is noted that while the security mechanism is required to provide 606 an authorization mechanism, the deployment of such a mechanism 607 depends on the nature of the network. For example, a network that 608 deploys PTP may consist of a set of identical OCs, where all clocks 609 are equally permitted to be a master. In such a network an 610 authorization mechanism may not be necessary. 612 The following subsections describe 5 distinct cases of clock 613 authentication. 615 5.1.1. Authentication and Authorization of Masters 617 Requirement 619 The security mechanism MUST support an authentication mechanism, 620 allowing slaves to authenticate the identity of masters. 622 Requirement 624 The authentication mechanism MUST allow slaves to verify that the 625 authenticated master is authorized to be a master. 627 Requirement Level 629 The requirements in this subsection address the spoofing attack 630 (Section 3.2.2.), and the rogue master attack (Section 3.2.4.). 632 The requirement level of these requirements is 'MUST' since in the 633 absence of these requirements the protocol is exposed to attacks that 634 are easy to implement and have a high impact. 636 Discussion 638 Clocks authenticate masters in order to ensure the authenticity of 639 the time source. It is important for a slave to verify the identity 640 of the master, as well as to verify that the master is indeed 641 authorized to be a master. 643 5.1.2. Recursive Authentication and Authorization of Masters (Chain of 644 Trust) 646 Requirement 648 The security mechanism MUST support recursive authentication and 649 authorization of the master, to be used in cases where time 650 information is conveyed through intermediate clocks. 652 Requirement Level 654 The requirement in this subsection addresses the spoofing attack 655 (Section 3.2.2.), and the rogue master attack (Section 3.2.4.). 657 The requirement level of this requirement is 'MUST' since in the 658 absence of this requirement the protocol is exposed to attacks that 659 are easy to implement and have a high impact. 661 Discussion 663 In some cases a slave is connected to an intermediate clock, that is 664 not the primary time source. For example, in PTP a slave can be 665 connected to a Boundary Clock (BC) or a Transparent Clock (TC), which 666 in turn is connected to a grandmaster. A similar example in NTP is 667 when a client is connected to a stratum 2 server, which is connected 668 to a stratum 1 server. In both the PTP and the NTP cases, the slave 669 authenticates the intermediate clock, and the intermediate clock 670 authenticates the grandmaster. This recursive authentication process 671 is referred to in [AutoKey] as proventication. 673 Specifically in PTP, this requirement implies that if a slave 674 receives time information through a TC, it must authenticate the TC 675 it is attached to, as well as authenticate the master it receives the 676 time information from, as per Section 5.1.1. Similarly, if a TC 677 receives time information through an attached TC, it must 678 authenticate the attached TC. 680 5.1.3. Authentication and Authorization of Slaves 682 Requirement 684 The security mechanism MAY provide a means for a master to 685 authenticate its slaves. 687 Requirement 688 The security mechanism MAY provide a means for a master to verify 689 that the sender of a protocol packet is authorized to send a packet 690 of this type. 692 Requirement Level 694 The requirement in this subsection prevents DoS attacks against the 695 master (Section 3.2.9.). 697 The requirement level of this requirement is 'MAY' since: 699 o Its low impact, i.e., in the absence of this requirement the 700 protocol is only exposed to DoS. 702 o Practical considerations: requiring an NTP server to authenticate 703 its clients may significantly impose on the server's performance. 705 Note that while the requirement level of this requirement is 'MAY', 706 the requirement in Section 5.1.1. is 'MUST'; the security mechanism 707 must provide a means for authentication and authorization, with an 708 emphasis on the master. Authentication and authorization of slaves is 709 specified in this subsection as 'MAY'. 711 Discussion 713 Slaves and intermediate clocks are authenticated by masters in order 714 to verify that they are authorized to receive timing services from 715 the master. 717 Authentication of slaves prevents unauthorized clocks from receiving 718 time services. Preventing the master from serving unauthorized clocks 719 can help in mitigating DoS attacks against the master. Note that the 720 authentication of slaves might put a higher load on the master than 721 serving the unauthorized clock, and hence this requirement is a MAY. 723 5.1.4. PTP: Authentication and Authorization of P2P TCs by the Master 725 Requirement 727 The security mechanism for PTP MAY provide a means for a master to 728 authenticate the identity of the P2P TCs directly connected to it. 730 Requirement 732 The security mechanism for PTP MAY provide a means for a master to 733 verify that P2P TCs directly connected to it are authorized to be 734 TCs. 736 Requirement Level 738 The requirement in this subsection prevents DoS attacks against the 739 master (Section 3.2.9.). 741 The requirement level of this requirement is 'MAY' for the same 742 reasons specified in Section 5.1.3. 744 Discussion 746 P2P TCs that are one hop from the master use the PDelay_Req and 747 PDelay_Resp handshake to compute the link delay between the master 748 and TC. These TCs are authenticated by the master. 750 Authentication of TCs, much like authentication of slaves, reduces 751 unnecessary load on the master and peer TCs, by preventing the master 752 from serving unauthorized clocks. 754 5.1.5. PTP: Authentication and Authorization of Control Messages 756 Requirement 758 The security mechanism for PTP MUST support authentication of 759 Announce messages. The authentication mechanism MUST also verify that 760 the sender is authorized to be a master. 762 Requirement 764 The security mechanism for PTP MUST support authentication and 765 authorization of Management messages. 767 Requirement 769 The security mechanism MAY support authentication and authorization 770 of Signaling messages. 772 Requirement Level 774 The requirements in this subsection address the spoofing attack 775 (Section 3.2.2.), and the rogue master attack (Section 3.2.4.). 777 The requirement level of the first two requirements is 'MUST' since 778 in the absence of these requirements the protocol is exposed to 779 attacks that are easy to implement and have a high impact. 781 The requirement level of the third requirement is 'MAY' since its 782 impact greatly depends on the application for which the Signaling 783 messages are used for. 785 Discussion 787 Master election is performed in PTP using the Best Master Clock 788 Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock 789 attributes using Announce messages, and the best master is elected 790 based on the information gathered from all the candidates. Announce 791 messages must be authenticated in order to prevent rogue master 792 attacks (Section 3.2.4.). Note, that this subsection specifies a 793 requirement that is not necessarily included in Section 5.1.1. or in 794 Section 5.1.3. , since the BMCA is initiated before clocks have been 795 defined as masters or slaves. 797 Management messages are used to monitor or configure PTP clocks. 798 Malicious usage of Management messages enables various attacks, such 799 as the rogue master attack, or DoS attack. 801 Signaling messages are used by PTP clocks to exchange information 802 that is not strictly related to time information or to master 803 selection, such as unicast negotiation. Authentication and 804 authorization of Signaling message may be required in some systems, 805 depending on the application these messages are used for. 807 5.2. Protocol Packet Integrity 809 Requirement 811 The security mechanism MUST protect the integrity of protocol 812 packets. 814 Requirement Level 816 The requirement in this subsection addresses the packet manipulation 817 attack (Section 3.2.1.). 819 The requirement level of this requirement is 'MUST' since in the 820 absence of this requirement the protocol is exposed to attacks that 821 are easy to implement and have high impact. 823 Discussion 825 While Section 5.1. refers to ensuring the identity an authorization 826 of the source of a protocol packet, this subsection refers to 827 ensuring that the packet arrived intact. The integrity protection 828 mechanism ensures the authenticity and completeness of data from the 829 data originator. 831 5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 833 Specifically in PTP, when protocol packets are subject to 834 modification by TCs, the integrity protection can be enforced in one 835 of two approaches, end-to-end or hop-by-hop. 837 5.2.1.1. Hop-by-Hop Integrity Protection 839 Each hop that needs to modify a protocol packet: 841 o Verifies its integrity. 843 o Modifies the packet, i.e., modifies the correctionField. 844 Note: Transparent Clocks (TCs) improve the end-to-end accuracy by 845 updating a "correctionField" (clause 6.5 in [IEEE1588]) in the PTP 846 packet by adding the latency caused by the current TC. 848 o Re-generates the integrity protection, e.g., re-computes a Message 849 Authentication Code. 851 In the hop-by-hop approach, the integrity of protocol packets is 852 protected by induction on the path from the originator to the 853 receiver. 855 This approach is simple, but allows rogue TCs to modify protocol 856 packets. 858 5.2.1.2. End-to-End Integrity Protection 860 In this approach, the integrity protection is maintained on the path 861 from the originator of a protocol packet to the receiver. This allows 862 the receiver to directly validate the protocol packet without the 863 ability of intermediate TCs to manipulate the packet. 865 Since TCs need to modify the correctionField, a separate integrity 866 protection mechanism is used specifically for the correctionField. 868 The end-to-end approach limits the TC's impact to the correctionField 869 alone, while the rest of the protocol packet is protected on an end- 870 to-end basis. It should be noted that this approach is more difficult 871 to implement than the hop-by-hop approach, as it requires the 872 correctionField to be protected separately from the other fields of 873 the packet, possibly using different cryptographic mechanisms and 874 keys. 876 5.3. Spoofing Prevention 878 Requirement 880 The security mechanism MUST provide a means to prevent master 881 spoofing. 883 Requirement 885 The security mechanism MUST provide a means to prevent slave 886 spoofing. 888 Requirement 890 PTP: The security mechanism MUST provide a means to prevent P2P TC 891 spoofing. 893 Requirement Level 895 The requirements in this subsection address spoofing attacks (Section 896 3.2.2.). As described in Section 3.2.2. , when these requirements 897 are not met, the attack may have a high impact, causing slaves to 898 rely on false time information. Thus, the requirement level is 899 'MUST'. 901 Discussion 903 Spoofing attacks may take various different forms, and can 904 potentially cause significant impact. In a master spoofing attack, 905 the attacker causes slaves to receive false information about the 906 current time by masquerading as the master. 908 By spoofing a slave or an intermediate node (the second example of 909 Section 3.2.2.), an attacker can tamper with slaves' delay 910 computations. These attacks can be mitigated by an authentication 911 mechanism (Section 5.1.3. and 5.1.4.), or by other means, for 912 example, a PTP Delay_Req can include a Message Authentication Code 913 (MAC) that is included in the corresponding Delay_Resp message, 914 allowing the slave to verify that the Delay_Resp was not sent in 915 response to a spoofed message. 917 5.4. Availability 919 Requirement 921 The security mechanism SHOULD include measures to mitigate DoS 922 attacks against the time protocol. 924 Requirement Level 926 The requirement in this subsection prevents DoS attacks against the 927 protocol (Section 3.2.9.). 929 The requirement level of this requirement is 'SHOULD' due to its low 930 impact, i.e., in the absence of this requirement the protocol is only 931 exposed to DoS. 933 Discussion 935 The protocol availability can be compromised by several different 936 attacks. 938 An attacker can inject protocol packets to implement the spoofing 939 attack (Section 3.2.2.) or the rogue master attack (Section 3.2.4. 940 ), causing DoS to the victim (Section 3.2.9.). An authentication 941 mechanism (Section 5.1.) limits these attacks strictly to internal 942 attackers, and thus prevents external attackers from performing them. 944 The DoS attacks described in Section 3.2.7. are performed at lower 945 layers than the time protocol layer, and are thus outside the scope 946 of the security requirements defined in this document. 948 5.5. Replay Protection 950 Requirement 952 The security mechanism MUST include a replay prevention mechanism. 954 Requirement Level 956 The requirement in this subsection prevents replay attacks (Section 957 3.2.3.). 959 The requirement level of this requirement is 'MUST' since in the 960 absence of this requirement the protocol is exposed to attacks that 961 are easy to implement and have a high impact. 963 Discussion 965 The replay attack (Section 3.2.3.) can compromise both the integrity 966 and availability of the protocol. Common encryption and 967 authentication mechanisms include replay prevention mechanisms that 968 typically use a monotonously increasing packet sequence number. 970 5.6. Cryptographic Keys and Security Associations 972 5.6.1. Key Freshness 974 Requirement 976 The cryptographic keys MUST be refreshed frequently. 978 Requirement Level 980 The requirement level of this requirement is 'MUST' since key 981 freshness is an essential property for cryptographic algorithms, as 982 discussed below. 984 Discussion 986 Key freshness guarantees that both sides share a common updated 987 secret key. It also helps in preventing replay attacks. Thus, it is 988 important for keys to be refreshed frequently. 990 5.6.2. Security Association 992 Requirement 994 The security protocol SHOULD support an association protocol where: 996 o Two or more clocks authenticate each other. 998 o The clocks generate and agree on a cryptographic session key. 1000 Requirement 1002 Each instance of the association protocol SHOULD produce a different 1003 session key. 1005 Requirement Level 1007 The requirement level of this requirement is 'SHOULD' since it may be 1008 expensive in terms of performance, especially in low-cost clocks. 1010 Discussion 1012 The security requirements in Section 5.1. and Section 5.2. require 1013 usage of cryptographic mechanisms, deploying cryptographic keys. A 1014 security association is an important building block in these 1015 mechanisms. 1017 5.6.3. Unicast and Multicast Associations 1019 Requirement 1021 The security mechanism SHOULD support security association protocols 1022 for unicast and for multicast associations. 1024 Requirement Level 1026 The requirement level of this requirement is 'SHOULD' since it may be 1027 expensive in terms of performance, especially for low-cost clocks. 1029 Discussion 1031 A unicast protocol requires an association protocol between two 1032 clocks, whereas a multicast protocol requires an association protocol 1033 among two or more clocks, where one of the clocks is a master. 1035 5.7. Performance 1037 Requirement 1039 The security mechanism MUST be designed in such a way that it does 1040 not significantly degrade the quality of the time transfer. 1042 Requirement 1044 The mechanism SHOULD minimize computational load. 1046 Requirement 1048 The mechanism SHOULD minimize storage requirements of client state in 1049 the master. 1051 Requirement 1053 The mechanism SHOULD minimize the bandwidth overhead required by the 1054 security protocol. 1056 Requirement Level 1058 While the quality of the time transfer is clearly a 'MUST', the other 1059 3 performance requirements are 'SHOULD', since some systems may be 1060 more sensitive to resource consumption than others, and hence these 1061 requirements should be considered on a per-system basis. 1063 Discussion 1064 Performance efficiency is important since client restrictions often 1065 dictate a low processing and memory footprint, and because the server 1066 may have extensive fan-out. 1068 Note that the performance requirements refer to a time-protocol- 1069 specific security mechanism. In systems where a security protocol is 1070 used for other types of traffic as well, this document does not place 1071 any performance requirements on the security protocol performance. 1072 For example, if IPsec encryption is used for securing all information 1073 between the master and slave node, including information that is not 1074 part of the time protocol, the requirements in this subsection are 1075 not necessarily applicable. 1077 5.8. Confidentiality 1079 Requirement 1081 The security mechanism MAY provide confidentiality protection of the 1082 protocol packets. 1084 Requirement Level 1086 The requirement level of this requirement is 'MAY' since it does not 1087 prevent severe threats, as discussed below. 1089 Discussion 1091 In the context of time protocols, confidentiality is typically of low 1092 importance, since timing information is typically not considered 1093 secret information. 1095 Confidentiality can play an important role when service providers 1096 charge their customers for time synchronization services, and thus an 1097 encryption mechanism can prevent eavesdroppers from obtaining the 1098 service without payment. Note that these cases are, for now, rather 1099 esoteric. 1101 Confidentiality can also prevent an MITM attacker from identifying 1102 protocol packets. Thus, confidentiality can assist in protecting the 1103 timing protocol against MITM attacks such as packet delay (Section 1104 3.2.6.), manipulation and interception and removal attacks. Note, 1105 that time protocols have predictable behavior even after encryption, 1106 such as packet transmission rates and packet lengths. Additional 1107 measures can be taken to mitigate encrypted traffic analysis by 1108 random padding of encrypted packets and by adding random dummy 1109 packets. Nevertheless, encryption does not prevent such MITM attacks, 1110 but rather makes these attacks more difficult to implement. 1112 5.9. Protection against Packet Delay and Interception Attacks 1114 Requirement 1116 The security mechanism MUST include means to protect the protocol 1117 from MITM attacks that degrade the clock accuracy. 1119 Requirement Level 1121 The requirements in this subsection address MITM attacks such as the 1122 packet delay attack (Section 3.2.6.) and packet interception attacks 1123 (Section 3.2.5. and Section 3.2.1.). 1125 The requirement level of this requirement is 'MUST'. In the absence 1126 of this requirement the protocol is exposed to attacks that are easy 1127 to implement and have a high impact. Note that in the absence of this 1128 requirement, the impact is similar to packet manipulation attacks 1129 (Section 3.2.1.), and thus this requirement has the same requirement 1130 level as integrity protection (Section 5.2.). 1132 It is noted that the implementation of this requirement depends on 1133 the topology and properties of the system. 1135 Discussion 1137 While this document does not define specific security solutions, we 1138 note that common practices for protection against MITM attacks use 1139 redundant masters (e.g. [NTPv4]), or redundant paths between the 1140 master and slave (e.g. [DelayAtt]). If one of the time sources 1141 indicates a time value that is significantly different than the other 1142 sources, it is assumed to be erroneous or under attack, and is 1143 therefore ignored. 1145 Thus, MITM attack prevention derives a requirement from the security 1146 mechanism, and a requirement from the network topology. While the 1147 security mechanism should support the ability to detect delay 1148 attacks, it is noted that in some networks it is not possible to 1149 provide the redundancy needed for such a detection mechanism. 1151 5.10. Combining Secured with Unsecured Nodes 1153 Integrating a security mechanism into a time synchronized system is a 1154 complex and expensive process, and hence in some cases may require 1155 incremental deployment, where new equipment supports the security 1156 mechanism, and is required to interoperate with legacy equipment 1157 without the security features. 1159 5.10.1. Secure Mode 1161 Requirement 1163 The security mechanism MUST support a secure mode, where only secured 1164 clocks are permitted to take part in the time protocol. In this mode 1165 every protocol packet received from an unsecured clock MUST be 1166 discarded. 1168 Requirement Level 1170 The requirement level of this requirement is 'MUST' since the full 1171 capacity of the security requirements defined in this document can 1172 only be achieved in secure mode. 1174 Discussion 1176 While the requirement in this subsection is similar to the one in 1177 5.1. , it refers to the secure mode, as opposed to the hybrid mode 1178 presented in the next subsection. 1180 5.10.2. Hybrid Mode 1182 Requirement 1184 The security protocol MAY support a hybrid mode, where both secured 1185 and unsecured clocks are permitted to take part in the protocol. 1187 Requirement Level 1189 The requirement level of this requirement is a 'MAY', since it is not 1190 necessarily required in all systems. This document recommends to 1191 deploy the 'Secure Mode' described in Section 5.10.1. where possible. 1193 Discussion 1195 The hybrid mode allows both secured and unsecured clocks to take part 1196 in the time protocol. NTP, for example, allows a mixture of secured 1197 and unsecured nodes. 1199 Requirement 1201 A master in the hybrid mode SHOULD be a secured clock. 1203 A secured slave in the hybrid mode SHOULD discard all protocol 1204 packets received from unsecured clocks. 1206 Requirement Level 1208 The requirement level of this requirement is a 'SHOULD', since it may 1209 not be applicable to all deployments. For example, a hybrid network 1210 may require the usage of unsecured masters or TCs. 1212 Discussion 1214 This requirement ensures that the existence of unsecured clocks does 1215 not compromise the security provided to secured clocks. Hence, 1216 secured slaves only "trust" protocol packets received from a secured 1217 clock. 1219 An unsecured slave can receive protocol packets either from unsecured 1220 clocks, or from secured clocks. Note that the latter does not apply 1221 when encryption is used. When integrity protection is used, the 1222 unsecured slave can receive secured packets ignoring the integrity 1223 protection. 1225 Note that the security scheme in [NTPv4] with [AutoKey] does not 1226 satisfy this requirement, since nodes prefer the server with the most 1227 accurate clock, which is not necessarily the server that supports 1228 authentication. For example, a stratum 2 server is connected to two 1229 stratum 1 servers, Server A, supporting authentication, and server B, 1230 without authentication. If server B has a more accurate clock than A, 1231 the stratum 2 server chooses server B, in spite of the fact it does 1232 not support authentication. 1234 6. Summary of Requirements 1236 +-----------+---------------------------------------------+--------+ 1237 | Section | Requirement | Type | 1238 +-----------+---------------------------------------------+--------+ 1239 | 5.1. | Authentication & authorization of sender. | MUST | 1240 | +---------------------------------------------+--------+ 1241 | | Authentication & authorization of master. | MUST | 1242 | +---------------------------------------------+--------+ 1243 | | Recursive authentication & authorization. | MUST | 1244 | +---------------------------------------------+--------+ 1245 | | Authentication & authorization of slaves. | MAY | 1246 | +---------------------------------------------+--------+ 1247 | | PTP: Authentication & authorization of | MAY | 1248 | | P2P TCs by master. | | 1249 | +---------------------------------------------+--------+ 1250 | | PTP: Authentication & authorization of | MUST | 1251 | | Announce messages. | | 1252 | +---------------------------------------------+--------+ 1253 | | PTP: Authentication & authorization of | MUST | 1254 | | Management messages. | | 1255 | +---------------------------------------------+--------+ 1256 | | PTP: Authentication & authorization of | MAY | 1257 | | Signaling messages. | | 1258 +-----------+---------------------------------------------+--------+ 1259 | 5.2. | Integrity protection. | MUST | 1260 +-----------+---------------------------------------------+--------+ 1261 | 5.3. | Spoofing prevention. | MUST | 1262 +-----------+---------------------------------------------+--------+ 1263 | 5.4. | Protection from DoS attacks against the | SHOULD | 1264 | | time protocol. | | 1265 +-----------+---------------------------------------------+--------+ 1266 | 5.5. | Replay protection. | MUST | 1267 +-----------+---------------------------------------------+--------+ 1268 | 5.6. | Key freshness. | MUST | 1269 | +---------------------------------------------+--------+ 1270 | | Security association. | SHOULD | 1271 | +---------------------------------------------+--------+ 1272 | | Unicast and multicast associations. | SHOULD | 1273 +-----------+---------------------------------------------+--------+ 1274 | 5.7. | Performance: no degradation in quality of | MUST | 1275 | | time transfer. | | 1276 | +---------------------------------------------+--------+ 1277 | | Performance: computation load. | SHOULD | 1278 | +---------------------------------------------+--------+ 1279 | | Performance: storage. | SHOULD | 1280 | +---------------------------------------------+--------+ 1281 | | Performance: bandwidth. | SHOULD | 1282 +-----------+---------------------------------------------+--------+ 1283 | 5.8. | Confidentiality protection. | MAY | 1284 +-----------+---------------------------------------------+--------+ 1285 | 5.9. | Protection against delay and interception | MUST | 1286 | | attacks. | | 1287 +-----------+---------------------------------------------+--------+ 1288 | 5.10. | Secure mode. | MUST | 1289 | +---------------------------------------------+--------+ 1290 | | Hybrid mode. | MAY | 1291 +-----------+---------------------------------------------+--------+ 1292 Table 2 Summary of Security Requirements 1294 7. Additional security implications 1296 This section discusses additional implications of the interaction 1297 between time protocols and security mechanisms. 1299 This section refers to time protocol security mechanisms, as well as 1300 to "external" security mechanisms, i.e., security mechanisms that are 1301 not strictly related to the time protocol. 1303 7.1. Security and on-the-fly Timestamping 1305 Time protocols often require that protocol packets be modified during 1306 transmission. Both NTP and PTP in one-step mode require clocks to 1307 modify protocol packets based on the time of transmission and/or 1308 reception. 1310 In the presence of a security mechanism, whether encryption or 1311 integrity protection: 1313 o During transmission the encryption and/or integrity protection 1314 MUST be applied after integrating the timestamp into the packet. 1316 To allow high accuracy, timestamping is typically performed as close 1317 to the transmission or reception time as possible. However, since the 1318 security engine must be placed between the timestamping function and 1319 the physical interface, it may introduce non-deterministic latency 1320 that causes accuracy degradation. These performance aspects have been 1321 analyzed in literature, e.g., [1588IPsec] and [Tunnel]. 1323 7.2. PTP: Security and Two-Step Timestamping 1325 PTP supports a two-step mode of operation, where the time of 1326 transmission of protocol packets is communicated without modifying 1327 the packets. As opposed to one-step mode, two-step timestamping can 1328 be performed without the requirement to encrypt after timestamping. 1330 Note that if an encryption mechanism such as IPsec is used, it 1331 presents a challenge to the timestamping mechanism, since time 1332 protocol packets are encrypted when traversing the physical 1333 interface, and are thus impossible to identify. A possible solution 1334 to this problem [IPsecSync] is to include an indication in the 1335 encryption header that identifies time protocol packets. 1337 7.3. Intermediate Clocks 1339 A time protocol allows slaves to receive time information from an 1340 accurate time source. Time information is sent over a path that often 1341 traverses one or more intermediate clocks. 1343 o In NTP, time information originated from a stratum 1 server can be 1344 distributed to stratum 2 servers, and in turn distributed from the 1345 stratum 2 servers to NTP clients. In this case, the stratum 2 1346 servers are a layer of intermediate clocks. These intermediate 1347 clocks are referred to as "secondary servers" in [NTPv4]. 1349 o In PTP, BCs and TCs are intermediate nodes used to improve the 1350 accuracy of time information conveyed between the grandmaster and 1351 the slaves. 1353 A common rule of thumb in network security is that end-to-end 1354 security is the best policy, as it secures the entire path between 1355 the data originator and its receiver. The usage of intermediate nodes 1356 implies that if a security mechanism is deployed in the network, a 1357 hop-by-hop security scheme must be used, since intermediate nodes 1358 must be able to send time information to the slaves, or to modify 1359 time information sent through them. 1361 This inherent property of using intermediate clocks increases the 1362 system's exposure to internal threats, as there is a large number of 1363 nodes that possess the security keys. 1365 Thus, there is a tradeoff between the achievable clock accuracy of a 1366 system, and the robustness of its security solution. On one hand high 1367 clock accuracy calls for hop-by-hop involvement in the protocol, also 1368 known as on-path support. On the other hand, a robust security 1369 solution calls for end-to-end data protection. 1371 7.4. External Security Protocols and Time Protocols 1373 Time protocols are often deployed in systems that use security 1374 mechanisms and protocols. 1376 A typical example is the 3GPP Femtocell network [3GPP], where IPsec 1377 is used for securing traffic between a Femtocell and the Femto 1378 Gateway. In some cases, all traffic between these two nodes may be 1379 secured by IPsec, including the time protocol traffic. This use-case 1380 is thoroughly discussed in [IPsecSync]. 1382 Another typical example is the usage of MACsec encryption ([MACsec]) 1383 in L2 networks that deploy time synchronization [AvbAssum]. 1385 The usage of external security mechanisms may affect time protocols 1386 as follows: 1388 o Timestamping accuracy can be affected, as described in 7.1. 1390 o If traffic is secured between two nodes in the network, no 1391 intermediate clocks can be used between these two nodes. In the 1392 [3GPP] example, if traffic between the Femtocell and the Femto 1393 Gateway is encrypted, then time protocol packets are necessarily 1394 transported over the underlying network without modification, and 1395 thus cannot enjoy the improved accuracy provided by intermediate 1396 clock nodes. 1398 7.5. External Security Services Requiring Time 1400 Cryptographic protocols often use time as an important factor in the 1401 cryptographic algorithm. If a time protocol is compromised, it may 1402 consequently expose the security protocols that rely on it to various 1403 attacks. Two examples are presented in this section. 1405 7.5.1. Timestamped Certificates 1407 Certificate validation requires the sender and receiver to be roughly 1408 time synchronized. Thus, synchronization is required for establishing 1409 security protocols such as IKEv2 and TLS. 1411 An even stronger interdependence between a time protocol and a 1412 security mechanism is defined in [AutoKey], which defines mutual 1413 dependence between the acquired time information, and the 1414 authentication protocol that secures it. This bootstrapping behavior 1415 results from the fact that trusting the received time information 1416 requires a valid certificate, and validating a certificate requires 1417 knowledge of the time. 1419 7.5.2. Time Changes and Replay Attacks 1421 A successful attack on a time protocol may cause the attacked clocks 1422 to go back in time. The erroneous time may expose cryptographic 1423 algorithms that rely on time, as a node may use a key that was 1424 already used in the past and has expired. 1426 8. Issues for Further Discussion 1428 The Key distribution is outside the scope of this document. Although 1429 this is an essential element of any security system, it is outside 1430 the scope of this document. 1432 9. Security Considerations 1434 The security considerations of network timing protocols are presented 1435 throughout this document. 1437 10. IANA Considerations 1439 There are no new IANA considerations implied by this document. 1441 11. Acknowledgments 1443 The authors gratefully acknowledge Stefano Ruffini, Doug Arnold, 1444 Kevin Gross, Dieter Sibold, Dan Grossman, Laurent Montini, Russell 1445 Smiley, and Shawn Emery for their thorough review and helpful 1446 comments. The authors would also like to thank members of the TICTOC 1447 WG for providing feedback on the TICTOC mailing list. 1449 This document was prepared using 2-Word-v2.0.template.dot. 1451 12. References 1453 12.1. Normative References 1455 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1456 Requirement Levels", BCP 14, RFC 2119, March 1997. 1458 [NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W., 1459 "Network Time Protocol Version 4: Protocol and 1460 Algorithms Specification", RFC 5905, June 2010. 1462 [AutoKey] Haberman, B., Mills, D., "Network Time Protocol 1463 Version 4: Autokey Specification", RFC 5906, June 1464 2010. 1466 [IEEE1588] IEEE TC 9 Instrumentation and Measurement Society, 1467 "1588 IEEE Standard for a Precision Clock 1468 Synchronization Protocol for Networked Measurement and 1469 Control Systems Version 2", IEEE Standard, 2008. 1471 12.2. Informative References 1473 [Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R., 1474 "Traps and pitfalls in secure clock synchronization" 1475 in Proceedings of 2007 International Symposium for 1476 Precision Clock Synchronization for Measurement, 1477 Control and Communication, ISPCS 2007, pp. 18-24, 1478 2007. 1480 [TM] T. Mizrahi, "Time synchronization security using IPsec 1481 and MACsec", ISPCS 2011, pp. 38-43, 2011. 1483 [SecPTP] J. Tsang, K. Beznosov, "A security analysis of the 1484 precise time protocol (short paper)," 8th 1485 International Conference on Information and 1486 Communication Security (ICICS 2006), pp. 50-59, 2006. 1488 [SecSen] S. Ganeriwal, C. Popper, S. Capkun, M. B. Srivastava, 1489 "Secure Time Synchronization in Sensor Networks", ACM 1490 Trans. Info. and Sys. Sec., Volume 11, Issue 4, July 1491 2008. 1493 [AvbAssum] D. Pannell, "Audio Video Bridging Gen 2 Assumptions", 1494 IEEE 802.1 AVB Plenary, work in progress, May 2012. 1496 [IPsecSync] Y. Xu, "IPsec security for packet based 1497 synchronization", IETF, draft-xu-tictoc-ipsec- 1498 security-for-synchronization (work in progress), 2011. 1500 [3GPP] 3GPP, "Security of Home Node B (HNB) / Home evolved 1501 Node B (HeNB)", 3GPP TS 33.320 10.4.0 (work in 1502 progress), 2011. 1504 [1588IPsec] A. Treytl, B. Hirschler, "Securing IEEE 1588 by IPsec 1505 tunnels - An analysis", in Proceedings of 2010 1506 International Symposium for Precision Clock 1507 Synchronization for Measurement, Control and 1508 Communication, ISPCS 2010, pp. 83-90, 2010. 1510 [Tunnel] A. Treytl, B. Hirschler, and T. Sauter, "Secure 1511 tunneling of high precision clock synchronisation 1512 protocols and other timestamped data", in Proceedings 1513 of the 8th IEEE International Workshop on Factory 1514 Communication Systems (WFCS), vol. ISBN 978-1-4244- 1515 5461-7, pp. 303-313, 2010. 1517 [DelayAtt] T. Mizrahi, "A Game Theoretic Analysis of Delay 1518 Attacks against Time Synchronization Protocols", 1519 accepted, to appear in Proceedings of the 1520 International IEEE Symposium on Precision Clock 1521 Synchronization for Measurement, Control and 1522 Communication, ISPCS, 2012. 1524 [MACsec] IEEE 802.1AE-2006, "IEEE Standard for Local and 1525 Metropolitan Area Networks - Media Access Control 1526 (MAC) Security", 2006. 1528 [IPsec] S. Kent, K. Seo, "Security Architecture for the 1529 Internet Protocol", IETF, RFC 4301, 2005. 1531 13. Contributing Authors 1533 Karen O'Donoghue 1534 ISOC 1536 Email: odonoghue@isoc.org 1538 Authors' Addresses 1540 Tal Mizrahi 1541 Marvell 1542 6 Hamada St. 1543 Yokneam, 20692 Israel 1545 Email: talmi@marvell.com