draft-ietf-ntp-using-nts-for-ntp-03.txt   draft-ietf-ntp-using-nts-for-ntp-04.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 29, 2016 Google Inc
K. Teichel K. Teichel
PTB PTB
December 21, 2015 February 26, 2016
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-03 draft-ietf-ntp-using-nts-for-ntp-04
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 41
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 29, 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 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . . . . 5 4.2. Broadcast Mode . . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 5
5.1. The Client . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. The Client . . . . . . . . . . . . . . . . . . . . . . . 5
5.1.1. The Client in Unicast Mode . . . . . . . . . . . . . 5 5.1.1. The Client in Unicast Mode . . . . . . . . . . . . . 5
5.1.2. The Client in Broadcast Mode . . . . . . . . . . . . 7 5.1.2. The Client in Broadcast Mode . . . . . . . . . . . . 8
5.2. The Server . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. The Server . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. The Server in Unicast Mode . . . . . . . . . . . . . 9 5.2.1. The Server in Unicast Mode . . . . . . . . . . . . . 9
5.2.2. The Server in Broadcast Mode . . . . . . . . . . . . 10 5.2.2. The Server in Broadcast Mode . . . . . . . . . . . . 10
6. Implementation Notes: ASN.1 Structures and Use of the CMS . . 10 6. Implementation Notes: ASN.1 Structures and Use of the CMS . . 11
6.1. Unicast Messages . . . . . . . . . . . . . . . . . . . . 11 6.1. Unicast Messages . . . . . . . . . . . . . . . . . . . . 13
6.1.1. Association Messages . . . . . . . . . . . . . . . . 11 6.1.1. Access Messages . . . . . . . . . . . . . . . . . . . 13
6.1.2. Cookie Messages . . . . . . . . . . . . . . . . . . . 11 6.1.2. Association Messages . . . . . . . . . . . . . . . . 13
6.1.3. Time Synchronization Messages . . . . . . . . . . . . 11 6.1.3. Cookie Messages . . . . . . . . . . . . . . . . . . . 14
6.2. Broadcast Messages . . . . . . . . . . . . . . . . . . . 12 6.1.4. Time Synchronization Messages . . . . . . . . . . . . 14
6.2.1. Broadcast Parameter Messages . . . . . . . . . . . . 12 6.2. Broadcast Messages . . . . . . . . . . . . . . . . . . . 15
6.2.2. Broadcast Time Synchronization Message . . . . . . . 12 6.2.1. Broadcast Parameter Messages . . . . . . . . . . . . 15
6.2.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 12 6.2.2. Broadcast Time Synchronization Message . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6.2.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 15
7.1. Field Type Registry . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7.1. Field Type Registry . . . . . . . . . . . . . . . . . . . 16
8.1. Employing Alternative Means for Association and Cookie 7.2. SMI Security for S/MIME CMS Content Type Registry . . . . 16
Exchange . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8.2. Usage of NTP Pools . . . . . . . . . . . . . . . . . . . 13 8.1. Employing Alternative Means for Access, Association and
8.3. Server Seed Lifetime . . . . . . . . . . . . . . . . . . 13 Cookie Exchange . . . . . . . . . . . . . . . . . . . . . 16
8.4. Supported Hash Algorithms . . . . . . . . . . . . . . . . 14 8.2. Usage of NTP Pools . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8.3. Server Seed Lifetime . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.4. Supported Hash Algorithms . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Flow Diagrams of Client Behaviour . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
Appendix B. Bit Lengths for Employed Primitives . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Flow Diagrams of Client Behaviour . . . . . . . . . 18
Appendix B. Bit Lengths for Employed Primitives . . . . . . . . 21
Appendix C. Error Codes . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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.
This document provides detail on how to specifically use those This document provides detail on how to specifically use those
measures to secure time synchronization between NTP clients and measures to secure time synchronization between NTP clients and
servers. servers.
2. Objectives 2. Objectives
The objectives of the NTS specification are as follows: The objectives of the Network Time Security (NTS) specification are
as follows:
o Authenticity: NTS enables an NTP client to authenticate its time o Authenticity: NTS enables an NTP client to authenticate its time
server(s). server(s).
o Integrity: NTS protects the integrity of NTP time synchronization o Integrity: NTS protects the integrity of NTP time synchronization
protocol packets via a message authentication code (MAC). protocol packets via a message authentication code (MAC).
o Confidentiality: NTS does not provide confidentiality protection o Confidentiality: NTS does not provide confidentiality protection
of the time synchronization packets. of the time synchronization packets.
skipping to change at page 4, line 31 skipping to change at page 4, line 33
TESLA Timed Efficient Stream Loss-Tolerant Authentication [RFC4082] TESLA Timed Efficient Stream Loss-Tolerant Authentication [RFC4082]
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 initially The server does not keep a state of the client. NTS initially
verifies the authenticity of the time server and exchanges a verifies the authenticity of the time server and exchanges a
symmetric key, the so-called cookie and a key input value (KIV). The symmetric key, the so-called cookie and a key input value (KIV). The
"association" and "cookie" message exchanges described in "access", "association", and "cookie" message exchanges described in
[I-D.ietf-ntp-network-time-security], Appendix B., can be utilized [I-D.ietf-ntp-network-time-security], Appendix B., can be utilized
for the exchange of the cookie and KIV. An implementation MUST for the exchange of the cookie and KIV. An implementation MUST
support the use of these exchanges. It MAY additionally support the support the use of these exchanges. It MAY additionally support the
use of any alternative secure communication for this purpose, as long use of any alternative secure communication for this purpose, as long
as it fulfills the preconditions given in as it fulfills the preconditions given in
[I-D.ietf-ntp-network-time-security], Section 6.1.1. [I-D.ietf-ntp-network-time-security], Section 6.1.1.
After the cookie and KIV are exchanged, the participants then use After the cookie and KIV are exchanged, the participants then use
them to protect the authenticity and the integrity of subsequent them to protect the authenticity and the integrity of subsequent
unicast-type time synchronization packets. In order to do this, the unicast-type time synchronization packets. In order to do this, the
skipping to change at page 5, line 18 skipping to change at page 5, line 18
synchronization via client-server mode, the necessary broadcast synchronization via client-server mode, the necessary broadcast
parameters are communicated from the server to the client. The parameters are communicated from the server to the client. The
"broadcast parameter" message exchange described in "broadcast parameter" message exchange described in
[I-D.ietf-ntp-network-time-security], Appendix B., can be utilized [I-D.ietf-ntp-network-time-security], Appendix B., can be utilized
for this communication. An implementation MUST support the use of for this communication. An implementation MUST support the use of
this exchange. It MAY additionally support the use of any this exchange. It MAY additionally support the use of any
alternative secure communication for this purpose, as long as it alternative secure communication for this purpose, as long as it
fulfills the necessary security goals (given in fulfills the necessary security goals (given in
[I-D.ietf-ntp-network-time-security], Section 6.2.1.). [I-D.ietf-ntp-network-time-security], Section 6.2.1.).
After the client has received the necessry broadcast parameters, After the client has received the necessary broadcast parameters,
"broadcast time synchronization" message exchanges are utilized in "broadcast time synchronization" message exchanges are utilized in
combination with optional "broadcast keycheck" exchanges to protect combination with optional "broadcast keycheck" exchanges to protect
authenticity and integrity of NTP broadcast time synchronization authenticity and integrity of NTP broadcast time synchronization
packets. As in the case of unicast time synchronization messages, packets. As in the case of unicast time synchronization messages,
this is also achieved by MACs. this is also achieved by MACs.
5. Protocol Sequence 5. Protocol Sequence
Throughout this section, the server seed, the nonces, cookies and Throughout this section, the access key, server seed, the nonces,
MACs mentioned have bit lengths of B_seed, B_nonce, B_cookie and cookies and MACs mentioned have bit lengths of B_accesskey, B_seed,
B_mac, respectively. These bit lengths are defined in Appendix B B_nonce, B_cookie and B_mac, respectively. These bit lengths are
(Appendix B). defined in Appendix B (Appendix B). If a message requires a MAC to
cover its contents, this MAC MUST be calculated according to:
mac = MSB_<B_mac> (HMAC(key, content)),
where the application of the function MSB_<B_mac> returns only the
B_mac most significant bits, where content is composed of the NTP
header and all extension fields prior to the MAC-carrying extension
field (see Section 6), and where key is the cookie for the given
association.
Note for clarification that different message exchanges use different Note for clarification that different message exchanges use different
nonces. A nonce is always generated by the client for a request nonces. A nonce is always generated by the client for a request
message, and then used by the server in its response. After this, it message, and then used by the server in its response. After this, it
is not to be used again. is not to be used again.
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:
NOTE: Steps 1 through 4 MAY alternatively be replaced an alternative NOTE: Steps 1 through 6 MAY alternatively be replaced by an
secure mechanism for association and cookie exchange. An alternative secure mechanism for access, association and cookie
implementation MAY choose to replace either steps 1 and 2 or all exchange.
of the steps 1 through 4 by alternative secure communication.
Step 1: It sends a client_assoc message to the server. It MUST keep Step 1: It sends a client_access message to the server.
the transmitted nonce as well as the values for the version number
and algorithms available for later checks.
Step 2: It waits for a reply in the form of a server_assoc message. Step 2: It waits for a reply in the form of a server_access message.
Step 3: It sends a client_assoc message to the server. It MUST
include the access key from the previously received server_access
message. It MUST keep the transmitted nonce as well as the values
for the version number and algorithms available for later checks.
Step 4: It waits for a reply in the form of a server_assoc message.
After receipt of the message it performs the following checks: After receipt of the message it performs the following 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 * It checks that the nonce sent back by the server matches the
one transmitted in client_assoc, 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
skipping to change at page 6, line 31 skipping to change at page 6, line 44
If one of the checks fails, the client MUST abort the run. If one of the checks fails, the client MUST abort the run.
Discussion: Note that by performing the above message exchange Discussion: Note that by performing the above message exchange
and checks, the client validates the authenticity of its and checks, the client validates the authenticity of its
immediate NTP server only. It does not recursively validate immediate NTP server only. It does not recursively validate
the authenticity of each NTP server on the time synchronization the authenticity of each NTP server on the time synchronization
chain. Recursive authentication (and authorization) as chain. Recursive authentication (and authorization) as
formulated in RFC 7384 [RFC7384] depends on the chosen trust formulated in RFC 7384 [RFC7384] depends on the chosen trust
anchor. anchor.
Step 3: Next it sends a client_cook message to the server. The Step 5: Next it sends a client_cook message to the server. The
client MUST save the included nonce until the reply has been client MUST save the included nonce until the reply has been
processed. processed.
Step 4: It awaits a reply in the form of a server_cook message; upon Step 6: It awaits a reply in the form of a server_cook message; upon
receipt it executes the following actions: receipt it executes the following actions:
* It verifies that the received version number matches the one * It verifies that the received version number matches the one
negotiated beforehand. negotiated beforehand.
* It verifies the signature using the server's public key. The * It verifies the signature using the server's public key. The
signature has to authenticate the encrypted data. signature has to authenticate the encrypted data.
* It decrypts the encrypted data with its own private key. * It decrypts the encrypted data with its own private key.
* It checks that the decrypted message is of the expected format: * It checks that the decrypted message is of the expected format:
the concatenation of a B_nonce bit nonce and a B_cookie bit the concatenation of a B_nonce bit nonce and a B_cookie bit
cookie. cookie.
* It verifies that the received nonce matches the nonce sent in * It verifies that the received nonce matches the nonce sent in
the client_cook message. the client_cook message.
If one of those checks fails, the client MUST abort the run. If one of those checks fails, the client MUST abort the run.
Step 5: The client sends a time_request message to the server. The Step 7: The client sends a time_request message to the server. The
client MUST append a MAC to the time_request message. The client client MUST append a MAC to the time_request message. The client
MUST save the included nonce and the transmit_timestamp (from the MUST save the included nonce and the transmit_timestamp (from the
time synchronization data) as a correlated pair for later time synchronization data) as a correlated pair for later
verification steps. verification steps.
Step 6: It awaits a reply in the form of a time_response message. Step 8: It 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,
* that the transmitted nonce belongs to a previous time_request * that the transmitted nonce belongs to a previous time_request
message, message,
* that the transmit_timestamp in that time_request message * that the transmit_timestamp in that time_request message
matches the corresponding time stamp from the synchronization matches the corresponding time stamp from the synchronization
skipping to change at page 7, line 35 skipping to change at page 7, line 47
* that the appended MAC verifies the received synchronization * that the appended MAC verifies the received synchronization
data, version number and nonce. data, version number and nonce.
If at least one of the first three checks fails (i.e. if the If at least one of the first three checks fails (i.e. if the
version number does not match, if the client has never used the version number does not match, if the client has never used the
nonce transmitted in the time_response message, or if it has used nonce transmitted in the time_response message, or if it has used
the nonce with initial time synchronization data different from the nonce with initial time synchronization data different from
that in the response), then the client MUST ignore this that in the response), then the client MUST ignore this
time_response message. If the MAC is invalid, the client MUST do time_response message. If the MAC is invalid, the client MUST do
one of the following: abort the run or go back to step 3 (because one of the following: abort the run or go back to step 5 (because
the cookie might have changed due to a server seed refresh). If the cookie might have changed due to a server seed refresh). If
both checks are successful, the client SHOULD continue time both checks are successful, the client SHOULD continue time
synchronization by repeating the exchange of time_request and synchronization by repeating the exchange of time_request and
time_response messages. 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,
skipping to change at page 9, line 33 skipping to change at page 9, line 45
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
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_access 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_access message as described
in [I-D.ietf-ntp-network-time-security]. in Appendix B of[I-D.ietf-ntp-network-time-security]. The server
MUST construct the access key according to:
access_key = MSB _<B_accesskey> (HMAC(server seed; Client's IP
address)).
o Upon receipt of a client_assoc message, the server checks the
included access key. To this end it reconstructs the access key
and compares it against the received one. If they match, the
server constructs and sends a reply in the form of a server_assoc
message as described in [I-D.ietf-ntp-network-time-security]. In
the case where the validity of the included access key can not be
verified, the server MUST NOT reply to the received request.
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
[I-D.ietf-ntp-network-time-security]. With this, it MUST [I-D.ietf-ntp-network-time-security]. With this, it MUST
construct a server_cook message as described in construct a server_cook message as described in
[I-D.ietf-ntp-network-time-security]. [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, verifies integrity of the message, then computes the the cookie and the MAC for that time_request packet and compares
necessary time synchronization data and constructs a time_response this value with the MAC in the received data.
message as given in [I-D.ietf-ntp-network-time-security].
The server MUST refresh its server seed periodically (see * If the re-calculated MAC does not match the MAC in the received
[I-D.ietf-ntp-network-time-security]). data the server MUST stop the processing of the request.
In addition to the server MAY be ready to perform the following * If the re-calculated MAC matches the MAC in the received data
action: the server computes the necessary time synchronization data and
constructs a time_response message as given in
[I-D.ietf-ntp-network-time-security].
In addition to items above, the server MAY be ready to perform the
following action:
o If an external mechanism for association and key exchange is used, o If an external mechanism for association and key exchange is used,
the server has to react accordingly. 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].
o Upon receipt of a client_keycheck message, the server looks up o Upon receipt of a client_keycheck message, the server re-
whether it has already disclosed the key associated with the calculates the cookie and the MAC for that client_keycheck packet
interval number transmitted in that message. If it has not and compares this value with the MAC in the received data.
disclosed it, it constructs and sends the appropriate
server_keycheck message as described in * If the re-calculated MAC does not match the MAC in the received
[I-D.ietf-ntp-network-time-security]. For more details, see also data the server MUST stop the processing of the request.
[I-D.ietf-ntp-network-time-security].
* If the re-calculated MAC matches the MAC in the received data
the server 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
[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.
The server is responsible to watch for the expiration date of the The server is responsible to watch for the expiration date of the
one-way key chain and generate a new key chain accordingly. one-way key chain and generate a new key chain accordingly.
In addition to the items above, the server MAY be ready to perform In addition to the items above, the server MAY be ready to perform
skipping to change at page 11, line 5 skipping to change at page 11, line 39
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.
All extension fields mentioned in the following list are notified by The NTP extension field structure is defined in RFC 5905 [RFC5905]
a field type value signalling content related to NTS version 1.0. and clarified in [I-D.ietf-ntp-extension-field]. It looks as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Value .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (as needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All extension fields mentioned in the rest of this section do not
require an NTP MAC field. If nothing else is explicitly stated, all
of those extension fields MUST have a length of at least 28 octets.
Furthermore, all extension fields mentioned in the rest of this
section are notified by a Field Type identifier signaling content
related to NTS (see IANA considerations (Section 7)).
The outermost structure of the extension field's Value field MUST be
an ASN.1 object that is structured as follows:
NTSExtensionFieldContent := SEQUENCE {
oid OBJECT IDENTIFIER,
errnum OCTET STRING (SIZE(2)),
content ANY DEFINED BY oid
}
The field errnum represents the error code of any message. The
client and server MAY ignore this field in any incoming message. The
server MUST set this to zero if the response to the request was
generated successfully. If it could not successfully generate a
response, the field errnum MUST be set to a non-zero value. The
different values of this field is defined in the Appendix C.
Whenever NTS requires a MAC for protection of a message, this MAC
MUST be included in an additional extension field. This MAC-carrying
extension field MUST be placed after the other NTS-related extension
field, and it SHOULD be the last extension field of the message. Any
MAC supplied by NTS in a MAC-carrying extension field MUST be
generated over the NTP header and all extension fields prior to the
MAC-carrying extension field.
Content MAY be added to an NTS-protected NTP message after the MAC
provided by NTS. However, it is RECOMMENDED to not make use of this
option and to apply the MAC protection of NTS to the whole of an NTP
message.
The MAC-carrying extension field contains an NTSExtensionFieldContent
object, whose content field is structured according to NTS-Plain.
The included NTS message object is as follows:
NTSMessageAuthenticationCode := SEQUENCE {
mac OCTET STRING (SIZE(16))
}
It is identified by the following object identifier:
id-ct-nts-ntsForNtpMessageAuthenticationCode OBJECT IDENTIFIER
::= TBD2
Note: In the following sections the word MAC is always used as
described above. In particular it is not to be confused with
NTP's MAC field.
6.1. Unicast Messages 6.1. Unicast Messages
6.1.1. Association Messages 6.1.1. Access Messages
6.1.1.1. Message Type: "client_assoc" 6.1.1.1. Message Type: "client_access"
This message is realized as an NTP packet with an extension field
which holds an "NTS-Plain" archetype structure. This structure
consists only of an NTS message object of the type
"ClientAccessData".
6.1.1.2. Message Type: "server_access"
Like "client_access", this message is realized as an NTP packet with
an extension field which holds an "NTS-Plain" archetype structure,
i.e. just an NTS message object of the type "ServerAccessData". The
latter holds all the data necessary for NTS.
6.1.2. Association Messages
6.1.2.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 structure. This structure which holds an "NTS-Plain" archetype structure. This structure
consists only of an NTS message object of the type "ClientAssocData", consists only of an NTS message object of the type "ClientAssocData",
which holds all the data necessary for the NTS security mechanisms. which holds all the data necessary for the NTS security mechanisms.
6.1.1.2. Message Type: "server_assoc" 6.1.2.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 structure, an extension field which holds an "NTS-Plain" archetype structure,
i.e. just an NTS message object of the type "ServerAssocData". The i.e. just an NTS message object of the type "ServerAssocData". The
latter holds all the data necessary for NTS. latter holds all the data necessary for NTS.
6.1.2. Cookie Messages 6.1.3. Cookie Messages
6.1.2.1. Message Type: "client_cook" 6.1.3.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-Plain", field which holds a CMS structure of archetype "NTS-Plain",
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.3.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-Encrypted-and- field containing a CMS structure of archetype "NTS-Encrypted-and-
Signed". 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.4. Time Synchronization Messages
6.1.3.1. Message Type: "time_request" 6.1.4.1. Message Type: "time_request"
This message type is realized as an NTP packet with regular NTP time This message type is realized as an NTP packet with regular NTP time
synchronization data. Furthermore, the packet has an extension field synchronization data. Furthermore, the packet has an extension field
which contains an ASN.1 object of type "TimeRequestSecurityData" which contains an ASN.1 object of type "TimeRequestSecurityData"
(packed in a CMS structure of archetype "NTS-Plain"). Finally, this (packed in a CMS structure of archetype "NTS-Plain"). Finally, this
NTP packet has another extension field which contains a Message message MUST be protected by a MAC.
Authentication Code generated over the whole packet (including the
extension field).
6.1.3.2. Message Type: "time_response" 6.1.4.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 another extension field which contains a Finally, this message MUST be protected by a MAC.
Message Authentication Code generated over the whole packet
(including the extension field). Note: In these two messages, where two extension fields are present,
the respective first extension field (the one not containing the
MAC) only needs to have a length of at least 16 octets. The
extension fields holding the MACs need to have the usual length of
at least 28 octets.
6.2. Broadcast Messages 6.2. Broadcast Messages
6.2.1. Broadcast Parameter Messages 6.2.1. Broadcast Parameter Messages
6.2.1.1. Message Type: "client_bpar" 6.2.1.1. Message Type: "client_bpar"
This first broadcast message is realized as an NTP packet which is This first broadcast message is realized as an NTP packet which is
empty except for an extension field which contains an ASN.1 object of empty except for an extension field which contains an ASN.1 object of
type "BroadcastParameterRequest" (packed in a CMS structure of type "BroadcastParameterRequest" (packed in a CMS structure of
skipping to change at page 12, line 42 skipping to change at page 15, line 31
NTS message object in this case is an ASN.1 object of type NTS message object in this case is an ASN.1 object of type
"BroadcastParameterResponse". "BroadcastParameterResponse".
6.2.2. Broadcast Time Synchronization Message 6.2.2. Broadcast Time Synchronization Message
6.2.2.1. Message Type: "server_broad" 6.2.2.1. Message Type: "server_broad"
This message's realization works via an NTP packet which carries This message's realization works via an NTP packet which carries
regular NTP broadcast time data as well as an extension field, which regular NTP broadcast time data as well as an extension field, which
contains an ASN.1 object of type "BroadcastTime" (packed in a CMS contains an ASN.1 object of type "BroadcastTime" (packed in a CMS
structure with archetype "NTS-Plain"). In addition to all this, this structure with archetype "NTS-Plain"). Finally, this message MUST be
packet has another extension field which contains a Message protected by a MAC.
Authentication Code generated over the whole packet (including the
extension field). Note: In this message, the first extension field (the one not
containing the MAC) only needs to have a length of at least 16
octets. The extension field holding the MACs needs to have the
usual length of at least 28 octets.
6.2.3. Broadcast Keycheck 6.2.3. Broadcast Keycheck
6.2.3.1. Message Type: "client_keycheck" 6.2.3.1. Message Type: "client_keycheck"
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 transports a CMS structure of archetype "NTS-Plain", containing which transports a CMS structure of archetype "NTS-Plain", containing
an ASN.1 object of type "ClientKeyCheckSecurityData". an ASN.1 object of type "ClientKeyCheckSecurityData". Finally, this
message MUST be protected by a MAC.
6.2.3.2. Message Type: "server_keycheck" 6.2.3.2. Message Type: "server_keycheck"
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 another extension "NTS-Plain"). Finally, this message MUST be protected by a MAC.
field which contains a Message Authentication Code generated over the
whole packet (including the extension field). Note: In this message, the first extension field (the one not
containing the MAC) only needs to have a length of at least 16
octets. The extension field holding the MACs needs to have the
usual length of at least 28 octets.
7. IANA Considerations 7. IANA Considerations
7.1. Field Type Registry 7.1. Field Type Registry
Within the "NTP Extensions Field Types" registry table, add one field Within the "NTP Extensions Field Types" registry table, add one field
type: type:
Field Type Meaning References Field Type Meaning References
---------- ------------------------------------ ---------- ---------- ------------------------------------ ----------
TBD1 NTS-Related Content [this doc] TBD1 NTS-Related Content [this doc]
7.2. SMI Security for S/MIME CMS Content Type Registry
Within the "SMI Security for S/MIME CMS Content Type
(1.2.840.113549.1.9.16.1)" table, add one content type identifier:
Decimal Description References
------- -------------------------------------------- ----------
TBD2 id-ct-nts-ntsForNtpMessageAuthenticationCode [this doc]
8. Security Considerations 8. Security Considerations
8.1. Employing Alternative Means for Association and Cookie Exchange All security considerations described in
[I-D.ietf-ntp-network-time-security] have to be taken into account.
The application of NTS to NTP requires the following additional
considerations.
If an implementation uses alternative means to perform association 8.1. Employing Alternative Means for Access, Association and Cookie
and cookie exchange, it MUST make sure that an adversary cannot abuse Exchange
the server to obtain a cookie belonging to a chosen KIV.
If an implementation uses alternative means to perform access,
association and cookie exchange, it MUST make sure that an adversary
cannot abuse the server to obtain a cookie belonging to a chosen KIV.
8.2. Usage of NTP Pools 8.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.
8.3. Server Seed Lifetime 8.3. Server Seed Lifetime
tbd According to Clause 5.6.1 in RFC 7384 [RFC7384] the server MUST
provide a means to refresh the value of its server seed from time to
time. A generally valid value for the server seed lifetime cannot be
given. The value depends on the required security level, the current
threat situation, and the chosen hash mechanisms.
As guidance, a value for the lifetime can be determined by
stipulating a maximum number of time requests for which the exchanged
cookie remains unchanged. For example, if this value is 1000 and the
client sends a time request every 64 seconds, the server seed
lifetime should be no longer than 64000 seconds. Corresponding
considerations can be made for a minimum number of requests.
8.4. Supported Hash Algorithms 8.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.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Russ Housley, Steven Bellovin, David The authors would like to thank Russ Housley, Steven Bellovin, David
Mills and Kurt Roeckx for discussions and comments on the design of Mills and Kurt Roeckx for discussions and comments on the design of
NTS. Also, thanks to Harlan Stenn for his technical review and NTS. Also, thanks to Harlan Stenn, Danny Mayer, Richard Welty and
specific text contributions to this document. Martin Langer for their technical review and specific text
contributions to this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ntp-cms-for-nts-message]
Sibold, D., Teichel, K., Roettger, S., and R. Housley,
"Protecting Network Time Security Messages with the
Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms-
for-nts-message-06 (work in progress), February 2016.
[I-D.ietf-ntp-extension-field]
Mizrahi, T. and D. Mayer, "The Network Time Protocol
Version 4 (NTPv4) Extension Fields", draft-ietf-ntp-
extension-field-07 (work in progress), February 2016.
[I-D.ietf-ntp-network-time-security]
Sibold, D., Roettger, S., and K. Teichel, "Network Time
Security", draft-ietf-ntp-network-time-security-13 (work
in progress), February 2016.
[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,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>. <http://www.rfc-editor.org/info/rfc5652>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>. <http://www.rfc-editor.org/info/rfc5905>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-ntp-cms-for-nts-message]
Sibold, D., Teichel, K., Roettger, S., and R. Housley,
"Protecting Network Time Security Messages with the
Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms-
for-nts-message-04 (work in progress), July 2015.
[I-D.ietf-ntp-network-time-security]
Sibold, D., Roettger, S., and K. Teichel, "Network Time
Security", draft-ietf-ntp-network-time-security-11 (work
in progress), October 2015.
[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>.
Appendix A. Flow Diagrams of Client Behaviour Appendix A. Flow Diagrams of Client Behaviour
+---------------+
|Access Messages|
+-------+-------+
|
v
+---------------------+ +---------------------+
|Association Messages | |Association Messages |
+----------+----------+ +----------+----------+
| |
+------------------------------>o +------------------------------>o
| | | |
| v | v
| +---------------+ | +---------------+
| |Cookie Messages| | |Cookie Messages|
| +-------+-------+ | +-------+-------+
skipping to change at page 18, line 10 skipping to change at page 21, line 10
| | | | | | | |
+-----------+ +-----------------------------------+ +-----------+ +-----------------------------------+
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 Appendix B. Bit Lengths for Employed Primitives
Define the following bit lengths for server seed, nonces, cookies and Define the following bit lengths for server seed, nonces, cookies and
MACs: MACs:
B_accesskey = 128,
B_seed = 128, B_seed = 128,
B_nonce = 128, B_nonce = 128,
B_cookie = 128, and B_cookie = 128, and
B_mac = 128. B_mac = 128.
Appendix C. Error Codes
+-----+---------+
| Bit | Meaning |
+-----+---------+
| 1 | D2 |
+-----+---------+
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. 52 change blocks. 
116 lines changed or deleted 295 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/