--- 1/draft-ietf-tictoc-security-requirements-03.txt 2013-02-07 22:46:38.035791007 +0100 +++ 2/draft-ietf-tictoc-security-requirements-04.txt 2013-02-07 22:46:38.083791217 +0100 @@ -1,17 +1,18 @@ TICTOC Working Group Tal Mizrahi Internet Draft Marvell Intended status: Informational -Expires: March 2013 September 14, 2012 +Expires: August 2013 February 7, 2013 - TICTOC Security Requirements - draft-ietf-tictoc-security-requirements-03.txt + Security Requirements of Time Synchronization Protocols + in Packet Switched Networks + draft-ietf-tictoc-security-requirements-04.txt Abstract As time synchronization 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 synchronization protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time synchronization protocol practices, the time synchronization @@ -33,139 +34,148 @@ 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 March 14, 2013. + This Internet-Draft will expire on August 7, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + Copyright (c) 2013 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 ................................................. 3 - 2. Conventions Used in this Document ............................ 4 - 2.1. Terminology ............................................. 4 - 2.2. Terms & Abbreviations ................................... 5 - 3. Security Threats ............................................. 5 - 3.1. Threat Model ............................................ 5 - 3.1.1. Internal vs. External Attackers .................... 6 - 3.1.2. Man in the Middle (MITM) vs. Packet Injector ....... 6 - 3.2. Threat Analysis.......................................... 6 - 3.2.1. Packet Interception and Manipulation ............... 6 - 3.2.2. Spoofing ........................................... 6 - 3.2.3. Replay Attack ...................................... 7 - 3.2.4. Rogue Master Attack ................................ 7 - 3.2.5. Packet Interception and Removal .................... 7 - 3.2.6. Packet Delay Manipulation .......................... 7 - 3.2.7. Cryptographic Performance Attacks .................. 7 - 3.2.8. L2/L3 DoS Attacks .................................. 8 - 3.2.9. Master Time Source Spoofing (e.g. GPS fraud) ....... 8 - 3.3. Threat Analysis Summary ................................. 8 - 4. Security Requirements ........................................ 9 - 4.1. Clock Identity Authentication ........................... 9 - 4.1.1. Authentication of Masters ......................... 10 - 4.1.2. Recursive Authentication of Masters (Chain of Trust)10 - 4.1.3. Authentication of Slaves .......................... 11 - 4.1.4. PTP: Authentication of Transparent Clocks.......... 11 - 4.1.5. PTP: Authentication of Announce Messages .......... 11 - 4.2. Data integrity ......................................... 12 - 4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 12 - 4.2.1.1. Hop by Hop Integrity Protection .............. 12 - 4.2.1.2. End to End Integrity Protection .............. 13 - - 4.3. Availability ........................................... 13 - 4.4. Replay Protection ...................................... 14 - 4.5. Cryptographic Keys & Security Associations ............. 14 - 4.5.1. Security Association .............................. 14 - 4.5.2. Unicast and Multicast ............................. 14 - 4.5.3. Key Freshness ..................................... 14 - 4.6. Performance ............................................ 15 - 4.7. Confidentiality......................................... 15 - 4.8. Protection against packet delay attacks ................ 16 - 4.9. Combining Secured with Unsecured Nodes ................. 16 - 4.9.1. Secure Mode ....................................... 17 - 4.9.2. Hybrid Mode ....................................... 17 - 5. Summary of Requirements ..................................... 18 - 6. Additional security implications ............................ 19 - 6.1. Security and on-the-fly Timestamping ................... 19 - 6.2. Security and Two-Step Timestamping ..................... 20 - 6.3. Intermediate Clocks .................................... 20 - 6.4. The Effect of External Security Protocols on Time - Synchronization ............................................. 21 - 6.5. External Security Services Requiring Time Synchronization21 - 7. Issues for Further Discussion ............................... 21 - 8. Security Considerations ..................................... 21 - 9. IANA Considerations ......................................... 22 - 10. Acknowledgments ............................................ 22 - 11. References ................................................. 22 - 11.1. Normative References .................................. 22 - 11.2. Informative References ................................ 22 - 12. Contributing Authors ....................................... 24 + 2. Conventions Used in this Document ............................ 5 + 2.1. Terminology ............................................. 5 + 2.2. Abbreviations ........................................... 5 + 2.3. Common Terminology for PTP and NTP ...................... 5 + 2.4. Terms used in this Document ............................. 5 + 3. Security Threats ............................................. 6 + 3.1. Threat Model ............................................ 7 + 3.1.1. Internal vs. External Attackers .................... 7 + 3.1.2. Man in the Middle (MITM) vs. Packet Injector ....... 7 + 3.2. Threat Analysis.......................................... 8 + 3.2.1. Packet Interception and Manipulation ............... 8 + 3.2.2. Spoofing ........................................... 8 + 3.2.3. Replay Attack ...................................... 8 + 3.2.4. Rogue Master Attack ................................ 8 + 3.2.5. Packet Interception and Removal .................... 9 + 3.2.6. Packet Delay Manipulation .......................... 9 + 3.2.7. Cryptographic Performance Attacks .................. 9 + 3.2.8. L2/L3 DoS Attacks .................................. 9 + 3.2.9. DoS Attacks against the Time Protocol .............. 9 + 3.2.10. Grandmaster Time Source Spoofing (e.g. GPS fraud) . 9 + 3.3. Threat Analysis Summary ................................ 10 + 4. Requirement Levels .......................................... 11 + 5. Security Requirements ....................................... 12 + 5.1. Clock Identity Authentication and Authorization ........ 12 + 5.1.1. Authentication and Authorization of Masters ....... 13 + 5.1.2. Recursive Authentication and Authorization of Masters + (Chain of Trust) ......................................... 14 + 5.1.3. Authentication and Authorization of Slaves ........ 15 + 5.1.4. PTP: Authentication and Authorization of Transparent + Clocks by Master ......................................... 15 + 5.1.5. PTP: Authentication and Authorization of Control + Messages ................................................. 16 + 5.2. Data integrity ......................................... 17 + 5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 18 + 5.2.1.1. Hop-by-Hop Integrity Protection .............. 18 + 5.2.1.2. End-to-End Integrity Protection .............. 19 + 5.3. Availability ........................................... 19 + 5.4. Replay Protection ...................................... 20 + 5.5. Cryptographic Keys and Security Associations ........... 20 + 5.5.1. Key Freshness ..................................... 20 + 5.5.2. Security Association .............................. 21 + 5.5.3. Unicast and Multicast ............................. 21 + 5.6. Performance ............................................ 22 + 5.7. Confidentiality......................................... 22 + 5.8. Protection against Packet Delay and Interception Attacks 23 + 5.9. Combining Secured with Unsecured Nodes ................. 24 + 5.9.1. Secure Mode ....................................... 24 + 5.9.2. Hybrid Mode ....................................... 24 + 6. Summary of Requirements ..................................... 26 + 7. Additional security implications ............................ 27 + 7.1. Security and on-the-fly Timestamping ................... 27 + 7.2. PTP: Security and Two-Step Timestamping ................ 28 + 7.3. Intermediate Clocks .................................... 28 + 7.4. The Effect of External Security Protocols on Time + Synchronization ............................................. 29 + 7.5. External Security Services Requiring Time Synchronization29 + 7.5.1. Timestamped Certificates .......................... 29 + 7.5.2. Time Synchronization as a Vulnerability ........... 30 + 8. Issues for Further Discussion ............................... 30 + 9. Security Considerations ..................................... 30 + 10. IANA Considerations......................................... 30 + 11. Acknowledgments ............................................ 30 + 12. References ................................................. 30 + 12.1. Normative References .................................. 30 + 12.2. Informative References ................................ 31 + 13. Contributing Authors ....................................... 32 1. Introduction As time synchronization protocols are becoming increasingly common and widely deployed, concern about the resulting exposure to various security threats is increasing. If a time synchronization protocol is compromised, the applications it serves are prone to a range of - possible attacks including Denial-of-Service or incorrect behavior. + possible attacks including Denial-of-Service (DoS) or incorrect + behavior. This document focuses on the security aspects of the Precision Time Protocol (PTP) [IEEE1588] and the Network Time Protocol [NTPv4]. The Network Time Protocol was defined with an inherent security protocol, - defined in [NTPv4] and in [AutoKey]. The IEEE 1588 includes an + defined in [NTPv4] and in [AutoKey]. [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. - Many of the existing packet timing deployments do not use any - security mechanisms. 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 it is deployed in. Based on a - system-specific threat assessment, the benefits of a security - solution must be weighed against the potential risks, and based on - this tradeoff an optimal security solution can be selected. + 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 it is deployed in. Based on a system-specific threat + assessment, the benefits of a security solution must be weighed + against the potential risks, and based on this tradeoff an optimal + security solution can be selected. This document attempts to add clarity to the time synchronization protocol security requirements discussion by addressing a series of questions: (1) What are the threats that need to be addressed for the time synchronization protocol, and thus 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 synchronization traffic path) + impacts? (e.g. an IPsec tunnel in the synchronization traffic path) (3) What are the security impacts of time synchronization protocol practices? (e.g. on-the-fly modification of timestamps) (4) What are the dependencies between other security services and time synchronization? (e.g. 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 synchronization @@ -178,102 +188,157 @@ 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, and 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 defines the requirements that every security mechanism should comply to. +2.2. Abbreviations + + BC Boundary Clock + + DoS Denial of Service + + MITM Man In The Middle + + NTP Network Time Protocol + + OC Ordinary Clock + + PTP Precision Time Protocol + + TC Transparent Clock + +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 general term "clock" refers to masters, slaves and PTP Transparent Clocks (TC). The term - "protocol packets" is refers generically to PTP and NTP messages. + "protocol packets" refers generically to PTP and NTP messages. -2.2. Terms & Abbreviations +2.4. Terms used in this Document - BC Boundary Clock + 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. - MITM Man In The Middle + o End-to-end security - A security approach where secured packets + sent from a source to a destination is not modified by + intermediate nodes. - NTP Network Time Protocol + 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. - OC Ordinary Clock + 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. - PTP Precision Time Protocol + 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. - Secured clock A clock that supports a security mechanism that - complies to the requirements in this document + 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. - TC Transparent Clock + o Protocol packets - Packets used by the time protocol. The + terminology used in this document distinguishes between time + packets and control packets. - Unsecured clock A clock that does not support a security mechanism - according to the requirments in this document + 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 + This section discusses the possible attacker types and analyzes various attacks against time synchronization protocols. The literature is rich with security threats of time synchronization protocols, e.g., [Traps], [AutoKey], [TM], [SecPTP], and [SecSen]. The threat analysis in this document is mostly based on [TM]. 3.1. Threat Model A time synchronization protocol can be attacked by various types of attackers. - The analysis in this documents classifies attackers according to 2 + The analysis in this document classifies attackers according to 2 criteria, as described in 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 synchronization protocol is secured - either by an encryption or an authentication mechanism. + either by an encryption or an authentication mechanism, or both. Internal attackers either have access to a trusted segment of the - network, or possess the encryption or authentication keys. External - attackers, on the other hand, do not have the keys, and are exposed - only to the encrypted or authenticated traffic. 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. + 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. + + 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. + 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 generatating protocol packets. An injector can also potentially - eavesdrop to protocol packets sent as multicast, record them and - replay them later. + 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. 3.2. Threat Analysis 3.2.1. Packet Interception and Manipulation - A packet interception and manipulation attack results when a Man-In- - The-Middle (MITM) attacker intercepts 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. + A packet interception and manipulation attack results when an MITM + attacker intercepts 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 attacker masquerades as a legitimate node in the network by generating and transmitting protocol packets. For example, an attacker can impersonate the master, allowing malicious distribution of false timing information. As with packet interception and manipulation, this can result in a situation where the time protocol is apparently operational but providing intentionally inaccurate information. @@ -282,727 +347,1051 @@ 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 Rouge Master attack the attacker does not - fake its identity, but rather manipulates the master election - process. 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. + 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. + + 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 a Man-In-The- - Middle attacker intercepts and drops protocol packets, preventing the - destination node from receiving the timing information. + A packet interception and removal attack results when an MITM + attacker intercepts and drops protocol packets, preventing the + destination node from receiving the some or all of the protocol + packets. 3.2.6. Packet Delay Manipulation - In a packet delay manipulation scenario, a Man-In-The-Middle attacker - intercepts protocol packets, and relays them to their destination - after adding a maliciously computed delay. + In a packet delay manipulation scenario, an MITM attacker intercepts + protocol packets, and relays them to their destination after adding a + maliciously computed delay. - Note that the attackee still receives one copy of each packet, - contrary to the replay attack, where a packet is received by the - attackee more than once. + 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. Cryptographic Performance Attacks In cryptographic performance attacks, an attacker transmits fake protocol packet, 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 + 3.2.8. L2/L3 DoS Attacks - There are many possible Layer 2 and Layer 3 Denial of Service - attacks. As the target's availability is compromised, the timing - protocol is affected accordingly. + There are many possible Layer 2 and Layer 3 DoS attacks. As the + target's availability is compromised, the timing protocol is affected + accordingly. -3.2.9. Master Time Source Spoofing (e.g. GPS fraud) +3.2.9. DoS Attacks against the Time Protocol + + An attacker can attack a clock using 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 3.2.2. and 3 .2.4. + +3.2.10. Grandmaster Time Source Spoofing (e.g. GPS fraud) In time source spoofing, an attacker spoofs the accurate time source - of the master. For example, if the master uses a GPS based clock as - its reference source, an attacker can spoof the GPS satellites, - causing the master to use a false reference time. + of the grandmaster. For example, if the grandmaster uses a GPS based + clock as its reference source, an attacker can spoof GPS satellite + signals, causing the grandmaster to use a false reference time. + + Note that this attack is outside the scope of the time + synchronization 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.3. Threat Analysis Summary The two key factors to a threat analysis are the severity and the likelihood of each of the analyzed attacks. Table 1 summarizes the security attacks presented in 3.2. For each attack, the table specifies its impact, and its applicability to each of the attacker types presented in 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 intuition to the severity of each attack, and the relevant Attacker Type columns provide an intuition about the 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 3 values: - o DoS - the attack causes a denial of service to the attacked node, + o DoS - the attack causes denial of service to the attacked node, the impact of which is not restricted to the time synchronization protocol. - o False time - slaves align to a false time or frequency value due - to the attack. Note that if the time synchronization service - aligns to a false time, it may cause denial of service 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 synchronization protocol. - o Accuracy degradation - the attack yields a degradation in the slave accuracy, but does not completely compromise the slaves' time and frequency. - The Attacket Type columns refer to the 4 possible combinations of the + o False time - slaves align to a false time or frequency value due + to the attack. Note that if the time synchronization service + 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 synchronization protocol. + All attacks that have a '+' for 'False Time' implicitly have a '+' + for 'Accuracy Degradation'. + + The Attacker Type columns refer to the 4 possible combinations of the attacker types defined in 3.1. +-----------------------------+-------------------++-------------------+ | Attack | Impact || Attacker Type | | +-----+--------+----++---------+---------+ -| |False|Accuracy| ||Internal | Extenal | +| |False|Accuracy| ||Internal |External | | |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.| +-----------------------------+-----+--------+----++----+----+----+----+ |Interception and manipulation| + | | || + | | | | +-----------------------------+-----+--------+----++----+----+----+----+ |Spoofing | + | | || + | + | | | +-----------------------------+-----+--------+----++----+----+----+----+ |Replay attack | + | | || + | + | | | +-----------------------------+-----+--------+----++----+----+----+----+ |Rogue master attack | + | | || + | + | | | +-----------------------------+-----+--------+----++----+----+----+----+ |Interception and Removal | | + | || + | | + | | +-----------------------------+-----+--------+----++----+----+----+----+ |Packet delay manipulation | + | | || + | | + | | +-----------------------------+-----+--------+----++----+----+----+----+ |Crypt. performance attacks | | | + || + | + | + | + | +-----------------------------+-----+--------+----++----+----+----+----+ -|DoS attacks | | | + || + | + | + | + | +|L2/L3 DoS attacks | | | + || + | + | + | + | ++-----------------------------+-----+--------+----++----+----+----+----+ +|Time Protocol DoS attacks | | | + || + | + | | | +-----------------------------+-----+--------+----++----+----+----+----+ |Master Time source spoofing | + | | || + | + | + | + | |(e.g. GPS spoofing) | | | || | | | | +-----------------------------+-----+--------+----++----+----+----+----+ Table 1 Threat Analysis - Summary -4. Security Requirements + The threats discussed in this section provide the background for the + security requirements presented in Section 5 . - This section defines a set of requirements from the security - mechanisms used for PTP and NTP. 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 requirments can be satisfied by extending the 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. +4. Requirement Levels -4.1. Clock Identity Authentication + The security requirements are presented in Section 5 . Each + requirement is defined with a requirement level, in accordance with + the requirement levels defined in [KEYWORDS]. + + 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. + + 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 about the reason for its requirement level. + +5. Security Requirements + + This section defines the requirements of security mechanisms used for + time synchronization protocols. + + 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 provide a means for each clock to authenticate the sender of a protocol packet. -Discussion +Requirement - In the context of this document, authentication refers to: + The security mechanism MUST provide a means for each clock to verify + that the sender of a protocol packet is authorized to send a packet + of this type. - o Identification: verifying the identity of the peer clock. +Requirement Level - o Authorization: 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. + 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. + +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. + + 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 4 distinct cases of clock authentication. -4.1.1. Authentication of Masters +5.1.1. Authentication and Authorization of Masters Requirement The security mechanism MUST support an authentication mechanism, - allowing slave clocks to authenticate the identity of master clocks. - -4.1.2. Recursive Authentication of Masters (Chain of Trust) + allowing slaves to authenticate the identity of masters. Requirement - The security mechanism MUST support recursive authentication of the - master, to be used in cases where end-to-end authentication is not - possible. + 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. Discussion Clocks authenticate masters in order to ensure the authenticity of - the time source. + 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. - In some cases a slave is connected to an intermediate master, that is +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), 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 master, and the intermediate master authenticates the - primary master. This inductive authentication process is referred to - in [AutoKey] as proventication. + 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 inductive authentication process + is referred to in [AutoKey] as proventication. -4.1.3. Authentication of Slaves + Specifically in PTP, this requirement implies that if a slave is + receives time information through a TC, it must authenticate the TC + it is attached to, as well as authenticate the master it receives the + time information from, as per Section 5.1.1. Similarly, if a TC + receives time information through an attached TC, it must + authenticate the attached TC. + +5.1.3. Authentication and Authorization of Slaves Requirement - The security mechanism SHOULD provide a means for a master to + The security mechanism MAY provide a means for a master to authenticate its slaves. +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 low impact, 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. + Discussion Slaves are authenticated by masters in order to verify that the slave is authorized to receive timing services from the master. Authentication of slaves prevents unauthorized clocks from receiving - time services, and also reduces unnecessary load on the master clock, - by preventing the master from serving unauthorized clocks. It could - be argued that the authentication of slaves could put a higher load - on the master then serving the unauthorized clock, and hence this + time services, and also reduces unnecessary load on the master, by + preventing the master from serving unauthorized clocks. It could be + argued that the authentication of slaves could put a higher load on + the master then serving the unauthorized clock, and hence this requirement is a SHOULD. -4.1.4. PTP: Authentication of Transparent Clocks +5.1.4. PTP: Authentication and Authorization of Transparent Clocks by + Master Requirement - The security mechanism for PTP SHOULD provide a means for a master to + 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 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 clock and peer TCs, by preventing the - master from serving unauthorized clocks. + unnecessary load on the master and peer TCs, by preventing the master + from serving unauthorized clocks. -4.1.5. PTP: Authentication of Announce Messages +5.1.5. PTP: Authentication and Authorization of Control Messages Requirement The security mechanism for PTP MUST support authentication of - Announce messages. + 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. + +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 for. 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 malicious master - attacks. + 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 Section 5.1.1. or in + Section 5.1.3. , since the BMCA is initiated before clocks have been + defined as masters or slaves. - Note, that this subsection specifies a requirement that is not - necessarily included in 4.1.1. or in 4.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. -4.2. Data integrity + 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 message may be required in some systems, + depending on the application these messages are used for. + +5.2. Data integrity Requirement The security mechanism MUST protect the integrity of protocol packets. +Requirement Level + + The requirement in this subsection addresses the packet interception + and 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 a high impact. + Discussion - While subsection 4.1. refers to ensuring WHO sent the 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. + 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. -4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection +5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection Requirement A security mechanism for PTP MUST support hop-by-hop integrity protection. Requirement A security mechanism for PTP SHOULD support end-to-end integrity protection. +Requirement Level + + The requirement in this subsection addresses the packet interception + and manipulation attack (Section 3.2.1. ). + + The requirement level of the first 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. + + The requirement level of the first requirement is 'SHOULD' since in + the presence of recursive authentication (Section 5.1.2. ) this + requirement may be redundant. + Discussion 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. -4.2.1.1. Hop by Hop Integrity Protection +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. o Re-generates the integrity protection, e.g., re-computes a Message Authentication Code. 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 malicious TCs to modify protocol + This approach is simple, but allows rogue TCs to modify protocol packets. -4.2.1.2. End to End Integrity Protection +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 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 separate - layers of protection for the correctionField and for the rest of the - packet, using different cryptographic mechanisms and keys. + 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. -4.3. Availability +5.3. Availability Requirement - The security mechanism MUST protect the time synchronization protocol - from DoS attacks by external attackers. + 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 messages to implement the - spoofing attack (Section 3.2.2. ) or the rogue master attack (Section - 3.2.4. ), causing denial of service to the attackee. An - authentication mechanism (Section 4.1. ) limits these attacks - strictly to internal attackers, and thus prevents external attackers - from performing them. + attacks. - Note that a security mechanism applied at the time synchronization - layer cannot, by itself, prevent DoS attacks described in Section - 3.2.8. DoS attacks at lower layers of the protocol stack (Section - 3.2.8. ) can still be implemented by external attackers even in the - presence of an authentication mechanism. + An attacker can inject protocol messages 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, and thus prevents external attackers from performing them. -4.4. Replay Protection + The DoS attacks described in Section 3.2.8. are performed at lower + layers than the time synchronization protocol layer, and are thus + outside the scope of the security requirements defined in this + document. + +5.4. Replay Protection Requirement - Protocol messages MUST be resistant to replay attacks. + The security mechanism MUST include a replay prevention mechanism. -4.5. Cryptographic Keys & Security Associations +Requirement Level -4.5.1. Security Association + 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.5. Cryptographic Keys and Security Associations + +5.5.1. Key Freshness + +Requirement + + The cryptographic keys MUST be refreshed periodically. + +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 and playback attacks. + Thus, it is important keys to be refreshed periodically. + +5.5.2. Security Association Requirement The security protocol SHOULD support an association protocol where: o Two or more clocks authenticate each other. o The clocks generate and agree on a cryptographic session key. +Requirement + + The association protocol SHOULD be periodically invoked. 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 4.1. and 4.2. require usage of - cryptographich mechanisms, deploying cryptographic keys. A security - association is an essential building block in these mechanisms. + The security requirements in Section 5.1. and Section 5 .2. require + usage of cryptographic mechanisms, deploying cryptographic keys. A + security association is an essential building block in these + mechanisms. -4.5.2. Unicast and Multicast +5.5.3. Unicast and Multicast Requirement The security mechanism SHOULD support security association protocols for unicast and for multicast associations. -Discussion +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 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. -4.5.3. Key Freshness - -Requirement - The cryptographic keys MUST be refreshed periodically. - -Requirement - - The association protocol MUST be invoked periodically, where each - instance of the association protocol MUST produce a different session - key. - -4.6. Performance +5.6. Performance Requirement The security mechanism MUST be designed in such a way that it does not degrade the quality of the time transfer. Requirement - The mechanism SHOULD be relatively lightweight, as client - restrictions often dictate a low processing and memory footprint, and - because the server may have extensive fan-out. + The mechanism SHOULD minimize computational load. Requirement - The mechanism also SHOULD not require excessive storage of client + The mechanism also SHOULD minimize storage requirements of client state in the master, nor significantly increase bandwidth consumption. 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. + Note that the performance requirements refer to a time- synchronization-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. -4.7. Confidentiality +5.7. 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. + Discussion + In the context of time synchronization, 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 payment for time synchronization services, but these cases are - rather esoteric. + charge their customers for time synchronization services, and thus an + encryption mechanism can prevent eavesdroppers from obtaining the + service without payment. Note that these cases are rather esoteric. Confidentiality can also prevent an MITM attacker from identifying protocol packets. Thus, confidentiality can assist in protecting the - timing protocol against packet delay attacks, where the attacker - selectively adds delay to time protocol packets. Note, that time - protocols have predictable behavior such as packet transmission rates - and packet lengths, and thus packet encryption does not prevent delay - attacks, but rather makes these attacks more difficult to implement. + 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 + measure 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. -4.8. Protection against packet delay attacks +5.8. Protection against Packet Delay and Interception Attacks Requirement - The security mechanism MAY include a means to detect packet delay - attacks. + The security mechanism SHOULD include means to protect the protocol + from MITM attacks that degrade the clock accuracy. -Requirement +Requirement Level - The security mechanism MAY include a redundancy mechanism that allows - a node that detects a delay attack to switch over to a secondary - master. + The requirements in this subsection address MITM attacks such as the + 3.2.1. ). + + The requirement level of this requirement is 'SHOULD'. In the absence + of this requirement the protocol is exposed to attacks that are easy + to implement and have a high impact. On the other hand, the + implementation of this requirement depends on the topology and + properties of the system, and is thus not necessarily applicable to + all deployments. Discussion While this document does not define specific security solutions, we - note that common practices for protection against delay attacks use + 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. - This requirement is a "may" requirement since both master redundancy - and path redundancy are not necessarily possible in all network - topologies. + 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 necessarily + possible to provide the redundancy needed for such a detection + mechanism. -4.9. Combining Secured with Unsecured Nodes +5.9. Combining Secured with Unsecured Nodes Integrating a security mechanism into a time synchronized system is a - complex process, and in some cases may require a gradual process, - where new equipment supports the security mechanism, and is required - to interoperate with legacy equipment without the security features. + complex process, and 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. -4.9.1. Secure Mode +5.9.1. Secure Mode Requirement The security mechanism MUST support a secure mode, where only secured clocks are permitted to take part in the synchronization protocol. A 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 a bit similar to the one - in 4.1. , it explicitly defines the secure mode, as opposed to the + in 5.1. , it explicitly defines the secure mode, as opposed to the hybrid mode presented in the next subsection. -4.9.2. Hybrid Mode +5.9.2. Hybrid Mode Requirement The security protocol MAY 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 a 'MAY', since it is not + necessarily required in all systems. This document recommends to + deploy the 'Secure Mode' described in Section 5.9.1. where possible. + Discussion The hybrid mode allows both secured and unsecured clocks to take part in the synchronization protocol. NTP, for example, allows a mixture of secured and unsecured nodes. Requirement A master in the hybrid mode SHOULD be a secured clock. 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 a '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 clock can receive protocol packets from either - secured clocks, or unsecured clocks. + clock. + + An unsecured slave can receive protocol packets either from unsecured + clocks, or from 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 best - clock, and 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. + satisfy this requirement, since nodes prefer the server with the most + accurate clock, and 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. -5. Summary of Requirements +6. Summary of Requirements - +-----------+--------------------------------------+---------------+ + +-----------+---------------------------------------------+--------+ | Section | Requirement | Type | - +-----------+--------------------------------------+---------------+ - | 4.1. | Authentication of sender. | MUST | - | +--------------------------------------+---------------+ - | | Authentication of master. | MUST | - | +--------------------------------------+---------------+ - | | Recursive authentication. | MUST | - | +--------------------------------------+---------------+ - | | Authentication of slaves. | SHOULD | - | +--------------------------------------+---------------+ - | | PTP: Authentication of TCs. | SHOULD | - | +--------------------------------------+---------------+ - | | PTP: Authentication of Announce | SHOULD | - | | messages. | | - +-----------+--------------------------------------+---------------+ - | 4.2. | Integrity protection. | MUST | - | +--------------------------------------+---------------+ + +-----------+---------------------------------------------+--------+ + | 5.1. | Authentication & authorization of sender. | MUST | + | +---------------------------------------------+--------+ + | | Authentication & authorization of master. | MUST | + | +---------------------------------------------+--------+ + | | Recursive authentication & authorization. | MUST | + | +---------------------------------------------+--------+ + | | Authentication of slaves. | MAY | + | +---------------------------------------------+--------+ + | | PTP: Authentication of TCs by master. | MAY | + | +---------------------------------------------+--------+ + | | 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 | + | +---------------------------------------------+--------+ | | PTP: hop-by-hop integrity protection.| MUST | - | +--------------------------------------+---------------+ + | +---------------------------------------------+--------+ | | PTP: end-to-end integrity protection.| SHOULD | - +-----------+--------------------------------------+---------------+ - | 4.3. | Protection against DoS attacks. | MUST | - +-----------+--------------------------------------+---------------+ - | 4.4. | Replay protection. | MUST | - +-----------+--------------------------------------+---------------+ - | 4.5. | Security association. | SHOULD | - | +--------------------------------------+---------------+ + +-----------+---------------------------------------------+--------+ + | 5.3. | Protection against DoS attacks. | SHOULD | + +-----------+---------------------------------------------+--------+ + | 5.4. | Replay protection. | MUST | + +-----------+---------------------------------------------+--------+ + | 5.5. | Key freshness. | MUST | + | +---------------------------------------------+--------+ + | | Security association. | SHOULD | + | +---------------------------------------------+--------+ | | Unicast and multicast associations. | SHOULD | - | +--------------------------------------+---------------+ - | | Key freshness. | MUST | - +-----------+--------------------------------------+---------------+ - | 4.6. | Performance: no degradation in | MUST | - | | quality of time transfer. | | - | +--------------------------------------+---------------+ - | | Performance: lightweight. | SHOULD | - | +--------------------------------------+---------------+ - | | Performance: storage, bandwidth. | MUST | - +-----------+--------------------------------------+---------------+ - | 4.7. | Confidentiality protection. | MAY | - +-----------+--------------------------------------+---------------+ - | 4.8. | Protection against delay attacks. | MAY | - +-----------+--------------------------------------+---------------+ - | 4.9. | Secure mode. | MUST | - | +--------------------------------------+---------------+ + +-----------+---------------------------------------------+--------+ + | 5.6. | Performance: no degradation in quality of | MUST | + | | time transfer. | | + | +---------------------------------------------+--------+ + | | Performance: computation load. | SHOULD | + | +---------------------------------------------+--------+ + | | Performance: storage, bandwidth. | SHOULD | + +-----------+---------------------------------------------+--------+ + | 5.7. | Confidentiality protection. | MAY | + +-----------+---------------------------------------------+--------+ + | 5.8. | Protection against delay and interception | SHOULD | + | | attacks. | | + +-----------+---------------------------------------------+--------+ + | 5.9. | Secure mode. | MUST | + | +---------------------------------------------+--------+ | | Hybrid mode. | MAY | - +-----------+--------------------------------------+---------------+ + +-----------+---------------------------------------------+--------+ Table 2 Summary of Security Requirements -6. Additional security implications +7. Additional security implications This section discusses additional implications of the interaction between time synchronization protocols and security mechanisms. This section refers to time synchronization security mechanisms, as well as to "external" security mechanisms, i.e., security mechanisms that are not strictly related to the time synchronization protocol. -6.1. Security and on-the-fly Timestamping +7.1. Security and on-the-fly Timestamping Time synchronization protocols often require protocol packets to be - modified during transmission and reception. Both NTP and PTP in one- - step mode require clocks to modify protocol packets with the time of - transmission or reception. + modified during transmission. Both NTP and PTP in one-step mode + require clocks to modify protocol packets with the time of + transmission. In the presence of a security mechanism, whether encryption or integrity protection: o During transmission the security protocol must be applied after integrating the timestamp into the packet. - o During reception, the encryption or integrity check must be - performed before modifying the packet with the time of reception. - 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, in some cases it may introduce non- - deterministic latency that causes accuracy degradation. These - performance aspects have been analyzed in the literature, e.g., in - [1588IPsec] and [Tunnel]. + the physical interface, it may introduce non-deterministic latency + that causes accuracy degradation. These performance aspects have been + analyzed in the literature, e.g., in [1588IPsec] and [Tunnel]. -6.2. Security and Two-Step Timestamping +7.2. PTP: Security and Two-Step Timestamping PTP supports a two-step mode of operation, where the time of - transmission and the time of reception of protocol packets are - measured without modifying the packets. As opposed to one-step mode, - two step timestamping can be performed at the physical interface even - in the presence of a security mechanism. + 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 synchronization packets. -6.3. Intermediate Clocks +7.3. Intermediate Clocks A time synchronization 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. 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, all - intermediate nodes must be exposed to the security key since they - must be able to send time information to the slaves, or to modify - time information sent through them. + intermediate nodes must possess the security key (hop-by-hop + security) since they must be able to send time information to the + slaves, or to modify time information sent through them. - This inhehrent property of using intermediate clocks increases the + This inherent property of using intermediate clocks increases the system's exposure to internal threats, as there is a large number of - nodes that are exposed to the security keys. + nodes that possess the security keys. -6.4. The Effect of External Security Protocols on Time Synchronization + Thus, there is a tradeoff 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. The Effect of External Security Protocols on Time Synchronization Time synchronization 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 synchronization protocol traffic. This use-case is thoroughly discussed in [IPsecSync]. - Another typical example is the usage of MACsec encryption in L2 - networks that deploy time synchronization [AvbAssum]. + Another typical example is the usage of MACsec encryption ([MACsec]) + in L2 networks that deploy time synchronization [AvbAssum]. The usage of external security mechanisms may affect time synchronization protocols as follows: - o Timestamping accuracy can be affected, as described in 6.1. + o Timestamping accuracy can be affected, as described in 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 sent over the underlying network without modification, and thus cannot enjoy the improved accuracy provided by intermediate clock nodes. -6.5. External Security Services Requiring Time Synchronization +7.5. External Security Services Requiring Time Synchronization + +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. An even stronger interdependence between a time synchronization 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. + 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. Issues for Further Discussion +7.5.2. Time Synchronization as a Vulnerability - o The key distribution is outside the scope of this document. - Although this is a cardinal element in any security system, it is - not a security requirement, and is thus not described here. + Cryptographic protocols often use time as an important factor in the + cryptographic algorithm. If a time synchronization protocol is + compromised, it may consequently cause expose the security protocols + that rely on it to various attacks. -8. Security Considerations + For example, a successful attack on a time synchronization protocol + may cause the attacked clocks to be synchronized to an early time. + This erroneous time may expose cryptographic algorithms that rely on + time to replay attacks. + +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. -9. IANA Considerations +10. IANA Considerations There are no new IANA considerations implied by this document. -10. Acknowledgments +11. Acknowledgments - The authors gratefully acknowledge Stefano Ruffini, Dieter Sibold and - Dan Grossman 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. + The authors gratefully acknowledge Stefano Ruffini, Doug Arnold, + Kevin Gross, Dieter Sibold, Dan Grossman and Laurent Montini 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. -11. References +12. References -11.1. Normative References +12.1. Normative References [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. [AutoKey] Haberman, B., Mills, D., "Network Time Protocol Version 4: Autokey Specification", RFC 5906, June 2010. - [IEEE1588] IEEE TC 9 Test and Measurement Society 2000, "1588 - IEEE Standard for a Precision Clock Synchronization - Protocol for Networked Measurement and Control Systems - Version 2", IEEE Standard, 2008. + [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. -11.2. Informative References +12.2. Informative References [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. [TM] T. Mizrahi, "Time synchronization security using IPsec and MACsec", ISPCS 2011, pp. 38-43, 2011. @@ -1041,21 +1430,28 @@ Communication Systems (WFCS), vol. ISBN 978-1-4244- 5461-7, pp. 303-313, 2010. [DelayAtt] T. Mizrahi, "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, 2012. -12. Contributing Authors + [MACsec] IEEE 802.1AE-2006, "IEEE Standard for Local and + Metropolitan Area Networks - Media Access Control + (MAC) Security", 2006. + + [IPsec] S. Kent, K. Seo, "Security Architecture for the + Internet Protocol", IETF, RFC 4301, 2005. + +13. Contributing Authors Karen O'Donoghue ISOC Email: odonoghue@isoc.org Authors' Addresses Tal Mizrahi Marvell