idnits 2.17.1 draft-ietf-tictoc-security-requirements-00.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 (November 30, 2011) is 4531 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Traps' is defined on line 637, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TICTOC Working Group Tal Mizrahi 2 Internet Draft Marvell 3 Intended status: Informational Karen O'Donoghue 4 Expires: May 2012 ISOC 5 November 30, 2011 7 TICTOC Security Requirements 8 draft-ietf-tictoc-security-requirements-00.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 May 30, 2012. 45 Copyright Notice 47 Copyright (c) 2011 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. Abbreviations ........................................... 4 66 3. Security Threats ............................................. 4 67 3.1. Packet interception and manipulation .................... 5 68 3.2. Spoofing ................................................ 5 69 3.3. Replay attack ........................................... 5 70 3.4. Rogue master attack ..................................... 5 71 3.5. Packet Interception and Removal ......................... 5 72 3.6. Packet delay manipulation ............................... 5 73 3.7. Cryptographic performance attacks ....................... 6 74 3.8. DoS attacks ............................................. 6 75 3.9. Time source spoofing (e.g. GPS fraud) ................... 6 76 4. Security Requirements ........................................ 6 77 4.1. Clock Identity Authentication ........................... 6 78 4.1.1. Authentication and Proventication of Masters ....... 6 79 4.1.2. Authentication of Slaves ........................... 7 80 4.1.3. PTP: Authentication of Transparent Clocks........... 7 81 4.1.4. PTP: Authentication of Announce Messages ........... 8 82 4.2. Data integrity .......................................... 8 83 4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 8 84 4.2.1.1. Hop by Hop Integrity Protection ............... 9 85 4.2.1.2. End to End Integrity Protection ............... 9 86 4.3. Availability ........................................... 10 87 4.4. Replay Protection ...................................... 10 88 4.5. Cryptographic Keys & Security Associations ............. 10 89 4.5.1. Security Association .............................. 10 90 4.5.2. Unicast and Multicast ............................. 10 91 4.5.3. Key Freshness ..................................... 11 93 4.6. Performance ............................................ 11 94 4.7. Confidentiality......................................... 11 95 4.8. Protection against packet delay attacks ................ 12 96 5. Summary of Requirements ..................................... 12 97 6. Additional security implications ............................ 13 98 7. Issues for Further Discussion ............................... 13 99 8. Security Considerations ..................................... 14 100 9. IANA Considerations ......................................... 14 101 10. Acknowledgments ............................................ 14 102 11. References ................................................. 14 103 11.1. Normative References .................................. 14 104 11.2. Informative References ................................ 15 106 1. Introduction 108 As time synchronization protocols are becoming increasingly common 109 and widely deployed, concern about the resulting exposure to various 110 security threats is increasing. If a time synchronization protocol is 111 compromised, the applications it serves are prone to a range of 112 possible attacks including Denial-of-Service or incorrect behavior. 114 This document focuses on the security aspects of the Precision Time 115 Protocol ([IEEE 1588]) and the Network Time Protocol ([NTPv4]). The 116 Network Time Protocol was defined with an inherent security protocol, 117 defined in [NTPv4] and in [AutoKey]. The IEEE 1588 includes an 118 experimental security protocol, defined in Annex K of the standard, 119 but this Annex was never formalized into a fully defined security 120 protocol. 122 This document attempts to add clarity to the time synchronization 123 protocol security requirements discussion by addressing a series of 124 questions. It is expected that this document will evolve into 125 possibly two documents including one on requirements and one 126 providing clarity around the additional questions raised below. Until 127 the discussion has matured sufficiently, it will be captured in this 128 document. The four primary questions addressed by this draft include: 130 (1) What are the threats that need to be addressed for the time 131 synchronization protocol, and thus what security services need to be 132 provided? (e.g. a malicious NTP server or PTP master) 134 (2) What external security practices impact the security and 135 performance of time keeping, and what can be done to mitigate these 136 impacts? (e.g. an IPSec tunnel in the synchronization traffic path) 138 (3) What are the security impacts of time synchronization protocol 139 practices? (e.g. on-the-fly modification of timestamps) 140 (4) What are the dependencies between other security services and 141 time synchronization? (e.g. which comes first - the certificate or 142 the timestamp?) 144 It is expected that the final version of this document will define a 145 set of requirements for security solutions for time synchronization 146 protocols, focusing on the IEEE 1588 and NTP. 148 2. Conventions Used in this Document 150 2.1. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [KEYWORDS]. 156 This document describes security requirements, and thus requirements 157 are phrased in the document in the form "the security mechanism 158 MUST/SHOULD/...". Note, that the phrasing does not imply that this 159 document defines a specific security mechanism, but defines the 160 requirements that every security mechanism should comply to. 162 This document refers to both PTP and NTP. For the sake of 163 consistency, throughout the document the term "master" applies to 164 both a PTP master and an NTP server. Similarly, the term "slave" 165 applies to both PTP slaves and NTP clients. The general term "clock" 166 refers to masters, slaves and PTP Transparent Clocks (TC). The term 167 "protocol packets" is refers generically to PTP and NTP messages. 169 2.2. Abbreviations 171 BC Boundary Clock 173 MITM Man In The Middle 175 NTP Network Time Protocol 177 OC Ordinary Clock 179 PTP Precision Time Protocol 181 TC Transparent Clock 183 3. Security Threats 185 The following section defines the security threats that are discussed 186 in subsequent sections. 188 3.1. Packet interception and manipulation 190 A packet interception and manipulation attack results when a Man-In- 191 The-Middle (MITM) attacker intercepts timing protocol packets, alters 192 them and relays them to their destination, allowing the attacker to 193 maliciously tamper with the protocol. This can result in a situation 194 where the time protocol is apparently operational but providing 195 intentionally inaccurate information. 197 3.2. Spoofing 199 In spoofing, an attacker masquerades as a legitimate node in the 200 network. For example, an attacker can impersonate the master, 201 allowing malicious distribution of false timing information. As with 202 packet interception and manipulation, this can result in a situation 203 where the time protocol is apparently operational but providing 204 intentionally inaccurate information. 206 3.3. Replay attack 208 In a replay attack, an attacker records protocol packets and replays 209 them at a later time. This can also result in a situation where the 210 time protocol is apparently operational but providing intentionally 211 inaccurate information. 213 3.4. Rogue master attack 215 In a rogue master attack, an attacker causes other nodes in the 216 network to believe it is a legitimate master. As opposed to the 217 spoofing attack, in the Rouge Master attack the attacker does not 218 fake its identity, but rather manipulates the master election 219 process. For example, in PTP, an attacker can manipulate the Best 220 Master Clock Algorithm (BMCA), and cause other nodes in the network 221 to believe it is the most eligible candidate to be a grandmaster. 223 3.5. Packet Interception and Removal 225 A packet interception and removal attack results when a Man-In-The- 226 Middle attacker intercepts and drops protocol packets, preventing the 227 destination node from receiving the timing information. 229 3.6. Packet delay manipulation 231 In a packet delay manipulation scenario, a Man-In-The-Middle attacker 232 intercepts protocol packets, and relays them to their destination 233 after adding a maliciously computed delay. 235 3.7. Cryptographic performance attacks 237 In cryptographic performance attacks, an attacker transmits fake 238 protocol packet, causing high utilization of the cryptographic engine 239 at the receiver, which attempts to verify the integrity of these fake 240 packets. 242 3.8. DoS attacks 244 There are many possible Layer 2 and Layer 3 Denial of Service 245 attacks. As the target's availability is compromised, the timing 246 protocol is affected accordingly. 248 3.9. Time source spoofing (e.g. GPS fraud) 250 In time source spoofing, an attacker spoofs the accurate time source 251 of the master. For example, if the master uses a GPS based clock as 252 its reference source, an attacker can spoof the GPS satellites, 253 causing the master to use a false reference time. 255 4. Security Requirements 257 4.1. Clock Identity Authentication 259 Requirement 261 The security mechanism MUST provide a means for each clock to 262 authenticate the sender of a protocol packet. 264 Discussion 266 In the context of this document, authentication refers to: 268 o Identification: verifying the identity of the peer clock. 270 o Authorization: verifying that the peer clock is permitted to play 271 the role that it plays in the protocol. For example, some nodes 272 may be permitted to be masters, while other nodes are only 273 permitted to be slaves or TCs. 275 The following subsections describe 4 distinct cases of clock 276 authentication. 278 4.1.1. Authentication and Proventication of Masters 280 Requirement 281 The security mechanism MUST support a proventication mechanism, to be 282 used in cases where end-to-end authentication is not possible. 284 Discussion 286 Slaves and transparent clocks authenticate masters in order to ensure 287 the authenticity of the time source. 289 In some cases a slave is connected to an intermediate master, that is 290 not the primary time source. For example, in PTP a slave can be 291 connected to a Boundary Clock (BC), which in turn is connected to a 292 grandmaster. A similar example in NTP is when a client is connected 293 to a stratum 2 server, which is connected to a stratum 1 server. In 294 both the PTP and the NTP cases, the slave authenticates the 295 intermediate master, and the intermediate master authenticates the 296 primary master. This inductive authentication process is referred to 297 in [AutoKey] as proventication. 299 4.1.2. Authentication of Slaves 301 Requirement 303 The security mechanism SHOULD provide a means for a master to 304 authenticate its slaves. 306 Discussion 308 Slaves are authenticated by masters in order to verify that the slave 309 is authorized to receive timing services from the master. 311 Authentication of slaves prevents unauthorized clocks from receiving 312 time services, and also reduces unnecessary load on the master clock, 313 by preventing the master from serving unauthorized clocks. It could 314 be argued that the authentication of slaves could put a higher load 315 on the master then serving the unauthorized clock. This tradeoff will 316 need to be discussed further. 318 4.1.3. PTP: Authentication of Transparent Clocks 320 Requirement 322 The security mechanism for PTP SHOULD provide a means for a master to 323 authenticate the TCs. 325 Discussion 327 Transparent clocks are authenticated by peer masters, slaves and TCs. 329 Authentication of TCs, much like authentication of slaves, reduces 330 unnecessary load on the master clock and peer TCs, by preventing the 331 master from serving unauthorized clocks. It also prevents malicious 332 TCs from attacking the protocol by manipulating the correctionField. 333 It could also be argued that the authentication could result in a 334 higher load then merely serving the unauthorized devices. This 335 tradeoff will need to be discussed further. 337 4.1.4. PTP: Authentication of Announce Messages 339 Requirement 341 The security mechanism for PTP MUST support authentication of 342 Announce messages. 344 Discussion 346 Master election is performed in PTP using the Best Master Clock 347 Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock 348 attributes using Announce messages, and the best master is elected 349 based on the information gathered from all the candidates. Announce 350 messages must be authenticated in order to prevent malicious master 351 attacks. 353 Note, that this subsection specifies a requirement that is not 354 necessarily included in 4.1.1. or in 4.1.2. , since the BMCA is 355 initiated before clocks have been defined as masters or slaves. 357 4.2. Data integrity 359 Requirement 361 The security mechanism MUST protect the integrity of protocol 362 packets. 364 Discussion 366 While subsection 4.1. refers to ensuring WHO sent the protocol 367 packet, this subsection refers to ensuring that the packet arrived 368 intact. The integrity protection mechanism ensures the authenticity 369 and completeness of data from the data originator. 371 4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 373 Requirement 374 A security mechanism for PTP MUST support hop-by-hop integrity 375 protection. 377 Requirement 379 A security mechanism for PTP SHOULD support end-to-end integrity 380 protection. 382 Discussion 384 Specifically in PTP, when protocol packets are subjected to 385 modification by TCs, the integrity protection can be enforced in one 386 of two approaches, end-to-end or hop-by-hop. 388 4.2.1.1. Hop by Hop Integrity Protection 390 Each hop that needs to modify a protocol packet: 392 o Verifies its integrity. 394 o Modifies the packet, i.e., modifies the correctionField. 396 o Re-generates the integrity protection, e.g., re-computes a Message 397 Authentication Code. 399 In the hop-by-hop approach, the integrity of protocol packets is 400 protected by induction on the path from the originator to the 401 receiver. 403 This approach is simple, but allows malicious TCs to modify protocol 404 packets. 406 4.2.1.2. End to End Integrity Protection 408 In this approach, the integrity protection is maintained on the path 409 from the originator of a protocol packet to the receiver. This allows 410 the receiver to validate the protocol packet without the ability of 411 intermediate TCs to manipulate the packet. 413 Since TCs need to modify the correctionField, a separate integrity 414 protection mechanism is used specifically for the correctionField. 416 The end-to-end approach limits the TC's impact to the correctionField 417 alone, while the rest of the protocol packet is protected on an end- 418 to-end basis. 420 4.3. Availability 422 Requirement 424 The security mechanism MUST be resistant to DoS attacks from an 425 external attacker. 427 Discussion 429 This requirement is attained by clock authentication, as described in 430 4.1. . 432 4.4. Replay Protection 434 Requirement 436 Protocol messages MUST be resistant to replay attacks. 438 4.5. Cryptographic Keys & Security Associations 440 4.5.1. Security Association 442 Requirement 444 The security protocol MUST support an association protocol where: 446 o Two or more clocks authenticate each other. 448 o The clocks generate and agree on a cryptographic session key. 450 Discussion 452 The security requirements in 4.1. and 4 .2. require usage of 453 cryptographich mechanisms, deploying cryptographic keys. A security 454 association is an essential building block in these mechanisms. 456 4.5.2. Unicast and Multicast 458 Requirement 460 The security mechanism MUST support security association protocols 461 for unicast and for multicast associations. 463 Discussion 464 A unicast protocol requires an association protocol between two 465 clocks, whereas a multicast protocol requires an association protocol 466 among two or more clocks, where one of the clocks is a master. 468 4.5.3. Key Freshness 470 Requirement 472 The cryptographic keys MUST be refreshed periodically. 474 Requirement 476 The association protocol MUST be invoked periodically, where each 477 instance of the association protocol MUST produce a different session 478 key. 480 4.6. Performance 482 Requirement 484 The security mechanism MUST be designed in such a way that it does 485 not degrade the quality of the time transfer. 487 Requirement 489 The mechanism SHOULD be relatively lightweight, as client 490 restrictions often dictate a low processing and memory footprint, and 491 because the server may have extensive fan-out. 493 Requirement 495 The mechanism also SHOULD not require excessive storage of client 496 state in the master, nor significantly increase bandwidth 497 consumption. 499 4.7. Confidentiality 501 Requirement 503 The security mechanism MAY provide confidentiality protection of the 504 protocol packets. 506 Discussion 508 In the context of time synchronization, confidentiality is typically 509 of low importance, since timing information is typically not 510 considered secret information. 512 Confidentiality can play an important role when service providers 513 charge payment for time synchronization services, but these cases are 514 rather esoteric. 516 Confidentiality can also prevent an MITM attacker from identifying 517 protocol packets. Thus, confidentiality can assist in protecting the 518 timing protocol against packet delay attacks, where the attacker 519 selectively adds delay to time protocol packets. 521 4.8. Protection against packet delay attacks 523 Requirement 525 The security mechanism MAY include a means to detect packet delay 526 attacks. 528 Requirement 530 The security mechanism MAY include a protection switching mechanism 531 that allows a node that detects a delay attack to switch over to a 532 secondary master. 534 5. Summary of Requirements 536 +-----------+--------------------------------------+---------------+ 537 | Section | Requirement | Type | 538 +-----------+--------------------------------------+---------------+ 539 | 4.1. | Authentication of sender. | MUST | 540 | +--------------------------------------+---------------+ 541 | | Proventication. | MUST | 542 | +--------------------------------------+---------------+ 543 | | Authentication of slaves. | SHOULD | 544 | +--------------------------------------+---------------+ 545 | | PTP: Authentication of TCs. | SHOULD | 546 | +--------------------------------------+---------------+ 547 | | PTP: Authentication of Announce | SHOULD | 548 | | messages. | | 549 +-----------+--------------------------------------+---------------+ 550 | 4.2. | Integrity protection. | MUST | 551 | +--------------------------------------+---------------+ 552 | | PTP: hop-by-hop integrity protection.| MUST | 553 | +--------------------------------------+---------------+ 554 | | PTP: end-to-end integrity protection.| SHOULD | 555 +-----------+--------------------------------------+---------------+ 556 | 4.3. | Protection against DoS attacks. | MUST | 557 +-----------+--------------------------------------+---------------+ 558 | 4.4. | Replay protection. | MUST | 559 +-----------+--------------------------------------+---------------+ 560 | 4.5. | Security association. | MUST | 561 | +--------------------------------------+---------------+ 562 | | Unicast and multicast associations. | MUST | 563 | +--------------------------------------+---------------+ 564 | | Key freshness. | MUST | 565 +-----------+--------------------------------------+---------------+ 566 | 4.6. | Performance: no degradation in | MUST | 567 | | quality of time transfer. | | 568 | +--------------------------------------+---------------+ 569 | | Performance: lightweight. | SHOULD | 570 | +--------------------------------------+---------------+ 571 | | Performance: storage, bandwidth. | MUST | 572 +-----------+--------------------------------------+---------------+ 573 | 4.7. | Confidentiality protection. | MAY | 574 +-----------+--------------------------------------+---------------+ 575 | 4.8. | Protection against delay attacks. | MAY | 576 +-----------+--------------------------------------+---------------+ 577 Table 1 Summary of Security Requirements 579 6. Additional security implications 581 This section will discuss additional security implications as 582 outlined in the questions below. Contributions are welcome and 583 encouraged. 585 o What external security practices impact the security and 586 performance of time keeping? (and what can be done to mitigate 587 these impacts?) 589 o What are the security impacts of time synchronization protocol 590 practices? (e.g. on-the-fly modification of timestamps) 592 o What are the dependencies between other security services and time 593 synchronization? 595 7. Issues for Further Discussion 597 This section will discuss additional issues as identified below. 598 Again, contributions are welcome and encouraged. 600 o Integrity - end-to-end vs. hop-by-hop. 602 o Supporting a hybrid network, where some nodes are security enabled 603 and others are not. 605 o The key distribution is outside the scope of this document. 606 Although this is a cardinal element in any security system, it is 607 not a security requirement, and is thus not described here. 609 8. Security Considerations 611 The security considerations of network timing protocols are presented 612 throughout this document. 614 9. IANA Considerations 616 There are no new IANA considerations implied by this document. 618 10. Acknowledgments 620 This document was prepared using 2-Word-v2.0.template.dot. 622 11. References 624 11.1. Normative References 626 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 627 Requirement Levels", BCP 14, RFC 2119, March 1997. 629 [NTPv4] Mills, D., Delaware, U., Martin, J., Burbank, J., 630 Kasch, W., "Network Time Protocol Version 4: Protocol 631 and Algorithms Specification", RFC 5905, June 2010. 633 [AutoKey] Haberman, B., Mills, D., "Network Time Protocol 634 Version 4: Autokey Specification", RFC 5906, June 635 2010. 637 [Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R., 638 "Traps and pitfalls in secure clock synchronization" 639 in Proceedings of 2007 International Symposium for 640 Precision Clock Synchronization for Measurement, 641 Control and Communication, ISPCS 2007, pp. 18-24, 642 2007. 644 11.2. Informative References 646 [IEEE 1588] IEEE TC 9 Test and Measurement Society 2000, "1588 647 IEEE Standard for a Precision Clock Synchronization 648 Protocol for Networked Measurement and Control Systems 649 Version 2", IEEE Standard, 2008. 651 Authors' Addresses 653 Tal Mizrahi 654 Marvell 655 6 Hamada St. 656 Yokneam, 20692 Israel 658 Email: talmi@marvell.com 660 Karen O'Donoghue 661 7167 Goby Lane 662 King George, VA 22485 664 Email: odonoghue@isoc.org