draft-ietf-tictoc-security-requirements-00.txt		draft-ietf-tictoc-security-requirements-01.txt
	TICTOC Working Group Tal Mizrahi		TICTOC Working Group Tal Mizrahi
	Internet Draft Marvell		Internet Draft Marvell
	Intended status: Informational Karen O'Donoghue		Intended status: Informational Karen O'Donoghue
	Expires: May 2012 ISOC		Expires: September 2012 ISOC
	November 30, 2011		March 12, 2012
	TICTOC Security Requirements		TICTOC Security Requirements
	draft-ietf-tictoc-security-requirements-00.txt		draft-ietf-tictoc-security-requirements-01.txt
	Abstract		Abstract
	As time synchronization protocols are becoming increasingly common		As time synchronization protocols are becoming increasingly common
	and widely deployed, concern about their exposure to various security		and widely deployed, concern about their exposure to various security
	threats is increasing. This document defines a set of requirements		threats is increasing. This document defines a set of requirements
	for security solutions for time synchronization protocols, focusing		for security solutions for time synchronization protocols, focusing
	on the IEEE 1588 and NTP. This document also discusses the security		on the IEEE 1588 and NTP. This document also discusses the security
	impacts of time synchronization protocol practices, the time		impacts of time synchronization protocol practices, the time
	synchronization performance implications of external security		synchronization 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 May 30, 2012.		This Internet-Draft will expire on September 12, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction ................................................. 3		1. Introduction ................................................. 3
	2. Conventions Used in this Document ............................ 4		2. Conventions Used in this Document ............................ 4
	2.1. Terminology ............................................. 4		2.1. Terminology ............................................. 4
	2.2. Abbreviations ........................................... 4		2.2. Abbreviations ........................................... 4
	3. Security Threats ............................................. 4		3. Security Threats ............................................. 5
	3.1. Packet interception and manipulation .................... 5		3.1. Packet interception and manipulation .................... 5
	3.2. Spoofing ................................................ 5		3.2. Spoofing ................................................ 5
	3.3. Replay attack ........................................... 5		3.3. Replay attack ........................................... 5
	3.4. Rogue master attack ..................................... 5		3.4. Rogue master attack ..................................... 5
	3.5. Packet Interception and Removal ......................... 5		3.5. Packet Interception and Removal ......................... 6
	3.6. Packet delay manipulation ............................... 5		3.6. Packet delay manipulation ............................... 6
	3.7. Cryptographic performance attacks ....................... 6		3.7. Cryptographic performance attacks ....................... 6
	3.8. DoS attacks ............................................. 6		3.8. DoS attacks ............................................. 6
	3.9. Time source spoofing (e.g. GPS fraud) ................... 6		3.9. Time source spoofing (e.g. GPS fraud) ................... 6
	4. Security Requirements ........................................ 6		4. Security Requirements ........................................ 6
	4.1. Clock Identity Authentication ........................... 6		4.1. Clock Identity Authentication ........................... 6
	4.1.1. Authentication and Proventication of Masters ....... 6		4.1.1. Authentication of Masters .......................... 7
	4.1.2. Authentication of Slaves ........................... 7		4.1.2. Proventication of Masters .......................... 7
	4.1.3. PTP: Authentication of Transparent Clocks........... 7		4.1.3. Authentication of Slaves ........................... 7
	4.1.4. PTP: Authentication of Announce Messages ........... 8		4.1.4. PTP: Authentication of Transparent Clocks........... 8
	4.2. Data integrity .......................................... 8		4.1.5. PTP: Authentication of Announce Messages ........... 8
	4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 8		4.2. Data integrity .......................................... 9
			4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 9
	4.2.1.1. Hop by Hop Integrity Protection ............... 9		4.2.1.1. Hop by Hop Integrity Protection ............... 9
	4.2.1.2. End to End Integrity Protection ............... 9		4.2.1.2. End to End Integrity Protection .............. 10
	4.3. Availability ........................................... 10		4.3. Availability ........................................... 10
	4.4. Replay Protection ...................................... 10		4.4. Replay Protection ...................................... 10
	4.5. Cryptographic Keys & Security Associations ............. 10		4.5. Cryptographic Keys & Security Associations ............. 10
	4.5.1. Security Association .............................. 10		4.5.1. Security Association .............................. 10
	4.5.2. Unicast and Multicast ............................. 10		4.5.2. Unicast and Multicast ............................. 11
	4.5.3. Key Freshness ..................................... 11		4.5.3. Key Freshness ..................................... 11
	4.6. Performance ............................................ 11		4.6. Performance ............................................ 11
	4.7. Confidentiality......................................... 11		4.7. Confidentiality......................................... 12
	4.8. Protection against packet delay attacks ................ 12		4.8. Protection against packet delay attacks ................ 12
	5. Summary of Requirements ..................................... 12		4.9. Combining Secured with Unsecured Nodes ................. 12
	6. Additional security implications ............................ 13		4.9.1. Secure Mode ....................................... 13
	7. Issues for Further Discussion ............................... 13		4.9.2. Hybrid Mode ....................................... 13
	8. Security Considerations ..................................... 14		5. Summary of Requirements ..................................... 13
	9. IANA Considerations ......................................... 14		6. Additional security implications ............................ 14
	10. Acknowledgments ............................................ 14		7. Issues for Further Discussion ............................... 15
	11. References ................................................. 14		8. Security Considerations ..................................... 15
	11.1. Normative References .................................. 14		9. IANA Considerations ......................................... 15
	11.2. Informative References ................................ 15		10. Acknowledgments ............................................ 15
			11. References ................................................. 15
			11.1. Normative References .................................. 15
			11.2. Informative References ................................ 16
	1. Introduction		1. Introduction
	As time synchronization protocols are becoming increasingly common		As time synchronization protocols are becoming increasingly common
	and widely deployed, concern about the resulting exposure to various		and widely deployed, concern about the resulting exposure to various
	security threats is increasing. If a time synchronization protocol is		security threats is increasing. If a time synchronization protocol is
	compromised, the applications it serves are prone to a range of		compromised, the applications it serves are prone to a range of
	possible attacks including Denial-of-Service or incorrect behavior.		possible attacks including Denial-of-Service or incorrect behavior.
	This document focuses on the security aspects of the Precision Time		This document focuses on the security aspects of the Precision Time
	skipping to change at page 4, line 33		skipping to change at page 4, line 40
	document defines a specific security mechanism, but defines the		document defines a specific security mechanism, but defines the
	requirements that every security mechanism should comply to.		requirements that every security mechanism should comply to.
	This document refers to both PTP and NTP. For the sake of		This document refers to both PTP and NTP. For the sake of
	consistency, throughout the document the term "master" applies to		consistency, throughout the document the term "master" applies to
	both a PTP master and an NTP server. Similarly, the term "slave"		both a PTP master and an NTP server. Similarly, the term "slave"
	applies to both PTP slaves and NTP clients. The general term "clock"		applies to both PTP slaves and NTP clients. The general term "clock"
	refers to masters, slaves and PTP Transparent Clocks (TC). The term		refers to masters, slaves and PTP Transparent Clocks (TC). The term
	"protocol packets" is refers generically to PTP and NTP messages.		"protocol packets" is refers generically to PTP and NTP messages.
	2.2. Abbreviations		2.2. Terms & Abbreviations
	BC Boundary Clock		BC Boundary Clock
	MITM Man In The Middle		MITM Man In The Middle
	NTP Network Time Protocol		NTP Network Time Protocol
	OC Ordinary Clock		OC Ordinary Clock
	PTP Precision Time Protocol		PTP Precision Time Protocol
			Secured clock A clock that supports a security mechanism that
			complies to the requirements in this document
	TC Transparent Clock		TC Transparent Clock
			Unsecured clock A clock that does not support a security mechanism
			according to the requirments in this document
	3. Security Threats		3. Security Threats
	The following section defines the security threats that are discussed		The following section defines the security threats that are discussed
	in subsequent sections.		in subsequent sections.
	3.1. Packet interception and manipulation		3.1. Packet interception and manipulation
	A packet interception and manipulation attack results when a Man-In-		A packet interception and manipulation attack results when a Man-In-
	The-Middle (MITM) attacker intercepts timing protocol packets, alters		The-Middle (MITM) attacker intercepts timing protocol packets, alters
	skipping to change at page 6, line 48		skipping to change at page 7, line 13
	o Identification: verifying the identity of the peer clock.		o Identification: verifying the identity of the peer clock.
	o Authorization: verifying that the peer clock is permitted to play		o Authorization: verifying that the peer clock is permitted to play
	the role that it plays in the protocol. For example, some nodes		the role that it plays in the protocol. For example, some nodes
	may be permitted to be masters, while other nodes are only		may be permitted to be masters, while other nodes are only
	permitted to be slaves or TCs.		permitted to be slaves or TCs.
	The following subsections describe 4 distinct cases of clock		The following subsections describe 4 distinct cases of clock
	authentication.		authentication.
	4.1.1. Authentication and Proventication of Masters		4.1.1. Authentication of Masters
	Requirement		Requirement
			The security mechanism MUST support an authentication mechanism,
			allowing slave clocks to authenticate the identity of master clocks.
			4.1.2. Proventication of Masters
			Requirement
	The security mechanism MUST support a proventication mechanism, to be		The security mechanism MUST support a proventication mechanism, to be
	used in cases where end-to-end authentication is not possible.		used in cases where end-to-end authentication is not possible.
	Discussion		Discussion
	Slaves and transparent clocks authenticate masters in order to ensure		Slaves and transparent clocks authenticate masters in order to ensure
	the authenticity of the time source.		the authenticity of the time source.
	In some cases a slave is connected to an intermediate master, that is		In some cases a slave is connected to an intermediate master, that is
	not the primary time source. For example, in PTP a slave can be		not the primary time source. For example, in PTP a slave can be
	connected to a Boundary Clock (BC), which in turn is connected to a		connected to a Boundary Clock (BC), which in turn is connected to a
	grandmaster. A similar example in NTP is when a client is connected		grandmaster. A similar example in NTP is when a client is connected
	to a stratum 2 server, which is connected to a stratum 1 server. In		to a stratum 2 server, which is connected to a stratum 1 server. In
	both the PTP and the NTP cases, the slave authenticates the		both the PTP and the NTP cases, the slave authenticates the
	intermediate master, and the intermediate master authenticates the		intermediate master, and the intermediate master authenticates the
	primary master. This inductive authentication process is referred to		primary master. This inductive authentication process is referred to
	in [AutoKey] as proventication.		in [AutoKey] as proventication.
	4.1.2. Authentication of Slaves		4.1.3. Authentication of Slaves
	Requirement		Requirement
	The security mechanism SHOULD provide a means for a master to		The security mechanism SHOULD provide a means for a master to
	authenticate its slaves.		authenticate its slaves.
	Discussion		Discussion
	Slaves are authenticated by masters in order to verify that the slave		Slaves are authenticated by masters in order to verify that the slave
	is authorized to receive timing services from the master.		is authorized to receive timing services from the master.
	Authentication of slaves prevents unauthorized clocks from receiving		Authentication of slaves prevents unauthorized clocks from receiving
	time services, and also reduces unnecessary load on the master clock,		time services, and also reduces unnecessary load on the master clock,
	by preventing the master from serving unauthorized clocks. It could		by preventing the master from serving unauthorized clocks. It could
	be argued that the authentication of slaves could put a higher load		be argued that the authentication of slaves could put a higher load
	on the master then serving the unauthorized clock. This tradeoff will		on the master then serving the unauthorized clock. This tradeoff will
	need to be discussed further.		need to be discussed further.
	skipping to change at page 7, line 41		skipping to change at page 8, line 14
	Slaves are authenticated by masters in order to verify that the slave		Slaves are authenticated by masters in order to verify that the slave
	is authorized to receive timing services from the master.		is authorized to receive timing services from the master.
	Authentication of slaves prevents unauthorized clocks from receiving		Authentication of slaves prevents unauthorized clocks from receiving
	time services, and also reduces unnecessary load on the master clock,		time services, and also reduces unnecessary load on the master clock,
	by preventing the master from serving unauthorized clocks. It could		by preventing the master from serving unauthorized clocks. It could
	be argued that the authentication of slaves could put a higher load		be argued that the authentication of slaves could put a higher load
	on the master then serving the unauthorized clock. This tradeoff will		on the master then serving the unauthorized clock. This tradeoff will
	need to be discussed further.		need to be discussed further.
	4.1.3. PTP: Authentication of Transparent Clocks		4.1.4. PTP: Authentication of Transparent Clocks
	Requirement		Requirement
	The security mechanism for PTP SHOULD provide a means for a master to		The security mechanism for PTP SHOULD provide a means for a master to
	authenticate the TCs.		authenticate the TCs.
	Discussion		Discussion
	Transparent clocks are authenticated by peer masters, slaves and TCs.		Transparent clocks are authenticated by peer masters, slaves and TCs.
	Authentication of TCs, much like authentication of slaves, reduces		Authentication of TCs, much like authentication of slaves, reduces
	unnecessary load on the master clock and peer TCs, by preventing the		unnecessary load on the master clock and peer TCs, by preventing the
	master from serving unauthorized clocks. It also prevents malicious		master from serving unauthorized clocks. It also prevents malicious
	TCs from attacking the protocol by manipulating the correctionField.		TCs from attacking the protocol by manipulating the correctionField.
	It could also be argued that the authentication could result in a		It could also be argued that the authentication could result in a
	higher load then merely serving the unauthorized devices. This		higher load then merely serving the unauthorized devices. This
	tradeoff will need to be discussed further.		tradeoff will need to be discussed further.
	4.1.4. PTP: Authentication of Announce Messages		4.1.5. PTP: Authentication of Announce Messages
	Requirement		Requirement
	The security mechanism for PTP MUST support authentication of		The security mechanism for PTP MUST support authentication of
	Announce messages.		Announce messages.
	Discussion		Discussion
	Master election is performed in PTP using the Best Master Clock		Master election is performed in PTP using the Best Master Clock
	Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock		Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock
	attributes using Announce messages, and the best master is elected		attributes using Announce messages, and the best master is elected
	based on the information gathered from all the candidates. Announce		based on the information gathered from all the candidates. Announce
	messages must be authenticated in order to prevent malicious master		messages must be authenticated in order to prevent malicious master
	attacks.		attacks.
	Note, that this subsection specifies a requirement that is not		Note, that this subsection specifies a requirement that is not
	necessarily included in 4.1.1. or in 4.1.2. , since the BMCA is		necessarily included in 4.1.1. or in 4.1.3. , since the BMCA is
	initiated before clocks have been defined as masters or slaves.		initiated before clocks have been defined as masters or slaves.
	4.2. Data integrity		4.2. Data integrity
	Requirement		Requirement
	The security mechanism MUST protect the integrity of protocol		The security mechanism MUST protect the integrity of protocol
	packets.		packets.
	Discussion		Discussion
	skipping to change at page 12, line 27		skipping to change at page 12, line 46
	The security mechanism MAY include a means to detect packet delay		The security mechanism MAY include a means to detect packet delay
	attacks.		attacks.
	Requirement		Requirement
	The security mechanism MAY include a protection switching mechanism		The security mechanism MAY include a protection switching mechanism
	that allows a node that detects a delay attack to switch over to a		that allows a node that detects a delay attack to switch over to a
	secondary master.		secondary master.
			4.9. Combining Secured with Unsecured Nodes
			Integrating a security mechanism into a time synchronized system is a
			complex process, and in some cases may require a gradual process,
			where new equipment supports the security mechanism, and is required
			to interoperate with legacy equipment without the security features.
			4.9.1. Secure Mode
			Requirement
			The security mechanism MUST support a secure mode, where only secured
			clocks are permitted to take part in the synchronization protocol. A
			protocol packet received from an unsecured clock MUST be discarded.
			4.9.2. Hybrid Mode
			Requirement
			The security protocol MAY support a hybrid mode, where both secured
			and unsecured clocks are permitted to take part in the protocol.
			A master in the hybrid mode MUST be a secured clock.
			A secured slave in the hybrid mode MUST discard all protocol packets
			received from unsecured clocks.
			Discussion
			The hybrid mode allows both secured and unsecured clocks to take part
			in the synchronization protocol. It is essential that the existence
			of unsecured clocks does not compromise the security provided to
			secured clocks. Hence, secured slaves only "trust" protocol packets
			received from a secured clock. An unsecured clock can receive
			protocol packets from either secured clocks, or unsecured clocks.
	5. Summary of Requirements		5. Summary of Requirements
	+-----------+--------------------------------------+---------------+		+-----------+--------------------------------------+---------------+
	| Section | Requirement | Type |		| Section | Requirement | Type |
	+-----------+--------------------------------------+---------------+		+-----------+--------------------------------------+---------------+
	| 4.1. | Authentication of sender. | MUST |		| 4.1. | Authentication of sender. | MUST |
	| +--------------------------------------+---------------+		| +--------------------------------------+---------------+
			| | Authentication of master. | MUST |
			| +--------------------------------------+---------------+
	| | Proventication. | MUST |		| | Proventication. | MUST |
	| +--------------------------------------+---------------+		| +--------------------------------------+---------------+
	| | Authentication of slaves. | SHOULD |		| | Authentication of slaves. | SHOULD |
	| +--------------------------------------+---------------+		| +--------------------------------------+---------------+
	| | PTP: Authentication of TCs. | SHOULD |		| | PTP: Authentication of TCs. | SHOULD |
	| +--------------------------------------+---------------+		| +--------------------------------------+---------------+
	| | PTP: Authentication of Announce | SHOULD |		| | PTP: Authentication of Announce | SHOULD |
	| | messages. | |		| | messages. | |
	+-----------+--------------------------------------+---------------+		+-----------+--------------------------------------+---------------+
	| 4.2. | Integrity protection. | MUST |		| 4.2. | Integrity protection. | MUST |
	skipping to change at page 13, line 25		skipping to change at page 14, line 33
	| | quality of time transfer. | |		| | quality of time transfer. | |
	| +--------------------------------------+---------------+		| +--------------------------------------+---------------+
	| | Performance: lightweight. | SHOULD |		| | Performance: lightweight. | SHOULD |
	| +--------------------------------------+---------------+		| +--------------------------------------+---------------+
	| | Performance: storage, bandwidth. | MUST |		| | Performance: storage, bandwidth. | MUST |
	+-----------+--------------------------------------+---------------+		+-----------+--------------------------------------+---------------+
	| 4.7. | Confidentiality protection. | MAY |		| 4.7. | Confidentiality protection. | MAY |
	+-----------+--------------------------------------+---------------+		+-----------+--------------------------------------+---------------+
	| 4.8. | Protection against delay attacks. | MAY |		| 4.8. | Protection against delay attacks. | MAY |
	+-----------+--------------------------------------+---------------+		+-----------+--------------------------------------+---------------+
			| 4.9. | Secure mode. | MUST |
			| +--------------------------------------+---------------+
			| | Hybrid mode. | MAY |
			+-----------+--------------------------------------+---------------+
	Table 1 Summary of Security Requirements		Table 1 Summary of Security Requirements
	6. Additional security implications		6. Additional security implications
	This section will discuss additional security implications as		This section will discuss additional security implications as
	outlined in the questions below. Contributions are welcome and		outlined in the questions below. Contributions are welcome and
	encouraged.		encouraged.
	o What external security practices impact the security and		o What external security practices impact the security and
	performance of time keeping? (and what can be done to mitigate		performance of time keeping? (and what can be done to mitigate
	skipping to change at page 13, line 46		skipping to change at page 15, line 18
	o What are the security impacts of time synchronization protocol		o What are the security impacts of time synchronization protocol
	practices? (e.g. on-the-fly modification of timestamps)		practices? (e.g. on-the-fly modification of timestamps)
	o What are the dependencies between other security services and time		o What are the dependencies between other security services and time
	synchronization?		synchronization?
	7. Issues for Further Discussion		7. Issues for Further Discussion
	This section will discuss additional issues as identified below.		This section will discuss additional issues as identified below.
	Again, contributions are welcome and encouraged.
	o Integrity - end-to-end vs. hop-by-hop.
	o Supporting a hybrid network, where some nodes are security enabled
	and others are not.
	o The key distribution is outside the scope of this document.		o The key distribution is outside the scope of this document.
	Although this is a cardinal element in any security system, it is		Although this is a cardinal element in any security system, it is
	not a security requirement, and is thus not described here.		not a security requirement, and is thus not described here.
	8. Security Considerations		8. 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.
End of changes. 30 change blocks.
	46 lines changed or deleted		97 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/