idnits 2.17.1 draft-ietf-tictoc-security-requirements-07.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 870 has weird spacing: '...equires the...' == Line 872 has weird spacing: '... the packet...' -- The document date (April 23, 2014) is 3627 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 23, 2014 6 Security Requirements of Time Protocols 7 in Packet Switched Networks 8 draft-ietf-tictoc-security-requirements-07.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 23, 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. Availability ........................................... 20 100 5.4. Replay Protection ...................................... 20 101 5.5. Cryptographic Keys and Security Associations ........... 21 102 5.5.1. Key Freshness ..................................... 21 103 5.5.2. Security Association .............................. 21 104 5.5.3. Unicast and Multicast Associations ................ 22 105 5.6. Performance ............................................ 22 106 5.7. Confidentiality......................................... 23 107 5.8. Protection against Packet Delay and Interception Attacks 24 108 5.9. Combining Secured with Unsecured Nodes ................. 25 109 5.9.1. Secure Mode ....................................... 25 110 5.9.2. Hybrid Mode ....................................... 25 111 6. Summary of Requirements ..................................... 26 112 7. Additional security implications ............................ 28 113 7.1. Security and on-the-fly Timestamping ................... 28 114 7.2. PTP: Security and Two-Step Timestamping ................ 28 115 7.3. Intermediate Clocks .................................... 29 116 7.4. External Security Protocols and Time Protocols.......... 29 117 7.5. External Security Services Requiring Time .............. 30 118 7.5.1. Timestamped Certificates .......................... 30 119 7.5.2. Time Changes and Replay Attacks ................... 30 120 8. Issues for Further Discussion ............................... 31 121 9. Security Considerations ..................................... 31 122 10. IANA Considerations......................................... 31 123 11. Acknowledgments ............................................ 31 124 12. References ................................................. 31 125 12.1. Normative References .................................. 31 126 12.2. Informative References ................................ 32 127 13. Contributing Authors ....................................... 33 129 1. Introduction 131 As time protocols are becoming increasingly common and widely 132 deployed, concern about the resulting exposure to various security 133 threats is increasing. If a time protocol is compromised, the 134 applications it serves are prone to a range of possible attacks 135 including Denial-of-Service (DoS) or incorrect behavior. 137 This document focuses on the security aspects of the Precision Time 138 Protocol (PTP) [IEEE1588] and the Network Time Protocol [NTPv4]. The 139 Network Time Protocol was defined with an inherent security protocol, 140 defined in [NTPv4] and in [AutoKey]. [IEEE1588] includes an 141 experimental security protocol, defined in Annex K of the standard, 142 but this Annex was never formalized into a fully defined security 143 protocol. 145 While NTP includes an inherent security protocol, the absence of a 146 standard security solution for PTP undoubtedly contributed to the 147 wide deployment of unsecured time synchronization solutions. However, 148 in some cases security mechanisms may not be strictly necessary, 149 e.g., due to other security practices in place, or due to the 150 architecture of the network. A time synchronization security 151 solution, much like any security solution, is comprised of various 152 building blocks, and must be carefully tailored for the specific 153 system it is deployed in. Based on a system-specific threat 154 assessment, the benefits of a security solution must be weighed 155 against the potential risks, and based on this tradeoff an optimal 156 security solution can be selected. 158 The target audience of this document includes: 160 o Timing and networking equipment vendors - can benefit from this 161 document by deriving the security features that should be 162 supported in the time/networking equipment. 164 o Standard development organizations - can use the requirements 165 defined in this document when specifying security mechanisms for a 166 time protocol. 168 o Network operators - can use this document as a reference when 169 designing the network and its security architecture. As stated 170 above, the requirements in this document may be deployed 171 selectively based on a careful per-system threat analysis. 173 This document attempts to add clarity to the time protocol security 174 requirements discussion by addressing a series of questions: 176 (1) What are the threats that need to be addressed for the time 177 protocol, and thus what security services need to be provided? (e.g. 178 a malicious NTP server or PTP master) 180 (2) What external security practices impact the security and 181 performance of time keeping, and what can be done to mitigate these 182 impacts? (e.g. an IPsec tunnel in the time protocol traffic path) 183 (3) What are the security impacts of time protocol practices? (e.g. 184 on-the-fly modification of timestamps) 186 (4) What are the dependencies between other security services and 187 time protocols? (e.g. which comes first - the certificate or the 188 timestamp?) 190 In light of the questions above, this document defines a set of 191 requirements for security solutions for time protocols, focusing on 192 PTP and NTP. 194 2. Conventions Used in this Document 196 2.1. Terminology 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in [KEYWORDS]. 202 This document describes security requirements, and thus requirements 203 are phrased in the document in the form "the security mechanism 204 MUST/SHOULD/...". Note, that the phrasing does not imply that this 205 document defines a specific security mechanism, but defines the 206 requirements with which every security mechanism should comply. 208 2.2. Abbreviations 210 BC Boundary Clock [IEEE1588] 212 DoS Denial of Service 214 MITM Man In The Middle 216 NTP Network Time Protocol [NTPv4] 218 OC Ordinary Clock [IEEE1588] 220 P2P TC Peer-to-Peer Transparent Clock [IEEE1588] 222 PTP Precision Time Protocol [IEEE1588] 224 TC Transparent Clock [IEEE1588] 226 2.3. Common Terminology for PTP and NTP 228 This document refers to both PTP and NTP. For the sake of 229 consistency, throughout the document the term "master" applies to 230 both a PTP master and an NTP server. Similarly, the term "slave" 231 applies to both PTP slaves and NTP clients. The term "protocol 232 packets" refers generically to PTP and NTP messages. 234 2.4. Terms used in this Document 236 o Clock - A node participating in the protocol (either PTP or NTP). 237 A clock can be a master, a slave, or an intermediate clock (see 238 corresponding definitions below). 240 o Control packets - Packets used by the protocol to exchange 241 information between clocks that is not strictly related to the 242 time. NTP uses NTP Control Messages. PTP uses Announce, Signaling 243 and Management messages. 245 o End-to-end security - A security approach where secured packets 246 sent from a source to a destination is not modified by 247 intermediate nodes. 249 o Grandmaster - A master that receives time information from a 250 locally attached clock device, and not through the network. A 251 grandmaster distributes its time to other clocks in the network. 253 o Hop-by-hop security - A security approach where secured packets 254 sent from a source to a destination may be modified by 255 intermediate nodes. In this approach intermediate nodes share the 256 encryption key with the source and destination, allowing them to 257 re-encrypt or re-authenticate modified packets before relaying 258 them to the destination. 260 o Intermediate clock - A clock that receives timing information from 261 a master, and sends timing information to other clocks. 262 In NTP this term refers to an NTP server that is not a Stratum 1 263 server. In PTP this term refers to a BC or a TC. 265 o Master - A clock that generates timing information to other clocks 266 in the network. 267 In NTP 'master' refers to an NTP server. In PTP 'master' refers to 268 a master OC (aka grandmaster) or to a port of a BC that is in the 269 master state. 271 o Protocol packets - Packets used by the time protocol. The 272 terminology used in this document distinguishes between time 273 packets and control packets. 275 o Secured clock - A clock that supports a security mechanism that 276 complies to the requirements in this document. 278 o Slave - A clock that receives timing information from a master. In 279 NTP 'slave' refers to an NTP client. In PTP 'slave' refers to a 280 slave OC, or to a port of a BC that is in the slave state. 282 o Time packets - Protocol packets carrying time information. 284 o Unsecured clock - A clock that does not support a security 285 mechanism according to the requirements in this document. 287 3. Security Threats 289 This section discusses the possible attacker types and analyzes 290 various attacks against time protocols. 292 The literature is rich with security threats of time protocols, e.g., 293 [Traps], [AutoKey], [TM], [SecPTP], and [SecSen]. The threat analysis 294 in this document is mostly based on [TM]. 296 3.1. Threat Model 298 A time protocol can be attacked by various types of attackers. 300 The analysis in this document classifies attackers according to 2 301 criteria, as described in Section 3.1.1. and Section 3.1.2. 303 3.1.1. Internal vs. External Attackers 305 In the context of internal and external attackers, the underlying 306 assumption is that the time protocol is secured either by an 307 encryption or an authentication mechanism, or both. 309 Internal attackers either have access to a trusted segment of the 310 network, or possess the encryption or authentication keys. An 311 internal attack can also be performed by exploiting vulnerabilities 312 in devices; for example, by installing malware, or obtaining 313 credentials to reconfigure the device. Thus, an internal attacker can 314 maliciously tamper with legitimate traffic in the network, as well as 315 generate its own traffic and make it appear legitimate to its 316 attacked nodes. 318 External attackers, on the other hand, do not have the keys, and have 319 access only to the encrypted or authenticated traffic. 321 Obviously, in the absence of a security mechanism there is no 322 distinction between internal and external attackers, since all 323 attackers are internal in practice. 325 3.1.2. Man in the Middle (MITM) vs. Packet Injector 327 MITM attackers are located in a position that allows interception and 328 modification of in-flight protocol packets. It is assumed that an 329 MITM attacker has physical access to a segment of the network, or has 330 gained control of one of the nodes in the network. 332 A traffic injector is not located in an MITM position, but can attack 333 by generating protocol packets. An injector can reside either within 334 the attacked network, or on an external network that is connected to 335 the attacked network. An injector can also potentially eavesdrop on 336 protocol packets sent as multicast, record them and replay them 337 later. 339 3.2. Threat Analysis 341 3.2.1. Packet Manipulation 343 A packet manipulation attack results when an MITM attacker receives 344 timing protocol packets, alters them and relays them to their 345 destination, allowing the attacker to maliciously tamper with the 346 protocol. This can result in a situation where the time protocol is 347 apparently operational but providing intentionally inaccurate 348 information. 350 3.2.2. Spoofing 352 In spoofing, an injector masquerades as a legitimate node in the 353 network by generating and transmitting protocol packets or control 354 packets. Two typical examples of spoofing attacks: 356 o An attacker can impersonate the master, allowing malicious 357 distribution of false timing information. 359 o An attacker can impersonate a legitimate clock, a slave or an 360 intermediate clock, by sending malicious messages to the master, 361 causing the master to respond to the legitimate clock with 362 protocol packets that are based on the spoofed messages. 363 Consequently, the delay computations of the legitimate clock are 364 based on false information. 366 As with packet manipulation, this attack can result in a situation 367 where the time protocol is apparently operational but providing 368 intentionally inaccurate information. 370 3.2.3. Replay Attack 372 In a replay attack, an attacker records protocol packets and replays 373 them at a later time without any modification. This can also result 374 in a situation where the time protocol is apparently operational but 375 providing intentionally inaccurate information. 377 3.2.4. Rogue Master Attack 379 In a rogue master attack, an attacker causes other nodes in the 380 network to believe it is a legitimate master. As opposed to the 381 spoofing attack, in the Rogue Master attack the attacker does not 382 fake its identity, but rather manipulates the master election process 383 using malicious control packets. For example, in PTP, an attacker can 384 manipulate the Best Master Clock Algorithm (BMCA), and cause other 385 nodes in the network to believe it is the most eligible candidate to 386 be a grandmaster. 388 In PTP, a possible variant of this attack is the rogue TC/BC attack. 389 Similar to the rogue master attack, an attacker can cause victims to 390 believe it is a legitimate TC or BC, allowing the attacker to 391 manipulate the time information forwarded to the victims. 393 3.2.5. Packet Interception and Removal 395 A packet interception and removal attack results when an MITM 396 attacker intercepts and drops protocol packets, preventing the 397 destination node from receiving some or all of the protocol packets. 399 3.2.6. Packet Delay Manipulation 401 In a packet delay manipulation scenario, an MITM attacker receives 402 protocol packets, and relays them to their destination after adding a 403 maliciously computed delay. The attacker can use various delay attack 404 strategies; the added delay can be constant, jittered, or slowly 405 wandering. Each of these strategies has a different impact, but they 406 all effectively manipulate the attacked clock. 408 Note that the victim still receives one copy of each packet, contrary 409 to the replay attack, where some or all of the packets may be 410 received by the victim more than once. 412 3.2.7. L2/L3 DoS Attacks 414 There are many possible Layer 2 and Layer 3 DoS attacks. As the 415 target's availability is compromised, the timing protocol is affected 416 accordingly. 418 3.2.8. Cryptographic Performance Attacks 420 In cryptographic performance attacks, an attacker transmits fake 421 protocol packets, causing high utilization of the cryptographic 422 engine at the receiver, which attempts to verify the integrity of 423 these fake packets. 425 This DoS attack is applicable to all encryption and authentication 426 protocols. However, when the time protocol uses a dedicated security 427 mechanism implemented in a dedicated cryptographic engine, this 428 attack can be applied to cause DoS specifically to the time protocol 430 3.2.9. DoS Attacks against the Time Protocol 432 An attacker can attack a clock by sending an excessive number of time 433 protocol packets, thus degrading the victim's performance. This 434 attack can be implemented, for example, using the attacks described 435 in Section 3.2.2. and Section 3.2.4. 437 3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud) 439 Grandmasters receive their time from an external accurate time 440 source, such as an atomic clock or a GPS clock, and then distribute 441 this time to the slaves using the time protocol. 443 Time source attack are aimed at the accurate time source of the 444 grandmaster. For example, if the grandmaster uses a GPS based clock 445 as its reference source, an attacker can jam the reception of the GPS 446 signal, or transmit a signal similar to one from a GPS satellite, 447 causing the grandmaster to use a false reference time. 449 Note that this attack is outside the scope of the time protocol. 450 While various security measures can be taken to mitigate this attack, 451 these measures are outside the scope of the security requirements 452 defined in this document. 454 3.3. Threat Analysis Summary 456 The two key factors to a threat analysis are the impact and the 457 likelihood of each of the analyzed attacks. 459 Table 1 summarizes the security attacks presented in Section 3.2. 460 For each attack, the table specifies its impact, and its 461 applicability to each of the attacker types presented in Section 3.1. 463 Table 1 clearly shows the distinction between external and internal 464 attackers, and motivates the usage of authentication and integrity 465 protection, significantly reducing the impact of external attackers. 467 The Impact column provides an intuitive measure of the severity of 468 each attack, and the relevant Attacker Type columns provide an 469 intuition about how difficult each attack is to implement, and hence 470 about the likelihood of each attack. 472 The impact column in Table 1 can have one of 3 values: 474 o DoS - the attack causes denial of service to the attacked node, 475 the impact of which is not restricted to the time protocol. 477 o Accuracy degradation - the attack yields a degradation in the 478 slave accuracy, but does not completely compromise the slaves' 479 time and frequency. 481 o False time - slaves align to a false time or frequency value due 482 to the attack. Note that if the time protocol aligns to a false 483 time, it may cause DoS to other applications that rely on accurate 484 time. However, for the purpose of the analysis in this section we 485 distinguish this implication from 'DoS', which refers to a DoS 486 attack that is not necessarily aimed at the time protocol. 487 All attacks that have a '+' for 'False Time' implicitly have a '+' 488 for 'Accuracy Degradation'. 490 The Attacker Type columns refer to the 4 possible combinations of the 491 attacker types defined in Section 3.1. 493 +-----------------------------+-------------------++-------------------+ 494 | Attack | Impact || Attacker Type | 495 | +-----+--------+----++---------+---------+ 496 | |False|Accuracy| ||Internal |External | 497 | |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.| 498 +-----------------------------+-----+--------+----++----+----+----+----+ 499 |Manipulation | + | | || + | | | | 500 +-----------------------------+-----+--------+----++----+----+----+----+ 501 |Spoofing | + | | || + | + | | | 502 +-----------------------------+-----+--------+----++----+----+----+----+ 503 |Replay attack | + | | || + | + | | | 504 +-----------------------------+-----+--------+----++----+----+----+----+ 505 |Rogue master attack | + | | || + | + | | | 506 +-----------------------------+-----+--------+----++----+----+----+----+ 507 |Interception and removal | | + | + || + | | + | | 508 +-----------------------------+-----+--------+----++----+----+----+----+ 509 |Packet delay manipulation | + | | || + | | + | | 510 +-----------------------------+-----+--------+----++----+----+----+----+ 511 |L2/L3 DoS attacks | | | + || + | + | + | + | 512 +-----------------------------+-----+--------+----++----+----+----+----+ 513 |Crypt. performance attacks | | | + || + | + | + | + | 514 +-----------------------------+-----+--------+----++----+----+----+----+ 515 |Time protocol DoS attacks | | | + || + | + | | | 516 +-----------------------------+-----+--------+----++----+----+----+----+ 517 |Master time source attack | + | | || + | + | + | + | 518 |(e.g., GPS spoofing) | | | || | | | | 519 +-----------------------------+-----+--------+----++----+----+----+----+ 520 Table 1 Threat Analysis - Summary 522 The threats discussed in this section provide the background for the 523 security requirements presented in Section 5. 525 4. Requirement Levels 527 The security requirements are presented in Section 5. Each 528 requirement is defined with a requirement level, in accordance with 529 the requirement levels defined in Section 2.1. 531 The requirement levels in this document are affected by the following 532 factors: 534 o Impact: 535 The possible impact of not implementing the requirement, as 536 illustrated in the 'impact' column of Table 1. 537 For example, a requirement that addresses a threat that can be 538 implemented by an external injector is typically a 'MUST', since 539 the threat can be implemented by all the attacker types analyzed 540 in Section 3.1. 542 o Difficulty of the corresponding attack: 543 The level of difficulty of the possible attacks that become 544 possible by not implementing the requirement. The level of 545 difficulty is reflected in the 'Attacker Type' column of Table 1. 546 For example, a requirement that addresses a threat that only 547 compromises the availability of the protocol is typically no more 548 than a 'SHOULD'. 550 o Practical considerations: 551 Various practical factors that may affect the requirement. 552 For example, if a requirement is very difficult to implement, or 553 is applicable to very specific scenarios, these factors may reduce 554 the requirement level. 556 Section 5. lists the requirements. For each requirement there is a 557 short explanation detailing the reason for its requirement level. 559 5. Security Requirements 561 This section defines a set of security requirements. These 562 requirements are phrased in the form "the security mechanism 563 MUST/SHOULD/MAY...". However, this document does not specify how 564 these requirements can be met. While these requirements can be 565 satisfied by defining explicit security mechanisms for time 566 protocols, at least a subset of the requirements can be met by 567 applying common security practices to the network or by using 568 existing security protocols, such as [IPsec] or [MACsec]. Thus, 569 security solutions that address these requirements are outside the 570 scope of this document. 572 5.1. Clock Identity Authentication and Authorization 574 Requirement 576 The security mechanism MUST support authentication. 578 Requirement 580 The security mechanism MUST support authorization. 582 Requirement Level 584 The requirements in this subsection address the spoofing attack 585 (Section 3.2.2.), and the rogue master attack (Section 3.2.4.). 587 The requirement level of these requirements is 'MUST' since in the 588 absence of these requirements the protocol is exposed to attacks that 589 are easy to implement and have a high impact. 591 Discussion 593 Authentication refers to verifying the identity of the peer clock. 594 Authorization, on the other hand, refers to verifying that the peer 595 clock is permitted to play the role that it plays in the protocol. 597 For example, some nodes may be permitted to be masters, while other 598 nodes are only permitted to be slaves or TCs. 600 Authorization requires clocks to maintain a list of authorized 601 clocks, or a "black list" of clocks that should be denied service or 602 revoked. 604 It is noted that while the security mechanism is required to provide 605 an authorization mechanism, the deployment of such a mechanism 606 depends on the nature of the network. For example, a network that 607 deploys PTP may consist of a set of identical OCs, where all clocks 608 are equally permitted to be a master. In such a network an 609 authorization mechanism may not be necessary. 611 The following subsections describe 5 distinct cases of clock 612 authentication. 614 5.1.1. Authentication and Authorization of Masters 616 Requirement 618 The security mechanism MUST support an authentication mechanism, 619 allowing slaves to authenticate the identity of masters. 621 Requirement 623 The authentication mechanism MUST allow slaves to verify that the 624 authenticated master is authorized to be a master. 626 Requirement Level 628 The requirements in this subsection address the spoofing attack 629 (Section 3.2.2.), and the rogue master attack (Section 3.2.4.). 631 The requirement level of these requirements is 'MUST' since in the 632 absence of these requirements the protocol is exposed to attacks that 633 are easy to implement and have a high impact. 635 Discussion 637 Clocks authenticate masters in order to ensure the authenticity of 638 the time source. It is important for a slave to verify the identity 639 of the master, as well as to verify that the master is indeed 640 authorized to be a master. 642 5.1.2. Recursive Authentication and Authorization of Masters (Chain of 643 Trust) 645 Requirement 647 The security mechanism MUST support recursive authentication and 648 authorization of the master, to be used in cases where time 649 information is conveyed through intermediate clocks. 651 Requirement Level 653 The requirement in this subsection addresses the spoofing attack 654 (Section 3.2.2.), and the rogue master attack (Section 3.2.4.). 656 The requirement level of this requirement is 'MUST' since in the 657 absence of this requirement the protocol is exposed to attacks that 658 are easy to implement and have a high impact. 660 Discussion 662 In some cases a slave is connected to an intermediate clock, that is 663 not the primary time source. For example, in PTP a slave can be 664 connected to a Boundary Clock (BC) or a Transparent Clock (TC), which 665 in turn is connected to a grandmaster. A similar example in NTP is 666 when a client is connected to a stratum 2 server, which is connected 667 to a stratum 1 server. In both the PTP and the NTP cases, the slave 668 authenticates the intermediate clock, and the intermediate clock 669 authenticates the grandmaster. This recursive authentication process 670 is referred to in [AutoKey] as proventication. 672 Specifically in PTP, this requirement implies that if a slave 673 receives time information through a TC, it must authenticate the TC 674 it is attached to, as well as authenticate the master it receives the 675 time information from, as per Section 5.1.1. Similarly, if a TC 676 receives time information through an attached TC, it must 677 authenticate the attached TC. 679 5.1.3. Authentication and Authorization of Slaves 681 Requirement 683 The security mechanism MUST provide a means for a master to 684 authenticate its slaves. 686 Requirement 687 The security mechanism MAY provide a means for a master to verify 688 that the sender of a protocol packet is authorized to send a packet 689 of this type. 691 Requirement Level 693 The authentication requirement in this subsection prevents DoS 694 attacks against the master (Section 3.2.9.), as well as spoofing 695 attacks (Section 3.2.2.). A spoofing attack, such as the second 696 example in Section 3.2.2. , is easy to implement and has a high 697 impact, and therefore the requirement level is 'MUST'. 699 The authorization requirement in this subsection only mitigates DoS 700 attacks against the master (Section 3.2.9.). The requirement level 701 is 'MAY', since the absence of this requirement has a relatively low 702 impact, i.e., in the absence of this requirement the protocol is only 703 exposed to DoS. Note that Section 5.1.1. specifies authorization as 704 a 'MUST', i.e., the security mechanism must provide a means for 705 authorization, with an emphasis on the master. Authentication and 706 authorization of slaves is specified in this subsection as 'MAY'. 708 Discussion 710 Slaves and intermediate clocks are authenticated by masters in order 711 to verify their identity, thus preventing attackers from sending 712 unauthorized protocol packets to the master, and preventing 713 unauthorized clocks from receiving time services. 715 Note that the authentication of slaves might put a higher load on the 716 master than serving the unauthorized clock, and thus the decision of 717 whether to deploy slave authentication and/or authorization should be 718 based on the environment in which the master and slaves are deployed. 720 5.1.4. PTP: Authentication and Authorization of P2P TCs by the Master 722 Requirement 724 The security mechanism for PTP MUST provide a means for a master to 725 authenticate the identity of the P2P TCs directly connected to it. 727 Requirement 729 The security mechanism for PTP MAY provide a means for a master to 730 verify that P2P TCs directly connected to it are authorized to be 731 TCs. 733 Requirement Level 734 As in Section 5.1.3. , authentication and authorization can help in 735 preventing DoS attacks against the master (Section 3.2.9.). 736 Authentication also mitigates spoofing attacks (Section 3.2.2.). 738 The requirement levels of the authentication and authorization 739 requirements in this subsection are 'MUST' and 'MAY' respectively, 740 for the same reasons specified in Section 5.1.3. 742 Discussion 744 P2P TCs that are one hop from the master use the PDelay_Req and 745 PDelay_Resp handshake to compute the link delay between the master 746 and TC. These TCs are authenticated by the master. 748 Authentication of TCs, much like authentication of slaves, prevents 749 external attackers from sending spoofed messages to the master, as 750 well as reduces unnecessary load on the master and peer TCs, by 751 preventing the master from serving unauthorized clocks. 753 5.1.5. PTP: Authentication and Authorization of Control Messages 755 Requirement 757 The security mechanism for PTP MUST support authentication of 758 Announce messages. The authentication mechanism MUST also verify that 759 the sender is authorized to be a master. 761 Requirement 763 The security mechanism for PTP MUST support authentication and 764 authorization of Management messages. 766 Requirement 768 The security mechanism MAY support authentication and authorization 769 of Signaling messages. 771 Requirement Level 773 The requirements in this subsection address the spoofing attack 774 (Section 3.2.2.), and the rogue master attack (Section 3.2.4.). 776 The requirement level of the first two requirements is 'MUST' since 777 in the absence of these requirements the protocol is exposed to 778 attacks that are easy to implement and have a high impact. 780 The requirement level of the third requirement is 'MAY' since its 781 impact greatly depends on the application for which the Signaling 782 messages are used for. 784 Discussion 786 Master election is performed in PTP using the Best Master Clock 787 Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock 788 attributes using Announce messages, and the best master is elected 789 based on the information gathered from all the candidates. Announce 790 messages must be authenticated in order to prevent rogue master 791 attacks (Section 3.2.4.). Note, that this subsection specifies a 792 requirement that is not necessarily included in Section 5.1.1. or in 793 Section 5.1.3. , since the BMCA is initiated before clocks have been 794 defined as masters or slaves. 796 Management messages are used to monitor or configure PTP clocks. 797 Malicious usage of Management messages enables various attacks, such 798 as the rogue master attack, or DoS attack. 800 Signaling messages are used by PTP clocks to exchange information 801 that is not strictly related to time information or to master 802 selection, such as unicast negotiation. Authentication and 803 authorization of Signaling message may be required in some systems, 804 depending on the application these messages are used for. 806 5.2. Protocol Packet Integrity 808 Requirement 810 The security mechanism MUST protect the integrity of protocol 811 packets. 813 Requirement Level 815 The requirement in this subsection addresses the packet manipulation 816 attack (Section 3.2.1.). 818 The requirement level of this requirement is 'MUST' since in the 819 absence of this requirement the protocol is exposed to attacks that 820 are easy to implement and have high impact. 822 Discussion 824 While Section 5.1. refers to ensuring the identity an authorization 825 of the source of a protocol packet, this subsection refers to 826 ensuring that the packet arrived intact. The integrity protection 827 mechanism ensures the authenticity and completeness of data from the 828 data originator. 830 5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 832 Specifically in PTP, when protocol packets are subject to 833 modification by TCs, the integrity protection can be enforced in one 834 of two approaches, end-to-end or hop-by-hop. 836 5.2.1.1. Hop-by-Hop Integrity Protection 838 Each hop that needs to modify a protocol packet: 840 o Verifies its integrity. 842 o Modifies the packet, i.e., modifies the correctionField. 843 Note: Transparent Clocks (TCs) improve the end-to-end accuracy by 844 updating a "correctionField" (clause 6.5 in [IEEE1588]) in the PTP 845 packet by adding the latency caused by the current TC. 847 o Re-generates the integrity protection, e.g., re-computes a Message 848 Authentication Code. 850 In the hop-by-hop approach, the integrity of protocol packets is 851 protected by induction on the path from the originator to the 852 receiver. 854 This approach is simple, but allows rogue TCs to modify protocol 855 packets. 857 5.2.1.2. End-to-End Integrity Protection 859 In this approach, the integrity protection is maintained on the path 860 from the originator of a protocol packet to the receiver. This allows 861 the receiver to directly validate the protocol packet without the 862 ability of intermediate TCs to manipulate the packet. 864 Since TCs need to modify the correctionField, a separate integrity 865 protection mechanism is used specifically for the correctionField. 867 The end-to-end approach limits the TC's impact to the correctionField 868 alone, while the rest of the protocol packet is protected on an end- 869 to-end basis. It should be noted that this approach is more difficult 870 to implement than the hop-by-hop approach, as it requires the 871 correctionField to be protected separately from the other fields of 872 the packet, possibly using different cryptographic mechanisms and 873 keys. 875 5.3. Availability 877 Requirement 879 The security mechanism SHOULD include measures to mitigate DoS 880 attacks against the time protocol. 882 Requirement Level 884 The requirement in this subsection prevents DoS attacks against the 885 protocol (Section 3.2.9.). 887 The requirement level of this requirement is 'SHOULD' due to its low 888 impact, i.e., in the absence of this requirement the protocol is only 889 exposed to DoS. 891 Discussion 893 The protocol availability can be compromised by several different 894 attacks. 896 An attacker can inject protocol packets to implement the spoofing 897 attack (Section 3.2.2.) or the rogue master attack (Section 3.2.4. 898 ), causing DoS to the victim (Section 3.2.9.). An authentication 899 mechanism (Section 5.1.) limits these attacks strictly to internal 900 attackers, and thus prevents external attackers from performing them. 902 The DoS attacks described in Section 3.2.7. are performed at lower 903 layers than the time protocol layer, and are thus outside the scope 904 of the security requirements defined in this document. 906 5.4. Replay Protection 908 Requirement 910 The security mechanism MUST include a replay prevention mechanism. 912 Requirement Level 914 The requirement in this subsection prevents replay attacks (Section 915 3.2.3.). 917 The requirement level of this requirement is 'MUST' since in the 918 absence of this requirement the protocol is exposed to attacks that 919 are easy to implement and have a high impact. 921 Discussion 922 The replay attack (Section 3.2.3.) can compromise both the integrity 923 and availability of the protocol. Common encryption and 924 authentication mechanisms include replay prevention mechanisms that 925 typically use a monotonously increasing packet sequence number. 927 5.5. Cryptographic Keys and Security Associations 929 5.5.1. Key Freshness 931 Requirement 933 The cryptographic keys MUST be refreshed frequently. 935 Requirement Level 937 The requirement level of this requirement is 'MUST' since key 938 freshness is an essential property for cryptographic algorithms, as 939 discussed below. 941 Discussion 943 Key freshness guarantees that both sides share a common updated 944 secret key. It also helps in preventing replay attacks. Thus, it is 945 important for keys to be refreshed frequently. 947 5.5.2. Security Association 949 Requirement 951 The security protocol SHOULD support an association protocol where: 953 o Two or more clocks authenticate each other. 955 o The clocks generate and agree on a cryptographic session key. 957 Requirement 959 Each instance of the association protocol SHOULD produce a different 960 session key. 962 Requirement Level 964 The requirement level of this requirement is 'SHOULD' since it may be 965 expensive in terms of performance, especially in low-cost clocks. 967 Discussion 968 The security requirements in Section 5.1. and Section 5.2. require 969 usage of cryptographic mechanisms, deploying cryptographic keys. A 970 security association is an important building block in these 971 mechanisms. 973 5.5.3. Unicast and Multicast Associations 975 Requirement 977 The security mechanism SHOULD support security association protocols 978 for unicast and for multicast associations. 980 Requirement Level 982 The requirement level of this requirement is 'SHOULD' since it may be 983 expensive in terms of performance, especially for low-cost clocks. 985 Discussion 987 A unicast protocol requires an association protocol between two 988 clocks, whereas a multicast protocol requires an association protocol 989 among two or more clocks, where one of the clocks is a master. 991 5.6. Performance 993 Requirement 995 The security mechanism MUST be designed in such a way that it does 996 not significantly degrade the quality of the time transfer. 998 Requirement 1000 The mechanism SHOULD minimize computational load. 1002 Requirement 1004 The mechanism SHOULD minimize storage requirements of client state in 1005 the master. 1007 Requirement 1009 The mechanism SHOULD minimize the bandwidth overhead required by the 1010 security protocol. 1012 Requirement Level 1013 While the quality of the time transfer is clearly a 'MUST', the other 1014 3 performance requirements are 'SHOULD', since some systems may be 1015 more sensitive to resource consumption than others, and hence these 1016 requirements should be considered on a per-system basis. 1018 Discussion 1020 Performance efficiency is important since client restrictions often 1021 dictate a low processing and memory footprint, and because the server 1022 may have extensive fan-out. 1024 Note that the performance requirements refer to a time-protocol- 1025 specific security mechanism. In systems where a security protocol is 1026 used for other types of traffic as well, this document does not place 1027 any performance requirements on the security protocol performance. 1028 For example, if IPsec encryption is used for securing all information 1029 between the master and slave node, including information that is not 1030 part of the time protocol, the requirements in this subsection are 1031 not necessarily applicable. 1033 5.7. Confidentiality 1035 Requirement 1037 The security mechanism MAY provide confidentiality protection of the 1038 protocol packets. 1040 Requirement Level 1042 The requirement level of this requirement is 'MAY' since it does not 1043 prevent severe threats, as discussed below. 1045 Discussion 1047 In the context of time protocols, confidentiality is typically of low 1048 importance, since timing information is typically not considered 1049 secret information. 1051 Confidentiality can play an important role when service providers 1052 charge their customers for time synchronization services, and thus an 1053 encryption mechanism can prevent eavesdroppers from obtaining the 1054 service without payment. Note that these cases are, for now, rather 1055 esoteric. 1057 Confidentiality can also prevent an MITM attacker from identifying 1058 protocol packets. Thus, confidentiality can assist in protecting the 1059 timing protocol against MITM attacks such as packet delay (Section 1060 3.2.6.), manipulation and interception and removal attacks. Note, 1061 that time protocols have predictable behavior even after encryption, 1062 such as packet transmission rates and packet lengths. Additional 1063 measures can be taken to mitigate encrypted traffic analysis by 1064 random padding of encrypted packets and by adding random dummy 1065 packets. Nevertheless, encryption does not prevent such MITM attacks, 1066 but rather makes these attacks more difficult to implement. 1068 5.8. Protection against Packet Delay and Interception Attacks 1070 Requirement 1072 The security mechanism MUST include means to protect the protocol 1073 from MITM attacks that degrade the clock accuracy. 1075 Requirement Level 1077 The requirements in this subsection address MITM attacks such as the 1078 packet delay attack (Section 3.2.6.) and packet interception attacks 1079 (Section 3.2.5. and Section 3.2.1.). 1081 The requirement level of this requirement is 'MUST'. In the absence 1082 of this requirement the protocol is exposed to attacks that are easy 1083 to implement and have a high impact. Note that in the absence of this 1084 requirement, the impact is similar to packet manipulation attacks 1085 (Section 3.2.1.), and thus this requirement has the same requirement 1086 level as integrity protection (Section 5.2.). 1088 It is noted that the implementation of this requirement depends on 1089 the topology and properties of the system. 1091 Discussion 1093 While this document does not define specific security solutions, we 1094 note that common practices for protection against MITM attacks use 1095 redundant masters (e.g. [NTPv4]), or redundant paths between the 1096 master and slave (e.g. [DelayAtt]). If one of the time sources 1097 indicates a time value that is significantly different than the other 1098 sources, it is assumed to be erroneous or under attack, and is 1099 therefore ignored. 1101 Thus, MITM attack prevention derives a requirement from the security 1102 mechanism, and a requirement from the network topology. While the 1103 security mechanism should support the ability to detect delay 1104 attacks, it is noted that in some networks it is not possible to 1105 provide the redundancy needed for such a detection mechanism. 1107 5.9. Combining Secured with Unsecured Nodes 1109 Integrating a security mechanism into a time synchronized system is a 1110 complex and expensive process, and hence in some cases may require 1111 incremental deployment, where new equipment supports the security 1112 mechanism, and is required to interoperate with legacy equipment 1113 without the security features. 1115 5.9.1. Secure Mode 1117 Requirement 1119 The security mechanism MUST support a secure mode, where only secured 1120 clocks are permitted to take part in the time protocol. In this mode 1121 every protocol packet received from an unsecured clock MUST be 1122 discarded. 1124 Requirement Level 1126 The requirement level of this requirement is 'MUST' since the full 1127 capacity of the security requirements defined in this document can 1128 only be achieved in secure mode. 1130 Discussion 1132 While the requirement in this subsection is similar to the one in 1133 5.1. , it refers to the secure mode, as opposed to the hybrid mode 1134 presented in the next subsection. 1136 5.9.2. Hybrid Mode 1138 Requirement 1140 The security protocol MAY support a hybrid mode, where both secured 1141 and unsecured clocks are permitted to take part in the protocol. 1143 Requirement Level 1145 The requirement level of this requirement is a 'MAY', since it is not 1146 necessarily required in all systems. This document recommends to 1147 deploy the 'Secure Mode' described in Section 5.9.1. where possible. 1149 Discussion 1151 The hybrid mode allows both secured and unsecured clocks to take part 1152 in the time protocol. NTP, for example, allows a mixture of secured 1153 and unsecured nodes. 1155 Requirement 1157 A master in the hybrid mode SHOULD be a secured clock. 1159 A secured slave in the hybrid mode SHOULD discard all protocol 1160 packets received from unsecured clocks. 1162 Requirement Level 1164 The requirement level of this requirement is a 'SHOULD', since it may 1165 not be applicable to all deployments. For example, a hybrid network 1166 may require the usage of unsecured masters or TCs. 1168 Discussion 1170 This requirement ensures that the existence of unsecured clocks does 1171 not compromise the security provided to secured clocks. Hence, 1172 secured slaves only "trust" protocol packets received from a secured 1173 clock. 1175 An unsecured slave can receive protocol packets either from unsecured 1176 clocks, or from secured clocks. Note that the latter does not apply 1177 when encryption is used. When integrity protection is used, the 1178 unsecured slave can receive secured packets ignoring the integrity 1179 protection. 1181 Note that the security scheme in [NTPv4] with [AutoKey] does not 1182 satisfy this requirement, since nodes prefer the server with the most 1183 accurate clock, which is not necessarily the server that supports 1184 authentication. For example, a stratum 2 server is connected to two 1185 stratum 1 servers, Server A, supporting authentication, and server B, 1186 without authentication. If server B has a more accurate clock than A, 1187 the stratum 2 server chooses server B, in spite of the fact it does 1188 not support authentication. 1190 6. Summary of Requirements 1192 +-----------+---------------------------------------------+--------+ 1193 | Section | Requirement | Type | 1194 +-----------+---------------------------------------------+--------+ 1195 | 5.1. | Authentication & authorization of sender. | MUST | 1196 | +---------------------------------------------+--------+ 1197 | | Authentication & authorization of master. | MUST | 1198 | +---------------------------------------------+--------+ 1199 | | Recursive authentication & authorization. | MUST | 1200 | +---------------------------------------------+--------+ 1201 | | Authentication of slaves. | MUST | 1202 | +---------------------------------------------+--------+ 1203 | | Authorization of slaves. | MAY | 1204 | +---------------------------------------------+--------+ 1205 | | PTP: Authentication of P2P TCs by master. | MUST | 1206 | +---------------------------------------------+--------+ 1207 | | PTP: Authorization of P2P TCs by master. | MAY | 1208 | +---------------------------------------------+--------+ 1209 | | PTP: Authentication & authorization of | MUST | 1210 | | Announce messages. | | 1211 | +---------------------------------------------+--------+ 1212 | | PTP: Authentication & authorization of | MUST | 1213 | | Management messages. | | 1214 | +---------------------------------------------+--------+ 1215 | | PTP: Authentication & authorization of | MAY | 1216 | | Signaling messages. | | 1217 +-----------+---------------------------------------------+--------+ 1218 | 5.2. | Integrity protection. | MUST | 1219 +-----------+---------------------------------------------+--------+ 1220 | 5.3. | Protection from DoS attacks against the | SHOULD | 1221 | | time protocol. | | 1222 +-----------+---------------------------------------------+--------+ 1223 | 5.4. | Replay protection. | MUST | 1224 +-----------+---------------------------------------------+--------+ 1225 | 5.5. | Key freshness. | MUST | 1226 | +---------------------------------------------+--------+ 1227 | | Security association. | SHOULD | 1228 | +---------------------------------------------+--------+ 1229 | | Unicast and multicast associations. | SHOULD | 1230 +-----------+---------------------------------------------+--------+ 1231 | 5.6. | Performance: no degradation in quality of | MUST | 1232 | | time transfer. | | 1233 | +---------------------------------------------+--------+ 1234 | | Performance: computation load. | SHOULD | 1235 | +---------------------------------------------+--------+ 1236 | | Performance: storage. | SHOULD | 1237 | +---------------------------------------------+--------+ 1238 | | Performance: bandwidth. | SHOULD | 1239 +-----------+---------------------------------------------+--------+ 1240 | 5.7. | Confidentiality protection. | MAY | 1241 +-----------+---------------------------------------------+--------+ 1242 | 5.8. | Protection against delay and interception | MUST | 1243 | | attacks. | | 1244 +-----------+---------------------------------------------+--------+ 1245 | 5.9. | Secure mode. | MUST | 1246 | +---------------------------------------------+--------+ 1247 | | Hybrid mode. | MAY | 1248 +-----------+---------------------------------------------+--------+ 1249 Table 2 Summary of Security Requirements 1251 7. Additional security implications 1253 This section discusses additional implications of the interaction 1254 between time protocols and security mechanisms. 1256 This section refers to time protocol security mechanisms, as well as 1257 to "external" security mechanisms, i.e., security mechanisms that are 1258 not strictly related to the time protocol. 1260 7.1. Security and on-the-fly Timestamping 1262 Time protocols often require that protocol packets be modified during 1263 transmission. Both NTP and PTP in one-step mode require clocks to 1264 modify protocol packets based on the time of transmission and/or 1265 reception. 1267 In the presence of a security mechanism, whether encryption or 1268 integrity protection: 1270 o During transmission the encryption and/or integrity protection 1271 MUST be applied after integrating the timestamp into the packet. 1273 To allow high accuracy, timestamping is typically performed as close 1274 to the transmission or reception time as possible. However, since the 1275 security engine must be placed between the timestamping function and 1276 the physical interface, it may introduce non-deterministic latency 1277 that causes accuracy degradation. These performance aspects have been 1278 analyzed in literature, e.g., [1588IPsec] and [Tunnel]. 1280 7.2. PTP: Security and Two-Step Timestamping 1282 PTP supports a two-step mode of operation, where the time of 1283 transmission of protocol packets is communicated without modifying 1284 the packets. As opposed to one-step mode, two-step timestamping can 1285 be performed without the requirement to encrypt after timestamping. 1287 Note that if an encryption mechanism such as IPsec is used, it 1288 presents a challenge to the timestamping mechanism, since time 1289 protocol packets are encrypted when traversing the physical 1290 interface, and are thus impossible to identify. A possible solution 1291 to this problem [IPsecSync] is to include an indication in the 1292 encryption header that identifies time protocol packets. 1294 7.3. Intermediate Clocks 1296 A time protocol allows slaves to receive time information from an 1297 accurate time source. Time information is sent over a path that often 1298 traverses one or more intermediate clocks. 1300 o In NTP, time information originated from a stratum 1 server can be 1301 distributed to stratum 2 servers, and in turn distributed from the 1302 stratum 2 servers to NTP clients. In this case, the stratum 2 1303 servers are a layer of intermediate clocks. These intermediate 1304 clocks are referred to as "secondary servers" in [NTPv4]. 1306 o In PTP, BCs and TCs are intermediate nodes used to improve the 1307 accuracy of time information conveyed between the grandmaster and 1308 the slaves. 1310 A common rule of thumb in network security is that end-to-end 1311 security is the best policy, as it secures the entire path between 1312 the data originator and its receiver. The usage of intermediate nodes 1313 implies that if a security mechanism is deployed in the network, a 1314 hop-by-hop security scheme must be used, since intermediate nodes 1315 must be able to send time information to the slaves, or to modify 1316 time information sent through them. 1318 This inherent property of using intermediate clocks increases the 1319 system's exposure to internal threats, as there is a large number of 1320 nodes that possess the security keys. 1322 Thus, there is a tradeoff between the achievable clock accuracy of a 1323 system, and the robustness of its security solution. On one hand high 1324 clock accuracy calls for hop-by-hop involvement in the protocol, also 1325 known as on-path support. On the other hand, a robust security 1326 solution calls for end-to-end data protection. 1328 7.4. External Security Protocols and Time Protocols 1330 Time protocols are often deployed in systems that use security 1331 mechanisms and protocols. 1333 A typical example is the 3GPP Femtocell network [3GPP], where IPsec 1334 is used for securing traffic between a Femtocell and the Femto 1335 Gateway. In some cases, all traffic between these two nodes may be 1336 secured by IPsec, including the time protocol traffic. This use-case 1337 is thoroughly discussed in [IPsecSync]. 1339 Another typical example is the usage of MACsec encryption ([MACsec]) 1340 in L2 networks that deploy time synchronization [AvbAssum]. 1342 The usage of external security mechanisms may affect time protocols 1343 as follows: 1345 o Timestamping accuracy can be affected, as described in 7.1. 1347 o If traffic is secured between two nodes in the network, no 1348 intermediate clocks can be used between these two nodes. In the 1349 [3GPP] example, if traffic between the Femtocell and the Femto 1350 Gateway is encrypted, then time protocol packets are necessarily 1351 transported over the underlying network without modification, and 1352 thus cannot enjoy the improved accuracy provided by intermediate 1353 clock nodes. 1355 7.5. External Security Services Requiring Time 1357 Cryptographic protocols often use time as an important factor in the 1358 cryptographic algorithm. If a time protocol is compromised, it may 1359 consequently expose the security protocols that rely on it to various 1360 attacks. Two examples are presented in this section. 1362 7.5.1. Timestamped Certificates 1364 Certificate validation requires the sender and receiver to be roughly 1365 time synchronized. Thus, synchronization is required for establishing 1366 security protocols such as IKEv2 and TLS. 1368 An even stronger interdependence between a time protocol and a 1369 security mechanism is defined in [AutoKey], which defines mutual 1370 dependence between the acquired time information, and the 1371 authentication protocol that secures it. This bootstrapping behavior 1372 results from the fact that trusting the received time information 1373 requires a valid certificate, and validating a certificate requires 1374 knowledge of the time. 1376 7.5.2. Time Changes and Replay Attacks 1378 A successful attack on a time protocol may cause the attacked clocks 1379 to go back in time. The erroneous time may expose cryptographic 1380 algorithms that rely on time, as a node may use a key that was 1381 already used in the past and has expired. 1383 8. Issues for Further Discussion 1385 The Key distribution is outside the scope of this document. Although 1386 this is an essential element of any security system, it is outside 1387 the scope of this document. 1389 9. Security Considerations 1391 The security considerations of network timing protocols are presented 1392 throughout this document. 1394 10. IANA Considerations 1396 There are no new IANA considerations implied by this document. 1398 11. Acknowledgments 1400 The authors gratefully acknowledge Stefano Ruffini, Doug Arnold, 1401 Kevin Gross, Dieter Sibold, Dan Grossman, Laurent Montini, Russell 1402 Smiley, and Shawn Emery for their thorough review and helpful 1403 comments. The authors would also like to thank members of the TICTOC 1404 WG for providing feedback on the TICTOC mailing list. 1406 This document was prepared using 2-Word-v2.0.template.dot. 1408 12. References 1410 12.1. Normative References 1412 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1413 Requirement Levels", BCP 14, RFC 2119, March 1997. 1415 [NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W., 1416 "Network Time Protocol Version 4: Protocol and 1417 Algorithms Specification", RFC 5905, June 2010. 1419 [AutoKey] Haberman, B., Mills, D., "Network Time Protocol 1420 Version 4: Autokey Specification", RFC 5906, June 1421 2010. 1423 [IEEE1588] IEEE TC 9 Instrumentation and Measurement Society, 1424 "1588 IEEE Standard for a Precision Clock 1425 Synchronization Protocol for Networked Measurement and 1426 Control Systems Version 2", IEEE Standard, 2008. 1428 12.2. Informative References 1430 [Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R., 1431 "Traps and pitfalls in secure clock synchronization" 1432 in Proceedings of 2007 International Symposium for 1433 Precision Clock Synchronization for Measurement, 1434 Control and Communication, ISPCS 2007, pp. 18-24, 1435 2007. 1437 [TM] T. Mizrahi, "Time synchronization security using IPsec 1438 and MACsec", ISPCS 2011, pp. 38-43, 2011. 1440 [SecPTP] J. Tsang, K. Beznosov, "A security analysis of the 1441 precise time protocol (short paper)," 8th 1442 International Conference on Information and 1443 Communication Security (ICICS 2006), pp. 50-59, 2006. 1445 [SecSen] S. Ganeriwal, C. Popper, S. Capkun, M. B. Srivastava, 1446 "Secure Time Synchronization in Sensor Networks", ACM 1447 Trans. Info. and Sys. Sec., Volume 11, Issue 4, July 1448 2008. 1450 [AvbAssum] D. Pannell, "Audio Video Bridging Gen 2 Assumptions", 1451 IEEE 802.1 AVB Plenary, work in progress, May 2012. 1453 [IPsecSync] Y. Xu, "IPsec security for packet based 1454 synchronization", IETF, draft-xu-tictoc-ipsec- 1455 security-for-synchronization (work in progress), 2011. 1457 [3GPP] 3GPP, "Security of Home Node B (HNB) / Home evolved 1458 Node B (HeNB)", 3GPP TS 33.320 10.4.0 (work in 1459 progress), 2011. 1461 [1588IPsec] A. Treytl, B. Hirschler, "Securing IEEE 1588 by IPsec 1462 tunnels - An analysis", in Proceedings of 2010 1463 International Symposium for Precision Clock 1464 Synchronization for Measurement, Control and 1465 Communication, ISPCS 2010, pp. 83-90, 2010. 1467 [Tunnel] A. Treytl, B. Hirschler, and T. Sauter, "Secure 1468 tunneling of high precision clock synchronisation 1469 protocols and other timestamped data", in Proceedings 1470 of the 8th IEEE International Workshop on Factory 1471 Communication Systems (WFCS), vol. ISBN 978-1-4244- 1472 5461-7, pp. 303-313, 2010. 1474 [DelayAtt] T. Mizrahi, "A Game Theoretic Analysis of Delay 1475 Attacks against Time Synchronization Protocols", 1476 accepted, to appear in Proceedings of the 1477 International IEEE Symposium on Precision Clock 1478 Synchronization for Measurement, Control and 1479 Communication, ISPCS, 2012. 1481 [MACsec] IEEE 802.1AE-2006, "IEEE Standard for Local and 1482 Metropolitan Area Networks - Media Access Control 1483 (MAC) Security", 2006. 1485 [IPsec] S. Kent, K. Seo, "Security Architecture for the 1486 Internet Protocol", IETF, RFC 4301, 2005. 1488 13. Contributing Authors 1490 Karen O'Donoghue 1491 ISOC 1493 Email: odonoghue@isoc.org 1495 Authors' Addresses 1497 Tal Mizrahi 1498 Marvell 1499 6 Hamada St. 1500 Yokneam, 20692 Israel 1502 Email: talmi@marvell.com