idnits 2.17.1 draft-ietf-tictoc-security-requirements-02.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 (June 17, 2012) is 4331 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 Karen O'Donoghue 4 Expires: December 2012 ISOC 5 June 17, 2012 7 TICTOC Security Requirements 8 draft-ietf-tictoc-security-requirements-02.txt 10 Abstract 12 As time synchronization protocols are becoming increasingly common 13 and widely deployed, concern about their exposure to various security 14 threats is increasing. This document defines a set of requirements 15 for security solutions for time synchronization protocols, focusing 16 on the IEEE 1588 and NTP. This document also discusses the security 17 impacts of time synchronization protocol practices, the time 18 synchronization performance implications of external security 19 practices, the 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 December 17, 2012. 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 .................... 5 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 ...................................... 6 74 3.2.4. Rogue Master Attack ................................ 6 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 .................................. 7 79 3.2.9. Master Time Source Spoofing (e.g. GPS fraud) ....... 7 80 3.3. Threat Analysis Summary ................................. 7 81 4. Security Requirements ........................................ 9 82 4.1. Clock Identity Authentication ........................... 9 83 4.1.1. Authentication of Masters .......................... 9 84 4.1.2. Proventication of Masters .......................... 9 85 4.1.3. Authentication of Slaves .......................... 10 86 4.1.4. PTP: Authentication of Transparent Clocks.......... 10 87 4.1.5. PTP: Authentication of Announce Messages .......... 11 88 4.2. Data integrity ......................................... 11 89 4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 11 90 4.2.1.1. Hop by Hop Integrity Protection .............. 12 91 4.2.1.2. End to End Integrity Protection .............. 12 93 4.3. Availability ........................................... 12 94 4.4. Replay Protection ...................................... 13 95 4.5. Cryptographic Keys & Security Associations ............. 13 96 4.5.1. Security Association .............................. 13 97 4.5.2. Unicast and Multicast ............................. 13 98 4.5.3. Key Freshness ..................................... 14 99 4.6. Performance ............................................ 14 100 4.7. Confidentiality......................................... 14 101 4.8. Protection against packet delay attacks ................ 15 102 4.9. Combining Secured with Unsecured Nodes ................. 15 103 4.9.1. Secure Mode ....................................... 15 104 4.9.2. Hybrid Mode ....................................... 16 105 5. Summary of Requirements ..................................... 16 106 6. Additional security implications ............................ 18 107 6.1. Security and on-the-fly Timestamping ................... 18 108 6.2. Security and Two-Step Timestamping ..................... 18 109 6.3. Intermediate Clocks .................................... 19 110 6.4. The Effect of External Security Protocols on Time 111 Synchronization ............................................. 19 112 6.5. External Security Services Requiring Time Synchronization20 113 7. Issues for Further Discussion ............................... 20 114 8. Security Considerations ..................................... 20 115 9. IANA Considerations ......................................... 20 116 10. Acknowledgments ............................................ 20 117 11. References ................................................. 21 118 11.1. Normative References .................................. 21 119 11.2. Informative References ................................ 21 121 1. Introduction 123 As time synchronization protocols are becoming increasingly common 124 and widely deployed, concern about the resulting exposure to various 125 security threats is increasing. If a time synchronization protocol is 126 compromised, the applications it serves are prone to a range of 127 possible attacks including Denial-of-Service or incorrect behavior. 129 This document focuses on the security aspects of the Precision Time 130 Protocol ([IEEE 1588]) and the Network Time Protocol ([NTPv4]). The 131 Network Time Protocol was defined with an inherent security protocol, 132 defined in [NTPv4] and in [AutoKey]. The IEEE 1588 includes an 133 experimental security protocol, defined in Annex K of the standard, 134 but this Annex was never formalized into a fully defined security 135 protocol. 137 This document attempts to add clarity to the time synchronization 138 protocol security requirements discussion by addressing a series of 139 questions. It is expected that this document will evolve into 140 possibly two documents including one on requirements and one 141 providing clarity around the additional questions raised below. Until 142 the discussion has matured sufficiently, it will be captured in this 143 document. The four primary questions addressed by this draft include: 145 (1) What are the threats that need to be addressed for the time 146 synchronization protocol, and thus what security services need to be 147 provided? (e.g. a malicious NTP server or PTP master) 149 (2) What external security practices impact the security and 150 performance of time keeping, and what can be done to mitigate these 151 impacts? (e.g. an IPSec tunnel in the synchronization traffic path) 153 (3) What are the security impacts of time synchronization protocol 154 practices? (e.g. on-the-fly modification of timestamps) 156 (4) What are the dependencies between other security services and 157 time synchronization? (e.g. which comes first - the certificate or 158 the timestamp?) 160 It is expected that the final version of this document will define a 161 set of requirements for security solutions for time synchronization 162 protocols, focusing on the IEEE 1588 and NTP. 164 2. Conventions Used in this Document 166 2.1. Terminology 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [KEYWORDS]. 172 This document describes security requirements, and thus requirements 173 are phrased in the document in the form "the security mechanism 174 MUST/SHOULD/...". Note, that the phrasing does not imply that this 175 document defines a specific security mechanism, but defines the 176 requirements that every security mechanism should comply to. 178 This document refers to both PTP and NTP. For the sake of 179 consistency, throughout the document the term "master" applies to 180 both a PTP master and an NTP server. Similarly, the term "slave" 181 applies to both PTP slaves and NTP clients. The general term "clock" 182 refers to masters, slaves and PTP Transparent Clocks (TC). The term 183 "protocol packets" is refers generically to PTP and NTP messages. 185 2.2. Terms & Abbreviations 187 BC Boundary Clock 189 MITM Man In The Middle 191 NTP Network Time Protocol 193 OC Ordinary Clock 195 PTP Precision Time Protocol 197 Secured clock A clock that supports a security mechanism that 198 complies to the requirements in this document 200 TC Transparent Clock 202 Unsecured clock A clock that does not support a security mechanism 203 according to the requirments in this document 205 3. Security Threats 207 This section discusses the possible attacker types, and analyzes 208 various attacks against time synchronization protocols. 210 The literature is rich with security threats of time synchronization 211 protocols, e.g., [Traps], [AutoKey], [TM], [SecPTP], and [SecSen]. 212 The threat analysis in this document is mostly based on [TM]. 214 3.1. Threat Model 216 A time synchronization protocol can be attacked by various types of 217 attackers. 219 The analysis in this documents classifies attackers according to 2 220 criteria, as described in 3.1.1. and 3.1.2. 222 3.1.1. Internal vs. External Attackers 224 In the context of internal and external attackers, the underlying 225 assumption is that the time synchronization protocol is secured 226 either by an encryption or an authentication mechanism. 228 Internal attackers either have access to a trusted segment of the 229 network, or possess the encryption or authentication keys. External 230 attackers, on the other hand, do not have the keys, and are exposed 231 only to the encrypted or authenticated traffic. Thus, an internal 232 attacker can maliciously tamper with legitimate traffic in the 233 network, as well as generate its own traffic and make it appear 234 legitimate to its attacked nodes. 236 Obviously, in the absence of a security mechanism there is no 237 distinction between internal and external attackers, since all 238 attackers are internal in practice. 240 3.1.2. Man in the Middle (MITM) vs. Packet Injector 242 MITM attackers are located in a position that allows interception and 243 modification of in-flight protocol packets, while a traffic injector 244 cannot intercept legitimate packets, but can record them, replay old 245 messages, and generate its own traffic. 247 3.2. Threat Analysis 249 3.2.1. Packet Interception and Manipulation 251 A packet interception and manipulation attack results when a Man-In- 252 The-Middle (MITM) attacker intercepts timing protocol packets, alters 253 them and relays them to their destination, allowing the attacker to 254 maliciously tamper with the protocol. This can result in a situation 255 where the time protocol is apparently operational but providing 256 intentionally inaccurate information. 258 3.2.2. Spoofing 260 In spoofing, an attacker masquerades as a legitimate node in the 261 network. For example, an attacker can impersonate the master, 262 allowing malicious distribution of false timing information. As with 263 packet interception and manipulation, this can result in a situation 264 where the time protocol is apparently operational but providing 265 intentionally inaccurate information. 267 3.2.3. Replay Attack 269 In a replay attack, an attacker records protocol packets and replays 270 them at a later time. This can also result in a situation where the 271 time protocol is apparently operational but providing intentionally 272 inaccurate information. 274 3.2.4. Rogue Master Attack 276 In a rogue master attack, an attacker causes other nodes in the 277 network to believe it is a legitimate master. As opposed to the 278 spoofing attack, in the Rouge Master attack the attacker does not 279 fake its identity, but rather manipulates the master election 280 process. For example, in PTP, an attacker can manipulate the Best 281 Master Clock Algorithm (BMCA), and cause other nodes in the network 282 to believe it is the most eligible candidate to be a grandmaster. 284 3.2.5. Packet Interception and Removal 286 A packet interception and removal attack results when a Man-In-The- 287 Middle attacker intercepts and drops protocol packets, preventing the 288 destination node from receiving the timing information. 290 3.2.6. Packet Delay Manipulation 292 In a packet delay manipulation scenario, a Man-In-The-Middle attacker 293 intercepts protocol packets, and relays them to their destination 294 after adding a maliciously computed delay. 296 3.2.7. Cryptographic Performance Attacks 298 In cryptographic performance attacks, an attacker transmits fake 299 protocol packet, causing high utilization of the cryptographic engine 300 at the receiver, which attempts to verify the integrity of these fake 301 packets. 303 3.2.8. L2/L3 DoS Attacks 305 There are many possible Layer 2 and Layer 3 Denial of Service 306 attacks. As the target's availability is compromised, the timing 307 protocol is affected accordingly. 309 3.2.9. Master Time Source Spoofing (e.g. GPS fraud) 311 In time source spoofing, an attacker spoofs the accurate time source 312 of the master. For example, if the master uses a GPS based clock as 313 its reference source, an attacker can spoof the GPS satellites, 314 causing the master to use a false reference time. 316 3.3. Threat Analysis Summary 318 The two key factors to a threat analysis are the severity and the 319 likelihood of each of the analyzed attacks. 321 Table 1 summarizes the security attacks presented in 3.2. For each 322 attack, the table specifies its impact, and its applicability to each 323 of the attacker types presented in 3.1. 325 The Impact column provides an intuition to the severity of each 326 attack, and the relevant Attacker Type columns provide an intuition 327 about the how difficult each attack is to implement, and hence about 328 the likelihood of each attack. 330 The impact column in Table 1 can have one of 3 values: 332 o False time - slaves align to a false time or frequency value due 333 to the attack. 335 o Accuracy degradation - the attack yields a degradation in the 336 slave accuracy, but does not completely compromise the slaves' 337 time and frequency. 339 o DoS - the attack causes a denial of service to the attacked node, 340 whose impact is not restricted to the time synchronization 341 protocol. 343 The Attacket Type columns refer to the 4 possible combinations of the 344 attacker types defined in 3.1. 346 +-----------------------------+-------------------++-------------------+ 347 | Attack | Impact || Attacker Type | 348 | +-----+--------+----++---------+---------+ 349 | |False|Accuracy| ||Internal | Extenal | 350 | |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.| 351 +-----------------------------+-----+--------+----++----+----+----+----+ 352 |Interception and manipulation| + | | || + | | | | 353 +-----------------------------+-----+--------+----++----+----+----+----+ 354 |Spoofing | + | | || + | + | | | 355 +-----------------------------+-----+--------+----++----+----+----+----+ 356 |Replay attack | + | | || + | + | | | 357 +-----------------------------+-----+--------+----++----+----+----+----+ 358 |Rogue master attack | + | | || + | + | | | 359 +-----------------------------+-----+--------+----++----+----+----+----+ 360 |Interception and Removal | | + | || + | | + | | 361 +-----------------------------+-----+--------+----++----+----+----+----+ 362 |Packet delay manipulation | + | | || + | | + | | 363 +-----------------------------+-----+--------+----++----+----+----+----+ 364 |Crypt. performance attacks | | | + || + | + | + | + | 365 +-----------------------------+-----+--------+----++----+----+----+----+ 366 |DoS attacks | | | + || + | + | + | + | 367 +-----------------------------+-----+--------+----++----+----+----+----+ 368 |Master Time source spoofing | + | | || + | + | + | + | 369 +-----------------------------+-----+--------+----++----+----+----+----+ 370 Table 1 Threat Analysis - Summary 372 4. Security Requirements 374 4.1. Clock Identity Authentication 376 Requirement 378 The security mechanism MUST provide a means for each clock to 379 authenticate the sender of a protocol packet. 381 Discussion 383 In the context of this document, authentication refers to: 385 o Identification: verifying the identity of the peer clock. 387 o Authorization: verifying that the peer clock is permitted to play 388 the role that it plays in the protocol. For example, some nodes 389 may be permitted to be masters, while other nodes are only 390 permitted to be slaves or TCs. 392 The following subsections describe 4 distinct cases of clock 393 authentication. 395 4.1.1. Authentication of Masters 397 Requirement 399 The security mechanism MUST support an authentication mechanism, 400 allowing slave clocks to authenticate the identity of master clocks. 402 4.1.2. Proventication of Masters 404 Requirement 406 The security mechanism MUST support a proventication mechanism, to be 407 used in cases where end-to-end authentication is not possible. 409 Discussion 411 Slaves and transparent clocks authenticate masters in order to ensure 412 the authenticity of the time source. 414 In some cases a slave is connected to an intermediate master, that is 415 not the primary time source. For example, in PTP a slave can be 416 connected to a Boundary Clock (BC), which in turn is connected to a 417 grandmaster. A similar example in NTP is when a client is connected 418 to a stratum 2 server, which is connected to a stratum 1 server. In 419 both the PTP and the NTP cases, the slave authenticates the 420 intermediate master, and the intermediate master authenticates the 421 primary master. This inductive authentication process is referred to 422 in [AutoKey] as proventication. 424 4.1.3. Authentication of Slaves 426 Requirement 428 The security mechanism SHOULD provide a means for a master to 429 authenticate its slaves. 431 Discussion 433 Slaves are authenticated by masters in order to verify that the slave 434 is authorized to receive timing services from the master. 436 Authentication of slaves prevents unauthorized clocks from receiving 437 time services, and also reduces unnecessary load on the master clock, 438 by preventing the master from serving unauthorized clocks. It could 439 be argued that the authentication of slaves could put a higher load 440 on the master then serving the unauthorized clock. This tradeoff will 441 need to be discussed further. 443 4.1.4. PTP: Authentication of Transparent Clocks 445 Requirement 447 The security mechanism for PTP SHOULD provide a means for a master to 448 authenticate the TCs. 450 Discussion 452 Transparent clocks are authenticated by peer masters, slaves and TCs. 454 Authentication of TCs, much like authentication of slaves, reduces 455 unnecessary load on the master clock and peer TCs, by preventing the 456 master from serving unauthorized clocks. It also prevents malicious 457 TCs from attacking the protocol by manipulating the correctionField. 458 It could also be argued that the authentication could result in a 459 higher load then merely serving the unauthorized devices. This 460 tradeoff will need to be discussed further. 462 4.1.5. PTP: Authentication of Announce Messages 464 Requirement 466 The security mechanism for PTP MUST support authentication of 467 Announce messages. 469 Discussion 471 Master election is performed in PTP using the Best Master Clock 472 Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock 473 attributes using Announce messages, and the best master is elected 474 based on the information gathered from all the candidates. Announce 475 messages must be authenticated in order to prevent malicious master 476 attacks. 478 Note, that this subsection specifies a requirement that is not 479 necessarily included in 4.1.1. or in 4.1.3. , since the BMCA is 480 initiated before clocks have been defined as masters or slaves. 482 4.2. Data integrity 484 Requirement 486 The security mechanism MUST protect the integrity of protocol 487 packets. 489 Discussion 491 While subsection 4.1. refers to ensuring WHO sent the protocol 492 packet, this subsection refers to ensuring that the packet arrived 493 intact. The integrity protection mechanism ensures the authenticity 494 and completeness of data from the data originator. 496 4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 498 Requirement 500 A security mechanism for PTP MUST support hop-by-hop integrity 501 protection. 503 Requirement 505 A security mechanism for PTP SHOULD support end-to-end integrity 506 protection. 508 Discussion 509 Specifically in PTP, when protocol packets are subject to 510 modification by TCs, the integrity protection can be enforced in one 511 of two approaches, end-to-end or hop-by-hop. 513 4.2.1.1. Hop by Hop Integrity Protection 515 Each hop that needs to modify a protocol packet: 517 o Verifies its integrity. 519 o Modifies the packet, i.e., modifies the correctionField. 521 o Re-generates the integrity protection, e.g., re-computes a Message 522 Authentication Code. 524 In the hop-by-hop approach, the integrity of protocol packets is 525 protected by induction on the path from the originator to the 526 receiver. 528 This approach is simple, but allows malicious TCs to modify protocol 529 packets. 531 4.2.1.2. End to End Integrity Protection 533 In this approach, the integrity protection is maintained on the path 534 from the originator of a protocol packet to the receiver. This allows 535 the receiver to validate the protocol packet without the ability of 536 intermediate TCs to manipulate the packet. 538 Since TCs need to modify the correctionField, a separate integrity 539 protection mechanism is used specifically for the correctionField. 541 The end-to-end approach limits the TC's impact to the correctionField 542 alone, while the rest of the protocol packet is protected on an end- 543 to-end basis. 545 4.3. Availability 547 Requirement 549 The security mechanism MUST protect the time synchronization protocol 550 from DoS attacks by external attackers. 552 Discussion 554 The protocol availability can be compromised by several different 555 attacks. An attacker can inject protocol messages to implement the 556 spoofing attack (3.2.2. ) or the rogue master attack (3.2.4. ), 557 causing denial of service to the attackee. An authentication 558 mechanism (4.1. ) limits these attacks strictly to internal 559 attackers, and thus prevents external attackers from performing them. 561 DoS attacks at lower layers of the protocol stack (3.2.8. ) can still 562 be implemented by external attackers even in the presence of an 563 authentication mechanism. 565 4.4. Replay Protection 567 Requirement 569 Protocol messages MUST be resistant to replay attacks. 571 4.5. Cryptographic Keys & Security Associations 573 4.5.1. Security Association 575 Requirement 577 The security protocol MUST support an association protocol where: 579 o Two or more clocks authenticate each other. 581 o The clocks generate and agree on a cryptographic session key. 583 Discussion 585 The security requirements in 4.1. and 4.2. require usage of 586 cryptographich mechanisms, deploying cryptographic keys. A security 587 association is an essential building block in these mechanisms. 589 4.5.2. Unicast and Multicast 591 Requirement 593 The security mechanism MUST support security association protocols 594 for unicast and for multicast associations. 596 Discussion 598 A unicast protocol requires an association protocol between two 599 clocks, whereas a multicast protocol requires an association protocol 600 among two or more clocks, where one of the clocks is a master. 602 4.5.3. Key Freshness 604 Requirement 606 The cryptographic keys MUST be refreshed periodically. 608 Requirement 610 The association protocol MUST be invoked periodically, where each 611 instance of the association protocol MUST produce a different session 612 key. 614 4.6. Performance 616 Requirement 618 The security mechanism MUST be designed in such a way that it does 619 not degrade the quality of the time transfer. 621 Requirement 623 The mechanism SHOULD be relatively lightweight, as client 624 restrictions often dictate a low processing and memory footprint, and 625 because the server may have extensive fan-out. 627 Requirement 629 The mechanism also SHOULD not require excessive storage of client 630 state in the master, nor significantly increase bandwidth 631 consumption. 633 Discussion 635 Note that the performance requirements refer to a time- 636 synchronization-specific security mechanism. In systems where a 637 security protocol is used for other types of traffic as well, this 638 document does not place any performance requirements on the security 639 protocol performance. For example, if IPsec encryption is used for 640 securing all information between the master and slave node, including 641 information that is not part of the time protocol, the requirements 642 in this subsection are not necessarily applicable. 644 4.7. Confidentiality 646 Requirement 647 The security mechanism MAY provide confidentiality protection of the 648 protocol packets. 650 Discussion 652 In the context of time synchronization, confidentiality is typically 653 of low importance, since timing information is typically not 654 considered secret information. 656 Confidentiality can play an important role when service providers 657 charge payment for time synchronization services, but these cases are 658 rather esoteric. 660 Confidentiality can also prevent an MITM attacker from identifying 661 protocol packets. Thus, confidentiality can assist in protecting the 662 timing protocol against packet delay attacks, where the attacker 663 selectively adds delay to time protocol packets. 665 4.8. Protection against packet delay attacks 667 Requirement 669 The security mechanism MAY include a means to detect packet delay 670 attacks. 672 Requirement 674 The security mechanism MAY include a protection switching mechanism 675 that allows a node that detects a delay attack to switch over to a 676 secondary master. 678 4.9. Combining Secured with Unsecured Nodes 680 Integrating a security mechanism into a time synchronized system is a 681 complex process, and in some cases may require a gradual process, 682 where new equipment supports the security mechanism, and is required 683 to interoperate with legacy equipment without the security features. 685 4.9.1. Secure Mode 687 Requirement 689 The security mechanism MUST support a secure mode, where only secured 690 clocks are permitted to take part in the synchronization protocol. A 691 protocol packet received from an unsecured clock MUST be discarded. 693 Discussion 694 While the requirement in this subsection is a bit similar to the one 695 in 4.1. , it explicitly defines the secure mode, as opposed to the 696 hybrid mode presented in the next subsection. 698 4.9.2. Hybrid Mode 700 Requirement 702 The security protocol MAY support a hybrid mode, where both secured 703 and unsecured clocks are permitted to take part in the protocol. 705 Discussion 707 The hybrid mode allows both secured and unsecured clocks to take part 708 in the synchronization protocol. 710 Requirement 712 A master in the hybrid mode SHOULD be a secured clock. 714 A secured slave in the hybrid mode SHOULD discard all protocol 715 packets received from unsecured clocks. 717 Discussion 719 This requirement ensures that the existence of unsecured clocks does 720 not compromise the security provided to secured clocks. Hence, 721 secured slaves only "trust" protocol packets received from a secured 722 clock. An unsecured clock can receive protocol packets from either 723 secured clocks, or unsecured clocks. 725 Note that the security scheme in [NTPv4] with [AutoKey] does not 726 satisfy this requirement, since nodes prefer the server with the best 727 clock, and not necessarily the server that supports authentication. 728 For example, a stratum 2 server is connected to two stratum 1 729 servers, Server A, supporting authentication, and server B, without 730 authentication. If server B has a more accurate clock than A, the 731 stratum 2 server chooses server B, in spite of the fact it does not 732 support authentication. 734 5. Summary of Requirements 736 +-----------+--------------------------------------+---------------+ 737 | Section | Requirement | Type | 738 +-----------+--------------------------------------+---------------+ 739 | 4.1. | Authentication of sender. | MUST | 740 | +--------------------------------------+---------------+ 741 | | Authentication of master. | MUST | 742 | +--------------------------------------+---------------+ 743 | | Proventication. | MUST | 744 | +--------------------------------------+---------------+ 745 | | Authentication of slaves. | SHOULD | 746 | +--------------------------------------+---------------+ 747 | | PTP: Authentication of TCs. | SHOULD | 748 | +--------------------------------------+---------------+ 749 | | PTP: Authentication of Announce | SHOULD | 750 | | messages. | | 751 +-----------+--------------------------------------+---------------+ 752 | 4.2. | Integrity protection. | MUST | 753 | +--------------------------------------+---------------+ 754 | | PTP: hop-by-hop integrity protection.| MUST | 755 | +--------------------------------------+---------------+ 756 | | PTP: end-to-end integrity protection.| SHOULD | 757 +-----------+--------------------------------------+---------------+ 758 | 4.3. | Protection against DoS attacks. | MUST | 759 +-----------+--------------------------------------+---------------+ 760 | 4.4. | Replay protection. | MUST | 761 +-----------+--------------------------------------+---------------+ 762 | 4.5. | Security association. | MUST | 763 | +--------------------------------------+---------------+ 764 | | Unicast and multicast associations. | MUST | 765 | +--------------------------------------+---------------+ 766 | | Key freshness. | MUST | 767 +-----------+--------------------------------------+---------------+ 768 | 4.6. | Performance: no degradation in | MUST | 769 | | quality of time transfer. | | 770 | +--------------------------------------+---------------+ 771 | | Performance: lightweight. | SHOULD | 772 | +--------------------------------------+---------------+ 773 | | Performance: storage, bandwidth. | MUST | 774 +-----------+--------------------------------------+---------------+ 775 | 4.7. | Confidentiality protection. | MAY | 776 +-----------+--------------------------------------+---------------+ 777 | 4.8. | Protection against delay attacks. | MAY | 778 +-----------+--------------------------------------+---------------+ 779 | 4.9. | Secure mode. | MUST | 780 | +--------------------------------------+---------------+ 781 | | Hybrid mode. | MAY | 782 +-----------+--------------------------------------+---------------+ 783 Table 2 Summary of Security Requirements 785 6. Additional security implications 787 This section discusses additional implications of the interaction 788 between time synchronization protocols and security mechanisms. 790 This section refers to time synchronization security mechanisms, as 791 well as to "external" security mechanisms, i.e., security mechanisms 792 that are not strictly related to the time synchronization protocol. 794 6.1. Security and on-the-fly Timestamping 796 Time synchronization protocols often require protocol packets to be 797 modified during transmission and reception. Both NTP and PTP in one- 798 step mode require clocks to modify protocol packets with the time of 799 transmission or reception. 801 In the presence of a security mechanism, whether encryption or 802 integrity protection: 804 o During transmission the security protocol must be applied after 805 integrating the timestamp into the packet. 807 o During reception, the encryption or integrity check must be 808 performed before modifying the packet with the time of reception. 810 To allow high accuracy, timestamping is typically performed as close 811 to the transmission or reception time as possible. However, since the 812 security engine must be placed between the timestamping function and 813 the physical interface, in some cases it may introduce non- 814 deterministic latency that causes accuracy degradation. These 815 performance aspects have been analyzed in the literature, e.g., in 816 [1588IPsec] and [Tunnel]. 818 6.2. Security and Two-Step Timestamping 820 PTP supports a two-step mode of operation, where the time of 821 transmission and the time of reception of protocol packets are 822 measured without modifying the packets. As opposed to one-step mode, 823 two step timestamping can be performed at the physical interface even 824 in the presence of a security mechanism. 826 Note that if an encryption mechanism is used, it presents a challenge 827 to the timestamping mechanism, since time protocol packets are 828 encrypted when traversing the physical interface, and are thus 829 impossible to identify. A possible solution to this problem 830 [IPsecSync] is to include an indication in the encryption header that 831 identifies time synchronization packets. 833 6.3. Intermediate Clocks 835 A time synchronization protocol allows slaves to receive time 836 information from an accurate time source. Time information is sent 837 over a path that often traverses one or more intermediate clocks. 839 o In NTP, time information originated from a stratum 1 server can be 840 distributed to stratum 2 servers, and in turn distributed from the 841 stratum 2 servers to NTP clients. In this case, the stratum 2 842 servers are a layer of intermediate clocks. 844 o In PTP, BCs and TCs are intermediate nodes used to improve the 845 accuracy of time information conveyed between the grandmaster and 846 the slaves. 848 A common rule of thumb in network security is that end-to-end 849 security is the best policy, as it secures the entire path between 850 the data originator and its receiver. The usage of intermediate nodes 851 implies that if a security mechanism is deployed in the network, all 852 intermediate nodes must be exposed to the security key since they 853 must be able to send time information to the slaves, or to modify 854 time information sent through them. 856 This inhehrent property of using intermediate clocks increases the 857 system's exposure to internal threats, as there is a large number of 858 nodes that are exposed to the security keys. 860 6.4. The Effect of External Security Protocols on Time Synchronization 862 Time synchronization protocols are often deployed in systems that use 863 security mechanisms and protocols. 865 A typical example is the 3GPP Femtocell network [3GPP], where IPsec 866 is used for securing traffic between a Femtocell and the Femto 867 Gateway. All traffic between these two nodes is secured by IPsec, 868 including the time synchronization protocol traffic. This use-case is 869 thoroughly discussed in [IPsecSync]. 871 Another typical example is the usage of MACsec encryption in L2 872 networks that deploy time synchronization [AvbAssum]. 874 The usage of external security mechanisms may affect time 875 synchronization protocols as follows: 877 o Timestamping accuracy can be affected, as described in 6.1. 879 o If traffic is secured between two nodes in the network, no 880 intermediate clocks can be used between these two nodes. In the 881 [3GPP] example, if traffic between the Femtocell and the Femto 882 Gateway is encrypted, then time protocol packets are sent over the 883 underlying network without modification, and thus cannot enjoy the 884 improved accuracy provided by intermediate clock nodes. 886 6.5. External Security Services Requiring Time Synchronization 888 Certificate validation requires the sender and receiver to be time 889 synchronized. Thus, synchronization is required for establishing 890 security protocols such as IKEv2 and TLS. 892 An even stronger interdependence between a time synchronization 893 protocol and a security mechanism is defined in [AutoKey], which 894 defines mutual dependence between the acquired time information, and 895 the authentication protocol that secures it. 897 7. Issues for Further Discussion 899 o The key distribution is outside the scope of this document. 900 Although this is a cardinal element in any security system, it is 901 not a security requirement, and is thus not described here. 903 8. Security Considerations 905 The security considerations of network timing protocols are presented 906 throughout this document. 908 9. IANA Considerations 910 There are no new IANA considerations implied by this document. 912 10. Acknowledgments 914 This document was prepared using 2-Word-v2.0.template.dot. 916 11. References 918 11.1. Normative References 920 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 921 Requirement Levels", BCP 14, RFC 2119, March 1997. 923 [NTPv4] Mills, D., Delaware, U., Martin, J., Burbank, J., 924 Kasch, W., "Network Time Protocol Version 4: Protocol 925 and Algorithms Specification", RFC 5905, June 2010. 927 [AutoKey] Haberman, B., Mills, D., "Network Time Protocol 928 Version 4: Autokey Specification", RFC 5906, June 929 2010. 931 11.2. Informative References 933 [IEEE 1588] IEEE TC 9 Test and Measurement Society 2000, "1588 934 IEEE Standard for a Precision Clock Synchronization 935 Protocol for Networked Measurement and Control Systems 936 Version 2", IEEE Standard, 2008. 938 [Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R., 939 "Traps and pitfalls in secure clock synchronization" 940 in Proceedings of 2007 International Symposium for 941 Precision Clock Synchronization for Measurement, 942 Control and Communication, ISPCS 2007, pp. 18-24, 943 2007. 945 [TM] T. Mizrahi, "Time synchronization security using IPsec 946 and MACsec", ISPCS 2011, pp. 38-43, 2011. 948 [SecPTP] J. Tsang, K. Beznosov, "A security analysis of the 949 precise time protocol (short paper)," 8th 950 International Conference on Information and 951 Communication Security (ICICS 2006), pp. 50-59, 2006. 953 [SecSen] S. Ganeriwal, C. Popper, S. Capkun, M. B. Srivastava, 954 "Secure Time Synchronization in Sensor Networks", ACM 955 Trans. Info. and Sys. Sec., Volume 11, Issue 4, July 956 2008. 958 [AvbAssum] D. Pannell, "Audio Video Bridging Gen 2 Assumptions", 959 IEEE 802.1 AVB Plenary, work in progress, May 2012. 961 [IPsecSync] Y. Xu, "IPsec security for packet based 962 synchronization", IETF, draft-xu-tictoc-ipsec- 963 security-for-synchronization (work in progress), 2011. 965 [3GPP] 3GPP, "Security of Home Node B (HNB) / Home evolved 966 Node B (HeNB)", 3GPP TS 33.320 10.4.0 (work in 967 progress), 2011. 969 [1588IPsec] A. Treytl, B. Hirschler, "Securing IEEE 1588 by IPsec 970 tunnels - An analysis", in Proceedings of 2010 971 International Symposium for Precision Clock 972 Synchronization for Measurement, Control and 973 Communication, ISPCS 2010, pp. 83-90, 2010. 975 [Tunnel] A. Treytl, B. Hirschler, and T. Sauter, "Secure 976 tunneling of high precision clock synchronisation 977 protocols and other timestamped data", in Proceedings 978 of the 8th IEEE International Workshop on Factory 979 Communication Systems (WFCS), vol. ISBN 978-1-4244- 980 5461-7, pp. 303-313, 2010. 982 Authors' Addresses 984 Tal Mizrahi 985 Marvell 986 6 Hamada St. 987 Yokneam, 20692 Israel 989 Email: talmi@marvell.com 991 Karen O'Donoghue 992 7167 Goby Lane 993 King George, VA 22485 995 Email: odonoghue@isoc.org