From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7384.txt | 2019 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2019 insertions(+) create mode 100644 doc/rfc/rfc7384.txt (limited to 'doc/rfc/rfc7384.txt') diff --git a/doc/rfc/rfc7384.txt b/doc/rfc/rfc7384.txt new file mode 100644 index 0000000..742db1f --- /dev/null +++ b/doc/rfc/rfc7384.txt @@ -0,0 +1,2019 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Mizrahi +Request for Comments: 7384 Marvell +Category: Informational October 2014 +ISSN: 2070-1721 + + + Security Requirements of Time Protocols + in Packet Switched Networks + +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 + practices on time protocols, and the dependencies between other + security services and time synchronization. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7384. + + + + + + + + + + + + + + + +Mizrahi Informational [Page 1] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +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 + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................4 + 2. Terminology .....................................................5 + 2.1. Requirements Language ......................................5 + 2.2. Abbreviations ..............................................6 + 2.3. Common Terminology for PTP and NTP .........................6 + 2.4. Terms Used in This Document ................................6 + 3. Security Threats ................................................7 + 3.1. Threat Model ...............................................8 + 3.1.1. Internal vs. External Attackers .....................8 + 3.1.2. Man in the Middle (MITM) vs. Packet Injector ........8 + 3.2. Threat Analysis ............................................9 + 3.2.1. Packet Manipulation .................................9 + 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 ..............11 + 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 ...................................12 + 4. Requirement Levels .............................................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) ........................16 + 5.1.3. Authentication and Authorization of Slaves .........17 + + + +Mizrahi Informational [Page 2] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + 5.1.4. PTP: Authentication and Authorization of + P2P TCs by the Master ..............................18 + 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 .........................................20 + 5.2.1.1. Hop-by-Hop Integrity Protection ...........20 + 5.2.1.2. End-to-End Integrity Protection ...........21 + 5.3. Spoofing Prevention .......................................21 + 5.4. Availability ..............................................22 + 5.5. Replay Protection .........................................23 + 5.6. Cryptographic Keys and Security Associations ..............23 + 5.6.1. Key Freshness ......................................23 + 5.6.2. Security Association ...............................24 + 5.6.3. Unicast and Multicast Associations .................24 + 5.7. Performance ...............................................25 + 5.8. Confidentiality ...........................................26 + 5.9. Protection against Packet Delay and Interception Attacks ..27 + 5.10. Combining Secured with Unsecured Nodes ...................27 + 5.10.1. Secure Mode .......................................28 + 5.10.2. Hybrid Mode .......................................28 + 6. Summary of Requirements ........................................29 + 7. Additional Security Implications ...............................31 + 7.1. Security and On-the-Fly Timestamping ......................31 + 7.2. PTP: Security and Two-Step Timestamping ...................31 + 7.3. Intermediate Clocks .......................................32 + 7.4. External Security Protocols and Time Protocols ............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 ..................................34 + 9. Security Considerations ........................................34 + 10. References ....................................................34 + 10.1. Normative References .....................................34 + 10.2. Informative References ...................................34 + Acknowledgments ...................................................36 + Contributors ......................................................36 + Author's Address ..................................................36 + + + + + + + + + + + + +Mizrahi Informational [Page 3] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +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 + protocols in packet networks and focuses on the two most common + protocols: the Network Time Protocol [NTPv4] and the Precision Time + Protocol (PTP) [IEEE1588]. Note that although PTP was not defined by + the IETF, it is one of the two most common time protocols; hence, it + is included in the discussion. + + The Network Time Protocol was defined with an inherent security + protocol; [NTPv4] defines a security protocol that is based on a + symmetric key authentication scheme, and [AutoKey] presents an + alternative security protocol, based on a public key authentication + scheme. [IEEE1588] includes an experimental security protocol, + defined in Annex K of the standard, but this Annex was never + formalized into a fully defined security protocol. + + While NTP includes an inherent security protocol, the absence of a + standard security solution for PTP undoubtedly contributed to the + wide deployment of unsecured time synchronization solutions. + However, in some cases, security mechanisms may not be strictly + necessary, e.g., due to other security practices in place or due to + the architecture of the network. A time synchronization security + solution, much like any security solution, is comprised of various + building blocks and must be carefully tailored for the specific + system in which it is deployed. Based on a system-specific threat + assessment, the benefits of a security solution must be weighed + against the potential risks, and based on this trade-off an optimal + security solution can be selected. + + The target audience of this document includes: + + o Timing and networking equipment vendors - can benefit from this + document by deriving the security features that should be + supported in the time/networking equipment. + + o Standards development organizations - can use the requirements + defined in this document when specifying security mechanisms for a + time protocol. + + + + + + +Mizrahi Informational [Page 4] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + o Network operators - can use this document as a reference when + designing a network and its security architecture. As stated + above, the requirements in this document may be deployed + selectively based on a careful per-system threat analysis. + + This document attempts to add clarity to the time protocol security + requirements discussion by addressing a series of questions: + + (1) What are the threats that need to be addressed for the time + protocol and what security services need to be provided (e.g., a + malicious NTP server or PTP master)? + + (2) What external security practices impact the security and + performance of time keeping and what can be done to mitigate + these impacts (e.g., an IPsec tunnel in the time protocol traffic + path)? + + (3) What are the security impacts of time protocol practices (e.g., + on-the-fly modification of timestamps)? + + (4) What are the dependencies between other security services and + time protocols? (For example, which comes first - the + certificate or the timestamp?) + + In light of the questions above, this document defines a set of + requirements for security solutions for time protocols, focusing on + PTP and NTP. + +2. Terminology + +2.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [KEYWORDS]. + + This document describes security requirements; thus, requirements are + phrased in the document in the form "the security mechanism + MUST/SHOULD/...". Note that the phrasing does not imply that this + document defines a specific security mechanism, but that it defines + the requirements with which every security mechanism should comply. + + + + + + + + + + +Mizrahi Informational [Page 5] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +2.2. Abbreviations + + BC Boundary Clock [IEEE1588] + + BMCA Best Master Clock Algorithm [IEEE1588] + + DoS Denial of Service + + MITM Man in the Middle + + NTP Network Time Protocol [NTPv4] + + OC Ordinary Clock [IEEE1588] + + P2P TC Peer-to-Peer Transparent Clock [IEEE1588] + + PTP Precision Time Protocol [IEEE1588] + + TC Transparent Clock [IEEE1588] + +2.3. Common Terminology for PTP and NTP + + This document refers to both PTP and NTP. For the sake of + consistency, throughout the document the term "master" applies to + both a PTP master and an NTP server. Similarly, the term "slave" + applies to both PTP slaves and NTP clients. The term "protocol + packets" refers generically to PTP and NTP messages. + +2.4. Terms Used in This Document + + 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 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. + + + + +Mizrahi Informational [Page 6] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + 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 + them to the destination. + + o Intermediate clock - A clock that receives timing information from + a master and sends timing information to other clocks. In NTP, + this term refers to an NTP server that is not a Stratum 1 server. + In PTP, this term refers to a BC or a TC. + + o Master - A clock that generates timing information to other clocks + in the network. In NTP, 'master' refers to an NTP server. In + PTP, 'master' refers to a master OC (aka grandmaster) or to a port + of a BC that is in the master state. + + o Protocol packets - Packets used by the time protocol. The + terminology used in this document distinguishes between time + packets and control packets. + + o Secured clock - A clock that supports a security mechanism that + complies to the requirements in this document. + + o Slave - A clock that receives timing information from a master. + In NTP, 'slave' refers to an NTP client. In PTP, 'slave' refers + to a slave OC or to a port of a BC that is in the slave state. + + o Time packets - Protocol packets carrying time information. + + 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], [TimeSec], [SecPTP], and [SecSen]. The threat + analysis in this document is mostly based on [TimeSec]. + + + + + + +Mizrahi Informational [Page 7] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +3.1. Threat Model + + A time protocol can be attacked by various types of attackers. + + The analysis in this document classifies attackers according to two + criteria, as described in Sections 3.1.1 and 3.1.2. + +3.1.1. Internal vs. External Attackers + + In the context of internal and external attackers, the underlying + assumption is that the time protocol is secured by either an + encryption mechanism, an authentication mechanism, or both. + + Internal attackers either have access to a trusted segment of the + network or possess the encryption or authentication keys. An + internal attack can also be performed by exploiting vulnerabilities + in devices; for example, by installing malware or obtaining + credentials to reconfigure the device. Thus, an internal attacker + can maliciously tamper with legitimate traffic in the network as well + as generate its own traffic and make it appear legitimate to its + attacked nodes. + + Note that internal attacks are a special case of Byzantine failures, + where a node in the system may fail in arbitrary ways; by crashing, + by omitting messages, or by malicious behavior. This document + focuses on nodes that demonstrate malicious behavior. + + External attackers, on the other hand, do not have the keys and have + access only to the encrypted or authenticated traffic. + + Obviously, in the absence of a security mechanism, there is no + distinction between internal and external attackers, since all + attackers are internal in practice. + +3.1.2. Man in the Middle (MITM) vs. Packet Injector + + MITM attackers are located in a position that allows interception and + modification of in-flight protocol packets. It is assumed that an + MITM attacker has physical access to a segment of the network or has + gained control of one of the nodes in the network. + + A traffic injector is not located in an MITM position, but can attack + by generating protocol packets. An injector can reside either within + the attacked network or on an external network that is connected to + the attacked network. An injector can also potentially eavesdrop on + protocol packets sent as multicast, record them, and replay them + later. + + + + +Mizrahi Informational [Page 8] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +3.2. Threat Analysis + +3.2.1. Packet Manipulation + + A packet manipulation attack results when an MITM attacker receives + timing protocol packets, alters them, and relays them to their + destination, allowing the attacker to maliciously tamper with the + protocol. This can result in a situation where the time protocol is + apparently operational but providing intentionally inaccurate + information. + +3.2.2. Spoofing + + In spoofing, an injector masquerades as a legitimate node in the + network by generating and transmitting protocol packets or control + packets. Two typical examples of spoofing attacks: + + o An attacker can impersonate the master, allowing malicious + distribution of false timing information. + + o An attacker can impersonate a legitimate clock, a slave, or an + intermediate clock, by sending malicious messages to the master, + causing the master to respond to the legitimate clock with + protocol packets that are based on the spoofed messages. + Consequently, the delay computations of the legitimate clock are + based on false information. + + As with packet manipulation, this attack can result in a situation + where the time protocol is apparently operational but providing + intentionally inaccurate information. + +3.2.3. Replay Attack + + In a replay attack, an attacker records protocol packets and replays + them at a later time without any modification. This can also result + in a situation where the time protocol is apparently operational but + providing intentionally inaccurate information. + +3.2.4. Rogue Master Attack + + In a rogue master attack, an attacker causes other nodes in the + network to believe it is a legitimate master. As opposed to the + spoofing attack, in the rogue master attack the attacker does not + fake its identity, but rather manipulates the master election process + using malicious control packets. For example, in PTP, an attacker + can manipulate the Best Master Clock Algorithm (BMCA) and cause other + nodes in the network to believe it is the most eligible candidate to + be a grandmaster. + + + +Mizrahi Informational [Page 9] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + In PTP, a possible variant of this attack is the rogue TC/BC attack. + Similar to the rogue master attack, an attacker can cause victims to + believe it is a legitimate TC or BC, allowing the attacker to + manipulate the time information forwarded to the victims. + +3.2.5. Packet Interception and Removal + + A packet interception and removal attack results when an MITM + attacker intercepts and drops protocol packets, preventing the + destination node from receiving some or all of the protocol packets. + +3.2.6. Packet Delay Manipulation + + In a packet delay manipulation scenario, an MITM attacker receives + protocol packets and relays them to their destination after adding a + maliciously computed delay. The attacker can use various delay + attack strategies; the added delay can be constant, jittered, or + slowly wandering. Each of these strategies has a different impact, + but they all effectively manipulate the attacked clock. + + Note that the victim still receives one copy of each packet, contrary + to the replay attack, where some or all of the packets may be + received by the victim more than once. + +3.2.7. L2/L3 DoS Attacks + + There are many possible Layer 2 and Layer 3 DoS attacks, e.g., IP + spoofing, ARP spoofing [Hack], MAC flooding [Anatomy], and many + others. As the target's availability is compromised, the timing + protocol is affected accordingly. + +3.2.8. Cryptographic Performance Attacks + + In cryptographic performance attacks, an attacker transmits fake + protocol packets, causing high utilization of the cryptographic + engine at the receiver, which attempts to verify the integrity of + these fake packets. + + This DoS attack is applicable to all encryption and authentication + protocols. However, when the time protocol uses a dedicated security + mechanism implemented in a dedicated cryptographic engine, this + attack can be applied to cause DoS specifically to the time protocol. + + + + + + + + + +Mizrahi Informational [Page 10] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +3.2.9. DoS Attacks against the Time Protocol + + An attacker can attack a clock by sending an excessive number of time + protocol packets, thus degrading the victim's performance. This + attack can be implemented, for example, using the attacks described + in Sections 3.2.2 and 3.2.4. + +3.2.10. Grandmaster Time Source Attack (e.g., GPS Fraud) + + Grandmasters receive their time from an external accurate time + source, such as an atomic clock or a GPS clock, and then distribute + this time to the slaves using the time protocol. + + Time source attacks are aimed at the accurate time source of the + 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 by either passively eavesdropping on + protocol packets or sending malicious packets and gathering + information from the responses. By eavesdropping on 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. + + + + +Mizrahi Informational [Page 11] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +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 + attackers, and motivates the usage of authentication and integrity + protection, significantly reducing the impact of external attackers. + + The Impact column provides an intuitive measure of the severity of + each attack, and the relevant Attacker Type column provides an + intuition about how difficult each attack is to implement and, hence, + about the likelihood of each attack. + + The Impact column in Table 1 can have one of three values: + + o DoS - the attack causes denial of service to the attacked node, + the impact of which is not restricted to the time protocol. + + o Accuracy degradation - the attack yields a degradation in the + slave accuracy, but does not completely compromise the slaves' + time and frequency. + + o False time - slaves align to a false time or frequency value due + to the attack. Note that if the time protocol aligns to a false + time, it may cause DoS to other applications that rely on accurate + time. However, for the purpose of the analysis in this section, + we distinguish this implication from 'DoS', which refers to a DoS + attack that is not necessarily aimed at the time protocol. All + attacks that have a '+' for 'False Time' implicitly have a '+' for + 'Accuracy Degradation'. Note that 'False Time' necessarily + implies 'Accuracy Degradation'. However, two different terms are + used, indicating two levels of severity. + + The Attacker Type column refers to the four possible combinations of + the attacker types defined in Section 3.1. + + + + + + + + + + + +Mizrahi Informational [Page 12] + +RFC 7384 Time Protocol Security Requirements October 2014 + + ++-----------------------------+-------------------++-------------------+ +| Attack | Impact || Attacker Type | +| +-----+--------+----++---------+---------+ +| |False|Accuracy| ||Internal |External | +| |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.| ++-----------------------------+-----+--------+----++----+----+----+----+ +|Manipulation | + | | || + | | | | ++-----------------------------+-----+--------+----++----+----+----+----+ +|Spoofing | + | | || + | + | | | ++-----------------------------+-----+--------+----++----+----+----+----+ +|Replay attack | + | | || + | + | | | ++-----------------------------+-----+--------+----++----+----+----+----+ +|Rogue master attack | + | | || + | + | | | ++-----------------------------+-----+--------+----++----+----+----+----+ +|Interception and removal | | + | + || + | | + | | ++-----------------------------+-----+--------+----++----+----+----+----+ +|Packet delay manipulation | + | | || + | | + | | ++-----------------------------+-----+--------+----++----+----+----+----+ +|L2/L3 DoS attacks | | | + || + | + | + | + | ++-----------------------------+-----+--------+----++----+----+----+----+ +|Crypt. performance attacks | | | + || + | + | + | + | ++-----------------------------+-----+--------+----++----+----+----+----+ +|Time protocol DoS attacks | | | + || + | + | | | ++-----------------------------+-----+--------+----++----+----+----+----+ +|Master time source attack | + | | || + | + | + | + | +|(e.g., GPS spoofing) | | | || | | | | ++-----------------------------+-----+--------+----++----+----+----+----+ + + Table 1: Threat Analysis - Summary + + The threats discussed in this section provide the background for the + security requirements presented in Section 5. + +4. Requirement Levels + + The security requirements are presented in Section 5. Each + requirement is defined with a requirement level, in accordance with + the requirement levels defined in Section 2.1. + + The requirement levels in this document are affected by the following + factors: + + o Impact: + The possible impact of not implementing the requirement, as + illustrated in the Impact column of Table 1. For example, a + requirement that addresses a threat that can be implemented by an + external injector is typically a 'MUST', since the threat can be + implemented by all the attacker types analyzed in Section 3.1. + + + +Mizrahi Informational [Page 13] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + o Difficulty of the corresponding attack: + The level of difficulty of the possible attacks that become + possible by not implementing the requirement. The level of + difficulty is reflected in the Attacker Type column of Table 1. + For example, a requirement that addresses a threat that only + compromises the availability of the protocol is typically no more + than a 'SHOULD'. + + o Practical considerations: + Various practical factors that may affect the requirement. For + example, if a requirement is very difficult to implement, or is + applicable to very specific scenarios, these factors may reduce + the requirement level. + + Section 5 lists the requirements. For each requirement, there is a + short explanation detailing the reason for its requirement level. + +5. Security Requirements + + This section defines a set of security requirements. These + requirements are phrased in the form "the security mechanism + MUST/SHOULD/MAY...". However, this document does not specify how + these requirements can be met. While these requirements can be + satisfied by defining explicit security mechanisms for time + protocols, at least a subset of the requirements can be met by + applying common security practices to the network or by using + existing security protocols, such as [IPsec] or [MACsec]. Thus, + security solutions that address these requirements are outside the + scope of this document. + +5.1. Clock Identity Authentication and Authorization + + Requirement + + The security mechanism MUST support authentication. + + Requirement + + The security mechanism MUST support authorization. + + Requirement Level + + The requirements in this subsection address the spoofing attack + (Section 3.2.2) and the rogue master attack (Section 3.2.4). + + The requirement level of these requirements is 'MUST' since, in + the absence of these requirements, the protocol is exposed to + attacks that are easy to implement and have a high impact. + + + +Mizrahi Informational [Page 14] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + Discussion + + Authentication refers to verifying the identity of the peer clock. + Authorization, on the other hand, refers to verifying that the + peer clock is permitted to play the role that it plays in the + protocol. For example, some nodes may be permitted to be masters, + while other nodes are only permitted to be slaves or TCs. + + Authentication is typically implemented by means of a + cryptographic signature, allowing the verification of the identity + of the sender. Authorization requires clocks to maintain a list + of authorized clocks, or a "black list" of clocks that should be + denied service or revoked. + + It is noted that while the security mechanism is required to + provide an authorization mechanism, the deployment of such a + mechanism depends on the nature of the network. For example, a + network that deploys PTP may consist of a set of identical OCs, + where all clocks are equally permitted to be a master. In such a + network, an authorization mechanism may not be necessary. + + The following subsections describe five distinct cases of clock + authentication. + +5.1.1. Authentication and Authorization of Masters + + Requirement + + The security mechanism MUST support an authentication mechanism, + allowing slaves to authenticate the identity of masters. + + Requirement + + The authentication mechanism MUST allow slaves to verify that the + authenticated master is authorized to be a master. + + Requirement Level + + The requirements in this subsection address the spoofing attack + (Section 3.2.2) and the rogue master attack (Section 3.2.4). + + The requirement level of these requirements is 'MUST' since, in + the absence of these requirements, the protocol is exposed to + attacks that are easy to implement and have a high impact. + + + + + + + +Mizrahi Informational [Page 15] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + Discussion + + Clocks authenticate masters in order to ensure the authenticity of + the time source. It is important for a slave to verify the + identity of the master, as well as to verify that the master is + indeed authorized to be a master. + +5.1.2. Recursive Authentication and Authorization of Masters (Chain of + Trust) + + Requirement + + The security mechanism MUST support recursive authentication and + authorization of the master, to be used in cases where time + information is conveyed through intermediate clocks. + + Requirement Level + + The requirement in this subsection addresses the spoofing attack + (Section 3.2.2) and the rogue master attack (Section 3.2.4). + + The requirement level of this requirement is 'MUST' since, in the + absence of this requirement, the protocol is exposed to attacks + that are easy to implement and have a high impact. + + Discussion + + In some cases, a slave is connected to an intermediate clock that + is not the primary time source. For example, in PTP, a slave can + be connected to a Boundary Clock (BC) or a Transparent Clock (TC), + which in turn is connected to a grandmaster. A similar example in + NTP is when a client is connected to a Stratum 2 server, which is + connected to a Stratum 1 server. In both the PTP and the NTP + cases, the slave authenticates the intermediate clock, and the + intermediate clock authenticates the grandmaster. This recursive + authentication process is referred to in [AutoKey] as + proventication. + + Specifically in PTP, this requirement implies that if a slave + receives time information through a TC, it must authenticate the + TC to which it is attached, as well as authenticate the master + from which it receives the time information, as per Section 5.1.1. + Similarly, if a TC receives time information through an attached + TC, it must authenticate the attached TC. + + + + + + + +Mizrahi Informational [Page 16] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +5.1.3. Authentication and Authorization of Slaves + + Requirement + + The security mechanism MAY provide a means for a master to + authenticate its slaves. + + Requirement + + The security mechanism MAY provide a means for a master to verify + that the sender of a protocol packet is authorized to send a + packet of this type. + + Requirement Level + + The requirement in this subsection prevents DoS attacks against + the master (Section 3.2.9). + + The requirement level of this requirement is 'MAY' since: + + o Its impact is low, i.e., in the absence of this requirement the + protocol is only exposed to DoS. + + o Practical considerations: requiring an NTP server to + authenticate its clients may significantly impose on the + server's performance. + + Note that while the requirement level of this requirement is + 'MAY', the requirement in Section 5.1.1 is 'MUST'; the security + mechanism must provide a means for authentication and + authorization, with an emphasis on the master. Authentication and + authorization of slaves are specified in this subsection as 'MAY'. + + Discussion + + Slaves and intermediate clocks are authenticated by masters in + order to verify that they are authorized to receive timing + services from the master. + + Authentication of slaves prevents unauthorized clocks from + receiving time services. Preventing the master from serving + unauthorized clocks can help in mitigating DoS attacks against the + master. Note that the authentication of slaves might put a higher + load on the master than serving the unauthorized clock; hence, + this requirement is 'MAY'. + + + + + + +Mizrahi Informational [Page 17] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +5.1.4. PTP: Authentication and Authorization of P2P TCs by the Master + + Requirement + + The security mechanism for PTP MAY provide a means for a master to + authenticate the identity of the P2P TCs directly connected to it. + + Requirement + + The security mechanism for PTP MAY provide a means for a master to + verify that P2P TCs directly connected to it are authorized to be + TCs. + + Requirement Level + + The requirement in this subsection prevents DoS attacks against + the master (Section 3.2.9). + + The requirement level of this requirement is 'MAY' for the same + reasons specified in Section 5.1.3. + + Discussion + + P2P TCs that are one hop from the master use the PDelay_Req and + PDelay_Resp handshake to compute the link delay between the master + and TC. These TCs are authenticated by the master. + + Authentication of TCs, much like authentication of slaves, reduces + unnecessary load on the master and peer TCs, by preventing the + master from serving unauthorized clocks. + +5.1.5. PTP: Authentication and Authorization of Control Messages + + Requirement + + The security mechanism for PTP MUST support authentication of + Announce messages. The authentication mechanism MUST also verify + that the sender is authorized to be a master. + + Requirement + + The security mechanism for PTP MUST support authentication and + authorization of Management messages. + + Requirement + + The security mechanism MAY support authentication and + authorization of Signaling messages. + + + +Mizrahi Informational [Page 18] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + Requirement Level + + The requirements in this subsection address the spoofing attack + (Section 3.2.2) and the rogue master attack (Section 3.2.4). + + The requirement level of the first two requirements is 'MUST' + since, in the absence of these requirements, the protocol is + exposed to attacks that are easy to implement and have a high + impact. + + The requirement level of the third requirement is 'MAY' since its + impact greatly depends on the application for which the Signaling + messages are used. + + Discussion + + Master election is performed in PTP using the Best Master Clock + Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock + attributes using Announce messages, and the best master is elected + based on the information gathered from all the candidates. + Announce messages must be authenticated in order to prevent rogue + master attacks (Section 3.2.4). Note that this subsection + specifies a requirement that is not necessarily included in + Sections 5.1.1 or 5.1.3, since the BMCA is initiated before clocks + have been defined as masters or slaves. + + Management messages are used to monitor or configure PTP clocks. + Malicious usage of Management messages enables various attacks, + such as the rogue master attack or DoS attack. + + Signaling messages are used by PTP clocks to exchange information + that is not strictly related to time information or to master + selection, such as unicast negotiation. Authentication and + authorization of Signaling messages may be required in some + systems, depending on the application for which these messages are + used. + +5.2. Protocol Packet Integrity + + Requirement + + The security mechanism MUST protect the integrity of protocol + packets. + + + + + + + + +Mizrahi Informational [Page 19] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + Requirement Level + + The requirement in this subsection addresses the packet + manipulation attack (Section 3.2.1). + + The requirement level of this requirement is 'MUST' since, in the + absence of this requirement, the protocol is exposed to attacks + that are easy to implement and have high impact. + + Discussion + + While Section 5.1 refers to ensuring the identity an authorization + of the source of a protocol packet, this subsection refers to + ensuring that the packet arrived intact. The integrity protection + mechanism ensures the authenticity and completeness of data from + the data originator. + + Integrity protection is typically implemented by means of an + Integrity Check Value (ICV) that is included in protocol packets + and is verified by the receiver. + +5.2.1. PTP: Hop-by-Hop vs. End-to-End Integrity Protection + + Specifically in PTP, when protocol packets are subject to + modification by TCs, the integrity protection can be enforced in one + of two approaches: end-to-end or hop-by-hop. + +5.2.1.1. Hop-by-Hop Integrity Protection + + Each hop that needs to modify a protocol packet: + + o Verifies its integrity. + + o Modifies the packet, i.e., modifies the correctionField. Note: + TCs improve the end-to-end accuracy by updating a correctionField + (Clause 6.5 in [IEEE1588]) in the PTP packet by adding the latency + caused by the current TC. + + o Re-generates the integrity protection, e.g., re-computes a Message + Authentication Code (MAC). + + In the hop-by-hop approach, the integrity of protocol packets is + protected by induction on the path from the originator to the + receiver. + + This approach is simple, but allows rogue TCs to modify protocol + packets. + + + + +Mizrahi Informational [Page 20] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +5.2.1.2. End-to-End Integrity Protection + + In this approach, the integrity protection is maintained on the path + from the originator of a protocol packet to the receiver. This + allows the receiver to directly validate the protocol packet without + the ability of intermediate TCs to manipulate the packet. + + Since TCs need to modify the correctionField, a separate integrity + protection mechanism is used specifically for the correctionField. + + The end-to-end approach limits the TC's impact to the correctionField + alone, while the rest of the protocol packet is protected on an end- + to-end basis. It should be noted that this approach is more + difficult to implement than the hop-by-hop approach, as it requires + the correctionField to be protected separately from the other fields + of the packet, possibly using different cryptographic mechanisms and + keys. + +5.3. Spoofing Prevention + + Requirement + + The security mechanism MUST provide a means to prevent master + spoofing. + + Requirement + + The security mechanism MUST provide a means to prevent slave + spoofing. + + Requirement + + PTP: The security mechanism MUST provide a means to prevent P2P TC + spoofing. + + Requirement Level + + The requirements in this subsection address spoofing attacks. As + described in Section 3.2.2, when these requirements are not met, + the attack may have a high impact, causing slaves to rely on false + time information. Thus, the requirement level is 'MUST'. + + Discussion + + Spoofing attacks may take various forms, and they can potentially + cause significant impact. In a master spoofing attack, the + attacker causes slaves to receive false information about the + current time by masquerading as the master. + + + +Mizrahi Informational [Page 21] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + By spoofing a slave or an intermediate node (the second example of + Section 3.2.2), an attacker can tamper with the slaves' delay + computations. These attacks can be mitigated by an authentication + mechanism (Sections 5.1.3 and 5.1.4) or by other means, for + example, a PTP Delay_Req can include a MAC that is included in the + corresponding Delay_Resp message, allowing the slave to verify + that the Delay_Resp was not sent in response to a spoofed message. + +5.4. Availability + + Requirement + + The security mechanism SHOULD include measures to mitigate DoS + attacks against the time protocol. + + Requirement Level + + The requirement in this subsection prevents DoS attacks against + the protocol (Section 3.2.9). + + The requirement level of this requirement is 'SHOULD' due to its + low impact, i.e., in the absence of this requirement the protocol + is only exposed to DoS. + + Discussion + + The protocol availability can be compromised by several different + attacks. An attacker can inject protocol packets to implement the + spoofing attack (Section 3.2.2) or the rogue master attack + (Section 3.2.4), causing DoS to the victim (Section 3.2.9). + + An authentication mechanism (Section 5.1) limits these attacks + strictly to internal attackers; thus, it prevents external + attackers from performing them. Hence, the requirements of + Section 5.1 can be used to mitigate this attack. Note that + Section 5.1 addresses a wider range of threats, whereas the + current section is focused on availability. + + The DoS attacks described in Section 3.2.7 are performed at lower + layers than the time protocol layer, and they are thus outside the + scope of the security requirements defined in this document. + + + + + + + + + + +Mizrahi Informational [Page 22] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +5.5. Replay Protection + + Requirement + + The security mechanism MUST include a replay prevention mechanism. + + Requirement Level + + The requirement in this subsection prevents replay attacks + (Section 3.2.3). + + The requirement level of this requirement is 'MUST' since, in the + absence of this requirement, the protocol is exposed to attacks + that are easy to implement and have a high impact. + + Discussion + + The replay attack (Section 3.2.3) can compromise both the + integrity 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 precise frequency requirement should be considered on a per- + system basis, based on the threats and system requirements. + + + +Mizrahi Informational [Page 23] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +5.6.2. Security Association + + Requirement + + The security protocol SHOULD support a security association + protocol where: + + o Two or more clocks authenticate each other. + + o The clocks generate and agree on a cryptographic session + key. + + Requirement + + Each instance of the association protocol SHOULD produce a + different session key. + + Requirement Level + + The requirement level of this requirement is 'SHOULD' since it may + be expensive in terms of performance, especially in low-cost + clocks. + + Discussion + + The security requirements in Sections 5.1 and 5.2 require usage of + cryptographic mechanisms, deploying cryptographic keys. A + security association (e.g., [IPsec]) is an important building + block in these mechanisms. + + It should be noted that in some cases, different security + association mechanisms may be used at different levels of clock + hierarchies. For example, the association between a Stratum 2 + clock and a Stratum 3 clock in NTP may have different + characteristics than an association between two clocks at the same + stratum level. On a related note, in some cases, a hybrid + solution may be used, where a subset of the network is not secured + at all (see Section 5.10.2). + +5.6.3. Unicast and Multicast Associations + + Requirement + + The security mechanism SHOULD support security association + protocols for unicast and for multicast associations. + + + + + + +Mizrahi Informational [Page 24] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + Requirement Level + + The requirement level of this requirement is 'SHOULD' since it may + be expensive in terms of performance, especially for low-cost + clocks. + + Discussion + + A unicast protocol requires an association protocol between two + clocks, whereas a multicast protocol requires an association + protocol among two or more clocks, where one of the clocks is a + master. + +5.7. Performance + + Requirement + + The security mechanism MUST be designed in such a way that it does + not significantly degrade the quality of the time transfer. + + Requirement + + The mechanism SHOULD minimize computational load. + + Requirement + + The mechanism SHOULD minimize storage requirements of client state + in the master. + + Requirement + + The mechanism SHOULD minimize the bandwidth overhead required by + the security protocol. + + Requirement Level + + While the quality of the time transfer is clearly a 'MUST', the + other three performance requirements are 'SHOULD', since some + systems may be more sensitive to resource consumption than others; + hence, these requirements should be considered on a per-system + basis. + + Discussion + + Performance efficiency is important since client restrictions + often dictate a low processing and memory footprint and because + the server may have extensive fan-out. + + + + +Mizrahi Informational [Page 25] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + Note that the performance requirements refer to a time-protocol- + specific security mechanism. In systems where a security protocol + is used for other types of traffic as well, this document does not + place any performance requirements on the security protocol + performance. For example, if IPsec encryption is used for + securing all information between the master and slave node, + including information that is not part of the time protocol, the + requirements in this subsection are not necessarily applicable. + +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 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 usually not considered + secret information. + + Confidentiality can play an important role when service providers + charge their customers for time synchronization services; thus, an + encryption mechanism can prevent eavesdroppers from obtaining the + service without payment. Note that these cases are, for now, + rather esoteric. + + Confidentiality can also prevent an MITM attacker from identifying + protocol packets. Thus, confidentiality can assist in protecting + the timing protocol against MITM attacks such as packet delay + (Section 3.2.6), manipulation and interception, and removal + attacks. Note that time protocols have predictable behavior even + after encryption, such as packet transmission rates and packet + lengths. Additional measures can be taken to mitigate encrypted + traffic analysis by random padding of encrypted packets and by + adding random dummy packets. Nevertheless, encryption does not + prevent such MITM attacks, but rather makes these attacks more + difficult to implement. + + + + + + +Mizrahi Informational [Page 26] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +5.9. Protection against Packet Delay and Interception Attacks + + Requirement + + The security mechanism MUST include means to protect the protocol + from MITM attacks that degrade the clock accuracy. + + Requirement Level + + The requirements in this subsection address MITM attacks such as + the packet delay attack (Section 3.2.6) and packet interception + attacks (Sections 3.2.5 and 3.2.1). + + The requirement level of this requirement is 'MUST'. In the + absence of this requirement, the protocol is exposed to attacks + that are easy to implement and have a high impact. Note that in + the absence of this requirement, the impact is similar to packet + manipulation attacks (Section 3.2.1); thus, this requirement has + the same requirement level as integrity protection (Section 5.2). + + It is noted that the implementation of this requirement depends on + the topology and properties of the system. + + Discussion + + While this document does not define specific security solutions, + we note that common practices for protection against MITM attacks + use redundant masters (e.g., [NTPv4]) or redundant paths between + the master and slave (e.g., [DelayAtt]). If one of the time + sources indicates a time value that is significantly different + than the other sources, it is assumed to be erroneous or under + attack and is therefore ignored. + + Thus, MITM attack prevention derives a requirement from the + security mechanism and a requirement from the network topology. + While the security mechanism should support the ability to detect + delay attacks, it is noted that in some networks it is not + possible to provide the redundancy needed for such a detection + mechanism. + +5.10. Combining Secured with Unsecured Nodes + + Integrating a security mechanism into a time-synchronized system is a + complex and expensive process, and hence in some cases may require + incremental deployment, where new equipment supports the security + mechanism, and is required to interoperate with legacy equipment + without the security features. + + + + +Mizrahi Informational [Page 27] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +5.10.1. Secure Mode + + Requirement + + The security mechanism MUST support a secure mode, where only + secured clocks are permitted to take part in the time protocol. + In this mode every protocol packet received from an unsecured + clock MUST be discarded. + + Requirement Level + + The requirement level of this requirement is 'MUST' since the full + capacity of the security requirements defined in this document can + only be achieved in secure mode. + + Discussion + + While the requirement in this subsection is similar to the one in + Section 5.1, it refers to the secure mode, as opposed to the + hybrid mode presented in the next subsection. + +5.10.2. Hybrid Mode + + Requirement + + The security protocol SHOULD support a hybrid mode, where both + secured and unsecured clocks are permitted to take part in the + protocol. + + Requirement Level + + The requirement level of this requirement is 'SHOULD'; on one + hand, hybrid mode enables a gradual transition from unsecured to + secured mode, which is especially important in large-scaled + deployments. On the other hand, hybrid mode is not required in + all systems; this document recommends deployment of the 'secure + mode' described in Section 5.10.1, where possible. + + Discussion + + The hybrid mode allows both secured and unsecured clocks to take + part in the time protocol. NTP, for example, allows a mixture of + secured and unsecured nodes. + + Requirement + + A master in the hybrid mode SHOULD be a secured clock. + + + + +Mizrahi Informational [Page 28] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + A secured slave in the hybrid mode SHOULD discard all protocol + packets received from unsecured clocks. + + Requirement Level + + The requirement level of this requirement is 'SHOULD' since it may + not be applicable to all deployments. For example, a hybrid + network may require the usage of unsecured masters or TCs. + + Discussion + + This requirement ensures that the existence of unsecured clocks + does not compromise the security provided to secured clocks. + Hence, secured slaves only "trust" protocol packets received from + a secured clock. + + An unsecured slave can receive protocol packets from either + unsecured clocks or secured clocks. Note that the latter does not + apply when encryption is used. When integrity protection is used, + the unsecured slave can receive secured packets ignoring the + integrity protection. + + Note that the security scheme in [NTPv4] with [AutoKey] does not + satisfy this requirement, since nodes prefer the server with the + most accurate clock, which is not necessarily the server that + supports authentication. For example, a Stratum 2 server is + connected to two Stratum 1 servers: Server A, supporting + authentication, and Server B, without authentication. If Server B + has a more accurate clock than A, the Stratum 2 server chooses + Server B, in spite of the fact it does not support authentication. + +6. Summary of Requirements + + +-----------+---------------------------------------------+--------+ + | Section | Requirement | Type | + +-----------+---------------------------------------------+--------+ + | 5.1 | Authentication & authorization of sender | MUST | + | +---------------------------------------------+--------+ + | | Authentication & authorization of master | MUST | + | +---------------------------------------------+--------+ + | | Recursive authentication & authorization | MUST | + | +---------------------------------------------+--------+ + | | Authentication & authorization of slaves | MAY | + | +---------------------------------------------+--------+ + | | PTP: Authentication & authorization of | MAY | + | | P2P TCs by master | | + +-----------+---------------------------------------------+--------+ + + + + +Mizrahi Informational [Page 29] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + +-----------+---------------------------------------------+--------+ + |5.1 (cont) | PTP: Authentication & authorization of | MUST | + | | Announce messages | | + | +---------------------------------------------+--------+ + | | PTP: Authentication & authorization of | MUST | + | | Management messages | | + | +---------------------------------------------+--------+ + | | PTP: Authentication & authorization of | MAY | + | | Signaling messages | | + +-----------+---------------------------------------------+--------+ + | 5.2 | Integrity protection | MUST | + +-----------+---------------------------------------------+--------+ + | 5.3 | Spoofing prevention | MUST | + +-----------+---------------------------------------------+--------+ + | 5.4 | Protection from DoS attacks against the | SHOULD | + | | time protocol | | + +-----------+---------------------------------------------+--------+ + | 5.5 | Replay protection | MUST | + +-----------+---------------------------------------------+--------+ + | 5.6 | Key freshness | MUST | + | +---------------------------------------------+--------+ + | | Security association | SHOULD | + | +---------------------------------------------+--------+ + | | Unicast and multicast associations | SHOULD | + +-----------+---------------------------------------------+--------+ + | 5.7 | Performance: no degradation in quality of | MUST | + | | time transfer | | + | +---------------------------------------------+--------+ + | | Performance: computation load | SHOULD | + | +---------------------------------------------+--------+ + | | Performance: storage | SHOULD | + | +---------------------------------------------+--------+ + | | Performance: bandwidth | SHOULD | + +-----------+---------------------------------------------+--------+ + | 5.8 | Confidentiality protection | MAY | + +-----------+---------------------------------------------+--------+ + | 5.9 | Protection against delay and interception | MUST | + | | attacks | | + +-----------+---------------------------------------------+--------+ + | 5.10 | Secure mode | MUST | + | +---------------------------------------------+--------+ + | | Hybrid mode | SHOULD | + +-----------+---------------------------------------------+--------+ + + Table 2: Summary of Security Requirements + + + + + + +Mizrahi Informational [Page 30] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +7. Additional Security Implications + + This section discusses additional implications of the interaction + between time protocols and security mechanisms. + + This section refers to time protocol security mechanisms, as well as + to "external" security mechanisms, i.e., security mechanisms that are + not strictly related to the time protocol. + +7.1. Security and On-the-Fly Timestamping + + Time protocols often require that protocol packets be modified during + transmission. Both NTP and PTP in one-step mode require clocks to + modify protocol packets based on the time of transmission and/or + reception. + + In the presence of a security mechanism, whether encryption or + integrity protection: + + o During transmission the encryption and/or integrity protection + MUST be applied after integrating the timestamp into the packet. + + To allow high accuracy, timestamping is typically performed as close + to the transmission or reception time as possible. However, since + the security engine must be placed between the timestamping function + and the physical interface, it may introduce non-deterministic + latency that causes accuracy degradation. These performance aspects + have been analyzed in literature, e.g., [1588IPsec] and [Tunnel]. + +7.2. PTP: Security and Two-Step Timestamping + + PTP supports a two-step mode of operation, where the time of + transmission of protocol packets is communicated without modifying + the packets. As opposed to one-step mode, two-step timestamping can + be performed without the requirement to encrypt after timestamping. + + Note that if an encryption mechanism such as IPsec is used, it + presents a challenge to the timestamping mechanism, since time + protocol packets are encrypted when traversing the physical + interface, and are thus impossible to identify. A possible solution + to this problem [IPsecSync] is to include an indication in the + encryption header that identifies time protocol packets. + + + + + + + + + +Mizrahi Informational [Page 31] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +7.3. Intermediate Clocks + + A time protocol allows slaves to receive time information from an + accurate time source. Time information is sent over a path that + often traverses one or more intermediate clocks. + + o In NTP, time information originated from a Stratum 1 server can be + distributed to Stratum 2 servers and, in turn, distributed from + the Stratum 2 servers to NTP clients. In this case, the Stratum 2 + servers are a layer of intermediate clocks. These intermediate + clocks are referred to as "secondary servers" in [NTPv4]. + + o In PTP, BCs and TCs are intermediate nodes used to improve the + accuracy of time information conveyed between the grandmaster and + the slaves. + + A common rule of thumb in network security is that end-to-end + security is the best policy, as it secures the entire path between + the data originator and its receiver. The usage of intermediate + nodes implies that if a security mechanism is deployed in the + network, a hop-by-hop security scheme must be used, since + intermediate nodes must be able to send time information to the + slaves, or to modify time information sent through them. + + This inherent property of using intermediate clocks increases the + system's exposure to internal threats, as a large number of nodes + possess the security keys. + + Thus, there is a trade-off between the achievable clock accuracy of a + system, and the robustness of its security solution. On one hand, + high clock accuracy calls for hop-by-hop involvement in the protocol, + also known as on-path support. On the other hand, a robust security + solution calls for end-to-end data protection. + +7.4. External Security Protocols and Time Protocols + + Time protocols are often deployed in systems that use security + mechanisms and protocols. + + A typical example is the 3GPP Femtocell network [3GPP], where IPsec + is used for securing traffic between a Femtocell and the Femto + Gateway. In some cases, all traffic between these two nodes may be + secured by IPsec, including the time protocol traffic. This use-case + is thoroughly discussed in [IPsecSync]. + + Another typical example is the usage of MACsec encryption ([MACsec]) + in L2 networks that deploy time synchronization [AvbAssum]. + + + + +Mizrahi Informational [Page 32] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + The usage of external security mechanisms may affect time protocols + as follows: + + o Timestamping accuracy can be affected, as described in Section + 7.1. + + o If traffic is secured between two nodes in the network, no + intermediate clocks can be used between these two nodes. In the + [3GPP] example, if traffic between the Femtocell and the Femto + Gateway is encrypted, then time protocol packets are necessarily + transported over the underlying network without modification and, + thus, cannot enjoy the improved accuracy provided by intermediate + clock nodes. + +7.5. External Security Services Requiring Time + + 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 Internet Key Exchange + Protocol version 2 (IKEv2) and Transport Layer Security (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 + + A successful attack on a time protocol may cause the attacked clocks + to go back in time. The erroneous time may expose cryptographic + algorithms that rely on time, as a node may use a key that was + already used in the past and has expired. + + + + + + + +Mizrahi Informational [Page 33] + +RFC 7384 Time Protocol Security Requirements October 2014 + + +8. Issues for Further Discussion + + The Key distribution is outside the scope of this document. Although + this is an essential element of any security system, it is outside + the scope of this document. + +9. Security Considerations + + The security considerations of network timing protocols are presented + throughout this document. + +10. References + +10.1. Normative References + + [IEEE1588] IEEE, "1588-2008 - IEEE Standard for a Precision Clock + Synchronization Protocol for Networked Measurement and + Control Systems", IEEE Standard 1588-2008, July 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., Ed., Burbank, J., and W. Kasch, + "Network Time Protocol Version 4: Protocol and + Algorithms Specification", RFC 5905, June 2010, + . + +10.2. Informative References + + [1588IPsec] Treytl, A. and 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, September 2010. + + [3GPP] 3GPP, "Security of Home Node B (HNB) / Home evolved + Node B (HeNB)", 3GPP TS 33.320 11.6.0, November 2012. + + [Anatomy] Nachreiner, C., "Anatomy of an ARP Poisoning Attack", + 2003. + + [AutoKey] Haberman, B., Ed., and D. Mills, "Network Time Protocol + Version 4: Autokey Specification", RFC 5906, June 2010, + . + + + + + +Mizrahi Informational [Page 34] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + [AvbAssum] Pannell, D., "Audio Video Bridging Gen 2 Assumptions", + IEEE 802.1 AVB Plenary, Work in Progress, May 2012. + + [DelayAtt] Mizrahi, T., "A game theoretic analysis of delay + 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, + September 2012. + + [Hack] McClure, S., Scambray, J., and G. Kurtz, "Hacking + Exposed: Network Security Secrets and Solutions", + McGraw-Hill, 2009. + + [IPsec] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005, + . + + [IPsecSync] Xu, Y., "IPsec security for packet based + synchronization", Work in Progress, draft-xu-tictoc- + ipsec-security-for-synchronization-02, September 2011. + + [Kerb] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, + "Kerberized Internet Negotiation of Keys (KINK)", + RFC 4430, March 2006, + . + + [MACsec] IEEE, "IEEE Standard for Local and metropolitan area + networks - Media Access Control (MAC) Security", IEEE + Standard 802.1AE, August 2006. + + [NTPDDoS] "Attackers use NTP reflection in huge DDoS attack", + TICTOC mail archive, 2014. + + [SecPTP] Tsang, J. and K. Beznosov, "A Security Analysis of the + Precise Time Protocol (Short Paper)," 8th International + Conference on Information and Communication Security + (ICICS) Lecture Notes in Computer Science Volume 4307, + pp. 50-59, 2006. + + [SecSen] Ganeriwal, S., Popper, C., Capkun, S., and M. B. + Srivastava, "Secure Time Synchronization in Sensor + Networks", ACM Trans. Inf. Syst. Secur., Volume 11, + Issue 4, Article 23, July 2008. + + [TimeSec] Mizrahi, T., "Time synchronization security using IPsec + and MACsec", ISPCS 2011, pp. 38-43, September 2011. + + + + +Mizrahi Informational [Page 35] + +RFC 7384 Time Protocol Security Requirements October 2014 + + + [Traps] Treytl, A., Gaderer, G., Hirschler, B., and R. Cohen, + "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, + October 2007. + + [Tunnel] Treytl, A., Hirschler, B., and T. Sauter, "Secure + tunneling of high-precision clock synchronisation + protocols and other time-stamped data", in Proceedings + of the 8th IEEE International Workshop on Factory + Communication Systems (WFCS), pp. 303-313, May 2010. + +Acknowledgments + + The author gratefully acknowledges Stefano Ruffini, Doug Arnold, + Kevin Gross, Dieter Sibold, Dan Grossman, Laurent Montini, Russell + Smiley, Shawn Emery, Dan Romascanu, Stephen Farrell, Kathleen + Moriarty, and Joel Jaeggli for their thorough review and helpful + comments. The author would also like to thank members of the TICTOC + WG for providing feedback on the TICTOC mailing list. + +Contributors + + Karen O'Donoghue + ISOC + + EMail: odonoghue@isoc.org + +Author's Address + + Tal Mizrahi + Marvell + 6 Hamada St. + Yokneam, 20692 Israel + + EMail: talmi@marvell.com + + + + + + + + + + + + + + +Mizrahi Informational [Page 36] + -- cgit v1.2.3