draft-ietf-tictoc-security-requirements-04.txt		draft-ietf-tictoc-security-requirements-05.txt
	TICTOC Working Group Tal Mizrahi		TICTOC Working Group Tal Mizrahi
	Internet Draft Marvell		Internet Draft Marvell
	Intended status: Informational		Intended status: Informational
	Expires: August 2013 February 7, 2013		Expires: October 2013 April 25, 2013
	Security Requirements of Time Synchronization Protocols		Security Requirements of Time Protocols
	in Packet Switched Networks		in Packet Switched Networks
	draft-ietf-tictoc-security-requirements-04.txt		draft-ietf-tictoc-security-requirements-05.txt
	Abstract		Abstract
	As time synchronization protocols are becoming increasingly common		As time and frequency distribution protocols are becoming
	and widely deployed, concern about their exposure to various security		increasingly common and widely deployed, concern about their exposure
	threats is increasing. This document defines a set of security		to various security threats is increasing. This document defines a
	requirements for time synchronization protocols, focusing on the		set of security requirements for time protocols, focusing on the
	Precision Time Protocol (PTP) and the Network Time Protocol (NTP).		Precision Time Protocol (PTP) and the Network Time Protocol (NTP).
	This document also discusses the security impacts of time		This document also discusses the security impacts of time protocol
	synchronization protocol practices, the time synchronization		practices, the performance implications of external security
	performance implications of external security practices, the		practices on time protocols and the dependencies between other
	dependencies between other security services and time		security services and time synchronization.
	synchronization.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 45		skipping to change at page 1, line 44
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 7, 2013.		This Internet-Draft will expire on October 25, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	skipping to change at page 2, line 27		skipping to change at page 2, line 27
	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 ............................ 5		2. Conventions Used in this Document ............................ 5
	2.1. Terminology ............................................. 5		2.1. Terminology ............................................. 5
	2.2. Abbreviations ........................................... 5		2.2. Abbreviations ........................................... 5
	2.3. Common Terminology for PTP and NTP ...................... 5		2.3. Common Terminology for PTP and NTP ...................... 5
	2.4. Terms used in this Document ............................. 5		2.4. Terms used in this Document ............................. 6
	3. Security Threats ............................................. 6		3. Security Threats ............................................. 7
	3.1. Threat Model ............................................ 7		3.1. Threat Model ............................................ 7
	3.1.1. Internal vs. External Attackers .................... 7		3.1.1. Internal vs. External Attackers .................... 7
	3.1.2. Man in the Middle (MITM) vs. Packet Injector ....... 7		3.1.2. Man in the Middle (MITM) vs. Packet Injector ....... 8
	3.2. Threat Analysis.......................................... 8		3.2. Threat Analysis.......................................... 8
	3.2.1. Packet Interception and Manipulation ............... 8		3.2.1. Packet Interception and Manipulation ............... 8
	3.2.2. Spoofing ........................................... 8		3.2.2. Spoofing ........................................... 8
	3.2.3. Replay Attack ...................................... 8		3.2.3. Replay Attack ...................................... 8
	3.2.4. Rogue Master Attack ................................ 8		3.2.4. Rogue Master Attack ................................ 8
	3.2.5. Packet Interception and Removal .................... 9		3.2.5. Packet Interception and Removal .................... 9
	3.2.6. Packet Delay Manipulation .......................... 9		3.2.6. Packet Delay Manipulation .......................... 9
	3.2.7. Cryptographic Performance Attacks .................. 9		3.2.7. L2/L3 DoS Attacks .................................. 9
	3.2.8. L2/L3 DoS Attacks .................................. 9		3.2.8. Cryptographic Performance Attacks .................. 9
	3.2.9. DoS Attacks against the Time Protocol .............. 9		3.2.9. DoS Attacks against the Time Protocol ............. 10
	3.2.10. Grandmaster Time Source Spoofing (e.g. GPS fraud) . 9		3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud) . 10
	3.3. Threat Analysis Summary ................................ 10		3.3. Threat Analysis Summary ................................ 10
	4. Requirement Levels .......................................... 11		4. Requirement Levels .......................................... 12
	5. Security Requirements ....................................... 12		5. Security Requirements ....................................... 12
	5.1. Clock Identity Authentication and Authorization ........ 12		5.1. Clock Identity Authentication and Authorization ........ 13
	5.1.1. Authentication and Authorization of Masters ....... 13		5.1.1. Authentication and Authorization of Masters ....... 14
	5.1.2. Recursive Authentication and Authorization of Masters		5.1.2. Recursive Authentication and Authorization of Masters
	(Chain of Trust) ......................................... 14		(Chain of Trust) ......................................... 14
	5.1.3. Authentication and Authorization of Slaves ........ 15		5.1.3. Authentication and Authorization of Slaves ........ 15
	5.1.4. PTP: Authentication and Authorization of Transparent		5.1.4. PTP: Authentication and Authorization of PTP TCs by the
	Clocks by Master ......................................... 15		Master ................................................... 16
	5.1.5. PTP: Authentication and Authorization of Control		5.1.5. PTP: Authentication and Authorization of Control
	Messages ................................................. 16		Messages ................................................. 17
	5.2. Data integrity ......................................... 17		5.2. Protocol Packet Integrity .............................. 18
	5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 18		5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 18
	5.2.1.1. Hop-by-Hop Integrity Protection .............. 18		5.2.1.1. Hop-by-Hop Integrity Protection .............. 19
	5.2.1.2. End-to-End Integrity Protection .............. 19		5.2.1.2. End-to-End Integrity Protection .............. 19
	5.3. Availability ........................................... 19		5.3. Availability ........................................... 20
	5.4. Replay Protection ...................................... 20		5.4. Replay Protection ...................................... 20
	5.5. Cryptographic Keys and Security Associations ........... 20		5.5. Cryptographic Keys and Security Associations ........... 21
	5.5.1. Key Freshness ..................................... 20		5.5.1. Key Freshness ..................................... 21
	5.5.2. Security Association .............................. 21		5.5.2. Security Association .............................. 21
	5.5.3. Unicast and Multicast ............................. 21		5.5.3. Unicast and Multicast Associations ................ 22
	5.6. Performance ............................................ 22		5.6. Performance ............................................ 22
	5.7. Confidentiality......................................... 22		5.7. Confidentiality......................................... 23
	5.8. Protection against Packet Delay and Interception Attacks 23		5.8. Protection against Packet Delay and Interception Attacks 24
	5.9. Combining Secured with Unsecured Nodes ................. 24		5.9. Combining Secured with Unsecured Nodes ................. 25
	5.9.1. Secure Mode ....................................... 24		5.9.1. Secure Mode ....................................... 25
	5.9.2. Hybrid Mode ....................................... 24		5.9.2. Hybrid Mode ....................................... 25
	6. Summary of Requirements ..................................... 26		6. Summary of Requirements ..................................... 26
	7. Additional security implications ............................ 27		7. Additional security implications ............................ 28
	7.1. Security and on-the-fly Timestamping ................... 27		7.1. Security and on-the-fly Timestamping ................... 28
	7.2. PTP: Security and Two-Step Timestamping ................ 28		7.2. PTP: Security and Two-Step Timestamping ................ 28
	7.3. Intermediate Clocks .................................... 28		7.3. Intermediate Clocks .................................... 29
	7.4. The Effect of External Security Protocols on Time		7.4. External Security Protocols and Time Protocols.......... 30
	Synchronization ............................................. 29		7.5. External Security Services Requiring Time .............. 30
	7.5. External Security Services Requiring Time Synchronization29		7.5.1. Timestamped Certificates .......................... 30
	7.5.1. Timestamped Certificates .......................... 29		7.5.2. Time Changes and Replay Attacks ................... 31
	7.5.2. Time Synchronization as a Vulnerability ........... 30		8. Issues for Further Discussion ............................... 31
	8. Issues for Further Discussion ............................... 30		9. Security Considerations ..................................... 31
	9. Security Considerations ..................................... 30		10. IANA Considerations......................................... 31
	10. IANA Considerations......................................... 30		11. Acknowledgments ............................................ 31
	11. Acknowledgments ............................................ 30		12. References ................................................. 31
	12. References ................................................. 30		12.1. Normative References .................................. 31
	12.1. Normative References .................................. 30		12.2. Informative References ................................ 32
	12.2. Informative References ................................ 31		13. Contributing Authors ....................................... 33
	13. Contributing Authors ....................................... 32
	1. Introduction		1. Introduction
	As time synchronization protocols are becoming increasingly common		As time protocols are becoming increasingly common and widely
	and widely deployed, concern about the resulting exposure to various		deployed, concern about the resulting exposure to various security
	security threats is increasing. If a time synchronization protocol is		threats is increasing. If a time protocol is compromised, the
	compromised, the applications it serves are prone to a range of		applications it serves are prone to a range of possible attacks
	possible attacks including Denial-of-Service (DoS) or incorrect		including Denial-of-Service (DoS) or incorrect behavior.
	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]. [IEEE1588] 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.
	While NTP includes an inherent security protocol, the absence of a		While NTP includes an inherent security protocol, the absence of a
	skipping to change at page 4, line 26		skipping to change at page 4, line 26
	in some cases security mechanisms may not be strictly necessary,		in some cases security mechanisms may not be strictly necessary,
	e.g., due to other security practices in place, or due to the		e.g., due to other security practices in place, or due to the
	architecture of the network. A time synchronization security		architecture of the network. A time synchronization security
	solution, much like any security solution, is comprised of various		solution, much like any security solution, is comprised of various
	building blocks, and must be carefully tailored for the specific		building blocks, and must be carefully tailored for the specific
	system it is deployed in. Based on a system-specific threat		system it is deployed in. Based on a system-specific threat
	assessment, the benefits of a security solution must be weighed		assessment, the benefits of a security solution must be weighed
	against the potential risks, and based on this tradeoff an optimal		against the potential risks, and based on this tradeoff an optimal
	security solution can be selected.		security solution can be selected.
	This document attempts to add clarity to the time synchronization		The target audience of this document includes:
	protocol security requirements discussion by addressing a series of
	questions:		o Timing and networking equipment vendors - can benefit from this
			document by deriving the security features that should be
			supported in the time/networking equipment.
			o Standard development organizations - can use the requirements
			defined in this document when specifying security mechanisms for a
			time protocol.
			o Network operators - can use this document as a reference when
			designing the network and its security architecture. As stated
			above, the requirements in this document may be deployed
			selectively based on a careful per-system threat analysis.
			This document attempts to add clarity to the time protocol security
			requirements discussion by addressing a series of 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		protocol, and thus what security services need to be provided? (e.g.
	provided? (e.g. a malicious NTP server or PTP master)		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 time protocol traffic path)
			(3) What are the security impacts of time protocol practices? (e.g.
	(3) What are the security impacts of time synchronization protocol		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 protocols? (e.g. which comes first - the certificate or the
	the timestamp?)		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 protocols, focusing on
	protocols, focusing on PTP and NTP.		PTP and NTP.
	2. Conventions Used in this Document		2. Conventions Used in this Document
	2.1. Terminology		2.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [KEYWORDS].		document are to be interpreted as described in [KEYWORDS].
	This document describes security requirements, and thus requirements		This document describes security requirements, and thus requirements
	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 with which every security mechanism should comply.
	2.2. Abbreviations		2.2. Abbreviations
	BC Boundary Clock		BC Boundary Clock
	DoS Denial of Service		DoS Denial of Service
	MITM Man In The Middle		MITM Man In The Middle
	NTP Network Time Protocol		NTP Network Time Protocol
	skipping to change at page 5, line 40		skipping to change at page 6, line 4
	PTP Precision Time Protocol		PTP Precision Time Protocol
	TC Transparent Clock		TC Transparent Clock
	2.3. Common Terminology for PTP and NTP		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 term "protocol
	refers to masters, slaves and PTP Transparent Clocks (TC). The term		packets" refers generically to PTP and NTP messages.
	"protocol packets" refers generically to PTP and NTP messages.
	2.4. Terms used in this Document		2.4. Terms used in this Document
			o Clock - A node participating in the protocol (either PTP or NTP).
			A clock can be a master, a slave, or an intermediate clock (see
			corresponding definitions below).
	o Control packets - Packets used by the protocol to exchange		o Control packets - Packets used by the protocol to exchange
	information between clocks that is not strictly related to the		information between clocks that is not strictly related to the
	time. NTP uses NTP Control Messages. PTP uses Announce, Signaling		time. NTP uses NTP Control Messages. PTP uses Announce, Signaling
	and Management messages.		and Management messages.
	o End-to-end security - A security approach where secured packets		o End-to-end security - A security approach where secured packets
	sent from a source to a destination is not modified by		sent from a source to a destination is not modified by
	intermediate nodes.		intermediate nodes.
	o Grandmaster - A master that receives time information from a		o Grandmaster - A master that receives time information from a
	skipping to change at page 6, line 50		skipping to change at page 7, line 17
	slave OC, or to a port of a BC that is in the slave state.		slave OC, or to a port of a BC that is in the slave state.
	o Time packets - Protocol packets carrying time information.		o Time packets - Protocol packets carrying time information.
	o Unsecured clock - A clock that does not support a security		o Unsecured clock - A clock that does not support a security
	mechanism according to the requirements in this document.		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 protocols.
	The literature is rich with security threats of time synchronization		The literature is rich with security threats of time protocols, e.g.,
	protocols, e.g., [Traps], [AutoKey], [TM], [SecPTP], and [SecSen].		[Traps], [AutoKey], [TM], [SecPTP], and [SecSen]. The threat analysis
	The threat analysis in this document is mostly based on [TM].		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 protocol can be attacked by various types of attackers.
	attackers.
	The analysis in this document 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 Section 3.1.1. and Section 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 protocol is secured either by an
	either by an encryption or an authentication mechanism, or both.		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. An		network, or possess the encryption or authentication keys. An
	internal attack can also be performed by exploiting vulnerabilities		internal attack can also be performed by exploiting vulnerabilities
	in devices; for example, by installing malware, or obtaining		in devices; for example, by installing malware, or obtaining
	credentials to reconfigure the device. Thus, an internal attacker can		credentials to reconfigure the device. Thus, an internal attacker can
	maliciously tamper with legitimate traffic in the network, as well as		maliciously tamper with legitimate traffic in the network, as well as
	generate its own traffic and make it appear legitimate to its		generate its own traffic and make it appear legitimate to its
	attacked nodes.		attacked nodes.
	skipping to change at page 8, line 18		skipping to change at page 8, line 32
	A packet interception and manipulation attack results when an MITM		A packet interception and manipulation attack results when an MITM
	attacker intercepts timing protocol packets, alters them and relays		attacker intercepts timing protocol packets, alters them and relays
	them to their destination, allowing the attacker to maliciously		them to their destination, allowing the attacker to maliciously
	tamper with the protocol. This can result in a situation where the		tamper with the protocol. This can result in a situation where the
	time protocol is apparently operational but providing intentionally		time protocol is apparently operational but providing 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 injector masquerades as a legitimate node in the
	network by generating and transmitting protocol packets. For example,		network by generating and transmitting protocol packets or control
	an attacker can impersonate the master, allowing malicious		packets. For example, an attacker can impersonate the master,
	distribution of false timing information. As with packet interception		allowing malicious distribution of false timing information. As with
	and manipulation, this can result in a situation where the time		packet interception and manipulation, this can result in a situation
	protocol is apparently operational but providing intentionally		where the time protocol is apparently operational but providing
	inaccurate information.		intentionally inaccurate information.
	3.2.3. Replay Attack		3.2.3. Replay Attack
	In a replay attack, an attacker records protocol packets and replays		In a replay attack, an attacker records protocol packets and replays
	them at a later time 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
	skipping to change at page 9, line 9		skipping to change at page 9, line 19
	In PTP, a possible variant of this attack is the rogue TC/BC attack.		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		Similar to the rogue master attack, an attacker can cause victims to
	believe it is a legitimate TC or BC, allowing the attacker to		believe it is a legitimate TC or BC, allowing the attacker to
	manipulate the time information forwarded to the victims.		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 an MITM		A packet interception and removal attack results when an MITM
	attacker intercepts and drops protocol packets, preventing the		attacker intercepts and drops protocol packets, preventing the
	destination node from receiving the some or all of the protocol		destination node from receiving some or all of the protocol packets.
	packets.
	3.2.6. Packet Delay Manipulation		3.2.6. Packet Delay Manipulation
	In a packet delay manipulation scenario, an MITM attacker intercepts		In a packet delay manipulation scenario, an MITM attacker intercepts
	protocol packets, and relays them to their destination after adding a		protocol packets, and relays them to their destination after adding a
	maliciously computed delay.		maliciously computed delay. The attacker can use various delay attack
			strategies; the added delay can be constant, jittered, or slowly
			wandering. Each of these strategies has a different impact, but they
			all effectively manipulate the attacked clock.
	Note that the victim still receives one copy of each packet, contrary		Note that the victim still receives one copy of each packet, contrary
	to the replay attack, where some or all of the packets may be		to the replay attack, where some or all of the packets may be
	received by the victim more than once.		received by the victim more than once.
	3.2.7. Cryptographic Performance Attacks		3.2.7. L2/L3 DoS Attacks
			There are many possible Layer 2 and Layer 3 DoS attacks. As the
			target's availability is compromised, the timing protocol is affected
			accordingly.
			3.2.8. 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 packets, causing high utilization of the cryptographic
	at the receiver, which attempts to verify the integrity of these fake		engine at the receiver, which attempts to verify the integrity of
	packets.		these fake packets.
	This DoS attack is applicable to all encryption and authentication		This DoS attack is applicable to all encryption and authentication
	protocols. However, when the time protocol uses a dedicated security		protocols. However, when the time protocol uses a dedicated security
	mechanism implemented in a dedicated cryptographic engine, this		mechanism implemented in a dedicated cryptographic engine, this
	attack can be applied to cause DoS specifically to the time protocol		attack can be applied to cause DoS specifically to the time protocol
	3.2.8. L2/L3 DoS Attacks
	There are many possible Layer 2 and Layer 3 DoS attacks. As the
	target's availability is compromised, the timing protocol is affected
	accordingly.
	3.2.9. DoS Attacks against the Time Protocol		3.2.9. DoS Attacks against the Time Protocol
	An attacker can attack a clock using an excessive number of time		An attacker can attack a clock by sending an excessive number of time
	protocol packets, thus degrading the victim's performance. This		protocol packets, thus degrading the victim's performance. This
	attack can be implemented, for example, using the attacks described		attack can be implemented, for example, using the attacks described
	in 3.2.2. and 3 .2.4.		in Section 3.2.2. and Section 3.2.4.
	3.2.10. Grandmaster Time Source Spoofing (e.g. GPS fraud)		3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud)
	In time source spoofing, an attacker spoofs the accurate time source		Grandmasters receive their time from an external accurate time
	of the grandmaster. For example, if the grandmaster uses a GPS based		source, such as an atomic clock or a GPS clock, and then distribute
	clock as its reference source, an attacker can spoof GPS satellite		this time to the slaves using the time protocol.
	signals, causing the grandmaster to use a false reference time.
	Note that this attack is outside the scope of the time		Time source attack are aimed at the accurate time source of the
	synchronization protocol. While various security measures can be		grandmaster. For example, if the grandmaster uses a GPS based clock
	taken to mitigate this attack, these measures are outside the scope		as its reference source, an attacker can jam the reception of the GPS
	of the security requirements defined in this document.		signal, or transmit a signal similar to one from a GPS satellite,
			causing the grandmaster to use a false reference time.
			Note that this attack is outside the scope of the time 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 impact 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 Section 3.2.
	attack, the table specifies its impact, and its applicability to each		For each attack, the table specifies its impact, and its
	of the attacker types presented in 3.1.		applicability to each of the attacker types presented in Section 3.1.
	Table 1 clearly shows the distinction between external and internal		Table 1 clearly shows the distinction between external and internal
	attackers, and motivates the usage of authentication and integrity		attackers, and motivates the usage of authentication and integrity
	protection, significantly reducing the impact of external attackers.		protection, significantly reducing the impact of external attackers.
	The Impact column provides an intuition to the severity of each		The Impact column provides an intuitive measure of the severity of
	attack, and the relevant Attacker Type columns provide an intuition		each attack, and the relevant Attacker Type columns provide an
	about the how difficult each attack is to implement, and hence about		intuition about how difficult each attack is to implement, and hence
	the likelihood of each attack.		about 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 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 protocol.
	protocol.
	o Accuracy degradation - the attack yields a degradation in the		o Accuracy degradation - the attack yields a degradation in the
	slave accuracy, but does not completely compromise the slaves'		slave accuracy, but does not completely compromise the slaves'
	time and frequency.		time and frequency.
	o False time - slaves align to a false time or frequency value due		o False time - slaves align to a false time or frequency value due
	to the attack. Note that if the time synchronization service		to the attack. Note that if the time protocol aligns to a false
	aligns to a false time, it may cause DoS to other applications		time, it may cause DoS to other applications that rely on accurate
	that rely on accurate time. However, for the purpose of the		time. However, for the purpose of the analysis in this section we
	analysis in this section we distinguish this implication from		distinguish this implication from 'DoS', which refers to a DoS
	'DoS', which refers to a DoS attack that is not necessarily aimed		attack that is not necessarily aimed at the time protocol.
	at the time synchronization protocol.
	All attacks that have a '+' for 'False Time' implicitly have a '+'		All attacks that have a '+' for 'False Time' implicitly have a '+'
	for 'Accuracy Degradation'.		for 'Accuracy Degradation'.
	The Attacker Type columns refer to the 4 possible combinations of the		The Attacker Type columns refer to the 4 possible combinations of the
	attacker types defined in 3.1.		attacker types defined in Section 3.1.
	+-----------------------------+-------------------++-------------------+		+-----------------------------+-------------------++-------------------+
	| Attack | Impact || Attacker Type |		| Attack | Impact || Attacker Type |
	| +-----+--------+----++---------+---------+		| +-----+--------+----++---------+---------+
	| |False|Accuracy| ||Internal |External |		| |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 | | | + || + | + | + | + |
	+-----------------------------+-----+--------+----++----+----+----+----+
	|L2/L3 DoS attacks | | | + || + | + | + | + |		|L2/L3 DoS attacks | | | + || + | + | + | + |
	+-----------------------------+-----+--------+----++----+----+----+----+		+-----------------------------+-----+--------+----++----+----+----+----+
	|Time Protocol DoS attacks | | | + || + | + | | |		|Crypt. performance attacks | | | + || + | + | + | + |
	+-----------------------------+-----+--------+----++----+----+----+----+		+-----------------------------+-----+--------+----++----+----+----+----+
	|Master Time source spoofing | + | | || + | + | + | + |		|Time protocol DoS attacks | | | + || + | + | | |
	|(e.g. GPS spoofing) | | | || | | | |		+-----------------------------+-----+--------+----++----+----+----+----+
			|Master time source attack | + | | || + | + | + | + |
			|(e.g., GPS spoofing) | | | || | | | |
	+-----------------------------+-----+--------+----++----+----+----+----+		+-----------------------------+-----+--------+----++----+----+----+----+
	Table 1 Threat Analysis - Summary		Table 1 Threat Analysis - Summary
	The threats discussed in this section provide the background for the		The threats discussed in this section provide the background for the
	security requirements presented in Section 5 .		security requirements presented in Section 5.
	4. Requirement Levels		4. Requirement Levels
	The security requirements are presented in Section 5 . Each		The security requirements are presented in Section 5. Each
	requirement is defined with a requirement level, in accordance with		requirement is defined with a requirement level, in accordance with
	the requirement levels defined in [KEYWORDS].		the requirement levels defined in Section 2.1.
	The requirement levels in this document are affected by the following		The requirement levels in this document are affected by the following
	factors:		factors:
	o Impact:		o Impact:
	The possible impact of not implementing the requirement, as		The possible impact of not implementing the requirement, as
	illustrated in the 'impact' column of Table 1.		illustrated in the 'impact' column of Table 1.
	For example, a requirement that addresses a threat that can be		For example, a requirement that addresses a threat that can be
	implemented by an external injector is typically a 'MUST', since		implemented by an external injector is typically a 'MUST', since
	the threat can be implemented by all the attacker types analyzed		the threat can be implemented by all the attacker types analyzed
	skipping to change at page 12, line 31		skipping to change at page 12, line 41
	compromises the availability of the protocol is typically no more		compromises the availability of the protocol is typically no more
	than a 'SHOULD'.		than a 'SHOULD'.
	o Practical considerations:		o Practical considerations:
	Various practical factors that may affect the requirement.		Various practical factors that may affect the requirement.
	For example, if a requirement is very difficult to implement, or		For example, if a requirement is very difficult to implement, or
	is applicable to very specific scenarios, these factors may reduce		is applicable to very specific scenarios, these factors may reduce
	the requirement level.		the requirement level.
	Section 5. lists the requirements. For each requirement there is a		Section 5. lists the requirements. For each requirement there is a
	short explanation about the reason for its requirement level.		short explanation detailing the reason for its requirement level.
	5. Security Requirements		5. Security Requirements
	This section defines the requirements of security mechanisms used for		This section defines a set of security requirements. These
	time synchronization protocols.		requirements are phrased in the form "the security mechanism
	These requirements are phrased in the form "the security mechanism
	MUST/SHOULD/MAY...". However, this document does not specify how		MUST/SHOULD/MAY...". However, this document does not specify how
	these requirements can be met. While these requirements can be		these requirements can be met. While these requirements can be
	satisfied by defining explicit security mechanisms for time		satisfied by defining explicit security mechanisms for time
	protocols, at least a subset of the requirements can be met by		protocols, at least a subset of the requirements can be met by
	applying common security practices to the network or by using		applying common security practices to the network or by using
	existing security protocols, such as [IPsec] or [MACsec]. Thus,		existing security protocols, such as [IPsec] or [MACsec]. Thus,
	security solutions that address these requirements are outside the		security solutions that address these requirements are outside the
	scope of this document.		scope of this document.
	5.1. Clock Identity Authentication and Authorization		5.1. Clock Identity Authentication and Authorization
	Requirement		Requirement
	The security mechanism MUST provide a means for each clock to
	authenticate the sender of a protocol packet.		The security mechanism MUST support authentication.
	Requirement		Requirement
	The security mechanism MUST provide a means for each clock to verify		The security mechanism MUST support authorization.
	that the sender of a protocol packet is authorized to send a packet
	of this type.
	Requirement Level		Requirement Level
	The requirements in this subsection address the spoofing attack		The requirements in this subsection address the spoofing attack
	(Section 3.2.2. ), and the rogue master attack (Section 3 .2.4. ).		(Section 3.2.2.), and the rogue master attack (Section 3.2.4.).
	The requirement level of these requirements is 'MUST' since in the		The requirement level of these requirements is 'MUST' since in the
	absence of these requirements the protocol is exposed to attacks that		absence of these requirements the protocol is exposed to attacks that
	are easy to implement and have a high impact.		are easy to implement and have a high impact.
	Discussion		Discussion
	Authentication refers to verifying the identity of the peer clock.		Authentication refers to verifying the identity of the peer clock.
	Authorization, on the other hand, refers to verifying that the peer		Authorization, on the other hand, refers to verifying that the peer
	clock is permitted to play the role that it plays in the protocol.		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		For example, some nodes may be permitted to be masters, while other
	nodes are only permitted to be slaves or TCs.		nodes are only permitted to be slaves or TCs.
			Authorization requires clocks to maintain a list of authorized
			clocks, or a "black list" of clocks that should be denied service or
			revoked.
	It is noted that while the security mechanism is required to provide		It is noted that while the security mechanism is required to provide
	an authorization mechanism, the deployment of such a mechanism		an authorization mechanism, the deployment of such a mechanism
	depends on the nature of the network. For example, a network that		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		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		are equally permitted to be a master. In such a network an
	authorization mechanism may not be necessary.		authorization mechanism may not be necessary.
	The following subsections describe 4 distinct cases of clock		The following subsections describe 4 distinct cases of clock
	authentication.		authentication.
	skipping to change at page 14, line 8		skipping to change at page 14, line 20
	allowing slaves to authenticate the identity of masters.		allowing slaves to authenticate the identity of masters.
	Requirement		Requirement
	The authentication mechanism MUST allow slaves to verify that the		The authentication mechanism MUST allow slaves to verify that the
	authenticated master is authorized to be a master.		authenticated master is authorized to be a master.
	Requirement Level		Requirement Level
	The requirements in this subsection address the spoofing attack		The requirements in this subsection address the spoofing attack
	(Section 3.2.2. ), and the rogue master attack (Section 3 .2.4. ).		(Section 3.2.2.), and the rogue master attack (Section 3.2.4.).
	The requirement level of these requirements is 'MUST' since in the		The requirement level of these requirements is 'MUST' since in the
	absence of these requirements the protocol is exposed to attacks that		absence of these requirements the protocol is exposed to attacks that
	are easy to implement and have a high impact.		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. It is important for a slave to verify the identity		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		of the master, as well as to verify that the master is indeed
	skipping to change at page 14, line 33		skipping to change at page 14, line 45
	Requirement		Requirement
	The security mechanism MUST support recursive authentication and		The security mechanism MUST support recursive authentication and
	authorization of the master, to be used in cases where time		authorization of the master, to be used in cases where time
	information is conveyed through intermediate clocks.		information is conveyed through intermediate clocks.
	Requirement Level		Requirement Level
	The requirement in this subsection addresses the spoofing attack		The requirement in this subsection addresses the spoofing attack
	(Section 3.2.2. ), and the rogue master attack (Section 3 .2.4. ).		(Section 3.2.2.), and the rogue master attack (Section 3.2.4.).
	The requirement level of this requirement is 'MUST' since in the		The requirement level of this requirement is 'MUST' since in the
	absence of this requirement the protocol is exposed to attacks that		absence of this requirement the protocol is exposed to attacks that
	are easy to implement and have a high impact.		are easy to implement and have a high impact.
	Discussion		Discussion
	In some cases a slave is connected to an intermediate clock, that is		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) or a Transparent Clock (TC), which		connected to a Boundary Clock (BC) or a Transparent Clock (TC), which
	in turn is connected to a grandmaster. A similar example in NTP is		in turn is connected to a grandmaster. A similar example in NTP is
	when a client is connected to a stratum 2 server, which is connected		when a client is connected to a stratum 2 server, which is connected
	to a stratum 1 server. In both the PTP and the NTP cases, the slave		to a stratum 1 server. In both the PTP and the NTP cases, the slave
	authenticates the intermediate clock, and the intermediate clock		authenticates the intermediate clock, and the intermediate clock
	authenticates the grandmaster. This inductive authentication process		authenticates the grandmaster. This recursive authentication process
	is referred to in [AutoKey] as proventication.		is referred to in [AutoKey] as proventication.
	Specifically in PTP, this requirement implies that if a slave is		Specifically in PTP, this requirement implies that if a slave is
	receives time information through a TC, it must authenticate the TC		receives time information through a TC, it must authenticate the TC
	it is attached to, as well as authenticate the master it receives the		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		time information from, as per Section 5.1.1. Similarly, if a TC
	receives time information through an attached TC, it must		receives time information through an attached TC, it must
	authenticate the attached TC.		authenticate the attached TC.
	5.1.3. Authentication and Authorization of Slaves		5.1.3. Authentication and Authorization of Slaves
	Requirement		Requirement
	The security mechanism MAY 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
			The security mechanism MAY provide a means for a master to verify
			that the sender of a protocol packet is authorized to send a packet
			of this type.
	Requirement Level		Requirement Level
	The requirement in this subsection prevents DoS attacks against the		The requirement in this subsection prevents DoS attacks against the
	master (Section 3.2.9. ).		master (Section 3.2.9.).
	The requirement level of this requirement is 'MAY' since:		The requirement level of this requirement is 'MAY' since:
	o Its low impact, i.e., in the absence of this requirement the		o Its low impact, i.e., in the absence of this requirement the
	protocol is only exposed to DoS.		protocol is only exposed to DoS.
	o Practical considerations: requiring an NTP server to authenticate		o Practical considerations: requiring an NTP server to authenticate
	its clients may significantly impose on the server's performance.		its clients may significantly impose on the server's performance.
			Note that while the requirement level of this requirement is 'MAY',
			the requirement in Section 5.1.1. is 'MUST'; the security mechanism
			must provide a means for authentication and authorization, with an
			emphasis on the master. Authentication and authorization of slaves is
			specified in this subsection as 'MAY'.
	Discussion		Discussion
	Slaves are authenticated by masters in order to verify that the slave		Slaves and intermediate clocks are authenticated by masters in order
	is authorized to receive timing services from the master.		to verify that they are 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, by		time services. Preventing the master from serving unauthorized clocks
	preventing the master from serving unauthorized clocks. It could be		can help in mitigating DoS attacks against the master. Note that the
	argued that the authentication of slaves could put a higher load on		authentication of slaves might put a higher load on the master than
	the master then serving the unauthorized clock, and hence this		serving the unauthorized clock, and hence this requirement is a
	requirement is a SHOULD.		SHOULD.
	5.1.4. PTP: Authentication and Authorization of Transparent Clocks by		5.1.4. PTP: Authentication and Authorization of PTP TCs by the Master
	Master
	Requirement		Requirement
	The security mechanism for PTP MAY 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
			The security mechanism for PTP MAY provide a means for a master to
			verify that P2P TCs directly connected to it are authorized to be
			TCs.
	Requirement Level		Requirement Level
	The requirement in this subsection prevents DoS attacks against the		The requirement in this subsection prevents DoS attacks against the
	master (Section 3.2.9. ).		master (Section 3.2.9.).
	The requirement level of this requirement is 'MAY' for the same		The requirement level of this requirement is 'MAY' for the same
	reasons specified in Section 5.1.3.		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.
	skipping to change at page 16, line 44		skipping to change at page 17, line 26
	authorization of Management messages.		authorization of Management messages.
	Requirement		Requirement
	The security mechanism MAY support authentication and authorization		The security mechanism MAY support authentication and authorization
	of Signaling messages.		of Signaling messages.
	Requirement Level		Requirement Level
	The requirements in this subsection address the spoofing attack		The requirements in this subsection address the spoofing attack
	(Section 3.2.2. ), and the rogue master attack (Section 3 .2.4. ).		(Section 3.2.2.), and the rogue master attack (Section 3.2.4.).
	The requirement level of the first two requirements is 'MUST' since		The requirement level of the first two requirements is 'MUST' since
	in the absence of these requirements the protocol is exposed to		in the absence of these requirements the protocol is exposed to
	attacks that are easy to implement and have a high impact.		attacks that are easy to implement and have a high impact.
	The requirement level of the third requirement is 'MAY' since its		The requirement level of the third requirement is 'MAY' since its
	impact greatly depends on the application for which the Signaling		impact greatly depends on the application for which the Signaling
	messages are used for.		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 rogue master		messages must be authenticated in order to prevent rogue master
	attacks (Section 3.2.4. ). Note, that this subsection specifies a		attacks (Section 3.2.4.). Note, that this subsection specifies a
	requirement that is not necessarily included in Section 5.1.1. or in		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		Section 5.1.3. , since the BMCA is initiated before clocks have been
	defined as masters or slaves.		defined as masters or slaves.
	Management messages are used to monitor or configure PTP clocks.		Management messages are used to monitor or configure PTP clocks.
	Malicious usage of Management messages enables various attacks, such		Malicious usage of Management messages enables various attacks, such
	as the rogue master attack, or DoS attack.		as the rogue master attack, or DoS attack.
	Signaling messages are used by PTP clocks to exchange information		Signaling messages are used by PTP clocks to exchange information
	that is not strictly related to time information or to master		that is not strictly related to time information or to master
	selection, such as unicast negotiation. Authentication and		selection, such as unicast negotiation. Authentication and
	authorization of Signaling message may be required in some systems,		authorization of Signaling message may be required in some systems,
	depending on the application these messages are used for.		depending on the application these messages are used for.
	5.2. Data integrity		5.2. Protocol Packet 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		Requirement Level
	The requirement in this subsection addresses the packet interception		The requirement in this subsection addresses the packet interception
	and manipulation attack (Section 3.2.1. ).		and manipulation attack (Section 3.2.1.).
	The requirement level of this requirement is 'MUST' since in the		The requirement level of this requirement is 'MUST' since in the
	absence of this requirement the protocol is exposed to attacks that		absence of this requirement the protocol is exposed to attacks that
	are easy to implement and have a high impact.		are easy to implement and have high impact.
	Discussion		Discussion
	While Section 5.1. refers to ensuring the identity an authorization		While Section 5.1. refers to ensuring the identity an authorization
	of the source of a protocol packet, this subsection refers to		of the source of a protocol packet, this subsection refers to
	ensuring that the packet arrived intact. The integrity protection		ensuring that the packet arrived intact. The integrity protection
	mechanism ensures the authenticity and completeness of data from the		mechanism ensures the authenticity and completeness of data from the
	data originator.		data originator.
	5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection		5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection
	skipping to change at page 18, line 22		skipping to change at page 18, line 50
	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		Requirement Level
	The requirement in this subsection addresses the packet interception		The requirement in this subsection addresses the packet interception
	and manipulation attack (Section 3.2.1. ).		and manipulation attack (Section 3.2.1.).
	The requirement level of the first requirement is 'MUST' since in the		The requirement level of the first requirement is 'MUST' since in the
	absence of this requirement the protocol is exposed to attacks that		absence of this requirement the protocol is exposed to attacks that
	are easy to implement and have a high impact.		are easy to implement and have a high impact.
	The requirement level of the first requirement is 'SHOULD' since in		The requirement level of the first requirement is 'SHOULD' since in
	the presence of recursive authentication (Section 5.1.2. ) this		the presence of recursive authentication (Section 5.1.2.) this
	requirement may be redundant.		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.
	5.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.
			Note: Transparent Clocks (TCs) improve the end-to-end accuracy by
			updating a "correctionField" (clause 6.5 in [IEEE1588]) in the PTP
			packet by adding the latency caused by the current TC.
	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 rogue TCs to modify protocol		This approach is simple, but allows rogue TCs to modify protocol
	packets.		packets.
	5.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 directly validate the protocol packet without the
	intermediate TCs to manipulate the packet.		ability of 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 the		to implement than the hop-by-hop approach, as it requires the
	correctionField to be protected separately from the other fields of		correctionField to be protected separately from the other fields of
	the packet, possibly using different cryptographic mechanisms and		the packet, possibly using different cryptographic mechanisms and
	skipping to change at page 19, line 40		skipping to change at page 20, line 20
	5.3. Availability		5.3. Availability
	Requirement		Requirement
	The security mechanism SHOULD include measures to mitigate DoS		The security mechanism SHOULD include measures to mitigate DoS
	attacks against the time protocol.		attacks against the time protocol.
	Requirement Level		Requirement Level
	The requirement in this subsection prevents DoS attacks against the		The requirement in this subsection prevents DoS attacks against the
	protocol (Section 3.2.9. ).		protocol (Section 3.2.9.).
	The requirement level of this requirement is 'SHOULD' due to its low		The requirement level of this requirement is 'SHOULD' due to its low
	impact, i.e., in the absence of this requirement the protocol is only		impact, i.e., in the absence of this requirement the protocol is only
	exposed to DoS.		exposed to DoS.
	Discussion		Discussion
	The protocol availability can be compromised by several different		The protocol availability can be compromised by several different
	attacks.		attacks.
	An attacker can inject protocol messages to implement the spoofing		An attacker can inject protocol messages to implement the spoofing
	attack (Section 3.2.2. ) or the rogue master attack (Section 3.2.4.		attack (Section 3.2.2.) or the rogue master attack (Section 3.2.4.
	), causing DoS to the victim (Section 3.2.9. ). An authentication		), causing DoS to the victim (Section 3.2.9.). An authentication
	mechanism (Section 5.1. ) limits these attacks strictly to internal		mechanism (Section 5.1.) limits these attacks strictly to internal
	attackers, and thus prevents external attackers from performing them.		attackers, and thus prevents external attackers from performing them.
	The DoS attacks described in Section 3.2.8. are performed at lower		The DoS attacks described in Section 3.2.7. are performed at lower
	layers than the time synchronization protocol layer, and are thus		layers than the time protocol layer, and are thus outside the scope
	outside the scope of the security requirements defined in this		of the security requirements defined in this document.
	document.
	5.4. Replay Protection		5.4. Replay Protection
	Requirement		Requirement
	The security mechanism MUST include a replay prevention mechanism.		The security mechanism MUST include a replay prevention mechanism.
	Requirement Level		Requirement Level
	The requirement in this subsection prevents replay attacks (Section		The requirement in this subsection prevents replay attacks (Section
	3.2.3. ).		3.2.3.).
	The requirement level of this requirement is 'MUST' since in the		The requirement level of this requirement is 'MUST' since in the
	absence of this requirement the protocol is exposed to attacks that		absence of this requirement the protocol is exposed to attacks that
	are easy to implement and have a high impact.		are easy to implement and have a high impact.
	Discussion		Discussion
	The replay attack (Section 3.2.3. ) can compromise both the integrity		The replay attack (Section 3.2.3.) can compromise both the integrity
	and availability of the protocol. Common encryption and		and availability of the protocol. Common encryption and
	authentication mechanisms include replay prevention mechanisms that		authentication mechanisms include replay prevention mechanisms that
	typically use a monotonously increasing packet sequence number.		typically use a monotonously increasing packet sequence number.
	5.5. Cryptographic Keys and Security Associations		5.5. Cryptographic Keys and Security Associations
	5.5.1. Key Freshness		5.5.1. Key Freshness
	Requirement		Requirement
	The cryptographic keys MUST be refreshed periodically.		The cryptographic keys MUST be refreshed frequently.
	Requirement Level		Requirement Level
	The requirement level of this requirement is 'MUST' since key		The requirement level of this requirement is 'MUST' since key
	freshness is an essential property for cryptographic algorithms, as		freshness is an essential property for cryptographic algorithms, as
	discussed below.		discussed below.
	Discussion		Discussion
	Key freshness guarantees that both sides share a common updated		Key freshness guarantees that both sides share a common updated
	secret key. It also helps in preventing replay and playback attacks.		secret key. It also helps in preventing replay and playback attacks.
	Thus, it is important keys to be refreshed periodically.		Thus, it is important for keys to be refreshed frequently.
	5.5.2. Security Association		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		Requirement
	The association protocol SHOULD be periodically invoked. Each		Each instance of the association protocol SHOULD produce a different
	instance of the association protocol SHOULD produce a different
	session key.		session key.
	Requirement Level		Requirement Level
	The requirement level of this requirement is 'SHOULD' since it may be		The requirement level of this requirement is 'SHOULD' since it may be
	expensive in terms of performance, especially in low-cost clocks.		expensive in terms of performance, especially in low-cost clocks.
	Discussion		Discussion
	The security requirements in Section 5.1. and Section 5 .2. require		The security requirements in Section 5.1. and Section 5.2. require
	usage of cryptographic mechanisms, deploying cryptographic keys. A		usage of cryptographic mechanisms, deploying cryptographic keys. A
	security association is an essential building block in these		security association is an important building block in these
	mechanisms.		mechanisms.
	5.5.3. Unicast and Multicast		5.5.3. Unicast and Multicast Associations
	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.
	Requirement Level		Requirement Level
	The requirement level of this requirement is 'SHOULD' since it may be		The requirement level of this requirement is 'SHOULD' since it may be
	expensive in terms of performance, especially in low-cost clocks.		expensive in terms of performance, especially for low-cost clocks.
	Discussion		Discussion
	A unicast protocol requires an association protocol between two		A unicast protocol requires an association protocol between two
	clocks, whereas a multicast protocol requires an association protocol		clocks, whereas a multicast protocol requires an association protocol
	among two or more clocks, where one of the clocks is a master.		among two or more clocks, where one of the clocks is a master.
	5.6. Performance		5.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 significantly degrade the quality of the time transfer.
	Requirement		Requirement
	The mechanism SHOULD minimize computational load.		The mechanism SHOULD minimize computational load.
	Requirement		Requirement
	The mechanism also SHOULD minimize storage requirements of client		The mechanism SHOULD minimize storage requirements of client state in
	state in the master, nor significantly increase bandwidth		the master.
	consumption.
			Requirement
			The mechanism SHOULD minimize the bandwidth overhead required by the
			security protocol.
			Requirement Level
			While the quality of the time transfer is clearly a 'MUST', the other
			3 performance requirements are 'SHOULD', since some systems may be
			more sensitive to resource consumption than others, and hence these
			requirements should be considered on a per-system basis.
	Discussion		Discussion
	Performance efficiency is important since client restrictions often		Performance efficiency is important since client restrictions often
	dictate a low processing and memory footprint, and because the server		dictate a low processing and memory footprint, and because the server
	may have extensive fan-out.		may have extensive fan-out.
	Note that the performance requirements refer to a time-		Note that the performance requirements refer to a time-protocol-
	synchronization-specific security mechanism. In systems where a		specific security mechanism. In systems where a security protocol is
	security protocol is used for other types of traffic as well, this		used for other types of traffic as well, this document does not place
	document does not place any performance requirements on the security		any performance requirements on the security protocol performance.
	protocol performance. For example, if IPsec encryption is used for		For example, if IPsec encryption is used for securing all information
	securing all information between the master and slave node, including		between the master and slave node, including information that is not
	information that is not part of the time protocol, the requirements		part of the time protocol, the requirements in this subsection are
	in this subsection are not necessarily applicable.		not necessarily applicable.
	5.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		Requirement Level
	The requirement level of this requirement is 'MAY' since it does not		The requirement level of this requirement is 'MAY' since it does not
	prevent severe threats, as discussed below.		prevent severe threats, as discussed below.
	Discussion		Discussion
	In the context of time synchronization, confidentiality is typically		In the context of time protocols, confidentiality is typically of low
	of low importance, since timing information is typically not		importance, since timing information is typically not considered
	considered secret information.		secret information.
	Confidentiality can play an important role when service providers		Confidentiality can play an important role when service providers
	charge their customers for time synchronization services, and thus an		charge their customers for time synchronization services, and thus an
	encryption mechanism can prevent eavesdroppers from obtaining the		encryption mechanism can prevent eavesdroppers from obtaining the
	service without payment. Note that these cases are rather esoteric.		service without payment. Note that these cases are, for now, 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 MITM attacks such as packet delay (Section		timing protocol against MITM attacks such as packet delay (Section
	3.2.6. ), manipulation and interception and removal attacks. Note,		3.2.6.), manipulation and interception and removal attacks. Note,
	that time protocols have predictable behavior even after encryption,		that time protocols have predictable behavior even after encryption,
	such as packet transmission rates and packet lengths. Additional		such as packet transmission rates and packet lengths. Additional
	measure can be taken to mitigate encrypted traffic analysis by random		measure can be taken to mitigate encrypted traffic analysis by random
	padding of encrypted packets and by adding random dummy packets.		padding of encrypted packets and by adding random dummy packets.
	Nevertheless, encryption does not prevent such MITM attacks, but		Nevertheless, encryption does not prevent such MITM attacks, but
	rather makes these attacks more difficult to implement.		rather makes these attacks more difficult to implement.
	5.8. Protection against Packet Delay and Interception Attacks		5.8. Protection against Packet Delay and Interception Attacks
	Requirement		Requirement
	The security mechanism SHOULD include means to protect the protocol		The security mechanism SHOULD include means to protect the protocol
	from MITM attacks that degrade the clock accuracy.		from MITM attacks that degrade the clock accuracy.
	Requirement Level		Requirement Level
	The requirements in this subsection address MITM attacks such as the		The requirements in this subsection address MITM attacks such as the
	3.2.1. ).		3.2.1.).
	The requirement level of this requirement is 'SHOULD'. In the absence		The requirement level of this requirement is 'SHOULD'. In the absence
	of this requirement the protocol is exposed to attacks that are easy		of this requirement the protocol is exposed to attacks that are easy
	to implement and have a high impact. On the other hand, the		to implement and have a high impact. On the other hand, the
	implementation of this requirement depends on the topology and		implementation of this requirement depends on the topology and
	properties of the system, and is thus not necessarily applicable to		properties of the system, and is thus not necessarily applicable to
	all deployments.		all deployments.
	Discussion		Discussion
	skipping to change at page 24, line 19		skipping to change at page 25, line 11
	Thus, MITM attack prevention derives a requirement from the security		Thus, MITM attack prevention derives a requirement from the security
	mechanism, and a requirement from the network topology. While the		mechanism, and a requirement from the network topology. While the
	security mechanism should support the ability to detect delay		security mechanism should support the ability to detect delay
	attacks, it is noted that in some networks it is not necessarily		attacks, it is noted that in some networks it is not necessarily
	possible to provide the redundancy needed for such a detection		possible to provide the redundancy needed for such a detection
	mechanism.		mechanism.
	5.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 incremental		complex and expensive process, and hence in some cases may require
	deployment, where new equipment supports the security mechanism, and		incremental deployment, where new equipment supports the security
	is required to interoperate with legacy equipment without the		mechanism, and is required to interoperate with legacy equipment
	security features.		without the security features.
	5.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 time protocol. In this mode
	protocol packet received from an unsecured clock MUST be discarded.		every protocol packet received from an unsecured clock MUST be
			discarded.
	Requirement Level		Requirement Level
	The requirement level of this requirement is 'MUST' since the full		The requirement level of this requirement is 'MUST' since the full
	capacity of the security requirements defined in this document can		capacity of the security requirements defined in this document can
	only be achieved in secure mode.		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 similar to the one in
	in 5.1. , it explicitly defines the secure mode, as opposed to the		5.1. , it refers to the secure mode, as opposed to the hybrid mode
	hybrid mode presented in the next subsection.		presented in the next subsection.
	5.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		Requirement Level
	skipping to change at page 25, line 12		skipping to change at page 26, line 4
	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		Requirement Level
	The requirement level of this requirement is a 'MAY', since it is not		The requirement level of this requirement is a 'MAY', since it is not
	necessarily required in all systems. This document recommends to		necessarily required in all systems. This document recommends to
	deploy the 'Secure Mode' described in Section 5.9.1. where possible.		deploy the 'Secure Mode' described in Section 5.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 time protocol. NTP, for example, allows a mixture of secured
	of secured and unsecured nodes.		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		Requirement Level
	skipping to change at page 25, line 45		skipping to change at page 26, line 36
	clock.		clock.
	An unsecured slave can receive protocol packets either from unsecured		An unsecured slave can receive protocol packets either from unsecured
	clocks, or from secured clocks. Note that the latter does not apply		clocks, or from secured clocks. Note that the latter does not apply
	when encryption is used. When integrity protection is used, the		when encryption is used. When integrity protection is used, the
	unsecured slave can receive secured packets ignoring the integrity		unsecured slave can receive secured packets ignoring the integrity
	protection.		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 most		satisfy this requirement, since nodes prefer the server with the most
	accurate clock, and not necessarily the server that supports		accurate clock, which is not necessarily the server that supports
	authentication. For example, a stratum 2 server is connected to two		authentication. For example, a stratum 2 server is connected to two
	stratum 1 servers, Server A, supporting authentication, and server B,		stratum 1 servers, Server A, supporting authentication, and server B,
	without authentication. If server B has a more accurate clock than A,		without authentication. If server B has a more accurate clock than A,
	the stratum 2 server chooses server B, in spite of the fact it does		the stratum 2 server chooses server B, in spite of the fact it does
	not support authentication.		not support authentication.
	6. Summary of Requirements		6. Summary of Requirements
	+-----------+---------------------------------------------+--------+		+-----------+---------------------------------------------+--------+
	| Section | Requirement | Type |		| Section | Requirement | Type |
	skipping to change at page 27, line 8		skipping to change at page 27, line 42
	| +---------------------------------------------+--------+		| +---------------------------------------------+--------+
	| | Security association. | SHOULD |		| | Security association. | SHOULD |
	| +---------------------------------------------+--------+		| +---------------------------------------------+--------+
	| | Unicast and multicast associations. | SHOULD |		| | Unicast and multicast associations. | SHOULD |
	+-----------+---------------------------------------------+--------+		+-----------+---------------------------------------------+--------+
	| 5.6. | Performance: no degradation in quality of | MUST |		| 5.6. | Performance: no degradation in quality of | MUST |
	| | time transfer. | |		| | time transfer. | |
	| +---------------------------------------------+--------+		| +---------------------------------------------+--------+
	| | Performance: computation load. | SHOULD |		| | Performance: computation load. | SHOULD |
	| +---------------------------------------------+--------+		| +---------------------------------------------+--------+
	| | Performance: storage, bandwidth. | SHOULD |		| | Performance: storage. | SHOULD |
			| +---------------------------------------------+--------+
			| | Performance: bandwidth. | SHOULD |
	+-----------+---------------------------------------------+--------+		+-----------+---------------------------------------------+--------+
	| 5.7. | Confidentiality protection. | MAY |		| 5.7. | Confidentiality protection. | MAY |
	+-----------+---------------------------------------------+--------+		+-----------+---------------------------------------------+--------+
	| 5.8. | Protection against delay and interception | SHOULD |		| 5.8. | Protection against delay and interception | SHOULD |
	| | attacks. | |		| | attacks. | |
	+-----------+---------------------------------------------+--------+		+-----------+---------------------------------------------+--------+
	| 5.9. | Secure mode. | MUST |		| 5.9. | Secure mode. | MUST |
	| +---------------------------------------------+--------+		| +---------------------------------------------+--------+
	| | Hybrid mode. | MAY |		| | Hybrid mode. | MAY |
	+-----------+---------------------------------------------+--------+		+-----------+---------------------------------------------+--------+
	Table 2 Summary of Security Requirements		Table 2 Summary of Security Requirements
	7. 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 protocols and security mechanisms.
	This section refers to time synchronization security mechanisms, as		This section refers to time protocol security mechanisms, as well as
	well as to "external" security mechanisms, i.e., security mechanisms		to "external" security mechanisms, i.e., security mechanisms that are
	that are not strictly related to the time synchronization protocol.		not strictly related to the time protocol.
	7.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 protocols often require that protocol packets be modified during
	modified during transmission. Both NTP and PTP in one-step mode		transmission. Both NTP and PTP in one-step mode require clocks to
	require clocks to modify protocol packets with the time of		modify protocol packets based on the time of transmission and/or
	transmission.		reception.
	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 encryption and/or integrity protection
	integrating the timestamp into the packet.		MUST be applied after integrating the timestamp into the packet.
	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, it may introduce non-deterministic latency		the physical interface, it may introduce non-deterministic latency
	that causes accuracy degradation. These performance aspects have been		that causes accuracy degradation. These performance aspects have been
	analyzed in the literature, e.g., in [1588IPsec] and [Tunnel].		analyzed in the literature, e.g., in [1588IPsec] and [Tunnel].
	7.2. PTP: 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 of protocol packets is communicated without modifying		transmission of protocol packets is communicated without modifying
	the packets. As opposed to one-step mode, two-step timestamping can		the packets. As opposed to one-step mode, two-step timestamping can
	be performed without the requirement to encrypt after timestamping.		be performed without the requirement to encrypt after timestamping.
	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 protocol packets.
	7.3. Intermediate Clocks		7.3. Intermediate Clocks
	A time synchronization protocol allows slaves to receive time		A time protocol allows slaves to receive time information from an
	information from an accurate time source. Time information is sent		accurate time source. Time information is sent over a path that often
	over a path that often traverses one or more intermediate clocks.		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. These intermediate
			clocks are referred to as "secondary servers" in [NTPv4].
	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 possess the security key (hop-by-hop		intermediate nodes MUST possess the security key (hop-by-hop
	security) since they must be able to send time information to the		security) since they must be able to send time information to the
	slaves, or to modify time information sent through them.		slaves, or to modify time information sent through them.
	This inherent 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 possess the security keys.		nodes that possess the security keys.
	Thus, there is a tradeoff between the achievable clock accuracy of a		Thus, there is a tradeoff between the achievable clock accuracy of a
	system, and the robustness of its security solution. On one hand high		system, and the robustness of its security solution. On one hand high
	clock accuracy calls for hop-by-hop involvement in the protocol, also		clock accuracy calls for hop-by-hop involvement in the protocol, also
	known as on-path support. On the other hand, a robust security		known as on-path support. On the other hand, a robust security
	solution calls for end-to-end data protection.		solution calls for end-to-end data protection.
	7.4. The Effect of External Security Protocols on Time Synchronization		7.4. External Security Protocols and Time Protocols
	Time synchronization protocols are often deployed in systems that use		Time protocols are often deployed in systems that use security
	security mechanisms and protocols.		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 protocol traffic. This use-case
	traffic. This use-case is thoroughly discussed in [IPsecSync].		is thoroughly discussed in [IPsecSync].
	Another typical example is the usage of MACsec encryption ([MACsec])		Another typical example is the usage of MACsec encryption ([MACsec])
	in L2 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 protocols
	synchronization protocols as follows:		as follows:
	o Timestamping accuracy can be affected, as described in 7.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 necessarily
	underlying network without modification, and thus cannot enjoy the		transported over the underlying network without modification, and
	improved accuracy provided by intermediate clock nodes.		thus cannot enjoy the improved accuracy provided by intermediate
			clock nodes.
	7.5. External Security Services Requiring Time Synchronization		7.5. External Security Services Requiring Time
			Cryptographic protocols often use time as an important factor in the
			cryptographic algorithm. If a time protocol is compromised, it may
			consequently expose the security protocols that rely on it to various
			attacks. Two examples are presented in this section.
	7.5.1. Timestamped Certificates		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 protocol and a
	protocol and a security mechanism is defined in [AutoKey], which		security mechanism is defined in [AutoKey], which defines mutual
	defines mutual dependence between the acquired time information, and		dependence between the acquired time information, and the
	the authentication protocol that secures it. This bootstrapping		authentication protocol that secures it. This bootstrapping behavior
	behavior results from the fact that trusting the received time		results from the fact that trusting the received time information
	information requires a valid certificate, and validating a		requires a valid certificate, and validating a certificate requires
	certificate requires knowledge of the time.		knowledge of the time.
	7.5.2. Time Synchronization as a Vulnerability
	Cryptographic protocols often use time as an important factor in the		7.5.2. Time Changes and Replay Attacks
	cryptographic algorithm. If a time synchronization protocol is
	compromised, it may consequently cause expose the security protocols
	that rely on it to various attacks.
	For example, a successful attack on a time synchronization protocol		A successful attack on a time protocol may cause the attacked clocks
	may cause the attacked clocks to be synchronized to an early time.		to go back in time. The erroneous time may expose cryptographic
	This erroneous time may expose cryptographic algorithms that rely on		algorithms that rely on time to prevent replay attacks.
	time to replay attacks.
	8. Issues for Further Discussion		8. Issues for Further Discussion
	The key distribution is outside the scope of this document. Although		The Key distribution is outside the scope of this document. Although
	this is an essential element of any security system, it is outside		this is an essential element of any security system, it is outside
	the scope of this document.		the scope of this document.
	9. Security Considerations		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.
	10. IANA Considerations		10. IANA Considerations
End of changes. 131 change blocks.
	273 lines changed or deleted		322 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/