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.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/