draft-ietf-tictoc-security-requirements-05.txt		draft-ietf-tictoc-security-requirements-06.txt
	TICTOC Working Group Tal Mizrahi		TICTOC Working Group Tal Mizrahi
	Internet Draft Marvell		Internet Draft Marvell
	Intended status: Informational		Intended status: Informational
	Expires: October 2013 April 25, 2013		Expires: April 2014 October 21, 2013
	Security Requirements of Time Protocols		Security Requirements of Time Protocols
	in Packet Switched Networks		in Packet Switched Networks
	draft-ietf-tictoc-security-requirements-05.txt		draft-ietf-tictoc-security-requirements-06.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 October 25, 2013.		This Internet-Draft will expire on April 21, 2014.
	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 33		skipping to change at page 2, line 33
	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 ............................. 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 Interception and 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 ...................................... 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. 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 .................. 9
	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
	skipping to change at page 3, line 24		skipping to change at page 3, line 24
	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 ..................................... 26		6. Summary of Requirements ..................................... 27
	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 ................ 28		7.2. PTP: Security and Two-Step Timestamping ................ 29
	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.......... 30
	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 ................... 31
	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
	skipping to change at page 8, line 21		skipping to change at page 8, line 21
	A traffic injector is not located in an MITM position, but can attack		A traffic injector is not located in an MITM position, but can attack
	by generating protocol packets. An injector can reside either within		by generating protocol packets. An injector can reside either within
	the attacked network, or on an external network that is connected to		the attacked network, or on an external network that is connected to
	the attacked network. An injector can also potentially eavesdrop on		the attacked network. An injector can also potentially eavesdrop on
	protocol packets sent as multicast, record them and replay them		protocol packets sent as multicast, record them and replay them
	later.		later.
	3.2. Threat Analysis		3.2. Threat Analysis
	3.2.1. Packet Interception and Manipulation		3.2.1. Packet Manipulation
	A packet interception and manipulation attack results when an MITM		A packet manipulation attack results when an MITM attacker receives
	attacker intercepts timing protocol packets, alters them and relays		timing protocol packets, alters them and relays them to their
	them to their destination, allowing the attacker to maliciously		destination, allowing the attacker to maliciously tamper with the
	tamper with the protocol. This can result in a situation where the		protocol. This can result in a situation where the time protocol is
	time protocol is apparently operational but providing intentionally		apparently operational but providing intentionally inaccurate
	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. For example, an attacker can impersonate the master,
	allowing malicious distribution of false timing information. As with		allowing malicious distribution of false timing information. As with
	packet interception and manipulation, this can result in a situation		packet manipulation, this can result in a situation where the time
	where the time protocol is apparently operational but providing		protocol is apparently operational but providing intentionally
	intentionally inaccurate information.		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 23		skipping to change at page 9, line 23
	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 some or all of the protocol packets.		destination node from receiving some or all of the protocol packets.
	3.2.6. Packet Delay Manipulation		3.2.6. Packet Delay Manipulation
	In a packet delay manipulation scenario, an MITM attacker intercepts		In a packet delay manipulation scenario, an MITM attacker receives
	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. The attacker can use various delay attack		maliciously computed delay. The attacker can use various delay attack
	strategies; the added delay can be constant, jittered, or slowly		strategies; the added delay can be constant, jittered, or slowly
	wandering. Each of these strategies has a different impact, but they		wandering. Each of these strategies has a different impact, but they
	all effectively manipulate the attacked clock.		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.
	skipping to change at page 11, line 27		skipping to change at page 11, line 27
	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 Section 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| + | | || + | | | |		|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 | + | | || + | | + | |
	skipping to change at page 15, line 14		skipping to change at page 15, line 14
	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 recursive 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
	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
	skipping to change at page 16, line 17		skipping to change at page 16, line 17
	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 that they are authorized to receive timing services from
	the master.		the master.
	Authentication of slaves prevents unauthorized clocks from receiving		Authentication of slaves prevents unauthorized clocks from receiving
	time services. Preventing the master from serving unauthorized clocks		time services. Preventing the master from serving unauthorized clocks
	can help in mitigating DoS attacks against the master. Note that the		can help in mitigating DoS attacks against the master. Note that the
	authentication of slaves might put a higher load on the master than		authentication of slaves might put a higher load on the master than
	serving the unauthorized clock, and hence this requirement is a		serving the unauthorized clock, and hence this requirement is a MAY.
	SHOULD.
	5.1.4. PTP: Authentication and Authorization of PTP TCs by the Master		5.1.4. PTP: Authentication and Authorization of PTP TCs by the 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		Requirement
	skipping to change at page 18, line 20		skipping to change at page 18, line 20
	5.2. Protocol Packet 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 manipulation
	and manipulation attack (Section 3.2.1.).		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 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
	skipping to change at page 18, line 49		skipping to change at page 18, line 49
	A security mechanism for PTP MUST support hop-by-hop integrity		A security mechanism for PTP MUST support hop-by-hop integrity
	protection.		protection.
	Requirement		Requirement
	A security mechanism for PTP SHOULD support end-to-end integrity		A security mechanism for PTP SHOULD support end-to-end integrity
	protection.		protection.
	Requirement Level		Requirement Level
	The requirement in this subsection addresses the packet interception		The requirement in this subsection addresses the packet manipulation
	and manipulation attack (Section 3.2.1.).		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
	skipping to change at page 24, line 32		skipping to change at page 24, line 32
	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. Note that in the absence of this
	implementation of this requirement depends on the topology and		requirement, the impact is similar to packet manipulation attacks
	properties of the system, and is thus not necessarily applicable to		(Section 3.2.1.), and thus this requirement has the same requirement
	all deployments.		level as integrity protection (Section 5.2.).
			It is noted that the implementation of this requirement depends on
			the topology and properties of the system.
	Discussion		Discussion
	While this document does not define specific security solutions, we		While this document does not define specific security solutions, we
	note that common practices for protection against 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.
	skipping to change at page 27, line 8		skipping to change at page 27, line 16
	+-----------+---------------------------------------------+--------+		+-----------+---------------------------------------------+--------+
	| 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 of slaves. | MAY |		| | Authentication & authorization of slaves. | MAY |
	| +---------------------------------------------+--------+		| +---------------------------------------------+--------+
	| | PTP: Authentication of TCs by master. | MAY |		| | PTP: Authentication of 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 |
	skipping to change at page 29, line 33		skipping to change at page 29, line 41
	servers are a layer of intermediate clocks. These intermediate		servers are a layer of intermediate clocks. These intermediate
	clocks are referred to as "secondary servers" in [NTPv4].		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, a
	intermediate nodes MUST possess the security key (hop-by-hop		hop-by-hop security scheme must be used, since intermediate nodes
	security) since they must be able to send time information to the		must be able to send time information to the slaves, or to modify
	slaves, or to modify time information sent through them.		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.
End of changes. 18 change blocks.
	34 lines changed or deleted		36 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/