--- 1/draft-ietf-tictoc-security-requirements-06.txt 2014-04-23 06:14:38.906325850 -0700 +++ 2/draft-ietf-tictoc-security-requirements-07.txt 2014-04-23 06:14:38.970327409 -0700 @@ -1,18 +1,18 @@ TICTOC Working Group Tal Mizrahi Internet Draft Marvell Intended status: Informational -Expires: April 2014 October 21, 2013 +Expires: October 2014 April 23, 2014 Security Requirements of Time Protocols in Packet Switched Networks - draft-ietf-tictoc-security-requirements-06.txt + draft-ietf-tictoc-security-requirements-07.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,25 +33,25 @@ 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 April 21, 2014. + This Internet-Draft will expire on October 23, 2014. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -65,65 +65,65 @@ 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 Manipulation ................................ 8 3.2.2. Spoofing ........................................... 8 - 3.2.3. Replay Attack ...................................... 8 - 3.2.4. Rogue Master Attack ................................ 8 + 3.2.3. Replay Attack ...................................... 9 + 3.2.4. Rogue Master Attack ................................ 9 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.8. Cryptographic Performance Attacks ................. 10 3.2.9. DoS Attacks against the Time Protocol ............. 10 3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud) . 10 3.3. Threat Analysis Summary ................................ 10 4. Requirement Levels .......................................... 12 - 5. Security Requirements ....................................... 12 + 5. Security Requirements ....................................... 13 5.1. Clock Identity Authentication and Authorization ........ 13 5.1.1. Authentication and Authorization of Masters ....... 14 5.1.2. Recursive Authentication and Authorization of Masters - (Chain of Trust) ......................................... 14 + (Chain of Trust) ......................................... 15 5.1.3. Authentication and Authorization of Slaves ........ 15 - 5.1.4. PTP: Authentication and Authorization of PTP TCs by the + 5.1.4. PTP: Authentication and Authorization of P2P TCs by the Master ................................................... 16 5.1.5. PTP: Authentication and Authorization of Control Messages ................................................. 17 5.2. Protocol Packet Integrity .............................. 18 - 5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 18 + 5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 19 5.2.1.1. Hop-by-Hop Integrity Protection .............. 19 5.2.1.2. End-to-End Integrity Protection .............. 19 5.3. Availability ........................................... 20 5.4. Replay Protection ...................................... 20 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 ..................................... 27 + 6. Summary of Requirements ..................................... 26 7. Additional security implications ............................ 28 7.1. Security and on-the-fly Timestamping ................... 28 - 7.2. PTP: Security and Two-Step Timestamping ................ 29 + 7.2. PTP: Security and Two-Step Timestamping ................ 28 7.3. Intermediate Clocks .................................... 29 - 7.4. External Security Protocols and Time Protocols.......... 30 + 7.4. External Security Protocols and Time Protocols.......... 29 7.5. External Security Services Requiring Time .............. 30 7.5.1. Timestamped Certificates .......................... 30 - 7.5.2. Time Changes and Replay Attacks ................... 31 + 7.5.2. Time Changes and Replay Attacks ................... 30 8. Issues for Further Discussion ............................... 31 9. Security Considerations ..................................... 31 10. IANA Considerations......................................... 31 11. Acknowledgments ............................................ 31 12. References ................................................. 31 12.1. Normative References .................................. 31 12.2. Informative References ................................ 32 13. Contributing Authors ....................................... 33 1. Introduction @@ -200,33 +200,35 @@ 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 with which every security mechanism should comply. 2.2. Abbreviations - BC Boundary Clock + BC Boundary Clock [IEEE1588] DoS Denial of Service MITM Man In The Middle - NTP Network Time Protocol + NTP Network Time Protocol [NTPv4] - OC Ordinary Clock + OC Ordinary Clock [IEEE1588] - PTP Precision Time Protocol + P2P TC Peer-to-Peer Transparent Clock [IEEE1588] - TC Transparent Clock + PTP Precision Time Protocol [IEEE1588] + + TC Transparent Clock [IEEE1588] 2.3. Common Terminology for PTP and NTP This document refers to both PTP and NTP. For the sake of consistency, throughout the document the term "master" applies to both a PTP master and an NTP server. Similarly, the term "slave" applies to both PTP slaves and NTP clients. The term "protocol packets" refers generically to PTP and NTP messages. 2.4. Terms used in this Document @@ -342,25 +344,35 @@ 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 manipulation, this can result in a situation where the time - protocol is apparently operational but providing intentionally - inaccurate information. + packets. Two typical examples of spoofing attacks: + + o An attacker can impersonate the master, allowing malicious + distribution of false timing information. + + o An attacker can impersonate a legitimate clock, a slave or an + intermediate clock, by sending malicious messages to the master, + causing the master to respond to the legitimate clock with + protocol packets that are based on the spoofed messages. + Consequently, the delay computations of the legitimate clock are + based on false information. + + As with packet manipulation, this attack can result in a situation + where the time protocol is apparently operational but providing + intentionally inaccurate information. 3.2.3. Replay Attack In a replay attack, an attacker records protocol packets and replays them at a later time without any modification. This can also result in a situation where the time protocol is apparently operational but providing intentionally inaccurate information. 3.2.4. Rogue Master Attack @@ -588,21 +601,21 @@ clocks, or a "black list" of clocks that should be denied service or revoked. It is noted that while the security mechanism is required to provide an authorization mechanism, the deployment of such a mechanism depends on the nature of the network. For example, a network that deploys PTP may consist of a set of identical OCs, where all clocks are equally permitted to be a master. In such a network an authorization mechanism may not be necessary. - The following subsections describe 4 distinct cases of clock + The following subsections describe 5 distinct cases of clock authentication. 5.1.1. Authentication and Authorization of Masters Requirement The security mechanism MUST support an authentication mechanism, allowing slaves to authenticate the identity of masters. Requirement @@ -659,90 +673,89 @@ 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 MAY provide a means for a master to + The security mechanism MUST provide a means for a master to authenticate its slaves. Requirement - The security mechanism MAY provide a means for a master to verify that the sender of a protocol packet is authorized to send a packet of this type. Requirement Level - The requirement in this subsection prevents DoS attacks against the - master (Section 3.2.9.). - - The requirement level of this requirement is 'MAY' since: - - o Its 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. + The authentication requirement in this subsection prevents DoS + attacks against the master (Section 3.2.9.), as well as spoofing + attacks (Section 3.2.2.). A spoofing attack, such as the second + example in Section 3.2.2. , is easy to implement and has a high + impact, and therefore the requirement level is 'MUST'. - Note that while the requirement level of this requirement is 'MAY', - the requirement in Section 5.1.1. is 'MUST'; the security mechanism - must provide a means for authentication and authorization, with an - emphasis on the master. Authentication and authorization of slaves is - specified in this subsection as 'MAY'. + The authorization requirement in this subsection only mitigates DoS + attacks against the master (Section 3.2.9.). The requirement level + is 'MAY', since the absence of this requirement has a relatively low + impact, i.e., in the absence of this requirement the protocol is only + exposed to DoS. Note that Section 5.1.1. specifies authorization as + a 'MUST', i.e., the security mechanism must provide a means for + authorization, with an emphasis on the master. Authentication and + authorization of slaves is specified in this subsection as 'MAY'. Discussion Slaves and intermediate clocks are authenticated by masters in order - to verify that they are authorized to receive timing services from - the master. + to verify their identity, thus preventing attackers from sending + unauthorized protocol packets to the master, and preventing + unauthorized clocks from receiving time services. - 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 MAY. + Note that the authentication of slaves might put a higher load on the + master than serving the unauthorized clock, and thus the decision of + whether to deploy slave authentication and/or authorization should be + based on the environment in which the master and slaves are deployed. -5.1.4. PTP: Authentication and Authorization of PTP TCs by the Master +5.1.4. PTP: Authentication and Authorization of P2P TCs by the Master Requirement - The security mechanism for PTP MAY provide a means for a master to + The security mechanism for PTP MUST provide a means for a master to authenticate the identity of the P2P TCs directly connected to it. Requirement The security mechanism for PTP MAY provide a means for a master to verify that P2P TCs directly connected to it are authorized to be TCs. Requirement Level + As in Section 5.1.3. , authentication and authorization can help in + preventing DoS attacks against the master (Section 3.2.9.). + Authentication also mitigates spoofing attacks (Section 3.2.2.). - 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. + The requirement levels of the authentication and authorization + requirements in this subsection are 'MUST' and 'MAY' respectively, + for the same reasons specified in Section 5.1.3. Discussion P2P TCs that are one hop from the master use the PDelay_Req and PDelay_Resp handshake to compute the link delay between the master and TC. These TCs are authenticated by the master. - Authentication of TCs, much like authentication of slaves, reduces - unnecessary load on the master and peer TCs, by preventing the master - from serving unauthorized clocks. + Authentication of TCs, much like authentication of slaves, prevents + external attackers from sending spoofed messages to the master, as + well as reduces unnecessary load on the master and peer TCs, by + preventing the master from serving unauthorized clocks. 5.1.5. PTP: Authentication and Authorization of Control Messages Requirement The security mechanism for PTP MUST support authentication of Announce messages. The authentication mechanism MUST also verify that the sender is authorized to be a master. Requirement @@ -809,45 +822,20 @@ Discussion While Section 5.1. refers to ensuring the identity an authorization of the source of a protocol packet, this subsection refers to ensuring that the packet arrived intact. The integrity protection mechanism ensures the authenticity and completeness of data from the data originator. 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 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. 5.2.1.1. Hop-by-Hop Integrity Protection Each hop that needs to modify a protocol packet: o Verifies its integrity. @@ -898,21 +886,21 @@ 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 + An attacker can inject protocol packets to implement the spoofing attack (Section 3.2.2.) or the rogue master attack (Section 3.2.4. ), causing DoS to the victim (Section 3.2.9.). An authentication mechanism (Section 5.1.) limits these attacks strictly to internal attackers, and thus prevents external attackers from performing them. The DoS attacks described in Section 3.2.7. are performed at lower layers than the time protocol layer, and are thus outside the scope of the security requirements defined in this document. 5.4. Replay Protection @@ -947,22 +934,22 @@ 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 for keys to be refreshed frequently. + secret key. It also helps in preventing replay attacks. Thus, it is + important for keys to be refreshed frequently. 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. @@ -1066,38 +1053,39 @@ encryption mechanism can prevent eavesdroppers from obtaining the service without payment. Note that these cases are, for now, rather esoteric. Confidentiality can also prevent an MITM attacker from identifying protocol packets. Thus, confidentiality can assist in protecting the timing protocol against MITM attacks such as packet delay (Section 3.2.6.), manipulation and interception and removal attacks. Note, that time protocols have predictable behavior even after encryption, such as packet transmission rates and packet lengths. Additional - 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. + measures can be taken to mitigate encrypted traffic analysis by + random padding of encrypted packets and by adding random dummy + packets. Nevertheless, encryption does not prevent such MITM attacks, + but rather makes these attacks more difficult to implement. 5.8. Protection against Packet Delay and Interception Attacks Requirement - The security mechanism SHOULD include means to protect the protocol + The security mechanism MUST include means to protect the protocol from MITM attacks that degrade the clock accuracy. Requirement Level The requirements in this subsection address MITM attacks such as the - 3.2.1.). + packet delay attack (Section 3.2.6.) and packet interception attacks + (Section 3.2.5. and Section 3.2.1.). - The requirement level of this requirement is 'SHOULD'. In the absence + The requirement level of this requirement is 'MUST'. In the absence of this requirement the protocol is exposed to attacks that are easy to implement and have a high impact. Note that in the absence of this requirement, the impact is similar to packet manipulation attacks (Section 3.2.1.), 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 @@ -1106,23 +1094,22 @@ note that common practices for protection against MITM attacks use redundant masters (e.g. [NTPv4]), or redundant paths between the master and slave (e.g. [DelayAtt]). If one of the time sources indicates a time value that is significantly different than the other sources, it is assumed to be erroneous or under attack, and is therefore ignored. Thus, MITM attack prevention derives a requirement from the security mechanism, and a requirement from the network topology. While the security mechanism should support the ability to detect delay - attacks, it is noted that in some networks it is not necessarily - possible to provide the redundancy needed for such a detection - mechanism. + attacks, it is noted that in some networks it is not possible to + provide the redundancy needed for such a detection mechanism. 5.9. Combining Secured with Unsecured Nodes Integrating a security mechanism into a time synchronized system is a complex and expensive process, and hence in some cases may require incremental deployment, where new equipment supports the security mechanism, and is required to interoperate with legacy equipment without the security features. 5.9.1. Secure Mode @@ -1203,61 +1191,62 @@ +-----------+---------------------------------------------+--------+ | Section | Requirement | Type | +-----------+---------------------------------------------+--------+ | 5.1. | Authentication & authorization of sender. | MUST | | +---------------------------------------------+--------+ | | Authentication & authorization of master. | MUST | | +---------------------------------------------+--------+ | | Recursive authentication & authorization. | MUST | | +---------------------------------------------+--------+ - | | Authentication & authorization of slaves. | MAY | + | | Authentication of slaves. | MUST | | +---------------------------------------------+--------+ - | | PTP: Authentication of TCs by master. | MAY | + | | Authorization of slaves. | MAY | + | +---------------------------------------------+--------+ + | | PTP: Authentication of P2P TCs by master. | MUST | + | +---------------------------------------------+--------+ + | | PTP: Authorization of P2P 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 | +-----------+---------------------------------------------+--------+ - | 5.3. | Protection against DoS attacks. | SHOULD | + | 5.3. | Protection from DoS attacks against the | SHOULD | + | | time protocol. | | +-----------+---------------------------------------------+--------+ | 5.4. | Replay protection. | MUST | +-----------+---------------------------------------------+--------+ | 5.5. | Key freshness. | MUST | | +---------------------------------------------+--------+ | | Security association. | SHOULD | | +---------------------------------------------+--------+ | | Unicast and multicast associations. | SHOULD | +-----------+---------------------------------------------+--------+ | 5.6. | Performance: no degradation in quality of | MUST | | | time transfer. | | | +---------------------------------------------+--------+ | | Performance: computation load. | SHOULD | | +---------------------------------------------+--------+ | | Performance: storage. | SHOULD | | +---------------------------------------------+--------+ | | Performance: bandwidth. | SHOULD | +-----------+---------------------------------------------+--------+ | 5.7. | Confidentiality protection. | MAY | +-----------+---------------------------------------------+--------+ - | 5.8. | Protection against delay and interception | SHOULD | + | 5.8. | Protection against delay and interception | MUST | | | attacks. | | +-----------+---------------------------------------------+--------+ | 5.9. | Secure mode. | MUST | | +---------------------------------------------+--------+ | | Hybrid mode. | MAY | +-----------+---------------------------------------------+--------+ Table 2 Summary of Security Requirements 7. Additional security implications @@ -1279,21 +1268,21 @@ integrity protection: o During transmission the encryption and/or integrity protection MUST be applied after integrating the timestamp into the packet. To allow high accuracy, timestamping is typically performed as close to the transmission or reception time as possible. However, since the security engine must be placed between the timestamping function and the physical interface, it may introduce non-deterministic latency that causes accuracy degradation. These performance aspects have been - analyzed in the literature, e.g., in [1588IPsec] and [Tunnel]. + analyzed in literature, e.g., [1588IPsec] and [Tunnel]. 7.2. PTP: Security and Two-Step Timestamping PTP supports a two-step mode of operation, where the time of transmission of protocol packets is communicated without modifying the packets. As opposed to one-step mode, two-step timestamping can be performed without the requirement to encrypt after timestamping. Note that if an encryption mechanism such as IPsec is used, it presents a challenge to the timestamping mechanism, since time @@ -1381,44 +1370,45 @@ dependence between the acquired time information, and the authentication protocol that secures it. This bootstrapping behavior results from the fact that trusting the received time information requires a valid certificate, and validating a certificate requires knowledge of the time. 7.5.2. Time Changes and Replay Attacks A successful attack on a time protocol may cause the attacked clocks to go back in time. The erroneous time may expose cryptographic - algorithms that rely on time to prevent replay attacks. + algorithms that rely on time, as a node may use a key that was + already used in the past and has expired. 8. Issues for Further Discussion The Key distribution is outside the scope of this document. Although this is an essential element of any security system, it is outside the scope of this document. 9. Security Considerations The security considerations of network timing protocols are presented throughout this document. 10. IANA Considerations There are no new IANA considerations implied by this document. 11. Acknowledgments The authors gratefully acknowledge Stefano Ruffini, Doug Arnold, - Kevin Gross, Dieter Sibold, Dan Grossman 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. + Kevin Gross, Dieter Sibold, Dan Grossman, Laurent Montini, Russell + Smiley, and Shawn Emery for their thorough review and helpful + comments. The authors would also like to thank members of the TICTOC + WG for providing feedback on the TICTOC mailing list. This document was prepared using 2-Word-v2.0.template.dot. 12. References 12.1. Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.