draft-ietf-ntp-using-nts-for-ntp-25.txt   draft-ietf-ntp-using-nts-for-ntp-26.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: September 20, 2020 K. Teichel Expires: September 23, 2020 K. Teichel
PTB PTB
M. Dansarie M. Dansarie
R. Sundblad R. Sundblad
Netnod Netnod
March 19, 2020 March 22, 2020
Network Time Security for the Network Time Protocol Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-25 draft-ietf-ntp-using-nts-for-ntp-26
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 September 20, 2020. This Internet-Draft will expire on September 23, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 3, line 44 skipping to change at page 3, line 44
8.5.3. Contact Information . . . . . . . . . . . . . . . . . 33 8.5.3. Contact Information . . . . . . . . . . . . . . . . . 33
8.5.4. Last Update . . . . . . . . . . . . . . . . . . . . . 33 8.5.4. Last Update . . . . . . . . . . . . . . . . . . . . . 33
8.6. Implementation 6 . . . . . . . . . . . . . . . . . . . . 33 8.6. Implementation 6 . . . . . . . . . . . . . . . . . . . . 33
8.6.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 34 8.6.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 34
8.6.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 34 8.6.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 34
8.6.3. Contact Information . . . . . . . . . . . . . . . . . 34 8.6.3. Contact Information . . . . . . . . . . . . . . . . . 34
8.6.4. Last Update . . . . . . . . . . . . . . . . . . . . . 34 8.6.4. Last Update . . . . . . . . . . . . . . . . . . . . . 34
8.7. Interoperability . . . . . . . . . . . . . . . . . . . . 34 8.7. Interoperability . . . . . . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9.1. Protected Modes . . . . . . . . . . . . . . . . . . . . . 34 9.1. Protected Modes . . . . . . . . . . . . . . . . . . . . . 34
9.2. Sensitivity to DDoS Attacks . . . . . . . . . . . . . . . 35 9.2. Key Compromise . . . . . . . . . . . . . . . . . . . . . 35
9.3. Avoiding DDoS Amplification . . . . . . . . . . . . . . . 35 9.3. Sensitivity to DDoS Attacks . . . . . . . . . . . . . . . 35
9.4. Initial Verification of Server Certificates . . . . . . . 36 9.4. Avoiding DDoS Amplification . . . . . . . . . . . . . . . 35
9.5. Delay Attacks . . . . . . . . . . . . . . . . . . . . . . 37 9.5. Initial Verification of Server Certificates . . . . . . . 36
9.6. NTS Stripping . . . . . . . . . . . . . . . . . . . . . . 37 9.6. Delay Attacks . . . . . . . . . . . . . . . . . . . . . . 37
9.7. NTS Stripping . . . . . . . . . . . . . . . . . . . . . . 38
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38
10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 38 10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 38
10.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 39 10.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 39
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
12.1. Normative References . . . . . . . . . . . . . . . . . . 39 12.1. Normative References . . . . . . . . . . . . . . . . . . 39
12.2. Informative References . . . . . . . . . . . . . . . . . 41 12.2. Informative References . . . . . . . . . . . . . . . . . 41
Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 42 Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
This memo specifies Network Time Security (NTS), a cryptographic This memo specifies Network Time Security (NTS), a cryptographic
skipping to change at page 4, line 24 skipping to change at page 4, line 24
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].
1.1. Objectives 1.1. Objectives
The objectives of NTS are as follows: The objectives of NTS are as follows:
o Identity: Through the use of a X.509 public key infrastructure, o Identity: Through the use of a X.509 public key infrastructure,
implementations may cryptographically establish the identity of implementations can cryptographically establish the identity of
the parties they are communicating with. the parties they are communicating with.
o Authentication: Implementations may cryptographically verify that o Authentication: Implementations can cryptographically verify that
any time synchronization packets are authentic, i.e., that they any time synchronization packets are authentic, i.e., that they
were produced by an identified party and have not been modified in were produced by an identified party and have not been modified in
transit. transit.
o Confidentiality: Although basic time synchronization data is o Confidentiality: Although basic time synchronization data is
considered non-confidential and sent in the clear, NTS includes considered non-confidential and sent in the clear, NTS includes
support for encrypting NTP extension fields. support for encrypting NTP extension fields.
o Replay prevention: Client implementations may detect when a o Replay prevention: Client implementations can detect when a
received time synchronization packet is a replay of a previous received time synchronization packet is a replay of a previous
packet. packet.
o Request-response consistency: Client implementations may verify o Request-response consistency: Client implementations can verify
that a time synchronization packet received from a server was sent that a time synchronization packet received from a server was sent
in response to a particular request from the client. in response to a particular request from the client.
o Unlinkability: For mobile clients, NTS will not leak any o Unlinkability: For mobile clients, NTS will not leak any
information additional to NTP which would permit a passive information additional to NTP which would permit a passive
adversary to determine that two packets sent over different adversary to determine that two packets sent over different
networks came from the same client. networks came from the same client.
o Non-amplification: Implementations (especially server o Non-amplification: Implementations (especially server
implementations) may avoid acting as distributed denial-of-service implementations) can avoid acting as distributed denial-of-service
(DDoS) amplifiers by never responding to a request with a packet (DDoS) amplifiers by never responding to a request with a packet
larger than the request packet. larger than the request packet.
o Scalability: Server implementations may serve large numbers of o Scalability: Server implementations can serve large numbers of
clients without having to retain any client-specific state. clients without having to retain any client-specific state.
o Performance: NTS must not significantly degrade the quality of the o Performance: NTS must not significantly degrade the quality of the
time transfer. The encryption and authentication used when time transfer. The encryption and authentication used when
actually transferring time should be lightweight (see RFC 7384, actually transferring time should be lightweight (see RFC 7384,
Section 5.7 [RFC7384]). Section 5.7 [RFC7384]).
1.2. Protocol Overview 1.2. Protocol Overview
The Network Time Protocol includes many different operating modes to The Network Time Protocol includes many different operating modes to
skipping to change at page 7, line 52 skipping to change at page 7, line 52
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. TLS profile for Network Time Security 3. TLS profile for Network Time Security
Network Time Security makes use of TLS for NTS key establishment. Network Time Security makes use of TLS for NTS key establishment.
Since the NTS protocol is new as of this publication, no backward- Since the NTS protocol is new as of this publication, no backward-
compatibility concerns exist to justify using obsolete, insecure, or compatibility concerns exist to justify using obsolete, insecure, or
otherwise broken TLS features or versions. Implementations MUST otherwise broken TLS features or versions. Implementations MUST
conform with [RFC7525] or with a later revision of BCP 195. In conform with RFC 7525 [RFC7525] or with a later revision of BCP 195.
particular, failure to use cipher suites that provide forward secrecy
will make all negotiated NTS keys recoverable by anyone that gains
access to the NTS-KE server's private key. Furthermore:
Implementations MUST NOT negotiate TLS versions earlier than 1.2, Implementations MUST NOT negotiate TLS versions earlier than 1.3
SHOULD negotiate TLS 1.3 [RFC8446] or later when possible, and MAY [RFC8446] and MAY refuse to negotiate any TLS version which has been
refuse to negotiate any TLS version which has been superseded by a superseded by a later supported version.
later supported version.
Use of the Application-Layer Protocol Negotiation Extension [RFC7301] Use of the Application-Layer Protocol Negotiation Extension [RFC7301]
is integral to NTS and support for it is REQUIRED for is integral to NTS and support for it is REQUIRED for
interoperability. interoperability.
Implementations MUST follow the rules in RFC 5280 [RFC5280] and RFC
6125 [RFC6125] for the representation and verification of application
service identity. Use of the DNS-ID identifier type [RFC6125] is
RECOMMENDED. Section 9.5 of this memo discusses particular
considerations for certificate verification in the context of NTS.
4. The NTS Key Establishment Protocol 4. The NTS Key Establishment Protocol
The NTS key establishment protocol is conducted via TCP port The NTS key establishment protocol is conducted via TCP port
[[TBD1]]. The two endpoints carry out a TLS handshake in conformance [[TBD1]]. The two endpoints carry out a TLS handshake in conformance
with Section 3, with the client offering (via an ALPN [RFC7301] with Section 3, with the client offering (via an ALPN [RFC7301]
extension), and the server accepting, an application-layer protocol extension), and the server accepting, an application-layer protocol
of "ntske/1". Immediately following a successful handshake, the of "ntske/1". Immediately following a successful handshake, the
client SHALL send a single request as Application Data encapsulated client SHALL send a single request as Application Data encapsulated
in the TLS-protected channel. Then, the server SHALL send a single in the TLS-protected channel. Then, the server SHALL send a single
response. After sending their respective request and response, the response. After sending their respective request and response, the
client and server SHALL send TLS "close_notify" alerts in accordance client and server SHALL send TLS "close_notify" alerts in accordance
with the TLS version in use, see RFC 8446 Section 6.1 [RFC8446]. with RFC 8446, Section 6.1 [RFC8446].
The client's request and the server's response each SHALL consist of The client's request and the server's response each SHALL consist of
a sequence of records formatted according to Figure 2. The request a sequence of records formatted according to Figure 2. The request
and a non-error response each SHALL include exactly one NTS Next and a non-error response each SHALL include exactly one NTS Next
Protocol Negotiation record. The sequence SHALL be terminated by a Protocol Negotiation record. The sequence SHALL be terminated by a
"End of Message" record. The requirement that all NTS-KE messages be "End of Message" record. The requirement that all NTS-KE messages be
terminated by an End of Message record makes them self-delimiting. terminated by an End of Message record makes them self-delimiting.
Clients and servers MAY enforce length limits on requests and Clients and servers MAY enforce length limits on requests and
responses, however, servers MUST accept requests of at least 1024 responses, however, servers MUST accept requests of at least 1024
skipping to change at page 14, line 35 skipping to change at page 14, line 35
server MAY incorporate this request when deciding what NTPv4 Server server MAY incorporate this request when deciding what NTPv4 Server
Negotiation and NTPv4 Port Negotiation records to respond with, but Negotiation and NTPv4 Port Negotiation records to respond with, but
honoring the client's preference is OPTIONAL. honoring the client's preference is OPTIONAL.
Servers MAY set the Critical Bit on records of this type; clients Servers MAY set the Critical Bit on records of this type; clients
SHOULD NOT. SHOULD NOT.
4.2. Key Extraction (generally) 4.2. Key Extraction (generally)
Following a successful run of the NTS-KE protocol, key material SHALL Following a successful run of the NTS-KE protocol, key material SHALL
be extracted using the TLS pseudorandom function (PRF) [RFC5705] for be extracted using the HMAC-based Extract-and-Expand Key Derivation
TLS version 1.2, or the HMAC-based Extract-and-Expand Key Derivation
Function (HKDF) [RFC5869] in accordance with RFC 8446, Section 7.5 Function (HKDF) [RFC5869] in accordance with RFC 8446, Section 7.5
[RFC8446] for TLS version 1.3. Inputs to the exporter function are [RFC8446]. Inputs to the exporter function are to be constructed in
to be constructed in a manner specific to the negotiated Next a manner specific to the negotiated Next Protocol. However, all
Protocol. However, all protocols which utilize NTS-KE MUST conform protocols which utilize NTS-KE MUST conform to the following two
to the following two rules: rules:
The disambiguating label string MUST be "EXPORTER-network-time- The disambiguating label string [RFC5705] MUST be "EXPORTER-
security/1". network-time-security".
The per-association context value MUST be provided and MUST begin The per-association context value MUST be provided and MUST begin
with the two-octet Protocol ID which was negotiated as a Next with the two-octet Protocol ID which was negotiated as a Next
Protocol. Protocol.
5. NTS Extension Fields for NTPv4 5. NTS Extension Fields for NTPv4
5.1. Key Extraction (for NTPv4) 5.1. Key Extraction (for NTPv4)
Following a successful run of the NTS-KE protocol wherein Protocol ID Following a successful run of the NTS-KE protocol wherein Protocol ID
0 (NTPv4) is selected as a Next Protocol, two AEAD keys SHALL be 0 (NTPv4) is selected as a Next Protocol, two AEAD keys SHALL be
extracted: a client-to-server (C2S) key and a server-to-client (S2C) extracted: a client-to-server (C2S) key and a server-to-client (S2C)
key. These keys SHALL be computed with the PRF defined in RFC 5705 key. These keys SHALL be computed with the HKDF defined in RFC 8446,
[RFC5705] for TLS version 1.2, or the HKDF defined in RFC 8446, Section 7.5 [RFC8446] using the following inputs.
Section 7.5 [RFC8446] for TLS version 1.3, using the following
inputs.
The disambiguating label string (for PRF) or label (for HKDF) The disambiguating label string [RFC5705] SHALL be "EXPORTER-
SHALL be "EXPORTER-network-time-security/1". network-time-security".
The context value SHALL consist of the following five octets: The context value SHALL consist of the following five octets:
The first two octets SHALL be zero (the Protocol ID for NTPv4). The first two octets SHALL be zero (the Protocol ID for NTPv4).
The next two octets SHALL be the Numeric Identifier of the The next two octets SHALL be the Numeric Identifier of the
negotiated AEAD Algorithm in network byte order. negotiated AEAD Algorithm in network byte order.
The final octet SHALL be 0x00 for the C2S key and 0x01 for the The final octet SHALL be 0x00 for the C2S key and 0x01 for the
S2C key. S2C key.
skipping to change at page 19, line 28 skipping to change at page 19, line 28
`N_REQ` be the lesser of 16 and N_MAX, rounded up to the nearest `N_REQ` be the lesser of 16 and N_MAX, rounded up to the nearest
multiple of 4. If N_LEN is greater than or equal to N_REQ, then no multiple of 4. If N_LEN is greater than or equal to N_REQ, then no
Additional Padding field is required. Otherwise, the Additional Additional Padding field is required. Otherwise, the Additional
Padding field SHALL be at least N_REQ - N_LEN octets in length. Padding field SHALL be at least N_REQ - N_LEN octets in length.
Servers MUST enforce this requirement by discarding any packet which Servers MUST enforce this requirement by discarding any packet which
does not conform to it. does not conform to it.
Senders are always free to include more Additional Padding than Senders are always free to include more Additional Padding than
mandated by the above paragraph. Theoretically, it could be mandated by the above paragraph. Theoretically, it could be
necessary to do so in order to bring the extension field to the necessary to do so in order to bring the extension field to the
minimum length required by [RFC7822]. This should never happen in minimum length required by RFC 7822 [RFC7822]. This should never
practice because any reasonable AEAD algorithm will have a nonce and happen in practice because any reasonable AEAD algorithm will have a
an authenticator long enough to bring the extension field to its nonce and an authenticator long enough to bring the extension field
required length already. Nonetheless, implementers are advised to to its required length already. Nonetheless, implementers are
explicitly handle this case and ensure that the extension field they advised to explicitly handle this case and ensure that the extension
emit is of legal length. field they emit is of legal length.
The NTS Authenticator and Encrypted Extension Fields extension field The NTS Authenticator and Encrypted Extension Fields extension field
MUST NOT be included in NTP packets whose mode is other than 3 MUST NOT be included in NTP packets whose mode is other than 3
(client) or 4 (server). (client) or 4 (server).
5.7. Protocol Details 5.7. Protocol Details
A client sending an NTS-protected request SHALL include the following A client sending an NTS-protected request SHALL include the following
extension fields as displayed in Figure 5: extension fields as displayed in Figure 5:
skipping to change at page 23, line 6 skipping to change at page 23, line 6
encrypted), within it (therefore encrypted and authenticated), or encrypted), within it (therefore encrypted and authenticated), or
after it (therefore neither encrypted nor authenticated). The client after it (therefore neither encrypted nor authenticated). The client
MUST discard any unauthenticated extension fields. Future MUST discard any unauthenticated extension fields. Future
specifications of extension fields MAY provide exceptions to this specifications of extension fields MAY provide exceptions to this
rule. rule.
Upon receiving an NTS-protected response, the client MUST verify that Upon receiving an NTS-protected response, the client MUST verify that
the Unique Identifier matches that of an outstanding request, and the Unique Identifier matches that of an outstanding request, and
that the packet is authentic under the S2C key associated with that that the packet is authentic under the S2C key associated with that
request. If either of these checks fails, the packet MUST be request. If either of these checks fails, the packet MUST be
discarded without further processing. discarded without further processing. In particular, the client MUST
discard unprotected responses to NTS-protected requests.
If the server is unable to validate the cookie or authenticate the If the server is unable to validate the cookie or authenticate the
request, it SHOULD respond with a Kiss-o'-Death (KoD) packet (see RFC request, it SHOULD respond with a Kiss-o'-Death (KoD) packet (see RFC
5905, Section 7.4 [RFC5905]) with kiss code "NTSN", meaning "NTS NAK" 5905, Section 7.4 [RFC5905]) with kiss code "NTSN", meaning "NTS NAK"
(NTS negative-acknowledgment). It MUST NOT include any NTS Cookie or (NTS negative-acknowledgment). It MUST NOT include any NTS Cookie or
NTS Authenticator and Encrypted Extension Fields extension fields. NTS Authenticator and Encrypted Extension Fields extension fields.
If the NTP server has previously responded with authentic NTS- If the NTP server has previously responded with authentic NTS-
protected NTP packets, the client MUST verify that any KoD packets protected NTP packets, the client MUST verify that any KoD packets
received from the server contain the Unique Identifier extension received from the server contain the Unique Identifier extension
field and that the Unique Identifier matches that of an outstanding field and that the Unique Identifier matches that of an outstanding
request. If this check fails, the packet MUST be discarded without request. If this check fails, the packet MUST be discarded without
further processing. If this check passes, the client MUST comply further processing. If this check passes, the client MUST comply
with RFC 5905, Section 7.4 [RFC5905] where required. A client MAY with RFC 5905, Section 7.4 [RFC5905] where required. A client MAY
automatically re-run the NTS-KE protocol upon forced disassociation automatically re-run the NTS-KE protocol upon forced disassociation
from an NTP server. In that case, it MUST be able to detect and stop from an NTP server. In that case, it MUST avoid quickly looping
looping between the NTS-KE and NTP servers by rate limiting the between the NTS-KE and NTP servers by rate limiting the retries
retries using e.g. exponential retry intervals. using, for example, exponential retry intervals. A reasonable
maximum retry interval could be 7 days, depending on the application.
Upon reception of the NTS NAK kiss code, the client SHOULD wait until Upon reception of the NTS NAK kiss code, the client SHOULD wait until
the next poll for a valid NTS-protected response and if none is the next poll for a valid NTS-protected response and if none is
received, initiate a fresh NTS-KE handshake to try to renegotiate new received, initiate a fresh NTS-KE handshake to try to renegotiate new
cookies, AEAD keys, and parameters. If the NTS-KE handshake cookies, AEAD keys, and parameters. If the NTS-KE handshake
succeeds, the client MUST discard all old cookies and parameters and succeeds, the client MUST discard all old cookies and parameters and
use the new ones instead. As long as the NTS-KE handshake has not use the new ones instead. As long as the NTS-KE handshake has not
succeeded, the client SHOULD continue polling the NTP server using succeeded, the client SHOULD continue polling the NTP server using
the cookies and parameters it has. the cookies and parameters it has.
skipping to change at page 24, line 9 skipping to change at page 24, line 11
The role of cookies in NTS is closely analogous to that of session The role of cookies in NTS is closely analogous to that of session
cookies in TLS. Accordingly, the thematic resemblance of this cookies in TLS. Accordingly, the thematic resemblance of this
section to RFC 5077 [RFC5077] is deliberate and the reader should section to RFC 5077 [RFC5077] is deliberate and the reader should
likewise take heed of its security considerations. likewise take heed of its security considerations.
Servers should select an AEAD algorithm which they will use to Servers should select an AEAD algorithm which they will use to
encrypt and authenticate cookies. The chosen algorithm should be one encrypt and authenticate cookies. The chosen algorithm should be one
such as AEAD_AES_SIV_CMAC_256 [RFC5297] which resists accidental such as AEAD_AES_SIV_CMAC_256 [RFC5297] which resists accidental
nonce reuse. It need not be the same as the one that was negotiated nonce reuse. It need not be the same as the one that was negotiated
with the client. Servers should randomly generate and store a master with the client. Servers should randomly generate and store a secret
AEAD key `K`. Servers should additionally choose a non-secret, unique master AEAD key `K`. Servers should additionally choose a non-secret,
value `I` as key-identifier for `K`. unique value `I` as key-identifier for `K`.
Servers should periodically (e.g., once daily) generate a new pair Servers should periodically (e.g., once daily) generate a new pair
(I,K) and immediately switch to using these values for all newly- (I,K) and immediately switch to using these values for all newly-
generated cookies. Following each such key rotation, servers should generated cookies. Following each such key rotation, servers should
securely erase any prevoiusly generated keys that should now be securely erase any previously generated keys that should now be
expired, e.g. two or more rotation periods prior. Servers should expired. Servers should continue to accept any cookie generated
continue to accept any cookie generated using keys that they have not using keys that they have not yet erased, even if those keys are no
yet erased, even if those keys are no longer current. Erasing old longer current. Erasing old keys provides for forward secrecy,
keys provides for forward secrecy, limiting the scope of what old limiting the scope of what old information can be stolen if a master
information can be stolen if a master key is somehow compromised. key is somehow compromised. Holding on to a limited number of old
Holding on to a limited number of old keys allows clients to keys allows clients to seamlessly transition from one generation to
seamlessly transition from one generation to the next without having the next without having to perform a new NTS-KE handshake.
to perform a new NTS-KE handshake.
The need to keep keys synchronized between NTS-KE and NTP servers as The need to keep keys synchronized between NTS-KE and NTP servers as
well as across load-balanced clusters can make automatic key rotation well as across load-balanced clusters can make automatic key rotation
challenging. However, the task can be accomplished without the need challenging. However, the task can be accomplished without the need
for central key-management infrastructure by using a ratchet, i.e., for central key-management infrastructure by using a ratchet, i.e.,
making each new key a deterministic, cryptographically pseudo-random making each new key a deterministic, cryptographically pseudo-random
function of its predecessor. A recommended concrete implementation function of its predecessor. A recommended concrete implementation
of this approach is to use HKDF [RFC5869] to derive new keys, using of this approach is to use HKDF [RFC5869] to derive new keys, using
the key's predecessor as Input Keying Material and its key identifier the key's predecessor as Input Keying Material and its key identifier
as a salt. as a salt.
skipping to change at page 26, line 10 skipping to change at page 26, line 10
Identification Sequence: Identification Sequence:
0x6E 0x74 0x73 0x6B 0x65 0x2F 0x31 ("ntske/1") 0x6E 0x74 0x73 0x6B 0x65 0x2F 0x31 ("ntske/1")
Reference: [[this memo]], Section 4 Reference: [[this memo]], Section 4
7.3. TLS Exporter Labels Registry 7.3. TLS Exporter Labels Registry
IANA is requested to allocate the following entry in the TLS Exporter IANA is requested to allocate the following entry in the TLS Exporter
Labels Registry [RFC5705]: Labels Registry [RFC5705]:
+--------------------+---------+-------------+---------------+------+ +-------------------+---------+-------------+----------------+------+
| Value | DTLS-OK | Recommended | Reference | Note | | Value | DTLS-OK | Recommended | Reference | Note |
+--------------------+---------+-------------+---------------+------+ +-------------------+---------+-------------+----------------+------+
| EXPORTER-network- | Y | Y | [[this | | | EXPORTER-network- | Y | Y | [[this memo]], | |
| time-security/1 | | | memo]], | | | time-security | | | Section 4.2 | |
| | | | Section 4.2 | | +-------------------+---------+-------------+----------------+------+
+--------------------+---------+-------------+---------------+------+
7.4. NTP Kiss-o'-Death Codes Registry 7.4. NTP Kiss-o'-Death Codes Registry
IANA is requested to allocate the following entry in the registry of IANA is requested to allocate the following entry in the registry of
NTP Kiss-o'-Death Codes [RFC5905]: NTP Kiss-o'-Death Codes [RFC5905]:
+------+---------------------------------------+--------------------+ +------+---------------------------------------+--------------------+
| Code | Meaning | Reference | | Code | Meaning | Reference |
+------+---------------------------------------+--------------------+ +------+---------------------------------------+--------------------+
| NTSN | Network Time Security (NTS) negative- | [[this memo]], | | NTSN | Network Time Security (NTS) negative- | [[this memo]], |
skipping to change at page 35, line 5 skipping to change at page 35, line 5
9.1. Protected Modes 9.1. Protected Modes
NTP provides many different operating modes in order to support NTP provides many different operating modes in order to support
different network topologies and to adapt to various requirements. different network topologies and to adapt to various requirements.
This memo only specifies NTS for NTP modes 3 (client) and 4 (server) This memo only specifies NTS for NTP modes 3 (client) and 4 (server)
(see Section 1.2). The best current practice for authenticating the (see Section 1.2). The best current practice for authenticating the
other NTP modes is using the symmetric message authentication code other NTP modes is using the symmetric message authentication code
feature as described in RFC 5905 [RFC5905] and RFC 8573 [RFC8573]. feature as described in RFC 5905 [RFC5905] and RFC 8573 [RFC8573].
9.2. Sensitivity to DDoS Attacks 9.2. Key Compromise
If the suggested format for NTS cookies in Section 6 of this draft is
used, an attacker who has gained access to the secret cookie
encryption key `K` can impersonate the NTP server, including
generating new cookies. NTP and NTS-KE server operators SHOULD
remove compromised keys as soon as the compromise is discovered.
This will cause the NTP servers to respond with NTS NAK, thus forcing
key renegotiation. Note that this measure does not protect against
MITM attacks where the attacker has access to a compromised cookie
encryption key. If another cookie scheme is used, there are likely
similar considerations for that particular scheme.
9.3. Sensitivity to DDoS Attacks
The introduction of NTS brings with it the introduction of asymmetric The introduction of NTS brings with it the introduction of asymmetric
cryptography to NTP. Asymmetric cryptography is necessary for cryptography to NTP. Asymmetric cryptography is necessary for
initial server authentication and AEAD key extraction. Asymmetric initial server authentication and AEAD key extraction. Asymmetric
cryptosystems are generally orders of magnitude slower than their cryptosystems are generally orders of magnitude slower than their
symmetric counterparts. This makes it much harder to build systems symmetric counterparts. This makes it much harder to build systems
that can serve requests at a rate corresponding to the full line that can serve requests at a rate corresponding to the full line
speed of the network connection. This, in turn, opens up a new speed of the network connection. This, in turn, opens up a new
possibility for DDoS attacks on NTP services. possibility for DDoS attacks on NTP services.
The main protection against these attacks in NTS lies in that the use The main protection against these attacks in NTS lies in that the use
of asymmetric cryptosystems is only necessary in the initial NTS-KE of asymmetric cryptosystems is only necessary in the initial NTS-KE
phase of the protocol. Since the protocol design enables separation phase of the protocol. Since the protocol design enables separation
of the NTS-KE and NTP servers, a successful DDoS attack on an NTS-KE of the NTS-KE and NTP servers, a successful DDoS attack on an NTS-KE
server separated from the NTP service it supports will not affect NTP server separated from the NTP service it supports will not affect NTP
users that have already performed initial authentication, AEAD key users that have already performed initial authentication, AEAD key
extraction, and cookie exchange. extraction, and cookie exchange.
NTS users should also consider that they are not fully protected NTS users should also consider that they are not fully protected
against DoS attacks by on-path adversaries. In addition to dropping against DoS attacks by on-path adversaries. In addition to dropping
packets and attacks such as those described in Section 9.5, an on- packets and attacks such as those described in Section 9.6, an on-
path attacker can send spoofed kiss-o'-death replies, which are not path attacker can send spoofed kiss-o'-death replies, which are not
authenticated, in response to NTP requests. This could result in authenticated, in response to NTP requests. This could result in
significantly increased load on the NTS-KE server. Implementers have significantly increased load on the NTS-KE server. Implementers have
to weigh the user's need for unlinkability against the added to weigh the user's need for unlinkability against the added
resilience that comes with cookie reuse in cases of NTS-KE server resilience that comes with cookie reuse in cases of NTS-KE server
unavailability. unavailability.
9.3. Avoiding DDoS Amplification 9.4. Avoiding DDoS Amplification
Certain non-standard and/or deprecated features of the Network Time Certain non-standard and/or deprecated features of the Network Time
Protocol enable clients to send a request to a server which causes Protocol enable clients to send a request to a server which causes
the server to send a response much larger than the request. Servers the server to send a response much larger than the request. Servers
which enable these features can be abused in order to amplify traffic which enable these features can be abused in order to amplify traffic
volume in DDoS attacks by sending them a request with a spoofed volume in DDoS attacks by sending them a request with a spoofed
source IP. In recent years, attacks of this nature have become an source IP. In recent years, attacks of this nature have become an
endemic nuisance. endemic nuisance.
NTS is designed to avoid contributing any further to this problem by NTS is designed to avoid contributing any further to this problem by
skipping to change at page 36, line 10 skipping to change at page 36, line 21
sent by the client. In particular, this is why the client is sent by the client. In particular, this is why the client is
required to send a separate and appropriately padded-out NTS Cookie required to send a separate and appropriately padded-out NTS Cookie
Placeholder extension field for every cookie it wants to get back, Placeholder extension field for every cookie it wants to get back,
rather than being permitted simply to specify a desired quantity. rather than being permitted simply to specify a desired quantity.
Due to the RFC 7822 [RFC7822] requirement that extensions be padded Due to the RFC 7822 [RFC7822] requirement that extensions be padded
and aligned to four-octet boundaries, response size may still in some and aligned to four-octet boundaries, response size may still in some
cases exceed request size by up to three octets. This is cases exceed request size by up to three octets. This is
sufficiently inconsequential that we have declined to address it. sufficiently inconsequential that we have declined to address it.
9.4. Initial Verification of Server Certificates 9.5. Initial Verification of Server Certificates
NTS's security goals are undermined if the client fails to verify NTS's security goals are undermined if the client fails to verify
that the X.509 certificate chain presented by the NTS-KE server is that the X.509 certificate chain presented by the NTS-KE server is
valid and rooted in a trusted certificate authority. RFC 5280 valid and rooted in a trusted certificate authority. RFC 5280
[RFC5280] and RFC 6125 [RFC6125] specify how such verification is to [RFC5280] and RFC 6125 [RFC6125] specify how such verification is to
be performed in general. However, the expectation that the client be performed in general. However, the expectation that the client
does not yet have a correctly-set system clock at the time of does not yet have a correctly-set system clock at the time of
certificate verification presents difficulties with verifying that certificate verification presents difficulties with verifying that
the certificate is within its validity period, i.e., that the current the certificate is within its validity period, i.e., that the current
time lies between the times specified in the certificate's notBefore time lies between the times specified in the certificate's notBefore
and notAfter fields. It may be operationally necessary in some cases and notAfter fields. It may be operationally necessary in some cases
for a client to accept a certificate which appears to be expired or for a client to accept a certificate which appears to be expired or
not yet valid. While there is no perfect solution to this problem, not yet valid. While there is no perfect solution to this problem,
there are several mitigations the client can implement to make it there are several mitigations the client can implement to make it
more difficult for an adversary to successfully present an expired more difficult for an adversary to successfully present an expired
certificate: certificate:
Check whether the system time is in fact unreliable. If the Check whether the system time is in fact unreliable. On systems
system clock has previously been synchronized since last boot, with the ntp_adjtime() system call, a return code other than
then on operating systems which implement a kernel-based phase- TIME_ERROR indicates that some trusted software has already set
locked-loop API, a call to ntp_gettime() should show a maximum the time and certificates can be strictly validated.
error less than NTP_PHASE_MAX. In this case, the clock SHOULD be
considered reliable and certificates can be strictly validated.
Allow the system administrator to specify that certificates should Allow the system administrator to specify that certificates should
*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
skipping to change at page 37, line 16 skipping to change at page 37, line 26
server, for example by picking a random time in the week preceding server, for example by picking a random time in the week preceding
certificate expiry to perform the new handshake. 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.5. Delay Attacks 9.6. Delay Attacks
In a packet delay attack, an adversary with the ability to act as a In a packet delay attack, an adversary with the ability to act as a
man-in-the-middle delays time synchronization packets between client man-in-the-middle delays time synchronization packets between client
and server asymmetrically [RFC7384]. Since NTP's formula for and server asymmetrically [RFC7384]. Since NTP's formula for
computing time offset relies on the assumption that network latency computing time offset relies on the assumption that network latency
is roughly symmetrical, this leads to the client to compute an is roughly symmetrical, this leads to the client to compute an
inaccurate value [Mizrahi]. The delay attack does not reorder or inaccurate value [Mizrahi]. The delay attack does not reorder or
modify the content of the exchanged synchronization packets. modify the content of the exchanged synchronization packets.
Therefore, cryptographic means do not provide a feasible way to Therefore, cryptographic means do not provide a feasible way to
mitigate this attack. However, the maximum error that an adversary mitigate this attack. However, the maximum error that an adversary
skipping to change at page 37, line 43 skipping to change at page 38, line 5
client will tolerate before concluding that the server is unsuitable client will tolerate before concluding that the server is unsuitable
for synchronization. The standard value for MAXDIST is one second, for synchronization. The standard value for MAXDIST is one second,
although some implementations use larger values. Whatever value a although some implementations use larger values. Whatever value a
client chooses, the maximum error which can be introduced by a delay client chooses, the maximum error which can be introduced by a delay
attack is MAXDIST/2. attack is MAXDIST/2.
Usage of multiple time sources, or multiple network paths to a given Usage of multiple time sources, or multiple network paths to a given
time source [Shpiner], may also serve to mitigate delay attacks if time source [Shpiner], may also serve to mitigate delay attacks if
the adversary is in control of only some of the paths. the adversary is in control of only some of the paths.
9.6. NTS Stripping 9.7. NTS Stripping
Implementers must be aware of the possibility of "NTS stripping" Implementers must be aware of the possibility of "NTS stripping"
attacks, where an attacker tricks clients into reverting to plain attacks, where an attacker attempts to trick clients into reverting
NTP. Naive client implementations might, for example, revert to plain NTP. Naive client implementations might, for example,
automatically to plain NTP if the NTS-KE handshake fails. A man-in- revert automatically to plain NTP if the NTS-KE handshake fails. A
the-middle attacker can easily cause this to happen. Even clients man-in-the-middle attacker can easily cause this to happen. Even
that already hold valid cookies can be vulnerable, since an attacker clients that already hold valid cookies can be vulnerable, since an
can force a client to repeat the NTS-KE handshake by sending faked attacker can force a client to repeat the NTS-KE handshake by sending
NTP mode 4 replies with the NTS NAK kiss code. Forcing a client to faked NTP mode 4 replies with the NTS NAK kiss code. Forcing a
repeat the NTS-KE handshake can also be the first step in more client to repeat the NTS-KE handshake can also be the first step in
advanced attacks. more advanced attacks.
For the reasons described here, implementations SHOULD NOT revert For the reasons described here, implementations SHOULD NOT revert
from NTS-protected to unprotected NTP with any server without from NTS-protected to unprotected NTP with any server without
explicit user action. explicit user action.
10. Privacy Considerations 10. Privacy Considerations
10.1. Unlinkability 10.1. Unlinkability
Unlinkability prevents a device from being tracked when it changes Unlinkability prevents a device from being tracked when it changes
skipping to change at page 39, line 24 skipping to change at page 39, line 31
and all other fields are set the same regardless of the identity of and all other fields are set the same regardless of the identity of
the client making the request. the client making the request.
Future extension fields could hypothetically contain sensitive Future extension fields could hypothetically contain sensitive
information, in which case NTS provides a mechanism for encrypting information, in which case NTS provides a mechanism for encrypting
them. them.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Richard Barnes, Steven Bellovin, The authors would like to thank Richard Barnes, Steven Bellovin,
Patrik Faeltstroem (Faltstrom), Scott Fluhrer, Sharon Goldberg, Russ Scott Fluhrer, Patrik Faeltstroem (Faltstrom), Sharon Goldberg, Russ
Housley, Benjamin Kaduk, Suresh Krishnan, Martin Langer, Barry Leiba, Housley, Benjamin Kaduk, Suresh Krishnan, Mirja Kuehlewind
Miroslav Lichvar, Aanchal Malhotra, Dave Mills, Sandra Murphy, Danny (Kuehlewind), Martin Langer, Barry Leiba, Miroslav Lichvar, Aanchal
Mayer, Karen O'Donoghue, Eric K. Rescorla, Stephen Roettger, Kurt Malhotra, Danny Mayer, Dave Mills, Sandra Murphy, Hal Murray, Karen
Roeckx, Dan Romascanu, Kyle Rose, Rich Salz, Brian Sniffen, Susan O'Donoghue, Eric K. Rescorla, Kurt Roeckx, Stephen Roettger, Dan
Sons, Douglas Stebila, Harlan Stenn, Joachim Stroembergsson Romascanu, Kyle Rose, Rich Salz, Brian Sniffen, Susan Sons, Douglas
(Strombergsson), Martin Thomson, Eric (Eric) Vyncke, Richard Welty, Stebila, Harlan Stenn, Joachim Stroembergsson (Strombergsson), Martin
Christer Weinigel, and Magnus Westerlund for contributions to this Thomson, Eric (Eric) Vyncke, Richard Welty, Christer Weinigel, and
document and comments on the design of NTS. Magnus Westerlund for contributions to this document and comments on
the design of NTS.
12. References 12. References
12.1. Normative References 12.1. Normative References
[IANA-AEAD] [IANA-AEAD]
IANA, "Authenticated Encryption with Associated Data IANA, "Authenticated Encryption with Associated Data
(AEAD) Parameters", (AEAD) Parameters",
<https://www.iana.org/assignments/aead-parameters/>. <https://www.iana.org/assignments/aead-parameters/>.
skipping to change at page 41, line 50 skipping to change at page 42, line 8
12.2. Informative References 12.2. Informative References
[I-D.ietf-ntp-data-minimization] [I-D.ietf-ntp-data-minimization]
Franke, D. and A. Malhotra, "NTP Client Data Franke, D. and A. Malhotra, "NTP Client Data
Minimization", draft-ietf-ntp-data-minimization-04 (work Minimization", draft-ietf-ntp-data-minimization-04 (work
in progress), March 2019. in progress), March 2019.
[Mizrahi] Mizrahi, T., "A game theoretic analysis of delay attacks [Mizrahi] Mizrahi, T., "A game theoretic analysis of delay attacks
against time synchronization protocols", in Proceedings against time synchronization protocols", in Proceedings
of Precision Clock Synchronization for Measurement Control of Precision Clock Synchronization for Measurement Control
and Communication, ISPCS 2012, pp. 1-6 and Communication, ISPCS 2012, pp. 1-6,
DOI 10.1109/ISPCS.2012.6336612, September 2012. DOI 10.1109/ISPCS.2012.6336612, September 2012.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
skipping to change at page 42, line 27 skipping to change at page 42, line 33
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code [RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code
for the Network Time Protocol", RFC 8573, for the Network Time Protocol", RFC 8573,
DOI 10.17487/RFC8573, June 2019, DOI 10.17487/RFC8573, June 2019,
<https://www.rfc-editor.org/info/rfc8573>. <https://www.rfc-editor.org/info/rfc8573>.
[Shpiner] Shpiner, A., Revah, Y., and T. Mizrahi, "Multi-path Time [Shpiner] Shpiner, A., Revah, Y., and T. Mizrahi, "Multi-path Time
Protocols", in Proceedings of IEEE International Symposium Protocols", in Proceedings of IEEE International Symposium
on Precision Clock Synchronization for Measurement, on Precision Clock Synchronization for Measurement,
Control and Communication (ISPCS) Control and Communication (ISPCS),
DOI 10.1109/ISPCS.2013.6644754, September 2013. DOI 10.1109/ISPCS.2013.6644754, September 2013.
Appendix A. Terms and Abbreviations Appendix A. Terms and Abbreviations
AEAD Authenticated Encryption with Associated Data [RFC5116] AEAD Authenticated Encryption with Associated Data [RFC5116]
ALPN Application-Layer Protocol Negotiation [RFC7301] ALPN Application-Layer Protocol Negotiation [RFC7301]
C2S Client-to-server C2S Client-to-server
skipping to change at page 43, line 4 skipping to change at page 43, line 10
EF Extension Field [RFC5905] EF Extension Field [RFC5905]
HKDF Hashed Message Authentication Code-based Key Derivation HKDF Hashed Message Authentication Code-based Key Derivation
Function [RFC5869] Function [RFC5869]
KoD Kiss-o'-Death [RFC5905] KoD Kiss-o'-Death [RFC5905]
NTP Network Time Protocol [RFC5905] NTP Network Time Protocol [RFC5905]
NTS Network Time Security NTS Network Time Security
NTS NAK NTS negative-acknowledgment NTS NAK NTS negative-acknowledgment
NTS-KE Network Time Security Key Exchange NTS-KE Network Time Security Key Exchange
PRF Pseudorandom Function
S2C Server-to-client S2C Server-to-client
TLS Transport Layer Security [RFC8446] TLS Transport Layer Security [RFC8446]
Authors' Addresses Authors' Addresses
Daniel Fox Franke Daniel Fox Franke
Akamai Technologies Akamai Technologies
145 Broadway 145 Broadway
Cambridge, MA 02142 Cambridge, MA 02142
 End of changes. 40 change blocks. 
102 lines changed or deleted 112 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/