draft-ietf-tictoc-security-requirements-02.txt   draft-ietf-tictoc-security-requirements-03.txt 
TICTOC Working Group Tal Mizrahi TICTOC Working Group Tal Mizrahi
Internet Draft Marvell Internet Draft Marvell
Intended status: Informational Karen O'Donoghue Intended status: Informational
Expires: December 2012 ISOC Expires: March 2013 September 14, 2012
June 17, 2012
TICTOC Security Requirements TICTOC Security Requirements
draft-ietf-tictoc-security-requirements-02.txt draft-ietf-tictoc-security-requirements-03.txt
Abstract Abstract
As time synchronization protocols are becoming increasingly common As time synchronization protocols are becoming increasingly common
and widely deployed, concern about their exposure to various security and widely deployed, concern about their exposure to various security
threats is increasing. This document defines a set of requirements threats is increasing. This document defines a set of security
for security solutions for time synchronization protocols, focusing requirements for time synchronization protocols, focusing on the
on the IEEE 1588 and NTP. This document also discusses the security Precision Time Protocol (PTP) and the Network Time Protocol (NTP).
impacts of time synchronization protocol practices, the time This document also discusses the security impacts of time
synchronization performance implications of external security synchronization protocol practices, the time synchronization
practices, the dependencies between other security services and time performance implications of external security practices, the
dependencies between other security services and time
synchronization. synchronization.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
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 December 17, 2012. This Internet-Draft will expire on March 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ................................................. 3 1. Introduction ................................................. 3
2. Conventions Used in this Document ............................ 4 2. Conventions Used in this Document ............................ 4
2.1. Terminology ............................................. 4 2.1. Terminology ............................................. 4
2.2. Terms & Abbreviations ................................... 5 2.2. Terms & Abbreviations ................................... 5
3. Security Threats ............................................. 5 3. Security Threats ............................................. 5
3.1. Threat Model ............................................ 5 3.1. Threat Model ............................................ 5
3.1.1. Internal vs. External Attackers .................... 5 3.1.1. Internal vs. External Attackers .................... 6
3.1.2. Man in the Middle (MITM) vs. Packet Injector ....... 6 3.1.2. Man in the Middle (MITM) vs. Packet Injector ....... 6
3.2. Threat Analysis.......................................... 6 3.2. Threat Analysis.......................................... 6
3.2.1. Packet Interception and Manipulation ............... 6 3.2.1. Packet Interception and Manipulation ............... 6
3.2.2. Spoofing ........................................... 6 3.2.2. Spoofing ........................................... 6
3.2.3. Replay Attack ...................................... 6 3.2.3. Replay Attack ...................................... 7
3.2.4. Rogue Master Attack ................................ 6 3.2.4. Rogue Master Attack ................................ 7
3.2.5. Packet Interception and Removal .................... 7 3.2.5. Packet Interception and Removal .................... 7
3.2.6. Packet Delay Manipulation .......................... 7 3.2.6. Packet Delay Manipulation .......................... 7
3.2.7. Cryptographic Performance Attacks .................. 7 3.2.7. Cryptographic Performance Attacks .................. 7
3.2.8. L2/L3 DoS Attacks .................................. 7 3.2.8. L2/L3 DoS Attacks .................................. 8
3.2.9. Master Time Source Spoofing (e.g. GPS fraud) ....... 7 3.2.9. Master Time Source Spoofing (e.g. GPS fraud) ....... 8
3.3. Threat Analysis Summary ................................. 7 3.3. Threat Analysis Summary ................................. 8
4. Security Requirements ........................................ 9 4. Security Requirements ........................................ 9
4.1. Clock Identity Authentication ........................... 9 4.1. Clock Identity Authentication ........................... 9
4.1.1. Authentication of Masters .......................... 9 4.1.1. Authentication of Masters ......................... 10
4.1.2. Proventication of Masters .......................... 9 4.1.2. Recursive Authentication of Masters (Chain of Trust)10
4.1.3. Authentication of Slaves .......................... 10 4.1.3. Authentication of Slaves .......................... 11
4.1.4. PTP: Authentication of Transparent Clocks.......... 10 4.1.4. PTP: Authentication of Transparent Clocks.......... 11
4.1.5. PTP: Authentication of Announce Messages .......... 11 4.1.5. PTP: Authentication of Announce Messages .......... 11
4.2. Data integrity ......................................... 11 4.2. Data integrity ......................................... 12
4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 11 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.1. Hop by Hop Integrity Protection .............. 12
4.2.1.2. End to End Integrity Protection .............. 12 4.2.1.2. End to End Integrity Protection .............. 13
4.3. Availability ........................................... 12 4.3. Availability ........................................... 13
4.4. Replay Protection ...................................... 13 4.4. Replay Protection ...................................... 14
4.5. Cryptographic Keys & Security Associations ............. 13 4.5. Cryptographic Keys & Security Associations ............. 14
4.5.1. Security Association .............................. 13 4.5.1. Security Association .............................. 14
4.5.2. Unicast and Multicast ............................. 13 4.5.2. Unicast and Multicast ............................. 14
4.5.3. Key Freshness ..................................... 14 4.5.3. Key Freshness ..................................... 14
4.6. Performance ............................................ 14 4.6. Performance ............................................ 15
4.7. Confidentiality......................................... 14 4.7. Confidentiality......................................... 15
4.8. Protection against packet delay attacks ................ 15 4.8. Protection against packet delay attacks ................ 16
4.9. Combining Secured with Unsecured Nodes ................. 15 4.9. Combining Secured with Unsecured Nodes ................. 16
4.9.1. Secure Mode ....................................... 15 4.9.1. Secure Mode ....................................... 17
4.9.2. Hybrid Mode ....................................... 16 4.9.2. Hybrid Mode ....................................... 17
5. Summary of Requirements ..................................... 16 5. Summary of Requirements ..................................... 18
6. Additional security implications ............................ 18 6. Additional security implications ............................ 19
6.1. Security and on-the-fly Timestamping ................... 18 6.1. Security and on-the-fly Timestamping ................... 19
6.2. Security and Two-Step Timestamping ..................... 18 6.2. Security and Two-Step Timestamping ..................... 20
6.3. Intermediate Clocks .................................... 19 6.3. Intermediate Clocks .................................... 20
6.4. The Effect of External Security Protocols on Time 6.4. The Effect of External Security Protocols on Time
Synchronization ............................................. 19 Synchronization ............................................. 21
6.5. External Security Services Requiring Time Synchronization20 6.5. External Security Services Requiring Time Synchronization21
7. Issues for Further Discussion ............................... 20 7. Issues for Further Discussion ............................... 21
8. Security Considerations ..................................... 20 8. Security Considerations ..................................... 21
9. IANA Considerations ......................................... 20 9. IANA Considerations ......................................... 22
10. Acknowledgments ............................................ 20 10. Acknowledgments ............................................ 22
11. References ................................................. 21 11. References ................................................. 22
11.1. Normative References .................................. 21 11.1. Normative References .................................. 22
11.2. Informative References ................................ 21 11.2. Informative References ................................ 22
12. Contributing Authors ....................................... 24
1. Introduction 1. Introduction
As time synchronization protocols are becoming increasingly common As time synchronization protocols are becoming increasingly common
and widely deployed, concern about the resulting exposure to various and widely deployed, concern about the resulting exposure to various
security threats is increasing. If a time synchronization protocol is security threats is increasing. If a time synchronization protocol is
compromised, the applications it serves are prone to a range of 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 or incorrect behavior.
This document focuses on the security aspects of the Precision Time This document focuses on the security aspects of the Precision Time
Protocol ([IEEE 1588]) and the Network Time Protocol ([NTPv4]). The Protocol (PTP) [IEEE1588] and the Network Time Protocol [NTPv4]. The
Network Time Protocol was defined with an inherent security protocol, 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]. The IEEE 1588 includes an
experimental security protocol, defined in Annex K of the standard, experimental security protocol, defined in Annex K of the standard,
but this Annex was never formalized into a fully defined security but this Annex was never formalized into a fully defined security
protocol. 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.
This document attempts to add clarity to the time synchronization This document attempts to add clarity to the time synchronization
protocol security requirements discussion by addressing a series of protocol security requirements discussion by addressing a series of
questions. It is expected that this document will evolve into questions:
possibly two documents including one on requirements and one
providing clarity around the additional questions raised below. Until
the discussion has matured sufficiently, it will be captured in this
document. The four primary questions addressed by this draft include:
(1) What are the threats that need to be addressed for the time (1) What are the threats that need to be addressed for the time
synchronization protocol, and thus what security services need to be synchronization protocol, and thus what security services need to be
provided? (e.g. a malicious NTP server or PTP master) provided? (e.g. a malicious NTP server or PTP master)
(2) What external security practices impact the security and (2) What external security practices impact the security and
performance of time keeping, and what can be done to mitigate these 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 (3) What are the security impacts of time synchronization protocol
practices? (e.g. on-the-fly modification of timestamps) practices? (e.g. on-the-fly modification of timestamps)
(4) What are the dependencies between other security services and (4) What are the dependencies between other security services and
time synchronization? (e.g. which comes first - the certificate or time synchronization? (e.g. which comes first - the certificate or
the timestamp?) the timestamp?)
It is expected that the final version of this document will define a In light of the questions above, this document defines a set of
set of requirements for security solutions for time synchronization requirements for security solutions for time synchronization
protocols, focusing on the IEEE 1588 and NTP. protocols, focusing on PTP and NTP.
2. Conventions Used in this Document 2. Conventions Used in this Document
2.1. Terminology 2.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
This document describes security requirements, and thus requirements This document describes security requirements, and thus requirements
skipping to change at page 6, line 15 skipping to change at page 6, line 26
network, as well as generate its own traffic and make it appear network, as well as generate its own traffic and make it appear
legitimate to its attacked nodes. legitimate to its attacked nodes.
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
MITM attackers are located in a position that allows interception and MITM attackers are located in a position that allows interception and
modification of in-flight protocol packets, while a traffic injector modification of in-flight protocol packets.
cannot intercept legitimate packets, but can record them, replay old
messages, and generate its own traffic. 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.
3.2. Threat Analysis 3.2. Threat Analysis
3.2.1. Packet Interception and Manipulation 3.2.1. Packet Interception and Manipulation
A packet interception and manipulation attack results when a Man-In- A packet interception and manipulation attack results when a Man-In-
The-Middle (MITM) attacker intercepts timing protocol packets, alters The-Middle (MITM) attacker intercepts timing protocol packets, alters
them and relays them to their destination, allowing the attacker to them and relays them to their destination, allowing the attacker to
maliciously tamper with the protocol. This can result in a situation maliciously tamper with the protocol. This can result in a situation
where the time protocol is apparently operational but providing where the time protocol is apparently operational but providing
intentionally inaccurate information. intentionally inaccurate information.
3.2.2. Spoofing 3.2.2. Spoofing
In spoofing, an attacker masquerades as a legitimate node in the In spoofing, an attacker masquerades as a legitimate node in the
network. For example, an attacker can impersonate the master, network by generating and transmitting protocol packets. For example,
allowing malicious distribution of false timing information. As with an attacker can impersonate the master, allowing malicious
packet interception and manipulation, this can result in a situation distribution of false timing information. As with packet interception
where the time protocol is apparently operational but providing and manipulation, this can result in a situation where the time
intentionally inaccurate information. protocol is apparently operational but providing intentionally
inaccurate information.
3.2.3. Replay Attack 3.2.3. Replay Attack
In a replay attack, an attacker records protocol packets and replays In a replay attack, an attacker records protocol packets and replays
them at a later time. This can also result in a situation where the them at a later time without any modification. This can also result
time protocol is apparently operational but providing intentionally in a situation where the time protocol is apparently operational but
inaccurate information. providing intentionally inaccurate information.
3.2.4. Rogue Master Attack 3.2.4. Rogue Master Attack
In a rogue master attack, an attacker causes other nodes in the In a rogue master attack, an attacker causes other nodes in the
network to believe it is a legitimate master. As opposed to the network to believe it is a legitimate master. As opposed to the
spoofing attack, in the Rouge Master attack the attacker does not spoofing attack, in the Rouge Master attack the attacker does not
fake its identity, but rather manipulates the master election fake its identity, but rather manipulates the master election
process. For example, in PTP, an attacker can manipulate the Best process. For example, in PTP, an attacker can manipulate the Best
Master Clock Algorithm (BMCA), and cause other nodes in the network Master Clock Algorithm (BMCA), and cause other nodes in the network
to believe it is the most eligible candidate to be a grandmaster. to believe it is the most eligible candidate to be a grandmaster.
skipping to change at page 7, line 21 skipping to change at page 7, line 36
A packet interception and removal attack results when a Man-In-The- A packet interception and removal attack results when a Man-In-The-
Middle attacker intercepts and drops protocol packets, preventing the Middle attacker intercepts and drops protocol packets, preventing the
destination node from receiving the timing information. destination node from receiving the timing information.
3.2.6. Packet Delay Manipulation 3.2.6. Packet Delay Manipulation
In a packet delay manipulation scenario, a Man-In-The-Middle attacker In a packet delay manipulation scenario, a Man-In-The-Middle attacker
intercepts protocol packets, and relays them to their destination intercepts protocol packets, and relays them to their destination
after adding a maliciously computed delay. 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.
3.2.7. Cryptographic Performance Attacks 3.2.7. Cryptographic Performance Attacks
In cryptographic performance attacks, an attacker transmits fake In cryptographic performance attacks, an attacker transmits fake
protocol packet, causing high utilization of the cryptographic engine protocol packet, causing high utilization of the cryptographic engine
at the receiver, which attempts to verify the integrity of these fake at the receiver, which attempts to verify the integrity of these fake
packets. packets.
3.2.8. L2/L3 DoS Attacks 3.2.8. L2/L3 DoS Attacks
There are many possible Layer 2 and Layer 3 Denial of Service There are many possible Layer 2 and Layer 3 Denial of Service
skipping to change at page 8, line 12 skipping to change at page 8, line 34
attack, the table specifies its impact, and its applicability to each attack, the table specifies its impact, and its applicability to each
of the attacker types presented in 3.1. of the attacker types presented in 3.1.
The Impact column provides an intuition to the severity of each The Impact column provides an intuition to the severity of each
attack, and the relevant Attacker Type columns provide an intuition attack, and the relevant Attacker Type columns provide an intuition
about the how difficult each attack is to implement, and hence about about the how difficult each attack is to implement, and hence about
the likelihood of each attack. the likelihood of each attack.
The impact column in Table 1 can have one of 3 values: 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,
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 o False time - slaves align to a false time or frequency value due
to the attack. 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 o Accuracy degradation - the attack yields a degradation in the
slave accuracy, but does not completely compromise the slaves' slave accuracy, but does not completely compromise the slaves'
time and frequency. time and frequency.
o DoS - the attack causes a denial of service to the attacked node,
whose impact is not restricted to the time synchronization
protocol.
The Attacket Type columns refer to the 4 possible combinations of the The Attacket Type columns refer to the 4 possible combinations of the
attacker types defined in 3.1. attacker types defined in 3.1.
+-----------------------------+-------------------++-------------------+ +-----------------------------+-------------------++-------------------+
| Attack | Impact || Attacker Type | | Attack | Impact || Attacker Type |
| +-----+--------+----++---------+---------+ | +-----+--------+----++---------+---------+
| |False|Accuracy| ||Internal | Extenal | | |False|Accuracy| ||Internal | Extenal |
| |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.| | |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.|
+-----------------------------+-----+--------+----++----+----+----+----+ +-----------------------------+-----+--------+----++----+----+----+----+
|Interception and manipulation| + | | || + | | | | |Interception and manipulation| + | | || + | | | |
skipping to change at page 9, line 6 skipping to change at page 9, line 28
+-----------------------------+-----+--------+----++----+----+----+----+ +-----------------------------+-----+--------+----++----+----+----+----+
|Interception and Removal | | + | || + | | + | | |Interception and Removal | | + | || + | | + | |
+-----------------------------+-----+--------+----++----+----+----+----+ +-----------------------------+-----+--------+----++----+----+----+----+
|Packet delay manipulation | + | | || + | | + | | |Packet delay manipulation | + | | || + | | + | |
+-----------------------------+-----+--------+----++----+----+----+----+ +-----------------------------+-----+--------+----++----+----+----+----+
|Crypt. performance attacks | | | + || + | + | + | + | |Crypt. performance attacks | | | + || + | + | + | + |
+-----------------------------+-----+--------+----++----+----+----+----+ +-----------------------------+-----+--------+----++----+----+----+----+
|DoS attacks | | | + || + | + | + | + | |DoS attacks | | | + || + | + | + | + |
+-----------------------------+-----+--------+----++----+----+----+----+ +-----------------------------+-----+--------+----++----+----+----+----+
|Master Time source spoofing | + | | || + | + | + | + | |Master Time source spoofing | + | | || + | + | + | + |
|(e.g. GPS spoofing) | | | || | | | |
+-----------------------------+-----+--------+----++----+----+----+----+ +-----------------------------+-----+--------+----++----+----+----+----+
Table 1 Threat Analysis - Summary Table 1 Threat Analysis - Summary
4. Security Requirements 4. Security Requirements
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.1. Clock Identity Authentication 4.1. Clock Identity Authentication
Requirement Requirement
The security mechanism MUST provide a means for each clock to The security mechanism MUST provide a means for each clock to
authenticate the sender of a protocol packet. authenticate the sender of a protocol packet.
Discussion Discussion
In the context of this document, authentication refers to: In the context of this document, authentication refers to:
o Identification: verifying the identity of the peer clock. o Identification: verifying the identity of the peer clock.
o Authorization: verifying that the peer clock is permitted to play o Authorization: verifying that the peer clock is permitted to play
skipping to change at page 9, line 39 skipping to change at page 10, line 28
The following subsections describe 4 distinct cases of clock The following subsections describe 4 distinct cases of clock
authentication. authentication.
4.1.1. Authentication of Masters 4.1.1. Authentication of Masters
Requirement Requirement
The security mechanism MUST support an authentication mechanism, The security mechanism MUST support an authentication mechanism,
allowing slave clocks to authenticate the identity of master clocks. allowing slave clocks to authenticate the identity of master clocks.
4.1.2. Proventication of Masters 4.1.2. Recursive Authentication of Masters (Chain of Trust)
Requirement Requirement
The security mechanism MUST support a proventication mechanism, to be The security mechanism MUST support recursive authentication of the
used in cases where end-to-end authentication is not possible. master, to be used in cases where end-to-end authentication is not
possible.
Discussion Discussion
Slaves and transparent clocks authenticate masters in order to ensure Clocks authenticate masters in order to ensure the authenticity of
the authenticity of the time source. the time source.
In some cases a slave is connected to an intermediate master, that is In some cases a slave is connected to an intermediate master, that is
not the primary time source. For example, in PTP a slave can be 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 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 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 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 both the PTP and the NTP cases, the slave authenticates the
intermediate master, and the intermediate master authenticates the intermediate master, and the intermediate master authenticates the
primary master. This inductive authentication process is referred to primary master. This inductive authentication process is referred to
in [AutoKey] as proventication. in [AutoKey] as proventication.
skipping to change at page 10, line 31 skipping to change at page 11, line 21
Discussion Discussion
Slaves are authenticated by masters in order to verify that the slave Slaves are authenticated by masters in order to verify that the slave
is authorized to receive timing services from the master. is authorized to receive timing services from the master.
Authentication of slaves prevents unauthorized clocks from receiving Authentication of slaves prevents unauthorized clocks from receiving
time services, and also reduces unnecessary load on the master clock, time services, and also reduces unnecessary load on the master clock,
by preventing the master from serving unauthorized clocks. It could by preventing the master from serving unauthorized clocks. It could
be argued that the authentication of slaves could put a higher load be argued that the authentication of slaves could put a higher load
on the master then serving the unauthorized clock. This tradeoff will on the master then serving the unauthorized clock, and hence this
need to be discussed further. requirement is a SHOULD.
4.1.4. PTP: Authentication of Transparent Clocks 4.1.4. PTP: Authentication of Transparent Clocks
Requirement Requirement
The security mechanism for PTP SHOULD provide a means for a master to The security mechanism for PTP SHOULD provide a means for a master to
authenticate the TCs. authenticate the identity of the P2P TCs directly connected to it.
Discussion Discussion
Transparent clocks are authenticated by peer masters, slaves and TCs. 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 Authentication of TCs, much like authentication of slaves, reduces
unnecessary load on the master clock and peer TCs, by preventing the unnecessary load on the master clock and peer TCs, by preventing the
master from serving unauthorized clocks. It also prevents malicious master from serving unauthorized clocks.
TCs from attacking the protocol by manipulating the correctionField.
It could also be argued that the authentication could result in a
higher load then merely serving the unauthorized devices. This
tradeoff will need to be discussed further.
4.1.5. PTP: Authentication of Announce Messages 4.1.5. PTP: Authentication of Announce Messages
Requirement Requirement
The security mechanism for PTP MUST support authentication of The security mechanism for PTP MUST support authentication of
Announce messages. Announce messages.
Discussion Discussion
skipping to change at page 12, line 38 skipping to change at page 13, line 29
In this approach, the integrity protection is maintained on the path In this approach, the integrity protection is maintained on the path
from the originator of a protocol packet to the receiver. This allows from the originator of a protocol packet to the receiver. This allows
the receiver to validate the protocol packet without the ability of the receiver to validate the protocol packet without the ability of
intermediate TCs to manipulate the packet. intermediate TCs to manipulate the packet.
Since TCs need to modify the correctionField, a separate integrity Since TCs need to modify the correctionField, a separate integrity
protection mechanism is used specifically for the correctionField. protection mechanism is used specifically for the correctionField.
The end-to-end approach limits the TC's impact to 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- alone, while the rest of the protocol packet is protected on an end-
to-end basis. 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.
4.3. Availability 4.3. Availability
Requirement Requirement
The security mechanism MUST protect the time synchronization protocol The security mechanism MUST protect the time synchronization protocol
from DoS attacks by external attackers. from DoS attacks by external attackers.
Discussion Discussion
The protocol availability can be compromised by several different The protocol availability can be compromised by several different
attacks. An attacker can inject protocol messages to implement the attacks. An attacker can inject protocol messages to implement the
spoofing attack (3.2.2. ) or the rogue master attack (3.2.4. ), spoofing attack (Section 3.2.2. ) or the rogue master attack (Section
causing denial of service to the attackee. An authentication 3.2.4. ), causing denial of service to the attackee. An
mechanism (4.1. ) limits these attacks strictly to internal authentication mechanism (Section 4.1. ) limits these attacks
attackers, and thus prevents external attackers from performing them. strictly to internal attackers, and thus prevents external attackers
from performing them.
DoS attacks at lower layers of the protocol stack (3.2.8. ) can still Note that a security mechanism applied at the time synchronization
be implemented by external attackers even in the presence of an layer cannot, by itself, prevent DoS attacks described in Section
authentication mechanism. 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.
4.4. Replay Protection 4.4. Replay Protection
Requirement Requirement
Protocol messages MUST be resistant to replay attacks. Protocol messages MUST be resistant to replay attacks.
4.5. Cryptographic Keys & Security Associations 4.5. Cryptographic Keys & Security Associations
4.5.1. Security Association 4.5.1. Security Association
Requirement Requirement
The security protocol MUST support an association protocol where: The security protocol SHOULD support an 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.
Discussion Discussion
The security requirements in 4.1. and 4.2. require usage of The security requirements in 4.1. and 4.2. require usage of
cryptographich mechanisms, deploying cryptographic keys. A security cryptographich mechanisms, deploying cryptographic keys. A security
association is an essential building block in these mechanisms. association is an essential building block in these mechanisms.
4.5.2. Unicast and Multicast 4.5.2. Unicast and Multicast
Requirement Requirement
The security mechanism MUST support security association protocols The security mechanism SHOULD support security association protocols
for unicast and for multicast associations. for unicast and for multicast associations.
Discussion Discussion
A unicast protocol requires an association protocol between two A unicast protocol requires an association protocol between two
clocks, whereas a multicast protocol requires an association protocol clocks, whereas a multicast protocol requires an association protocol
among two or more clocks, where one of the clocks is a master. among two or more clocks, where one of the clocks is a master.
4.5.3. Key Freshness 4.5.3. Key Freshness
skipping to change at page 15, line 20 skipping to change at page 16, line 15
of low importance, since timing information is typically not of low importance, since timing information is typically not
considered secret information. considered secret information.
Confidentiality can play an important role when service providers Confidentiality can play an important role when service providers
charge payment for time synchronization services, but these cases are charge payment for time synchronization services, but these cases are
rather esoteric. rather esoteric.
Confidentiality can also prevent an MITM attacker from identifying Confidentiality can also prevent an MITM attacker from identifying
protocol packets. Thus, confidentiality can assist in protecting the protocol packets. Thus, confidentiality can assist in protecting the
timing protocol against packet delay attacks, where the attacker timing protocol against packet delay attacks, where the attacker
selectively adds delay to time protocol packets. 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.
4.8. Protection against packet delay attacks 4.8. Protection against packet delay attacks
Requirement Requirement
The security mechanism MAY include a means to detect packet delay The security mechanism MAY include a means to detect packet delay
attacks. attacks.
Requirement Requirement
The security mechanism MAY include a protection switching mechanism The security mechanism MAY include a redundancy mechanism that allows
that allows a node that detects a delay attack to switch over to a a node that detects a delay attack to switch over to a secondary
secondary master. master.
Discussion
While this document does not define specific security solutions, we
note that common practices for protection against delay 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.
4.9. Combining Secured with Unsecured Nodes 4.9. Combining Secured with Unsecured Nodes
Integrating a security mechanism into a time synchronized system is a Integrating a security mechanism into a time synchronized system is a
complex process, and in some cases may require a gradual process, complex process, and in some cases may require a gradual process,
where new equipment supports the security mechanism, and is required where new equipment supports the security mechanism, and is required
to interoperate with legacy equipment without the security features. to interoperate with legacy equipment without the security features.
4.9.1. Secure Mode 4.9.1. Secure Mode
skipping to change at page 16, line 18 skipping to change at page 17, line 31
4.9.2. Hybrid Mode 4.9.2. Hybrid Mode
Requirement Requirement
The security protocol MAY support a hybrid mode, where both secured The security protocol MAY support a hybrid mode, where both secured
and unsecured clocks are permitted to take part in the protocol. and unsecured clocks are permitted to take part in the protocol.
Discussion Discussion
The hybrid mode allows both secured and unsecured clocks to take part The hybrid mode allows both secured and unsecured clocks to take part
in the synchronization protocol. in the synchronization protocol. NTP, for example, allows a mixture
of secured and unsecured nodes.
Requirement Requirement
A master in the hybrid mode SHOULD be a secured clock. A master in the hybrid mode SHOULD be a secured clock.
A secured slave in the hybrid mode SHOULD discard all protocol A secured slave in the hybrid mode SHOULD discard all protocol
packets received from unsecured clocks. packets received from unsecured clocks.
Discussion Discussion
skipping to change at page 17, line 7 skipping to change at page 18, line 20
5. Summary of Requirements 5. Summary of Requirements
+-----------+--------------------------------------+---------------+ +-----------+--------------------------------------+---------------+
| Section | Requirement | Type | | Section | Requirement | Type |
+-----------+--------------------------------------+---------------+ +-----------+--------------------------------------+---------------+
| 4.1. | Authentication of sender. | MUST | | 4.1. | Authentication of sender. | MUST |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | Authentication of master. | MUST | | | Authentication of master. | MUST |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | Proventication. | MUST | | | Recursive authentication. | MUST |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | Authentication of slaves. | SHOULD | | | Authentication of slaves. | SHOULD |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | PTP: Authentication of TCs. | SHOULD | | | PTP: Authentication of TCs. | SHOULD |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | PTP: Authentication of Announce | SHOULD | | | PTP: Authentication of Announce | SHOULD |
| | messages. | | | | messages. | |
+-----------+--------------------------------------+---------------+ +-----------+--------------------------------------+---------------+
| 4.2. | Integrity protection. | MUST | | 4.2. | Integrity protection. | MUST |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | PTP: hop-by-hop integrity protection.| MUST | | | PTP: hop-by-hop integrity protection.| MUST |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | PTP: end-to-end integrity protection.| SHOULD | | | PTP: end-to-end integrity protection.| SHOULD |
+-----------+--------------------------------------+---------------+ +-----------+--------------------------------------+---------------+
| 4.3. | Protection against DoS attacks. | MUST | | 4.3. | Protection against DoS attacks. | MUST |
+-----------+--------------------------------------+---------------+ +-----------+--------------------------------------+---------------+
| 4.4. | Replay protection. | MUST | | 4.4. | Replay protection. | MUST |
+-----------+--------------------------------------+---------------+ +-----------+--------------------------------------+---------------+
| 4.5. | Security association. | MUST | | 4.5. | Security association. | SHOULD |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | Unicast and multicast associations. | MUST | | | Unicast and multicast associations. | SHOULD |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | Key freshness. | MUST | | | Key freshness. | MUST |
+-----------+--------------------------------------+---------------+ +-----------+--------------------------------------+---------------+
| 4.6. | Performance: no degradation in | MUST | | 4.6. | Performance: no degradation in | MUST |
| | quality of time transfer. | | | | quality of time transfer. | |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | Performance: lightweight. | SHOULD | | | Performance: lightweight. | SHOULD |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | Performance: storage, bandwidth. | MUST | | | Performance: storage, bandwidth. | MUST |
+-----------+--------------------------------------+---------------+ +-----------+--------------------------------------+---------------+
skipping to change at page 19, line 5 skipping to change at page 20, line 16
[1588IPsec] and [Tunnel]. [1588IPsec] and [Tunnel].
6.2. Security and Two-Step Timestamping 6.2. Security and Two-Step Timestamping
PTP supports a two-step mode of operation, where the time of PTP supports a two-step mode of operation, where the time of
transmission and the time of reception of protocol packets are transmission and the time of reception of protocol packets are
measured without modifying the packets. As opposed to one-step mode, measured without modifying the packets. As opposed to one-step mode,
two step timestamping can be performed at the physical interface even two step timestamping can be performed at the physical interface even
in the presence of a security mechanism. in the presence of a security mechanism.
Note that if an encryption mechanism is used, it presents a challenge Note that if an encryption mechanism such as IPsec is used, it
to the timestamping mechanism, since time protocol packets are presents a challenge to the timestamping mechanism, since time
encrypted when traversing the physical interface, and are thus protocol packets are encrypted when traversing the physical
impossible to identify. A possible solution to this problem interface, and are thus impossible to identify. A possible solution
[IPsecSync] is to include an indication in the encryption header that to this problem [IPsecSync] is to include an indication in the
identifies time synchronization packets. encryption header that identifies time synchronization packets.
6.3. Intermediate Clocks 6.3. Intermediate Clocks
A time synchronization protocol allows slaves to receive time A time synchronization protocol allows slaves to receive time
information from an accurate time source. Time information is sent information from an accurate time source. Time information is sent
over a path that often traverses one or more intermediate clocks. over a path that often traverses one or more intermediate clocks.
o In NTP, time information originated from a stratum 1 server can be o In NTP, time information originated from a stratum 1 server can be
distributed to stratum 2 servers, and in turn distributed from the distributed to stratum 2 servers, and in turn distributed from the
stratum 2 servers to NTP clients. In this case, the stratum 2 stratum 2 servers to NTP clients. In this case, the stratum 2
skipping to change at page 19, line 46 skipping to change at page 21, line 12
system's exposure to internal threats, as there is a large number of system's exposure to internal threats, as there is a large number of
nodes that are exposed to the security keys. nodes that are exposed to the security keys.
6.4. The Effect of External Security Protocols on Time Synchronization 6.4. The Effect of External Security Protocols on Time Synchronization
Time synchronization protocols are often deployed in systems that use Time synchronization protocols are often deployed in systems that use
security mechanisms and protocols. security mechanisms and protocols.
A typical example is the 3GPP Femtocell network [3GPP], where IPsec A typical example is the 3GPP Femtocell network [3GPP], where IPsec
is used for securing traffic between a Femtocell and the Femto is used for securing traffic between a Femtocell and the Femto
Gateway. All traffic between these two nodes is secured by IPsec, Gateway. In some cases, all traffic between these two nodes may be
including the time synchronization protocol traffic. This use-case is secured by IPsec, including the time synchronization protocol
thoroughly discussed in [IPsecSync]. traffic. This use-case is thoroughly discussed in [IPsecSync].
Another typical example is the usage of MACsec encryption in L2 Another typical example is the usage of MACsec encryption in L2
networks that deploy time synchronization [AvbAssum]. networks that deploy time synchronization [AvbAssum].
The usage of external security mechanisms may affect time The usage of external security mechanisms may affect time
synchronization protocols as follows: synchronization protocols as follows:
o Timestamping accuracy can be affected, as described in 6.1. o Timestamping accuracy can be affected, as described in 6.1.
o If traffic is secured between two nodes in the network, no o If traffic is secured between two nodes in the network, no
intermediate clocks can be used between these two nodes. In the intermediate clocks can be used between these two nodes. In the
[3GPP] example, if traffic between the Femtocell and the Femto [3GPP] example, if traffic between the Femtocell and the Femto
Gateway is encrypted, then time protocol packets are sent over the Gateway is encrypted, then time protocol packets are sent over the
underlying network without modification, and thus cannot enjoy the underlying network without modification, and thus cannot enjoy the
improved accuracy provided by intermediate clock nodes. improved accuracy provided by intermediate clock nodes.
6.5. External Security Services Requiring Time Synchronization 6.5. External Security Services Requiring Time Synchronization
Certificate validation requires the sender and receiver to be time Certificate validation requires the sender and receiver to be roughly
synchronized. Thus, synchronization is required for establishing time synchronized. Thus, synchronization is required for establishing
security protocols such as IKEv2 and TLS. security protocols such as IKEv2 and TLS.
An even stronger interdependence between a time synchronization An even stronger interdependence between a time synchronization
protocol and a security mechanism is defined in [AutoKey], which protocol and a security mechanism is defined in [AutoKey], which
defines mutual dependence between the acquired time information, and defines mutual dependence between the acquired time information, and
the authentication protocol that secures it. the authentication protocol that secures it.
7. Issues for Further Discussion 7. Issues for Further Discussion
o The key distribution is outside the scope of this document. o The key distribution is outside the scope of this document.
skipping to change at page 20, line 45 skipping to change at page 22, line 11
The security considerations of network timing protocols are presented The security considerations of network timing protocols are presented
throughout this document. throughout this document.
9. IANA Considerations 9. IANA Considerations
There are no new IANA considerations implied by this document. There are no new IANA considerations implied by this document.
10. Acknowledgments 10. 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.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
11. References 11. References
11.1. Normative References 11.1. Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[NTPv4] Mills, D., Delaware, U., Martin, J., Burbank, J., [NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W.,
Kasch, W., "Network Time Protocol Version 4: Protocol "Network Time Protocol Version 4: Protocol and
and Algorithms Specification", RFC 5905, June 2010. Algorithms Specification", RFC 5905, June 2010.
[AutoKey] Haberman, B., Mills, D., "Network Time Protocol [AutoKey] Haberman, B., Mills, D., "Network Time Protocol
Version 4: Autokey Specification", RFC 5906, June Version 4: Autokey Specification", RFC 5906, June
2010. 2010.
11.2. Informative References [IEEE1588] IEEE TC 9 Test and Measurement Society 2000, "1588
[IEEE 1588] IEEE TC 9 Test and Measurement Society 2000, "1588
IEEE Standard for a Precision Clock Synchronization IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems Protocol for Networked Measurement and Control Systems
Version 2", IEEE Standard, 2008. Version 2", IEEE Standard, 2008.
11.2. Informative References
[Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R., [Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R.,
"Traps and pitfalls in secure clock synchronization" "Traps and pitfalls in secure clock synchronization"
in Proceedings of 2007 International Symposium for in Proceedings of 2007 International Symposium for
Precision Clock Synchronization for Measurement, Precision Clock Synchronization for Measurement,
Control and Communication, ISPCS 2007, pp. 18-24, Control and Communication, ISPCS 2007, pp. 18-24,
2007. 2007.
[TM] T. Mizrahi, "Time synchronization security using IPsec [TM] T. Mizrahi, "Time synchronization security using IPsec
and MACsec", ISPCS 2011, pp. 38-43, 2011. and MACsec", ISPCS 2011, pp. 38-43, 2011.
skipping to change at page 22, line 26 skipping to change at page 23, line 39
Synchronization for Measurement, Control and Synchronization for Measurement, Control and
Communication, ISPCS 2010, pp. 83-90, 2010. Communication, ISPCS 2010, pp. 83-90, 2010.
[Tunnel] A. Treytl, B. Hirschler, and T. Sauter, "Secure [Tunnel] A. Treytl, B. Hirschler, and T. Sauter, "Secure
tunneling of high precision clock synchronisation tunneling of high precision clock synchronisation
protocols and other timestamped data", in Proceedings protocols and other timestamped data", in Proceedings
of the 8th IEEE International Workshop on Factory of the 8th IEEE International Workshop on Factory
Communication Systems (WFCS), vol. ISBN 978-1-4244- Communication Systems (WFCS), vol. ISBN 978-1-4244-
5461-7, pp. 303-313, 2010. 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
Karen O'Donoghue
ISOC
Email: odonoghue@isoc.org
Authors' Addresses Authors' Addresses
Tal Mizrahi Tal Mizrahi
Marvell Marvell
6 Hamada St. 6 Hamada St.
Yokneam, 20692 Israel Yokneam, 20692 Israel
Email: talmi@marvell.com Email: talmi@marvell.com
Karen O'Donoghue
7167 Goby Lane
King George, VA 22485
Email: odonoghue@isoc.org
 End of changes. 54 change blocks. 
124 lines changed or deleted 199 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/