< draft-ietf-ntp-network-time-security-07.txt		draft-ietf-ntp-network-time-security-08.txt >
	NTP Working Group D. Sibold		NTP Working Group D. Sibold
	Internet-Draft PTB		Internet-Draft PTB
	Intended status: Standards Track S. Roettger		Intended status: Standards Track S. Roettger
	Expires: September 4, 2015 Google Inc.		Expires: September 6, 2015 Google Inc.
	K. Teichel		K. Teichel
	PTB		PTB
	March 3, 2015		March 5, 2015
	Network Time Security		Network Time Security
	draft-ietf-ntp-network-time-security-07.txt		draft-ietf-ntp-network-time-security-08.txt
	Abstract		Abstract
	This document describes Network Time Security (NTS), a collection of		This document describes Network Time Security (NTS), a collection of
	measures that enable secure time synchronization with time servers		measures that enable secure time synchronization with time servers
	using protocols like the Network Time Protocol (NTP) or the Precision		using protocols like the Network Time Protocol (NTP) or the Precision
	Time Protocol (PTP). Its design considers the special requirements		Time Protocol (PTP). Its design considers the special requirements
	of precise timekeeping which are described in Security Requirements		of precise timekeeping which are described in Security Requirements
	of Time Protocols in Packet Switched Networks [RFC7384].		of Time Protocols in Packet Switched Networks [RFC7384].
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on September 4, 2015.		This Internet-Draft will expire on September 6, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4		2.1. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4
	2.2. Common Terminology for PTP and NTP . . . . . . . . . . . 4		2.2. Common Terminology for PTP and NTP . . . . . . . . . . . 4
	3. Security Threats . . . . . . . . . . . . . . . . . . . . . . 4		3. Security Threats . . . . . . . . . . . . . . . . . . . . . . 4
	4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. NTS Overview . . . . . . . . . . . . . . . . . . . . . . . . 5		5. NTS Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
	6. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 6		6. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 6
	6.1. Association Message Exchange . . . . . . . . . . . . . . 7		6.1. Association Message Exchange . . . . . . . . . . . . . . 7
	6.1.1. Goals of the Association Exchange . . . . . . . . . . 7		6.1.1. Goals of the Association Exchange . . . . . . . . . . 7
	6.1.2. Message Type: "client_assoc" . . . . . . . . . . . . 7		6.1.2. Message Type: "client_assoc" . . . . . . . . . . . . 7
	6.1.3. Message Type: "server_assoc" . . . . . . . . . . . . 7		6.1.3. Message Type: "server_assoc" . . . . . . . . . . . . 8
	6.1.4. Procedure Overview of the Association Exchange . . . 8		6.1.4. Procedure Overview of the Association Exchange . . . 8
	6.2. Cookie Messages . . . . . . . . . . . . . . . . . . . . . 9		6.2. Cookie Messages . . . . . . . . . . . . . . . . . . . . . 9
	6.2.1. Goals of the Cookie Exchange . . . . . . . . . . . . 9		6.2.1. Goals of the Cookie Exchange . . . . . . . . . . . . 10
	6.2.2. Message Type: "client_cook" . . . . . . . . . . . . . 10		6.2.2. Message Type: "client_cook" . . . . . . . . . . . . . 10
	6.2.3. Message Type: "server_cook" . . . . . . . . . . . . . 10		6.2.3. Message Type: "server_cook" . . . . . . . . . . . . . 10
	6.2.4. Procedure Overview of the Cookie Exchange . . . . . . 11		6.2.4. Procedure Overview of the Cookie Exchange . . . . . . 11
	6.3. Unicast Time Synchronisation Messages . . . . . . . . . . 12		6.3. Unicast Time Synchronisation Messages . . . . . . . . . . 12
	6.3.1. Goals of the Unicast Time Synchronization Exchange . 12		6.3.1. Goals of the Unicast Time Synchronization Exchange . 12
	6.3.2. Message Type: "time_request" . . . . . . . . . . . . 12		6.3.2. Message Type: "time_request" . . . . . . . . . . . . 12
	6.3.3. Message Type: "time_response" . . . . . . . . . . . . 13		6.3.3. Message Type: "time_response" . . . . . . . . . . . . 13
	6.3.4. Procedure Overview of the Unicast Time		6.3.4. Procedure Overview of the Unicast Time
	Synchronization Exchange . . . . . . . . . . . . . . 13		Synchronization Exchange . . . . . . . . . . . . . . 13
	6.4. Broadcast Parameter Messages . . . . . . . . . . . . . . 14		6.4. Broadcast Parameter Messages . . . . . . . . . . . . . . 14
	skipping to change at page 4, line 10 ¶		skipping to change at page 4, line 10 ¶
	synchronization protocol.		synchronization protocol.
	The two most popular time synchronization protocols, the Network Time		The two most popular time synchronization protocols, the Network Time
	Protocol (NTP) [RFC5905] and the Precision Time Protocol (PTP)		Protocol (NTP) [RFC5905] and the Precision Time Protocol (PTP)
	[IEEE1588], currently do not provide adequate intrinsic security		[IEEE1588], currently do not provide adequate intrinsic security
	precautions. This document specifies security measures which enable		precautions. This document specifies security measures which enable
	these and possibly other protocols to verify the authenticity of the		these and possibly other protocols to verify the authenticity of the
	time server/master and the integrity of the time synchronization		time server/master and the integrity of the time synchronization
	protocol packets. The utilization of these measures for a given		protocol packets. The utilization of these measures for a given
	specific time synchronisation protocol has to be described in a		specific time synchronization protocol has to be described in a
	separate document.		separate document.
	[RFC7384] specifies that a security mechanism for timekeeping must be		[RFC7384] specifies that a security mechanism for timekeeping must be
	designed in such a way that it does not degrade the quality of the		designed in such a way that it does not degrade the quality of the
	time transfer. This implies that for time keeping the increase in		time transfer. This implies that for time keeping the increase in
	bandwidth and message latency caused by the security measures should		bandwidth and message latency caused by the security measures should
	be small. Also, NTP as well as PTP work via UDP and connections are		be small. Also, NTP as well as PTP work via UDP and connections are
	stateless on the server/master side. Therefore, all security		stateless on the server/master side. Therefore, all security
	measures in this document are designed in such a way that they add		measures in this document are designed in such a way that they add
	little demand for bandwidth, that the necessary calculations can be		little demand for bandwidth, that the necessary calculations can be
	skipping to change at page 5, line 35 ¶		skipping to change at page 5, line 35 ¶
	o Integration with protocols: NTS can be used to secure different		o Integration with protocols: NTS can be used to secure different
	time synchronization protocols, specifically at least NTP and PTP.		time synchronization protocols, specifically at least NTP and PTP.
	A client or server running an NTS-secured version of a time		A client or server running an NTS-secured version of a time
	protocol does not negatively affect other participants who are		protocol does not negatively affect other participants who are
	running unsecured versions of that protocol.		running unsecured versions of that protocol.
	5. NTS Overview		5. NTS Overview
	NTS applies X.509 certificates to verify the authenticity of the time		NTS applies X.509 certificates to verify the authenticity of the time
	server and to exchange a symmetric key, the so-called cookie. It		server and to exchange a symmetric key, the so-called cookie. A
	then uses the cookie to protect the authenticity and the integrity of		client needs a public/private key pair for encryption, with the
	subsequent unicast-type time synchronization packets. In order to do		public key enclosed in a certificate. A server needs a public/
	this, a Message Authentication Code (MAC) is attached to each time		private key pair for signing, with the public key enclosed in a
	synchronization packet. The calculation of the MAC includes the		certificate. If a participant intends to act as both a client and a
	whole time synchronization packet and the cookie which is shared		server, it MUST have two different key pairs for these purposes.
	between client and server. The cookie is calculated according to:
			After the cookie is exchanged, the client then uses it to protect the
			authenticity and the integrity of subsequent unicast-type time
			synchronization packets. In order to do this, a Message
			Authentication Code (MAC) is attached to each time synchronization
			packet. The calculation of the MAC includes the whole time
			synchronization packet and the cookie which is shared between client
			and server. The cookie is calculated according to:
	cookie = MSB_<b> (HMAC(server seed, H(certificate of client))),		cookie = MSB_<b> (HMAC(server seed, H(certificate of client))),
	with the server seed as the key, where H is a hash function, and		with the server seed as the key, where H is a hash function, and
	where the function MSB_<b> cuts off the b most significant bits of		where the function MSB_<b> cuts off the b most significant bits of
	the result of the HMAC function. The client's certificate contains		the result of the HMAC function. The client's certificate contains
	the client's public key and enables the server to identify the		the client's public key and enables the server to identify the
	client, if client authorization is desired. The server seed is a		client, if client authorization is desired. The server seed is a
	random value of bit length b that the server possesses, which has to		random value of bit length b that the server possesses, which has to
	remain secret. The cookie never changes as long as the server seed		remain secret. The cookie never changes as long as the server seed
	skipping to change at page 7, line 23 ¶		skipping to change at page 7, line 28 ¶
	6.1.1. Goals of the Association Exchange		6.1.1. Goals of the Association Exchange
	The association exchange:		The association exchange:
	o enables the client to verify any communication with the server as		o enables the client to verify any communication with the server as
	authentic,		authentic,
	o lets the participants negotiate NTS version and algorithms,		o lets the participants negotiate NTS version and algorithms,
	o guarantees authenticity of the negotiation result to the client.		o guarantees authenticity of the negotiation result to the client,
			o guarantees to the client that the negotiation result is based on
			the client's original, unaltered request.
	6.1.2. Message Type: "client_assoc"		6.1.2. Message Type: "client_assoc"
	The protocol sequence starts with the client sending an association		The protocol sequence starts with the client sending an association
	message, called client_assoc. This message contains		message, called client_assoc. This message contains
	o the NTS message ID "client_assoc",		o the NTS message ID "client_assoc",
	o a nonce,		o a nonce,
	skipping to change at page 8, line 48 ¶		skipping to change at page 9, line 12 ¶
	number or algorithms the server_assoc message MUST contain an		number or algorithms the server_assoc message MUST contain an
	error code.		error code.
	3. The client waits for a reply in the form of a server_assoc		3. The client waits for a reply in the form of a server_assoc
	message. After receipt of the message it performs the following		message. After receipt of the message it performs the following
	checks:		checks:
	* The client checks that the message contains a conforming		* The client checks that the message contains a conforming
	version number.		version number.
			* It checks that the nonce sent back by the server matches the
			one transmitted in client_assoc,
	* It also verifies that the server has chosen the encryption and		* It also verifies that the server has chosen the encryption and
	hash algorithms from its proposal sent in the client_assoc		hash algorithms from its proposal sent in the client_assoc
	message.		message and that this proposal was not altered.
	* Furthermore, it performs authenticity checks on the		* Furthermore, it performs authenticity checks on the
	certificate chain and the signature for the version number.		certificate chain and the signature.
	If one of the checks fails, the client MUST abort the run.		If one of the checks fails, the client MUST abort the run.
	+------------------------+		+------------------------+
	| o Choose version |		| o Choose version |
	| o Choose algorithms |		| o Choose algorithms |
	| o Acquire certificates |		| o Acquire certificates |
	| o Assemble response |		| o Assemble response |
	| o Create signature |		| o Create signature |
	+-----------+------------+		+-----------+------------+
	skipping to change at page 21, line 41 ¶		skipping to change at page 21, line 41 ¶
	+-----------+----------+		+-----------+----------+
	|		|
	<-+->		<-+->
	Server --------------------------------------------->		Server --------------------------------------------->
	\ /| \		\ /| \
	\ server_ client_ / \ server_		\ server_ client_ / \ server_
	\ broad keycheck / \ keycheck		\ broad keycheck / \ keycheck
	\| / \|		\| / \|
	Client --------------------------------------------->		Client --------------------------------------------->
	<-------- Extended broadcast time ------->		<-------- Extended broadcast time ------->
	synchronization. exchange		synchronization exchange
	<---- Keycheck exchange --->		<---- Keycheck exchange --->
	Procedure for extended broadcast time synchronization exchange.		Procedure for extended broadcast time synchronization exchange.
	7. Server Seed Considerations		7. Server Seed Considerations
	The server has to calculate a random seed which has to be kept		The server has to calculate a random seed which has to be kept
	secret. The server MUST generate a seed for each supported hash		secret. The server MUST generate a seed for each supported hash
	algorithm, see Section 8.1.		algorithm, see Section 8.1.
End of changes. 13 change blocks.
	18 lines changed or deleted		31 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/