--- 1/draft-ietf-tictoc-security-requirements-07.txt 2014-04-30 01:14:20.818633999 -0700 +++ 2/draft-ietf-tictoc-security-requirements-08.txt 2014-04-30 01:14:20.878635469 -0700 @@ -1,18 +1,18 @@ TICTOC Working Group Tal Mizrahi Internet Draft Marvell Intended status: Informational -Expires: October 2014 April 23, 2014 +Expires: October 2014 April 30, 2014 Security Requirements of Time Protocols in Packet Switched Networks - draft-ietf-tictoc-security-requirements-07.txt + draft-ietf-tictoc-security-requirements-08.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 23, 2014. + This Internet-Draft will expire on October 30, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -89,49 +89,50 @@ (Chain of Trust) ......................................... 15 5.1.3. Authentication and Authorization of Slaves ........ 15 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 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 ..................................... 26 - 7. Additional security implications ............................ 28 - 7.1. Security and on-the-fly Timestamping ................... 28 - 7.2. PTP: Security and Two-Step Timestamping ................ 28 - 7.3. Intermediate Clocks .................................... 29 - 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 ................... 30 + 5.3. Spoofing Prevention .................................... 20 + 5.4. Availability ........................................... 20 + 5.5. Replay Protection ...................................... 21 + 5.6. Cryptographic Keys and Security Associations ........... 22 + 5.6.1. Key Freshness ..................................... 22 + 5.6.2. Security Association .............................. 22 + 5.6.3. Unicast and Multicast Associations ................ 23 + 5.7. Performance ............................................ 23 + 5.8. Confidentiality......................................... 24 + 5.9. Protection against Packet Delay and Interception Attacks 25 + 5.10. Combining Secured with Unsecured Nodes ................ 25 + 5.10.1. Secure Mode ...................................... 26 + 5.10.2. Hybrid Mode ...................................... 26 + 6. Summary of Requirements ..................................... 27 + 7. Additional security implications ............................ 29 + 7.1. Security and on-the-fly Timestamping ................... 29 + 7.2. PTP: Security and Two-Step Timestamping ................ 29 + 7.3. Intermediate Clocks .................................... 30 + 7.4. External Security Protocols and Time Protocols.......... 30 + 7.5. External Security Services Requiring Time .............. 31 + 7.5.1. Timestamped Certificates .......................... 31 + 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 - 12.1. Normative References .................................. 31 + 9. Security Considerations ..................................... 32 + 10. IANA Considerations......................................... 32 + 11. Acknowledgments ............................................ 32 + 12. References ................................................. 32 + 12.1. Normative References .................................. 32 12.2. Informative References ................................ 32 - 13. Contributing Authors ....................................... 33 + 13. Contributing Authors ....................................... 34 1. Introduction As time protocols are becoming increasingly common and widely deployed, concern about the resulting exposure to various security threats is increasing. If a time protocol is compromised, the applications it serves are prone to a range of possible attacks including Denial-of-Service (DoS) or incorrect behavior. This document focuses on the security aspects of the Precision Time @@ -673,89 +674,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 MUST provide a means for a master to + The security mechanism MAY provide a means for a master to authenticate its slaves. Requirement The security mechanism MAY provide a means for a master to verify that the sender of a protocol packet is authorized to send a packet of this type. Requirement Level - The 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'. + The requirement in this subsection prevents DoS attacks against the + master (Section 3.2.9.). - 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'. + 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. + + 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'. Discussion Slaves and intermediate clocks are authenticated by masters in order - to verify their identity, thus preventing attackers from sending - unauthorized protocol packets to the master, and preventing - unauthorized clocks from receiving time services. + to verify that they are authorized to receive timing services from + the master. - 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. + 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. 5.1.4. PTP: Authentication and Authorization of P2P TCs by the Master Requirement - The security mechanism for PTP MUST 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 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 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. + 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, 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. + Authentication of TCs, much like authentication of slaves, reduces + unnecessary load on the master and peer TCs, by preventing the master + from serving unauthorized clocks. 5.1.5. PTP: Authentication and Authorization of Control Messages Requirement The security mechanism for PTP MUST support authentication of Announce messages. The authentication mechanism MUST also verify that the sender is authorized to be a master. Requirement @@ -865,21 +866,62 @@ protection mechanism is used specifically for the correctionField. The end-to-end approach limits the TC's impact to the correctionField alone, while the rest of the protocol packet is protected on an end- to-end basis. It should be noted that this approach is more difficult to implement than the hop-by-hop approach, as it requires the correctionField to be protected separately from the other fields of the packet, possibly using different cryptographic mechanisms and keys. -5.3. Availability +5.3. Spoofing Prevention + +Requirement + + The security mechanism MUST provide a means to prevent master + spoofing. + +Requirement + + The security mechanism MUST provide a means to prevent slave + spoofing. + +Requirement + + PTP: The security mechanism MUST provide a means to prevent P2P TC + spoofing. + +Requirement Level + + The requirements in this subsection address spoofing attacks (Section + 3.2.2.). As described in Section 3.2.2. , when these requirements + are not met, the attack may have a high impact, causing slaves to + rely on false time information. Thus, the requirement level is + 'MUST'. + +Discussion + + Spoofing attacks may take various different forms, and can + potentially cause significant impact. In a master spoofing attack, + the attacker causes slaves to receive false information about the + current time by masquerading as the master. + + By spoofing a slave or an intermediate node (the second example of + Section 3.2.2.), an attacker can tamper with slaves' delay + computations. These attacks can be mitigated by an authentication + mechanism (Section 5.1.3. and 5.1.4.), or by other means, for + example, a PTP Delay_Req can include a Message Authentication Code + (MAC) that is included in the corresponding Delay_Resp message, + allowing the slave to verify that the Delay_Resp was not sent in + response to a spoofed message. + +5.4. Availability Requirement The security mechanism SHOULD include measures to mitigate DoS attacks against the time protocol. Requirement Level The requirement in this subsection prevents DoS attacks against the protocol (Section 3.2.9.). @@ -896,21 +938,21 @@ 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 +5.5. Replay Protection Requirement The security mechanism MUST include a replay prevention mechanism. Requirement Level The requirement in this subsection prevents replay attacks (Section 3.2.3.). @@ -912,46 +954,47 @@ Requirement Level The requirement in this subsection prevents replay attacks (Section 3.2.3.). The requirement level of this requirement is 'MUST' since in the absence of this requirement the protocol is exposed to attacks that are easy to implement and have a high impact. Discussion + The replay attack (Section 3.2.3.) can compromise both the integrity and availability of the protocol. Common encryption and authentication mechanisms include replay prevention mechanisms that typically use a monotonously increasing packet sequence number. -5.5. Cryptographic Keys and Security Associations +5.6. Cryptographic Keys and Security Associations -5.5.1. Key Freshness +5.6.1. Key Freshness Requirement The cryptographic keys MUST be refreshed frequently. Requirement Level The requirement level of this requirement is 'MUST' since key freshness is an essential property for cryptographic algorithms, as discussed below. Discussion Key freshness guarantees that both sides share a common updated secret key. It also helps in preventing replay attacks. Thus, it is important for keys to be refreshed frequently. -5.5.2. Security Association +5.6.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 @@ -958,44 +1001,45 @@ 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 Section 5.1. and Section 5.2. require usage of cryptographic mechanisms, deploying cryptographic keys. A security association is an important building block in these mechanisms. -5.5.3. Unicast and Multicast Associations +5.6.3. Unicast and Multicast Associations Requirement The security mechanism SHOULD support security association protocols for unicast and for multicast associations. Requirement Level The requirement level of this requirement is 'SHOULD' since it may be expensive in terms of performance, especially for low-cost clocks. Discussion A unicast protocol requires an association protocol between two clocks, whereas a multicast protocol requires an association protocol among two or more clocks, where one of the clocks is a master. -5.6. Performance +5.7. Performance Requirement The security mechanism MUST be designed in such a way that it does not significantly degrade the quality of the time transfer. Requirement The mechanism SHOULD minimize computational load. @@ -1023,21 +1067,21 @@ Note that the performance requirements refer to a time-protocol- specific security mechanism. In systems where a security protocol is used for other types of traffic as well, this document does not place any performance requirements on the security protocol performance. For example, if IPsec encryption is used for securing all information between the master and slave node, including information that is not part of the time protocol, the requirements in this subsection are not necessarily applicable. -5.7. Confidentiality +5.8. Confidentiality Requirement The security mechanism MAY provide confidentiality protection of the protocol packets. Requirement Level The requirement level of this requirement is 'MAY' since it does not prevent severe threats, as discussed below. @@ -1058,21 +1102,21 @@ protocol packets. Thus, confidentiality can assist in protecting the timing protocol against MITM attacks such as packet delay (Section 3.2.6.), manipulation and interception and removal attacks. Note, that time protocols have predictable behavior even after encryption, such as packet transmission rates and packet lengths. Additional measures can be taken to mitigate encrypted traffic analysis by random padding of encrypted packets and by adding random dummy packets. Nevertheless, encryption does not prevent such MITM attacks, but rather makes these attacks more difficult to implement. -5.8. Protection against Packet Delay and Interception Attacks +5.9. Protection against Packet Delay and Interception Attacks Requirement The security mechanism MUST include means to protect the protocol from MITM attacks that degrade the clock accuracy. Requirement Level The requirements in this subsection address MITM attacks such as the packet delay attack (Section 3.2.6.) and packet interception attacks @@ -1097,61 +1141,61 @@ indicates a time value that is significantly different than the other sources, it is assumed to be erroneous or under attack, and is therefore ignored. Thus, MITM attack prevention derives a requirement from the security mechanism, and a requirement from the network topology. While the security mechanism should support the ability to detect delay attacks, it is noted that in some networks it is not possible to provide the redundancy needed for such a detection mechanism. -5.9. Combining Secured with Unsecured Nodes +5.10. Combining Secured with Unsecured Nodes Integrating a security mechanism into a time synchronized system is a complex and expensive process, and hence in some cases may require incremental deployment, where new equipment supports the security mechanism, and is required to interoperate with legacy equipment without the security features. -5.9.1. Secure Mode +5.10.1. Secure Mode Requirement The security mechanism MUST support a secure mode, where only secured clocks are permitted to take part in the time protocol. In this mode every protocol packet received from an unsecured clock MUST be discarded. Requirement Level The requirement level of this requirement is 'MUST' since the full capacity of the security requirements defined in this document can only be achieved in secure mode. Discussion While the requirement in this subsection is similar to the one in 5.1. , it refers to the secure mode, as opposed to the hybrid mode presented in the next subsection. -5.9.2. Hybrid Mode +5.10.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. + deploy the 'Secure Mode' described in Section 5.10.1. where possible. Discussion The hybrid mode allows both secured and unsecured clocks to take part in the time protocol. NTP, for example, allows a mixture of secured and unsecured nodes. Requirement A master in the hybrid mode SHOULD be a secured clock. @@ -1191,65 +1235,64 @@ +-----------+---------------------------------------------+--------+ | Section | Requirement | Type | +-----------+---------------------------------------------+--------+ | 5.1. | Authentication & authorization of sender. | MUST | | +---------------------------------------------+--------+ | | Authentication & authorization of master. | MUST | | +---------------------------------------------+--------+ | | Recursive authentication & authorization. | MUST | | +---------------------------------------------+--------+ - | | Authentication of slaves. | MUST | - | +---------------------------------------------+--------+ - | | Authorization of slaves. | MAY | - | +---------------------------------------------+--------+ - | | PTP: Authentication of P2P TCs by master. | MUST | + | | Authentication & authorization of slaves. | MAY | | +---------------------------------------------+--------+ - | | PTP: Authorization of P2P TCs by master. | MAY | + | | PTP: Authentication & authorization of | MAY | + | | P2P TCs by master. | | | +---------------------------------------------+--------+ | | PTP: Authentication & authorization of | MUST | | | Announce messages. | | | +---------------------------------------------+--------+ | | PTP: Authentication & authorization of | MUST | | | Management messages. | | | +---------------------------------------------+--------+ | | PTP: Authentication & authorization of | MAY | | | Signaling messages. | | +-----------+---------------------------------------------+--------+ | 5.2. | Integrity protection. | MUST | +-----------+---------------------------------------------+--------+ - | 5.3. | Protection from DoS attacks against the | SHOULD | + | 5.3. | Spoofing prevention. | MUST | + +-----------+---------------------------------------------+--------+ + | 5.4. | Protection from DoS attacks against the | SHOULD | | | time protocol. | | +-----------+---------------------------------------------+--------+ - | 5.4. | Replay protection. | MUST | + | 5.5. | Replay protection. | MUST | +-----------+---------------------------------------------+--------+ - | 5.5. | Key freshness. | MUST | + | 5.6. | Key freshness. | MUST | | +---------------------------------------------+--------+ | | Security association. | SHOULD | | +---------------------------------------------+--------+ | | Unicast and multicast associations. | SHOULD | +-----------+---------------------------------------------+--------+ - | 5.6. | Performance: no degradation in quality of | MUST | + | 5.7. | 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. | Confidentiality protection. | MAY | +-----------+---------------------------------------------+--------+ - | 5.8. | Protection against delay and interception | MUST | + | 5.9. | Protection against delay and interception | MUST | | | attacks. | | +-----------+---------------------------------------------+--------+ - | 5.9. | Secure mode. | MUST | + | 5.10. | Secure mode. | MUST | | +---------------------------------------------+--------+ | | Hybrid mode. | MAY | +-----------+---------------------------------------------+--------+ Table 2 Summary of Security Requirements 7. Additional security implications This section discusses additional implications of the interaction between time protocols and security mechanisms.