< draft-ietf-ntp-network-time-security-12.txt   draft-ietf-ntp-network-time-security-13.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: June 23, 2016 Google Inc. Expires: August 28, 2016 Google Inc.
K. Teichel K. Teichel
PTB PTB
December 21, 2015 February 25, 2016
Network Time Security Network Time Security
draft-ietf-ntp-network-time-security-12 draft-ietf-ntp-network-time-security-13
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 June 23, 2016. This Internet-Draft will expire on August 28, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 51 skipping to change at page 2, line 51
6.2.2. Goals of the Broadcast Time Synchronization Exchange 11 6.2.2. Goals of the Broadcast Time Synchronization Exchange 11
6.2.3. Message Type: "server_broad" . . . . . . . . . . . . 11 6.2.3. Message Type: "server_broad" . . . . . . . . . . . . 11
6.2.4. Procedure Overview of Broadcast Time Synchronization 6.2.4. Procedure Overview of Broadcast Time Synchronization
Exchange . . . . . . . . . . . . . . . . . . . . . . 12 Exchange . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . . . 13 6.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . . . 13
6.3.1. Preconditions for the Broadcast Keycheck Exchange . . 13 6.3.1. Preconditions for the Broadcast Keycheck Exchange . . 13
6.3.2. Goals of the Broadcast Keycheck Exchange . . . . . . 14 6.3.2. Goals of the Broadcast Keycheck Exchange . . . . . . 14
6.3.3. Message Type: "client_keycheck" . . . . . . . . . . . 14 6.3.3. Message Type: "client_keycheck" . . . . . . . . . . . 14
6.3.4. Message Type: "server_keycheck" . . . . . . . . . . . 14 6.3.4. Message Type: "server_keycheck" . . . . . . . . . . . 14
6.3.5. Procedure Overview of the Broadcast Keycheck Exchange 15 6.3.5. Procedure Overview of the Broadcast Keycheck Exchange 15
7. Server Seed Considerations . . . . . . . . . . . . . . . . . 16 7. Server Seed, Hash Algorithms and Generating MACs . . . . . . 16
8. Hash Algorithms and MAC Generation . . . . . . . . . . . . . 16 7.1. Server Seed . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 16 7.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 16
8.2. MAC Calculation . . . . . . . . . . . . . . . . . . . . . 17 7.3. MAC Calculation . . . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Initial Verification of the Server Certificates . . . . 17 9.2. Initial Verification of the Server Certificates . . . . . 18
10.3. Revocation of Server Certificates . . . . . . . . . . . 18 9.3. Revocation of Server Certificates . . . . . . . . . . . . 18
10.4. Mitigating Denial-of-Service for broadcast packets . . . 18 9.4. Mitigating Denial-of-Service for broadcast packets . . . 18
10.5. Delay Attack . . . . . . . . . . . . . . . . . . . . . . 18 9.5. Delay Attack . . . . . . . . . . . . . . . . . . . . . . 19
10.6. Random Number Generation . . . . . . . . . . . . . . . . 20 9.6. Random Number Generation . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. (informative) TICTOC Security Requirements . . . . . 22 Appendix A. (informative) TICTOC Security Requirements . . . . . 22
Appendix B. (normative) Inherent Association Protocol Messages . 23 Appendix B. (normative) Inherent Association Protocol Messages . 23
B.1. Overview of NTS with Inherent Association Protocol . . . 23 B.1. Overview of NTS with Inherent Association Protocol . . . 23
B.2. Access Message Exchange . . . . . . . . . . . . . . . . . 24 B.2. Access Message Exchange . . . . . . . . . . . . . . . . . 24
B.2.1. Goals of the Access Message Exchange . . . . . . . . 24 B.2.1. Goals of the Access Message Exchange . . . . . . . . 24
B.2.2. Message Type: "client_access" . . . . . . . . . . . . 24 B.2.2. Message Type: "client_access" . . . . . . . . . . . . 24
B.2.3. Message Type: "server_access" . . . . . . . . . . . . 24 B.2.3. Message Type: "server_access" . . . . . . . . . . . . 24
B.2.4. Procedure Overview of the Access Exchange . . . . . . 24 B.2.4. Procedure Overview of the Access Exchange . . . . . . 25
B.3. Association Message Exchange . . . . . . . . . . . . . . 25 B.3. Association Message Exchange . . . . . . . . . . . . . . 25
B.3.1. Goals of the Association Exchange . . . . . . . . . . 25 B.3.1. Goals of the Association Exchange . . . . . . . . . . 25
B.3.2. Message Type: "client_assoc" . . . . . . . . . . . . 25 B.3.2. Message Type: "client_assoc" . . . . . . . . . . . . 26
B.3.3. Message Type: "server_assoc" . . . . . . . . . . . . 26 B.3.3. Message Type: "server_assoc" . . . . . . . . . . . . 26
B.3.4. Procedure Overview of the Association Exchange . . . 26 B.3.4. Procedure Overview of the Association Exchange . . . 27
B.4. Cookie Message Exchange . . . . . . . . . . . . . . . . . 27 B.4. Cookie Message Exchange . . . . . . . . . . . . . . . . . 28
B.4.1. Goals of the Cookie Exchange . . . . . . . . . . . . 28 B.4.1. Goals of the Cookie Exchange . . . . . . . . . . . . 28
B.4.2. Message Type: "client_cook" . . . . . . . . . . . . . 28 B.4.2. Message Type: "client_cook" . . . . . . . . . . . . . 29
B.4.3. Message Type: "server_cook" . . . . . . . . . . . . . 28 B.4.3. Message Type: "server_cook" . . . . . . . . . . . . . 29
B.4.4. Procedure Overview of the Cookie Exchange . . . . . . 29 B.4.4. Procedure Overview of the Cookie Exchange . . . . . . 30
B.4.5. Broadcast Parameter Messages . . . . . . . . . . . . 30 B.4.5. Broadcast Parameter Messages . . . . . . . . . . . . 31
Appendix C. (normative) Using TESLA for Broadcast-Type Messages 32 Appendix C. (normative) Using TESLA for Broadcast-Type Messages 33
C.1. Server Preparation . . . . . . . . . . . . . . . . . . . 32 C.1. Server Preparation . . . . . . . . . . . . . . . . . . . 33
C.2. Client Preparation . . . . . . . . . . . . . . . . . . . 34 C.2. Client Preparation . . . . . . . . . . . . . . . . . . . 35
C.3. Sending Authenticated Broadcast Packets . . . . . . . . . 35 C.3. Sending Authenticated Broadcast Packets . . . . . . . . . 36
C.4. Authentication of Received Packets . . . . . . . . . . . 35 C.4. Authentication of Received Packets . . . . . . . . . . . 36
Appendix D. (informative) Dependencies . . . . . . . . . . . . . 37 Appendix D. (informative) Dependencies . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Time synchronization protocols are increasingly utilized to Time synchronization protocols are increasingly utilized to
synchronize clocks in networked infrastructures. Successful attacks synchronize clocks in networked infrastructures. Successful attacks
against the time synchronization protocol can seriously degrade the against the time synchronization protocol can seriously degrade the
reliable performance of such infrastructures. Therefore, time reliable performance of such infrastructures. Therefore, time
synchronization protocols have to be secured if they are applied in synchronization protocols have to be secured if they are applied in
environments that are prone to malicious attacks. This can be environments that are prone to malicious attacks. This can be
accomplished either by utilization of external security protocols, accomplished either by utilization of external security protocols,
like IPsec or TLS, or by intrinsic security measures of the time like IPsec or TLS, or by intrinsic security measures of the time
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 generic security measures which
these and possibly other protocols to verify the authenticity of the enable these and possibly other protocols to verify the authenticity
time server/master and the integrity of the time synchronization of the time server/master and the integrity of the time
protocol packets. The utilization of these measures for a given synchronization protocol packets. The utilization of these measures
specific time synchronization protocol has to be described in a for a given specific time synchronization protocol has to be
separate document. described in a 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
executed in a fast manner, and that the measures do not require a executed in a fast manner, and that the measures do not require a
skipping to change at page 6, line 36 skipping to change at page 6, line 36
The cookie deterministically depends on KIV as long as the server The cookie deterministically depends on KIV as long as the server
seed stays the same. The server seed has to be refreshed seed stays the same. The server seed has to be refreshed
periodically in order to provide key freshness as required in periodically in order to provide key freshness as required in
[RFC7384]. See Section 7 for details on seed refreshing. [RFC7384]. See Section 7 for details on seed refreshing.
Since the server does not keep a state of the client, it has to Since the server does not keep a state of the client, it has to
recalculate the cookie each time it receives a unicast time recalculate the cookie each time it receives a unicast time
synchronization request from the client. To this end, the client has synchronization request from the client. To this end, the client has
to attach its KIV to each request (see Section 6.1). to attach its KIV to each request (see Section 6.1).
Note: The communication of the KIV and the cookie can be performed
between client and server directly, or via a third party key
distribution entity.
For broadcast-type messages, authenticity and integrity of the time For broadcast-type messages, authenticity and integrity of the time
synchronization packets are also ensured by a MAC, which is attached synchronization packets are also ensured by a MAC, which is attached
to the time synchronization packet by the sender. Verification of to the time synchronization packet by the sender. Verification of
the broadcast-type packets' authenticity is based on the TESLA the broadcast-type packets' authenticity is based on the TESLA
protocol, in particular on its "not re-using keys" scheme, see protocol, in particular on its "not re-using keys" scheme, see
Section 3.7.2 of [RFC4082]. TESLA uses a one-way chain of keys, Section 3.7.2 of [RFC4082]. TESLA uses a one-way chain of keys,
where each key is the output of a one-way function applied to the where each key is the output of a one-way function applied to the
previous key in the chain. The server securely shares the last previous key in the chain. The server securely shares the last
element of the chain with all clients. The server splits time into element of the chain with all clients. The server splits time into
intervals of uniform duration and assigns each key to an interval in intervals of uniform duration and assigns each key to an interval in
skipping to change at page 9, line 23 skipping to change at page 9, line 23
client MUST save the included nonce and the transmit_timestamp client MUST save the included nonce and the transmit_timestamp
(from the time synchronization data) as a correlated pair for (from the time synchronization data) as a correlated pair for
later verification steps. Optionally, the client protects the later verification steps. Optionally, the client protects the
request message with an appended MAC. request message with an appended MAC.
2. Upon receipt of a time_request message, the server performs the 2. Upon receipt of a time_request message, the server performs the
following steps: following steps:
* It re-calculates the cookie. * It re-calculates the cookie.
* If the request message contains a MAC the server verifies the * If the request message contains a MAC the server re-calculates
received data. the MAC and compares this value with the MAC in the received
data.
+ If falsified the server MUST stop the processing of the + If the re-calculated MAC does not match the MAC in the
received data the server MUST stop the processing of the
request. request.
+ If verified the server continuous to process the request. + If the re-calculated MAC matches the MAC in the received
data the server continues to process the request.
* The server computes the necessary time synchronization data * The server computes the necessary time synchronization data
and constructs a time_response message as given in and constructs a time_response message as given in
Section 6.1.4. Section 6.1.4.
3. The client awaits a reply in the form of a time_response message. 3. The client awaits a reply in the form of a time_response message.
Upon receipt, it checks: Upon receipt, it checks:
* that the transmitted version number matches the one negotiated * that the transmitted version number matches the one negotiated
previously, previously,
skipping to change at page 14, line 31 skipping to change at page 14, line 31
contains contains
o the NTS message ID "client_keycheck", o the NTS message ID "client_keycheck",
o the NTS version number negotiated during association, o the NTS version number negotiated during association,
o a nonce, o a nonce,
o an interval number from the TESLA disclosure schedule, o an interval number from the TESLA disclosure schedule,
o the hash algorithm H negotiated during association, and o the hash algorithm H negotiated during association,
o the client's key input value KIV. o the client's key input value KIV, and
o optional: a MAC (generated with the cookie as key) for
verification of all of the above data.
6.3.4. Message Type: "server_keycheck" 6.3.4. Message Type: "server_keycheck"
A message of this type is sent by the server upon receipt of a A message of this type is sent by the server upon receipt of a
client_keycheck message during the broadcast loop of the server. client_keycheck message during the broadcast loop of the server.
Prior to this, the server MUST recalculate the client's cookie by Prior to this, the server MUST recalculate the client's cookie by
using the received key input value and the transmitted hash using the received key input value and the transmitted hash
algorithm. It contains algorithm. It contains
o the NTS message ID "server_keycheck" o the NTS message ID "server_keycheck"
skipping to change at page 14, line 48 skipping to change at page 15, line 4
client_keycheck message during the broadcast loop of the server. client_keycheck message during the broadcast loop of the server.
Prior to this, the server MUST recalculate the client's cookie by Prior to this, the server MUST recalculate the client's cookie by
using the received key input value and the transmitted hash using the received key input value and the transmitted hash
algorithm. It contains algorithm. It contains
o the NTS message ID "server_keycheck" o the NTS message ID "server_keycheck"
o the version number as transmitted in "client_keycheck, o the version number as transmitted in "client_keycheck,
o the nonce transmitted in the client_keycheck message, o the nonce transmitted in the client_keycheck message,
o the interval number transmitted in the client_keycheck message, o the interval number transmitted in the client_keycheck message,
and and
o a MAC (generated with the cookie as key) for verification of all o a MAC (generated with the cookie as key) for verification of all
of the above data. of the above data.
6.3.5. Procedure Overview of the Broadcast Keycheck Exchange 6.3.5. Procedure Overview of the Broadcast Keycheck Exchange
A broadcast keycheck message exchange consists of the following A broadcast keycheck message exchange consists of the following
steps: steps:
1. The client sends a client_keycheck message. It MUST memorize the 1. The client sends a client_keycheck message. It MUST memorize the
nonce and the time interval number that it sends as a correlated nonce and the time interval number that it sends as a correlated
pair. pair.
2. Upon receipt of a client_keycheck message, the server looks up 2. Upon receipt of a client_keycheck message the server performs as
whether it has already disclosed the key associated with the follows: If the client_keycheck message contains a MAC the server
interval number transmitted in that message. If it has not re-calculates the MAC and compares this value with the MAC in the
disclosed it, it constructs and sends the appropriate received data.
server_keycheck message as described in Section 6.3.4. For more
details, see also Appendix C. * If the re-calculated MAC does not match the MAC in the
received data the server MUST stop the processing of the
request.
* If the re-calculated MAC matches the MAC in the received data
the server continues to process the request: It looks up
whether it has already disclosed the key associated with the
interval number transmitted in that message. If it has not
disclosed it, it constructs and sends the appropriate
server_keycheck message as described in Section 6.3.4. For
more details, see also Appendix C.
3. The client awaits a reply in the form of a server_keycheck 3. The client awaits a reply in the form of a server_keycheck
message. On receipt, it performs the following checks: message. On receipt, it performs the following checks:
* that the transmitted version number matches the one negotiated * that the transmitted version number matches the one negotiated
previously, previously,
* that the transmitted nonce belongs to a previous * that the transmitted nonce belongs to a previous
client_keycheck message, client_keycheck message,
skipping to change at page 16, line 25 skipping to change at page 16, line 25
\ 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, Hash Algorithms and Generating MACs
7.1. Server Seed
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 7.2.
According to the requirements in [RFC7384], the server MUST refresh According to the requirements in [RFC7384], the server MUST refresh
each server seed periodically. Consequently, the cookie memorized by each server seed periodically. Consequently, the cookie memorized by
the client becomes obsolete. In this case, the client cannot verify the client becomes obsolete. In this case, the client cannot verify
the MAC attached to subsequent time response messages and has to the MAC attached to subsequent time response messages and has to
respond accordingly by re-initiating the protocol with a cookie respond accordingly by re-initiating the protocol with a cookie
request (Appendix B.4). request (Appendix B.4).
8. Hash Algorithms and MAC Generation 7.2. Hash Algorithms
8.1. Hash Algorithms
Hash algorithms are used for calculation of the cookie and the MAC. Hash algorithms are used for calculation of the cookie and the MAC.
The client and the server negotiate a hash algorithm H during the The client and the server negotiate a hash algorithm H during the
association phase at the beginning. The selected algorithm H is used association phase at the beginning. The selected algorithm H MUST be
for all hashing processes in that run. used for all hashing processes in that run.
In the TESLA scheme, hash algorithms are used as pseudo-random In the TESLA scheme, hash algorithms are used as pseudo-random
functions to construct the one-way key chain. Here, the utilized functions to construct the one-way key chain. Here, the utilized
hash algorithm is communicated by the server and is non-negotiable. hash algorithm is communicated by the server and is non-negotiable.
Note: Note: Any hash algorithm is prone to be compromised in the future.
A successful attack on a hash algorithm would enable any NTS
client to derive the server seed from its own cookie. Therefore,
the server MUST have separate seed values for its different
supported hash algorithms. This way, knowledge gained from an
attack on a hash algorithm H can at least only be used to
compromise such clients who use hash algorithm H as well.
Any hash algorithm is prone to be compromised in the future. A 7.3. MAC Calculation
successful attack on a hash algorithm would enable any NTS client
to derive the server seed from its own cookie. Therefore, the
server MUST have separate seed values for its different supported
hash algorithms. This way, knowledge gained from an attack on a
hash algorithm H can at least only be used to compromise such
clients who use hash algorithm H as well.
8.2. MAC Calculation For the calculation of the MAC, client and server MUST use a Keyed-
Hash Message Authentication Code (HMAC) as described in [RFC2104].
The HMAC is generated with the hash algorithm specified by the client
(see Section 7.2). The input values for the HMAC are the cookie and
the content that has to be protected by NTS.
For the calculation of the MAC, client and server use a Keyed-Hash 8. IANA Considerations
Message Authentication Code (HMAC) approach [RFC2104]. The HMAC is
generated with the hash algorithm specified by the client (see
Section 8.1).
9. IANA Considerations As mentioned, this document generically specifies security measures
whose utilization for any given specific time synchronization
protocol requires a separate document. Consequently, this document
itself does not have any IANA actions (TO BE REVIEWED).
10. Security Considerations 9. Security Considerations
10.1. Privacy Aspects of security for time synchronization protocols are treated
throughout this document. For a comprehensive discussion of security
requirements in time synchronization contexts, refer to [RFC7384].
See Appendix A for a tabular overview of how NTS deals with those
requirements.
Additional NTS specific discussion of security issues can be found in
the following subsections.
Note: Any separate document describing the utilization of NTS to a
specific time synchronization protocol may additionally introduce
discussion of its own specific security considerations.
9.1. Privacy
The payload of time synchronization protocol packets of two-way time The payload of time synchronization protocol packets of two-way time
transfer approaches like NTP and PTP consists basically of time transfer approaches like NTP and PTP consists basically of time
stamps, which are not considered secret [RFC7384]. Therefore, stamps, which are not considered secret [RFC7384]. Therefore,
encryption of the time synchronization protocol packet's payload is encryption of the time synchronization protocol packet's payload is
not considered in this document. However, an attacker can exploit not considered in this document. However, an attacker can exploit
the exchange of time synchronization protocol packets for topology the exchange of time synchronization protocol packets for topology
detection and inference attacks as described in [RFC7624]. To make detection and inference attacks as described in [RFC7624]. To make
such attacks more difficult, that draft recommends the encryption of such attacks more difficult, that draft recommends the encryption of
the packet payload. Yet, in the case of time synchronization the packet payload. Yet, in the case of time synchronization
protocols the confidentiality protection of time synchronization protocols the confidentiality protection of time synchronization
packet's payload is of secondary importance since the packet's meta packet's payload is of secondary importance since the packet's meta
data (IP addresses, port numbers, possibly packet size and regular data (IP addresses, port numbers, possibly packet size and regular
sending intervals) carry more information than the payload. To sending intervals) carry more information than the payload. To
enhance the privacy of the time synchronization partners, the usage enhance the privacy of the time synchronization partners, the usage
of tunnel protocols such as IPsec and MACsec, where applicable, is of tunnel protocols such as IPsec and MACsec, where applicable, is
therefore more suited than confidentiality protection of the payload. therefore more suited than confidentiality protection of the payload.
10.2. Initial Verification of the Server Certificates 9.2. Initial Verification of the Server Certificates
The client may wish to verify the validity of certificates during the The client may wish to verify the validity of certificates during the
initial association phase. Since it generally has no reliable time initial association phase. Since it generally has no reliable time
during this initial communication phase, it is impossible to verify during this initial communication phase, it is impossible to verify
the period of validity of the certificates. To solve this chicken- the period of validity of the certificates. To solve this chicken-
and-egg problem, the client has to rely on external means. and-egg problem, the client has to rely on external means.
10.3. Revocation of Server Certificates 9.3. Revocation of Server Certificates
According to Section 7, it is the client's responsibility to initiate According to Section 7, it is the client's responsibility to initiate
a new association with the server after the server's certificate a new association with the server after the server's certificate
expires. To this end, the client reads the expiration date of the expires. To this end, the client reads the expiration date of the
certificate during the certificate message exchange (Appendix B.3.3). certificate during the certificate message exchange (Appendix B.3.3).
Furthermore, certificates may also be revoked prior to the normal Furthermore, certificates may also be revoked prior to the normal
expiration date. To increase security the client MAY periodically expiration date. To increase security the client MAY periodically
verify the state of the server's certificate via Online Certificate verify the state of the server's certificate via Online Certificate
Status Protocol (OCSP) Online Certificate Status Protocol (OCSP) Status Protocol (OCSP) Online Certificate Status Protocol (OCSP)
[RFC6960]. [RFC6960].
10.4. Mitigating Denial-of-Service for broadcast packets 9.4. Mitigating Denial-of-Service for broadcast packets
TESLA authentication buffers packets for delayed authentication. TESLA authentication buffers packets for delayed authentication.
This makes the protocol vulnerable to flooding attacks, causing the This makes the protocol vulnerable to flooding attacks, causing the
client to buffer excessive numbers of packets. To add stronger DoS client to buffer excessive numbers of packets. To add stronger DoS
protection to the protocol, the client and the server use the "not protection to the protocol, the client and the server use the "not
re-using keys" scheme of TESLA as pointed out in Section 3.7.2 of RFC re-using keys" scheme of TESLA as pointed out in Section 3.7.2 of RFC
4082 [RFC4082]. In this scheme the server never uses a key for the 4082 [RFC4082]. In this scheme the server never uses a key for the
MAC generation more than once. Therefore, the client can discard any MAC generation more than once. Therefore, the client can discard any
packet that contains a disclosed key it already knows, thus packet that contains a disclosed key it already knows, thus
preventing memory flooding attacks. preventing memory flooding attacks.
Discussion: Note that an alternative approach to enhance TESLA's Discussion: Note that an alternative approach to enhance TESLA's
resistance against DoS attacks involves the addition of a group resistance against DoS attacks involves the addition of a group
MAC to each packet. This requires the exchange of an additional MAC to each packet. This requires the exchange of an additional
shared key common to the whole group. This adds additional shared key common to the whole group. This adds additional
complexity to the protocol and hence is currently not considered complexity to the protocol and hence is currently not considered
in this document. in this document.
10.5. Delay Attack 9.5. Delay Attack
In a packet delay attack, an adversary with the ability to act as a In a packet delay attack, an adversary with the ability to act as a
MITM delays time synchronization packets between client and server MITM delays time synchronization packets between client and server
asymmetrically [RFC7384]. This prevents the client from accurately asymmetrically [RFC7384]. This prevents the client from accurately
measuring the network delay, and hence its time offset to the server measuring the network delay, and hence its time offset to the server
[Mizrahi]. The delay attack does not modify the content of the [Mizrahi]. The delay attack does not modify the content of the
exchanged synchronization packets. Therefore, cryptographic means do exchanged synchronization packets. Therefore, cryptographic means do
not provide a feasible way to mitigate this attack. However, several not provide a feasible way to mitigate this attack. However, several
non-cryptographic precautions can be taken in order to detect this non-cryptographic precautions can be taken in order to detect this
attack. attack.
skipping to change at page 20, line 5 skipping to change at page 20, line 20
accumulate until the loose time synchronization requirement is accumulate until the loose time synchronization requirement is
violated, which breaks the TESLA scheme. To mitigate this violated, which breaks the TESLA scheme. To mitigate this
vulnerability the security condition in TESLA has to be supplemented vulnerability the security condition in TESLA has to be supplemented
by an additional check in which the client, upon receipt of a by an additional check in which the client, upon receipt of a
broadcast message, verifies the status of the corresponding key via a broadcast message, verifies the status of the corresponding key via a
unicast message exchange with the broadcast server (see Appendix C.4 unicast message exchange with the broadcast server (see Appendix C.4
for a detailed description of this check). Note that a broadcast for a detailed description of this check). Note that a broadcast
client should also apply the above-mentioned precautions as far as client should also apply the above-mentioned precautions as far as
possible. possible.
10.6. Random Number Generation 9.6. Random Number Generation
At various points of the protocol, the generation of random numbers At various points of the protocol, the generation of random numbers
is required. The employed methods of generation need to be is required. The employed methods of generation need to be
cryptographically secure. See [RFC4086] for guidelines concerning cryptographically secure. See [RFC4086] for guidelines concerning
this topic. this topic.
11. Acknowledgements 10. Acknowledgements
The authors would like to thank Tal Mizrahi, Russ Housley, Steven The authors would like to thank Tal Mizrahi, Russ Housley, Steven
Bellovin, David Mills, Kurt Roeckx, Rainer Bermbach, Martin Langer Bellovin, David Mills, Kurt Roeckx, Rainer Bermbach, Martin Langer
and Florian Weimer for discussions and comments on the design of NTS. and Florian Weimer for discussions and comments on the design of NTS.
Also, thanks go to Harlan Stenn for his technical review and specific Also, thanks go to Harlan Stenn and Richard Welty for their technical
text contributions to this document. review and specific text contributions to this document.
12. References 11. References
12.1. Normative References 11.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, DOI Hashing for Message Authentication", RFC 2104, DOI
10.17487/RFC2104, February 1997, 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>. <http://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 20, line 44 skipping to change at page 21, line 15
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, Transform Introduction", RFC 4082, DOI 10.17487/RFC4082,
June 2005, <http://www.rfc-editor.org/info/rfc4082>. June 2005, <http://www.rfc-editor.org/info/rfc4082>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <http://www.rfc-editor.org/info/rfc7384>. October 2014, <http://www.rfc-editor.org/info/rfc7384>.
12.2. Informative References 11.2. Informative References
[I-D.ietf-ntp-cms-for-nts-message] [I-D.ietf-ntp-cms-for-nts-message]
Sibold, D., Teichel, K., Roettger, S., and R. Housley, Sibold, D., Teichel, K., Roettger, S., and R. Housley,
"Protecting Network Time Security Messages with the "Protecting Network Time Security Messages with the
Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms- Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms-
for-nts-message-04 (work in progress), July 2015. for-nts-message-04 (work in progress), July 2015.
[I-D.ietf-tictoc-multi-path-synchronization] [I-D.ietf-tictoc-multi-path-synchronization]
Shpiner, A., Tse, R., Schelp, C., and T. Mizrahi, "Multi- Shpiner, A., Tse, R., Schelp, C., and T. Mizrahi, "Multi-
Path Time Synchronization", draft-ietf-tictoc-multi-path- Path Time Synchronization", draft-ietf-tictoc-multi-path-
skipping to change at page 23, line 15 skipping to change at page 23, line 33
+---------+------------------------------+-------------+------------+ +---------+------------------------------+-------------+------------+
| 5.9 | Protection against Packet | MUST | Limited*) | | 5.9 | Protection against Packet | MUST | Limited*) |
| | Delay and Interception | | | | | Delay and Interception | | |
| | Attacks | | | | | Attacks | | |
+---------+------------------------------+-------------+------------+ +---------+------------------------------+-------------+------------+
| 5.10 | Secure mode | MUST | OK | | 5.10 | Secure mode | MUST | OK |
+---------+------------------------------+-------------+------------+ +---------+------------------------------+-------------+------------+
| | Hybrid mode | SHOULD | - | | | Hybrid mode | SHOULD | - |
+---------+------------------------------+-------------+------------+ +---------+------------------------------+-------------+------------+
*) See discussion in Section 10.5. *) See discussion in Section 9.5.
Comparison of NTS specification against Security Requirements of Time Comparison of NTS specification against Security Requirements of Time
Protocols in Packet Switched Networks (RFC 7384) Protocols in Packet Switched Networks (RFC 7384)
Appendix B. (normative) Inherent Association Protocol Messages Appendix B. (normative) Inherent Association Protocol Messages
This appendix presents a procedure that performs the association, the This appendix presents a procedure that performs the association, the
cookie, and also the broadcast parameter message exchanges between a cookie, and also the broadcast parameter message exchanges between a
client and a server. This procedure is one possible way to achieve client and a server. This procedure is one possible way to achieve
the preconditions listed in Sections Section 6.1.1, Section 6.2.1, the preconditions listed in Sections Section 6.1.1, Section 6.2.1,
skipping to change at page 24, line 34 skipping to change at page 25, line 4
association exchange with the server in the future. It contains: association exchange with the server in the future. It contains:
o the NTS message ID "client_access". o the NTS message ID "client_access".
B.2.3. Message Type: "server_access" B.2.3. Message Type: "server_access"
This message is sent by the server on receipt of a client_access This message is sent by the server on receipt of a client_access
message. It contains: message. It contains:
o the NTS message ID "server_access", o the NTS message ID "server_access",
o an access key. o an access key.
B.2.4. Procedure Overview of the Access Exchange B.2.4. Procedure Overview of the Access Exchange
For an access exchange, the following steps are performed: For an access exchange, the following steps are performed:
1. The client sends a client_access message to the server. 1. The client sends a client_access message to the server.
2. Upon receipt of a client_access, the server calculates the access 2. Upon receipt of a client_access, the server calculates the access
key according to key. It then sends a reply in the form of a server_access
message. The server must either memorize the access key or
access_key = HMAC(server seed; address of client), alternatively apply a means by which it can reconstruct the
access key. Note that in both cases the access key must be
then it constructs and sends a reply in the form of a correlated with the address of the requester. Note also that if
server_access message. In general the address of the client will the server memorizes the access key for a requester, it has to
be represented by the IP address of the client. keep state for a certain amount of time.
3. The client waits for a response in the form of a server_access 3. The client waits for a response in the form of a server_access
message. Upon receipt of one, it MUST memorize the included message. Upon receipt of one, it MUST memorize the included
access key. access key.
B.3. Association Message Exchange B.3. Association Message Exchange
In this message exchange, the participants negotiate the hash and In this message exchange, the participants negotiate the hash and
encryption algorithms that are used throughout the protocol. In encryption algorithms that are used throughout the protocol. In
addition, the client receives the certification chain up to a trusted addition, the client receives the certification chain up to a trusted
skipping to change at page 27, line 25 skipping to change at page 28, line 6
* 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 and that this proposal was not altered. 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. 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 Check access key |
+------------------------+
| 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 |
+-----------+------------+ +-----------+------------+
| |
<-+-> <-+->
Server ---------------------------> Server --------------------------->
skipping to change at page 38, line 4 skipping to change at page 38, line 34
| | public key | server | messages. The client uses | | | public key | server | messages. The client uses |
| | (encryption) | | the private key to decrypt | | | (encryption) | | the private key to decrypt |
| +--------------+--------+ them. The certificate is | | +--------------+--------+ them. The certificate is |
| | certificate | client | sent in client_cook messages, | | | certificate | client | sent in client_cook messages, |
| | | | where it is used for trans- | | | | | where it is used for trans- |
| | | | portation of the public key | | | | | portation of the public key |
| | | | as well as (optionally) for | | | | | as well as (optionally) for |
| | | | verification of client | | | | | verification of client |
| | | | authorization. | | | | | authorization. |
+---------+--------------+--------+-------------------------------+ +---------+--------------+--------+-------------------------------+
+------------<---------------+
| At least one | This table shows the kind of cryptographic resources that NTS
V successful | participants of server and client role should have ready before NTS
++====[ ]===++ ++=====^=====++ communication starts.
|| Cookie || ||Association||
|| Exchange || || Exchange || ++===========================================++
++====_ _===++ ++===========++ || ||
|| Secure Authentication and Cookie Exchange ||
|| ||
++=======_ _=================================++
| |
| At least one | At least one
| successful | successful
V V
++=======[ ]=======++ ++=======[ ]=======++
|| Unicast Time |>-----\ As long as further || Unicast Time |>-----\ As long as further
|| Synchronization || | synchronization || Synchronization || | synchronization
|| Exchange(s) |<-----/ is desired || Exchange(s) |<-----/ is desired
++=======_ _=======++ ++=======_ _=======++
| |
skipping to change at page 39, line 5 skipping to change at page 39, line 51
/ \ / \
either / \ or either / \ or
/----------/ \-------------\ /----------/ \-------------\
| | | |
V V V V
++========[ ]========++ ++========[ ]========++ ++========[ ]========++ ++========[ ]========++
|| Keycheck Exchange || || Keycheck Exchange || || Keycheck Exchange || || Keycheck Exchange ||
++===================++ || with TimeSync || ++===================++ || with TimeSync ||
++===================++ ++===================++
This diagram shows the dependencies between the different message
exchanges and procedures which NTS offers.
Authors' Addresses Authors' Addresses
Dieter Sibold Dieter Sibold
Physikalisch-Technische Bundesanstalt Physikalisch-Technische Bundesanstalt
Bundesallee 100 Bundesallee 100
Braunschweig D-38116 Braunschweig D-38116
Germany Germany
Phone: +49-(0)531-592-8420 Phone: +49-(0)531-592-8420
Fax: +49-531-592-698420 Fax: +49-531-592-698420
 End of changes. 46 change blocks. 
105 lines changed or deleted 148 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/