--- 1/draft-ietf-tictoc-security-requirements-05.txt 2013-10-21 14:14:35.127277978 -0700 +++ 2/draft-ietf-tictoc-security-requirements-06.txt 2013-10-21 14:14:35.187279539 -0700 @@ -1,18 +1,18 @@ TICTOC Working Group Tal Mizrahi Internet Draft Marvell Intended status: Informational -Expires: October 2013 April 25, 2013 +Expires: April 2014 October 21, 2013 Security Requirements of Time Protocols in Packet Switched Networks - draft-ietf-tictoc-security-requirements-05.txt + draft-ietf-tictoc-security-requirements-06.txt Abstract As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security @@ -33,21 +33,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on October 25, 2013. + This Internet-Draft will expire on April 21, 2014. Copyright Notice 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 @@ -63,21 +63,21 @@ 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 ............................. 6 3. Security Threats ............................................. 7 3.1. Threat Model ............................................ 7 3.1.1. Internal vs. External Attackers .................... 7 3.1.2. Man in the Middle (MITM) vs. Packet Injector ....... 8 3.2. Threat Analysis.......................................... 8 - 3.2.1. Packet Interception and Manipulation ............... 8 + 3.2.1. Packet 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. L2/L3 DoS Attacks .................................. 9 3.2.8. Cryptographic Performance Attacks .................. 9 3.2.9. DoS Attacks against the Time Protocol ............. 10 3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud) . 10 3.3. Threat Analysis Summary ................................ 10 @@ -101,24 +101,24 @@ 5.5. Cryptographic Keys and Security Associations ........... 21 5.5.1. Key Freshness ..................................... 21 5.5.2. Security Association .............................. 21 5.5.3. Unicast and Multicast Associations ................ 22 5.6. Performance ............................................ 22 5.7. Confidentiality......................................... 23 5.8. Protection against Packet Delay and Interception Attacks 24 5.9. Combining Secured with Unsecured Nodes ................. 25 5.9.1. Secure Mode ....................................... 25 5.9.2. Hybrid Mode ....................................... 25 - 6. Summary of Requirements ..................................... 26 + 6. Summary of Requirements ..................................... 27 7. Additional security implications ............................ 28 7.1. Security and on-the-fly Timestamping ................... 28 - 7.2. PTP: Security and Two-Step Timestamping ................ 28 + 7.2. PTP: Security and Two-Step Timestamping ................ 29 7.3. Intermediate Clocks .................................... 29 7.4. External Security Protocols and Time Protocols.......... 30 7.5. External Security Services Requiring Time .............. 30 7.5.1. Timestamped Certificates .......................... 30 7.5.2. Time Changes and Replay Attacks ................... 31 8. Issues for Further Discussion ............................... 31 9. Security Considerations ..................................... 31 10. IANA Considerations......................................... 31 11. Acknowledgments ............................................ 31 12. References ................................................. 31 @@ -329,38 +329,38 @@ 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. 3.2. Threat Analysis -3.2.1. Packet Interception and Manipulation +3.2.1. Packet Manipulation - 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. + 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. 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. + packet manipulation, this 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 @@ -379,21 +379,21 @@ 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 intercepts + 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. @@ -477,21 +477,21 @@ The Attacker Type columns refer to the 4 possible combinations of the attacker types defined in Section 3.1. +-----------------------------+-------------------++-------------------+ | Attack | Impact || Attacker Type | | +-----+--------+----++---------+---------+ | |False|Accuracy| ||Internal |External | | |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.| +-----------------------------+-----+--------+----++----+----+----+----+ -|Interception and manipulation| + | | || + | | | | +|Manipulation | + | | || + | | | | +-----------------------------+-----+--------+----++----+----+----+----+ |Spoofing | + | | || + | + | | | +-----------------------------+-----+--------+----++----+----+----+----+ |Replay attack | + | | || + | + | | | +-----------------------------+-----+--------+----++----+----+----+----+ |Rogue master attack | + | | || + | + | | | +-----------------------------+-----+--------+----++----+----+----+----+ |Interception and removal | | + | + || + | | + | | +-----------------------------+-----+--------+----++----+----+----+----+ |Packet delay manipulation | + | | || + | | + | | @@ -648,21 +648,21 @@ 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 is + Specifically in PTP, this requirement implies that if a slave 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 @@ -697,22 +697,21 @@ 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, and hence this requirement is a - SHOULD. + serving the unauthorized clock, and hence this requirement is a MAY. 5.1.4. PTP: Authentication and Authorization of PTP 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 @@ -793,22 +792,22 @@ 5.2. Protocol Packet 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 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 @@ -822,22 +821,22 @@ 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 in this subsection addresses the packet 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 @@ -1086,24 +1085,27 @@ The security mechanism SHOULD 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 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. + 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.), and 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. @@ -1201,21 +1203,21 @@ +-----------+---------------------------------------------+--------+ | Section | Requirement | Type | +-----------+---------------------------------------------+--------+ | 5.1. | Authentication & authorization of sender. | MUST | | +---------------------------------------------+--------+ | | Authentication & authorization of master. | MUST | | +---------------------------------------------+--------+ | | Recursive authentication & authorization. | MUST | | +---------------------------------------------+--------+ - | | Authentication of slaves. | MAY | + | | Authentication & authorization 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 | @@ -1312,24 +1314,24 @@ 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, all - 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. + 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 there is a large number of nodes that possess the security keys. 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.