draft-ietf-tictoc-security-requirements-10.txt   draft-ietf-tictoc-security-requirements-11.txt 
TICTOC Working Group Tal Mizrahi TICTOC Working Group T. Mizrahi
Internet Draft Marvell Internet Draft Marvell
Intended status: Informational Intended status: Informational
Expires: January 2015 July 2, 2014 Expires: January 2015 July 21, 2014
Security Requirements of Time Protocols Security Requirements of Time Protocols
in Packet Switched Networks in Packet Switched Networks
draft-ietf-tictoc-security-requirements-10.txt draft-ietf-tictoc-security-requirements-11.txt
Abstract Abstract
As time and frequency distribution protocols are becoming As time and frequency distribution protocols are becoming
increasingly common and widely deployed, concern about their exposure increasingly common and widely deployed, concern about their exposure
to various security threats is increasing. This document defines a to various security threats is increasing. This document defines a
set of security requirements for time protocols, focusing on the set of security requirements for time protocols, focusing on the
Precision Time Protocol (PTP) and the Network Time Protocol (NTP). Precision Time Protocol (PTP) and the Network Time Protocol (NTP).
This document also discusses the security impacts of time protocol This document also discusses the security impacts of time protocol
practices, the performance implications of external security practices, the performance implications of external security
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2015. This Internet-Draft will expire on January 21, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 18 skipping to change at page 3, line 18
5.2. Protocol Packet Integrity .............................. 19 5.2. Protocol Packet Integrity .............................. 19
5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 19 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.1. Hop-by-Hop Integrity Protection .............. 19
5.2.1.2. End-to-End Integrity Protection .............. 20 5.2.1.2. End-to-End Integrity Protection .............. 20
5.3. Spoofing Prevention .................................... 20 5.3. Spoofing Prevention .................................... 20
5.4. Availability ........................................... 21 5.4. Availability ........................................... 21
5.5. Replay Protection ...................................... 22 5.5. Replay Protection ...................................... 22
5.6. Cryptographic Keys and Security Associations ........... 22 5.6. Cryptographic Keys and Security Associations ........... 22
5.6.1. Key Freshness ..................................... 22 5.6.1. Key Freshness ..................................... 22
5.6.2. Security Association .............................. 23 5.6.2. Security Association .............................. 23
5.6.3. Unicast and Multicast Associations ................ 23 5.6.3. Unicast and Multicast Associations ................ 24
5.7. Performance ............................................ 24 5.7. Performance ............................................ 24
5.8. Confidentiality......................................... 25 5.8. Confidentiality......................................... 25
5.9. Protection against Packet Delay and Interception Attacks 25 5.9. Protection against Packet Delay and Interception Attacks 26
5.10. Combining Secured with Unsecured Nodes ................ 26 5.10. Combining Secured with Unsecured Nodes ................ 27
5.10.1. Secure Mode ...................................... 26 5.10.1. Secure Mode ...................................... 27
5.10.2. Hybrid Mode ...................................... 27 5.10.2. Hybrid Mode ...................................... 27
6. Summary of Requirements ..................................... 28 6. Summary of Requirements ..................................... 28
7. Additional security implications ............................ 30 7. Additional security implications ............................ 30
7.1. Security and on-the-fly Timestamping ................... 30 7.1. Security and on-the-fly Timestamping ................... 30
7.2. PTP: Security and Two-Step Timestamping ................ 30 7.2. PTP: Security and Two-Step Timestamping ................ 30
7.3. Intermediate Clocks .................................... 31 7.3. Intermediate Clocks .................................... 31
7.4. External Security Protocols and Time Protocols.......... 31 7.4. External Security Protocols and Time Protocols.......... 32
7.5. External Security Services Requiring Time .............. 32 7.5. External Security Services Requiring Time .............. 32
7.5.1. Timestamped Certificates .......................... 32 7.5.1. Timestamped Certificates .......................... 32
7.5.2. Time Changes and Replay Attacks ................... 32 7.5.2. Time Changes and Replay Attacks ................... 33
8. Issues for Further Discussion ............................... 32 8. Issues for Further Discussion ............................... 33
9. Security Considerations ..................................... 33 9. Security Considerations ..................................... 33
10. IANA Considerations......................................... 33 10. IANA Considerations......................................... 33
11. Acknowledgments ............................................ 33 11. Acknowledgments ............................................ 33
12. References ................................................. 33 12. References ................................................. 33
12.1. Normative References .................................. 33 12.1. Normative References .................................. 33
12.2. Informative References ................................ 33 12.2. Informative References ................................ 34
13. Contributing Authors ....................................... 35 13. Contributing Authors ....................................... 35
1. Introduction 1. Introduction
As time protocols are becoming increasingly common and widely As time protocols are becoming increasingly common and widely
deployed, concern about the resulting exposure to various security deployed, concern about the resulting exposure to various security
threats is increasing. If a time protocol is compromised, the threats is increasing. If a time protocol is compromised, the
applications it serves are prone to a range of possible attacks applications it serves are prone to a range of possible attacks
including Denial-of-Service (DoS) or incorrect behavior. including Denial-of-Service (DoS) or incorrect behavior.
skipping to change at page 8, line 12 skipping to change at page 8, line 12
network, or possess the encryption or authentication keys. An network, or possess the encryption or authentication keys. An
internal attack can also be performed by exploiting vulnerabilities internal attack can also be performed by exploiting vulnerabilities
in devices; for example, by installing malware, or obtaining in devices; for example, by installing malware, or obtaining
credentials to reconfigure the device. Thus, an internal attacker can credentials to reconfigure the device. Thus, an internal attacker can
maliciously tamper with legitimate traffic in the network, as well as maliciously tamper with legitimate traffic in the network, as well as
generate its own traffic and make it appear legitimate to its generate its own traffic and make it appear legitimate to its
attacked nodes. attacked nodes.
Note that internal attacks are a special case of Byzantine failures, Note that internal attacks are a special case of Byzantine failures,
where a node in the system may fail in arbitrary ways; by crashing, where a node in the system may fail in arbitrary ways; by crashing,
by ommitting messages, or by malicious behavior. This document by omitting messages, or by malicious behavior. This document focuses
focuses on nodes that demonstrate malicous behavior. on nodes that demonstrate malicious behavior.
External attackers, on the other hand, do not have the keys, and have External attackers, on the other hand, do not have the keys, and have
access only to the encrypted or authenticated traffic. access only to the encrypted or authenticated traffic.
Obviously, in the absence of a security mechanism there is no Obviously, in the absence of a security mechanism there is no
distinction between internal and external attackers, since all distinction between internal and external attackers, since all
attackers are internal in practice. attackers are internal in practice.
3.1.2. Man in the Middle (MITM) vs. Packet Injector 3.1.2. Man in the Middle (MITM) vs. Packet Injector
skipping to change at page 19, line 35 skipping to change at page 19, line 35
are easy to implement and have high impact. are easy to implement and have high impact.
Discussion Discussion
While Section 5.1. refers to ensuring the identity an authorization While Section 5.1. refers to ensuring the identity an authorization
of the source of a protocol packet, this subsection refers to of the source of a protocol packet, this subsection refers to
ensuring that the packet arrived intact. The integrity protection ensuring that the packet arrived intact. The integrity protection
mechanism ensures the authenticity and completeness of data from the mechanism ensures the authenticity and completeness of data from the
data originator. data originator.
Integrity protection is typically impelmented by means of an Integrity protection is typically implemented by means of an
Integrity Check Value (ICV) that is included in protocol packets and Integrity Check Value (ICV) that is included in protocol packets and
is verified by the receiver. is verified by the receiver.
5.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
Specifically in PTP, when protocol packets are subject to Specifically in PTP, when protocol packets are subject to
modification by TCs, the integrity protection can be enforced in one modification by TCs, the integrity protection can be enforced in one
of two approaches, end-to-end or hop-by-hop. of two approaches, end-to-end or hop-by-hop.
5.2.1.1. Hop-by-Hop Integrity Protection 5.2.1.1. Hop-by-Hop Integrity Protection
skipping to change at page 21, line 23 skipping to change at page 21, line 23
'MUST'. 'MUST'.
Discussion Discussion
Spoofing attacks may take various different forms, and can Spoofing attacks may take various different forms, and can
potentially cause significant impact. In a master spoofing attack, potentially cause significant impact. In a master spoofing attack,
the attacker causes slaves to receive false information about the the attacker causes slaves to receive false information about the
current time by masquerading as the master. current time by masquerading as the master.
By spoofing a slave or an intermediate node (the second example of By spoofing a slave or an intermediate node (the second example of
Section 3.2.2.), an attacker can tamper with slaves' delay Section 3.2.2.), an attacker can tamper with the slaves' delay
computations. These attacks can be mitigated by an authentication computations. These attacks can be mitigated by an authentication
mechanism (Section 5.1.3. and 5.1.4.), or by other means, for 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 example, a PTP Delay_Req can include a Message Authentication Code
(MAC) that is included in the corresponding Delay_Resp message, (MAC) that is included in the corresponding Delay_Resp message,
allowing the slave to verify that the Delay_Resp was not sent in allowing the slave to verify that the Delay_Resp was not sent in
response to a spoofed message. response to a spoofed message.
5.4. Availability 5.4. Availability
Requirement Requirement
skipping to change at page 21, line 50 skipping to change at page 21, line 50
The requirement in this subsection prevents DoS attacks against the The requirement in this subsection prevents DoS attacks against the
protocol (Section 3.2.9.). protocol (Section 3.2.9.).
The requirement level of this requirement is 'SHOULD' due to its low 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 impact, i.e., in the absence of this requirement the protocol is only
exposed to DoS. exposed to DoS.
Discussion Discussion
The protocol availability can be compromised by several different The protocol availability can be compromised by several different
attacks. attacks. An attacker can inject protocol packets to implement the
spoofing attack (Section 3.2.2.) or the rogue master attack (Section
3.2.4.), causing DoS to the victim (Section 3.2.9.).
An attacker can inject protocol packets to implement the spoofing An authentication mechanism (Section 5.1.) limits these attacks
attack (Section 3.2.2.) or the rogue master attack (Section 3.2.4. strictly to internal attackers, and thus prevents external attackers
), causing DoS to the victim (Section 3.2.9.). An authentication from performing them. Hence, the requirements of Section 5.1. can be
mechanism (Section 5.1.) limits these attacks strictly to internal used to mitigate this attack. Note, that Section 5.1. addresses a
attackers, and thus prevents external attackers from performing them. wider range of threats, whereas the current section is focused on
availability.
The DoS attacks described in Section 3.2.7. are performed at lower 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 layers than the time protocol layer, and are thus outside the scope
of the security requirements defined in this document. of the security requirements defined in this document.
5.5. Replay Protection 5.5. Replay Protection
Requirement Requirement
The security mechanism MUST include a replay prevention mechanism. The security mechanism MUST include a replay prevention mechanism.
skipping to change at page 22, line 46 skipping to change at page 23, line 4
5.6. Cryptographic Keys and Security Associations 5.6. Cryptographic Keys and Security Associations
5.6.1. Key Freshness 5.6.1. Key Freshness
Requirement Requirement
The cryptographic keys MUST be refreshed frequently. The cryptographic keys MUST be refreshed frequently.
Requirement Level Requirement Level
The requirement level of this requirement is 'MUST' since key The requirement level of this requirement is 'MUST' since key
freshness is an essential property for cryptographic algorithms, as freshness is an essential property for cryptographic algorithms, as
discussed below. discussed below.
Discussion Discussion
Key freshness guarantees that both sides share a common updated Key freshness guarantees that both sides share a common updated
secret key. It also helps in preventing replay attacks. Thus, it is secret key. It also helps in preventing replay attacks. Thus, it is
important for keys to be refreshed frequently. important for keys to be refreshed frequently. Note that the term
'frequently' is used without a quantitative requirement, as the
precise frequency requirement should be considered on a per-system
basis, based on the threats and system requirements.
5.6.2. Security Association 5.6.2. Security Association
Requirement Requirement
The security protocol SHOULD support an association protocol where: The security protocol SHOULD support a security association protocol
where:
o Two or more clocks authenticate each other. o Two or more clocks authenticate each other.
o The clocks generate and agree on a cryptographic session key. o The clocks generate and agree on a cryptographic session key.
Requirement Requirement
Each instance of the association protocol SHOULD produce a different Each instance of the association protocol SHOULD produce a different
session key. session key.
Requirement Level Requirement Level
The requirement level of this requirement is 'SHOULD' since it may be The requirement level of this requirement is 'SHOULD' since it may be
expensive in terms of performance, especially in low-cost clocks. expensive in terms of performance, especially in low-cost clocks.
Discussion Discussion
The security requirements in Section 5.1. and Section 5.2. require The security requirements in Section 5.1. and Section 5.2. require
usage of cryptographic mechanisms, deploying cryptographic keys. A usage of cryptographic mechanisms, deploying cryptographic keys. A
security association is an important building block in these security association (e.g., [IPsec]) is an important building block
mechanisms. in these mechanisms.
It should be noted that in some cases different security association It should be noted that in some cases different security association
mechanisms may be used at different levels of clock hierarchies. For mechanisms may be used at different levels of clock hierarchies. For
example, the association between a Stratum 2 clock and a Stratum 3 example, the association between a Stratum 2 clock and a Stratum 3
clock in NTP may have different characteristics than an association clock in NTP may have different characteristics than an association
between two clocks at the same stratum level. On a related note, in between two clocks at the same stratum level. On a related note, in
some cases a hybrid solution may be used, where a subset of the some cases a hybrid solution may be used, where a subset of the
network is not secured at all (see Section 5.10.2.). network is not secured at all (see Section 5.10.2.).
5.6.3. Unicast and Multicast Associations 5.6.3. Unicast and Multicast Associations
 End of changes. 19 change blocks. 
27 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/