draft-ietf-ntp-using-nts-for-ntp-15.txt   draft-ietf-ntp-using-nts-for-ntp-16.txt 
NTP Working Group D. Franke NTP Working Group D. Franke
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track D. Sibold Intended status: Standards Track D. Sibold
Expires: June 20, 2019 K. Teichel Expires: August 12, 2019 K. Teichel
PTB PTB
M. Dansarie M. Dansarie
R. Sundblad R. Sundblad
Netnod Netnod
December 17, 2018 February 08, 2019
Network Time Security for the Network Time Protocol Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-15 draft-ietf-ntp-using-nts-for-ntp-16
Abstract Abstract
This memo specifies Network Time Security (NTS), a mechanism for This memo specifies Network Time Security (NTS), a mechanism for
using Transport Layer Security (TLS) and Authenticated Encryption using Transport Layer Security (TLS) and Authenticated Encryption
with Associated Data (AEAD) to provide cryptographic security for the with Associated Data (AEAD) to provide cryptographic security for the
client-server mode of the Network Time Protocol (NTP). client-server mode of the Network Time Protocol (NTP).
NTS is structured as a suite of two loosely coupled sub-protocols. NTS is structured as a suite of two loosely coupled sub-protocols.
The first (NTS-KE) handles initial authentication and key The first (NTS-KE) handles initial authentication and key
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 20, 2019. This Internet-Draft will expire on August 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 3, line 33 skipping to change at page 3, line 33
9.1. Sensitivity to DDoS attacks . . . . . . . . . . . . . . . 30 9.1. Sensitivity to DDoS attacks . . . . . . . . . . . . . . . 30
9.2. Avoiding DDoS Amplification . . . . . . . . . . . . . . . 30 9.2. Avoiding DDoS Amplification . . . . . . . . . . . . . . . 30
9.3. Initial Verification of Server Certificates . . . . . . . 31 9.3. Initial Verification of Server Certificates . . . . . . . 31
9.4. Delay Attacks . . . . . . . . . . . . . . . . . . . . . . 32 9.4. Delay Attacks . . . . . . . . . . . . . . . . . . . . . . 32
9.5. Random Number Generation . . . . . . . . . . . . . . . . 33 9.5. Random Number Generation . . . . . . . . . . . . . . . . 33
9.6. NTS Stripping . . . . . . . . . . . . . . . . . . . . . . 33 9.6. NTS Stripping . . . . . . . . . . . . . . . . . . . . . . 33
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33
10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 33 10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 33
10.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 34 10.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 34
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.1. Normative References . . . . . . . . . . . . . . . . . . 34 12.1. Normative References . . . . . . . . . . . . . . . . . . 35
12.2. Informative References . . . . . . . . . . . . . . . . . 36 12.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 37 Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This memo specifies Network Time Security (NTS), a cryptographic This memo specifies Network Time Security (NTS), a cryptographic
security mechanism for network time synchronization. A complete security mechanism for network time synchronization. A complete
specification is provided for application of NTS to the client-server specification is provided for application of NTS to the client-server
mode of the Network Time Protocol (NTP) [RFC5905]. mode of the Network Time Protocol (NTP) [RFC5905].
skipping to change at page 32, line 10 skipping to change at page 32, line 10
*always* be strictly validated. Such a configuration is *always* be strictly validated. Such a configuration is
appropriate on systems which have a battery-backed clock and which appropriate on systems which have a battery-backed clock and which
can reasonably prompt the user to manually set an approximately- can reasonably prompt the user to manually set an approximately-
correct time if it appears to be needed. correct time if it appears to be needed.
Once the clock has been synchronized, periodically write the Once the clock has been synchronized, periodically write the
current system time to persistent storage. Do not accept any current system time to persistent storage. Do not accept any
certificate whose notAfter field is earlier than the last recorded certificate whose notAfter field is earlier than the last recorded
time. time.
Do not process time packets from servers if the time computed from NTP time replies are expected to be consistent with the NTS-KE TLS
them falls outside the validity period of the server's certificate validity period, i.e. time replies received
certificate. However, clients should not perform a new NTS-KE immediately after an NTS-KE handshake are expected to lie within
handshake solely based on the fact that the certificate used by the certificate validity period. Implementations are recommended
the NTS-KE server in a previous handshake has expired, if the to check that this is the case. Performing a new NTS-KE handshake
client has previously received valid NTS protected NTP replies based solely on the fact that the certificate used by the NTS-KE
that lay within the certificate's validity time. server in a previous handshake has expired is normally not
necessary. Clients that still wish to do this must take care not
to cause an inadvertent denial-of-service attack on the NTS-KE
server, for example by picking a random time in the week preceding
certificate expiry to perform the new handshake.
Use multiple time sources. The ability to pass off an expired Use multiple time sources. The ability to pass off an expired
certificate is only useful to an adversary who has compromised the certificate is only useful to an adversary who has compromised the
corresponding private key. If the adversary has compromised only corresponding private key. If the adversary has compromised only
a minority of servers, NTP's selection algorithm (RFC 5905 section a minority of servers, NTP's selection algorithm (RFC 5905 section
11.2.1 [RFC5905]) will protect the client from accepting bad time 11.2.1 [RFC5905]) will protect the client from accepting bad time
from the adversary-controlled servers. from the adversary-controlled servers.
9.4. Delay Attacks 9.4. Delay Attacks
 End of changes. 7 change blocks. 
14 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/