draft-ietf-ntp-using-nts-for-ntp-27.txt   draft-ietf-ntp-using-nts-for-ntp-28.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 25, 2020 K. Teichel Expires: September 26, 2020 K. Teichel
PTB PTB
M. Dansarie M. Dansarie
R. Sundblad R. Sundblad
Netnod Netnod
March 24, 2020 March 25, 2020
Network Time Security for the Network Time Protocol Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-27 draft-ietf-ntp-using-nts-for-ntp-28
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 25, 2020. This Internet-Draft will expire on September 26, 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 6, line 16 skipping to change at page 6, line 16
establishing key material for use with the NTS Extension Fields establishing key material for use with the NTS Extension Fields
for NTPv4. It uses TLS to establish keys, provide the client with for NTPv4. It uses TLS to establish keys, provide the client with
an initial supply of cookies, and negotiate some additional an initial supply of cookies, and negotiate some additional
protocol options. After this, the TLS channel is closed with no protocol options. After this, the TLS channel is closed with no
per-client state remaining on the server side. per-client state remaining on the server side.
The typical protocol flow is as follows: The client connects to an The typical protocol flow is as follows: The client connects to an
NTS-KE server on the NTS TCP port and the two parties perform a TLS NTS-KE server on the NTS TCP port and the two parties perform a TLS
handshake. Via the TLS channel, the parties negotiate some handshake. Via the TLS channel, the parties negotiate some
additional protocol parameters and the server sends the client a additional protocol parameters and the server sends the client a
supply of cookies along with an address of an NTP server for which supply of cookies along with an address and port of an NTP server for
the cookies are valid. The parties use TLS key export [RFC5705] to which the cookies are valid. The parties use TLS key export
extract key material which will be used in the next phase of the [RFC5705] to extract key material which will be used in the next
protocol. This negotiation takes only a single round trip, after phase of the protocol. This negotiation takes only a single round
which the server closes the connection and discards all associated trip, after which the server closes the connection and discards all
state. At this point the NTS-KE phase of the protocol is complete. associated state. At this point the NTS-KE phase of the protocol is
Ideally, the client never needs to connect to the NTS-KE server complete. Ideally, the client never needs to connect to the NTS-KE
again. server again.
Time synchronization proceeds with the indicated NTP server over the Time synchronization proceeds with the indicated NTP server. The
NTP UDP port. The client sends the server an NTP client packet which client sends the server an NTP client packet which includes several
includes several extension fields. Included among these fields are a extension fields. Included among these fields are a cookie
cookie (previously provided by the key establishment server) and an (previously provided by the key establishment server) and an
authentication tag, computed using key material extracted from the authentication tag, computed using key material extracted from the
NTS-KE handshake. The NTP server uses the cookie to recover this key NTS-KE handshake. The NTP server uses the cookie to recover this key
material and send back an authenticated response. The response material and send back an authenticated response. The response
includes a fresh, encrypted cookie which the client then sends back includes a fresh, encrypted cookie which the client then sends back
in the clear in a subsequent request. (This constant refreshing of in the clear in a subsequent request. (This constant refreshing of
cookies is necessary in order to achieve NTS's unlinkability goal.) cookies is necessary in order to achieve NTS's unlinkability goal.)
Figure 1 provides an overview of the high-level interaction between Figure 1 provides an overview of the high-level interaction between
the client, the NTS-KE server, and the NTP server. Note that the the client, the NTS-KE server, and the NTP server. Note that the
cookies' data format and the exchange of secrets between NTS-KE and cookies' data format and the exchange of secrets between NTS-KE and
skipping to change at page 10, line 16 skipping to change at page 10, line 16
displays the protocol steps to be performed by the NTS client and displays the protocol steps to be performed by the NTS client and
server and record types to be exchanged. server and record types to be exchanged.
+---------------------------------------+ +---------------------------------------+
| - Verify client request message. | | - Verify client request message. |
| - Extract TLS key material. | | - Extract TLS key material. |
| - Generate KE response message. | | - Generate KE response message. |
| - Include Record Types: | | - Include Record Types: |
| o NTS Next Protocol Negotiation | | o NTS Next Protocol Negotiation |
| o AEAD Algorithm Negotiation | | o AEAD Algorithm Negotiation |
| o NTP Server Negotiation | | o <NTPv4 Server Negotiation> |
| o <NTPv4 Port Negotiation> |
| o New Cookie for NTPv4 | | o New Cookie for NTPv4 |
| o <New Cookie for NTPv4> | | o <New Cookie for NTPv4> |
| o End of Message | | o End of Message |
+-----------------+---------------------+ +-----------------+---------------------+
| |
| |
Server -----------+---------------+-----+-----------------------> Server -----------+---------------+-----+----------------------->
^ \ ^ \
/ \ / \
/ TLS application \ / TLS application \
skipping to change at page 10, line 38 skipping to change at page 10, line 39
/ \ / \
/ V / V
Client -----+---------------------------------+-----------------> Client -----+---------------------------------+----------------->
| | | |
| | | |
| | | |
+-----------+----------------------+ +------+-----------------+ +-----------+----------------------+ +------+-----------------+
|- Generate KE request message. | |- Verify server response| |- Generate KE request message. | |- Verify server response|
| - Include Record Types: | | message. | | - Include Record Types: | | message. |
| o NTS Next Protocol Negotiation | |- Extract cookie(s). | | o NTS Next Protocol Negotiation | |- Extract cookie(s). |
| o AEAD Algorithm Negotiation | | | | o AEAD Algorithm Negotiation | +------------------------+
| o <NTP Server Negotiation> | | | | o <NTPv4 Server Negotiation> |
| o End of Message | | | | o <NTPv4 Port Negotiation> |
+----------------------------------+ +------------------------+ | o End of Message |
+----------------------------------+
Figure 3: NTS Key Establishment Messages Figure 3: NTS Key Establishment 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 a zero- The End of Message record has a Record Type number of 0 and a zero-
skipping to change at page 13, line 30 skipping to change at page 13, line 30
4.1.7. NTPv4 Server Negotiation 4.1.7. NTPv4 Server Negotiation
The NTPv4 Server Negotiation record has a Record Type number of 6. The NTPv4 Server Negotiation record has a Record Type number of 6.
Its body consists of an ASCII-encoded [RFC0020] string. The contents Its body consists of an ASCII-encoded [RFC0020] string. The contents
of the string SHALL be either an IPv4 address, an IPv6 address, or a of the string SHALL be either an IPv4 address, an IPv6 address, or a
fully qualified domain name (FQDN). IPv4 addresses MUST be in dotted fully qualified domain name (FQDN). IPv4 addresses MUST be in dotted
decimal notation. IPv6 addresses MUST conform to the "Text decimal notation. IPv6 addresses MUST conform to the "Text
Representation of Addresses" as specified in RFC 4291 [RFC4291] and Representation of Addresses" as specified in RFC 4291 [RFC4291] and
MUST NOT include zone identifiers [RFC6874]. If a label contains at MUST NOT include zone identifiers [RFC6874]. If a label contains at
least one non-ASCII character, it is an internationalized domain name least one non-ASCII character, it is an internationalized domain name
and an A-LABEL MUST be used as defined in section 2.3.2.1 of RFC 5890 and an A-LABEL MUST be used as defined in Section 2.3.2.1 of RFC 5890
[RFC5890]. If the record contains a domain name, the recipient MUST [RFC5890]. If the record contains a domain name, the recipient MUST
treat it as a FQDN, e.g. by making sure it ends with a dot. treat it as a FQDN, e.g. by making sure it ends with a dot.
When NTPv4 is negotiated as a Next Protocol and this record is sent When NTPv4 is negotiated as a Next Protocol and this record is sent
by the server, the body specifies the hostname or IP address of the by the server, the body specifies the hostname or IP address of the
NTPv4 server with which the client should associate and which will NTPv4 server with which the client should associate and which will
accept the supplied cookies. If no record of this type is sent, the accept the supplied cookies. If no record of this type is sent, the
client SHALL interpret this as a directive to associate with an NTPv4 client SHALL interpret this as a directive to associate with an NTPv4
server at the same IP address as the NTS-KE server. Servers MUST NOT server at the same IP address as the NTS-KE server. Servers MUST NOT
send more than one record of this type. send more than one record of this type.
skipping to change at page 14, line 45 skipping to change at page 14, line 45
A mechanism for not unnecessarily overloading the NTS-KE server is A mechanism for not unnecessarily overloading the NTS-KE server is
REQUIRED when retrying the key establishment process due to protocol, REQUIRED when retrying the key establishment process due to protocol,
communication, or other errors. The exact workings of this will be communication, or other errors. The exact workings of this will be
dependent on the application and operational experience gathered over dependent on the application and operational experience gathered over
time. Until such experience is available, this memo provides the time. Until such experience is available, this memo provides the
following suggestion. following suggestion.
Clients SHOULD use exponential backoff, with an initial and minimum Clients SHOULD use exponential backoff, with an initial and minimum
retry interval of 10 seconds, a maximum retry interval of 5 days, and retry interval of 10 seconds, a maximum retry interval of 5 days, and
a base of 1.5. Thus, the minimum interval in seconds, t, for the nth a base of 1.5. Thus, the minimum interval in seconds, `t`, for the
retry is calculated with nth retry is calculated with
t = min(10 * 1.5^(n-1), 432000). t = min(10 * 1.5^(n-1), 432000).
Clients MUST NOT reset the retry interval until they have performed a Clients MUST NOT reset the retry interval until they have performed a
successful key establishment with the NTS-KE server, followed by a successful key establishment with the NTS-KE server, followed by a
successful use of the negotiated next protocol with the keys and data successful use of the negotiated next protocol with the keys and data
established during that transaction. established during that transaction.
4.3. Key Extraction (generally) 4.3. Key Extraction (generally)
skipping to change at page 15, line 20 skipping to change at page 15, line 20
be extracted using the HMAC-based Extract-and-Expand Key Derivation be extracted using 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]. Inputs to the exporter function are to be constructed in [RFC8446]. Inputs to the exporter function are to be constructed in
a manner specific to the negotiated Next Protocol. However, all a manner specific to the negotiated Next Protocol. However, all
protocols which utilize NTS-KE MUST conform to the following two protocols which utilize NTS-KE MUST conform to the following two
rules: rules:
The disambiguating label string [RFC5705] MUST be "EXPORTER- The disambiguating label string [RFC5705] MUST be "EXPORTER-
network-time-security". network-time-security".
The per-association context value MUST be provided and MUST begin The per-association context value [RFC5705] MUST be provided and
with the two-octet Protocol ID which was negotiated as a Next MUST begin with the two-octet Protocol ID which was negotiated as
Protocol. a Next 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 HKDF defined in RFC 8446, key. These keys SHALL be computed with the HKDF defined in RFC 8446,
Section 7.5 [RFC8446] using the following inputs. Section 7.5 [RFC8446] using the following inputs.
The disambiguating label string [RFC5705] SHALL be "EXPORTER- The disambiguating label string [RFC5705] SHALL be "EXPORTER-
network-time-security". network-time-security".
The context value SHALL consist of the following five octets: The per-association context value [RFC5705] 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.
Implementations wishing to derive additional keys for private or Implementations wishing to derive additional keys for private or
skipping to change at page 16, line 39 skipping to change at page 16, line 39
storage of session state onto the client. The purpose of the unique storage of session state onto the client. The purpose of the unique
identifier extension field is to protect the client from replay identifier extension field is to protect the client from replay
attacks. attacks.
5.3. The Unique Identifier Extension Field 5.3. The Unique Identifier Extension Field
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 has cryptographically strong means of detecting replayed packets. It has
a Field Type of [[TBD2]]. When the extension field is included in a a Field Type of [[TBD2]]. When the extension field is included in a
client packet (mode 3), its body SHALL consist of a string of octets client packet (mode 3), its body SHALL consist of a string of octets
generated uniformly at random. The string MUST be at least 32 octets generated by a cryptographically secure random number generator
long. When the extension field is included in a server packet (mode [RFC4086]. The string MUST be at least 32 octets long. When the
4), its body SHALL contain the same octet string as was provided in extension field is included in a server packet (mode 4), its body
the client packet to which the server is responding. All server SHALL contain the same octet string as was provided in the client
packets generated by NTS-implementing servers in response to client packet to which the server is responding. All server packets
packets containing this extension field MUST also contain this field generated by NTS-implementing servers in response to client packets
with the same content as in the client's request. The field's use in containing this extension field MUST also contain this field with the
modes other than client-server is not defined. same content as in the client's request. The field's use in modes
other than client-server is not defined.
This extension field MAY also be used standalone, without NTS, in This extension field MAY also be used standalone, without NTS, in
which case it provides the client with a means of detecting spoofed which case it provides the client with a means of detecting spoofed
packets from off-path attackers. Historically, NTP's origin packets from off-path attackers. Historically, NTP's origin
timestamp field has played both these roles, but for cryptographic timestamp field has played both these roles, but for cryptographic
purposes this is suboptimal because it is only 64 bits long and, purposes this is suboptimal because it is only 64 bits long and,
depending on implementation details, most of those bits may be depending on implementation details, most of those bits may be
predictable. In contrast, the Unique Identifier extension field predictable. In contrast, the Unique Identifier extension field
enables a degree of unpredictability and collision resistance more enables a degree of unpredictability and collision resistance more
consistent with cryptographic best practice. consistent with cryptographic best practice.
skipping to change at page 24, line 28 skipping to change at page 24, line 28
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 secret with the client. Servers should randomly generate and store a secret
master AEAD key `K`. Servers should additionally choose a non-secret, master AEAD key `K`. Servers should additionally choose a non-secret,
unique 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 previously generated keys that should now be securely erase any previously generated keys that should now be
expired. Servers should continue to accept any cookie generated expired. Servers should continue to accept any cookie generated
using keys that they have not yet erased, even if those keys are no using keys that they have not yet erased, even if those keys are no
longer current. Erasing old keys provides for forward secrecy, longer current. Erasing old keys provides for forward secrecy,
limiting the scope of what old information can be stolen if a master limiting the scope of what old information can be stolen if a master
key is somehow compromised. Holding on to a limited number of old key is somehow compromised. Holding on to a limited number of old
keys allows clients to seamlessly transition from one generation to keys allows clients to seamlessly transition from one generation to
the next without having to perform a new NTS-KE handshake. the next without having to perform a new NTS-KE handshake.
 End of changes. 14 change blocks. 
37 lines changed or deleted 41 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/