draft-ietf-ntp-using-nts-for-ntp-00.txt   draft-ietf-ntp-using-nts-for-ntp-01.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 7, 2015 Google Inc Expires: January 7, 2016 Google Inc
K. Teichel K. Teichel
PTB PTB
March 06, 2015 July 06, 2015
Using the Network Time Security Specification to Secure the Network Time Using the Network Time Security Specification to Secure the Network Time
Protocol Protocol
draft-ietf-ntp-using-nts-for-ntp-00.txt draft-ietf-ntp-using-nts-for-ntp-01
Abstract Abstract
This document describes how to use the measures described in the This document describes how to use the measures described in the
Network Time Security (NTS) specification to secure time Network Time Security (NTS) specification to secure time
synchronization with servers using the Network Time Protocol (NTP). synchronization with servers using the Network Time Protocol (NTP).
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 7, 2015. This Internet-Draft will expire on January 7, 2016.
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 23 skipping to change at page 2, line 23
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. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 3. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4
4. Overview of NTS-Secured NTP . . . . . . . . . . . . . . . . . 4 4. Overview of NTS-Secured NTP . . . . . . . . . . . . . . . . . 4
4.1. Symmetric and Client/Server Mode . . . . . . . . . . . . 4 4.1. Symmetric and Client/Server Mode . . . . . . . . . . . . 4
4.2. Broadcast Mode . . . . . . . . . . . . . . . . . . . . . 4 4.2. Broadcast Mode . . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 4 5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 5
5.1. The Client . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. The Client . . . . . . . . . . . . . . . . . . . . . . . 5
5.1.1. The Client in Unicast Mode . . . . . . . . . . . . . 4 5.1.1. The Client in Unicast Mode . . . . . . . . . . . . . 5
5.1.2. The Client in Broadcast Mode . . . . . . . . . . . . 6 5.1.2. The Client in Broadcast Mode . . . . . . . . . . . . 7
5.2. The Server . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. The Server . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. The Server in Unicast Mode . . . . . . . . . . . . . 8 5.2.1. The Server in Unicast Mode . . . . . . . . . . . . . 9
5.2.2. The Server in Broadcast Mode . . . . . . . . . . . . 9 5.2.2. The Server in Broadcast Mode . . . . . . . . . . . . 9
6. Implementation Notes: ASN.1 Structures and Use of the CMS . . 9 6. Implementation Notes: ASN.1 Structures and Use of the CMS . . 10
6.1. Unicast Messages . . . . . . . . . . . . . . . . . . . . 9 6.1. Unicast Messages . . . . . . . . . . . . . . . . . . . . 10
6.1.1. Association Messages . . . . . . . . . . . . . . . . 9 6.1.1. Association Messages . . . . . . . . . . . . . . . . 10
6.1.2. Cookie Messages . . . . . . . . . . . . . . . . . . . 10 6.1.2. Cookie Messages . . . . . . . . . . . . . . . . . . . 11
6.1.3. Time Synchronization Messages . . . . . . . . . . . . 10 6.1.3. Time Synchronization Messages . . . . . . . . . . . . 11
6.2. Broadcast Messages . . . . . . . . . . . . . . . . . . . 11 6.2. Broadcast Messages . . . . . . . . . . . . . . . . . . . 12
6.2.1. Broadcast Parameter Messages . . . . . . . . . . . . 11 6.2.1. Broadcast Parameter Messages . . . . . . . . . . . . 12
6.2.2. Broadcast Time Synchronization Message . . . . . . . 11 6.2.2. Broadcast Time Synchronization Message . . . . . . . 12
6.2.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 11 6.2.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Usage of NTP Pools . . . . . . . . . . . . . . . . . . . 12 7.1. Employing Alternative Means for Association and Cookie
7.2. Server Seed Lifetime . . . . . . . . . . . . . . . . . . 12 Exchange . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3. Supported Hash Algorithms . . . . . . . . . . . . . . . . 12 7.2. Usage of NTP Pools . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7.3. Server Seed Lifetime . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.4. Supported Hash Algorithms . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Flow Diagrams of Client Behaviour . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Flow Diagrams of Client Behaviour . . . . . . . . . 14
Appendix B. Bit Lengths for Employed Primitives . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
One of the most popular time synchronization protocols, the Network One of the most popular time synchronization protocols, the Network
Time Protocol (NTP) [RFC5905], currently does not provide adequate Time Protocol (NTP) [RFC5905], currently does not provide adequate
intrinsic security precautions. The Network Time Security draft intrinsic security precautions. The Network Time Security draft
[I-D.ietf-ntp-network-time-security] specifies security measures [I-D.ietf-ntp-network-time-security] specifies security measures
which can be used to enable time synchronization protocols to verify which can be used to enable time synchronization protocols to verify
authenticity of the time server and integrity of the time authenticity of the time server and integrity of the time
synchronization protocol packets. synchronization protocol packets.
skipping to change at page 3, line 48 skipping to change at page 3, line 48
server has arrived without alteration. server has arrived without alteration.
o Modes of operation: Both the unicast and the broadcast mode of NTP o Modes of operation: Both the unicast and the broadcast mode of NTP
are supported. are supported.
o Hybrid mode: Both secure and insecure communication modes are o Hybrid mode: Both secure and insecure communication modes are
possible for both NTP servers and clients. possible for both NTP servers and clients.
o Compatibility: o Compatibility:
* Unsecured NTP associations are not be affected. * Unsecured NTP associations are not affected.
* An NTP server that does not support NTS are not affected by * An NTP server that does not support NTS is not affected by NTS-
NTS-secured authentication requests. secured authentication requests.
3. Terms and Abbreviations 3. Terms and Abbreviations
CMS Cryptographic Message Syntax [RFC5652]
HMAC Keyed-Hash Message Authentication Code
MAC Message Authentication Code
MITM Man In The Middle MITM Man In The Middle
NTP Network Time Protocol [RFC5905] NTP Network Time Protocol [RFC5905]
NTS Network Time Security NTS Network Time Security
TESLA Timed Efficient Stream Loss-Tolerant Authentication TESLA Timed Efficient Stream Loss-Tolerant Authentication [RFC4082]
MAC Message Authentication Code
HMAC Keyed-Hash Message Authentication Code
4. Overview of NTS-Secured NTP 4. Overview of NTS-Secured NTP
4.1. Symmetric and Client/Server Mode 4.1. Symmetric and Client/Server Mode
The server does not keep a state of the client. NTS applies X.509 The server does not keep a state of the client. NTS initially
certificates to verify the authenticity of the time server and to verifies the authenticity of the time server and exchanges a
exchange a symmetric key, the so-called cookie. The "association" symmetric key, the so-called cookie and a key input value (KIV). The
and "cookie" message exchanges are utilized for this. In subsequent "association" and "cookie" message exchanges described in
"unicast time synchronization" message exchanges, the cookie is then [I-D.ietf-ntp-network-time-security], Appendix B., can be utilized
used to protect authenticity and integrity of NTP unicast time for the exchange of the cookie and KIV. An implementation MUST
synchronization packets. This is achieved by a MAC attached to each support the use of these exchanges. It MAY additionally support the
time synchronization packet. use of any alternative secure communication for this purpose, as long
as it fulfills the preconditions given in
[I-D.ietf-ntp-network-time-security], Section 6.1.1.
After the cookie and KIV are exchanged, the participants then use
them to protect the authenticity and the integrity of subsequent
unicast-type time synchronization packets. In order to do this, the
server attaches a Message Authentication Code (MAC) 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. Therefore, the client can perform a
validity check for this MAC on reception of a time synchronization
packet.
4.2. Broadcast Mode 4.2. Broadcast Mode
After the client has accomplished the necessary initial time After the client has accomplished the necessary initial time
synchronization via client-server mode, a "broadcast parameter" synchronization via client-server mode, the necessary broadcast
message exchange is utilized to communicate the necessary broadcast parameters are communicated from the server to the client. The
parameters to the client. Subsequently, "broadcast time "broadcast parameter" message exchange described in
synchronization" message exchanges are utilized in combination with [I-D.ietf-ntp-network-time-security], Appendix B., can be utilized
optional "broadcast keycheck" exchanges to protect authenticity and for this communication. An implementation MUST support the use of
integrity of NTP broadcast time synchronization packets. This is this exchange. It MAY additionally support the use of any
also achieved by MACs. alternative secure communication for this purpose, as long as it
fulfills the necessary security goals (given in
[I-D.ietf-ntp-network-time-security], Section 6.2.1.).
After the client has received the necessry broadcast parameters,
"broadcast time synchronization" message exchanges are utilized in
combination with optional "broadcast keycheck" exchanges to protect
authenticity and integrity of NTP broadcast time synchronization
packets. As in the case of unicast time synchronization messages,
this is also achieved by MACs.
5. Protocol Sequence 5. Protocol Sequence
Throughout this section, the nonces, cookies and MACs mentioned have
bit lengths of B_nonce, B_cookie and B_mac, respectively. These bit
lengths are defined in Appendix B (Appendix B).
5.1. The Client 5.1. The Client
5.1.1. The Client in Unicast Mode 5.1.1. The Client in Unicast Mode
For a unicast run, the client performs the following steps: For a unicast run, the client performs the following steps:
1. It sends a client_assoc message to the server. It MUST keep the NOTE: Steps 1 through 4 MAY alternatively be replaced an alternative
transmitted nonce as well as the values for the version number secure mechanism for association and cookie exchange. An
and algorithms available for later checks. implementation MAY choose to replace either steps 1 and 2 or all
of the steps 1 through 4 by alternative secure communication.
2. It waits for a reply in the form of a server_assoc message. Step 1: It sends a client_assoc message to the server. It MUST keep
After receipt of the message it performs the following checks: the transmitted nonce as well as the values for the version number
and algorithms available for later checks.
* The client checks that the message contains a conforming Step 2: It waits for a reply in the form of a server_assoc message.
version number. After receipt of the message it performs the following checks:
* It checks that the nonce sent back by the server matches the * The client checks that the message contains a conforming
one transmitted in client_assoc, version number.
* It also verifies that the server has chosen the encryption and * It checks that the nonce sent back by the server matches the
hash algorithms from its proposal sent in the client_assoc one transmitted in client_assoc,
message and that this proposal was not altered.
* Furthermore, it performs authenticity checks on the * It also verifies that the server has chosen the encryption and
certificate chain and the signature. hash algorithms from its proposal sent in the client_assoc
message and that this proposal was not altered.
If one of the checks fails, the client MUST abort the run. * Furthermore, it performs authenticity checks on the certificate
Discussion: chain and the signature.
Note that by performing the above message exchange and checks, If one of the checks fails, the client MUST abort the run.
the client validates the authenticity of its immediate NTP
server only. It does not recursively validate the
authenticity of each NTP server on the time synchronization
chain. Recursive authentication (and authorization) as
formulated in RFC 7384 [RFC7384] depends on the chosen trust
anchor.
3. Next it sends a client_cook message to the server. The client Discussion: Note that by performing the above message exchange
MUST save the included nonce until the reply has been processed. and checks, the client validates the authenticity of its
immediate NTP server only. It does not recursively validate
the authenticity of each NTP server on the time synchronization
chain. Recursive authentication (and authorization) as
formulated in RFC 7384 [RFC7384] depends on the chosen trust
anchor.
4. It awaits a reply in the form of a server_cook message; upon Step 3: Next it sends a client_cook message to the server. The
receipt it executes the following actions: client MUST save the included nonce until the reply has been
processed.
* It verifies that the received version number matches the one Step 4: It awaits a reply in the form of a server_cook message; upon
negotiated beforehand. receipt it executes the following actions:
* It verifies the signature using the server's public key. The * It verifies that the received version number matches the one
signature has to authenticate the encrypted data. negotiated beforehand.
* It decrypts the encrypted data with its own private key. * It verifies the signature using the server's public key. The
signature has to authenticate the encrypted data.
* It checks that the decrypted message is of the expected * It decrypts the encrypted data with its own private key.
format: the concatenation of a 128 bit nonce and a 128 bit
cookie.
* It verifies that the received nonce matches the nonce sent in * It checks that the decrypted message is of the expected format:
the client_cook message. the concatenation of a B_nonce bit nonce and a B_cookie bit
cookie.
If one of those checks fails, the client MUST abort the run. * It verifies that the received nonce matches the nonce sent in
the client_cook message.
5. The client sends a time_request message to the server. The If one of those checks fails, the client MUST abort the run.
client MUST save the included nonce and the transmit_timestamp
(from the time synchronization data) as a correlated pair for
later verification steps.
6. It awaits a reply in the form of a time_response message. Upon Step 5: The client sends a time_request message to the server. The
receipt, it checks: client MUST save the included nonce and the transmit_timestamp
(from the time synchronization data) as a correlated pair for
later verification steps.
* that the transmitted version number matches the one negotiated Step 6: It awaits a reply in the form of a time_response message.
previously, Upon receipt, it checks:
* that the transmitted nonce belongs to a previous time_request * that the transmitted version number matches the one negotiated
message, previously,
* that the transmit_timestamp in that time_request message * that the transmitted nonce belongs to a previous time_request
matches the corresponding time stamp from the synchronization message,
data received in the time_response, and
* that the appended MAC verifies the received synchronization * that the transmit_timestamp in that time_request message
data, version number and nonce. matches the corresponding time stamp from the synchronization
data received in the time_response, and
If at least one of the first three checks fails (i.e. if the * that the appended MAC verifies the received synchronization
version number does not match, if the client has never used the data, version number and nonce.
nonce transmitted in the time_response message, or if it has used
the nonce with initial time synchronization data different from If at least one of the first three checks fails (i.e. if the
that in the response), then the client MUST ignore this version number does not match, if the client has never used the
time_response message. If the MAC is invalid, the client MUST do nonce transmitted in the time_response message, or if it has used
one of the following: abort the run or go back to step 5 (because the nonce with initial time synchronization data different from
the cookie might have changed due to a server seed refresh). If that in the response), then the client MUST ignore this
both checks are successful, the client SHOULD continue time time_response message. If the MAC is invalid, the client MUST do
synchronization by repeating the exchange of time_request and one of the following: abort the run or go back to step 3 (because
time_response messages. the cookie might have changed due to a server seed refresh). If
both checks are successful, the client SHOULD continue time
synchronization by repeating the exchange of time_request and
time_response messages.
The client's behavior in unicast mode is also expressed in Figure 1. The client's behavior in unicast mode is also expressed in Figure 1.
5.1.2. The Client in Broadcast Mode 5.1.2. The Client in Broadcast Mode
To establish a secure broadcast association with a broadcast server, To establish a secure broadcast association with a broadcast server,
the client MUST initially authenticate the broadcast server and the client MUST initially authenticate the broadcast server and
securely synchronize its time with it up to an upper bound for its securely synchronize its time with it up to an upper bound for its
time offset in unicast mode. After that, the client performs the time offset in unicast mode. After that, the client performs the
following steps: following steps:
1. It sends a client_bpar message to the server. It MUST remember NOTE: Steps 1 and 2 MAY be replaced by an alternative security
the transmitted values for the nonce, the version number and the mechanism for the broadcast parameter exchange.
signature algorithm.
2. It waits for a reply in the form of a server_bpar message after Step 1: It sends a client_bpar message to the server. It MUST
which it performs the following checks: remember the transmitted values for the nonce, the version number
and the signature algorithm.
* The message must contain all the necessary information for the Step 2: It waits for a reply in the form of a server_bpar message
TESLA protocol, as specified for a server_bpar message. after which it performs the following checks:
* The message must contain a nonce belonging to a client_bpar * The message must contain all the necessary information for the
message that the client has previously sent. TESLA protocol, as specified for a server_bpar message.
* Verification of the message's signature. * The message must contain a nonce belonging to a client_bpar
message that the client has previously sent.
If any information is missing or if the server's signature cannot * Verification of the message's signature.
be verified, the client MUST abort the broadcast run. If all
checks are successful, the client MUST remember all the broadcast
parameters received for later checks.
3. The client awaits time synchronization data in the form of a If any information is missing or if the server's signature cannot
server_broadcast message. Upon receipt, it performs the be verified, the client MUST abort the broadcast run. If all
following checks: checks are successful, the client MUST remember all the broadcast
parameters received for later checks.
1. Proof that the MAC is based on a key that is not yet Step 3: The client awaits time synchronization data in the form of a
disclosed (packet timeliness). This is achieved via a server_broadcast message. Upon receipt, it performs the following
combination of checks. First, the disclosure schedule is checks:
used, which requires loose time synchronization. If this is
successful, the client obtains a stronger guarantee via a key
check exchange: it sends a client_keycheck message and waits
for the appropriate response. Note that it needs to memorize
the nonce and the time interval number that it sends as a
correlated pair. For more detail on both of the mentioned
timeliness checks, see [I-D.ietf-ntp-network-time-security].
If its timeliness is verified, the packet will be buffered
for later authentication. Otherwise, the client MUST discard
it. Note that the time information included in the packet
will not be used for synchronization until its authenticity
could also be verified.
2. The client checks that it does not already know the disclosed 1. Proof that the MAC is based on a key that is not yet disclosed
key. Otherwise, the client SHOULD discard the packet to (packet timeliness). This is achieved via a combination of
avoid a buffer overrun. If verified, the client ensures that checks. First, the disclosure schedule is used, which
the disclosed key belongs to the one-way key chain by requires loose time synchronization. If this is successful,
applying the one-way function until equality with a previous the client obtains a stronger guarantee via a key check
disclosed key is shown. If it is falsified, the client MUST exchange: it sends a client_keycheck message and waits for the
discard the packet. appropriate response. Note that it needs to memorize the
nonce and the time interval number that it sends as a
correlated pair. For more detail on both of the mentioned
timeliness checks, see [I-D.ietf-ntp-network-time-security].
If its timeliness is verified, the packet will be buffered for
later authentication. Otherwise, the client MUST discard it.
Note that the time information included in the packet will not
be used for synchronization until its authenticity could also
be verified.
3. If the disclosed key is legitimate, then the client verifies 2. The client checks that it does not already know the disclosed
the authenticity of any packet that it has received during key. Otherwise, the client SHOULD discard the packet to avoid
the corresponding time interval. If authenticity of a packet a buffer overrun. If verified, the client ensures that the
is verified it is released from the buffer and the packet's disclosed key belongs to the one-way key chain by applying the
time information can be utilized. If the verification fails, one-way function until equality with a previous disclosed key
then authenticity is no longer given. In this case, the is shown. If it is falsified, the client MUST discard the
client MUST request authentic time from the server by means packet.
of a unicast time request message. Also, the client MUST re-
initialize the broadcast sequence with a "client_bpar"
message if the one-way key chain expires, which it can check
via the disclosure schedule.
See RFC 4082 [RFC4082] for a detailed description of the packet 3. If the disclosed key is legitimate, then the client verifies
verification process. the authenticity of any packet that it has received during the
corresponding time interval. If authenticity of a packet is
verified it is released from the buffer and the packet's time
information can be utilized. If the verification fails, then
authenticity is no longer given. In this case, the client
MUST request authentic time from the server by means of a
unicast time request message. Also, the client MUST re-
initialize the broadcast sequence with a "client_bpar" message
if the one-way key chain expires, which it can check via the
disclosure schedule.
See RFC 4082 [RFC4082] for a detailed description of the packet
verification process.
The client MUST restart the broadcast sequence with a client_bpar The client MUST restart the broadcast sequence with a client_bpar
message ([I-D.ietf-ntp-network-time-security]) if the one-way key message ([I-D.ietf-ntp-network-time-security]) if the one-way key
chain expires. chain expires.
The client's behavior in broadcast mode can also be seen in Figure 2. The client's behavior in broadcast mode can also be seen in Figure 2.
5.2. The Server 5.2. The Server
5.2.1. The Server in Unicast Mode 5.2.1. The Server in Unicast Mode
skipping to change at page 8, line 40 skipping to change at page 9, line 28
To support unicast mode, the server MUST be ready to perform the To support unicast mode, the server MUST be ready to perform the
following actions: following actions:
o Upon receipt of a client_assoc message, the server constructs and o Upon receipt of a client_assoc message, the server constructs and
sends a reply in the form of a server_assoc message as described sends a reply in the form of a server_assoc message as described
in [I-D.ietf-ntp-network-time-security]. in [I-D.ietf-ntp-network-time-security].
o Upon receipt of a client_cook message, the server checks whether o Upon receipt of a client_cook message, the server checks whether
it supports the given cryptographic algorithms. It then it supports the given cryptographic algorithms. It then
calculates the cookie according to the formula given in calculates the cookie according to the formula given in
Section 4.1. With this, it MUST construct a server_cook message [I-D.ietf-ntp-network-time-security]. With this, it MUST
as described in [I-D.ietf-ntp-network-time-security]. construct a server_cook message as described in
[I-D.ietf-ntp-network-time-security].
o Upon receipt of a time_request message, the server re-calculates o Upon receipt of a time_request message, the server re-calculates
the cookie, then computes the necessary time synchronization data the cookie, then computes the necessary time synchronization data
and constructs a time_response message as given in and constructs a time_response message as given in
[I-D.ietf-ntp-network-time-security]. [I-D.ietf-ntp-network-time-security].
The server MUST refresh its server seed periodically (see The server MUST refresh its server seed periodically (see
[I-D.ietf-ntp-network-time-security]). [I-D.ietf-ntp-network-time-security]).
In addition to the server MAY be ready to perform the following
action:
o If an external mechanism for association and key exchange is used
the server has to react accordingly.
5.2.2. The Server in Broadcast Mode 5.2.2. The Server in Broadcast Mode
A broadcast server MUST also support unicast mode in order to provide A broadcast server MUST also support unicast mode in order to provide
the initial time synchronization, which is a precondition for any the initial time synchronization, which is a precondition for any
broadcast association. To support NTS broadcast, the server MUST broadcast association. To support NTS broadcast, the server MUST
additionally be ready to perform the following actions: additionally be ready to perform the following actions:
o Upon receipt of a client_bpar message, the server constructs and o Upon receipt of a client_bpar message, the server constructs and
sends a server_bpar message as described in sends a server_bpar message as described in
[I-D.ietf-ntp-network-time-security]. [I-D.ietf-ntp-network-time-security].
skipping to change at page 9, line 29 skipping to change at page 10, line 22
disclosed it, it constructs and sends the appropriate disclosed it, it constructs and sends the appropriate
server_keycheck message as described in server_keycheck message as described in
[I-D.ietf-ntp-network-time-security]. For more details, see also [I-D.ietf-ntp-network-time-security]. For more details, see also
[I-D.ietf-ntp-network-time-security]. [I-D.ietf-ntp-network-time-security].
o The server follows the TESLA protocol in all other aspects, by o The server follows the TESLA protocol in all other aspects, by
regularly sending server_broad messages as described in regularly sending server_broad messages as described in
[I-D.ietf-ntp-network-time-security], adhering to its own [I-D.ietf-ntp-network-time-security], adhering to its own
disclosure schedule. disclosure schedule.
It is also the server's responsibility to watch for the expiration The server is responsible to watch for the expiration date of the
date of the one-way key chain and generate a new key chain one-way key chain and generate a new key chain accordingly.
accordingly.
In addition to the items above, the server MAY be ready to perform
the following action:
o Upon receipt of external communication for the purpose of
broadcast parameter exchange, the server reacts according to the
way the external communication is specified.
6. Implementation Notes: ASN.1 Structures and Use of the CMS 6. Implementation Notes: ASN.1 Structures and Use of the CMS
This section presents some hints about the structures of the This section presents some hints about the structures of the
communication packets for the different message types when one wishes communication packets for the different message types when one wishes
to implement NTS for NTP. See document to implement NTS for NTP. See document
[I-D.ietf-ntp-cms-for-nts-message] for descriptions of the archetypes [I-D.ietf-ntp-cms-for-nts-message] for descriptions of the archetypes
for CMS structures as well as for the ASN.1 structures that are for CMS structures as well as for the ASN.1 structures that are
referenced here. referenced here.
6.1. Unicast Messages 6.1. Unicast Messages
6.1.1. Association Messages 6.1.1. Association Messages
6.1.1.1. Message Type: "client_assoc" 6.1.1.1. Message Type: "client_assoc"
This message is realized as an NTP packet with an extension field This message is realized as an NTP packet with an extension field
which holds an "NTS-Plain" archetype CMS structure. This structure which holds an "NTS-Plain" archetype structure. This structure
contains in its core an NTS message object of the type consists only of an NTS message object of the type
"ClientAssociationData", which holds all the data necessary for the "ClientAssociationData", which holds all the data necessary for the
NTS security mechanisms. NTS security mechanisms.
6.1.1.2. Message Type: "server_assoc" 6.1.1.2. Message Type: "server_assoc"
Like "client_assoc", this message is realized as an NTP packet with Like "client_assoc", this message is realized as an NTP packet with
an extension field which holds an "NTS-Plain" archetype CMS an extension field which holds an "NTS-Plain" archetype structure,
structure. This structure contains in its core an NTS message object i.e. just an NTS message object of the type "ServerAssociationData".
of the type "ServerAssociationData". The latter holds all the data The latter holds all the data necessary for NTS.
necessary for NTS.
6.1.2. Cookie Messages 6.1.2. Cookie Messages
6.1.2.1. Message Type: "client_cook" 6.1.2.1. Message Type: "client_cook"
This message type is realized as an NTP packet with an extension This message type is realized as an NTP packet with an extension
field which holds a CMS structure of archetype "NTS-Certified", field which holds a CMS structure of archetype "NTS-Certified",
containing in its core an NTS message object of the type containing in its core an NTS message object of the type
"ClientCookieData". The latter holds all the data necessary for the "ClientCookieData". The latter holds all the data necessary for the
NTS security mechanisms. NTS security mechanisms.
6.1.2.2. Message Type: "server_cook" 6.1.2.2. Message Type: "server_cook"
This message type is realized as an NTP packet with an extension This message type is realized as an NTP packet with an extension
field containing a CMS structure of archetype "NTS-Signed-and- field containing a CMS structure of archetype "NTS-Encrypted-and-
Encrypted". The NTS message object in that structure is a Signed". The NTS message object in that structure is a
"ServerCookieData" object, which holds all data required by NTS for "ServerCookieData" object, which holds all data required by NTS for
this message type. this message type.
6.1.3. Time Synchronization Messages 6.1.3. Time Synchronization Messages
6.1.3.1. Message Type: "time_request" 6.1.3.1. Message Type: "time_request"
This message type is realized as an NTP packet which actually This message type is realized as an NTP packet which actually
contains regular NTP time synchronization data, as an unsecured NTP contains regular NTP time synchronization data, as an unsecured NTP
packet from a client to a server would. Furthermore, the packet has packet from a client to a server would. Furthermore, the packet has
an extension field which contains an ASN.1 object of type an extension field which contains an ASN.1 object of type
"TimeRequestSecurityData" (packed in a CMS structure of archetype "TimeRequestSecurityData" (packed in a CMS structure of archetype
"NTS-Plain"), whose structure is as follows: "NTS-Plain").
6.1.3.2. Message Type: "time_response" 6.1.3.2. Message Type: "time_response"
This message is also realized as an NTP packet with regular NTP time This message is also realized as an NTP packet with regular NTP time
synchronization data. The packet also has an extension field which synchronization data. The packet also has an extension field which
contains an ASN.1 object of type "TimeResponseSecurityData". contains an ASN.1 object of type "TimeResponseSecurityData".
Finally, this NTP packet has a MAC field which contains a Message Finally, this NTP packet has a MAC field which contains a Message
Authentication Code generated over the whole packet (including the Authentication Code generated over the whole packet (including the
extension field). extension field).
skipping to change at page 12, line 7 skipping to change at page 13, line 7
This message is also realized as an NTP packet with an extension This message is also realized as an NTP packet with an extension
field, which contains an ASN.1 object of type field, which contains an ASN.1 object of type
"ServerKeyCheckSecurityData" (packed in a CMS structure of archetype "ServerKeyCheckSecurityData" (packed in a CMS structure of archetype
"NTS-Plain"). Additionally, this NTP packet has a MAC field which "NTS-Plain"). Additionally, this NTP packet has a MAC field which
contains a Message Authentication Code generated over the whole contains a Message Authentication Code generated over the whole
packet (including the extension field). packet (including the extension field).
7. Security Considerations 7. Security Considerations
7.1. Usage of NTP Pools 7.1. Employing Alternative Means for Association and Cookie Exchange
If an implementation uses alternative means to perform association
and cookie exchange, it MUST make sure that an adversary cannot abuse
the server to obtain a cookie belonging to a chosen KIV.
7.2. Usage of NTP Pools
The certification-based authentication scheme described in The certification-based authentication scheme described in
[I-D.ietf-ntp-network-time-security] is not applicable to the concept [I-D.ietf-ntp-network-time-security] is not applicable to the concept
of NTP pools. Therefore, NTS is unable to provide secure usage of of NTP pools. Therefore, NTS is unable to provide secure usage of
NTP pools. NTP pools.
7.2. Server Seed Lifetime 7.3. Server Seed Lifetime
tbd tbd
7.3. Supported Hash Algorithms 7.4. Supported Hash Algorithms
The list of the hash algorithms supported by the server has to The list of the hash algorithms supported by the server has to
fulfill the following requirements: fulfill the following requirements:
o it MUST NOT include SHA-1 or weaker algorithms, o it MUST NOT include SHA-1 or weaker algorithms,
o it MUST include SHA-256 or stronger algorithms. o it MUST include SHA-256 or stronger algorithms.
8. Acknowledgements 8. Acknowledgements
skipping to change at page 12, line 46 skipping to change at page 14, line 5
9.1. Normative References 9.1. Normative References
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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, June 2005. Transform Introduction", RFC 4082, June 2005.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
9.2. Informative References 9.2. Informative References
[I-D.ietf-ntp-cms-for-nts-message] [I-D.ietf-ntp-cms-for-nts-message]
Sibold, D., Roettger, S., Teichel, K., 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-01 (work in progress), January 2015. for-nts-message-03 (work in progress), April 2015.
[I-D.ietf-ntp-network-time-security] [I-D.ietf-ntp-network-time-security]
Sibold, D., Roettger, S., and K. Teichel, "Network Time Sibold, D., Roettger, S., and K. Teichel, "Network Time
Security", draft-ietf-ntp-network-time-security-07 (work Security", draft-ietf-ntp-network-time-security-08 (work
in progress), March 2015. in progress), March 2015.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, October 2014. Packet Switched Networks", RFC 7384, October 2014.
Appendix A. Flow Diagrams of Client Behaviour Appendix A. Flow Diagrams of Client Behaviour
+---------------------+ +---------------------+
|Association Messages | |Association Messages |
+----------+----------+ +----------+----------+
| |
skipping to change at page 16, line 5 skipping to change at page 17, line 5
| | | | | | | |
| v v | | v v |
| +-------------+ +-----------------+ | | +-------------+ +-----------------+ |
| |Sync. Process| |Discard Previous | | | |Sync. Process| |Discard Previous | |
| +------+------+ +--------+--------+ | | +------+------+ +--------+--------+ |
| | | | | | | |
+-----------+ +-----------------------------------+ +-----------+ +-----------------------------------+
Figure 2: The client's behaviour in NTS broadcast mode. Figure 2: The client's behaviour in NTS broadcast mode.
Appendix B. Bit Lengths for Employed Primitives
Define the following bit lengths for nonces, cookies and MACs:
B_nonce = 128,
B_cookie = 128, and
B_mac = 128.
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. 62 change blocks. 
188 lines changed or deleted 257 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/