draft-ietf-ntp-using-nts-for-ntp-14.txt   draft-ietf-ntp-using-nts-for-ntp-15.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: April 25, 2019 K. Teichel Expires: June 20, 2019 K. Teichel
PTB PTB
M. Dansarie M. Dansarie
R. Sundblad R. Sundblad
Netnod Netnod
October 22, 2018 December 17, 2018
Network Time Security for the Network Time Protocol Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-14 draft-ietf-ntp-using-nts-for-ntp-15
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
establishment over TLS. The second handles encryption and establishment over TLS. The second handles encryption and
authentication during NTP time via extension fields in the NTP authentication during NTP time synchronization via extension fields
packets, and holds all required state only on the client via opaque in the NTP packets, and holds all required state only on the client
cookies. via opaque cookies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 25, 2019. This Internet-Draft will expire on June 20, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . 6 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 7
3. TLS profile for Network Time Security . . . . . . . . . . . . 7 3. TLS profile for Network Time Security . . . . . . . . . . . . 7
4. The NTS Key Establishment Protocol . . . . . . . . . . . . . 7 4. The NTS Key Establishment Protocol . . . . . . . . . . . . . 7
4.1. NTS-KE Record Types . . . . . . . . . . . . . . . . . . . 9 4.1. NTS-KE Record Types . . . . . . . . . . . . . . . . . . . 9
4.1.1. End of Message . . . . . . . . . . . . . . . . . . . 9 4.1.1. End of Message . . . . . . . . . . . . . . . . . . . 9
4.1.2. NTS Next Protocol Negotiation . . . . . . . . . . . . 10 4.1.2. NTS Next Protocol Negotiation . . . . . . . . . . . . 10
4.1.3. Error . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.3. Error . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.4. Warning . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.4. Warning . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.5. AEAD Algorithm Negotiation . . . . . . . . . . . . . 11 4.1.5. AEAD Algorithm Negotiation . . . . . . . . . . . . . 11
4.1.6. New Cookie for NTPv4 . . . . . . . . . . . . . . . . 11 4.1.6. New Cookie for NTPv4 . . . . . . . . . . . . . . . . 11
4.1.7. NTPv4 Server Negotiation . . . . . . . . . . . . . . 12 4.1.7. NTPv4 Server Negotiation . . . . . . . . . . . . . . 12
skipping to change at page 2, line 51 skipping to change at page 2, line 51
5.3. The Unique Identifier Extension Field . . . . . . . . . . 14 5.3. The Unique Identifier Extension Field . . . . . . . . . . 14
5.4. The NTS Cookie Extension Field . . . . . . . . . . . . . 15 5.4. The NTS Cookie Extension Field . . . . . . . . . . . . . 15
5.5. The NTS Cookie Placeholder Extension Field . . . . . . . 15 5.5. The NTS Cookie Placeholder Extension Field . . . . . . . 15
5.6. The NTS Authenticator and Encrypted Extension Fields 5.6. The NTS Authenticator and Encrypted Extension Fields
Extension Field . . . . . . . . . . . . . . . . . . . . . 15 Extension Field . . . . . . . . . . . . . . . . . . . . . 15
5.7. Protocol Details . . . . . . . . . . . . . . . . . . . . 17 5.7. Protocol Details . . . . . . . . . . . . . . . . . . . . 17
6. Suggested Format for NTS Cookies . . . . . . . . . . . . . . 22 6. Suggested Format for NTS Cookies . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7.1. Service Name and Transport Protocol Port Number Registry 23 7.1. Service Name and Transport Protocol Port Number Registry 23
7.2. TLS Application-Layer Protocol Negotiation (ALPN) 7.2. TLS Application-Layer Protocol Negotiation (ALPN)
Protocol IDs Registry . . . . . . . . . . . . . . . . . . 24 Protocol IDs Registry . . . . . . . . . . . . . . . . . . 23
7.3. TLS Exporter Labels Registry . . . . . . . . . . . . . . 24 7.3. TLS Exporter Labels Registry . . . . . . . . . . . . . . 24
7.4. NTP Kiss-o'-Death Codes Registry . . . . . . . . . . . . 24 7.4. NTP Kiss-o'-Death Codes Registry . . . . . . . . . . . . 24
7.5. NTP Extension Field Types Registry . . . . . . . . . . . 24 7.5. NTP Extension Field Types Registry . . . . . . . . . . . 24
7.6. Network Time Security Key Establishment Record Types 7.6. Network Time Security Key Establishment Record Types
Registry . . . . . . . . . . . . . . . . . . . . . . . . 25 Registry . . . . . . . . . . . . . . . . . . . . . . . . 25
7.7. Network Time Security Next Protocols Registry . . . . . . 26 7.7. Network Time Security Next Protocols Registry . . . . . . 26
7.8. Network Time Security Error and Warning Codes Registries 27 7.8. Network Time Security Error and Warning Codes Registries 27
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 28 8. Implementation Status - RFC EDITOR: REMOVE BEFORE PUBLICATION 28
8.1. Implementation PoC 1 . . . . . . . . . . . . . . . . . . 28 8.1. Implementation PoC 1 . . . . . . . . . . . . . . . . . . 28
8.1.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 28 8.1.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 28
8.1.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 29 8.1.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 29
8.1.3. Contact Information . . . . . . . . . . . . . . . . . 29 8.1.3. Contact Information . . . . . . . . . . . . . . . . . 29
8.1.4. Last Update . . . . . . . . . . . . . . . . . . . . . 29 8.1.4. Last Update . . . . . . . . . . . . . . . . . . . . . 29
8.2. Implementation PoC 2 . . . . . . . . . . . . . . . . . . 29 8.2. Implementation PoC 2 . . . . . . . . . . . . . . . . . . 29
8.2.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 29 8.2.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 29
8.2.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 29 8.2.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 29
8.2.3. Contact Information . . . . . . . . . . . . . . . . . 29 8.2.3. Contact Information . . . . . . . . . . . . . . . . . 29
8.2.4. Last Update . . . . . . . . . . . . . . . . . . . . . 29 8.2.4. Last Update . . . . . . . . . . . . . . . . . . . . . 29
8.3. Interoperability . . . . . . . . . . . . . . . . . . . . 30 8.3. Interoperability . . . . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9.1. Sensitivity to DDoS attacks . . . . . . . . . . . . . . . 30 9.1. Sensitivity to DDoS attacks . . . . . . . . . . . . . . . 30
9.2. Avoiding DDoS Amplification . . . . . . . . . . . . . . . 30 9.2. Avoiding DDoS Amplification . . . . . . . . . . . . . . . 30
9.3. Initial Verification of Server Certificates . . . . . . . 31 9.3. Initial Verification of Server Certificates . . . . . . . 31
9.4. Delay Attacks . . . . . . . . . . . . . . . . . . . . . . 32 9.4. Delay Attacks . . . . . . . . . . . . . . . . . . . . . . 32
9.5. Random Number Generation . . . . . . . . . . . . . . . . 32 9.5. Random Number Generation . . . . . . . . . . . . . . . . 33
9.6. NTS Stripping . . . . . . . . . . . . . . . . . . . . . . 33
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33
10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 33 10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 33
10.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 33 10.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 34
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . 34 12.1. Normative References . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . 36 12.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 37 Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This memo specifies Network Time Security (NTS), a cryptographic This memo specifies Network Time Security (NTS), a cryptographic
skipping to change at page 7, line 14 skipping to change at page 7, line 20
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. conform with [RFC7525] or with a later revision of BCP 195. In
Furthermore: 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 certificate. Furthermore:
Implementations MUST NOT negotiate TLS versions earlier than 1.2, Implementations MUST NOT negotiate TLS versions earlier than 1.2,
SHOULD negotiate TLS 1.3 [RFC8446] or later when possible, and MAY SHOULD negotiate TLS 1.3 [RFC8446] or later when possible, and MAY
refuse to negotiate any TLS version which has been superseded by a refuse to negotiate any TLS version which has been 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.
skipping to change at page 8, line 27 skipping to change at page 8, line 31
Figure 2: NTS-KE Record Format Figure 2: NTS-KE Record Format
The fields of an NTS-KE record are defined as follows: The fields of an NTS-KE record are defined as follows:
C (Critical Bit): Determines the disposition of unrecognized C (Critical Bit): Determines the disposition of unrecognized
Record Types. Implementations which receive a record with an Record Types. Implementations which receive a record with an
unrecognized Record Type MUST ignore the record if the Critical unrecognized Record Type MUST ignore the record if the Critical
Bit is 0 and MUST treat it as an error if the Critical Bit is 1. Bit is 0 and MUST treat it as an error if the Critical Bit is 1.
Record Type Number: A 15-bit integer in network byte order. The Record Type Number: A 15-bit integer in network byte order. The
semantics of record types 0-6 are specified in this memo. semantics of record types 0-7 are specified in this memo.
Additional type numbers SHALL be tracked through the IANA Network Additional type numbers SHALL be tracked through the IANA Network
Time Security Key Establishment Record Types registry. Time Security Key Establishment Record Types registry.
Body Length: The length of the Record Body field, in octets, as a Body Length: The length of the Record Body field, in octets, as a
16-bit integer in network byte order. Record bodies MAY have any 16-bit integer in network byte order. Record bodies MAY have any
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.
skipping to change at page 9, line 26 skipping to change at page 9, line 26
+-----------------+---------------------+ +-----------------+---------------------+
| |
| |
Server -----------+---------------+-----+-----------------------> Server -----------+---------------+-----+----------------------->
^ \ ^ \
/ \ / \
/ TLS application \ / TLS application \
/ data \ / data \
/ \ / \
/ 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 <NTP Server Negotiation> | | |
| o End of Message | | | | o End of Message | | |
skipping to change at page 14, line 23 skipping to change at page 14, line 23
encrypted. encrypted.
Some extension fields which are authenticated but not encrypted. Some extension fields which are authenticated but not encrypted.
An extension field which contains AEAD output (i.e., an An extension field which contains AEAD output (i.e., an
authentication tag and possible ciphertext). The corresponding authentication tag and possible ciphertext). The corresponding
plaintext, if non-empty, consists of some extension fields which plaintext, if non-empty, consists of some extension fields which
benefit from both encryption and authentication. benefit from both encryption and authentication.
Possibly, some additional extension fields which are neither Possibly, some additional extension fields which are neither
encrypted nor authenticated. These are discarded by the receiver. encrypted nor authenticated. In general, these are discarded by
the receiver.
Always included among the authenticated or authenticated-and- Always included among the authenticated or authenticated-and-
encrypted extension fields are a cookie extension field and a unique encrypted extension fields are a cookie extension field and a unique
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
skipping to change at page 15, line 46 skipping to change at page 15, line 47
checking its length, MUST be ignored by the server. checking its length, MUST be ignored by the server.
5.6. The NTS Authenticator and Encrypted Extension Fields Extension 5.6. The NTS Authenticator and Encrypted Extension Fields Extension
Field Field
The NTS Authenticator and Encrypted Extension Fields extension field The NTS Authenticator and Encrypted Extension Fields extension field
is the central cryptographic element of an NTS-protected NTP packet. is the central cryptographic element of an NTS-protected NTP packet.
Its Field Type is [[TBD5]]. It SHALL be formatted according to Its Field Type is [[TBD5]]. It SHALL be formatted according to
Figure 4 and include the following fields: Figure 4 and include the following fields:
Nonce length: Two octets in network byte order, giving the length Nonce Length: Two octets in network byte order, giving the length
of the Nonce field, excluding any padding, interpreted as an of the Nonce field, excluding any padding, interpreted as an
unsigned integer. unsigned integer.
Ciphertext Length: Two octets in network byte order, giving the Ciphertext Length: Two octets in network byte order, giving the
length of the Ciphertext field, excluding any padding, interpreted length of the Ciphertext field, excluding any padding, interpreted
as an unsigned integer. as an unsigned integer.
Nonce: A nonce as required by the negotiated AEAD Algorithm. The Nonce: A nonce as required by the negotiated AEAD Algorithm. The
field is zero-padded to a word (four octets) boundary. field is zero-padded to a word (four octets) boundary.
skipping to change at page 16, line 30 skipping to change at page 16, line 30
required to include additional zero-padding. The necessary length required to include additional zero-padding. The necessary length
of this field is specified below. of this field is specified below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce Length | Ciphertext Length | | Nonce Length | Ciphertext Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Nonce, including up to 3 bytes padding . . Nonce, including up to 3 octets padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Ciphertext, including up to 3 bytes padding . . Ciphertext, including up to 3 octets padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Additional Padding . . Additional Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 25 skipping to change at page 17, line 25
fields to be encrypted. The format of any such fields SHALL be in fields to be encrypted. The format of any such fields SHALL be in
accordance with RFC 7822 [RFC7822]. If multiple extension fields accordance with RFC 7822 [RFC7822]. If multiple extension fields
are present they SHALL be joined by concatenation. 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 purpose of the Additional Padding field is to ensure that servers The purpose of the Additional Padding field is to ensure that servers
can always choose a nonce whose length is adequate to ensure its can always choose a nonce whose length is adequate to ensure its
uniqueness, even if the client chooses a shorter one, and still uniqueness, even if the client chooses a shorter one, and still
ensure that the overall length of the server's response packet. does ensure that the overall length of the server's response packet does
not exceed the length of the request. For mode 4 (server) packets, not exceed the length of the request. For mode 4 (server) packets,
no Additional Padding field is ever required. For mode 3 (client) no Additional Padding field is ever required. For mode 3 (client)
packets, the length of the Additional Padding field SHALL be computed packets, the length of the Additional Padding field SHALL be computed
as follows. Let `N_LEN` be the padded length of the the Nonce field. as follows. Let `N_LEN` be the padded length of the the Nonce field.
Let `N_MAX` be, as specified by RFC 5116 [RFC5116], the maximum Let `N_MAX` be, as specified by RFC 5116 [RFC5116], the maximum
permitted nonce length for the negotiated AEAD algorithm. Let permitted nonce length for the negotiated AEAD algorithm. Let
`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.
skipping to change at page 18, line 9 skipping to change at page 18, line 9
extension fields as displayed in Figure 5: extension fields as displayed in Figure 5:
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 authenticated Exactly one NTS Cookie extension field which MUST be authenticated
and MUST NOT be encrypted. The cookie MUST be one which has been and MUST NOT be encrypted. The cookie MUST be one which has been
previously provided to the client; either from the key exchange previously provided to the client; either from the key exchange
server during the NTS-KE handshake or from the NTP server in server during the NTS-KE handshake or from the NTP server in
response to a previous NTS-protected NTP request. To protect the response to a previous NTS-protected NTP request.
client's privacy, the same cookie SHOULD NOT be included in
multiple requests. If the client does not have any cookies that
it has not already sent, it SHOULD initiate a re-run the NTS-KE
protocol.
Exactly one NTS Authenticator and Encrypted Extension Fields Exactly one NTS Authenticator and Encrypted Extension Fields
extension field, generated using an AEAD Algorithm and C2S key extension field, generated using an AEAD Algorithm and C2S key
established through NTS-KE. established through NTS-KE.
To protect the client's privacy, the client SHOULD avoid reusing a
cookie. If the client does not have any cookies that it has not
already sent, it SHOULD initiate a re-run the NTS-KE protocol. The
client MAY reuse cookies in order to prioritize resilience over
unlinkability. Which of the two that should be prioritized in any
particular case is dependent on the application and the user's
preference. Section 10.1 describes the privacy considerations of
this in further detail.
The client MAY include one or more NTS Cookie Placeholder extension The client MAY include one or more NTS Cookie Placeholder extension
fields which MUST be authenticated and MAY be encrypted. The number fields which MUST be authenticated and MAY be encrypted. The number
of NTS Cookie Placeholder extension fields that the client includes of NTS Cookie Placeholder extension fields that the client includes
SHOULD be such that if the client includes N placeholders and the SHOULD be such that if the client includes N placeholders and the
server sends back N+1 cookies, the number of unused cookies stored by server sends back N+1 cookies, the number of unused cookies stored by
the client will come to eight. The client SHOULD NOT include more the client will come to eight. The client SHOULD NOT include more
than seven NTS Cookie Placeholder extension fields in a request. than seven NTS Cookie Placeholder extension fields in a request.
When both the client and server adhere to all cookie-management When both the client and server adhere to all cookie-management
guidance provided in this memo, the number of placeholder extension guidance provided in this memo, the number of placeholder extension
fields will equal the number of dropped packets since the last fields will equal the number of dropped packets since the last
skipping to change at page 19, line 25 skipping to change at page 19, line 25
+-----------------+---------------------+ +-----------------+---------------------+
| |
| |
Server -----------+---------------+-----+-----------------------> Server -----------+---------------+-----+----------------------->
^ \ ^ \
/ \ / \
Time request / \ Time response Time request / \ Time response
(mode 3) / \ (mode 4) (mode 3) / \ (mode 4)
/ \ / \
/ V / V
Client -----+---------------------------------+----------------> Client -----+---------------------------------+----------------->
| | | |
| | | |
| | | |
+-----------+----------------------+ +------+-----------------+ +-----------+----------------------+ +------+-----------------+
|- Generate time request message | |- Verify time response | |- Generate time request message | |- Verify time response |
| - Include NTPv4 Extension fields | | message | | - Include NTPv4 Extension fields | | message |
| o Unique Identifier EF | |- Extract cookie(s) | | o Unique Identifier EF | |- Extract cookie(s) |
| o NTS Cookie EF | |- Time synchronization | | o NTS Cookie EF | |- Time synchronization |
| o <NTS Cookie Placeholder EF> | | processing | | o <NTS Cookie Placeholder EF> | | processing |
| | +------------------------+ | | +------------------------+
skipping to change at page 20, line 34 skipping to change at page 20, line 34
authenticated and encrypted. The number of NTS Cookie extension authenticated and encrypted. The number of NTS Cookie extension
fields included SHOULD be equal to, and MUST NOT exceed, one plus fields included SHOULD be equal to, and MUST NOT exceed, one plus
the number of valid NTS Cookie Placeholder extension fields the number of valid NTS Cookie Placeholder extension fields
included in the request. The cookies returned in those fields included in the request. The cookies returned in those fields
MUST be valid for use with the NTP server that sent them. They MUST be valid for use with the NTP server that sent them. They
MAY be valid for other NTP servers as well, but there is no way MAY be valid for other NTP servers as well, but there is no way
for the server to indicate this. for the server to indicate this.
We emphasize the contrast that NTS Cookie extension fields MUST NOT We emphasize the contrast that NTS Cookie extension fields MUST NOT
be encrypted when sent from client to server, but MUST be encrypted be encrypted when sent from client to server, but MUST be encrypted
from sent from server to client. The former is necessary in order when sent from server to client. The former is necessary in order
for the server to be able to recover the C2S and S2C keys, while the for the server to be able to recover the C2S and S2C keys, while the
latter is necessary to satisfy the unlinkability goals discussed in latter is necessary to satisfy the unlinkability goals discussed in
Section 10.1. We emphasize also that "encrypted" means encapsulated Section 10.1. We emphasize also that "encrypted" means encapsulated
within the the NTS Authenticator and Encrypted Extensions extension within the the NTS Authenticator and Encrypted Extensions extension
field. While the body of an NTS Cookie extension field will field. While the body of an NTS Cookie extension field will
generally consist of some sort of AEAD output (regardless of whether generally consist of some sort of AEAD output (regardless of whether
the recommendations of Section 6 are precisely followed), this is not the recommendations of Section 6 are precisely followed), this is not
sufficient to make the extension field "encrypted". sufficient to make the extension field "encrypted".
The server MAY include additional (non-NTS-related) extension fields The server MAY include additional (non-NTS-related) extension fields
skipping to change at page 21, line 26 skipping to change at page 21, line 26
negative-acknowledgment (NAK)". It MUST NOT include any NTS Cookie negative-acknowledgment (NAK)". It MUST NOT include any NTS Cookie
or NTS Authenticator and Encrypted Extension Fields extension fields. or 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 (i.e., packets containing the NTS Authenticator protected NTP packets (i.e., packets containing the NTS Authenticator
and Encrypted Extension Fields extension field), the client MUST and Encrypted Extension Fields extension field), the client MUST
verify that any KoD packets received from the server contain the verify that any KoD packets received from the server contain the
Unique Identifier extension field and that the Unique Identifier Unique Identifier extension field and that the Unique Identifier
matches that of an outstanding request. If this check fails, the matches that of an outstanding request. If this check fails, the
packet MUST be discarded without further processing. If this check packet MUST be discarded without further processing. If this check
passes, the client MUST comply with RFC 5095, Section 7.4 [RFC5905] passes, the client MUST comply with RFC 5905, Section 7.4 [RFC5905]
where required. A client MAY automatically re-run the NTS-KE where required. A client MAY automatically re-run the NTS-KE
protocol upon forced disassociation from an NTP server. In that protocol upon forced disassociation from an NTP server. In that
case, it MUST be able to detect and stop looping between the NTS-KE case, it MUST be able to detect and stop looping between the NTS-KE
and NTP servers. and NTP servers by rate limiting the retries using e.g. exponential
retry intervals.
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.
The client MAY reuse cookies in order to prioritize resilience over
unlinkability. Which of the two that should be prioritized in any
particular case is dependent on the application and the user's
preference. Section 10.1 describes the privacy considerations of
this in further detail.
To allow for NTP session restart when the NTS-KE server is To allow for NTP session restart when the NTS-KE server is
unavailable and to reduce NTS-KE server load, the client SHOULD keep unavailable and to reduce NTS-KE server load, the client SHOULD keep
at least one unused but recent cookie, AEAD keys, negotiated AEAD at least one unused but recent cookie, AEAD keys, negotiated AEAD
algorithm, and other necessary parameters on persistent storage. algorithm, and other necessary parameters on persistent storage.
This way, the client is able to resume the NTP session without This way, the client is able to resume the NTP session without
performing renewed NTS-KE negotiation. performing renewed NTS-KE negotiation.
6. Suggested Format for NTS Cookies 6. 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
skipping to change at page 27, line 50 skipping to change at page 27, line 50
| Number | Description | Reference | | Number | Description | Reference |
+-------------+------------------------------+----------------------+ +-------------+------------------------------+----------------------+
| 0 | Unrecognized Critical | [[this memo]], | | 0 | Unrecognized Critical | [[this memo]], |
| | Extension | Section 4.1.3 | | | Extension | Section 4.1.3 |
| 1 | Bad Request | [[this memo]], | | 1 | Bad Request | [[this memo]], |
| | | Section 4.1.3 | | | | Section 4.1.3 |
| 32768-65535 | Reserved for Private or | Reserved by [[this | | 32768-65535 | Reserved for Private or | Reserved by [[this |
| | Experimental Use | memo]] | | | Experimental Use | memo]] |
+-------------+------------------------------+----------------------+ +-------------+------------------------------+----------------------+
The Network Time Security Warning Codes Registry SHALL initally be The Network Time Security Warning Codes Registry SHALL initially be
empty except for the reserved range, i.e.: empty except for the reserved range, i.e.:
+-------------+-------------------------------+---------------------+ +-------------+-------------------------------+---------------------+
| Number | Description | Reference | | Number | Description | Reference |
+-------------+-------------------------------+---------------------+ +-------------+-------------------------------+---------------------+
| 32768-65535 | Reserved for Private or | Reserved by [[this | | 32768-65535 | Reserved for Private or | Reserved by [[this |
| | Experimental Use | memo]] | | | Experimental Use | memo]] |
+-------------+-------------------------------+---------------------+ +-------------+-------------------------------+---------------------+
8. Implementation Status 8. Implementation Status - RFC EDITOR: REMOVE BEFORE PUBLICATION
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 7942. Internet-Draft, and is based on a proposal described in RFC 7942.
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not supplied by IETF contributors. This is not intended as, and must not
skipping to change at page 29, line 21 skipping to change at page 29, line 21
8.1.3. Contact Information 8.1.3. Contact Information
Contact Martin Langer: mart.langer@ostfalia.de Contact Martin Langer: mart.langer@ostfalia.de
8.1.4. Last Update 8.1.4. Last Update
The implementation was updated 3rd May 2018. The implementation was updated 3rd May 2018.
8.2. Implementation PoC 2 8.2. Implementation PoC 2
Organization: tbd Organization: Akamai Technologies
Implementor: Daniel Fox Franke Implementor: Daniel Fox Franke
Maturity: Proof-of-Concept Prototype Maturity: Proof-of-Concept Prototype
This implementation was used to verify consistency and to ensure This implementation was used to verify consistency and to ensure
completeness of this specification. completeness of this specification.
8.2.1. Coverage 8.2.1. Coverage
skipping to change at page 32, line 12 skipping to change at page 32, line 12
can reasonably prompt the user to manually set an approximately- can reasonably prompt the user to manually set an approximately-
correct time if it appears to be needed. correct time if it appears to be needed.
Once the clock has been synchronized, periodically write the Once the clock has been synchronized, periodically write the
current system time to persistent storage. Do not accept any current system time to persistent storage. Do not accept any
certificate whose notAfter field is earlier than the last recorded certificate whose notAfter field is earlier than the last recorded
time. time.
Do not process time packets from servers if the time computed from Do not process time packets from servers if the time computed from
them falls outside the validity period of the server's them falls outside the validity period of the server's
certificate. certificate. However, clients should not perform a new NTS-KE
handshake solely based on the fact that the certificate used by
the NTS-KE server in a previous handshake has expired, if the
client has previously received valid NTS protected NTP replies
that lay within the certificate's validity time.
Use multiple time sources. The ability to pass off an expired Use multiple time sources. The ability to pass off an expired
certificate is only useful to an adversary who has compromised the certificate is only useful to an adversary who has compromised the
corresponding private key. If the adversary has compromised only corresponding private key. If the adversary has compromised only
a minority of servers, NTP's selection algorithm (RFC 5905 section a minority of servers, NTP's selection algorithm (RFC 5905 section
11.2.1 [RFC5905]) will protect the client from accepting bad time 11.2.1 [RFC5905]) will protect the client from accepting bad time
from the adversary-controlled servers. from the adversary-controlled servers.
9.4. Delay Attacks 9.4. Delay Attacks
skipping to change at page 33, line 7 skipping to change at page 33, line 13
the adversary is in control of only some of the paths. the adversary is in control of only some of the paths.
9.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. Whenever this draft specifies the use of random numbers is required. Whenever this draft specifies the use of
random numbers, cryptographically secure random number generation random numbers, cryptographically secure random number generation
MUST be used. RFC 4086 [RFC4086] contains guidelines concerning this MUST be used. RFC 4086 [RFC4086] contains guidelines concerning this
topic. topic.
9.6. NTS Stripping
Implementers must be aware of the possibility of "NTS stripping"
attacks, where an attacker tricks clients into reverting to plain
NTP. Naive client implementations might, for example, revert
automatically to plain NTP if the NTS-KE handshake fails. A man-in-
the-middle attacker can easily cause this to happen. Even clients
that already hold valid cookies can be vulnerable, since an attacker
can force a client to repeat the NTS-KE handshake by sending faked
NTP mode 4 replies with the NTS NAK kiss code. Forcing a client to
repeat the NTS-KE handshake can also be the first step in more
advanced attacks.
For the reasons described here, implementations SHOULD NOT revert
from NTS-protected to unprotected NTP with any server without
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
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
 End of changes. 31 change blocks. 
41 lines changed or deleted 65 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/