idnits 2.17.1 draft-ietf-tictoc-security-requirements-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 21, 2014) is 3565 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TICTOC Working Group T. Mizrahi 2 Internet Draft Marvell 3 Intended status: Informational 4 Expires: January 2015 July 21, 2014 6 Security Requirements of Time Protocols 7 in Packet Switched Networks 8 draft-ietf-tictoc-security-requirements-11.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 January 21, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction ................................................. 3 63 2. Conventions Used in this Document ............................ 5 64 2.1. Terminology ............................................. 5 65 2.2. Abbreviations ........................................... 5 66 2.3. Common Terminology for PTP and NTP ...................... 6 67 2.4. Terms used in this Document ............................. 6 68 3. Security Threats ............................................. 7 69 3.1. Threat Model ............................................ 7 70 3.1.1. Internal vs. External Attackers .................... 7 71 3.1.2. Man in the Middle (MITM) vs. Packet Injector ....... 8 72 3.2. Threat Analysis.......................................... 8 73 3.2.1. Packet Manipulation ................................ 8 74 3.2.2. Spoofing ........................................... 9 75 3.2.3. Replay Attack ...................................... 9 76 3.2.4. Rogue Master Attack ................................ 9 77 3.2.5. Packet Interception and Removal ................... 10 78 3.2.6. Packet Delay Manipulation ......................... 10 79 3.2.7. L2/L3 DoS Attacks ................................. 10 80 3.2.8. Cryptographic Performance Attacks ................. 10 81 3.2.9. DoS Attacks against the Time Protocol ............. 10 82 3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud) . 11 83 3.3. Threat Analysis Summary ................................ 11 84 4. Requirement Levels .......................................... 13 85 5. Security Requirements ....................................... 13 86 5.1. Clock Identity Authentication and Authorization ........ 14 87 5.1.1. Authentication and Authorization of Masters ....... 15 88 5.1.2. Recursive Authentication and Authorization of Masters 89 (Chain of Trust) ......................................... 15 90 5.1.3. Authentication and Authorization of Slaves ........ 16 91 5.1.4. PTP: Authentication and Authorization of P2P TCs by the 92 Master ................................................... 17 93 5.1.5. PTP: Authentication and Authorization of Control 94 Messages ................................................. 18 95 5.2. Protocol Packet Integrity .............................. 19 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 .............. 20 99 5.3. Spoofing Prevention .................................... 20 100 5.4. Availability ........................................... 21 101 5.5. Replay Protection ...................................... 22 102 5.6. Cryptographic Keys and Security Associations ........... 22 103 5.6.1. Key Freshness ..................................... 22 104 5.6.2. Security Association .............................. 23 105 5.6.3. Unicast and Multicast Associations ................ 24 106 5.7. Performance ............................................ 24 107 5.8. Confidentiality......................................... 25 108 5.9. Protection against Packet Delay and Interception Attacks 26 109 5.10. Combining Secured with Unsecured Nodes ................ 27 110 5.10.1. Secure Mode ...................................... 27 111 5.10.2. Hybrid Mode ...................................... 27 112 6. Summary of Requirements ..................................... 28 113 7. Additional security implications ............................ 30 114 7.1. Security and on-the-fly Timestamping ................... 30 115 7.2. PTP: Security and Two-Step Timestamping ................ 30 116 7.3. Intermediate Clocks .................................... 31 117 7.4. External Security Protocols and Time Protocols.......... 32 118 7.5. External Security Services Requiring Time .............. 32 119 7.5.1. Timestamped Certificates .......................... 32 120 7.5.2. Time Changes and Replay Attacks ................... 33 121 8. Issues for Further Discussion ............................... 33 122 9. Security Considerations ..................................... 33 123 10. IANA Considerations......................................... 33 124 11. Acknowledgments ............................................ 33 125 12. References ................................................. 33 126 12.1. Normative References .................................. 33 127 12.2. Informative References ................................ 34 128 13. Contributing Authors ....................................... 35 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 discusses the security aspects of time distribution 139 protocols in packet networks, and focuses on the two most common 140 protocols, the Network Time Protocol [NTPv4] and the Precision Time 141 Protocol (PTP) [IEEE1588]. Note, that although PTP was not defined by 142 the IETF, it is one of the two most common time protocols and hence 143 it is included in the discussion. 145 The Network Time Protocol was defined with an inherent security 146 protocol; [NTPv4] defines a security protocol that is based on a 147 symmetric key authentication scheme, and [AutoKey] presents an 148 alternative security protocol, based on a public key authentication 149 scheme. [IEEE1588] includes an experimental security protocol, 150 defined in Annex K of the standard, but this Annex was never 151 formalized into a fully defined security protocol. 153 While NTP includes an inherent security protocol, the absence of a 154 standard security solution for PTP undoubtedly contributed to the 155 wide deployment of unsecured time synchronization solutions. However, 156 in some cases security mechanisms may not be strictly necessary, 157 e.g., due to other security practices in place, or due to the 158 architecture of the network. A time synchronization security 159 solution, much like any security solution, is comprised of various 160 building blocks, and must be carefully tailored for the specific 161 system it is deployed in. Based on a system-specific threat 162 assessment, the benefits of a security solution must be weighed 163 against the potential risks, and based on this tradeoff an optimal 164 security solution can be selected. 166 The target audience of this document includes: 168 o Timing and networking equipment vendors - can benefit from this 169 document by deriving the security features that should be 170 supported in the time/networking equipment. 172 o Standard development organizations - can use the requirements 173 defined in this document when specifying security mechanisms for a 174 time protocol. 176 o Network operators - can use this document as a reference when 177 designing the network and its security architecture. As stated 178 above, the requirements in this document may be deployed 179 selectively based on a careful per-system threat analysis. 181 This document attempts to add clarity to the time protocol security 182 requirements discussion by addressing a series of questions: 184 (1) What are the threats that need to be addressed for the time 185 protocol, and thus what security services need to be provided? (e.g. 186 a malicious NTP server or PTP master) 188 (2) What external security practices impact the security and 189 performance of time keeping, and what can be done to mitigate these 190 impacts? (e.g. an IPsec tunnel in the time protocol traffic path) 192 (3) What are the security impacts of time protocol practices? (e.g. 193 on-the-fly modification of timestamps) 195 (4) What are the dependencies between other security services and 196 time protocols? (e.g. which comes first - the certificate or the 197 timestamp?) 199 In light of the questions above, this document defines a set of 200 requirements for security solutions for time protocols, focusing on 201 PTP and NTP. 203 2. Conventions Used in this Document 205 2.1. Terminology 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in [KEYWORDS]. 211 This document describes security requirements, and thus requirements 212 are phrased in the document in the form "the security mechanism 213 MUST/SHOULD/...". Note, that the phrasing does not imply that this 214 document defines a specific security mechanism, but defines the 215 requirements with which every security mechanism should comply. 217 2.2. Abbreviations 219 BC Boundary Clock [IEEE1588] 221 DoS Denial of Service 223 MITM Man In The Middle 225 NTP Network Time Protocol [NTPv4] 227 OC Ordinary Clock [IEEE1588] 229 P2P TC Peer-to-Peer Transparent Clock [IEEE1588] 230 PTP Precision Time Protocol [IEEE1588] 232 TC Transparent Clock [IEEE1588] 234 2.3. Common Terminology for PTP and NTP 236 This document refers to both PTP and NTP. For the sake of 237 consistency, throughout the document the term "master" applies to 238 both a PTP master and an NTP server. Similarly, the term "slave" 239 applies to both PTP slaves and NTP clients. The term "protocol 240 packets" refers generically to PTP and NTP messages. 242 2.4. Terms used in this Document 244 o Clock - A node participating in the protocol (either PTP or NTP). 245 A clock can be a master, a slave, or an intermediate clock (see 246 corresponding definitions below). 248 o Control packets - Packets used by the protocol to exchange 249 information between clocks that is not strictly related to the 250 time. NTP uses NTP Control Messages. PTP uses Announce, Signaling 251 and Management messages. 253 o End-to-end security - A security approach where secured packets 254 sent from a source to a destination is not modified by 255 intermediate nodes. 257 o Grandmaster - A master that receives time information from a 258 locally attached clock device, and not through the network. A 259 grandmaster distributes its time to other clocks in the network. 261 o Hop-by-hop security - A security approach where secured packets 262 sent from a source to a destination may be modified by 263 intermediate nodes. In this approach intermediate nodes share the 264 encryption key with the source and destination, allowing them to 265 re-encrypt or re-authenticate modified packets before relaying 266 them to the destination. 268 o Intermediate clock - A clock that receives timing information from 269 a master, and sends timing information to other clocks. 270 In NTP this term refers to an NTP server that is not a Stratum 1 271 server. In PTP this term refers to a BC or a TC. 273 o Master - A clock that generates timing information to other clocks 274 in the network. 275 In NTP 'master' refers to an NTP server. In PTP 'master' refers to 276 a master OC (aka grandmaster) or to a port of a BC that is in the 277 master state. 279 o Protocol packets - Packets used by the time protocol. The 280 terminology used in this document distinguishes between time 281 packets and control packets. 283 o Secured clock - A clock that supports a security mechanism that 284 complies to the requirements in this document. 286 o Slave - A clock that receives timing information from a master. In 287 NTP 'slave' refers to an NTP client. In PTP 'slave' refers to a 288 slave OC, or to a port of a BC that is in the slave state. 290 o Time packets - Protocol packets carrying time information. 292 o Unsecured clock - A clock that does not support a security 293 mechanism according to the requirements in this document. 295 3. Security Threats 297 This section discusses the possible attacker types and analyzes 298 various attacks against time protocols. 300 The literature is rich with security threats of time protocols, e.g., 301 [Traps], [AutoKey], [TM], [SecPTP], and [SecSen]. The threat analysis 302 in this document is mostly based on [TM]. 304 3.1. Threat Model 306 A time protocol can be attacked by various types of attackers. 308 The analysis in this document classifies attackers according to 2 309 criteria, as described in Section 3.1.1. and Section 3.1.2. 311 3.1.1. Internal vs. External Attackers 313 In the context of internal and external attackers, the underlying 314 assumption is that the time protocol is secured either by an 315 encryption or an authentication mechanism, or both. 317 Internal attackers either have access to a trusted segment of the 318 network, or possess the encryption or authentication keys. An 319 internal attack can also be performed by exploiting vulnerabilities 320 in devices; for example, by installing malware, or obtaining 321 credentials to reconfigure the device. Thus, an internal attacker can 322 maliciously tamper with legitimate traffic in the network, as well as 323 generate its own traffic and make it appear legitimate to its 324 attacked nodes. 326 Note that internal attacks are a special case of Byzantine failures, 327 where a node in the system may fail in arbitrary ways; by crashing, 328 by omitting messages, or by malicious behavior. This document focuses 329 on nodes that demonstrate malicious behavior. 331 External attackers, on the other hand, do not have the keys, and have 332 access only to the encrypted or authenticated traffic. 334 Obviously, in the absence of a security mechanism there is no 335 distinction between internal and external attackers, since all 336 attackers are internal in practice. 338 3.1.2. Man in the Middle (MITM) vs. Packet Injector 340 MITM attackers are located in a position that allows interception and 341 modification of in-flight protocol packets. It is assumed that an 342 MITM attacker has physical access to a segment of the network, or has 343 gained control of one of the nodes in the network. 345 A traffic injector is not located in an MITM position, but can attack 346 by generating protocol packets. An injector can reside either within 347 the attacked network, or on an external network that is connected to 348 the attacked network. An injector can also potentially eavesdrop on 349 protocol packets sent as multicast, record them and replay them 350 later. 352 3.2. Threat Analysis 354 3.2.1. Packet Manipulation 356 A packet manipulation attack results when an MITM attacker receives 357 timing protocol packets, alters them and relays them to their 358 destination, allowing the attacker to maliciously tamper with the 359 protocol. This can result in a situation where the time protocol is 360 apparently operational but providing intentionally inaccurate 361 information. 363 3.2.2. Spoofing 365 In spoofing, an injector masquerades as a legitimate node in the 366 network by generating and transmitting protocol packets or control 367 packets. Two typical examples of spoofing attacks: 369 o An attacker can impersonate the master, allowing malicious 370 distribution of false timing information. 372 o An attacker can impersonate a legitimate clock, a slave or an 373 intermediate clock, by sending malicious messages to the master, 374 causing the master to respond to the legitimate clock with 375 protocol packets that are based on the spoofed messages. 376 Consequently, the delay computations of the legitimate clock are 377 based on false information. 379 As with packet manipulation, this attack can result in a situation 380 where the time protocol is apparently operational but providing 381 intentionally inaccurate information. 383 3.2.3. Replay Attack 385 In a replay attack, an attacker records protocol packets and replays 386 them at a later time without any modification. This can also result 387 in a situation where the time protocol is apparently operational but 388 providing intentionally inaccurate information. 390 3.2.4. Rogue Master Attack 392 In a rogue master attack, an attacker causes other nodes in the 393 network to believe it is a legitimate master. As opposed to the 394 spoofing attack, in the Rogue Master attack the attacker does not 395 fake its identity, but rather manipulates the master election process 396 using malicious control packets. For example, in PTP, an attacker can 397 manipulate the Best Master Clock Algorithm (BMCA), and cause other 398 nodes in the network to believe it is the most eligible candidate to 399 be a grandmaster. 401 In PTP, a possible variant of this attack is the rogue TC/BC attack. 402 Similar to the rogue master attack, an attacker can cause victims to 403 believe it is a legitimate TC or BC, allowing the attacker to 404 manipulate the time information forwarded to the victims. 406 3.2.5. Packet Interception and Removal 408 A packet interception and removal attack results when an MITM 409 attacker intercepts and drops protocol packets, preventing the 410 destination node from receiving some or all of the protocol packets. 412 3.2.6. Packet Delay Manipulation 414 In a packet delay manipulation scenario, an MITM attacker receives 415 protocol packets, and relays them to their destination after adding a 416 maliciously computed delay. The attacker can use various delay attack 417 strategies; the added delay can be constant, jittered, or slowly 418 wandering. Each of these strategies has a different impact, but they 419 all effectively manipulate the attacked clock. 421 Note that the victim still receives one copy of each packet, contrary 422 to the replay attack, where some or all of the packets may be 423 received by the victim more than once. 425 3.2.7. L2/L3 DoS Attacks 427 There are many possible Layer 2 and Layer 3 DoS attacks, e.g., IP 428 spoofing, ARP spoofing [Hack], MAC flooding [Anatomy], and many 429 others. As the target's availability is compromised, the timing 430 protocol is affected accordingly. 432 3.2.8. Cryptographic Performance Attacks 434 In cryptographic performance attacks, an attacker transmits fake 435 protocol packets, causing high utilization of the cryptographic 436 engine at the receiver, which attempts to verify the integrity of 437 these fake packets. 439 This DoS attack is applicable to all encryption and authentication 440 protocols. However, when the time protocol uses a dedicated security 441 mechanism implemented in a dedicated cryptographic engine, this 442 attack can be applied to cause DoS specifically to the time protocol. 444 3.2.9. DoS Attacks against the Time Protocol 446 An attacker can attack a clock by sending an excessive number of time 447 protocol packets, thus degrading the victim's performance. This 448 attack can be implemented, for example, using the attacks described 449 in Section 3.2.2. and Section 3.2.4. 451 3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud) 453 Grandmasters receive their time from an external accurate time 454 source, such as an atomic clock or a GPS clock, and then distribute 455 this time to the slaves using the time protocol. 457 Time source attack are aimed at the accurate time source of the 458 grandmaster. For example, if the grandmaster uses a GPS based clock 459 as its reference source, an attacker can jam the reception of the GPS 460 signal, or transmit a signal similar to one from a GPS satellite, 461 causing the grandmaster to use a false reference time. 463 Note that this attack is outside the scope of the time protocol. 464 While various security measures can be taken to mitigate this attack, 465 these measures are outside the scope of the security requirements 466 defined in this document. 468 3.3. Threat Analysis Summary 470 The two key factors to a threat analysis are the impact and the 471 likelihood of each of the analyzed attacks. 473 Table 1 summarizes the security attacks presented in Section 3.2. 474 For each attack, the table specifies its impact, and its 475 applicability to each of the attacker types presented in Section 3.1. 477 Table 1 clearly shows the distinction between external and internal 478 attackers, and motivates the usage of authentication and integrity 479 protection, significantly reducing the impact of external attackers. 481 The Impact column provides an intuitive measure of the severity of 482 each attack, and the relevant Attacker Type columns provide an 483 intuition about how difficult each attack is to implement, and hence 484 about the likelihood of each attack. 486 The impact column in Table 1 can have one of 3 values: 488 o DoS - the attack causes denial of service to the attacked node, 489 the impact of which is not restricted to the time protocol. 491 o Accuracy degradation - the attack yields a degradation in the 492 slave accuracy, but does not completely compromise the slaves' 493 time and frequency. 495 o False time - slaves align to a false time or frequency value due 496 to the attack. Note that if the time protocol aligns to a false 497 time, it may cause DoS to other applications that rely on accurate 498 time. However, for the purpose of the analysis in this section we 499 distinguish this implication from 'DoS', which refers to a DoS 500 attack that is not necessarily aimed at the time protocol. 501 All attacks that have a '+' for 'False Time' implicitly have a '+' 502 for 'Accuracy Degradation'. 503 Note, that 'False Time' necessarily implies 'Accuracy 504 Degradation'. However, two different terms are used, indicating 505 two levels of severity. 507 The Attacker Type columns refer to the 4 possible combinations of the 508 attacker types defined in Section 3.1. 510 +-----------------------------+-------------------++-------------------+ 511 | Attack | Impact || Attacker Type | 512 | +-----+--------+----++---------+---------+ 513 | |False|Accuracy| ||Internal |External | 514 | |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.| 515 +-----------------------------+-----+--------+----++----+----+----+----+ 516 |Manipulation | + | | || + | | | | 517 +-----------------------------+-----+--------+----++----+----+----+----+ 518 |Spoofing | + | | || + | + | | | 519 +-----------------------------+-----+--------+----++----+----+----+----+ 520 |Replay attack | + | | || + | + | | | 521 +-----------------------------+-----+--------+----++----+----+----+----+ 522 |Rogue master attack | + | | || + | + | | | 523 +-----------------------------+-----+--------+----++----+----+----+----+ 524 |Interception and removal | | + | + || + | | + | | 525 +-----------------------------+-----+--------+----++----+----+----+----+ 526 |Packet delay manipulation | + | | || + | | + | | 527 +-----------------------------+-----+--------+----++----+----+----+----+ 528 |L2/L3 DoS attacks | | | + || + | + | + | + | 529 +-----------------------------+-----+--------+----++----+----+----+----+ 530 |Crypt. performance attacks | | | + || + | + | + | + | 531 +-----------------------------+-----+--------+----++----+----+----+----+ 532 |Time protocol DoS attacks | | | + || + | + | | | 533 +-----------------------------+-----+--------+----++----+----+----+----+ 534 |Master time source attack | + | | || + | + | + | + | 535 |(e.g., GPS spoofing) | | | || | | | | 536 +-----------------------------+-----+--------+----++----+----+----+----+ 537 Table 1 Threat Analysis - Summary 539 The threats discussed in this section provide the background for the 540 security requirements presented in Section 5. 542 4. Requirement Levels 544 The security requirements are presented in Section 5. Each 545 requirement is defined with a requirement level, in accordance with 546 the requirement levels defined in Section 2.1. 548 The requirement levels in this document are affected by the following 549 factors: 551 o Impact: 552 The possible impact of not implementing the requirement, as 553 illustrated in the 'impact' column of Table 1. 554 For example, a requirement that addresses a threat that can be 555 implemented by an external injector is typically a 'MUST', since 556 the threat can be implemented by all the attacker types analyzed 557 in Section 3.1. 559 o Difficulty of the corresponding attack: 560 The level of difficulty of the possible attacks that become 561 possible by not implementing the requirement. The level of 562 difficulty is reflected in the 'Attacker Type' column of Table 1. 563 For example, a requirement that addresses a threat that only 564 compromises the availability of the protocol is typically no more 565 than a 'SHOULD'. 567 o Practical considerations: 568 Various practical factors that may affect the requirement. 569 For example, if a requirement is very difficult to implement, or 570 is applicable to very specific scenarios, these factors may reduce 571 the requirement level. 573 Section 5. lists the requirements. For each requirement there is a 574 short explanation detailing the reason for its requirement level. 576 5. Security Requirements 578 This section defines a set of security requirements. These 579 requirements are phrased in the form "the security mechanism 580 MUST/SHOULD/MAY...". However, this document does not specify how 581 these requirements can be met. While these requirements can be 582 satisfied by defining explicit security mechanisms for time 583 protocols, at least a subset of the requirements can be met by 584 applying common security practices to the network or by using 585 existing security protocols, such as [IPsec] or [MACsec]. Thus, 586 security solutions that address these requirements are outside the 587 scope of this document. 589 5.1. Clock Identity Authentication and Authorization 591 Requirement 593 The security mechanism MUST support authentication. 595 Requirement 597 The security mechanism MUST support authorization. 599 Requirement Level 601 The requirements in this subsection address the spoofing attack 602 (Section 3.2.2.), and the rogue master attack (Section 3.2.4.). 604 The requirement level of these requirements is 'MUST' since in the 605 absence of these requirements the protocol is exposed to attacks that 606 are easy to implement and have a high impact. 608 Discussion 610 Authentication refers to verifying the identity of the peer clock. 611 Authorization, on the other hand, refers to verifying that the peer 612 clock is permitted to play the role that it plays in the protocol. 613 For example, some nodes may be permitted to be masters, while other 614 nodes are only permitted to be slaves or TCs. 616 Authentication is typically implemented by means of a cryptographic 617 signature, allowing to verify the identity of the sender. 618 Authorization requires clocks to maintain a list of authorized 619 clocks, or a "black list" of clocks that should be denied service or 620 revoked. 622 It is noted that while the security mechanism is required to provide 623 an authorization mechanism, the deployment of such a mechanism 624 depends on the nature of the network. For example, a network that 625 deploys PTP may consist of a set of identical OCs, where all clocks 626 are equally permitted to be a master. In such a network an 627 authorization mechanism may not be necessary. 629 The following subsections describe 5 distinct cases of clock 630 authentication. 632 5.1.1. Authentication and Authorization of Masters 634 Requirement 636 The security mechanism MUST support an authentication mechanism, 637 allowing slaves to authenticate the identity of masters. 639 Requirement 641 The authentication mechanism MUST allow slaves to verify that the 642 authenticated master is authorized to be a master. 644 Requirement Level 646 The requirements in this subsection address the spoofing attack 647 (Section 3.2.2.), and the rogue master attack (Section 3.2.4.). 649 The requirement level of these requirements is 'MUST' since in the 650 absence of these requirements the protocol is exposed to attacks that 651 are easy to implement and have a high impact. 653 Discussion 655 Clocks authenticate masters in order to ensure the authenticity of 656 the time source. It is important for a slave to verify the identity 657 of the master, as well as to verify that the master is indeed 658 authorized to be a master. 660 5.1.2. Recursive Authentication and Authorization of Masters (Chain of 661 Trust) 663 Requirement 665 The security mechanism MUST support recursive authentication and 666 authorization of the master, to be used in cases where time 667 information is conveyed through intermediate clocks. 669 Requirement Level 671 The requirement in this subsection addresses the spoofing attack 672 (Section 3.2.2.), and the rogue master attack (Section 3.2.4.). 674 The requirement level of this requirement is 'MUST' since in the 675 absence of this requirement the protocol is exposed to attacks that 676 are easy to implement and have a high impact. 678 Discussion 679 In some cases a slave is connected to an intermediate clock, that is 680 not the primary time source. For example, in PTP a slave can be 681 connected to a Boundary Clock (BC) or a Transparent Clock (TC), which 682 in turn is connected to a grandmaster. A similar example in NTP is 683 when a client is connected to a stratum 2 server, which is connected 684 to a stratum 1 server. In both the PTP and the NTP cases, the slave 685 authenticates the intermediate clock, and the intermediate clock 686 authenticates the grandmaster. This recursive authentication process 687 is referred to in [AutoKey] as proventication. 689 Specifically in PTP, this requirement implies that if a slave 690 receives time information through a TC, it must authenticate the TC 691 it is attached to, as well as authenticate the master it receives the 692 time information from, as per Section 5.1.1. Similarly, if a TC 693 receives time information through an attached TC, it must 694 authenticate the attached TC. 696 5.1.3. Authentication and Authorization of Slaves 698 Requirement 700 The security mechanism MAY provide a means for a master to 701 authenticate its slaves. 703 Requirement 705 The security mechanism MAY provide a means for a master to verify 706 that the sender of a protocol packet is authorized to send a packet 707 of this type. 709 Requirement Level 711 The requirement in this subsection prevents DoS attacks against the 712 master (Section 3.2.9.). 714 The requirement level of this requirement is 'MAY' since: 716 o Its low impact, i.e., in the absence of this requirement the 717 protocol is only exposed to DoS. 719 o Practical considerations: requiring an NTP server to authenticate 720 its clients may significantly impose on the server's performance. 722 Note that while the requirement level of this requirement is 'MAY', 723 the requirement in Section 5.1.1. is 'MUST'; the security mechanism 724 must provide a means for authentication and authorization, with an 725 emphasis on the master. Authentication and authorization of slaves is 726 specified in this subsection as 'MAY'. 728 Discussion 730 Slaves and intermediate clocks are authenticated by masters in order 731 to verify that they are authorized to receive timing services from 732 the master. 734 Authentication of slaves prevents unauthorized clocks from receiving 735 time services. Preventing the master from serving unauthorized clocks 736 can help in mitigating DoS attacks against the master. Note that the 737 authentication of slaves might put a higher load on the master than 738 serving the unauthorized clock, and hence this requirement is a MAY. 740 5.1.4. PTP: Authentication and Authorization of P2P TCs by the Master 742 Requirement 744 The security mechanism for PTP MAY provide a means for a master to 745 authenticate the identity of the P2P TCs directly connected to it. 747 Requirement 749 The security mechanism for PTP MAY provide a means for a master to 750 verify that P2P TCs directly connected to it are authorized to be 751 TCs. 753 Requirement Level 755 The requirement in this subsection prevents DoS attacks against the 756 master (Section 3.2.9.). 758 The requirement level of this requirement is 'MAY' for the same 759 reasons specified in Section 5.1.3. 761 Discussion 763 P2P TCs that are one hop from the master use the PDelay_Req and 764 PDelay_Resp handshake to compute the link delay between the master 765 and TC. These TCs are authenticated by the master. 767 Authentication of TCs, much like authentication of slaves, reduces 768 unnecessary load on the master and peer TCs, by preventing the master 769 from serving unauthorized clocks. 771 5.1.5. PTP: Authentication and Authorization of Control Messages 773 Requirement 775 The security mechanism for PTP MUST support authentication of 776 Announce messages. The authentication mechanism MUST also verify that 777 the sender is authorized to be a master. 779 Requirement 781 The security mechanism for PTP MUST support authentication and 782 authorization of Management messages. 784 Requirement 786 The security mechanism MAY support authentication and authorization 787 of Signaling messages. 789 Requirement Level 791 The requirements in this subsection address the spoofing attack 792 (Section 3.2.2.), and the rogue master attack (Section 3.2.4.). 794 The requirement level of the first two requirements is 'MUST' since 795 in the absence of these requirements the protocol is exposed to 796 attacks that are easy to implement and have a high impact. 798 The requirement level of the third requirement is 'MAY' since its 799 impact greatly depends on the application for which the Signaling 800 messages are used for. 802 Discussion 804 Master election is performed in PTP using the Best Master Clock 805 Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock 806 attributes using Announce messages, and the best master is elected 807 based on the information gathered from all the candidates. Announce 808 messages must be authenticated in order to prevent rogue master 809 attacks (Section 3.2.4.). Note, that this subsection specifies a 810 requirement that is not necessarily included in Section 5.1.1. or in 811 Section 5.1.3. , since the BMCA is initiated before clocks have been 812 defined as masters or slaves. 814 Management messages are used to monitor or configure PTP clocks. 815 Malicious usage of Management messages enables various attacks, such 816 as the rogue master attack, or DoS attack. 818 Signaling messages are used by PTP clocks to exchange information 819 that is not strictly related to time information or to master 820 selection, such as unicast negotiation. Authentication and 821 authorization of Signaling message may be required in some systems, 822 depending on the application these messages are used for. 824 5.2. Protocol Packet Integrity 826 Requirement 828 The security mechanism MUST protect the integrity of protocol 829 packets. 831 Requirement Level 833 The requirement in this subsection addresses the packet manipulation 834 attack (Section 3.2.1.). 836 The requirement level of this requirement is 'MUST' since in the 837 absence of this requirement the protocol is exposed to attacks that 838 are easy to implement and have high impact. 840 Discussion 842 While Section 5.1. refers to ensuring the identity an authorization 843 of the source of a protocol packet, this subsection refers to 844 ensuring that the packet arrived intact. The integrity protection 845 mechanism ensures the authenticity and completeness of data from the 846 data originator. 848 Integrity protection is typically implemented by means of an 849 Integrity Check Value (ICV) that is included in protocol packets and 850 is verified by the receiver. 852 5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 854 Specifically in PTP, when protocol packets are subject to 855 modification by TCs, the integrity protection can be enforced in one 856 of two approaches, end-to-end or hop-by-hop. 858 5.2.1.1. Hop-by-Hop Integrity Protection 860 Each hop that needs to modify a protocol packet: 862 o Verifies its integrity. 864 o Modifies the packet, i.e., modifies the correctionField. 865 Note: Transparent Clocks (TCs) improve the end-to-end accuracy by 866 updating a "correctionField" (clause 6.5 in [IEEE1588]) in the PTP 867 packet by adding the latency caused by the current TC. 869 o Re-generates the integrity protection, e.g., re-computes a Message 870 Authentication Code. 872 In the hop-by-hop approach, the integrity of protocol packets is 873 protected by induction on the path from the originator to the 874 receiver. 876 This approach is simple, but allows rogue TCs to modify protocol 877 packets. 879 5.2.1.2. End-to-End Integrity Protection 881 In this approach, the integrity protection is maintained on the path 882 from the originator of a protocol packet to the receiver. This allows 883 the receiver to directly validate the protocol packet without the 884 ability of intermediate TCs to manipulate the packet. 886 Since TCs need to modify the correctionField, a separate integrity 887 protection mechanism is used specifically for the correctionField. 889 The end-to-end approach limits the TC's impact to the correctionField 890 alone, while the rest of the protocol packet is protected on an end- 891 to-end basis. It should be noted that this approach is more difficult 892 to implement than the hop-by-hop approach, as it requires the 893 correctionField to be protected separately from the other fields of 894 the packet, possibly using different cryptographic mechanisms and 895 keys. 897 5.3. Spoofing Prevention 899 Requirement 901 The security mechanism MUST provide a means to prevent master 902 spoofing. 904 Requirement 906 The security mechanism MUST provide a means to prevent slave 907 spoofing. 909 Requirement 910 PTP: The security mechanism MUST provide a means to prevent P2P TC 911 spoofing. 913 Requirement Level 915 The requirements in this subsection address spoofing attacks (Section 916 3.2.2.). As described in Section 3.2.2. , when these requirements 917 are not met, the attack may have a high impact, causing slaves to 918 rely on false time information. Thus, the requirement level is 919 'MUST'. 921 Discussion 923 Spoofing attacks may take various different forms, and can 924 potentially cause significant impact. In a master spoofing attack, 925 the attacker causes slaves to receive false information about the 926 current time by masquerading as the master. 928 By spoofing a slave or an intermediate node (the second example of 929 Section 3.2.2.), an attacker can tamper with the slaves' delay 930 computations. These attacks can be mitigated by an authentication 931 mechanism (Section 5.1.3. and 5.1.4.), or by other means, for 932 example, a PTP Delay_Req can include a Message Authentication Code 933 (MAC) that is included in the corresponding Delay_Resp message, 934 allowing the slave to verify that the Delay_Resp was not sent in 935 response to a spoofed message. 937 5.4. Availability 939 Requirement 941 The security mechanism SHOULD include measures to mitigate DoS 942 attacks against the time protocol. 944 Requirement Level 946 The requirement in this subsection prevents DoS attacks against the 947 protocol (Section 3.2.9.). 949 The requirement level of this requirement is 'SHOULD' due to its low 950 impact, i.e., in the absence of this requirement the protocol is only 951 exposed to DoS. 953 Discussion 955 The protocol availability can be compromised by several different 956 attacks. An attacker can inject protocol packets to implement the 957 spoofing attack (Section 3.2.2.) or the rogue master attack (Section 958 3.2.4.), causing DoS to the victim (Section 3.2.9.). 960 An authentication mechanism (Section 5.1.) limits these attacks 961 strictly to internal attackers, and thus prevents external attackers 962 from performing them. Hence, the requirements of Section 5.1. can be 963 used to mitigate this attack. Note, that Section 5.1. addresses a 964 wider range of threats, whereas the current section is focused on 965 availability. 967 The DoS attacks described in Section 3.2.7. are performed at lower 968 layers than the time protocol layer, and are thus outside the scope 969 of the security requirements defined in this document. 971 5.5. Replay Protection 973 Requirement 975 The security mechanism MUST include a replay prevention mechanism. 977 Requirement Level 979 The requirement in this subsection prevents replay attacks (Section 980 3.2.3.). 982 The requirement level of this requirement is 'MUST' since in the 983 absence of this requirement the protocol is exposed to attacks that 984 are easy to implement and have a high impact. 986 Discussion 988 The replay attack (Section 3.2.3.) can compromise both the integrity 989 and availability of the protocol. Common encryption and 990 authentication mechanisms include replay prevention mechanisms that 991 typically use a monotonously increasing packet sequence number. 993 5.6. Cryptographic Keys and Security Associations 995 5.6.1. Key Freshness 997 Requirement 999 The cryptographic keys MUST be refreshed frequently. 1001 Requirement Level 1002 The requirement level of this requirement is 'MUST' since key 1003 freshness is an essential property for cryptographic algorithms, as 1004 discussed below. 1006 Discussion 1008 Key freshness guarantees that both sides share a common updated 1009 secret key. It also helps in preventing replay attacks. Thus, it is 1010 important for keys to be refreshed frequently. Note that the term 1011 'frequently' is used without a quantitative requirement, as the 1012 precise frequency requirement should be considered on a per-system 1013 basis, based on the threats and system requirements. 1015 5.6.2. Security Association 1017 Requirement 1019 The security protocol SHOULD support a security association protocol 1020 where: 1022 o Two or more clocks authenticate each other. 1024 o The clocks generate and agree on a cryptographic session key. 1026 Requirement 1028 Each instance of the association protocol SHOULD produce a different 1029 session key. 1031 Requirement Level 1033 The requirement level of this requirement is 'SHOULD' since it may be 1034 expensive in terms of performance, especially in low-cost clocks. 1036 Discussion 1038 The security requirements in Section 5.1. and Section 5.2. require 1039 usage of cryptographic mechanisms, deploying cryptographic keys. A 1040 security association (e.g., [IPsec]) is an important building block 1041 in these mechanisms. 1043 It should be noted that in some cases different security association 1044 mechanisms may be used at different levels of clock hierarchies. For 1045 example, the association between a Stratum 2 clock and a Stratum 3 1046 clock in NTP may have different characteristics than an association 1047 between two clocks at the same stratum level. On a related note, in 1048 some cases a hybrid solution may be used, where a subset of the 1049 network is not secured at all (see Section 5.10.2.). 1051 5.6.3. Unicast and Multicast Associations 1053 Requirement 1055 The security mechanism SHOULD support security association protocols 1056 for unicast and for multicast associations. 1058 Requirement Level 1060 The requirement level of this requirement is 'SHOULD' since it may be 1061 expensive in terms of performance, especially for low-cost clocks. 1063 Discussion 1065 A unicast protocol requires an association protocol between two 1066 clocks, whereas a multicast protocol requires an association protocol 1067 among two or more clocks, where one of the clocks is a master. 1069 5.7. Performance 1071 Requirement 1073 The security mechanism MUST be designed in such a way that it does 1074 not significantly degrade the quality of the time transfer. 1076 Requirement 1078 The mechanism SHOULD minimize computational load. 1080 Requirement 1082 The mechanism SHOULD minimize storage requirements of client state in 1083 the master. 1085 Requirement 1087 The mechanism SHOULD minimize the bandwidth overhead required by the 1088 security protocol. 1090 Requirement Level 1092 While the quality of the time transfer is clearly a 'MUST', the other 1093 3 performance requirements are 'SHOULD', since some systems may be 1094 more sensitive to resource consumption than others, and hence these 1095 requirements should be considered on a per-system basis. 1097 Discussion 1099 Performance efficiency is important since client restrictions often 1100 dictate a low processing and memory footprint, and because the server 1101 may have extensive fan-out. 1103 Note that the performance requirements refer to a time-protocol- 1104 specific security mechanism. In systems where a security protocol is 1105 used for other types of traffic as well, this document does not place 1106 any performance requirements on the security protocol performance. 1107 For example, if IPsec encryption is used for securing all information 1108 between the master and slave node, including information that is not 1109 part of the time protocol, the requirements in this subsection are 1110 not necessarily applicable. 1112 5.8. Confidentiality 1114 Requirement 1116 The security mechanism MAY provide confidentiality protection of the 1117 protocol packets. 1119 Requirement Level 1121 The requirement level of this requirement is 'MAY' since it does not 1122 prevent severe threats, as discussed below. 1124 Discussion 1126 In the context of time protocols, confidentiality is typically of low 1127 importance, since timing information is typically not considered 1128 secret information. 1130 Confidentiality can play an important role when service providers 1131 charge their customers for time synchronization services, and thus an 1132 encryption mechanism can prevent eavesdroppers from obtaining the 1133 service without payment. Note that these cases are, for now, rather 1134 esoteric. 1136 Confidentiality can also prevent an MITM attacker from identifying 1137 protocol packets. Thus, confidentiality can assist in protecting the 1138 timing protocol against MITM attacks such as packet delay (Section 1139 3.2.6.), manipulation and interception and removal attacks. Note, 1140 that time protocols have predictable behavior even after encryption, 1141 such as packet transmission rates and packet lengths. Additional 1142 measures can be taken to mitigate encrypted traffic analysis by 1143 random padding of encrypted packets and by adding random dummy 1144 packets. Nevertheless, encryption does not prevent such MITM attacks, 1145 but rather makes these attacks more difficult to implement. 1147 5.9. Protection against Packet Delay and Interception Attacks 1149 Requirement 1151 The security mechanism MUST include means to protect the protocol 1152 from MITM attacks that degrade the clock accuracy. 1154 Requirement Level 1156 The requirements in this subsection address MITM attacks such as the 1157 packet delay attack (Section 3.2.6.) and packet interception attacks 1158 (Section 3.2.5. and Section 3.2.1.). 1160 The requirement level of this requirement is 'MUST'. In the absence 1161 of this requirement the protocol is exposed to attacks that are easy 1162 to implement and have a high impact. Note that in the absence of this 1163 requirement, the impact is similar to packet manipulation attacks 1164 (Section 3.2.1.), and thus this requirement has the same requirement 1165 level as integrity protection (Section 5.2.). 1167 It is noted that the implementation of this requirement depends on 1168 the topology and properties of the system. 1170 Discussion 1172 While this document does not define specific security solutions, we 1173 note that common practices for protection against MITM attacks use 1174 redundant masters (e.g. [NTPv4]), or redundant paths between the 1175 master and slave (e.g. [DelayAtt]). If one of the time sources 1176 indicates a time value that is significantly different than the other 1177 sources, it is assumed to be erroneous or under attack, and is 1178 therefore ignored. 1180 Thus, MITM attack prevention derives a requirement from the security 1181 mechanism, and a requirement from the network topology. While the 1182 security mechanism should support the ability to detect delay 1183 attacks, it is noted that in some networks it is not possible to 1184 provide the redundancy needed for such a detection mechanism. 1186 5.10. Combining Secured with Unsecured Nodes 1188 Integrating a security mechanism into a time synchronized system is a 1189 complex and expensive process, and hence in some cases may require 1190 incremental deployment, where new equipment supports the security 1191 mechanism, and is required to interoperate with legacy equipment 1192 without the security features. 1194 5.10.1. Secure Mode 1196 Requirement 1198 The security mechanism MUST support a secure mode, where only secured 1199 clocks are permitted to take part in the time protocol. In this mode 1200 every protocol packet received from an unsecured clock MUST be 1201 discarded. 1203 Requirement Level 1205 The requirement level of this requirement is 'MUST' since the full 1206 capacity of the security requirements defined in this document can 1207 only be achieved in secure mode. 1209 Discussion 1211 While the requirement in this subsection is similar to the one in 1212 5.1. , it refers to the secure mode, as opposed to the hybrid mode 1213 presented in the next subsection. 1215 5.10.2. Hybrid Mode 1217 Requirement 1219 The security protocol SHOULD support a hybrid mode, where both 1220 secured and unsecured clocks are permitted to take part in the 1221 protocol. 1223 Requirement Level 1225 The requirement level of this requirement is a 'SHOULD'; on one hand 1226 hybrid mode enables a gradual transition from unsecured to secured 1227 mode, which is especially important in large-scaled deployments. On 1228 the other hand, hybrid mode is not required in all systems; this 1229 document recommends to deploy the 'Secure Mode' described in Section 1230 5.10.1. where possible. 1232 Discussion 1233 The hybrid mode allows both secured and unsecured clocks to take part 1234 in the time protocol. NTP, for example, allows a mixture of secured 1235 and unsecured nodes. 1237 Requirement 1239 A master in the hybrid mode SHOULD be a secured clock. 1241 A secured slave in the hybrid mode SHOULD discard all protocol 1242 packets received from unsecured clocks. 1244 Requirement Level 1246 The requirement level of this requirement is a 'SHOULD', since it may 1247 not be applicable to all deployments. For example, a hybrid network 1248 may require the usage of unsecured masters or TCs. 1250 Discussion 1252 This requirement ensures that the existence of unsecured clocks does 1253 not compromise the security provided to secured clocks. Hence, 1254 secured slaves only "trust" protocol packets received from a secured 1255 clock. 1257 An unsecured slave can receive protocol packets either from unsecured 1258 clocks, or from secured clocks. Note that the latter does not apply 1259 when encryption is used. When integrity protection is used, the 1260 unsecured slave can receive secured packets ignoring the integrity 1261 protection. 1263 Note that the security scheme in [NTPv4] with [AutoKey] does not 1264 satisfy this requirement, since nodes prefer the server with the most 1265 accurate clock, which is not necessarily the server that supports 1266 authentication. For example, a stratum 2 server is connected to two 1267 stratum 1 servers, Server A, supporting authentication, and server B, 1268 without authentication. If server B has a more accurate clock than A, 1269 the stratum 2 server chooses server B, in spite of the fact it does 1270 not support authentication. 1272 6. Summary of Requirements 1274 +-----------+---------------------------------------------+--------+ 1275 | Section | Requirement | Type | 1276 +-----------+---------------------------------------------+--------+ 1277 | 5.1. | Authentication & authorization of sender. | MUST | 1278 | +---------------------------------------------+--------+ 1279 | | Authentication & authorization of master. | MUST | 1280 | +---------------------------------------------+--------+ 1281 | | Recursive authentication & authorization. | MUST | 1282 | +---------------------------------------------+--------+ 1283 | | Authentication & authorization of slaves. | MAY | 1284 | +---------------------------------------------+--------+ 1285 | | PTP: Authentication & authorization of | MAY | 1286 | | P2P TCs by master. | | 1287 | +---------------------------------------------+--------+ 1288 | | PTP: Authentication & authorization of | MUST | 1289 | | Announce messages. | | 1290 | +---------------------------------------------+--------+ 1291 | | PTP: Authentication & authorization of | MUST | 1292 | | Management messages. | | 1293 | +---------------------------------------------+--------+ 1294 | | PTP: Authentication & authorization of | MAY | 1295 | | Signaling messages. | | 1296 +-----------+---------------------------------------------+--------+ 1297 | 5.2. | Integrity protection. | MUST | 1298 +-----------+---------------------------------------------+--------+ 1299 | 5.3. | Spoofing prevention. | MUST | 1300 +-----------+---------------------------------------------+--------+ 1301 | 5.4. | Protection from DoS attacks against the | SHOULD | 1302 | | time protocol. | | 1303 +-----------+---------------------------------------------+--------+ 1304 | 5.5. | Replay protection. | MUST | 1305 +-----------+---------------------------------------------+--------+ 1306 | 5.6. | Key freshness. | MUST | 1307 | +---------------------------------------------+--------+ 1308 | | Security association. | SHOULD | 1309 | +---------------------------------------------+--------+ 1310 | | Unicast and multicast associations. | SHOULD | 1311 +-----------+---------------------------------------------+--------+ 1312 | 5.7. | Performance: no degradation in quality of | MUST | 1313 | | time transfer. | | 1314 | +---------------------------------------------+--------+ 1315 | | Performance: computation load. | SHOULD | 1316 | +---------------------------------------------+--------+ 1317 | | Performance: storage. | SHOULD | 1318 | +---------------------------------------------+--------+ 1319 | | Performance: bandwidth. | SHOULD | 1320 +-----------+---------------------------------------------+--------+ 1321 | 5.8. | Confidentiality protection. | MAY | 1322 +-----------+---------------------------------------------+--------+ 1323 | 5.9. | Protection against delay and interception | MUST | 1324 | | attacks. | | 1325 +-----------+---------------------------------------------+--------+ 1326 | 5.10. | Secure mode. | MUST | 1327 | +---------------------------------------------+--------+ 1328 | | Hybrid mode. | SHOULD | 1329 +-----------+---------------------------------------------+--------+ 1330 Table 2 Summary of Security Requirements 1332 7. Additional security implications 1334 This section discusses additional implications of the interaction 1335 between time protocols and security mechanisms. 1337 This section refers to time protocol security mechanisms, as well as 1338 to "external" security mechanisms, i.e., security mechanisms that are 1339 not strictly related to the time protocol. 1341 7.1. Security and on-the-fly Timestamping 1343 Time protocols often require that protocol packets be modified during 1344 transmission. Both NTP and PTP in one-step mode require clocks to 1345 modify protocol packets based on the time of transmission and/or 1346 reception. 1348 In the presence of a security mechanism, whether encryption or 1349 integrity protection: 1351 o During transmission the encryption and/or integrity protection 1352 MUST be applied after integrating the timestamp into the packet. 1354 To allow high accuracy, timestamping is typically performed as close 1355 to the transmission or reception time as possible. However, since the 1356 security engine must be placed between the timestamping function and 1357 the physical interface, it may introduce non-deterministic latency 1358 that causes accuracy degradation. These performance aspects have been 1359 analyzed in literature, e.g., [1588IPsec] and [Tunnel]. 1361 7.2. PTP: Security and Two-Step Timestamping 1363 PTP supports a two-step mode of operation, where the time of 1364 transmission of protocol packets is communicated without modifying 1365 the packets. As opposed to one-step mode, two-step timestamping can 1366 be performed without the requirement to encrypt after timestamping. 1368 Note that if an encryption mechanism such as IPsec is used, it 1369 presents a challenge to the timestamping mechanism, since time 1370 protocol packets are encrypted when traversing the physical 1371 interface, and are thus impossible to identify. A possible solution 1372 to this problem [IPsecSync] is to include an indication in the 1373 encryption header that identifies time protocol packets. 1375 7.3. Intermediate Clocks 1377 A time protocol allows slaves to receive time information from an 1378 accurate time source. Time information is sent over a path that often 1379 traverses one or more intermediate clocks. 1381 o In NTP, time information originated from a stratum 1 server can be 1382 distributed to stratum 2 servers, and in turn distributed from the 1383 stratum 2 servers to NTP clients. In this case, the stratum 2 1384 servers are a layer of intermediate clocks. These intermediate 1385 clocks are referred to as "secondary servers" in [NTPv4]. 1387 o In PTP, BCs and TCs are intermediate nodes used to improve the 1388 accuracy of time information conveyed between the grandmaster and 1389 the slaves. 1391 A common rule of thumb in network security is that end-to-end 1392 security is the best policy, as it secures the entire path between 1393 the data originator and its receiver. The usage of intermediate nodes 1394 implies that if a security mechanism is deployed in the network, a 1395 hop-by-hop security scheme must be used, since intermediate nodes 1396 must be able to send time information to the slaves, or to modify 1397 time information sent through them. 1399 This inherent property of using intermediate clocks increases the 1400 system's exposure to internal threats, as there is a large number of 1401 nodes that possess the security keys. 1403 Thus, there is a tradeoff between the achievable clock accuracy of a 1404 system, and the robustness of its security solution. On one hand high 1405 clock accuracy calls for hop-by-hop involvement in the protocol, also 1406 known as on-path support. On the other hand, a robust security 1407 solution calls for end-to-end data protection. 1409 7.4. External Security Protocols and Time Protocols 1411 Time protocols are often deployed in systems that use security 1412 mechanisms and protocols. 1414 A typical example is the 3GPP Femtocell network [3GPP], where IPsec 1415 is used for securing traffic between a Femtocell and the Femto 1416 Gateway. In some cases, all traffic between these two nodes may be 1417 secured by IPsec, including the time protocol traffic. This use-case 1418 is thoroughly discussed in [IPsecSync]. 1420 Another typical example is the usage of MACsec encryption ([MACsec]) 1421 in L2 networks that deploy time synchronization [AvbAssum]. 1423 The usage of external security mechanisms may affect time protocols 1424 as follows: 1426 o Timestamping accuracy can be affected, as described in 7.1. 1428 o If traffic is secured between two nodes in the network, no 1429 intermediate clocks can be used between these two nodes. In the 1430 [3GPP] example, if traffic between the Femtocell and the Femto 1431 Gateway is encrypted, then time protocol packets are necessarily 1432 transported over the underlying network without modification, and 1433 thus cannot enjoy the improved accuracy provided by intermediate 1434 clock nodes. 1436 7.5. External Security Services Requiring Time 1438 Cryptographic protocols often use time as an important factor in the 1439 cryptographic algorithm. If a time protocol is compromised, it may 1440 consequently expose the security protocols that rely on it to various 1441 attacks. Two examples are presented in this section. 1443 7.5.1. Timestamped Certificates 1445 Certificate validation requires the sender and receiver to be roughly 1446 time synchronized. Thus, synchronization is required for establishing 1447 security protocols such as IKEv2 and TLS. 1449 An even stronger interdependence between a time protocol and a 1450 security mechanism is defined in [AutoKey], which defines mutual 1451 dependence between the acquired time information, and the 1452 authentication protocol that secures it. This bootstrapping behavior 1453 results from the fact that trusting the received time information 1454 requires a valid certificate, and validating a certificate requires 1455 knowledge of the time. 1457 7.5.2. Time Changes and Replay Attacks 1459 A successful attack on a time protocol may cause the attacked clocks 1460 to go back in time. The erroneous time may expose cryptographic 1461 algorithms that rely on time, as a node may use a key that was 1462 already used in the past and has expired. 1464 8. Issues for Further Discussion 1466 The Key distribution is outside the scope of this document. Although 1467 this is an essential element of any security system, it is outside 1468 the scope of this document. 1470 9. Security Considerations 1472 The security considerations of network timing protocols are presented 1473 throughout this document. 1475 10. IANA Considerations 1477 There are no new IANA considerations implied by this document. 1479 11. Acknowledgments 1481 The authors gratefully acknowledge Stefano Ruffini, Doug Arnold, 1482 Kevin Gross, Dieter Sibold, Dan Grossman, Laurent Montini, Russell 1483 Smiley, and Shawn Emery for their thorough review and helpful 1484 comments. The authors would also like to thank members of the TICTOC 1485 WG for providing feedback on the TICTOC mailing list. 1487 This document was prepared using 2-Word-v2.0.template.dot. 1489 12. References 1491 12.1. Normative References 1493 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1494 Requirement Levels", BCP 14, RFC 2119, March 1997. 1496 12.2. Informative References 1498 [1588IPsec] A. Treytl, B. Hirschler, "Securing IEEE 1588 by IPsec 1499 tunnels - An analysis", in Proceedings of 2010 1500 International Symposium for Precision Clock 1501 Synchronization for Measurement, Control and 1502 Communication, ISPCS 2010, pp. 83-90, 2010. 1504 [3GPP] 3GPP, "Security of Home Node B (HNB) / Home evolved 1505 Node B (HeNB)", 3GPP TS 33.320 10.4.0 (work in 1506 progress), 2011. 1508 [Anatomy] C. Nachreiner, "Anatomy of an ARP Poisoning Attack", 1509 2003. 1511 [AutoKey] Haberman, B., Mills, D., "Network Time Protocol 1512 Version 4: Autokey Specification", RFC 5906, June 1513 2010. 1515 [AvbAssum] D. Pannell, "Audio Video Bridging Gen 2 Assumptions", 1516 IEEE 802.1 AVB Plenary, work in progress, May 2012. 1518 [DelayAtt] T. Mizrahi, "A Game Theoretic Analysis of Delay 1519 Attacks against Time Synchronization Protocols", 1520 accepted, to appear in Proceedings of the 1521 International IEEE Symposium on Precision Clock 1522 Synchronization for Measurement, Control and 1523 Communication, ISPCS, 2012. 1525 [Hack] S. McClure, J. Scambray, G. Kurtz, Kurtz, "Hacking 1526 exposed: network security secrets and solutions", 1527 McGraw-Hill, 2009. 1529 [IEEE1588] IEEE TC 9 Instrumentation and Measurement Society, 1530 "1588 IEEE Standard for a Precision Clock 1531 Synchronization Protocol for Networked Measurement and 1532 Control Systems Version 2", IEEE Standard, 2008. 1534 [IPsec] S. Kent, K. Seo, "Security Architecture for the 1535 Internet Protocol", IETF, RFC 4301, 2005. 1537 [IPsecSync] Y. Xu, "IPsec security for packet based 1538 synchronization", IETF, draft-xu-tictoc-ipsec- 1539 security-for-synchronization (work in progress), 2011. 1541 [MACsec] IEEE 802.1AE-2006, "IEEE Standard for Local and 1542 Metropolitan Area Networks - Media Access Control 1543 (MAC) Security", 2006. 1545 [NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W., 1546 "Network Time Protocol Version 4: Protocol and 1547 Algorithms Specification", RFC 5905, June 2010. 1549 [SecPTP] J. Tsang, K. Beznosov, "A security analysis of the 1550 precise time protocol (short paper)," 8th 1551 International Conference on Information and 1552 Communication Security (ICICS 2006), pp. 50-59, 2006. 1554 [SecSen] S. Ganeriwal, C. Popper, S. Capkun, M. B. Srivastava, 1555 "Secure Time Synchronization in Sensor Networks", ACM 1556 Trans. Info. and Sys. Sec., Volume 11, Issue 4, July 1557 2008. 1559 [TM] T. Mizrahi, "Time synchronization security using IPsec 1560 and MACsec", ISPCS 2011, pp. 38-43, 2011. 1562 [Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R., 1563 "Traps and pitfalls in secure clock synchronization" 1564 in Proceedings of 2007 International Symposium for 1565 Precision Clock Synchronization for Measurement, 1566 Control and Communication, ISPCS 2007, pp. 18-24, 1567 2007. 1569 [Tunnel] A. Treytl, B. Hirschler, and T. Sauter, "Secure 1570 tunneling of high precision clock synchronisation 1571 protocols and other timestamped data", in Proceedings 1572 of the 8th IEEE International Workshop on Factory 1573 Communication Systems (WFCS), vol. ISBN 978-1-4244- 1574 5461-7, pp. 303-313, 2010. 1576 13. Contributing Authors 1578 Karen O'Donoghue 1579 ISOC 1581 Email: odonoghue@isoc.org 1583 Authors' Addresses 1585 Tal Mizrahi 1586 Marvell 1587 6 Hamada St. 1588 Yokneam, 20692 Israel 1590 Email: talmi@marvell.com