draft-ietf-ntp-using-nts-for-ntp-10.txt   draft-ietf-ntp-using-nts-for-ntp-11.txt 
NTP Working Group D. Franke NTP Working Group D. Franke
Internet-Draft Akamai Internet-Draft
Intended status: Standards Track D. Sibold Intended status: Standards Track D. Sibold
Expires: May 3, 2018 K. Teichel Expires: September 6, 2018 K. Teichel
PTB PTB
October 30, 2017 March 05, 2018
Network Time Security for the Network Time Protocol Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-10 draft-ietf-ntp-using-nts-for-ntp-11
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
Network Time Protocol. Network Time Protocol.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 May 3, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Protocol overview . . . . . . . . . . . . . . . . . . . . 4 1.2. Protocol overview . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. TLS profile for Network Time Security . . . . . . . . . . . . 5 3. TLS profile for Network Time Security . . . . . . . . . . . . 5
4. The NTS Key Establishment protocol . . . . . . . . . . . . . 6 4. The NTS Key Establishment protocol . . . . . . . . . . . . . 6
4.1. NTS-KE record types . . . . . . . . . . . . . . . . . . . 7 4.1. NTS-KE record types . . . . . . . . . . . . . . . . . . . 8
4.1.1. End of Message . . . . . . . . . . . . . . . . . . . 7 4.1.1. End of Message . . . . . . . . . . . . . . . . . . . 8
4.1.2. NTS Next Protocol Negotiation . . . . . . . . . . . . 7 4.1.2. NTS Next Protocol Negotiation . . . . . . . . . . . . 9
4.1.3. Error . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.3. Error . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.4. Warning . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.4. Warning . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.5. AEAD Algorithm Negotiation . . . . . . . . . . . . . 8 4.1.5. AEAD Algorithm Negotiation . . . . . . . . . . . . . 10
4.1.6. New Cookie for NTPv4 . . . . . . . . . . . . . . . . 9 4.1.6. New Cookie for NTPv4 . . . . . . . . . . . . . . . . 11
4.2. Key Extraction (generally) . . . . . . . . . . . . . . . 9 4.2. Key Extraction (generally) . . . . . . . . . . . . . . . 11
5. NTS Extension Fields for NTPv4 . . . . . . . . . . . . . . . 10 5. NTS Extension Fields for NTPv4 . . . . . . . . . . . . . . . 11
5.1. Key Extraction (for NTPv4) . . . . . . . . . . . . . . . 10 5.1. Key Extraction (for NTPv4) . . . . . . . . . . . . . . . 11
5.2. Packet structure overview . . . . . . . . . . . . . . . . 10 5.2. Packet structure overview . . . . . . . . . . . . . . . . 12
5.3. The Unique Identifier extension field . . . . . . . . . . 11 5.3. The Unique Identifier extension field . . . . . . . . . . 12
5.4. The NTS Cookie extension field . . . . . . . . . . . . . 11 5.4. The NTS Cookie extension field . . . . . . . . . . . . . 13
5.5. The NTS Cookie Placeholder extension field . . . . . . . 11 5.5. The NTS Cookie Placeholder extension field . . . . . . . 13
5.6. The NTS Authenticator and Encrypted Extension Fields 5.6. The NTS Authenticator and Encrypted Extension Fields
extension field . . . . . . . . . . . . . . . . . . . . . 12 extension field . . . . . . . . . . . . . . . . . . . . . 13
5.7. Protocol details . . . . . . . . . . . . . . . . . . . . 13 6. Protocol details . . . . . . . . . . . . . . . . . . . . . . 14
6. Suggested format for NTS cookies . . . . . . . . . . . . . . 15 7. Suggested format for NTS cookies . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security considerations . . . . . . . . . . . . . . . . . . . 20 9. Security considerations . . . . . . . . . . . . . . . . . . . 23
8.1. Avoiding DDoS amplification . . . . . . . . . . . . . . . 20 9.1. Avoiding DDoS amplification . . . . . . . . . . . . . . . 23
8.2. Initial verification of server certificates . . . . . . . 21 9.2. Initial verification of server certificates . . . . . . . 23
8.3. Usage of NTP pools . . . . . . . . . . . . . . . . . . . 22 9.3. Usage of NTP pools . . . . . . . . . . . . . . . . . . . 24
8.4. Delay attacks . . . . . . . . . . . . . . . . . . . . . . 22 9.4. Delay attacks . . . . . . . . . . . . . . . . . . . . . . 25
8.5. Random number generation . . . . . . . . . . . . . . . . 23 9.5. Random number generation . . . . . . . . . . . . . . . . 25
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
9.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 25
9.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 23 10.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 26 Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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].
1.1. Objectives 1.1. Objectives
skipping to change at page 3, line 38 skipping to change at page 3, line 38
o Replay prevention: Client implementations may detect when a o Replay prevention: Client implementations may 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 may 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 which would permit a passive adversary to determine information additional to NTP which would permit a passive
that two packets sent over different networks came from the same adversary to determine that two packets sent over different
client. networks came from the same client.
o Non-amplification: implementations (especially server o Non-amplification: implementations (especially server
implementations) may avoid acting as DDoS amplifiers by never implementations) may avoid acting as DDoS amplifiers by never
responding to a request with a packet larger than the request responding to a request with a packet larger than the request
packet. packet.
o Scalability: Server implementations may serve large numbers of o Scalability: Server implementations may serve large numbers of
clients without having to retain any client-specific state. clients without having to retain any client-specific state.
1.2. Protocol overview 1.2. Protocol overview
skipping to change at page 4, line 21 skipping to change at page 4, line 21
monitoring and administration and a broadcast mode. These various monitoring and administration and a broadcast mode. These various
modes have differing and partly contradictory requirements for modes have differing and partly contradictory requirements for
security and performance. Symmetric and control modes demand mutual security and performance. Symmetric and control modes demand mutual
authentication and mutual replay protection, and for certain message authentication and mutual replay protection, and for certain message
types control mode may require confidentiality as well as types control mode may require confidentiality as well as
authentication. Client-server mode places more stringent authentication. Client-server mode places more stringent
requirements on resource utilization than other modes, because requirements on resource utilization than other modes, because
servers may have vast number of clients and be unable to afford to servers may have vast number of clients and be unable to afford to
maintain per-client state. However, client-server mode also has more maintain per-client state. However, client-server mode also has more
relaxed security needs, because only the client requires replay relaxed security needs, because only the client requires replay
protection: it is harmless for servers to process replayed packets. protection: it is harmless for stateless servers to process replayed
The security demands of symmetric and control modes, on the other packets. The security demands of symmetric and control modes, on the
hand, are in conflict with the resource-utilization demands of other hand, are in conflict with the resource-utilization demands of
client-server mode: any scheme which provides replay protection client-server mode: any scheme which provides replay protection
inherently involves maintaining some state to keep track of what inherently involves maintaining some state to keep track of what
messages have already been seen. messages have already been seen.
This memo specifies NTS exclusively for the client-server mode of This memo specifies NTS exclusively for the client-server mode of
NTP. To this end, NTS is structured as a suite of two protocols: NTP. To this end, NTS is structured as a suite of two protocols:
The "NTS Extension Fields for NTPv4" are a collection of NTP The "NTS Extension Fields for NTPv4" are a collection of NTP
extension fields for cryptographically securing NTPv4 using extension fields for cryptographically securing NTPv4 using
previously-established key material. They are suitable for previously-established key material. They are suitable for
skipping to change at page 7, line 24 skipping to change at page 7, line 24
representable length and need not be aligned to a word boundary. representable length and need not be aligned to a word boundary.
Record Body: the syntax and semantics of this field SHALL be Record Body: the syntax and semantics of this field SHALL be
determined by the Record Type. determined by the Record Type.
For clarity regarding bit-endianness: the Critical Bit is the most- For clarity regarding bit-endianness: the Critical Bit is the most-
significant bit of the first octet. In C, given a network buffer significant bit of the first octet. In C, given a network buffer
`unsigned char b[]` containing an NTS-KE record, the critical bit is `unsigned char b[]` containing an NTS-KE record, the critical bit is
`b[0] >> 7` while the record type is `((b[0] & 0x7f) << 8) + b[1]`. `b[0] >> 7` while the record type is `((b[0] & 0x7f) << 8) + b[1]`.
Figure 2 provides a schematic overview of the key exchange. It
displays the protocol steps to be performed by the NTS client and
server and record types to be exchanged.
+---------------------------------------+
| - verify client request message |
| - extract TLS key material |
| - generate KE response message |
| - included Record Types: |
| - NTS Next Protocol Negotiation |
| - AEAD Alg. Negotiation |
| - New Cookie for NTPv4 |
| - <New Cookie for NTPv4> |
| - End of Message |
+-----------------+---------------------+
|
|
Server -------- --+---------------+-----+----------------------->
^ \
/ \
/ TLS application \
/ data \
/ \
/ V
Client -----+---------------------------------+---------------->
| |
| |
| |
+-----------+----------------------+ +------+-----------------+
|- generate KE request message | |- verify server response|
| - include Record Types: | | message |
| o NTS Next Protocol Negotiation | |- extract cookie(s) |
| o AEAD Alg. Negotiation | | |
| o End of Message | | |
+----------------------------------+ +------------------------+
Figure 2: NTS Key Exchange messages
4.1. NTS-KE record types 4.1. NTS-KE record types
The following NTS-KE Record Types are defined. The following NTS-KE Record Types are defined.
4.1.1. End of Message 4.1.1. End of Message
The End of Message record has a Record Type number of 0 and an zero- The End of Message record has a Record Type number of 0 and an zero-
length body. It MUST occur exactly once as the final record of every length body. It MUST occur exactly once as the final record of every
NTS-KE request and response. The Critical Bit MUST be set. NTS-KE request and response. The Critical Bit MUST be set.
skipping to change at page 8, line 39 skipping to change at page 10, line 13
with a new TLS handshake and retry its request. with a new TLS handshake and retry its request.
4.1.4. Warning 4.1.4. Warning
The Warning record has a Record Type number of 3. Its body is The Warning record has a Record Type number of 3. Its body is
exactly two octets long, consisting of an unsigned 16-bit integer in exactly two octets long, consisting of an unsigned 16-bit integer in
network byte order, denoting a warning code. The Critical Bit MUST network byte order, denoting a warning code. The Critical Bit MUST
be set. be set.
Clients MUST NOT include Warning records in their request. If Clients MUST NOT include Warning records in their request. If
clients receive a server response which includes an Warning record, clients receive a server response which includes a Warning record,
they MAY discard any negotiated key material and abort without they MAY discard any negotiated key material and abort without
proceeding to the Next Protocol. Unrecognized warning codes MUST be proceeding to the Next Protocol. Unrecognized warning codes MUST be
treated as errors. treated as errors.
This memo defines no warning codes. This memo defines no warning codes.
4.1.5. AEAD Algorithm Negotiation 4.1.5. AEAD Algorithm Negotiation
The AEAD Algorithm Negotiation record has a Record Type number of 4. The AEAD Algorithm Negotiation record has a Record Type number of 4.
Its body consists of a sequence of unsigned 16-bit integers in Its body consists of a sequence of unsigned 16-bit integers in
skipping to change at page 9, line 31 skipping to change at page 11, line 9
MUST support AEAD_AES_SIV_CMAC_256 [RFC5297] (Numeric Identifier 15). MUST support AEAD_AES_SIV_CMAC_256 [RFC5297] (Numeric Identifier 15).
That is, if the client includes AEAD_AES_SIV_CMAC_256 in its AEAD That is, if the client includes AEAD_AES_SIV_CMAC_256 in its AEAD
Algorithm Negotiation record, and the server accepts Protocol ID 0 Algorithm Negotiation record, and the server accepts Protocol ID 0
(NTPv4); in its NTS Next Protocol Negotiation record, then the (NTPv4); in its NTS Next Protocol Negotiation record, then the
server's AEAD Algorithm Negotiation record MUST NOT be empty. server's AEAD Algorithm Negotiation record MUST NOT be empty.
4.1.6. New Cookie for NTPv4 4.1.6. New Cookie for NTPv4
The New Cookie for NTPv4 record has a Record Type number of 5. The The New Cookie for NTPv4 record has a Record Type number of 5. The
contents of its body SHALL be implementation-defined and clients MUST contents of its body SHALL be implementation-defined and clients MUST
NOT attempt to interpret them. See Section 6 for a suggested NOT attempt to interpret them. See Section 7 for a suggested
construction. construction.
Clients MUST NOT send records of this type. Servers MUST send at Clients MUST NOT send records of this type. Servers MUST send at
least one record of this type, and SHOULD send eight of them, if they least one record of this type, and SHOULD send eight of them, if they
accept Protocol ID 0 (NTPv4) as a Next Protocol. The Critical Bit accept Protocol ID 0 (NTPv4) as a Next Protocol. The Critical Bit
SHOULD NOT be set. SHOULD NOT be set.
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
skipping to change at page 11, line 17 skipping to change at page 12, line 44
identifier extension field. The purpose of the cookie extension identifier extension field. The purpose of the cookie extension
field is to enable the server to offload storage of session state field is to enable the server to offload storage of session state
onto the client. The purpose of the unique-identifier extension onto the client. The purpose of the unique-identifier extension
field is to protect the client from replay attacks. field is to protect the client from replay attacks.
5.3. The Unique Identifier extension field 5.3. The Unique Identifier extension field
The Unique Identifier extension field has a Field Type of [[TBD2]]. The Unique Identifier extension field has a Field Type of [[TBD2]].
When the extension field is included in a client packet (mode 3), its When the extension field is included in a client packet (mode 3), its
body SHALL consist of a string of octets generated uniformly at body SHALL consist of a string of octets generated uniformly at
random. The string SHOULD be 32 octets long. When the extension random. The string MUST be at least 32 octets long. When the
field is included in a server packet (mode 4), its body SHALL contain extension field is included in a server packet (mode 4), its body
the same octet string as was provided in the client packet to which SHALL contain the same octet string as was provided in the client
the server is responding. Its use in modes other than client/server packet to which the server is responding. Its use in modes other
is not defined. than client/server is not defined.
The Unique Identifier extension field provides the client with a The Unique Identifier extension field provides the client with a
cryptographically strong means of detecting replayed packets. It MAY cryptographically strong means of detecting replayed packets. It MAY
also be used standalone, without NTS, in which case it provides the also be used standalone, without NTS, in which case it provides the
client with a means of detecting spoofed packets from off-path client with a means of detecting spoofed packets from off-path
attackers. Historically, NTP's origin timestamp field has played attackers. Historically, NTP's origin timestamp field has played
both these roles, but for cryptographic purposes this is suboptimal both these roles, but for cryptographic purposes this is suboptimal
because it is only 64 bits long and, depending on implementation because it is only 64 bits long and, depending on implementation
details, most of those bits may be predictable. In contrast, the details, most of those bits may be predictable. In contrast, the
Unique Identifier extension field enables a degree of Unique Identifier extension field enables a degree of
unpredictability and collision-resistance more consistent with unpredictability and collision-resistance more consistent with
cryptographic best practice. cryptographic best practice.
5.4. The NTS Cookie extension field 5.4. The NTS Cookie extension field
The NTS Cookie extension field has a Field Type of [[TBD3]]. Its The NTS Cookie extension field has a Field Type of [[TBD3]]. Its
purpose is to carry information which enables the server to recompute purpose is to carry information which enables the server to recompute
keys and other session state without having to store any per-client keys and other session state without having to store any per-client
state. The contents of its body SHALL be implementation-defined and state. The contents of its body SHALL be implementation-defined and
clients MUST NOT attempt to interpret them. See Section 6 for a clients MUST NOT attempt to interpret them. See Section 7 for a
suggested construction. The NTS Cookie extension field MUST NOT be suggested construction. The NTS Cookie extension field MUST NOT be
included in NTP packets whose mode is other than 3 (client) or 4 included in NTP packets whose mode is other than 3 (client) or 4
(server). (server).
5.5. The NTS Cookie Placeholder extension field 5.5. The NTS Cookie Placeholder extension field
The NTS Cookie Placeholder extension field has a Field Type of The NTS Cookie Placeholder extension field has a Field Type of
[[TBD4]]. When this extension field is included in a client packet [[TBD4]]. When this extension field is included in a client packet
(mode 3), it communicates to the server that the client wishes it to (mode 3), it communicates to the server that the client wishes it to
send additional cookies in its response. This extension field MUST send additional cookies in its response. This extension field MUST
skipping to change at page 13, line 22 skipping to change at page 14, line 48
accordance with RFC 7822 [RFC7822], and if multiple extension accordance with RFC 7822 [RFC7822], and if multiple extension
fields are present they SHALL be joined by concatenation. fields are present they SHALL be joined by concatenation.
N: The nonce SHALL be formed however required by the negotiated N: The nonce SHALL be formed however required by the negotiated
AEAD Algorithm. AEAD Algorithm.
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 6. 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: extension fields as displayed in Figure 3:
Exactly one Unique Identifier extension field, which MUST be Exactly one Unique Identifier extension field, which MUST be
authenticated, MUST NOT be encrypted, and whose contents MUST NOT authenticated, MUST NOT be encrypted, and whose contents MUST NOT
duplicate those of any previous request. duplicate those of any previous request.
Exactly one NTS Cookie extension field, which MUST be Exactly one NTS Cookie extension field, which MUST be
authenticated and MUST NOT be encrypted. The cookie MUST be one authenticated and MUST NOT be encrypted. The cookie MUST be one
which the server previously provided the client; it may have been which the server previously provided the client; it may have been
provided during the NTS-KE handshake or in response to a previous provided during the NTS-KE handshake or in response to a previous
NTS-protected NTP request. To protect client's privacy, the same NTS-protected NTP request. To protect client's privacy, the same
skipping to change at page 15, line 22 skipping to change at page 17, line 5
discarded without further processing. discarded without further processing.
Upon receiving an NTS NAK, the client MUST verify that the Unique Upon receiving an NTS NAK, the client MUST verify that the Unique
Identifier matches that of an outstanding request. If this check Identifier matches that of an outstanding request. If this check
fails, the packet MUST be discarded without further processing. If fails, the packet MUST be discarded without further processing. If
this check passes, the client SHOULD wait until the next poll for a this check passes, the client SHOULD wait until the next poll for a
valid NTS-protected response and if none is received, discard all valid NTS-protected response and if none is received, discard all
cookies and AEAD keys associated with the server which sent the NAK cookies and AEAD keys associated with the server which sent the NAK
and initiate a fresh NTS-KE handshake. and initiate a fresh NTS-KE handshake.
6. Suggested format for NTS cookies +---------------------------------------+
| - verify time request message |
| - generate time response message |
| - included NTPv4 extension fields |
| o Unique Identifier EF |
| o NTS Cookie EF |
| o <NTS Cookie EF> |
| |
| - generate AEAD tag of NTP message |
| - add NTS Authentication and |
| Encrypted Extension Fields EF |
| - transmit time request packet |
+-----------------+---------------------+
|
|
Server -------- --+---------------+-----+----------------------->
^ \
/ \
time request / \ time response
(mode 3) / \ (mode 4)
/ \
/ V
Client -----+---------------------------------+---------------->
| |
| |
| |
+-----------+----------------------+ +------+-----------------+
|- generate time request message | |- verify time response |
| - include NTPv4 Extension fields | | message |
| o Unique Identifier EF | |- extract cookie(s) |
| o NTS Cookie EF | |- time synchronization |
| o <NTS Cookie Placeholder EF> | | processing |
| | +------------------------+
|- generate AEAD tag of NTP message|
|- add NTS Authentication and |
| Encrypted Extension Fields EF |
|- transmit time request packet |
+----------------------------------+
Figure 3: NTS Time Synchronization Message
7. Suggested format for NTS cookies
This section is non-normative. It gives a suggested way for servers This section is non-normative. It gives a suggested way for servers
to construct NTS cookies. All normative requirements are stated in to construct NTS cookies. All normative requirements are stated in
Section 4.1.6 and Section 5.4. Section 4.1.6 and Section 5.4.
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.
skipping to change at page 16, line 42 skipping to change at page 19, line 17
To verify and decrypt a cookie provided by the client, first parse it To verify and decrypt a cookie provided by the client, first parse it
into its components `I`, `N`, and `C`. Use `I` to look up its into its components `I`, `N`, and `C`. Use `I` to look up its
decryption key `K`. If the key whose identifier is `I` has been decryption key `K`. If the key whose identifier is `I` has been
erased or never existed, decryption fails; reply with an NTS NAK. erased or never existed, decryption fails; reply with an NTS NAK.
Otherwise, attempt to decrypt and verify ciphertext `C` using key `K` Otherwise, attempt to decrypt and verify ciphertext `C` using key `K`
and nonce `N` with no associated data. If decryption or verification and nonce `N` with no associated data. If decryption or verification
fails, reply with an NTS NAK. Otherwise, parse out the contents of fails, reply with an NTS NAK. Otherwise, parse out the contents of
the resulting plaintext `P` to obtain the negotiated AEAD algorithm, the resulting plaintext `P` to obtain the negotiated AEAD algorithm,
S2C key, and C2S key. S2C key, and C2S key.
7. IANA Considerations 8. IANA Considerations
IANA is requested to allocate two entries, identical except for the IANA is requested to allocate two entries, identical except for the
Transport Protocol, in the Service Name and Transport Protocol Port Transport Protocol, in the Service Name and Transport Protocol Port
Number Registry as follows: Number Registry as follows:
Service Name: nts Service Name: nts
Transport Protocol: tcp, udp Transport Protocol: tcp, udp
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org> Contact: IETF Chair <chair@ietf.org>
Description: Network Time Security Description: Network Time Security
Reference: [[this memo]] Reference: [[this memo]]
Port Number: [[TBD1]], selected by IANA from the user port range Port Number: [[TBD1]], selected by IANA from the user port range
skipping to change at page 20, line 37 skipping to change at page 23, line 15
+--------+---------------------------------+---------------+ +--------+---------------------------------+---------------+
| Number | Description | Reference | | Number | Description | Reference |
+--------+---------------------------------+---------------+ +--------+---------------------------------+---------------+
| 0 | Unrecognized Critical Extension | [[this memo]] | | 0 | Unrecognized Critical Extension | [[this memo]] |
| 1 | Bad Request | [[this memo]] | | 1 | Bad Request | [[this memo]] |
+--------+---------------------------------+---------------+ +--------+---------------------------------+---------------+
The Network Time Security Warning Codes Registry SHALL initially be The Network Time Security Warning Codes Registry SHALL initially be
empty. empty.
8. Security considerations 9. Security considerations
8.1. Avoiding DDoS amplification 9.1. 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 distributed denial-of-service (DDoS) attacks by sending volume in distributed denial-of-service (DDoS) attacks by sending
them a request with a spoofed source IP. In recent years, attacks of them a request with a spoofed source IP. In recent years, attacks of
this nature have become an endemic nuisance. this nature have become an 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
ensuring that NTS-related extension fields included in server ensuring that NTS-related extension fields included in server
responses will be the same size as the NTS-related extension fields responses will be the same size as the NTS-related extension fields
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.
8.2. Initial verification of server certificates 9.2. 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 server is valid and that the X.509 certificate chain presented by the server is valid and
rooted in a trusted certificate authority. [RFC5280] and [RFC6125] rooted in a trusted certificate authority. [RFC5280] and [RFC6125]
specifies how such verification is to be performed in general. specifies how such verification is to be performed in general.
However, the expectation that the client does not yet have a However, the expectation that the client does not yet have a
correctly-set system clock at the time of certificate verification correctly-set system clock at the time of certificate verification
presents difficulties with verifying that the certificate is within presents difficulties with verifying that the certificate is within
its validity period, i.e., that the current time lies between the its validity period, i.e., that the current time lies between the
times specified in the certificate's notBefore and notAfter fields, times specified in the certificate's notBefore and notAfter fields,
skipping to change at page 22, line 7 skipping to change at page 24, line 34
them falls outside the validity period of the server's them falls outside the validity period of the server's
certificate. certificate.
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 ([RFC5905] a minority of servers, NTP's selection algorithm ([RFC5905]
section 11.2.1) will protect the client from accepting bad time section 11.2.1) will protect the client from accepting bad time
from the adversary-controlled servers. from the adversary-controlled servers.
8.3. Usage of NTP pools 9.3. Usage of NTP pools
Additional standardization work and infrastructure development is Additional standardization work and infrastructure development is
necessary before NTS can be used with public NTP server pools. necessary before NTS can be used with public NTP server pools.
First, a scheme will need to be specified for determining what First, a scheme will need to be specified for determining what
constitutes an acceptable certificate for a pool server, such as constitutes an acceptable certificate for a pool server, such as
establishing a value required to be contained in its Extended Key establishing a value required to be contained in its Extended Key
Usage attribute, and how to determine, given the DNS name of a pool, Usage attribute, and how to determine, given the DNS name of a pool,
what Subject Alternative Name to expect in the certificates of its what Subject Alternative Name to expect in the certificates of its
members. Implementing any such specification will necessitate members. Implementing any such specification will necessitate
infrastructure work: pool organizers will need to act as certificate infrastructure work: pool organizers will need to act as certificate
authorities, regularly monitor the behavior of servers to which authorities, regularly monitor the behavior of servers to which
certificates have been issued, and promptly revoke the certificate of certificates have been issued, and promptly revoke the certificate of
any server found to be serving incorrect time. any server found to be serving incorrect time.
8.4. Delay attacks 9.4. 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 23, line 5 skipping to change at page 25, line 32
will tolerate before concluding that the server is unsuitable for will tolerate before concluding that the server is unsuitable for
synchronization. The standard value for MAXDIST is one second, 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.
8.5. Random number generation 9.5. Random number generation
At various points in NTS, the generation of cryptographically secure At various points in NTS, the generation of cryptographically secure
random numbers is required. See [RFC4086] for guidelines concerning random numbers is required. Whenever this draft specifies the use of
random numbers, then cryptographically secure random number
generation MUST be used. See [RFC4086] for guidelines concerning
this topic. this topic.
9. Privacy Considerations 10. Privacy Considerations
9.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
network addresses (e.g. because said device moved between different network addresses (e.g. because said device moved between different
networks). In other words, unlinkability thwarts an attacker that networks). In other words, unlinkability thwarts an attacker that
seeks to link a new network address used by a device with a network seeks to link a new network address used by a device with a network
address that it was formerly using, because of recognizable data that address that it was formerly using, because of recognizable data that
the device persistently sends as part of an NTS-secured NTP the device persistently sends as part of an NTS-secured NTP
association. This is the justification for continually supplying the association. This is the justification for continually supplying the
client with fresh cookies, so that a cookie never represents client with fresh cookies, so that a cookie never represents
recognizable data in the sense outlined above. recognizable data in the sense outlined above.
NTS's unlinkability objective is merely to not leak any additional NTS's unlinkability objective is merely to not leak any additional
data that could be used to link a device's network address. NTS does data that could be used to link a device's network address. NTS does
not rectify legacy linkability issues that are already present in not rectify legacy linkability issues that are already present in
NTP. Thus, a client that requires unlinkability MUST also minimize NTP. Thus, a client that requires unlinkability must also minimize
information transmitted in a client query (mode 3) packet as information transmitted in a client query (mode 3) packet as
described in the draft [I-D.ietf-ntp-data-minimization]. described in the draft [I-D.ietf-ntp-data-minimization].
The unlinkability objective only holds for time synchronization The unlinkability objective only holds for time synchronization
traffic, as opposed to key exchange traffic. This implies that it traffic, as opposed to key exchange traffic. This implies that it
cannot be guaranteed for devices that function not only as time cannot be guaranteed for devices that function not only as time
clients, but also as time servers (because the latter can be clients, but also as time servers (because the latter can be
externally triggered to send authentication data). externally triggered to send authentication data).
It should also be noted that it could be possible to link devices It should also be noted that it could be possible to link devices
that operate as time servers from their time synchronization traffic, that operate as time servers from their time synchronization traffic,
using information exposed in (mode 4) server response packets (e.g. using information exposed in (mode 4) server response packets (e.g.
reference ID, reference time, stratum, poll). Also, devices that reference ID, reference time, stratum, poll). Also, devices that
respond to NTP control queries could be linked using the information respond to NTP control queries could be linked using the information
revealed by control queries. revealed by control queries.
9.2. Confidentiality 10.2. Confidentiality
NTS does not protect the confidentiality of information in NTP's NTS does not protect the confidentiality of information in NTP's
header fields. When clients implement header fields. When clients implement
[I-D.ietf-ntp-data-minimization], client packet headers do not [I-D.ietf-ntp-data-minimization], client packet headers do not
contain any information which the client could conceivably wish to contain any information which the client could conceivably wish to
keep secret: one field is random, and all others are fixed. keep secret: one field is random, and all others are fixed.
Information in server packet headers is likewise public: the origin Information in server packet headers is likewise public: the origin
timestamp is copied from the client's (random) transmit timestamp, timestamp is copied from the client's (random) transmit timestamp,
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.
10. Acknowledgements 11. Acknowledgements
The authors would like to thank Richard Barnes, Steven Bellovin, The authors would like to thank Richard Barnes, Steven Bellovin,
Scott Fluhrer, Sharon Goldberg, Russ Housley, Martin Langer, Miroslav Scott Fluhrer, Sharon Goldberg, Russ Housley, Martin Langer, Miroslav
Lichvar, Aanchal Malhotra, Dave Mills, Danny Mayer, Karen O'Donoghue, Lichvar, Aanchal Malhotra, Dave Mills, Danny Mayer, Karen O'Donoghue,
Eric K. Rescorla, Stephen Roettger, Kurt Roeckx, Kyle Rose, Rich Eric K. Rescorla, Stephen Roettger, Kurt Roeckx, Kyle Rose, Rich
Salz, Brian Sniffen, Susan Sons, Douglas Stebila, Harlan Stenn, Salz, Brian Sniffen, Susan Sons, Douglas Stebila, Harlan Stenn,
Martin Thomson, and Richard Welty for contributions to this document Martin Thomson, and Richard Welty for contributions to this document
and comments on the design of NTS. and comments on the design of NTS.
11. References 12. References
11.1. Normative References
[I-D.ietf-ntp-data-minimization] 12.1. Normative References
Franke, D. and A. Malhotra, "NTP Client Data
Minimization", draft-ietf-ntp-data-minimization-00 (work
in progress), May 2017.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
skipping to change at page 25, line 22 skipping to change at page 27, line 44
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
DOI 10.17487/RFC7465, February 2015, DOI 10.17487/RFC7465, February 2015,
<https://www.rfc-editor.org/info/rfc7465>. <https://www.rfc-editor.org/info/rfc7465>.
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
skipping to change at page 26, line 5 skipping to change at page 28, line 20
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS) Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension", Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015, RFC 7627, DOI 10.17487/RFC7627, September 2015,
<https://www.rfc-editor.org/info/rfc7627>. <https://www.rfc-editor.org/info/rfc7627>.
[RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4
(NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822,
March 2016, <https://www.rfc-editor.org/info/rfc7822>. March 2016, <https://www.rfc-editor.org/info/rfc7822>.
11.2. Informative References 12.2. Informative References
[I-D.ietf-ntp-data-minimization]
Franke, D. and A. Malhotra, "NTP Client Data
Minimization", draft-ietf-ntp-data-minimization-00 (work
in progress), May 2017.
[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, September 2012. and Communication, ISPCS 2012, pp. 1-6, 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>.
skipping to change at page 27, line 8 skipping to change at page 29, line 29
NTP Network Time Protocol [RFC5905] NTP Network Time Protocol [RFC5905]
NTS Network Time Security NTS Network Time Security
TLS Transport Layer Security TLS Transport Layer Security
Authors' Addresses Authors' Addresses
Daniel Fox Franke Daniel Fox Franke
Akamai Technologies, Inc.
150 Broadway
Cambridge, MA 02142
United States
Email: dafranke@akamai.com Email: dfoxfranke@akamai.com
URI: https://www.dfranke.us URI: https://www.dfranke.us
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. 38 change blocks. 
86 lines changed or deleted 160 lines changed or added

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