draft-ietf-ntp-using-nts-for-ntp-22.txt   draft-ietf-ntp-using-nts-for-ntp-23.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: August 16, 2020 K. Teichel Expires: September 4, 2020 K. Teichel
PTB PTB
M. Dansarie M. Dansarie
R. Sundblad R. Sundblad
Netnod Netnod
February 13, 2020 March 3, 2020
Network Time Security for the Network Time Protocol Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-22 draft-ietf-ntp-using-nts-for-ntp-23
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 August 16, 2020. This Internet-Draft will expire on September 4, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
7.2. TLS Application-Layer Protocol Negotiation (ALPN) 7.2. TLS Application-Layer Protocol Negotiation (ALPN)
Protocol IDs Registry . . . . . . . . . . . . . . . . . . 25 Protocol IDs Registry . . . . . . . . . . . . . . . . . . 25
7.3. TLS Exporter Labels Registry . . . . . . . . . . . . . . 26 7.3. TLS Exporter Labels Registry . . . . . . . . . . . . . . 26
7.4. NTP Kiss-o'-Death Codes Registry . . . . . . . . . . . . 26 7.4. NTP Kiss-o'-Death Codes Registry . . . . . . . . . . . . 26
7.5. NTP Extension Field Types Registry . . . . . . . . . . . 26 7.5. NTP Extension Field Types Registry . . . . . . . . . . . 26
7.6. Network Time Security Key Establishment Record Types 7.6. Network Time Security Key Establishment Record Types
Registry . . . . . . . . . . . . . . . . . . . . . . . . 27 Registry . . . . . . . . . . . . . . . . . . . . . . . . 27
7.7. Network Time Security Next Protocols Registry . . . . . . 28 7.7. Network Time Security Next Protocols Registry . . . . . . 28
7.8. Network Time Security Error and Warning Codes Registries 29 7.8. Network Time Security Error and Warning Codes Registries 29
8. Implementation Status - RFC EDITOR: REMOVE BEFORE PUBLICATION 30 8. Implementation Status - RFC EDITOR: REMOVE BEFORE PUBLICATION 30
8.1. Implementation 1 . . . . . . . . . . . . . . . . . . . . 30 8.1. Implementation 1 . . . . . . . . . . . . . . . . . . . . 31
8.1.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 30 8.1.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 31
8.1.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 31 8.1.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 31
8.1.3. Contact Information . . . . . . . . . . . . . . . . . 31 8.1.3. Contact Information . . . . . . . . . . . . . . . . . 31
8.1.4. Last Update . . . . . . . . . . . . . . . . . . . . . 31 8.1.4. Last Update . . . . . . . . . . . . . . . . . . . . . 31
8.2. Implementation 2 . . . . . . . . . . . . . . . . . . . . 31 8.2. Implementation 2 . . . . . . . . . . . . . . . . . . . . 31
8.2.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 31 8.2.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 31
8.2.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 31 8.2.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 32
8.2.3. Contact Information . . . . . . . . . . . . . . . . . 31 8.2.3. Contact Information . . . . . . . . . . . . . . . . . 32
8.2.4. Last Update . . . . . . . . . . . . . . . . . . . . . 31 8.2.4. Last Update . . . . . . . . . . . . . . . . . . . . . 32
8.3. Implementation 3 . . . . . . . . . . . . . . . . . . . . 32 8.3. Implementation 3 . . . . . . . . . . . . . . . . . . . . 32
8.3.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 32 8.3.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 32
8.3.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 32 8.3.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 32
8.3.3. Contact Information . . . . . . . . . . . . . . . . . 32 8.3.3. Contact Information . . . . . . . . . . . . . . . . . 32
8.3.4. Last Update . . . . . . . . . . . . . . . . . . . . . 32 8.3.4. Last Update . . . . . . . . . . . . . . . . . . . . . 32
8.4. Implementation 4 . . . . . . . . . . . . . . . . . . . . 32 8.4. Implementation 4 . . . . . . . . . . . . . . . . . . . . 33
8.4.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 32 8.4.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 33
8.4.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 33 8.4.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 33
8.4.3. Contact Information . . . . . . . . . . . . . . . . . 33 8.4.3. Contact Information . . . . . . . . . . . . . . . . . 33
8.4.4. Last Update . . . . . . . . . . . . . . . . . . . . . 33 8.4.4. Last Update . . . . . . . . . . . . . . . . . . . . . 33
8.5. Implementation 5 . . . . . . . . . . . . . . . . . . . . 33 8.5. Implementation 5 . . . . . . . . . . . . . . . . . . . . 33
8.5.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 33 8.5.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 33
8.5.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 33 8.5.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 34
8.5.3. Contact Information . . . . . . . . . . . . . . . . . 33 8.5.3. Contact Information . . . . . . . . . . . . . . . . . 34
8.5.4. Last Update . . . . . . . . . . . . . . . . . . . . . 33 8.5.4. Last Update . . . . . . . . . . . . . . . . . . . . . 34
8.6. Implementation 6 . . . . . . . . . . . . . . . . . . . . 33 8.6. Implementation 6 . . . . . . . . . . . . . . . . . . . . 34
8.6.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 34 8.6.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 34
8.6.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 34 8.6.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 34
8.6.3. Contact Information . . . . . . . . . . . . . . . . . 34 8.6.3. Contact Information . . . . . . . . . . . . . . . . . 34
8.6.4. Last Update . . . . . . . . . . . . . . . . . . . . . 34 8.6.4. Last Update . . . . . . . . . . . . . . . . . . . . . 34
8.7. Interoperability . . . . . . . . . . . . . . . . . . . . 34 8.7. Interoperability . . . . . . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35
9.1. Protected Modes . . . . . . . . . . . . . . . . . . . . . 34 9.1. Protected Modes . . . . . . . . . . . . . . . . . . . . . 35
9.2. Sensitivity to DDoS Attacks . . . . . . . . . . . . . . . 35 9.2. Sensitivity to DDoS Attacks . . . . . . . . . . . . . . . 35
9.3. Avoiding DDoS Amplification . . . . . . . . . . . . . . . 35 9.3. Avoiding DDoS Amplification . . . . . . . . . . . . . . . 36
9.4. Initial Verification of Server Certificates . . . . . . . 36 9.4. Initial Verification of Server Certificates . . . . . . . 36
9.5. Delay Attacks . . . . . . . . . . . . . . . . . . . . . . 37 9.5. Delay Attacks . . . . . . . . . . . . . . . . . . . . . . 37
9.6. Random Number Generation . . . . . . . . . . . . . . . . 37 9.6. Random Number Generation . . . . . . . . . . . . . . . . 38
9.7. NTS Stripping . . . . . . . . . . . . . . . . . . . . . . 38 9.7. NTS Stripping . . . . . . . . . . . . . . . . . . . . . . 38
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38
10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 38 10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 38
10.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 39 10.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 39
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
12.1. Normative References . . . . . . . . . . . . . . . . . . 39 12.1. Normative References . . . . . . . . . . . . . . . . . . 40
12.2. Informative References . . . . . . . . . . . . . . . . . 41 12.2. Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 42 Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
This memo specifies Network Time Security (NTS), a cryptographic This memo specifies Network Time Security (NTS), a cryptographic
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 8, line 6 skipping to change at page 8, line 6
3. TLS profile for Network Time Security 3. TLS profile for Network Time Security
Network Time Security makes use of TLS for NTS key establishment. Network Time Security makes use of TLS for NTS key establishment.
Since the NTS protocol is new as of this publication, no backward- Since the NTS protocol is new as of this publication, no backward-
compatibility concerns exist to justify using obsolete, insecure, or compatibility concerns exist to justify using obsolete, insecure, or
otherwise broken TLS features or versions. Implementations MUST otherwise broken TLS features or versions. Implementations MUST
conform with [RFC7525] or with a later revision of BCP 195. In conform with [RFC7525] or with a later revision of BCP 195. In
particular, failure to use cipher suites that provide forward secrecy particular, failure to use cipher suites that provide forward secrecy
will make all negotiated NTS keys recoverable by anyone that gains will make all negotiated NTS keys recoverable by anyone that gains
access to the NTS-KE server's private certificate. Furthermore: access to the NTS-KE server's private key. Furthermore:
Implementations MUST NOT negotiate TLS versions earlier than 1.2, Implementations MUST NOT negotiate TLS versions earlier than 1.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 12, line 25 skipping to change at page 12, line 25
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
network byte order, denoting Numeric Identifiers from the IANA AEAD network byte order, denoting Numeric Identifiers from the IANA AEAD
registry [RFC5116]. The Critical Bit MAY be set. Algorithms registry [IANA-AEAD]. The Critical Bit MAY be set.
If the NTS Next Protocol Negotiation record offers Protocol ID 0 (for If the NTS Next Protocol Negotiation record offers Protocol ID 0 (for
NTPv4), then this record MUST be included exactly once. Other NTPv4), then this record MUST be included exactly once. Other
protocols MAY require it as well. protocols MAY require it as well.
When included in a request, this record denotes which AEAD algorithms When included in a request, this record denotes which AEAD algorithms
the client is willing to use to secure the Next Protocol, in the client is willing to use to secure the Next Protocol, in
decreasing preference order. When included in a response, this decreasing preference order. When included in a response, this
record denotes which algorithm the server chooses to use. It is record denotes which algorithm the server chooses to use. It is
empty if the server supports none of the algorithms offered. In empty if the server supports none of the algorithms offered. In
skipping to change at page 13, line 22 skipping to change at page 13, line 22
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 the least one record of this type, and SHOULD send eight of them, if the
Next Protocol Negotiation response record contains Protocol ID 0 Next Protocol Negotiation response record contains Protocol ID 0
(NTPv4) and the AEAD Algorithm Negotiation response record is not (NTPv4) and the AEAD Algorithm Negotiation response record is not
empty. The Critical Bit SHOULD NOT be set. empty. The Critical Bit SHOULD NOT be set.
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 [ANSI.X3-4.1986] string. The Its body consists of an ASCII-encoded [ANSI.X3-4.1986] string. The
contents of the string SHALL be either an IPv4 address in dotted contents of the string SHALL be either an IPv4 address, an IPv6
decimal notation, an IPv6 address, or a fully qualified domain name address, or a fully qualified domain name (FQDN). IPv4 addresses
(FQDN). IPv6 addresses MUST conform to the "Text Representation of MUST be in dotted decimal notation. IPv6 addresses MUST conform to
Addresses" as specified in [RFC4291] and MUST NOT include zone the "Text Representation of Addresses" as specified in RFC 4291
identifiers [RFC6874]. If internationalized labels are needed in the [RFC4291] and MUST NOT include zone identifiers [RFC6874]. If a
domain name, the A-LABEL syntax specified in [RFC5891] MUST be used. label contains at least one non-ASCII character, an A-LABEL MUST be
used as defined in section 2.3.2.1 of RFC 5890 [RFC5890].
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.
When this record is sent by the client, it indicates that the client When this record is sent by the client, it indicates that the client
skipping to change at page 27, line 11 skipping to change at page 27, line 11
IANA is requested to allocate the following entries in the NTP IANA is requested to allocate the following entries in the NTP
Extension Field Types registry [RFC5905]: Extension Field Types registry [RFC5905]:
+----------+-----------------------------+--------------------------+ +----------+-----------------------------+--------------------------+
| Field | Meaning | Reference | | Field | Meaning | Reference |
| Type | | | | Type | | |
+----------+-----------------------------+--------------------------+ +----------+-----------------------------+--------------------------+
| [[TBD2]] | Unique Identifier | [[this memo]], | | [[TBD2]] | Unique Identifier | [[this memo]], |
| | | Section 5.3 | | | | Section 5.3 |
| [[TBD3]] | NTS Cookie | [[this memo]], Section | | [[TBD3]] | NTS Cookie | [[this memo]], |
| | | 5.4 | | | | Section 5.4 |
| [[TBD4]] | NTS Cookie Placeholder | [[this memo]], | | [[TBD4]] | NTS Cookie Placeholder | [[this memo]], |
| | | Section 5.5 | | | | Section 5.5 |
| [[TBD5]] | NTS Authenticator and | [[this memo]], Section | | [[TBD5]] | NTS Authenticator and | [[this memo]], |
| | Encrypted Extension Fields | 5.6 | | | Encrypted Extension Fields | Section 5.6 |
+----------+-----------------------------+--------------------------+ +----------+-----------------------------+--------------------------+
[[RFC EDITOR: REMOVE BEFORE PUBLICATION - The NTP WG suggests that
the following values be used:
Unique Identifier 0x0104
NTS Cookie 0x0204
Cookie Placeholder 0x0304
NTS Authenticator 0x0404]]
[[RFC EDITOR: Replace all instances of [[TBD2]], [[TBD3]], [[TBD4]], [[RFC EDITOR: Replace all instances of [[TBD2]], [[TBD3]], [[TBD4]],
and [[TBD5]] in this document with the respective IANA assignments. and [[TBD5]] in this document with the respective IANA assignments.]]
7.6. Network Time Security Key Establishment Record Types Registry 7.6. Network Time Security Key Establishment Record Types Registry
IANA is requested to create a new registry entitled "Network Time IANA is requested to create a new registry entitled "Network Time
Security Key Establishment Record Types". Entries SHALL have the Security Key Establishment Record Types". Entries SHALL have the
following fields: following fields:
Record Type Number (REQUIRED): An integer in the range 0-32767 Record Type Number (REQUIRED): An integer in the range 0-32767
inclusive. inclusive.
skipping to change at page 28, line 9 skipping to change at page 28, line 17
of the above ranges the Record Type Number should be allocated from. of the above ranges the Record Type Number should be allocated from.
Applicants MAY request a specific Record Type Number and such Applicants MAY request a specific Record Type Number and such
requests MAY be granted at the registrar's discretion. requests MAY be granted at the registrar's discretion.
The initial contents of this registry SHALL be as follows: The initial contents of this registry SHALL be as follows:
+-------------+-------------------------+---------------------------+ +-------------+-------------------------+---------------------------+
| Record Type | Description | Reference | | Record Type | Description | Reference |
| Number | | | | Number | | |
+-------------+-------------------------+---------------------------+ +-------------+-------------------------+---------------------------+
| 0 | End of Message | [[this memo]], Section | | 0 | End of Message | [[this memo]], |
| | | 4.1.1 | | | | Section 4.1.1 |
| 1 | NTS Next Protocol | [[this memo]], | | 1 | NTS Next Protocol | [[this memo]], |
| | Negotiation | Section 4.1.2 | | | Negotiation | Section 4.1.2 |
| 2 | Error | [[this memo]], Section | | 2 | Error | [[this memo]], |
| | | 4.1.3 | | | | Section 4.1.3 |
| 3 | Warning | [[this memo]], Section | | 3 | Warning | [[this memo]], |
| | | 4.1.4 | | | | Section 4.1.4 |
| 4 | AEAD Algorithm | [[this memo]], Section | | 4 | AEAD Algorithm | [[this memo]], |
| | Negotiation | 4.1.5 | | | Negotiation | Section 4.1.5 |
| 5 | New Cookie for NTPv4 | [[this memo]], Section | | 5 | New Cookie for NTPv4 | [[this memo]], |
| | | 4.1.6 | | | | Section 4.1.6 |
| 6 | NTPv4 Server | [[this memo]], Section | | 6 | NTPv4 Server | [[this memo]], |
| | Negotiation | 4.1.7 | | | Negotiation | Section 4.1.7 |
| 7 | NTPv4 Port Negotiation | [[this memo]], Section | | 7 | NTPv4 Port Negotiation | [[this memo]], |
| | | 4.1.8 | | | | Section 4.1.8 |
| 16384-32767 | Reserved for Private & | [[this memo]] | | 16384-32767 | Reserved for Private & | [[this memo]] |
| | Experimental Use | | | | Experimental Use | |
+-------------+-------------------------+---------------------------+ +-------------+-------------------------+---------------------------+
7.7. Network Time Security Next Protocols Registry 7.7. Network Time Security Next Protocols Registry
IANA is requested to create a new registry entitled "Network Time IANA is requested to create a new registry entitled "Network Time
Security Next Protocols". Entries SHALL have the following fields: Security Next Protocols". Entries SHALL have the following fields:
Protocol ID (REQUIRED): An integer in the range 0-65535 inclusive, Protocol ID (REQUIRED): An integer in the range 0-65535 inclusive,
skipping to change at page 33, line 49 skipping to change at page 34, line 21
8.5.3. Contact Information 8.5.3. Contact Information
Contact Watson Ladd: watson@cloudflare.com Contact Watson Ladd: watson@cloudflare.com
8.5.4. Last Update 8.5.4. Last Update
The implementation was updated 21. March 2019. The implementation was updated 21. March 2019.
8.6. Implementation 6 8.6. Implementation 6
Organization: Netnod Organization: Hacklunch, independent
Implementor: Michael Cardell Widerkrantz et. al. Implementor: Michael Cardell Widerkrantz, Daniel Lublin, Martin
Samuelsson et. al.
Maturity: Early proof of concept Maturity: interoperable client, immature server
8.6.1. Coverage 8.6.1. Coverage
NTS-KE client and server. NTS-KE client and server.
8.6.2. Licensing 8.6.2. Licensing
???? Licensing is ISC (details in LICENSE file).
The source code is available at: https://github.com/mchackorg/gonts Source code is available at: https://gitlab.com/hacklunch/ntsclient
8.6.3. Contact Information 8.6.3. Contact Information
Contact Michael Cardell Widerkrantz: mc@netnod.se Contact Michael Cardell Widerkrantz: mc@netnod.se
8.6.4. Last Update 8.6.4. Last Update
The implementation was updated 24. March 2019. The implementation was updated 6. February 2020.
8.7. Interoperability 8.7. Interoperability
The Interoperability tests distinguished between NTS key The Interoperability tests distinguished between NTS key
establishment protocol and NTS time exchange messages. For the establishment protocol and NTS time exchange messages. For the
implementations 1, 2, 3, and 4 pairwise interoperability of the NTS implementations 1, 2, 3, and 4 pairwise interoperability of the NTS
key establishment protocol and exchange of NTS protected NTP messages key establishment protocol and exchange of NTS protected NTP messages
have been verified successfully. The implementation 2 was able to have been verified successfully. The implementation 2 was able to
successfully perform the key establishment protocol against the successfully perform the key establishment protocol against the
server side of the implementation 5. server side of the implementation 5.
skipping to change at page 39, line 46 skipping to change at page 40, line 16
12. References 12. References
12.1. Normative References 12.1. Normative References
[ANSI.X3-4.1986] [ANSI.X3-4.1986]
American National Standards Institute, "Coded Character American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[IANA-AEAD]
IANA, "Authenticated Encryption with Associated Data
(AEAD) Parameters",
<https://www.iana.org/assignments/aead-parameters/>.
[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>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
skipping to change at page 40, line 22 skipping to change at page 40, line 43
[RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV)
Authenticated Encryption Using the Advanced Encryption Authenticated Encryption Using the Advanced Encryption
Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October
2008, <https://www.rfc-editor.org/info/rfc5297>. 2008, <https://www.rfc-editor.org/info/rfc5297>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>. March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Protocol", RFC 5891, Applications (IDNA): Definitions and Document Framework",
DOI 10.17487/RFC5891, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5891>. <https://www.rfc-editor.org/info/rfc5890>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
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
skipping to change at page 41, line 45 skipping to change at page 42, line 17
[I-D.ietf-ntp-data-minimization] [I-D.ietf-ntp-data-minimization]
Franke, D. and A. Malhotra, "NTP Client Data Franke, D. and A. Malhotra, "NTP Client Data
Minimization", draft-ietf-ntp-data-minimization-04 (work Minimization", draft-ietf-ntp-data-minimization-04 (work
in progress), March 2019. in progress), March 2019.
[Mizrahi] Mizrahi, T., "A game theoretic analysis of delay attacks [Mizrahi] Mizrahi, T., "A game theoretic analysis of delay attacks
against time synchronization protocols", in Proceedings against time synchronization protocols", in Proceedings
of Precision Clock Synchronization for Measurement Control of Precision Clock Synchronization for Measurement Control
and Communication, ISPCS 2012, pp. 1-6, September 2012. and Communication, ISPCS 2012, pp. 1-6, September 2012.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
skipping to change at page 43, line 4 skipping to change at page 43, line 16
AEAD Authenticated Encryption with Associated Data [RFC5116] AEAD Authenticated Encryption with Associated Data [RFC5116]
ALPN Application-Layer Protocol Negotiation [RFC7301] ALPN Application-Layer Protocol Negotiation [RFC7301]
C2S Client-to-server C2S Client-to-server
DDoS Distributed Denial-of-Service DDoS Distributed Denial-of-Service
EF Extension Field [RFC5905] EF Extension Field [RFC5905]
HKDF Hashed Message Authentication Code-based Key Derivation HKDF Hashed Message Authentication Code-based Key Derivation
Function [RFC5869] Function [RFC5869]
IANA Internet Assigned Numbers Authority
IP Internet Protocol
KoD Kiss-o'-Death [RFC5905] KoD Kiss-o'-Death [RFC5905]
NTP Network Time Protocol [RFC5905] NTP Network Time Protocol [RFC5905]
NTS Network Time Security NTS Network Time Security
NTS-KE Network Time Security Key Exchange NTS-KE Network Time Security Key Exchange
PRF Pseudorandom Function PRF Pseudorandom Function
S2C Server-to-client S2C Server-to-client
SCSV Signaling Cipher Suite Value [RFC7507] SCSV Signaling Cipher Suite Value [RFC7507]
TCP Transmission Control Protocol [RFC0793]
TLS Transport Layer Security [RFC8446] TLS Transport Layer Security [RFC8446]
UDP User Datagram Protocol [RFC0768]
Authors' Addresses Authors' Addresses
Daniel Fox Franke Daniel Fox Franke
Akamai Technologies Akamai Technologies
150 Broadway 150 Broadway
Cambridge, MA 02142 Cambridge, MA 02142
United States United States
Email: dafranke@akamai.com Email: dafranke@akamai.com
URI: https://www.dfranke.us URI: https://www.dfranke.us
skipping to change at page 44, line 26 skipping to change at page 44, line 26
Physikalisch-Technische Physikalisch-Technische
Bundesanstalt Bundesanstalt
Bundesallee 100 Bundesallee 100
Braunschweig D-38116 Braunschweig D-38116
Germany Germany
Phone: +49-(0)531-592-4471 Phone: +49-(0)531-592-4471
Email: kristof.teichel@ptb.de Email: kristof.teichel@ptb.de
Marcus Dansarie Marcus Dansarie
Sweden
Email: marcus@dansarie.se Email: marcus@dansarie.se
URI: https://orcid.org/0000-0001-9246-0263 URI: https://orcid.org/0000-0001-9246-0263
Ragnar Sundblad Ragnar Sundblad
Netnod Netnod
Sweden
Email: ragge@netnod.se Email: ragge@netnod.se
 End of changes. 36 change blocks. 
76 lines changed or deleted 78 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/