idnits 2.17.1 draft-ietf-tictoc-security-requirements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The mechanism also SHOULD not require excessive storage of client state in the master, nor significantly increase bandwidth consumption. -- The document date (September 14, 2012) is 4239 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 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: March 2013 September 14, 2012 6 TICTOC Security Requirements 7 draft-ietf-tictoc-security-requirements-03.txt 9 Abstract 11 As time synchronization protocols are becoming increasingly common 12 and widely deployed, concern about their exposure to various security 13 threats is increasing. This document defines a set of security 14 requirements for time synchronization protocols, focusing on the 15 Precision Time Protocol (PTP) and the Network Time Protocol (NTP). 16 This document also discusses the security impacts of time 17 synchronization protocol practices, the time synchronization 18 performance implications of external security practices, the 19 dependencies between other security services and time 20 synchronization. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on March 14, 2013. 45 Copyright Notice 47 Copyright (c) 2012 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 ............................ 4 64 2.1. Terminology ............................................. 4 65 2.2. Terms & Abbreviations ................................... 5 66 3. Security Threats ............................................. 5 67 3.1. Threat Model ............................................ 5 68 3.1.1. Internal vs. External Attackers .................... 6 69 3.1.2. Man in the Middle (MITM) vs. Packet Injector ....... 6 70 3.2. Threat Analysis.......................................... 6 71 3.2.1. Packet Interception and Manipulation ............... 6 72 3.2.2. Spoofing ........................................... 6 73 3.2.3. Replay Attack ...................................... 7 74 3.2.4. Rogue Master Attack ................................ 7 75 3.2.5. Packet Interception and Removal .................... 7 76 3.2.6. Packet Delay Manipulation .......................... 7 77 3.2.7. Cryptographic Performance Attacks .................. 7 78 3.2.8. L2/L3 DoS Attacks .................................. 8 79 3.2.9. Master Time Source Spoofing (e.g. GPS fraud) ....... 8 80 3.3. Threat Analysis Summary ................................. 8 81 4. Security Requirements ........................................ 9 82 4.1. Clock Identity Authentication ........................... 9 83 4.1.1. Authentication of Masters ......................... 10 84 4.1.2. Recursive Authentication of Masters (Chain of Trust)10 85 4.1.3. Authentication of Slaves .......................... 11 86 4.1.4. PTP: Authentication of Transparent Clocks.......... 11 87 4.1.5. PTP: Authentication of Announce Messages .......... 11 88 4.2. Data integrity ......................................... 12 89 4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 12 90 4.2.1.1. Hop by Hop Integrity Protection .............. 12 91 4.2.1.2. End to End Integrity Protection .............. 13 93 4.3. Availability ........................................... 13 94 4.4. Replay Protection ...................................... 14 95 4.5. Cryptographic Keys & Security Associations ............. 14 96 4.5.1. Security Association .............................. 14 97 4.5.2. Unicast and Multicast ............................. 14 98 4.5.3. Key Freshness ..................................... 14 99 4.6. Performance ............................................ 15 100 4.7. Confidentiality......................................... 15 101 4.8. Protection against packet delay attacks ................ 16 102 4.9. Combining Secured with Unsecured Nodes ................. 16 103 4.9.1. Secure Mode ....................................... 17 104 4.9.2. Hybrid Mode ....................................... 17 105 5. Summary of Requirements ..................................... 18 106 6. Additional security implications ............................ 19 107 6.1. Security and on-the-fly Timestamping ................... 19 108 6.2. Security and Two-Step Timestamping ..................... 20 109 6.3. Intermediate Clocks .................................... 20 110 6.4. The Effect of External Security Protocols on Time 111 Synchronization ............................................. 21 112 6.5. External Security Services Requiring Time Synchronization21 113 7. Issues for Further Discussion ............................... 21 114 8. Security Considerations ..................................... 21 115 9. IANA Considerations ......................................... 22 116 10. Acknowledgments ............................................ 22 117 11. References ................................................. 22 118 11.1. Normative References .................................. 22 119 11.2. Informative References ................................ 22 120 12. Contributing Authors ....................................... 24 122 1. Introduction 124 As time synchronization protocols are becoming increasingly common 125 and widely deployed, concern about the resulting exposure to various 126 security threats is increasing. If a time synchronization protocol is 127 compromised, the applications it serves are prone to a range of 128 possible attacks including Denial-of-Service or incorrect behavior. 130 This document focuses on the security aspects of the Precision Time 131 Protocol (PTP) [IEEE1588] and the Network Time Protocol [NTPv4]. The 132 Network Time Protocol was defined with an inherent security protocol, 133 defined in [NTPv4] and in [AutoKey]. The IEEE 1588 includes an 134 experimental security protocol, defined in Annex K of the standard, 135 but this Annex was never formalized into a fully defined security 136 protocol. 138 Many of the existing packet timing deployments do not use any 139 security mechanisms. The absence of a standard security solution for 140 PTP undoubtedly contributed to the wide deployment of unsecured time 141 synchronization solutions. However, in some cases security mechanisms 142 may not be strictly necessary, e.g., due to other security practices 143 in place, or due to the architecture of the network. A time 144 synchronization security solution, much like any security solution, 145 is comprised of various building blocks, and must be carefully 146 tailored for the specific system it is deployed in. Based on a 147 system-specific threat assessment, the benefits of a security 148 solution must be weighed against the potential risks, and based on 149 this tradeoff an optimal security solution can be selected. 151 This document attempts to add clarity to the time synchronization 152 protocol security requirements discussion by addressing a series of 153 questions: 155 (1) What are the threats that need to be addressed for the time 156 synchronization protocol, and thus what security services need to be 157 provided? (e.g. a malicious NTP server or PTP master) 159 (2) What external security practices impact the security and 160 performance of time keeping, and what can be done to mitigate these 161 impacts? (e.g. an IPSec tunnel in the synchronization traffic path) 163 (3) What are the security impacts of time synchronization protocol 164 practices? (e.g. on-the-fly modification of timestamps) 166 (4) What are the dependencies between other security services and 167 time synchronization? (e.g. which comes first - the certificate or 168 the timestamp?) 170 In light of the questions above, this document defines a set of 171 requirements for security solutions for time synchronization 172 protocols, focusing on PTP and NTP. 174 2. Conventions Used in this Document 176 2.1. Terminology 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [KEYWORDS]. 182 This document describes security requirements, and thus requirements 183 are phrased in the document in the form "the security mechanism 184 MUST/SHOULD/...". Note, that the phrasing does not imply that this 185 document defines a specific security mechanism, but defines the 186 requirements that every security mechanism should comply to. 188 This document refers to both PTP and NTP. For the sake of 189 consistency, throughout the document the term "master" applies to 190 both a PTP master and an NTP server. Similarly, the term "slave" 191 applies to both PTP slaves and NTP clients. The general term "clock" 192 refers to masters, slaves and PTP Transparent Clocks (TC). The term 193 "protocol packets" is refers generically to PTP and NTP messages. 195 2.2. Terms & Abbreviations 197 BC Boundary Clock 199 MITM Man In The Middle 201 NTP Network Time Protocol 203 OC Ordinary Clock 205 PTP Precision Time Protocol 207 Secured clock A clock that supports a security mechanism that 208 complies to the requirements in this document 210 TC Transparent Clock 212 Unsecured clock A clock that does not support a security mechanism 213 according to the requirments in this document 215 3. Security Threats 217 This section discusses the possible attacker types, and analyzes 218 various attacks against time synchronization protocols. 220 The literature is rich with security threats of time synchronization 221 protocols, e.g., [Traps], [AutoKey], [TM], [SecPTP], and [SecSen]. 222 The threat analysis in this document is mostly based on [TM]. 224 3.1. Threat Model 226 A time synchronization protocol can be attacked by various types of 227 attackers. 229 The analysis in this documents classifies attackers according to 2 230 criteria, as described in 3.1.1. and 3.1.2. 232 3.1.1. Internal vs. External Attackers 234 In the context of internal and external attackers, the underlying 235 assumption is that the time synchronization protocol is secured 236 either by an encryption or an authentication mechanism. 238 Internal attackers either have access to a trusted segment of the 239 network, or possess the encryption or authentication keys. External 240 attackers, on the other hand, do not have the keys, and are exposed 241 only to the encrypted or authenticated traffic. Thus, an internal 242 attacker can maliciously tamper with legitimate traffic in the 243 network, as well as generate its own traffic and make it appear 244 legitimate to its attacked nodes. 246 Obviously, in the absence of a security mechanism there is no 247 distinction between internal and external attackers, since all 248 attackers are internal in practice. 250 3.1.2. Man in the Middle (MITM) vs. Packet Injector 252 MITM attackers are located in a position that allows interception and 253 modification of in-flight protocol packets. 255 A traffic injector is not located in an MITM position, but can attack 256 by generatating protocol packets. An injector can also potentially 257 eavesdrop to protocol packets sent as multicast, record them and 258 replay them later. 260 3.2. Threat Analysis 262 3.2.1. Packet Interception and Manipulation 264 A packet interception and manipulation attack results when a Man-In- 265 The-Middle (MITM) attacker intercepts timing protocol packets, alters 266 them and relays them to their destination, allowing the attacker to 267 maliciously tamper with the protocol. This can result in a situation 268 where the time protocol is apparently operational but providing 269 intentionally inaccurate information. 271 3.2.2. Spoofing 273 In spoofing, an attacker masquerades as a legitimate node in the 274 network by generating and transmitting protocol packets. For example, 275 an attacker can impersonate the master, allowing malicious 276 distribution of false timing information. As with packet interception 277 and manipulation, this can result in a situation where the time 278 protocol is apparently operational but providing intentionally 279 inaccurate information. 281 3.2.3. Replay Attack 283 In a replay attack, an attacker records protocol packets and replays 284 them at a later time without any modification. This can also result 285 in a situation where the time protocol is apparently operational but 286 providing intentionally inaccurate information. 288 3.2.4. Rogue Master Attack 290 In a rogue master attack, an attacker causes other nodes in the 291 network to believe it is a legitimate master. As opposed to the 292 spoofing attack, in the Rouge Master attack the attacker does not 293 fake its identity, but rather manipulates the master election 294 process. For example, in PTP, an attacker can manipulate the Best 295 Master Clock Algorithm (BMCA), and cause other nodes in the network 296 to believe it is the most eligible candidate to be a grandmaster. 298 3.2.5. Packet Interception and Removal 300 A packet interception and removal attack results when a Man-In-The- 301 Middle attacker intercepts and drops protocol packets, preventing the 302 destination node from receiving the timing information. 304 3.2.6. Packet Delay Manipulation 306 In a packet delay manipulation scenario, a Man-In-The-Middle attacker 307 intercepts protocol packets, and relays them to their destination 308 after adding a maliciously computed delay. 310 Note that the attackee still receives one copy of each packet, 311 contrary to the replay attack, where a packet is received by the 312 attackee more than once. 314 3.2.7. Cryptographic Performance Attacks 316 In cryptographic performance attacks, an attacker transmits fake 317 protocol packet, causing high utilization of the cryptographic engine 318 at the receiver, which attempts to verify the integrity of these fake 319 packets. 321 3.2.8. L2/L3 DoS Attacks 323 There are many possible Layer 2 and Layer 3 Denial of Service 324 attacks. As the target's availability is compromised, the timing 325 protocol is affected accordingly. 327 3.2.9. Master Time Source Spoofing (e.g. GPS fraud) 329 In time source spoofing, an attacker spoofs the accurate time source 330 of the master. For example, if the master uses a GPS based clock as 331 its reference source, an attacker can spoof the GPS satellites, 332 causing the master to use a false reference time. 334 3.3. Threat Analysis Summary 336 The two key factors to a threat analysis are the severity and the 337 likelihood of each of the analyzed attacks. 339 Table 1 summarizes the security attacks presented in 3.2. For each 340 attack, the table specifies its impact, and its applicability to each 341 of the attacker types presented in 3.1. 343 The Impact column provides an intuition to the severity of each 344 attack, and the relevant Attacker Type columns provide an intuition 345 about the how difficult each attack is to implement, and hence about 346 the likelihood of each attack. 348 The impact column in Table 1 can have one of 3 values: 350 o DoS - the attack causes a denial of service to the attacked node, 351 the impact of which is not restricted to the time synchronization 352 protocol. 354 o False time - slaves align to a false time or frequency value due 355 to the attack. Note that if the time synchronization service 356 aligns to a false time, it may cause denial of service to other 357 applications that rely on accurate time. However, for the purpose 358 of the analysis in this section we distinguish this implication 359 from "DoS", which refers to a DoS attack that is not necessarily 360 aimed at the time synchronization protocol. 362 o Accuracy degradation - the attack yields a degradation in the 363 slave accuracy, but does not completely compromise the slaves' 364 time and frequency. 366 The Attacket Type columns refer to the 4 possible combinations of the 367 attacker types defined in 3.1. 369 +-----------------------------+-------------------++-------------------+ 370 | Attack | Impact || Attacker Type | 371 | +-----+--------+----++---------+---------+ 372 | |False|Accuracy| ||Internal | Extenal | 373 | |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.| 374 +-----------------------------+-----+--------+----++----+----+----+----+ 375 |Interception and manipulation| + | | || + | | | | 376 +-----------------------------+-----+--------+----++----+----+----+----+ 377 |Spoofing | + | | || + | + | | | 378 +-----------------------------+-----+--------+----++----+----+----+----+ 379 |Replay attack | + | | || + | + | | | 380 +-----------------------------+-----+--------+----++----+----+----+----+ 381 |Rogue master attack | + | | || + | + | | | 382 +-----------------------------+-----+--------+----++----+----+----+----+ 383 |Interception and Removal | | + | || + | | + | | 384 +-----------------------------+-----+--------+----++----+----+----+----+ 385 |Packet delay manipulation | + | | || + | | + | | 386 +-----------------------------+-----+--------+----++----+----+----+----+ 387 |Crypt. performance attacks | | | + || + | + | + | + | 388 +-----------------------------+-----+--------+----++----+----+----+----+ 389 |DoS attacks | | | + || + | + | + | + | 390 +-----------------------------+-----+--------+----++----+----+----+----+ 391 |Master Time source spoofing | + | | || + | + | + | + | 392 |(e.g. GPS spoofing) | | | || | | | | 393 +-----------------------------+-----+--------+----++----+----+----+----+ 394 Table 1 Threat Analysis - Summary 396 4. Security Requirements 398 This section defines a set of requirements from the security 399 mechanisms used for PTP and NTP. These requirements are phrased in 400 the form "the security mechanism MUST/SHOULD/MAY...". However, this 401 document does not specify how these requirements can be met; While 402 these requirments can be satisfied by extending the time protocols, 403 at least a subset of the requirements can be met by applying common 404 security practices to the network or by using existing security 405 protocols, such as IPsec or MACsec. Thus, security solutions that 406 address these requirements are outside the scope of this document. 408 4.1. Clock Identity Authentication 410 Requirement 411 The security mechanism MUST provide a means for each clock to 412 authenticate the sender of a protocol packet. 414 Discussion 416 In the context of this document, authentication refers to: 418 o Identification: verifying the identity of the peer clock. 420 o Authorization: verifying that the peer clock is permitted to play 421 the role that it plays in the protocol. For example, some nodes 422 may be permitted to be masters, while other nodes are only 423 permitted to be slaves or TCs. 425 The following subsections describe 4 distinct cases of clock 426 authentication. 428 4.1.1. Authentication of Masters 430 Requirement 432 The security mechanism MUST support an authentication mechanism, 433 allowing slave clocks to authenticate the identity of master clocks. 435 4.1.2. Recursive Authentication of Masters (Chain of Trust) 437 Requirement 439 The security mechanism MUST support recursive authentication of the 440 master, to be used in cases where end-to-end authentication is not 441 possible. 443 Discussion 445 Clocks authenticate masters in order to ensure the authenticity of 446 the time source. 448 In some cases a slave is connected to an intermediate master, that is 449 not the primary time source. For example, in PTP a slave can be 450 connected to a Boundary Clock (BC), which in turn is connected to a 451 grandmaster. A similar example in NTP is when a client is connected 452 to a stratum 2 server, which is connected to a stratum 1 server. In 453 both the PTP and the NTP cases, the slave authenticates the 454 intermediate master, and the intermediate master authenticates the 455 primary master. This inductive authentication process is referred to 456 in [AutoKey] as proventication. 458 4.1.3. Authentication of Slaves 460 Requirement 462 The security mechanism SHOULD provide a means for a master to 463 authenticate its slaves. 465 Discussion 467 Slaves are authenticated by masters in order to verify that the slave 468 is authorized to receive timing services from the master. 470 Authentication of slaves prevents unauthorized clocks from receiving 471 time services, and also reduces unnecessary load on the master clock, 472 by preventing the master from serving unauthorized clocks. It could 473 be argued that the authentication of slaves could put a higher load 474 on the master then serving the unauthorized clock, and hence this 475 requirement is a SHOULD. 477 4.1.4. PTP: Authentication of Transparent Clocks 479 Requirement 481 The security mechanism for PTP SHOULD provide a means for a master to 482 authenticate the identity of the P2P TCs directly connected to it. 484 Discussion 486 P2P TCs that are one hop from the master use the PDelay_Req and 487 PDelay_Resp handshake to compute the link delay between the master 488 and TC. These TCs are authenticated by the master. 490 Authentication of TCs, much like authentication of slaves, reduces 491 unnecessary load on the master clock and peer TCs, by preventing the 492 master from serving unauthorized clocks. 494 4.1.5. PTP: Authentication of Announce Messages 496 Requirement 498 The security mechanism for PTP MUST support authentication of 499 Announce messages. 501 Discussion 503 Master election is performed in PTP using the Best Master Clock 504 Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock 505 attributes using Announce messages, and the best master is elected 506 based on the information gathered from all the candidates. Announce 507 messages must be authenticated in order to prevent malicious master 508 attacks. 510 Note, that this subsection specifies a requirement that is not 511 necessarily included in 4.1.1. or in 4.1.3. , since the BMCA is 512 initiated before clocks have been defined as masters or slaves. 514 4.2. Data integrity 516 Requirement 518 The security mechanism MUST protect the integrity of protocol 519 packets. 521 Discussion 523 While subsection 4.1. refers to ensuring WHO sent the protocol 524 packet, this subsection refers to ensuring that the packet arrived 525 intact. The integrity protection mechanism ensures the authenticity 526 and completeness of data from the data originator. 528 4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 530 Requirement 532 A security mechanism for PTP MUST support hop-by-hop integrity 533 protection. 535 Requirement 537 A security mechanism for PTP SHOULD support end-to-end integrity 538 protection. 540 Discussion 542 Specifically in PTP, when protocol packets are subject to 543 modification by TCs, the integrity protection can be enforced in one 544 of two approaches, end-to-end or hop-by-hop. 546 4.2.1.1. Hop by Hop Integrity Protection 548 Each hop that needs to modify a protocol packet: 550 o Verifies its integrity. 552 o Modifies the packet, i.e., modifies the correctionField. 554 o Re-generates the integrity protection, e.g., re-computes a Message 555 Authentication Code. 557 In the hop-by-hop approach, the integrity of protocol packets is 558 protected by induction on the path from the originator to the 559 receiver. 561 This approach is simple, but allows malicious TCs to modify protocol 562 packets. 564 4.2.1.2. End to End Integrity Protection 566 In this approach, the integrity protection is maintained on the path 567 from the originator of a protocol packet to the receiver. This allows 568 the receiver to validate the protocol packet without the ability of 569 intermediate TCs to manipulate the packet. 571 Since TCs need to modify the correctionField, a separate integrity 572 protection mechanism is used specifically for the correctionField. 574 The end-to-end approach limits the TC's impact to the correctionField 575 alone, while the rest of the protocol packet is protected on an end- 576 to-end basis. It should be noted that this approach is more difficult 577 to implement than the hop-by-hop approach, as it requires separate 578 layers of protection for the correctionField and for the rest of the 579 packet, using different cryptographic mechanisms and keys. 581 4.3. Availability 583 Requirement 585 The security mechanism MUST protect the time synchronization protocol 586 from DoS attacks by external attackers. 588 Discussion 590 The protocol availability can be compromised by several different 591 attacks. An attacker can inject protocol messages to implement the 592 spoofing attack (Section 3.2.2. ) or the rogue master attack (Section 593 3.2.4. ), causing denial of service to the attackee. An 594 authentication mechanism (Section 4.1. ) limits these attacks 595 strictly to internal attackers, and thus prevents external attackers 596 from performing them. 598 Note that a security mechanism applied at the time synchronization 599 layer cannot, by itself, prevent DoS attacks described in Section 600 3.2.8. DoS attacks at lower layers of the protocol stack (Section 601 3.2.8. ) can still be implemented by external attackers even in the 602 presence of an authentication mechanism. 604 4.4. Replay Protection 606 Requirement 608 Protocol messages MUST be resistant to replay attacks. 610 4.5. Cryptographic Keys & Security Associations 612 4.5.1. Security Association 614 Requirement 616 The security protocol SHOULD support an association protocol where: 618 o Two or more clocks authenticate each other. 620 o The clocks generate and agree on a cryptographic session key. 622 Discussion 624 The security requirements in 4.1. and 4.2. require usage of 625 cryptographich mechanisms, deploying cryptographic keys. A security 626 association is an essential building block in these mechanisms. 628 4.5.2. Unicast and Multicast 630 Requirement 632 The security mechanism SHOULD support security association protocols 633 for unicast and for multicast associations. 635 Discussion 637 A unicast protocol requires an association protocol between two 638 clocks, whereas a multicast protocol requires an association protocol 639 among two or more clocks, where one of the clocks is a master. 641 4.5.3. Key Freshness 643 Requirement 644 The cryptographic keys MUST be refreshed periodically. 646 Requirement 648 The association protocol MUST be invoked periodically, where each 649 instance of the association protocol MUST produce a different session 650 key. 652 4.6. Performance 654 Requirement 656 The security mechanism MUST be designed in such a way that it does 657 not degrade the quality of the time transfer. 659 Requirement 661 The mechanism SHOULD be relatively lightweight, as client 662 restrictions often dictate a low processing and memory footprint, and 663 because the server may have extensive fan-out. 665 Requirement 667 The mechanism also SHOULD not require excessive storage of client 668 state in the master, nor significantly increase bandwidth 669 consumption. 671 Discussion 673 Note that the performance requirements refer to a time- 674 synchronization-specific security mechanism. In systems where a 675 security protocol is used for other types of traffic as well, this 676 document does not place any performance requirements on the security 677 protocol performance. For example, if IPsec encryption is used for 678 securing all information between the master and slave node, including 679 information that is not part of the time protocol, the requirements 680 in this subsection are not necessarily applicable. 682 4.7. Confidentiality 684 Requirement 686 The security mechanism MAY provide confidentiality protection of the 687 protocol packets. 689 Discussion 690 In the context of time synchronization, confidentiality is typically 691 of low importance, since timing information is typically not 692 considered secret information. 694 Confidentiality can play an important role when service providers 695 charge payment for time synchronization services, but these cases are 696 rather esoteric. 698 Confidentiality can also prevent an MITM attacker from identifying 699 protocol packets. Thus, confidentiality can assist in protecting the 700 timing protocol against packet delay attacks, where the attacker 701 selectively adds delay to time protocol packets. Note, that time 702 protocols have predictable behavior such as packet transmission rates 703 and packet lengths, and thus packet encryption does not prevent delay 704 attacks, but rather makes these attacks more difficult to implement. 706 4.8. Protection against packet delay attacks 708 Requirement 710 The security mechanism MAY include a means to detect packet delay 711 attacks. 713 Requirement 715 The security mechanism MAY include a redundancy mechanism that allows 716 a node that detects a delay attack to switch over to a secondary 717 master. 719 Discussion 721 While this document does not define specific security solutions, we 722 note that common practices for protection against delay attacks use 723 redundant masters (e.g. [NTPv4]), or redundant paths between the 724 master and slave (e.g. [DelayAtt]). If one of the time sources 725 indicates a time value that is significantly different than the other 726 sources, it is assumed to be erroneous or under attack, and is 727 therefore ignored. 729 This requirement is a "may" requirement since both master redundancy 730 and path redundancy are not necessarily possible in all network 731 topologies. 733 4.9. Combining Secured with Unsecured Nodes 735 Integrating a security mechanism into a time synchronized system is a 736 complex process, and in some cases may require a gradual process, 737 where new equipment supports the security mechanism, and is required 738 to interoperate with legacy equipment without the security features. 740 4.9.1. Secure Mode 742 Requirement 744 The security mechanism MUST support a secure mode, where only secured 745 clocks are permitted to take part in the synchronization protocol. A 746 protocol packet received from an unsecured clock MUST be discarded. 748 Discussion 750 While the requirement in this subsection is a bit similar to the one 751 in 4.1. , it explicitly defines the secure mode, as opposed to the 752 hybrid mode presented in the next subsection. 754 4.9.2. Hybrid Mode 756 Requirement 758 The security protocol MAY support a hybrid mode, where both secured 759 and unsecured clocks are permitted to take part in the protocol. 761 Discussion 763 The hybrid mode allows both secured and unsecured clocks to take part 764 in the synchronization protocol. NTP, for example, allows a mixture 765 of secured and unsecured nodes. 767 Requirement 769 A master in the hybrid mode SHOULD be a secured clock. 771 A secured slave in the hybrid mode SHOULD discard all protocol 772 packets received from unsecured clocks. 774 Discussion 776 This requirement ensures that the existence of unsecured clocks does 777 not compromise the security provided to secured clocks. Hence, 778 secured slaves only "trust" protocol packets received from a secured 779 clock. An unsecured clock can receive protocol packets from either 780 secured clocks, or unsecured clocks. 782 Note that the security scheme in [NTPv4] with [AutoKey] does not 783 satisfy this requirement, since nodes prefer the server with the best 784 clock, and not necessarily the server that supports authentication. 785 For example, a stratum 2 server is connected to two stratum 1 786 servers, Server A, supporting authentication, and server B, without 787 authentication. If server B has a more accurate clock than A, the 788 stratum 2 server chooses server B, in spite of the fact it does not 789 support authentication. 791 5. Summary of Requirements 793 +-----------+--------------------------------------+---------------+ 794 | Section | Requirement | Type | 795 +-----------+--------------------------------------+---------------+ 796 | 4.1. | Authentication of sender. | MUST | 797 | +--------------------------------------+---------------+ 798 | | Authentication of master. | MUST | 799 | +--------------------------------------+---------------+ 800 | | Recursive authentication. | MUST | 801 | +--------------------------------------+---------------+ 802 | | Authentication of slaves. | SHOULD | 803 | +--------------------------------------+---------------+ 804 | | PTP: Authentication of TCs. | SHOULD | 805 | +--------------------------------------+---------------+ 806 | | PTP: Authentication of Announce | SHOULD | 807 | | messages. | | 808 +-----------+--------------------------------------+---------------+ 809 | 4.2. | Integrity protection. | MUST | 810 | +--------------------------------------+---------------+ 811 | | PTP: hop-by-hop integrity protection.| MUST | 812 | +--------------------------------------+---------------+ 813 | | PTP: end-to-end integrity protection.| SHOULD | 814 +-----------+--------------------------------------+---------------+ 815 | 4.3. | Protection against DoS attacks. | MUST | 816 +-----------+--------------------------------------+---------------+ 817 | 4.4. | Replay protection. | MUST | 818 +-----------+--------------------------------------+---------------+ 819 | 4.5. | Security association. | SHOULD | 820 | +--------------------------------------+---------------+ 821 | | Unicast and multicast associations. | SHOULD | 822 | +--------------------------------------+---------------+ 823 | | Key freshness. | MUST | 824 +-----------+--------------------------------------+---------------+ 825 | 4.6. | Performance: no degradation in | MUST | 826 | | quality of time transfer. | | 827 | +--------------------------------------+---------------+ 828 | | Performance: lightweight. | SHOULD | 829 | +--------------------------------------+---------------+ 830 | | Performance: storage, bandwidth. | MUST | 831 +-----------+--------------------------------------+---------------+ 832 | 4.7. | Confidentiality protection. | MAY | 833 +-----------+--------------------------------------+---------------+ 834 | 4.8. | Protection against delay attacks. | MAY | 835 +-----------+--------------------------------------+---------------+ 836 | 4.9. | Secure mode. | MUST | 837 | +--------------------------------------+---------------+ 838 | | Hybrid mode. | MAY | 839 +-----------+--------------------------------------+---------------+ 840 Table 2 Summary of Security Requirements 842 6. Additional security implications 844 This section discusses additional implications of the interaction 845 between time synchronization protocols and security mechanisms. 847 This section refers to time synchronization security mechanisms, as 848 well as to "external" security mechanisms, i.e., security mechanisms 849 that are not strictly related to the time synchronization protocol. 851 6.1. Security and on-the-fly Timestamping 853 Time synchronization protocols often require protocol packets to be 854 modified during transmission and reception. Both NTP and PTP in one- 855 step mode require clocks to modify protocol packets with the time of 856 transmission or reception. 858 In the presence of a security mechanism, whether encryption or 859 integrity protection: 861 o During transmission the security protocol must be applied after 862 integrating the timestamp into the packet. 864 o During reception, the encryption or integrity check must be 865 performed before modifying the packet with the time of reception. 867 To allow high accuracy, timestamping is typically performed as close 868 to the transmission or reception time as possible. However, since the 869 security engine must be placed between the timestamping function and 870 the physical interface, in some cases it may introduce non- 871 deterministic latency that causes accuracy degradation. These 872 performance aspects have been analyzed in the literature, e.g., in 873 [1588IPsec] and [Tunnel]. 875 6.2. Security and Two-Step Timestamping 877 PTP supports a two-step mode of operation, where the time of 878 transmission and the time of reception of protocol packets are 879 measured without modifying the packets. As opposed to one-step mode, 880 two step timestamping can be performed at the physical interface even 881 in the presence of a security mechanism. 883 Note that if an encryption mechanism such as IPsec is used, it 884 presents a challenge to the timestamping mechanism, since time 885 protocol packets are encrypted when traversing the physical 886 interface, and are thus impossible to identify. A possible solution 887 to this problem [IPsecSync] is to include an indication in the 888 encryption header that identifies time synchronization packets. 890 6.3. Intermediate Clocks 892 A time synchronization protocol allows slaves to receive time 893 information from an accurate time source. Time information is sent 894 over a path that often traverses one or more intermediate clocks. 896 o In NTP, time information originated from a stratum 1 server can be 897 distributed to stratum 2 servers, and in turn distributed from the 898 stratum 2 servers to NTP clients. In this case, the stratum 2 899 servers are a layer of intermediate clocks. 901 o In PTP, BCs and TCs are intermediate nodes used to improve the 902 accuracy of time information conveyed between the grandmaster and 903 the slaves. 905 A common rule of thumb in network security is that end-to-end 906 security is the best policy, as it secures the entire path between 907 the data originator and its receiver. The usage of intermediate nodes 908 implies that if a security mechanism is deployed in the network, all 909 intermediate nodes must be exposed to the security key since they 910 must be able to send time information to the slaves, or to modify 911 time information sent through them. 913 This inhehrent property of using intermediate clocks increases the 914 system's exposure to internal threats, as there is a large number of 915 nodes that are exposed to the security keys. 917 6.4. The Effect of External Security Protocols on Time Synchronization 919 Time synchronization protocols are often deployed in systems that use 920 security mechanisms and protocols. 922 A typical example is the 3GPP Femtocell network [3GPP], where IPsec 923 is used for securing traffic between a Femtocell and the Femto 924 Gateway. In some cases, all traffic between these two nodes may be 925 secured by IPsec, including the time synchronization protocol 926 traffic. This use-case is thoroughly discussed in [IPsecSync]. 928 Another typical example is the usage of MACsec encryption in L2 929 networks that deploy time synchronization [AvbAssum]. 931 The usage of external security mechanisms may affect time 932 synchronization protocols as follows: 934 o Timestamping accuracy can be affected, as described in 6.1. 936 o If traffic is secured between two nodes in the network, no 937 intermediate clocks can be used between these two nodes. In the 938 [3GPP] example, if traffic between the Femtocell and the Femto 939 Gateway is encrypted, then time protocol packets are sent over the 940 underlying network without modification, and thus cannot enjoy the 941 improved accuracy provided by intermediate clock nodes. 943 6.5. External Security Services Requiring Time Synchronization 945 Certificate validation requires the sender and receiver to be roughly 946 time synchronized. Thus, synchronization is required for establishing 947 security protocols such as IKEv2 and TLS. 949 An even stronger interdependence between a time synchronization 950 protocol and a security mechanism is defined in [AutoKey], which 951 defines mutual dependence between the acquired time information, and 952 the authentication protocol that secures it. 954 7. Issues for Further Discussion 956 o The key distribution is outside the scope of this document. 957 Although this is a cardinal element in any security system, it is 958 not a security requirement, and is thus not described here. 960 8. Security Considerations 962 The security considerations of network timing protocols are presented 963 throughout this document. 965 9. IANA Considerations 967 There are no new IANA considerations implied by this document. 969 10. Acknowledgments 971 The authors gratefully acknowledge Stefano Ruffini, Dieter Sibold and 972 Dan Grossman for their thorough review and helpful comments. The 973 authors would also like to thank members of the TICTOC WG for 974 providing feedback on the TICTOC mailing list. 976 This document was prepared using 2-Word-v2.0.template.dot. 978 11. References 980 11.1. Normative References 982 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 983 Requirement Levels", BCP 14, RFC 2119, March 1997. 985 [NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W., 986 "Network Time Protocol Version 4: Protocol and 987 Algorithms Specification", RFC 5905, June 2010. 989 [AutoKey] Haberman, B., Mills, D., "Network Time Protocol 990 Version 4: Autokey Specification", RFC 5906, June 991 2010. 993 [IEEE1588] IEEE TC 9 Test and Measurement Society 2000, "1588 994 IEEE Standard for a Precision Clock Synchronization 995 Protocol for Networked Measurement and Control Systems 996 Version 2", IEEE Standard, 2008. 998 11.2. Informative References 1000 [Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R., 1001 "Traps and pitfalls in secure clock synchronization" 1002 in Proceedings of 2007 International Symposium for 1003 Precision Clock Synchronization for Measurement, 1004 Control and Communication, ISPCS 2007, pp. 18-24, 1005 2007. 1007 [TM] T. Mizrahi, "Time synchronization security using IPsec 1008 and MACsec", ISPCS 2011, pp. 38-43, 2011. 1010 [SecPTP] J. Tsang, K. Beznosov, "A security analysis of the 1011 precise time protocol (short paper)," 8th 1012 International Conference on Information and 1013 Communication Security (ICICS 2006), pp. 50-59, 2006. 1015 [SecSen] S. Ganeriwal, C. Popper, S. Capkun, M. B. Srivastava, 1016 "Secure Time Synchronization in Sensor Networks", ACM 1017 Trans. Info. and Sys. Sec., Volume 11, Issue 4, July 1018 2008. 1020 [AvbAssum] D. Pannell, "Audio Video Bridging Gen 2 Assumptions", 1021 IEEE 802.1 AVB Plenary, work in progress, May 2012. 1023 [IPsecSync] Y. Xu, "IPsec security for packet based 1024 synchronization", IETF, draft-xu-tictoc-ipsec- 1025 security-for-synchronization (work in progress), 2011. 1027 [3GPP] 3GPP, "Security of Home Node B (HNB) / Home evolved 1028 Node B (HeNB)", 3GPP TS 33.320 10.4.0 (work in 1029 progress), 2011. 1031 [1588IPsec] A. Treytl, B. Hirschler, "Securing IEEE 1588 by IPsec 1032 tunnels - An analysis", in Proceedings of 2010 1033 International Symposium for Precision Clock 1034 Synchronization for Measurement, Control and 1035 Communication, ISPCS 2010, pp. 83-90, 2010. 1037 [Tunnel] A. Treytl, B. Hirschler, and T. Sauter, "Secure 1038 tunneling of high precision clock synchronisation 1039 protocols and other timestamped data", in Proceedings 1040 of the 8th IEEE International Workshop on Factory 1041 Communication Systems (WFCS), vol. ISBN 978-1-4244- 1042 5461-7, pp. 303-313, 2010. 1044 [DelayAtt] T. Mizrahi, "A Game Theoretic Analysis of Delay 1045 Attacks against Time Synchronization Protocols", 1046 accepted, to appear in Proceedings of the 1047 International IEEE Symposium on Precision Clock 1048 Synchronization for Measurement, Control and 1049 Communication, ISPCS, 2012. 1051 12. Contributing Authors 1053 Karen O'Donoghue 1054 ISOC 1056 Email: odonoghue@isoc.org 1058 Authors' Addresses 1060 Tal Mizrahi 1061 Marvell 1062 6 Hamada St. 1063 Yokneam, 20692 Israel 1065 Email: talmi@marvell.com