--- 1/draft-ietf-tictoc-security-requirements-11.txt 2014-09-03 03:14:35.658403193 -0700 +++ 2/draft-ietf-tictoc-security-requirements-12.txt 2014-09-03 03:14:35.722404756 -0700 @@ -1,18 +1,18 @@ TICTOC Working Group T. Mizrahi Internet Draft Marvell Intended status: Informational -Expires: January 2015 July 21, 2014 +Expires: March 2015 September 3, 2014 Security Requirements of Time Protocols in Packet Switched Networks - draft-ietf-tictoc-security-requirements-11.txt + draft-ietf-tictoc-security-requirements-12.txt Abstract As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security @@ -33,21 +33,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 21, 2015. + This Internet-Draft will expire on March 3, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -73,66 +73,68 @@ 3.2.1. Packet Manipulation ................................ 8 3.2.2. Spoofing ........................................... 9 3.2.3. Replay Attack ...................................... 9 3.2.4. Rogue Master Attack ................................ 9 3.2.5. Packet Interception and Removal ................... 10 3.2.6. Packet Delay Manipulation ......................... 10 3.2.7. L2/L3 DoS Attacks ................................. 10 3.2.8. Cryptographic Performance Attacks ................. 10 3.2.9. DoS Attacks against the Time Protocol ............. 10 3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud) . 11 + 3.2.11. Exploiting Vulnerabilities in the Time Protocol .. 11 + 3.2.12. Network Reconnaissance ........................... 11 3.3. Threat Analysis Summary ................................ 11 4. Requirement Levels .......................................... 13 - 5. Security Requirements ....................................... 13 + 5. Security Requirements ....................................... 14 5.1. Clock Identity Authentication and Authorization ........ 14 5.1.1. Authentication and Authorization of Masters ....... 15 5.1.2. Recursive Authentication and Authorization of Masters - (Chain of Trust) ......................................... 15 - 5.1.3. Authentication and Authorization of Slaves ........ 16 + (Chain of Trust) ......................................... 16 + 5.1.3. Authentication and Authorization of Slaves ........ 17 5.1.4. PTP: Authentication and Authorization of P2P TCs by the Master ................................................... 17 5.1.5. PTP: Authentication and Authorization of Control Messages ................................................. 18 5.2. Protocol Packet Integrity .............................. 19 - 5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 19 - 5.2.1.1. Hop-by-Hop Integrity Protection .............. 19 + 5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 20 + 5.2.1.1. Hop-by-Hop Integrity Protection .............. 20 5.2.1.2. End-to-End Integrity Protection .............. 20 - 5.3. Spoofing Prevention .................................... 20 - 5.4. Availability ........................................... 21 + 5.3. Spoofing Prevention .................................... 21 + 5.4. Availability ........................................... 22 5.5. Replay Protection ...................................... 22 - 5.6. Cryptographic Keys and Security Associations ........... 22 - 5.6.1. Key Freshness ..................................... 22 + 5.6. Cryptographic Keys and Security Associations ........... 23 + 5.6.1. Key Freshness ..................................... 23 5.6.2. Security Association .............................. 23 5.6.3. Unicast and Multicast Associations ................ 24 - 5.7. Performance ............................................ 24 - 5.8. Confidentiality......................................... 25 + 5.7. Performance ............................................ 25 + 5.8. Confidentiality......................................... 26 5.9. Protection against Packet Delay and Interception Attacks 26 5.10. Combining Secured with Unsecured Nodes ................ 27 5.10.1. Secure Mode ...................................... 27 - 5.10.2. Hybrid Mode ...................................... 27 - 6. Summary of Requirements ..................................... 28 + 5.10.2. Hybrid Mode ...................................... 28 + 6. Summary of Requirements ..................................... 29 7. Additional security implications ............................ 30 - 7.1. Security and on-the-fly Timestamping ................... 30 - 7.2. PTP: Security and Two-Step Timestamping ................ 30 + 7.1. Security and on-the-fly Timestamping ................... 31 + 7.2. PTP: Security and Two-Step Timestamping ................ 31 7.3. Intermediate Clocks .................................... 31 7.4. External Security Protocols and Time Protocols.......... 32 - 7.5. External Security Services Requiring Time .............. 32 - 7.5.1. Timestamped Certificates .......................... 32 + 7.5. External Security Services Requiring Time .............. 33 + 7.5.1. Timestamped Certificates .......................... 33 7.5.2. Time Changes and Replay Attacks ................... 33 8. Issues for Further Discussion ............................... 33 - 9. Security Considerations ..................................... 33 - 10. IANA Considerations......................................... 33 - 11. Acknowledgments ............................................ 33 - 12. References ................................................. 33 - 12.1. Normative References .................................. 33 + 9. Security Considerations ..................................... 34 + 10. IANA Considerations......................................... 34 + 11. Acknowledgments ............................................ 34 + 12. References ................................................. 34 + 12.1. Normative References .................................. 34 12.2. Informative References ................................ 34 - 13. Contributing Authors ....................................... 35 + 13. Contributing Authors ....................................... 36 1. Introduction As time protocols are becoming increasingly common and widely deployed, concern about the resulting exposure to various security threats is increasing. If a time protocol is compromised, the applications it serves are prone to a range of possible attacks including Denial-of-Service (DoS) or incorrect behavior. This document discusses the security aspects of time distribution @@ -244,22 +246,27 @@ o Clock - A node participating in the protocol (either PTP or NTP). A clock can be a master, a slave, or an intermediate clock (see corresponding definitions below). o Control packets - Packets used by the protocol to exchange information between clocks that is not strictly related to the time. NTP uses NTP Control Messages. PTP uses Announce, Signaling and Management messages. o End-to-end security - A security approach where secured packets - sent from a source to a destination is not modified by - intermediate nodes. + sent from a source to a destination are not modified by + intermediate nodes, allowing the destination to authenticate the + source of the packets, and to verify their integrity. + In the context of confidentiality, end-to-end encryption + guarantees that intermediate nodes cannot eavesdrop to en-route + packets. However, as discussed in Section 5. , confidentiality is + not a strict requirement in this document. o Grandmaster - A master that receives time information from a locally attached clock device, and not through the network. A grandmaster distributes its time to other clocks in the network. o Hop-by-hop security - A security approach where secured packets sent from a source to a destination may be modified by intermediate nodes. In this approach intermediate nodes share the encryption key with the source and destination, allowing them to re-encrypt or re-authenticate modified packets before relaying @@ -291,22 +298,22 @@ o Unsecured clock - A clock that does not support a security mechanism according to the requirements in this document. 3. Security Threats This section discusses the possible attacker types and analyzes various attacks against time protocols. The literature is rich with security threats of time protocols, e.g., - [Traps], [AutoKey], [TM], [SecPTP], and [SecSen]. The threat analysis - in this document is mostly based on [TM]. + [Traps], [AutoKey], [TimeSec], [SecPTP], and [SecSen]. The threat + analysis in this document is mostly based on [TimeSec]. 3.1. Threat Model A time protocol can be attacked by various types of attackers. The analysis in this document classifies attackers according to 2 criteria, as described in Section 3.1.1. and Section 3.1.2. 3.1.1. Internal vs. External Attackers @@ -458,20 +465,44 @@ grandmaster. For example, if the grandmaster uses a GPS based clock as its reference source, an attacker can jam the reception of the GPS signal, or transmit a signal similar to one from a GPS satellite, causing the grandmaster to use a false reference time. Note that this attack is outside the scope of the time protocol. While various security measures can be taken to mitigate this attack, these measures are outside the scope of the security requirements defined in this document. +3.2.11. Exploiting Vulnerabilities in the Time Protocol + + Time protocols can be attacked by exploiting vulnerabilities in the + protocol, implementation bugs, or misconfigurations (e.g., + [NTPDDoS]). It should be noted that such attacks cannot typically be + mitigated by security mechanisms. However, when a new vulnerability + is discovered, operators should react as soon as possible, and take + the necessary measures to address it. + +3.2.12. Network Reconnaissance + + An attacker can exploit the time protocol to collect information such + as addresses and locations of nodes that take part in the protocol. + Reconnaissance can be applied either by passively eavesdropping to + protocol packets, or by sending malicious packets and gathering + information from the responses. By eavesdropping to a time protocol, + an attacker can learn the network latencies, which provide + information about the network topology and node locations. + + Moreover, properties such as the frequency of the protocol packets, + or the exact times at which they are sent can allow fingerprinting of + specific nodes; thus, protocol packets from a node can be identified + even if network addresses are hidden or encrypted. + 3.3. Threat Analysis Summary The two key factors to a threat analysis are the impact and the likelihood of each of the analyzed attacks. Table 1 summarizes the security attacks presented in Section 3.2. For each attack, the table specifies its impact, and its applicability to each of the attacker types presented in Section 3.1. Table 1 clearly shows the distinction between external and internal @@ -989,23 +1019,27 @@ and availability of the protocol. Common encryption and authentication mechanisms include replay prevention mechanisms that typically use a monotonously increasing packet sequence number. 5.6. Cryptographic Keys and Security Associations 5.6.1. Key Freshness Requirement + The security mechanism MUST provide a means to refresh the + cryptographic keys. + The cryptographic keys MUST be refreshed frequently. Requirement Level + The requirement level of this requirement is 'MUST' since key freshness is an essential property for cryptographic algorithms, as discussed below. Discussion Key freshness guarantees that both sides share a common updated secret key. It also helps in preventing replay attacks. Thus, it is important for keys to be refreshed frequently. Note that the term 'frequently' is used without a quantitative requirement, as the @@ -1111,22 +1143,23 @@ 5.8. Confidentiality Requirement The security mechanism MAY provide confidentiality protection of the protocol packets. Requirement Level - The requirement level of this requirement is 'MAY' since it does not - prevent severe threats, as discussed below. + The requirement level of this requirement is 'MAY' since the absence + of this requirement does not expose the protocol to severe threats, + as discussed below. Discussion In the context of time protocols, confidentiality is typically of low importance, since timing information is typically not considered secret information. Confidentiality can play an important role when service providers charge their customers for time synchronization services, and thus an encryption mechanism can prevent eavesdroppers from obtaining the @@ -1437,21 +1470,23 @@ Cryptographic protocols often use time as an important factor in the cryptographic algorithm. If a time protocol is compromised, it may consequently expose the security protocols that rely on it to various attacks. Two examples are presented in this section. 7.5.1. Timestamped Certificates Certificate validation requires the sender and receiver to be roughly time synchronized. Thus, synchronization is required for establishing - security protocols such as IKEv2 and TLS. + security protocols such as IKEv2 and TLS. Other authentication and + key exchange mechanisms, such as Kerberos, also require the parties + involved to be synchronized [Kerb]. An even stronger interdependence between a time protocol and a security mechanism is defined in [AutoKey], which defines mutual dependence between the acquired time information, and the authentication protocol that secures it. This bootstrapping behavior results from the fact that trusting the received time information requires a valid certificate, and validating a certificate requires knowledge of the time. 7.5.2. Time Changes and Replay Attacks @@ -1473,33 +1508,43 @@ throughout this document. 10. IANA Considerations There are no new IANA considerations implied by this document. 11. Acknowledgments The authors gratefully acknowledge Stefano Ruffini, Doug Arnold, Kevin Gross, Dieter Sibold, Dan Grossman, Laurent Montini, Russell - Smiley, and Shawn Emery for their thorough review and helpful + Smiley, Shawn Emery, Dan Romascanu, Stephen Farrell, Kathleen + Moriarty, and Joel Jaeggli for their thorough review and helpful comments. The authors would also like to thank members of the TICTOC WG for providing feedback on the TICTOC mailing list. This document was prepared using 2-Word-v2.0.template.dot. 12. References 12.1. Normative References + [IEEE1588] IEEE TC 9 Instrumentation and Measurement Society, + "1588 IEEE Standard for a Precision Clock + Synchronization Protocol for Networked Measurement and + Control Systems Version 2", IEEE Standard, 2008. + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. + [NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W., + "Network Time Protocol Version 4: Protocol and + Algorithms Specification", RFC 5905, June 2010. + 12.2. Informative References [1588IPsec] A. Treytl, B. Hirschler, "Securing IEEE 1588 by IPsec tunnels - An analysis", in Proceedings of 2010 International Symposium for Precision Clock Synchronization for Measurement, Control and Communication, ISPCS 2010, pp. 83-90, 2010. [3GPP] 3GPP, "Security of Home Node B (HNB) / Home evolved Node B (HeNB)", 3GPP TS 33.320 10.4.0 (work in @@ -1519,51 +1564,49 @@ Attacks against Time Synchronization Protocols", accepted, to appear in Proceedings of the International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication, ISPCS, 2012. [Hack] S. McClure, J. Scambray, G. Kurtz, Kurtz, "Hacking exposed: network security secrets and solutions", McGraw-Hill, 2009. - [IEEE1588] IEEE TC 9 Instrumentation and Measurement Society, - "1588 IEEE Standard for a Precision Clock - Synchronization Protocol for Networked Measurement and - Control Systems Version 2", IEEE Standard, 2008. - [IPsec] S. Kent, K. Seo, "Security Architecture for the Internet Protocol", IETF, RFC 4301, 2005. [IPsecSync] Y. Xu, "IPsec security for packet based synchronization", IETF, draft-xu-tictoc-ipsec- security-for-synchronization (work in progress), 2011. + [Kerb] S. Sakane, K. Kamada, M. Thomas, J. Vilhuber, + "Kerberized Internet Negotiation of Keys (KINK)", + 2006. + [MACsec] IEEE 802.1AE-2006, "IEEE Standard for Local and Metropolitan Area Networks - Media Access Control (MAC) Security", 2006. - [NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W., - "Network Time Protocol Version 4: Protocol and - Algorithms Specification", RFC 5905, June 2010. + [NTPDDoS] "Attackers use NTP reflection in huge DDoS attack", + TICTOC mail archive, 2014. [SecPTP] J. Tsang, K. Beznosov, "A security analysis of the precise time protocol (short paper)," 8th International Conference on Information and Communication Security (ICICS 2006), pp. 50-59, 2006. [SecSen] S. Ganeriwal, C. Popper, S. Capkun, M. B. Srivastava, "Secure Time Synchronization in Sensor Networks", ACM Trans. Info. and Sys. Sec., Volume 11, Issue 4, July 2008. - [TM] T. Mizrahi, "Time synchronization security using IPsec + [TimeSec] T. Mizrahi, "Time synchronization security using IPsec and MACsec", ISPCS 2011, pp. 38-43, 2011. [Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R., "Traps and pitfalls in secure clock synchronization" in Proceedings of 2007 International Symposium for Precision Clock Synchronization for Measurement, Control and Communication, ISPCS 2007, pp. 18-24, 2007. [Tunnel] A. Treytl, B. Hirschler, and T. Sauter, "Secure