draft-ietf-tictoc-security-requirements-06.txt		draft-ietf-tictoc-security-requirements-07.txt
	TICTOC Working Group Tal Mizrahi		TICTOC Working Group Tal Mizrahi
	Internet Draft Marvell		Internet Draft Marvell
	Intended status: Informational		Intended status: Informational
	Expires: April 2014 October 21, 2013		Expires: October 2014 April 23, 2014
	Security Requirements of Time Protocols		Security Requirements of Time Protocols
	in Packet Switched Networks		in Packet Switched Networks
	draft-ietf-tictoc-security-requirements-06.txt		draft-ietf-tictoc-security-requirements-07.txt
	Abstract		Abstract
	As time and frequency distribution protocols are becoming		As time and frequency distribution protocols are becoming
	increasingly common and widely deployed, concern about their exposure		increasingly common and widely deployed, concern about their exposure
	to various security threats is increasing. This document defines a		to various security threats is increasing. This document defines a
	set of security requirements for time protocols, focusing on the		set of security requirements for time protocols, focusing on the
	Precision Time Protocol (PTP) and the Network Time Protocol (NTP).		Precision Time Protocol (PTP) and the Network Time Protocol (NTP).
	This document also discusses the security impacts of time protocol		This document also discusses the security impacts of time protocol
	practices, the performance implications of external security		practices, the performance implications of external security
	skipping to change at page 1, line 44		skipping to change at page 1, line 44
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 21, 2014.		This Internet-Draft will expire on October 23, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 35		skipping to change at page 2, line 35
	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 ............................. 6		2.4. Terms used in this Document ............................. 6
	3. Security Threats ............................................. 7		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 ....... 8		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 Manipulation ................................ 8		3.2.1. Packet Manipulation ................................ 8
	3.2.2. Spoofing ........................................... 8		3.2.2. Spoofing ........................................... 8
	3.2.3. Replay Attack ...................................... 8		3.2.3. Replay Attack ...................................... 9
	3.2.4. Rogue Master Attack ................................ 8		3.2.4. Rogue Master Attack ................................ 9
	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. L2/L3 DoS Attacks .................................. 9		3.2.7. L2/L3 DoS Attacks .................................. 9
	3.2.8. Cryptographic Performance Attacks .................. 9		3.2.8. Cryptographic Performance Attacks ................. 10
	3.2.9. DoS Attacks against the Time Protocol ............. 10		3.2.9. DoS Attacks against the Time Protocol ............. 10
	3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud) . 10		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 .......................................... 12		4. Requirement Levels .......................................... 12
	5. Security Requirements ....................................... 12		5. Security Requirements ....................................... 13
	5.1. Clock Identity Authentication and Authorization ........ 13		5.1. Clock Identity Authentication and Authorization ........ 13
	5.1.1. Authentication and Authorization of Masters ....... 14		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) ......................................... 15
	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 PTP TCs by the		5.1.4. PTP: Authentication and Authorization of P2P TCs by the
	Master ................................................... 16		Master ................................................... 16
	5.1.5. PTP: Authentication and Authorization of Control		5.1.5. PTP: Authentication and Authorization of Control
	Messages ................................................. 17		Messages ................................................. 17
	5.2. Protocol Packet Integrity .............................. 18		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 19
	5.2.1.1. Hop-by-Hop Integrity Protection .............. 19		5.2.1.1. Hop-by-Hop Integrity Protection .............. 19
	5.2.1.2. End-to-End Integrity Protection .............. 19		5.2.1.2. End-to-End Integrity Protection .............. 19
	5.3. Availability ........................................... 20		5.3. Availability ........................................... 20
	5.4. Replay Protection ...................................... 20		5.4. Replay Protection ...................................... 20
	5.5. Cryptographic Keys and Security Associations ........... 21		5.5. Cryptographic Keys and Security Associations ........... 21
	5.5.1. Key Freshness ..................................... 21		5.5.1. Key Freshness ..................................... 21
	5.5.2. Security Association .............................. 21		5.5.2. Security Association .............................. 21
	5.5.3. Unicast and Multicast Associations ................ 22		5.5.3. Unicast and Multicast Associations ................ 22
	5.6. Performance ............................................ 22		5.6. Performance ............................................ 22
	5.7. Confidentiality......................................... 23		5.7. Confidentiality......................................... 23
	5.8. Protection against Packet Delay and Interception Attacks 24		5.8. Protection against Packet Delay and Interception Attacks 24
	5.9. Combining Secured with Unsecured Nodes ................. 25		5.9. Combining Secured with Unsecured Nodes ................. 25
	5.9.1. Secure Mode ....................................... 25		5.9.1. Secure Mode ....................................... 25
	5.9.2. Hybrid Mode ....................................... 25		5.9.2. Hybrid Mode ....................................... 25
	6. Summary of Requirements ..................................... 27		6. Summary of Requirements ..................................... 26
	7. Additional security implications ............................ 28		7. Additional security implications ............................ 28
	7.1. Security and on-the-fly Timestamping ................... 28		7.1. Security and on-the-fly Timestamping ................... 28
	7.2. PTP: Security and Two-Step Timestamping ................ 29		7.2. PTP: Security and Two-Step Timestamping ................ 28
	7.3. Intermediate Clocks .................................... 29		7.3. Intermediate Clocks .................................... 29
	7.4. External Security Protocols and Time Protocols.......... 30		7.4. External Security Protocols and Time Protocols.......... 29
	7.5. External Security Services Requiring Time .............. 30		7.5. External Security Services Requiring Time .............. 30
	7.5.1. Timestamped Certificates .......................... 30		7.5.1. Timestamped Certificates .......................... 30
	7.5.2. Time Changes and Replay Attacks ................... 31		7.5.2. Time Changes and Replay Attacks ................... 30
	8. Issues for Further Discussion ............................... 31		8. Issues for Further Discussion ............................... 31
	9. Security Considerations ..................................... 31		9. Security Considerations ..................................... 31
	10. IANA Considerations......................................... 31		10. IANA Considerations......................................... 31
	11. Acknowledgments ............................................ 31		11. Acknowledgments ............................................ 31
	12. References ................................................. 31		12. References ................................................. 31
	12.1. Normative References .................................. 31		12.1. Normative References .................................. 31
	12.2. Informative References ................................ 32		12.2. Informative References ................................ 32
	13. Contributing Authors ....................................... 33		13. Contributing Authors ....................................... 33
	1. Introduction		1. Introduction
	skipping to change at page 5, line 31		skipping to change at page 5, line 31
	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 with which every security mechanism should comply.		requirements with which every security mechanism should comply.
	2.2. Abbreviations		2.2. Abbreviations
	BC Boundary Clock		BC Boundary Clock [IEEE1588]
	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 [NTPv4]
	OC Ordinary Clock		OC Ordinary Clock [IEEE1588]
	PTP Precision Time Protocol		P2P TC Peer-to-Peer Transparent Clock [IEEE1588]
	TC Transparent Clock		PTP Precision Time Protocol [IEEE1588]
			TC Transparent Clock [IEEE1588]
	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 term "protocol		applies to both PTP slaves and NTP clients. The term "protocol
	packets" refers generically to PTP and NTP messages.		packets" refers generically to PTP and NTP messages.
	2.4. Terms used in this Document		2.4. Terms used in this Document
	skipping to change at page 8, line 34		skipping to change at page 8, line 34
	timing protocol packets, alters them and relays them to their		timing protocol packets, alters them and relays them to their
	destination, allowing the attacker to maliciously tamper with the		destination, allowing the attacker to maliciously tamper with the
	protocol. This can result in a situation where the time protocol is		protocol. This can result in a situation where the time protocol is
	apparently operational but providing intentionally inaccurate		apparently operational but providing intentionally inaccurate
	information.		information.
	3.2.2. Spoofing		3.2.2. Spoofing
	In spoofing, an injector 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 or control		network by generating and transmitting protocol packets or control
	packets. For example, an attacker can impersonate the master,		packets. Two typical examples of spoofing attacks:
	allowing malicious distribution of false timing information. As with
	packet manipulation, this can result in a situation where the time		o An attacker can impersonate the master, allowing malicious
	protocol is apparently operational but providing intentionally		distribution of false timing information.
	inaccurate information.
			o An attacker can impersonate a legitimate clock, a slave or an
			intermediate clock, by sending malicious messages to the master,
			causing the master to respond to the legitimate clock with
			protocol packets that are based on the spoofed messages.
			Consequently, the delay computations of the legitimate clock are
			based on false information.
			As with packet manipulation, this attack can result in a situation
			where the time protocol is apparently operational but providing
			intentionally inaccurate information.
	3.2.3. Replay Attack		3.2.3. Replay Attack
	In a replay attack, an attacker records protocol packets and replays		In a replay attack, an attacker records protocol packets and replays
	them at a later time 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 13, line 47		skipping to change at page 14, line 19
	clocks, or a "black list" of clocks that should be denied service or		clocks, or a "black list" of clocks that should be denied service or
	revoked.		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 5 distinct cases of clock
	authentication.		authentication.
	5.1.1. Authentication and Authorization of Masters		5.1.1. Authentication and Authorization of Masters
	Requirement		Requirement
	The security mechanism MUST support an authentication mechanism,		The security mechanism MUST support an authentication mechanism,
	allowing slaves to authenticate the identity of masters.		allowing slaves to authenticate the identity of masters.
	Requirement		Requirement
	skipping to change at page 15, line 25		skipping to change at page 15, line 46
	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 MUST provide a means for a master to
	authenticate its slaves.		authenticate its slaves.
	Requirement		Requirement
	The security mechanism MAY provide a means for a master to verify		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		that the sender of a protocol packet is authorized to send a packet
	of this type.		of this type.
	Requirement Level		Requirement Level
	The requirement in this subsection prevents DoS attacks against the		The authentication requirement in this subsection prevents DoS
	master (Section 3.2.9.).		attacks against the master (Section 3.2.9.), as well as spoofing
			attacks (Section 3.2.2.). A spoofing attack, such as the second
	The requirement level of this requirement is 'MAY' since:		example in Section 3.2.2. , is easy to implement and has a high
			impact, and therefore the requirement level is 'MUST'.
	o Its low impact, i.e., in the absence of this requirement the
	protocol is only exposed to DoS.
	o Practical considerations: requiring an NTP server to authenticate
	its clients may significantly impose on the server's performance.
	Note that while the requirement level of this requirement is 'MAY',		The authorization requirement in this subsection only mitigates DoS
	the requirement in Section 5.1.1. is 'MUST'; the security mechanism		attacks against the master (Section 3.2.9.). The requirement level
	must provide a means for authentication and authorization, with an		is 'MAY', since the absence of this requirement has a relatively low
	emphasis on the master. Authentication and authorization of slaves is		impact, i.e., in the absence of this requirement the protocol is only
	specified in this subsection as 'MAY'.		exposed to DoS. Note that Section 5.1.1. specifies authorization as
			a 'MUST', i.e., the security mechanism must provide a means for
			authorization, with an emphasis on the master. Authentication and
			authorization of slaves is specified in this subsection as 'MAY'.
	Discussion		Discussion
	Slaves and intermediate clocks are authenticated by masters in order		Slaves and intermediate clocks are authenticated by masters in order
	to verify that they are authorized to receive timing services from		to verify their identity, thus preventing attackers from sending
	the master.		unauthorized protocol packets to the master, and preventing
			unauthorized clocks from receiving time services.
	Authentication of slaves prevents unauthorized clocks from receiving		Note that the authentication of slaves might put a higher load on the
	time services. Preventing the master from serving unauthorized clocks		master than serving the unauthorized clock, and thus the decision of
	can help in mitigating DoS attacks against the master. Note that the		whether to deploy slave authentication and/or authorization should be
	authentication of slaves might put a higher load on the master than		based on the environment in which the master and slaves are deployed.
	serving the unauthorized clock, and hence this requirement is a MAY.
	5.1.4. PTP: Authentication and Authorization of PTP TCs by the Master		5.1.4. PTP: Authentication and Authorization of P2P TCs by the Master
	Requirement		Requirement
	The security mechanism for PTP MAY provide a means for a master to		The security mechanism for PTP MUST 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		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
	verify that P2P TCs directly connected to it are authorized to be		verify that P2P TCs directly connected to it are authorized to be
	TCs.		TCs.
	Requirement Level		Requirement Level
			As in Section 5.1.3. , authentication and authorization can help in
			preventing DoS attacks against the master (Section 3.2.9.).
			Authentication also mitigates spoofing attacks (Section 3.2.2.).
	The requirement in this subsection prevents DoS attacks against the		The requirement levels of the authentication and authorization
	master (Section 3.2.9.).		requirements in this subsection are 'MUST' and 'MAY' respectively,
			for the same reasons specified in Section 5.1.3.
	The requirement level of this requirement is 'MAY' for the same
	reasons specified in Section 5.1.3.
	Discussion		Discussion
	P2P TCs that are one hop from the master use the PDelay_Req and		P2P TCs that are one hop from the master use the PDelay_Req and
	PDelay_Resp handshake to compute the link delay between the master		PDelay_Resp handshake to compute the link delay between the master
	and TC. These TCs are authenticated by the master.		and TC. These TCs are authenticated by the master.
	Authentication of TCs, much like authentication of slaves, reduces		Authentication of TCs, much like authentication of slaves, prevents
	unnecessary load on the master and peer TCs, by preventing the master		external attackers from sending spoofed messages to the master, as
	from serving unauthorized clocks.		well as reduces unnecessary load on the master and peer TCs, by
			preventing the master from serving unauthorized clocks.
	5.1.5. PTP: Authentication and Authorization of Control Messages		5.1.5. PTP: Authentication and Authorization of Control Messages
	Requirement		Requirement
	The security mechanism for PTP MUST support authentication of		The security mechanism for PTP MUST support authentication of
	Announce messages. The authentication mechanism MUST also verify that		Announce messages. The authentication mechanism MUST also verify that
	the sender is authorized to be a master.		the sender is authorized to be a master.
	Requirement		Requirement
	skipping to change at page 18, line 37		skipping to change at page 19, line 9
	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
	Requirement
	A security mechanism for PTP MUST support hop-by-hop integrity
	protection.
	Requirement
	A security mechanism for PTP SHOULD support end-to-end integrity
	protection.
	Requirement Level
	The requirement in this subsection addresses the packet manipulation
	attack (Section 3.2.1.).
	The requirement level of the first requirement is 'MUST' since in the
	absence of this requirement the protocol is exposed to attacks that
	are easy to implement and have a high impact.
	The requirement level of the first requirement is 'SHOULD' since in
	the presence of recursive authentication (Section 5.1.2.) this
	requirement may be redundant.
	Discussion
	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.
	skipping to change at page 20, line 31		skipping to change at page 20, line 26
	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 packets 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.7. are performed at lower		The DoS attacks described in Section 3.2.7. are performed at lower
	layers than the time protocol layer, and are thus outside the scope		layers than the time protocol layer, and are thus outside the scope
	of the security requirements defined in this document.		of the security requirements defined in this document.
	5.4. Replay Protection		5.4. Replay Protection
	skipping to change at page 21, line 33		skipping to change at page 21, line 26
	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 attacks. Thus, it is
	Thus, it is important for keys to be refreshed frequently.		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.
	skipping to change at page 24, line 13		skipping to change at page 24, line 7
	encryption mechanism can prevent eavesdroppers from obtaining the		encryption mechanism can prevent eavesdroppers from obtaining the
	service without payment. Note that these cases are, for now, rather		service without payment. Note that these cases are, for now, rather
	esoteric.		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		measures can be taken to mitigate encrypted traffic analysis by
	padding of encrypted packets and by adding random dummy packets.		random padding of encrypted packets and by adding random dummy
	Nevertheless, encryption does not prevent such MITM attacks, but		packets. Nevertheless, encryption does not prevent such MITM attacks,
	rather makes these attacks more difficult to implement.		but 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 MUST 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.).		packet delay attack (Section 3.2.6.) and packet interception attacks
			(Section 3.2.5. and Section 3.2.1.).
	The requirement level of this requirement is 'SHOULD'. In the absence		The requirement level of this requirement is 'MUST'. 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. Note that in the absence of this		to implement and have a high impact. Note that in the absence of this
	requirement, the impact is similar to packet manipulation attacks		requirement, the impact is similar to packet manipulation attacks
	(Section 3.2.1.), and thus this requirement has the same requirement		(Section 3.2.1.), and thus this requirement has the same requirement
	level as integrity protection (Section 5.2.).		level as integrity protection (Section 5.2.).
	It is noted that the implementation of this requirement depends on		It is noted that the implementation of this requirement depends on
	the topology and properties of the system.		the topology and properties of the system.
	Discussion		Discussion
	skipping to change at page 25, line 8		skipping to change at page 24, line 48
	note that common practices for protection against MITM attacks use		note that common practices for protection against MITM attacks use
	redundant masters (e.g. [NTPv4]), or redundant paths between the		redundant masters (e.g. [NTPv4]), or redundant paths between the
	master and slave (e.g. [DelayAtt]). If one of the time sources		master and slave (e.g. [DelayAtt]). If one of the time sources
	indicates a time value that is significantly different than the other		indicates a time value that is significantly different than the other
	sources, it is assumed to be erroneous or under attack, and is		sources, it is assumed to be erroneous or under attack, and is
	therefore ignored.		therefore ignored.
	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 possible to
	possible to provide the redundancy needed for such a detection		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 and expensive process, and hence in some cases may require		complex and expensive process, and hence in some cases may require
	incremental deployment, where new equipment supports the security		incremental deployment, where new equipment supports the security
	mechanism, and is required to interoperate with legacy equipment		mechanism, and is required to interoperate with legacy equipment
	without the security features.		without the security features.
	5.9.1. Secure Mode		5.9.1. Secure Mode
	skipping to change at page 27, line 16		skipping to change at page 27, line 5
	+-----------+---------------------------------------------+--------+		+-----------+---------------------------------------------+--------+
	| Section | Requirement | Type |		| Section | Requirement | Type |
	+-----------+---------------------------------------------+--------+		+-----------+---------------------------------------------+--------+
	| 5.1. | Authentication & authorization of sender. | MUST |		| 5.1. | Authentication & authorization of sender. | MUST |
	| +---------------------------------------------+--------+		| +---------------------------------------------+--------+
	| | Authentication & authorization of master. | MUST |		| | Authentication & authorization of master. | MUST |
	| +---------------------------------------------+--------+		| +---------------------------------------------+--------+
	| | Recursive authentication & authorization. | MUST |		| | Recursive authentication & authorization. | MUST |
	| +---------------------------------------------+--------+		| +---------------------------------------------+--------+
	| | Authentication & authorization of slaves. | MAY |		| | Authentication of slaves. | MUST |
	| +---------------------------------------------+--------+		| +---------------------------------------------+--------+
	| | PTP: Authentication of TCs by master. | MAY |		| | Authorization of slaves. | MAY |
			| +---------------------------------------------+--------+
			| | PTP: Authentication of P2P TCs by master. | MUST |
			| +---------------------------------------------+--------+
			| | PTP: Authorization of P2P TCs by master. | MAY |
	| +---------------------------------------------+--------+		| +---------------------------------------------+--------+
	| | PTP: Authentication & authorization of | MUST |		| | PTP: Authentication & authorization of | MUST |
	| | Announce messages. | |		| | Announce messages. | |
	| +---------------------------------------------+--------+		| +---------------------------------------------+--------+
	| | PTP: Authentication & authorization of | MUST |		| | PTP: Authentication & authorization of | MUST |
	| | Management messages. | |		| | Management messages. | |
	| +---------------------------------------------+--------+		| +---------------------------------------------+--------+
	| | PTP: Authentication & authorization of | MAY |		| | PTP: Authentication & authorization of | MAY |
	| | Signaling messages. | |		| | Signaling messages. | |
	+-----------+---------------------------------------------+--------+		+-----------+---------------------------------------------+--------+
	| 5.2. | Integrity protection. | MUST |		| 5.2. | Integrity protection. | MUST |
	| +---------------------------------------------+--------+
	| | PTP: hop-by-hop integrity protection. | MUST |
	| +---------------------------------------------+--------+
	| | PTP: end-to-end integrity protection. | SHOULD |
	+-----------+---------------------------------------------+--------+		+-----------+---------------------------------------------+--------+
	| 5.3. | Protection against DoS attacks. | SHOULD |		| 5.3. | Protection from DoS attacks against the | SHOULD |
			| | time protocol. | |
	+-----------+---------------------------------------------+--------+		+-----------+---------------------------------------------+--------+
	| 5.4. | Replay protection. | MUST |		| 5.4. | Replay protection. | MUST |
	+-----------+---------------------------------------------+--------+		+-----------+---------------------------------------------+--------+
	| 5.5. | Key freshness. | MUST |		| 5.5. | Key freshness. | MUST |
	| +---------------------------------------------+--------+		| +---------------------------------------------+--------+
	| | 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. | SHOULD |		| | Performance: storage. | SHOULD |
	| +---------------------------------------------+--------+		| +---------------------------------------------+--------+
	| | Performance: bandwidth. | 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 | MUST |
	| | 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
	skipping to change at page 29, line 6		skipping to change at page 28, line 41
	integrity protection:		integrity protection:
	o During transmission the encryption and/or integrity protection		o During transmission the encryption and/or integrity protection
	MUST be applied after 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 literature, e.g., [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
	skipping to change at page 31, line 17		skipping to change at page 31, line 4
	dependence between the acquired time information, and the		dependence between the acquired time information, and the
	authentication protocol that secures it. This bootstrapping behavior		authentication protocol that secures it. This bootstrapping behavior
	results from the fact that trusting the received time information		results from the fact that trusting the received time information
	requires a valid certificate, and validating a certificate requires		requires a valid certificate, and validating a certificate requires
	knowledge of the time.		knowledge of the time.
	7.5.2. Time Changes and Replay Attacks		7.5.2. Time Changes and Replay Attacks
	A successful attack on a time protocol may cause the attacked clocks		A successful attack on a time protocol may cause the attacked clocks
	to go back in time. The erroneous time may expose cryptographic		to go back in time. The erroneous time may expose cryptographic
	algorithms that rely on time to prevent replay attacks.		algorithms that rely on time, as a node may use a key that was
			already used in the past and has expired.
	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
	There are no new IANA considerations implied by this document.		There are no new IANA considerations implied by this document.
	11. Acknowledgments		11. Acknowledgments
	The authors gratefully acknowledge Stefano Ruffini, Doug Arnold,		The authors gratefully acknowledge Stefano Ruffini, Doug Arnold,
	Kevin Gross, Dieter Sibold, Dan Grossman and Laurent Montini for		Kevin Gross, Dieter Sibold, Dan Grossman, Laurent Montini, Russell
	their thorough review and helpful comments. The authors would also		Smiley, and Shawn Emery for their thorough review and helpful
	like to thank members of the TICTOC WG for providing feedback on the		comments. The authors would also like to thank members of the TICTOC
	TICTOC mailing list.		WG for providing feedback on the TICTOC mailing list.
	This document was prepared using 2-Word-v2.0.template.dot.		This document was prepared using 2-Word-v2.0.template.dot.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate		[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
End of changes. 48 change blocks.
	112 lines changed or deleted		100 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/