draft-ietf-tictoc-security-requirements-03.txt		draft-ietf-tictoc-security-requirements-04.txt
	TICTOC Working Group Tal Mizrahi		TICTOC Working Group Tal Mizrahi
	Internet Draft Marvell		Internet Draft Marvell
	Intended status: Informational		Intended status: Informational
	Expires: March 2013 September 14, 2012		Expires: August 2013 February 7, 2013
	TICTOC Security Requirements		Security Requirements of Time Synchronization Protocols
	draft-ietf-tictoc-security-requirements-03.txt		in Packet Switched Networks
			draft-ietf-tictoc-security-requirements-04.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 security		threats is increasing. This document defines a set of security
	requirements for time synchronization protocols, focusing on the		requirements for time synchronization 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		This document also discusses the security impacts of time
	synchronization protocol practices, the time synchronization		synchronization protocol practices, the time synchronization
	skipping to change at page 1, line 44		skipping to change at page 1, line 45
	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 March 14, 2013.		This Internet-Draft will expire on August 7, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	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 ............................ 5
	2.1. Terminology ............................................. 4		2.1. Terminology ............................................. 5
	2.2. Terms & Abbreviations ................................... 5		2.2. Abbreviations ........................................... 5
	3. Security Threats ............................................. 5		2.3. Common Terminology for PTP and NTP ...................... 5
	3.1. Threat Model ............................................ 5		2.4. Terms used in this Document ............................. 5
	3.1.1. Internal vs. External Attackers .................... 6		3. Security Threats ............................................. 6
	3.1.2. Man in the Middle (MITM) vs. Packet Injector ....... 6		3.1. Threat Model ............................................ 7
	3.2. Threat Analysis.......................................... 6		3.1.1. Internal vs. External Attackers .................... 7
	3.2.1. Packet Interception and Manipulation ............... 6		3.1.2. Man in the Middle (MITM) vs. Packet Injector ....... 7
	3.2.2. Spoofing ........................................... 6		3.2. Threat Analysis.......................................... 8
	3.2.3. Replay Attack ...................................... 7		3.2.1. Packet Interception and Manipulation ............... 8
	3.2.4. Rogue Master Attack ................................ 7		3.2.2. Spoofing ........................................... 8
	3.2.5. Packet Interception and Removal .................... 7		3.2.3. Replay Attack ...................................... 8
	3.2.6. Packet Delay Manipulation .......................... 7		3.2.4. Rogue Master Attack ................................ 8
	3.2.7. Cryptographic Performance Attacks .................. 7		3.2.5. Packet Interception and Removal .................... 9
	3.2.8. L2/L3 DoS Attacks .................................. 8		3.2.6. Packet Delay Manipulation .......................... 9
	3.2.9. Master Time Source Spoofing (e.g. GPS fraud) ....... 8		3.2.7. Cryptographic Performance Attacks .................. 9
	3.3. Threat Analysis Summary ................................. 8		3.2.8. L2/L3 DoS Attacks .................................. 9
	4. Security Requirements ........................................ 9		3.2.9. DoS Attacks against the Time Protocol .............. 9
	4.1. Clock Identity Authentication ........................... 9		3.2.10. Grandmaster Time Source Spoofing (e.g. GPS fraud) . 9
	4.1.1. Authentication of Masters ......................... 10		3.3. Threat Analysis Summary ................................ 10
	4.1.2. Recursive Authentication of Masters (Chain of Trust)10		4. Requirement Levels .......................................... 11
	4.1.3. Authentication of Slaves .......................... 11		5. Security Requirements ....................................... 12
	4.1.4. PTP: Authentication of Transparent Clocks.......... 11		5.1. Clock Identity Authentication and Authorization ........ 12
	4.1.5. PTP: Authentication of Announce Messages .......... 11		5.1.1. Authentication and Authorization of Masters ....... 13
	4.2. Data integrity ......................................... 12		5.1.2. Recursive Authentication and Authorization of Masters
	4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 12		(Chain of Trust) ......................................... 14
	4.2.1.1. Hop by Hop Integrity Protection .............. 12		5.1.3. Authentication and Authorization of Slaves ........ 15
	4.2.1.2. End to End Integrity Protection .............. 13		5.1.4. PTP: Authentication and Authorization of Transparent
			Clocks by Master ......................................... 15
	4.3. Availability ........................................... 13		5.1.5. PTP: Authentication and Authorization of Control
	4.4. Replay Protection ...................................... 14		Messages ................................................. 16
	4.5. Cryptographic Keys & Security Associations ............. 14		5.2. Data integrity ......................................... 17
	4.5.1. Security Association .............................. 14		5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 18
	4.5.2. Unicast and Multicast ............................. 14		5.2.1.1. Hop-by-Hop Integrity Protection .............. 18
	4.5.3. Key Freshness ..................................... 14		5.2.1.2. End-to-End Integrity Protection .............. 19
	4.6. Performance ............................................ 15		5.3. Availability ........................................... 19
	4.7. Confidentiality......................................... 15		5.4. Replay Protection ...................................... 20
	4.8. Protection against packet delay attacks ................ 16		5.5. Cryptographic Keys and Security Associations ........... 20
	4.9. Combining Secured with Unsecured Nodes ................. 16		5.5.1. Key Freshness ..................................... 20
	4.9.1. Secure Mode ....................................... 17		5.5.2. Security Association .............................. 21
	4.9.2. Hybrid Mode ....................................... 17		5.5.3. Unicast and Multicast ............................. 21
	5. Summary of Requirements ..................................... 18		5.6. Performance ............................................ 22
	6. Additional security implications ............................ 19		5.7. Confidentiality......................................... 22
	6.1. Security and on-the-fly Timestamping ................... 19		5.8. Protection against Packet Delay and Interception Attacks 23
	6.2. Security and Two-Step Timestamping ..................... 20		5.9. Combining Secured with Unsecured Nodes ................. 24
	6.3. Intermediate Clocks .................................... 20		5.9.1. Secure Mode ....................................... 24
	6.4. The Effect of External Security Protocols on Time		5.9.2. Hybrid Mode ....................................... 24
	Synchronization ............................................. 21		6. Summary of Requirements ..................................... 26
	6.5. External Security Services Requiring Time Synchronization21		7. Additional security implications ............................ 27
	7. Issues for Further Discussion ............................... 21		7.1. Security and on-the-fly Timestamping ................... 27
	8. Security Considerations ..................................... 21		7.2. PTP: Security and Two-Step Timestamping ................ 28
	9. IANA Considerations ......................................... 22		7.3. Intermediate Clocks .................................... 28
	10. Acknowledgments ............................................ 22		7.4. The Effect of External Security Protocols on Time
	11. References ................................................. 22		Synchronization ............................................. 29
	11.1. Normative References .................................. 22		7.5. External Security Services Requiring Time Synchronization29
	11.2. Informative References ................................ 22		7.5.1. Timestamped Certificates .......................... 29
	12. Contributing Authors ....................................... 24		7.5.2. Time Synchronization as a Vulnerability ........... 30
			8. Issues for Further Discussion ............................... 30
			9. Security Considerations ..................................... 30
			10. IANA Considerations......................................... 30
			11. Acknowledgments ............................................ 30
			12. References ................................................. 30
			12.1. Normative References .................................. 30
			12.2. Informative References ................................ 31
			13. Contributing Authors ....................................... 32
	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 (DoS) 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 (PTP) [IEEE1588] 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]. [IEEE1588] 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		While NTP includes an inherent security protocol, the absence of a
	security mechanisms. The absence of a standard security solution for		standard security solution for PTP undoubtedly contributed to the
	PTP undoubtedly contributed to the wide deployment of unsecured time		wide deployment of unsecured time synchronization solutions. However,
	synchronization solutions. However, in some cases security mechanisms		in some cases security mechanisms may not be strictly necessary,
	may not be strictly necessary, e.g., due to other security practices		e.g., due to other security practices in place, or due to the
	in place, or due to the architecture of the network. A time		architecture of the network. A time synchronization security
	synchronization security solution, much like any security solution,		solution, much like any security solution, is comprised of various
	is comprised of various building blocks, and must be carefully		building blocks, and must be carefully tailored for the specific
	tailored for the specific system it is deployed in. Based on a		system it is deployed in. Based on a system-specific threat
	system-specific threat assessment, the benefits of a security		assessment, the benefits of a security solution must be weighed
	solution must be weighed against the potential risks, and based on		against the potential risks, and based on this tradeoff an optimal
	this tradeoff an optimal security solution can be selected.		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:		questions:
	(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?)
	In light of the questions above, this document defines a set of		In light of the questions above, this document defines a set of
	requirements for security solutions for time synchronization		requirements for security solutions for time synchronization
	skipping to change at page 5, line 5		skipping to change at page 5, line 19
	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
	are phrased in the document in the form "the security mechanism		are phrased in the document in the form "the security mechanism
	MUST/SHOULD/...". Note, that the phrasing does not imply that this		MUST/SHOULD/...". Note, that the phrasing does not imply that this
	document defines a specific security mechanism, but defines the		document defines a specific security mechanism, but defines the
	requirements that every security mechanism should comply to.		requirements that every security mechanism should comply to.
			2.2. Abbreviations
			BC Boundary Clock
			DoS Denial of Service
			MITM Man In The Middle
			NTP Network Time Protocol
			OC Ordinary Clock
			PTP Precision Time Protocol
			TC Transparent Clock
			2.3. Common Terminology for PTP and NTP
	This document refers to both PTP and NTP. For the sake of		This document refers to both PTP and NTP. For the sake of
	consistency, throughout the document the term "master" applies to		consistency, throughout the document the term "master" applies to
	both a PTP master and an NTP server. Similarly, the term "slave"		both a PTP master and an NTP server. Similarly, the term "slave"
	applies to both PTP slaves and NTP clients. The general term "clock"		applies to both PTP slaves and NTP clients. The general term "clock"
	refers to masters, slaves and PTP Transparent Clocks (TC). The term		refers to masters, slaves and PTP Transparent Clocks (TC). The term
	"protocol packets" is refers generically to PTP and NTP messages.		"protocol packets" refers generically to PTP and NTP messages.
	2.2. Terms & Abbreviations		2.4. Terms used in this Document
	BC Boundary Clock		o Control packets - Packets used by the protocol to exchange
			information between clocks that is not strictly related to the
			time. NTP uses NTP Control Messages. PTP uses Announce, Signaling
			and Management messages.
	MITM Man In The Middle		o End-to-end security - A security approach where secured packets
			sent from a source to a destination is not modified by
			intermediate nodes.
	NTP Network Time Protocol		o Grandmaster - A master that receives time information from a
			locally attached clock device, and not through the network. A
			grandmaster distributes its time to other clocks in the network.
	OC Ordinary Clock		o Hop-by-hop security - A security approach where secured packets
			sent from a source to a destination may be modified by
			intermediate nodes. In this approach intermediate nodes share the
			encryption key with the source and destination, allowing them to
			re-encrypt or re-authenticate modified packets before relaying
			them to the destination.
	PTP Precision Time Protocol		o Intermediate clock - A clock that receives timing information from
			a master, and sends timing information to other clocks.
			In NTP this term refers to an NTP server that is not a Stratum 1
			server. In PTP this term refers to a BC or a TC.
	Secured clock A clock that supports a security mechanism that		o Master - A clock that generates timing information to other clocks
	complies to the requirements in this document		in the network.
			In NTP 'master' refers to an NTP server. In PTP 'master' refers to
			a master OC (aka grandmaster) or to a port of a BC that is in the
			master state.
	TC Transparent Clock		o Protocol packets - Packets used by the time protocol. The
			terminology used in this document distinguishes between time
			packets and control packets.
	Unsecured clock A clock that does not support a security mechanism		o Secured clock - A clock that supports a security mechanism that
	according to the requirments in this document		complies to the requirements in this document.
			o Slave - A clock that receives timing information from a master. In
			NTP 'slave' refers to an NTP client. In PTP 'slave' refers to a
			slave OC, or to a port of a BC that is in the slave state.
			o Time packets - Protocol packets carrying time information.
			o Unsecured clock - A clock that does not support a security
			mechanism according to the requirements in this document.
	3. Security Threats		3. Security Threats
	This section discusses the possible attacker types, and analyzes		This section discusses the possible attacker types and analyzes
	various attacks against time synchronization protocols.		various attacks against time synchronization protocols.
	The literature is rich with security threats of time synchronization		The literature is rich with security threats of time synchronization
	protocols, e.g., [Traps], [AutoKey], [TM], [SecPTP], and [SecSen].		protocols, e.g., [Traps], [AutoKey], [TM], [SecPTP], and [SecSen].
	The threat analysis in this document is mostly based on [TM].		The threat analysis in this document is mostly based on [TM].
	3.1. Threat Model		3.1. Threat Model
	A time synchronization protocol can be attacked by various types of		A time synchronization protocol can be attacked by various types of
	attackers.		attackers.
	The analysis in this documents classifies attackers according to 2		The analysis in this document classifies attackers according to 2
	criteria, as described in 3.1.1. and 3.1.2.		criteria, as described in 3.1.1. and 3 .1.2.
	3.1.1. Internal vs. External Attackers		3.1.1. Internal vs. External Attackers
	In the context of internal and external attackers, the underlying		In the context of internal and external attackers, the underlying
	assumption is that the time synchronization protocol is secured		assumption is that the time synchronization protocol is secured
	either by an encryption or an authentication mechanism.		either by an encryption or an authentication mechanism, or both.
	Internal attackers either have access to a trusted segment of the		Internal attackers either have access to a trusted segment of the
	network, or possess the encryption or authentication keys. External		network, or possess the encryption or authentication keys. An
	attackers, on the other hand, do not have the keys, and are exposed		internal attack can also be performed by exploiting vulnerabilities
	only to the encrypted or authenticated traffic. Thus, an internal		in devices; for example, by installing malware, or obtaining
	attacker can maliciously tamper with legitimate traffic in the		credentials to reconfigure the device. Thus, an internal attacker can
	network, as well as generate its own traffic and make it appear		maliciously tamper with legitimate traffic in the network, as well as
	legitimate to its attacked nodes.		generate its own traffic and make it appear legitimate to its
			attacked nodes.
			External attackers, on the other hand, do not have the keys, and have
			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
	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.		modification of in-flight protocol packets. It is assumed that an
			MITM attacker has physical access to a segment of the network, or has
			gained control of one of the nodes in the network.
	A traffic injector is not located in an MITM position, but can attack		A traffic injector is not located in an MITM position, but can attack
	by generatating protocol packets. An injector can also potentially		by generating protocol packets. An injector can reside either within
	eavesdrop to protocol packets sent as multicast, record them and		the attacked network, or on an external network that is connected to
	replay them later.		the attacked network. An injector can also potentially eavesdrop on
			protocol packets sent as multicast, record them and replay them
			later.
	3.2. Threat Analysis		3.2. 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 an MITM
	The-Middle (MITM) attacker intercepts timing protocol packets, alters		attacker intercepts timing protocol packets, alters them and relays
	them and relays them to their destination, allowing the attacker to		them to their destination, allowing the attacker to maliciously
	maliciously tamper with the protocol. This can result in a situation		tamper with the protocol. This can result in a situation where the
	where the time protocol is apparently operational but providing		time protocol is apparently operational but providing intentionally
	intentionally inaccurate information.		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 by generating and transmitting protocol packets. For example,		network by generating and transmitting protocol packets. For example,
	an attacker can impersonate the master, allowing malicious		an attacker can impersonate the master, allowing malicious
	distribution of false timing information. As with packet interception		distribution of false timing information. As with packet interception
	and manipulation, this can result in a situation where the time		and manipulation, this can result in a situation where the time
	protocol is apparently operational but providing intentionally		protocol is apparently operational but providing intentionally
	inaccurate information.		inaccurate information.
	skipping to change at page 7, line 18		skipping to change at page 8, line 37
	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 without any modification. This can also result		them at a later time without any modification. This can also result
	in a situation where the time protocol is apparently operational but		in a situation where the time protocol is apparently operational but
	providing intentionally 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 Rogue 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
	process. For example, in PTP, an attacker can manipulate the Best		using malicious control packets. For example, in PTP, an attacker can
	Master Clock Algorithm (BMCA), and cause other nodes in the network		manipulate the Best Master Clock Algorithm (BMCA), and cause other
	to believe it is the most eligible candidate to be a grandmaster.		nodes in the network to believe it is the most eligible candidate to
			be a grandmaster.
			In PTP, a possible variant of this attack is the rogue TC/BC attack.
			Similar to the rogue master attack, an attacker can cause victims to
			believe it is a legitimate TC or BC, allowing the attacker to
			manipulate the time information forwarded to the victims.
	3.2.5. Packet Interception and Removal		3.2.5. Packet Interception and Removal
	A packet interception and removal attack results when a Man-In-The-		A packet interception and removal attack results when an MITM
	Middle attacker intercepts and drops protocol packets, preventing the		attacker intercepts and drops protocol packets, preventing the
	destination node from receiving the timing information.		destination node from receiving the some or all of the protocol
			packets.
	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, an MITM attacker intercepts
	intercepts protocol packets, and relays them to their destination		protocol packets, and relays them to their destination after adding a
	after adding a maliciously computed delay.		maliciously computed delay.
	Note that the attackee still receives one copy of each packet,		Note that the victim still receives one copy of each packet, contrary
	contrary to the replay attack, where a packet is received by the		to the replay attack, where some or all of the packets may be
	attackee more than once.		received by the victim 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.
			This DoS attack is applicable to all encryption and authentication
			protocols. However, when the time protocol uses a dedicated security
			mechanism implemented in a dedicated cryptographic engine, this
			attack can be applied to cause DoS specifically to the time protocol
	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 DoS attacks. As the
	attacks. As the target's availability is compromised, the timing		target's availability is compromised, the timing protocol is affected
	protocol is affected accordingly.		accordingly.
	3.2.9. Master Time Source Spoofing (e.g. GPS fraud)		3.2.9. DoS Attacks against the Time Protocol
			An attacker can attack a clock using an excessive number of time
			protocol packets, thus degrading the victim's performance. This
			attack can be implemented, for example, using the attacks described
			in 3.2.2. and 3 .2.4.
			3.2.10. Grandmaster Time Source Spoofing (e.g. GPS fraud)
	In time source spoofing, an attacker spoofs the accurate time source		In time source spoofing, an attacker spoofs the accurate time source
	of the master. For example, if the master uses a GPS based clock as		of the grandmaster. For example, if the grandmaster uses a GPS based
	its reference source, an attacker can spoof the GPS satellites,		clock as its reference source, an attacker can spoof GPS satellite
	causing the master to use a false reference time.		signals, causing the grandmaster to use a false reference time.
			Note that this attack is outside the scope of the time
			synchronization protocol. While various security measures can be
			taken to mitigate this attack, these measures are outside the scope
			of the security requirements defined in this document.
	3.3. Threat Analysis Summary		3.3. Threat Analysis Summary
	The two key factors to a threat analysis are the severity and the		The two key factors to a threat analysis are the severity and the
	likelihood of each of the analyzed attacks.		likelihood of each of the analyzed attacks.
	Table 1 summarizes the security attacks presented in 3.2. For each		Table 1 summarizes the security attacks presented in 3.2. For each
	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.
			Table 1 clearly shows the distinction between external and internal
			attackers, and motivates the usage of authentication and integrity
			protection, significantly reducing the impact of external attackers.
	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,		o DoS - the attack causes denial of service to the attacked node,
	the impact of which is not restricted to the time synchronization		the impact of which is not restricted to the time synchronization
	protocol.		protocol.
	o False time - slaves align to a false time or frequency value due
	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.
	The Attacket Type columns refer to the 4 possible combinations of the		o False time - slaves align to a false time or frequency value due
			to the attack. Note that if the time synchronization service
			aligns to a false time, it may cause DoS 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.
			All attacks that have a '+' for 'False Time' implicitly have a '+'
			for 'Accuracy Degradation'.
			The Attacker 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 |External |
	| |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.|		| |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.|
	+-----------------------------+-----+--------+----++----+----+----+----+		+-----------------------------+-----+--------+----++----+----+----+----+
	|Interception and manipulation| + | | || + | | | |		|Interception and manipulation| + | | || + | | | |
	+-----------------------------+-----+--------+----++----+----+----+----+		+-----------------------------+-----+--------+----++----+----+----+----+
	|Spoofing | + | | || + | + | | |		|Spoofing | + | | || + | + | | |
	+-----------------------------+-----+--------+----++----+----+----+----+		+-----------------------------+-----+--------+----++----+----+----+----+
	|Replay attack | + | | || + | + | | |		|Replay attack | + | | || + | + | | |
	+-----------------------------+-----+--------+----++----+----+----+----+		+-----------------------------+-----+--------+----++----+----+----+----+
	|Rogue master attack | + | | || + | + | | |		|Rogue master attack | + | | || + | + | | |
	+-----------------------------+-----+--------+----++----+----+----+----+		+-----------------------------+-----+--------+----++----+----+----+----+
	|Interception and Removal | | + | || + | | + | |		|Interception and Removal | | + | || + | | + | |
	+-----------------------------+-----+--------+----++----+----+----+----+		+-----------------------------+-----+--------+----++----+----+----+----+
	|Packet delay manipulation | + | | || + | | + | |		|Packet delay manipulation | + | | || + | | + | |
	+-----------------------------+-----+--------+----++----+----+----+----+		+-----------------------------+-----+--------+----++----+----+----+----+
	|Crypt. performance attacks | | | + || + | + | + | + |		|Crypt. performance attacks | | | + || + | + | + | + |
	+-----------------------------+-----+--------+----++----+----+----+----+		+-----------------------------+-----+--------+----++----+----+----+----+
	|DoS attacks | | | + || + | + | + | + |		|L2/L3 DoS attacks | | | + || + | + | + | + |
			+-----------------------------+-----+--------+----++----+----+----+----+
			|Time Protocol DoS attacks | | | + || + | + | | |
	+-----------------------------+-----+--------+----++----+----+----+----+		+-----------------------------+-----+--------+----++----+----+----+----+
	|Master Time source spoofing | + | | || + | + | + | + |		|Master Time source spoofing | + | | || + | + | + | + |
	|(e.g. GPS spoofing) | | | || | | | |		|(e.g. GPS spoofing) | | | || | | | |
	+-----------------------------+-----+--------+----++----+----+----+----+		+-----------------------------+-----+--------+----++----+----+----+----+
	Table 1 Threat Analysis - Summary		Table 1 Threat Analysis - Summary
	4. Security Requirements		The threats discussed in this section provide the background for the
			security requirements presented in Section 5 .
	This section defines a set of requirements from the security		4. Requirement Levels
	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		The security requirements are presented in Section 5 . Each
			requirement is defined with a requirement level, in accordance with
			the requirement levels defined in [KEYWORDS].
			The requirement levels in this document are affected by the following
			factors:
			o Impact:
			The possible impact of not implementing the requirement, as
			illustrated in the 'impact' column of Table 1.
			For example, a requirement that addresses a threat that can be
			implemented by an external injector is typically a 'MUST', since
			the threat can be implemented by all the attacker types analyzed
			in Section 3.1.
			o Difficulty of the corresponding attack:
			The level of difficulty of the possible attacks that become
			possible by not implementing the requirement. The level of
			difficulty is reflected in the 'Attacker Type' column of Table 1.
			For example, a requirement that addresses a threat that only
			compromises the availability of the protocol is typically no more
			than a 'SHOULD'.
			o Practical considerations:
			Various practical factors that may affect the requirement.
			For example, if a requirement is very difficult to implement, or
			is applicable to very specific scenarios, these factors may reduce
			the requirement level.
			Section 5. lists the requirements. For each requirement there is a
			short explanation about the reason for its requirement level.
			5. Security Requirements
			This section defines the requirements of security mechanisms used for
			time synchronization protocols.
			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 requirements can be
			satisfied by defining explicit security mechanisms for 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.
			5.1. Clock Identity Authentication and Authorization
	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		Requirement
	In the context of this document, authentication refers to:		The security mechanism MUST provide a means for each clock to verify
			that the sender of a protocol packet is authorized to send a packet
			of this type.
	o Identification: verifying the identity of the peer clock.		Requirement Level
	o Authorization: verifying that the peer clock is permitted to play		The requirements in this subsection address the spoofing attack
	the role that it plays in the protocol. For example, some nodes		(Section 3.2.2. ), and the rogue master attack (Section 3 .2.4. ).
	may be permitted to be masters, while other nodes are only
	permitted to be slaves or TCs.
	The following subsections describe 4 distinct cases of clock		The requirement level of these requirements is 'MUST' since in the
	authentication.		absence of these requirements the protocol is exposed to attacks that
			are easy to implement and have a high impact.
	4.1.1. Authentication of Masters		Discussion
			Authentication refers to verifying the identity of the peer clock.
			Authorization, on the other hand, refers to verifying that the peer
			clock is permitted to play the role that it plays in the protocol.
			For example, some nodes may be permitted to be masters, while other
			nodes are only permitted to be slaves or TCs.
			It is noted that while the security mechanism is required to provide
			an authorization mechanism, the deployment of such a mechanism
			depends on the nature of the network. For example, a network that
			deploys PTP may consist of a set of identical OCs, where all clocks
			are equally permitted to be a master. In such a network an
			authorization mechanism may not be necessary.
			The following subsections describe 4 distinct cases of clock
			authentication.
			5.1.1. Authentication and Authorization 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 slaves to authenticate the identity of masters.
	4.1.2. Recursive Authentication of Masters (Chain of Trust)
	Requirement		Requirement
	The security mechanism MUST support recursive authentication of the		The authentication mechanism MUST allow slaves to verify that the
	master, to be used in cases where end-to-end authentication is not		authenticated master is authorized to be a master.
	possible.
			Requirement Level
			The requirements in this subsection address the spoofing attack
			(Section 3.2.2. ), and the rogue master attack (Section 3 .2.4. ).
			The requirement level of these requirements is 'MUST' since in the
			absence of these requirements the protocol is exposed to attacks that
			are easy to implement and have a high impact.
	Discussion		Discussion
	Clocks authenticate masters in order to ensure the authenticity of		Clocks authenticate masters in order to ensure the authenticity of
	the time source.		the time source. It is important for a slave to verify the identity
			of the master, as well as to verify that the master is indeed
			authorized to be a master.
	In some cases a slave is connected to an intermediate master, that is		5.1.2. Recursive Authentication and Authorization of Masters (Chain of
			Trust)
			Requirement
			The security mechanism MUST support recursive authentication and
			authorization of the master, to be used in cases where time
			information is conveyed through intermediate clocks.
			Requirement Level
			The requirement in this subsection addresses the spoofing attack
			(Section 3.2.2. ), and the rogue master attack (Section 3 .2.4. ).
			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
			In some cases a slave is connected to an intermediate clock, that is
	not the primary time source. For example, in PTP a slave can be		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) or a Transparent Clock (TC), which
	grandmaster. A similar example in NTP is when a client is connected		in turn is connected to a grandmaster. A similar example in NTP is
	to a stratum 2 server, which is connected to a stratum 1 server. In		when a client is connected to a stratum 2 server, which is connected
	both the PTP and the NTP cases, the slave authenticates the		to a stratum 1 server. In both the PTP and the NTP cases, the slave
	intermediate master, and the intermediate master authenticates the		authenticates the intermediate clock, and the intermediate clock
	primary master. This inductive authentication process is referred to		authenticates the grandmaster. This inductive authentication process
	in [AutoKey] as proventication.		is referred to in [AutoKey] as proventication.
	4.1.3. Authentication of Slaves		Specifically in PTP, this requirement implies that if a slave is
			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		Requirement
	The security mechanism SHOULD provide a means for a master to		The security mechanism MAY provide a means for a master to
	authenticate its slaves.		authenticate its slaves.
			Requirement Level
			The requirement in this subsection prevents DoS attacks against the
			master (Section 3.2.9. ).
			The requirement level of this requirement is 'MAY' since:
			o Its low impact, i.e., in the absence of this requirement the
			protocol is only exposed to DoS.
			o Practical considerations: requiring an NTP server to authenticate
			its clients may significantly impose on the server's performance.
	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, by
	by preventing the master from serving unauthorized clocks. It could		preventing the master from serving unauthorized clocks. It could be
	be argued that the authentication of slaves could put a higher load		argued that the authentication of slaves could put a higher load on
	on the master then serving the unauthorized clock, and hence this		the master then serving the unauthorized clock, and hence this
	requirement is a SHOULD.		requirement is a SHOULD.
	4.1.4. PTP: Authentication of Transparent Clocks		5.1.4. PTP: Authentication and Authorization of Transparent Clocks by
			Master
	Requirement		Requirement
	The security mechanism for PTP SHOULD 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.		authenticate the identity of the P2P TCs directly connected to it.
			Requirement Level
			The requirement in this subsection prevents DoS attacks against the
			master (Section 3.2.9. ).
			The requirement level of this requirement is 'MAY' for the same
			reasons specified in Section 5.1.3.
	Discussion		Discussion
	P2P TCs that are one hop from the master use the PDelay_Req and		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		PDelay_Resp handshake to compute the link delay between the master
	and TC. These TCs are authenticated by 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 and peer TCs, by preventing the master
	master from serving unauthorized clocks.		from serving unauthorized clocks.
	4.1.5. PTP: Authentication of Announce Messages		5.1.5. PTP: Authentication and Authorization of Control 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. The authentication mechanism MUST also verify that
			the sender is authorized to be a master.
			Requirement
			The security mechanism for PTP MUST support authentication and
			authorization of Management messages.
			Requirement
			The security mechanism MAY support authentication and authorization
			of Signaling messages.
			Requirement Level
			The requirements in this subsection address the spoofing attack
			(Section 3.2.2. ), and the rogue master attack (Section 3 .2.4. ).
			The requirement level of the first two requirements is 'MUST' since
			in the absence of these requirements the protocol is exposed to
			attacks that are easy to implement and have a high impact.
			The requirement level of the third requirement is 'MAY' since its
			impact greatly depends on the application for which the Signaling
			messages are used for.
	Discussion		Discussion
	Master election is performed in PTP using the Best Master Clock		Master election is performed in PTP using the Best Master Clock
	Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock		Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock
	attributes using Announce messages, and the best master is elected		attributes using Announce messages, and the best master is elected
	based on the information gathered from all the candidates. Announce		based on the information gathered from all the candidates. Announce
	messages must be authenticated in order to prevent malicious master		messages must be authenticated in order to prevent rogue master
	attacks.		attacks (Section 3.2.4. ). Note, that this subsection specifies a
			requirement that is not necessarily included in Section 5.1.1. or in
			Section 5.1.3. , since the BMCA is initiated before clocks have been
			defined as masters or slaves.
	Note, that this subsection specifies a requirement that is not		Management messages are used to monitor or configure PTP clocks.
	necessarily included in 4.1.1. or in 4.1.3. , since the BMCA is		Malicious usage of Management messages enables various attacks, such
	initiated before clocks have been defined as masters or slaves.		as the rogue master attack, or DoS attack.
	4.2. Data integrity		Signaling messages are used by PTP clocks to exchange information
			that is not strictly related to time information or to master
			selection, such as unicast negotiation. Authentication and
			authorization of Signaling message may be required in some systems,
			depending on the application these messages are used for.
			5.2. Data integrity
	Requirement		Requirement
	The security mechanism MUST protect the integrity of protocol		The security mechanism MUST protect the integrity of protocol
	packets.		packets.
			Requirement Level
			The requirement in this subsection addresses the packet interception
			and manipulation attack (Section 3.2.1. ).
			The requirement level of this requirement is 'MUST' since in the
			absence of this requirement the protocol is exposed to attacks that
			are easy to implement and have a high impact.
	Discussion		Discussion
	While subsection 4.1. refers to ensuring WHO sent the protocol		While Section 5.1. refers to ensuring the identity an authorization
	packet, this subsection refers to ensuring that the packet arrived		of the source of a protocol packet, this subsection refers to
	intact. The integrity protection mechanism ensures the authenticity		ensuring that the packet arrived intact. The integrity protection
	and completeness of data from the data originator.		mechanism ensures the authenticity and completeness of data from the
			data originator.
	4.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
	Requirement		Requirement
	A security mechanism for PTP MUST support hop-by-hop integrity		A security mechanism for PTP MUST support hop-by-hop integrity
	protection.		protection.
	Requirement		Requirement
	A security mechanism for PTP SHOULD support end-to-end integrity		A security mechanism for PTP SHOULD support end-to-end integrity
	protection.		protection.
			Requirement Level
			The requirement in this subsection addresses the packet interception
			and manipulation attack (Section 3.2.1. ).
			The requirement level of the first requirement is 'MUST' since in the
			absence of this requirement the protocol is exposed to attacks that
			are easy to implement and have a high impact.
			The requirement level of the first requirement is 'SHOULD' since in
			the presence of recursive authentication (Section 5.1.2. ) this
			requirement may be redundant.
	Discussion		Discussion
	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.
	4.2.1.1. Hop by Hop Integrity Protection		5.2.1.1. Hop-by-Hop Integrity Protection
	Each hop that needs to modify a protocol packet:		Each hop that needs to modify a protocol packet:
	o Verifies its integrity.		o Verifies its integrity.
	o Modifies the packet, i.e., modifies the correctionField.		o Modifies the packet, i.e., modifies the correctionField.
	o Re-generates the integrity protection, e.g., re-computes a Message		o Re-generates the integrity protection, e.g., re-computes a Message
	Authentication Code.		Authentication Code.
	In the hop-by-hop approach, the integrity of protocol packets is		In the hop-by-hop approach, the integrity of protocol packets is
	protected by induction on the path from the originator to the		protected by induction on the path from the originator to the
	receiver.		receiver.
	This approach is simple, but allows malicious TCs to modify protocol		This approach is simple, but allows rogue TCs to modify protocol
	packets.		packets.
	4.2.1.2. End to End Integrity Protection		5.2.1.2. End-to-End Integrity Protection
	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. It should be noted that this approach is more difficult		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		to implement than the hop-by-hop approach, as it requires the
	layers of protection for the correctionField and for the rest of the		correctionField to be protected separately from the other fields of
	packet, using different cryptographic mechanisms and keys.		the packet, possibly using different cryptographic mechanisms and
			keys.
	4.3. Availability		5.3. Availability
	Requirement		Requirement
	The security mechanism MUST protect the time synchronization protocol		The security mechanism SHOULD include measures to mitigate DoS
	from DoS attacks by external attackers.		attacks against the time protocol.
			Requirement Level
			The requirement in this subsection prevents DoS attacks against the
			protocol (Section 3.2.9. ).
			The requirement level of this requirement is 'SHOULD' due to its low
			impact, i.e., in the absence of this requirement the protocol is only
			exposed to DoS.
	Discussion		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.
	spoofing attack (Section 3.2.2. ) or the rogue master attack (Section
	3.2.4. ), causing denial of service to the attackee. An
	authentication mechanism (Section 4.1. ) limits these attacks
	strictly to internal attackers, and thus prevents external attackers
	from performing them.
	Note that a security mechanism applied at the time synchronization		An attacker can inject protocol messages to implement the spoofing
	layer cannot, by itself, prevent DoS attacks described in Section		attack (Section 3.2.2. ) or the rogue master attack (Section 3.2.4.
	3.2.8. DoS attacks at lower layers of the protocol stack (Section		), causing DoS to the victim (Section 3.2.9. ). An authentication
	3.2.8. ) can still be implemented by external attackers even in the		mechanism (Section 5.1. ) limits these attacks strictly to internal
	presence of an authentication mechanism.		attackers, and thus prevents external attackers from performing them.
	4.4. Replay Protection		The DoS attacks described in Section 3.2.8. are performed at lower
			layers than the time synchronization protocol layer, and are thus
			outside the scope of the security requirements defined in this
			document.
			5.4. Replay Protection
	Requirement		Requirement
	Protocol messages MUST be resistant to replay attacks.		The security mechanism MUST include a replay prevention mechanism.
	4.5. Cryptographic Keys & Security Associations		Requirement Level
	4.5.1. Security Association		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.5.1. Key Freshness
			Requirement
			The cryptographic keys MUST be refreshed periodically.
			Requirement Level
			The requirement level of this requirement is 'MUST' since key
			freshness is an essential property for cryptographic algorithms, as
			discussed below.
			Discussion
			Key freshness guarantees that both sides share a common updated
			secret key. It also helps in preventing replay and playback attacks.
			Thus, it is important keys to be refreshed periodically.
			5.5.2. Security Association
	Requirement		Requirement
	The security protocol SHOULD 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.
			Requirement
			The association protocol SHOULD be periodically invoked. 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		Discussion
	The security requirements in 4.1. and 4.2. require usage of		The security requirements in Section 5.1. and Section 5 .2. require
	cryptographich mechanisms, deploying cryptographic keys. A security		usage of cryptographic mechanisms, deploying cryptographic keys. A
	association is an essential building block in these mechanisms.		security association is an essential building block in these
			mechanisms.
	4.5.2. Unicast and Multicast		5.5.3. Unicast and Multicast
	Requirement		Requirement
	The security mechanism SHOULD 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		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
	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		5.6. Performance
	Requirement
	The cryptographic keys MUST be refreshed periodically.
	Requirement
	The association protocol MUST be invoked periodically, where each
	instance of the association protocol MUST produce a different session
	key.
	4.6. Performance
	Requirement		Requirement
	The security mechanism MUST be designed in such a way that it does		The security mechanism MUST be designed in such a way that it does
	not degrade the quality of the time transfer.		not degrade the quality of the time transfer.
	Requirement		Requirement
	The mechanism SHOULD be relatively lightweight, as client		The mechanism SHOULD minimize computational load.
	restrictions often dictate a low processing and memory footprint, and
	because the server may have extensive fan-out.
	Requirement		Requirement
	The mechanism also SHOULD not require excessive storage of client		The mechanism also SHOULD minimize storage requirements of client
	state in the master, nor significantly increase bandwidth		state in the master, nor significantly increase bandwidth
	consumption.		consumption.
	Discussion		Discussion
			Performance efficiency is important since client restrictions often
			dictate a low processing and memory footprint, and because the server
			may have extensive fan-out.
	Note that the performance requirements refer to a time-		Note that the performance requirements refer to a time-
	synchronization-specific security mechanism. In systems where a		synchronization-specific security mechanism. In systems where a
	security protocol is used for other types of traffic as well, this		security protocol is used for other types of traffic as well, this
	document does not place any performance requirements on the security		document does not place any performance requirements on the security
	protocol performance. For example, if IPsec encryption is used for		protocol performance. For example, if IPsec encryption is used for
	securing all information between the master and slave node, including		securing all information between the master and slave node, including
	information that is not part of the time protocol, the requirements		information that is not part of the time protocol, the requirements
	in this subsection are not necessarily applicable.		in this subsection are not necessarily applicable.
	4.7. Confidentiality		5.7. Confidentiality
	Requirement		Requirement
	The security mechanism MAY provide confidentiality protection of the		The security mechanism MAY provide confidentiality protection of the
	protocol packets.		protocol packets.
			Requirement Level
			The requirement level of this requirement is 'MAY' since it does not
			prevent severe threats, as discussed below.
	Discussion		Discussion
	In the context of time synchronization, confidentiality is typically		In the context of time synchronization, confidentiality is typically
	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 their customers for time synchronization services, and thus an
	rather esoteric.		encryption mechanism can prevent eavesdroppers from obtaining the
			service without payment. Note that these cases are 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 MITM attacks such as packet delay (Section
	selectively adds delay to time protocol packets. Note, that time		3.2.6. ), manipulation and interception and removal attacks. Note,
	protocols have predictable behavior such as packet transmission rates		that time protocols have predictable behavior even after encryption,
	and packet lengths, and thus packet encryption does not prevent delay		such as packet transmission rates and packet lengths. Additional
	attacks, but rather makes these attacks more difficult to implement.		measure can be taken to mitigate encrypted traffic analysis by random
			padding of encrypted packets and by adding random dummy packets.
			Nevertheless, encryption does not prevent such MITM attacks, but
			rather makes these attacks more difficult to implement.
	4.8. Protection against packet delay attacks		5.8. Protection against Packet Delay and Interception Attacks
	Requirement		Requirement
	The security mechanism MAY include a means to detect packet delay		The security mechanism SHOULD include means to protect the protocol
	attacks.		from MITM attacks that degrade the clock accuracy.
	Requirement		Requirement Level
	The security mechanism MAY include a redundancy mechanism that allows		The requirements in this subsection address MITM attacks such as the
	a node that detects a delay attack to switch over to a secondary		3.2.1. ).
	master.
			The requirement level of this requirement is 'SHOULD'. In the absence
			of this requirement the protocol is exposed to attacks that are easy
			to implement and have a high impact. On the other hand, the
			implementation of this requirement depends on the topology and
			properties of the system, and is thus not necessarily applicable to
			all deployments.
	Discussion		Discussion
	While this document does not define specific security solutions, we		While this document does not define specific security solutions, we
	note that common practices for protection against delay attacks use		note that common practices for protection against MITM attacks use
	redundant masters (e.g. [NTPv4]), or redundant paths between the		redundant masters (e.g. [NTPv4]), or redundant paths between the
	master and slave (e.g. [DelayAtt]). If one of the time sources		master and slave (e.g. [DelayAtt]). If one of the time sources
	indicates a time value that is significantly different than the other		indicates a time value that is significantly different than the other
	sources, it is assumed to be erroneous or under attack, and is		sources, it is assumed to be erroneous or under attack, and is
	therefore ignored.		therefore ignored.
	This requirement is a "may" requirement since both master redundancy		Thus, MITM attack prevention derives a requirement from the security
	and path redundancy are not necessarily possible in all network		mechanism, and a requirement from the network topology. While the
	topologies.		security mechanism should support the ability to detect delay
			attacks, it is noted that in some networks it is not necessarily
			possible to provide the redundancy needed for such a detection
			mechanism.
	4.9. Combining Secured with Unsecured Nodes		5.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 incremental
	where new equipment supports the security mechanism, and is required		deployment, where new equipment supports the security mechanism, and
	to interoperate with legacy equipment without the security features.		is required to interoperate with legacy equipment without the
			security features.
	4.9.1. Secure Mode		5.9.1. Secure Mode
	Requirement		Requirement
	The security mechanism MUST support a secure mode, where only secured		The security mechanism MUST support a secure mode, where only secured
	clocks are permitted to take part in the synchronization protocol. A		clocks are permitted to take part in the synchronization protocol. A
	protocol packet received from an unsecured clock MUST be discarded.		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		Discussion
	While the requirement in this subsection is a bit similar to the one		While the requirement in this subsection is a bit similar to the one
	in 4.1. , it explicitly defines the secure mode, as opposed to the		in 5.1. , it explicitly defines the secure mode, as opposed to the
	hybrid mode presented in the next subsection.		hybrid mode presented in the next subsection.
	4.9.2. Hybrid Mode		5.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.
			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.
	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. NTP, for example, allows a mixture		in the synchronization protocol. NTP, for example, allows a mixture
	of secured and unsecured nodes.		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.
			Requirement Level
			The requirement level of this requirement is a 'SHOULD', since it may
			not be applicable to all deployments. For example, a hybrid network
			may require the usage of unsecured masters or TCs.
	Discussion		Discussion
	This requirement ensures that the existence of unsecured clocks does		This requirement ensures that the existence of unsecured clocks does
	not compromise the security provided to secured clocks. Hence,		not compromise the security provided to secured clocks. Hence,
	secured slaves only "trust" protocol packets received from a secured		secured slaves only "trust" protocol packets received from a secured
	clock. An unsecured clock can receive protocol packets from either		clock.
	secured clocks, or unsecured clocks.
			An unsecured slave can receive protocol packets either from unsecured
			clocks, or from secured clocks. Note that the latter does not apply
			when encryption is used. When integrity protection is used, the
			unsecured slave can receive secured packets ignoring the integrity
			protection.
	Note that the security scheme in [NTPv4] with [AutoKey] does not		Note that the security scheme in [NTPv4] with [AutoKey] does not
	satisfy this requirement, since nodes prefer the server with the best		satisfy this requirement, since nodes prefer the server with the most
	clock, and not necessarily the server that supports authentication.		accurate clock, and not necessarily the server that supports
	For example, a stratum 2 server is connected to two stratum 1		authentication. For example, a stratum 2 server is connected to two
	servers, Server A, supporting authentication, and server B, without		stratum 1 servers, Server A, supporting authentication, and server B,
	authentication. If server B has a more accurate clock than A, the		without authentication. If server B has a more accurate clock than A,
	stratum 2 server chooses server B, in spite of the fact it does not		the stratum 2 server chooses server B, in spite of the fact it does
	support authentication.		not support authentication.
	5. Summary of Requirements		6. Summary of Requirements
	+-----------+--------------------------------------+---------------+		+-----------+---------------------------------------------+--------+
	| Section | Requirement | Type |		| Section | Requirement | Type |
	+-----------+--------------------------------------+---------------+		+-----------+---------------------------------------------+--------+
	| 4.1. | Authentication of sender. | MUST |		| 5.1. | Authentication & authorization of sender. | MUST |
	| +--------------------------------------+---------------+		| +---------------------------------------------+--------+
	| | Authentication of master. | MUST |		| | Authentication & authorization of master. | MUST |
	| +--------------------------------------+---------------+		| +---------------------------------------------+--------+
	| | Recursive authentication. | MUST |		| | Recursive authentication & authorization. | MUST |
	| +--------------------------------------+---------------+		| +---------------------------------------------+--------+
	| | Authentication of slaves. | SHOULD |		| | Authentication of slaves. | MAY |
	| +--------------------------------------+---------------+		| +---------------------------------------------+--------+
	| | PTP: Authentication of TCs. | SHOULD |		| | PTP: Authentication of TCs by master. | MAY |
	| +--------------------------------------+---------------+		| +---------------------------------------------+--------+
	| | PTP: Authentication of Announce | SHOULD |		| | PTP: Authentication & authorization of | MUST |
	| | messages. | |		| | Announce messages. | |
	+-----------+--------------------------------------+---------------+		| +---------------------------------------------+--------+
	| 4.2. | Integrity protection. | MUST |		| | PTP: Authentication & authorization of | MUST |
	| +--------------------------------------+---------------+		| | Management messages. | |
	| | PTP: hop-by-hop integrity protection.| MUST |		| +---------------------------------------------+--------+
	| +--------------------------------------+---------------+		| | PTP: Authentication & authorization of | MAY |
	| | PTP: end-to-end integrity protection.| SHOULD |		| | Signaling messages. | |
	+-----------+--------------------------------------+---------------+		+-----------+---------------------------------------------+--------+
	| 4.3. | Protection against DoS attacks. | MUST |		| 5.2. | Integrity protection. | MUST |
	+-----------+--------------------------------------+---------------+		| +---------------------------------------------+--------+
	| 4.4. | Replay protection. | MUST |		| | PTP: hop-by-hop integrity protection. | MUST |
	+-----------+--------------------------------------+---------------+		| +---------------------------------------------+--------+
	| 4.5. | Security association. | SHOULD |		| | PTP: end-to-end integrity protection. | SHOULD |
	| +--------------------------------------+---------------+		+-----------+---------------------------------------------+--------+
	| | Unicast and multicast associations. | SHOULD |		| 5.3. | Protection against DoS attacks. | SHOULD |
	| +--------------------------------------+---------------+		+-----------+---------------------------------------------+--------+
	| | Key freshness. | MUST |		| 5.4. | Replay protection. | MUST |
	+-----------+--------------------------------------+---------------+		+-----------+---------------------------------------------+--------+
	| 4.6. | Performance: no degradation in | MUST |		| 5.5. | Key freshness. | MUST |
	| | quality of time transfer. | |		| +---------------------------------------------+--------+
	| +--------------------------------------+---------------+		| | Security association. | SHOULD |
	| | Performance: lightweight. | SHOULD |		| +---------------------------------------------+--------+
	| +--------------------------------------+---------------+		| | Unicast and multicast associations. | SHOULD |
	| | Performance: storage, bandwidth. | MUST |		+-----------+---------------------------------------------+--------+
	+-----------+--------------------------------------+---------------+		| 5.6. | Performance: no degradation in quality of | MUST |
	| 4.7. | Confidentiality protection. | MAY |		| | time transfer. | |
	+-----------+--------------------------------------+---------------+		| +---------------------------------------------+--------+
	| 4.8. | Protection against delay attacks. | MAY |		| | Performance: computation load. | SHOULD |
	+-----------+--------------------------------------+---------------+		| +---------------------------------------------+--------+
	| 4.9. | Secure mode. | MUST |		| | Performance: storage, bandwidth. | SHOULD |
	| +--------------------------------------+---------------+		+-----------+---------------------------------------------+--------+
	| | Hybrid mode. | MAY |		| 5.7. | Confidentiality protection. | MAY |
	+-----------+--------------------------------------+---------------+		+-----------+---------------------------------------------+--------+
			| 5.8. | Protection against delay and interception | SHOULD |
			| | attacks. | |
			+-----------+---------------------------------------------+--------+
			| 5.9. | Secure mode. | MUST |
			| +---------------------------------------------+--------+
			| | Hybrid mode. | MAY |
			+-----------+---------------------------------------------+--------+
	Table 2 Summary of Security Requirements		Table 2 Summary of Security Requirements
	6. Additional security implications		7. Additional security implications
	This section discusses additional implications of the interaction		This section discusses additional implications of the interaction
	between time synchronization protocols and security mechanisms.		between time synchronization protocols and security mechanisms.
	This section refers to time synchronization security mechanisms, as		This section refers to time synchronization security mechanisms, as
	well as to "external" security mechanisms, i.e., security mechanisms		well as to "external" security mechanisms, i.e., security mechanisms
	that are not strictly related to the time synchronization protocol.		that are not strictly related to the time synchronization protocol.
	6.1. Security and on-the-fly Timestamping		7.1. Security and on-the-fly Timestamping
	Time synchronization protocols often require protocol packets to be		Time synchronization protocols often require protocol packets to be
	modified during transmission and reception. Both NTP and PTP in one-		modified during transmission. Both NTP and PTP in one-step mode
	step mode require clocks to modify protocol packets with the time of		require clocks to modify protocol packets with the time of
	transmission or reception.		transmission.
	In the presence of a security mechanism, whether encryption or		In the presence of a security mechanism, whether encryption or
	integrity protection:		integrity protection:
	o During transmission the security protocol must be applied after		o During transmission the security protocol must be applied after
	integrating the timestamp into the packet.		integrating the timestamp into the packet.
	o During reception, the encryption or integrity check must be
	performed before modifying the packet with the time of reception.
	To allow high accuracy, timestamping is typically performed as close		To allow high accuracy, timestamping is typically performed as close
	to the transmission or reception time as possible. However, since the		to the transmission or reception time as possible. However, since the
	security engine must be placed between the timestamping function and		security engine must be placed between the timestamping function and
	the physical interface, in some cases it may introduce non-		the physical interface, it may introduce non-deterministic latency
	deterministic latency that causes accuracy degradation. These		that causes accuracy degradation. These performance aspects have been
	performance aspects have been analyzed in the literature, e.g., in		analyzed in the literature, e.g., in [1588IPsec] and [Tunnel].
	[1588IPsec] and [Tunnel].
	6.2. Security and Two-Step Timestamping		7.2. PTP: 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 of protocol packets is communicated without modifying
	measured without modifying the packets. As opposed to one-step mode,		the packets. As opposed to one-step mode, two-step timestamping can
	two step timestamping can be performed at the physical interface even		be performed without the requirement to encrypt after timestamping.
	in the presence of a security mechanism.
	Note that if an encryption mechanism such as IPsec is used, it		Note that if an encryption mechanism such as IPsec is used, it
	presents a challenge to the timestamping mechanism, since time		presents a challenge to the timestamping mechanism, since time
	protocol packets are encrypted when traversing the physical		protocol packets are encrypted when traversing the physical
	interface, and are thus impossible to identify. A possible solution		interface, and are thus impossible to identify. A possible solution
	to this problem [IPsecSync] is to include an indication in the		to this problem [IPsecSync] is to include an indication in the
	encryption header that identifies time synchronization packets.		encryption header that identifies time synchronization packets.
	6.3. Intermediate Clocks		7.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
	servers are a layer of intermediate clocks.		servers are a layer of intermediate clocks.
	o In PTP, BCs and TCs are intermediate nodes used to improve the		o In PTP, BCs and TCs are intermediate nodes used to improve the
	accuracy of time information conveyed between the grandmaster and		accuracy of time information conveyed between the grandmaster and
	the slaves.		the slaves.
	A common rule of thumb in network security is that end-to-end		A common rule of thumb in network security is that end-to-end
	security is the best policy, as it secures the entire path between		security is the best policy, as it secures the entire path between
	the data originator and its receiver. The usage of intermediate nodes		the data originator and its receiver. The usage of intermediate nodes
	implies that if a security mechanism is deployed in the network, all		implies that if a security mechanism is deployed in the network, all
	intermediate nodes must be exposed to the security key since they		intermediate nodes must possess the security key (hop-by-hop
	must be able to send time information to the slaves, or to modify		security) since they must be able to send time information to the
	time information sent through them.		slaves, or to modify time information sent through them.
	This inhehrent property of using intermediate clocks increases the		This inherent property of using intermediate clocks increases the
	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 possess the security keys.
	6.4. The Effect of External Security Protocols on Time Synchronization		Thus, there is a tradeoff between the achievable clock accuracy of a
			system, and the robustness of its security solution. On one hand high
			clock accuracy calls for hop-by-hop involvement in the protocol, also
			known as on-path support. On the other hand, a robust security
			solution calls for end-to-end data protection.
			7.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. In some cases, all traffic between these two nodes may be		Gateway. In some cases, all traffic between these two nodes may be
	secured by IPsec, including the time synchronization protocol		secured by IPsec, including the time synchronization protocol
	traffic. This use-case is 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 ([MACsec])
	networks that deploy time synchronization [AvbAssum].		in L2 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 7.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		7.5. External Security Services Requiring Time Synchronization
			7.5.1. Timestamped Certificates
	Certificate validation requires the sender and receiver to be roughly		Certificate validation requires the sender and receiver to be roughly
	time 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. This bootstrapping
			behavior results from the fact that trusting the received time
			information requires a valid certificate, and validating a
			certificate requires knowledge of the time.
	7. Issues for Further Discussion		7.5.2. Time Synchronization as a Vulnerability
	o The key distribution is outside the scope of this document.		Cryptographic protocols often use time as an important factor in the
	Although this is a cardinal element in any security system, it is		cryptographic algorithm. If a time synchronization protocol is
	not a security requirement, and is thus not described here.		compromised, it may consequently cause expose the security protocols
			that rely on it to various attacks.
	8. Security Considerations		For example, a successful attack on a time synchronization protocol
			may cause the attacked clocks to be synchronized to an early time.
			This erroneous time may expose cryptographic algorithms that rely on
			time to replay attacks.
			8. Issues for Further Discussion
			The key distribution is outside the scope of this document. Although
			this is an essential element of any security system, it is outside
			the scope of this document.
			9. Security Considerations
	The security considerations of network timing protocols are presented		The security considerations of network timing protocols are presented
	throughout this document.		throughout this document.
	9. IANA Considerations		10. IANA Considerations
	There are no new IANA considerations implied by this document.		There are no new IANA considerations implied by this document.
	10. Acknowledgments		11. Acknowledgments
	The authors gratefully acknowledge Stefano Ruffini, Dieter Sibold and		The authors gratefully acknowledge Stefano Ruffini, Doug Arnold,
	Dan Grossman for their thorough review and helpful comments. The		Kevin Gross, Dieter Sibold, Dan Grossman and Laurent Montini for
	authors would also like to thank members of the TICTOC WG for		their thorough review and helpful comments. The authors would also
	providing feedback on the TICTOC mailing list.		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		12. References
	11.1. Normative References		12.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., Martin, J., Burbank, J., Kasch, W.,		[NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W.,
	"Network Time Protocol Version 4: Protocol and		"Network Time Protocol Version 4: Protocol 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.
	[IEEE1588] IEEE TC 9 Test and Measurement Society 2000, "1588		[IEEE1588] IEEE TC 9 Instrumentation and Measurement Society,
	IEEE Standard for a Precision Clock Synchronization		"1588 IEEE Standard for a Precision Clock
	Protocol for Networked Measurement and Control Systems		Synchronization Protocol for Networked Measurement and
	Version 2", IEEE Standard, 2008.		Control Systems Version 2", IEEE Standard, 2008.
	11.2. Informative References		12.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 24, line 5		skipping to change at page 32, line 19
	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		[DelayAtt] T. Mizrahi, "A Game Theoretic Analysis of Delay
	Attacks against Time Synchronization Protocols",		Attacks against Time Synchronization Protocols",
	accepted, to appear in Proceedings of the		accepted, to appear in Proceedings of the
	International IEEE Symposium on Precision Clock		International IEEE Symposium on Precision Clock
	Synchronization for Measurement, Control and		Synchronization for Measurement, Control and
	Communication, ISPCS, 2012.		Communication, ISPCS, 2012.
	12. Contributing Authors		[MACsec] IEEE 802.1AE-2006, "IEEE Standard for Local and
			Metropolitan Area Networks - Media Access Control
			(MAC) Security", 2006.
			[IPsec] S. Kent, K. Seo, "Security Architecture for the
			Internet Protocol", IETF, RFC 4301, 2005.
			13. Contributing Authors
	Karen O'Donoghue		Karen O'Donoghue
	ISOC		ISOC
	Email: odonoghue@isoc.org		Email: odonoghue@isoc.org
	Authors' Addresses		Authors' Addresses
	Tal Mizrahi		Tal Mizrahi
	Marvell		Marvell
End of changes. 143 change blocks.
	378 lines changed or deleted		774 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/