draft-ietf-ntp-using-nts-for-ntp-17.txt   draft-ietf-ntp-using-nts-for-ntp-18.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 17, 2019 K. Teichel Expires: October 19, 2019 K. Teichel
PTB PTB
M. Dansarie M. Dansarie
R. Sundblad R. Sundblad
Netnod Netnod
February 13, 2019 April 17, 2019
Network Time Security for the Network Time Protocol Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-17 draft-ietf-ntp-using-nts-for-ntp-18
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 17, 2019. This Internet-Draft will expire on October 19, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4 1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . 8
4.1. NTS-KE Record Types . . . . . . . . . . . . . . . . . . . 9 4.1. NTS-KE Record Types . . . . . . . . . . . . . . . . . . . 10
4.1.1. End of Message . . . . . . . . . . . . . . . . . . . 9 4.1.1. End of Message . . . . . . . . . . . . . . . . . . . 10
4.1.2. NTS Next Protocol Negotiation . . . . . . . . . . . . 10 4.1.2. NTS Next Protocol Negotiation . . . . . . . . . . . . 11
4.1.3. Error . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.3. Error . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.4. Warning . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.4. Warning . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.5. AEAD Algorithm Negotiation . . . . . . . . . . . . . 11 4.1.5. AEAD Algorithm Negotiation . . . . . . . . . . . . . 12
4.1.6. New Cookie for NTPv4 . . . . . . . . . . . . . . . . 11 4.1.6. New Cookie for NTPv4 . . . . . . . . . . . . . . . . 12
4.1.7. NTPv4 Server Negotiation . . . . . . . . . . . . . . 12 4.1.7. NTPv4 Server Negotiation . . . . . . . . . . . . . . 13
4.1.8. NTPv4 Port Negotiation . . . . . . . . . . . . . . . 12 4.1.8. NTPv4 Port Negotiation . . . . . . . . . . . . . . . 13
4.2. Key Extraction (generally) . . . . . . . . . . . . . . . 13 4.2. Key Extraction (generally) . . . . . . . . . . . . . . . 14
5. NTS Extension Fields for NTPv4 . . . . . . . . . . . . . . . 13 5. NTS Extension Fields for NTPv4 . . . . . . . . . . . . . . . 14
5.1. Key Extraction (for NTPv4) . . . . . . . . . . . . . . . 13 5.1. Key Extraction (for NTPv4) . . . . . . . . . . . . . . . 14
5.2. Packet Structure Overview . . . . . . . . . . . . . . . . 14 5.2. Packet Structure Overview . . . . . . . . . . . . . . . . 15
5.3. The Unique Identifier Extension Field . . . . . . . . . . 14 5.3. The Unique Identifier Extension Field . . . . . . . . . . 15
5.4. The NTS Cookie Extension Field . . . . . . . . . . . . . 15 5.4. The NTS Cookie Extension Field . . . . . . . . . . . . . 16
5.5. The NTS Cookie Placeholder Extension Field . . . . . . . 15 5.5. The NTS Cookie Placeholder Extension Field . . . . . . . 16
5.6. The NTS Authenticator and Encrypted Extension Fields 5.6. The NTS Authenticator and Encrypted Extension Fields
Extension Field . . . . . . . . . . . . . . . . . . . . . 15 Extension Field . . . . . . . . . . . . . . . . . . . . . 16
5.7. Protocol Details . . . . . . . . . . . . . . . . . . . . 17 5.7. Protocol Details . . . . . . . . . . . . . . . . . . . . 19
6. Suggested Format for NTS Cookies . . . . . . . . . . . . . . 22 6. Suggested Format for NTS Cookies . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7.1. Service Name and Transport Protocol Port Number Registry 23 7.1. Service Name and Transport Protocol Port Number Registry 25
7.2. TLS Application-Layer Protocol Negotiation (ALPN) 7.2. TLS Application-Layer Protocol Negotiation (ALPN)
Protocol IDs Registry . . . . . . . . . . . . . . . . . . 23 Protocol IDs Registry . . . . . . . . . . . . . . . . . . 25
7.3. TLS Exporter Labels Registry . . . . . . . . . . . . . . 24 7.3. TLS Exporter Labels Registry . . . . . . . . . . . . . . 26
7.4. NTP Kiss-o'-Death Codes Registry . . . . . . . . . . . . 24 7.4. NTP Kiss-o'-Death Codes Registry . . . . . . . . . . . . 26
7.5. NTP Extension Field Types Registry . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . . . . . . 25 Registry . . . . . . . . . . . . . . . . . . . . . . . . 27
7.7. Network Time Security Next Protocols Registry . . . . . . 26 7.7. Network Time Security Next Protocols Registry . . . . . . 28
7.8. Network Time Security Error and Warning Codes Registries 27 7.8. Network Time Security Error and Warning Codes Registries 29
8. Implementation Status - RFC EDITOR: REMOVE BEFORE PUBLICATION 28 8. Implementation Status - RFC EDITOR: REMOVE BEFORE PUBLICATION 30
8.1. Implementation PoC 1 . . . . . . . . . . . . . . . . . . 28 8.1. Implementation 1 . . . . . . . . . . . . . . . . . . . . 30
8.1.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 28 8.1.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 30
8.1.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 29 8.1.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 31
8.1.3. Contact Information . . . . . . . . . . . . . . . . . 29 8.1.3. Contact Information . . . . . . . . . . . . . . . . . 31
8.1.4. Last Update . . . . . . . . . . . . . . . . . . . . . 29 8.1.4. Last Update . . . . . . . . . . . . . . . . . . . . . 31
8.2. Implementation PoC 2 . . . . . . . . . . . . . . . . . . 29 8.2. Implementation 2 . . . . . . . . . . . . . . . . . . . . 31
8.2.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 29 8.2.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 31
8.2.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 29 8.2.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 31
8.2.3. Contact Information . . . . . . . . . . . . . . . . . 29 8.2.3. Contact Information . . . . . . . . . . . . . . . . . 31
8.2.4. Last Update . . . . . . . . . . . . . . . . . . . . . 29 8.2.4. Last Update . . . . . . . . . . . . . . . . . . . . . 31
8.3. Interoperability . . . . . . . . . . . . . . . . . . . . 30 8.3. Implementation 3 . . . . . . . . . . . . . . . . . . . . 32
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8.3.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Sensitivity to DDoS attacks . . . . . . . . . . . . . . . 30 8.3.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 32
9.2. Avoiding DDoS Amplification . . . . . . . . . . . . . . . 30 8.3.3. Contact Information . . . . . . . . . . . . . . . . . 32
9.3. Initial Verification of Server Certificates . . . . . . . 31 8.3.4. Last Update . . . . . . . . . . . . . . . . . . . . . 32
9.4. Delay Attacks . . . . . . . . . . . . . . . . . . . . . . 32 8.4. Implementation 4 . . . . . . . . . . . . . . . . . . . . 32
9.5. Random Number Generation . . . . . . . . . . . . . . . . 33 8.4.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 32
9.6. NTS Stripping . . . . . . . . . . . . . . . . . . . . . . 33 8.4.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 33
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 8.4.3. Contact Information . . . . . . . . . . . . . . . . . 33
10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 33 8.4.4. Last Update . . . . . . . . . . . . . . . . . . . . . 33
10.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 34 8.5. Implementation 5 . . . . . . . . . . . . . . . . . . . . 33
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 8.5.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.5.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . . 35 8.5.3. Contact Information . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . 36 8.5.4. Last Update . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 37 8.6. Implementation 6 . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 8.6.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 34
8.6.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 34
8.6.3. Contact Information . . . . . . . . . . . . . . . . . 34
8.6.4. Last Update . . . . . . . . . . . . . . . . . . . . . 34
8.7. Interoperability . . . . . . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9.1. Sensitivity to DDoS attacks . . . . . . . . . . . . . . . 34
9.2. Avoiding DDoS Amplification . . . . . . . . . . . . . . . 35
9.3. Initial Verification of Server Certificates . . . . . . . 35
9.4. Delay Attacks . . . . . . . . . . . . . . . . . . . . . . 37
9.5. Random Number Generation . . . . . . . . . . . . . . . . 37
9.6. NTS Stripping . . . . . . . . . . . . . . . . . . . . . . 37
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38
10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 38
10.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 38
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
12.1. Normative References . . . . . . . . . . . . . . . . . . 39
12.2. Informative References . . . . . . . . . . . . . . . . . 41
Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 42
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 47 skipping to change at page 9, line 43
representable length and need not be aligned to a word boundary. representable length and need not be aligned to a word boundary.
Record Body: The syntax and semantics of this field SHALL be Record Body: The syntax and semantics of this field SHALL be
determined by the Record Type. determined by the Record Type.
For clarity regarding bit-endianness: the Critical Bit is the most- For clarity regarding bit-endianness: the Critical Bit is the most-
significant bit of the first octet. In C, given a network buffer significant bit of the first octet. In C, given a network buffer
`unsigned char b[]` containing an NTS-KE record, the critical bit is `unsigned char b[]` containing an NTS-KE record, the critical bit is
`b[0] >> 7` while the record type is `((b[0] & 0x7f) << 8) + b[1]`. `b[0] >> 7` while the record type is `((b[0] & 0x7f) << 8) + b[1]`.
Note that, although the Type-Length-Body format of an NTS-KE record
is similar to that of an NTP extension field, the semantics of the
length field differ. While the length subfield of an NTP extension
field gives the length of the entire extension field including the
type and length subfields, the length field of an NTS-KE record gives
just the length of the body.
Figure 3 provides a schematic overview of the key exchange. It Figure 3 provides a schematic overview of the key exchange. It
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 |
skipping to change at page 17, line 17 skipping to change at page 18, line 17
K: For packets sent from the client to the server, the C2S key K: For packets sent from the client to the server, the C2S key
SHALL be used. For packets sent from the server to the client, SHALL be used. For packets sent from the server to the client,
the S2C key SHALL be used. the S2C key SHALL be used.
A: The associated data SHALL consist of the portion of the NTP A: The associated data SHALL consist of the portion of the NTP
packet beginning from the start of the NTP header and ending at packet beginning from the start of the NTP header and ending at
the end of the last extension field which precedes the NTS the end of the last extension field which precedes the NTS
Authenticator and Encrypted Extension Fields extension field. Authenticator and Encrypted Extension Fields extension field.
P: The plaintext SHALL consist of all (if any) NTP extension P: the plaintext SHALL consist of all (if any) NTP extension
fields to be encrypted. The format of any such fields SHALL be in fields to be encrypted; if multiple extension fields are present
accordance with RFC 7822 [RFC7822]. If multiple extension fields they SHALL be joined by concatenation. Each such field SHALL be
are present they SHALL be joined by concatenation. formatted in accordance with RFC 7822 [RFC7822], except that,
contrary to the RFC 7822 requirement that fields have a minimum
length of 16 or 28 octets, encrypted extension fields MAY be
arbitrarily short (but still MUST be a multiple of 4 octets in
length).
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)
skipping to change at page 17, line 42 skipping to change at page 18, line 46
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.
Servers MUST enforce this requirement by discarding any packet which Servers MUST enforce this requirement by discarding any packet which
does not conform to it. does not conform to it.
Senders are always free to include more Additional Padding than
mandated by the above paragraph. Theoretically, it could be
necessary to do so in order to bring the extension field to the
minimum length required by [RFC7822]. This should never happen in
practice because any reasonable AEAD algorithm will have a nonce and
an authenticator long enough to bring the extension field to its
required length already. Nonetheless, implementers are advised to
explicitly handle this case and ensure that the extension field they
emit is of legal length.
The NTS Authenticator and Encrypted Extension Fields extension field The NTS Authenticator and Encrypted Extension Fields extension field
MUST NOT be included in NTP packets whose mode is other than 3 MUST NOT be included in NTP packets whose mode is other than 3
(client) or 4 (server). (client) or 4 (server).
5.7. Protocol Details 5.7. Protocol Details
A client sending an NTS-protected request SHALL include the following A client sending an NTS-protected request SHALL include the following
extension fields as displayed in Figure 5: extension fields as displayed in Figure 5:
Exactly one Unique Identifier extension field which MUST be Exactly one Unique Identifier extension field which MUST be
skipping to change at page 19, line 5 skipping to change at page 20, line 5
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
successful volley. successful volley.
In rare circumstances, it may be necessary to include fewer NTS
Cookie Placeholder extensions than recommended above in order to
prevent datagram fragmentation. When cookies adhere the format
recommended in Section 6 and the AEAD in use is the mandatory-to-
implement AEAD_AES_SIV_CMAC_256, senders can include a cookie and
seven placeholders and still have packet size fall comfortably below
1280 octets if no non-NTS-related extensions are used; 1280 octets is
the minimum prescribed MTU for IPv6 and is in practice also safe for
avoiding IPv4 fragmentation. Nonetheless, Nonetheless, senders
SHOULD include fewer cookies and placeholders than otherwise
indicated if doing so is necessary to prevent fragmentation.
+---------------------------------------+ +---------------------------------------+
| - Verify time request message | | - Verify time request message |
| - Generate time response message | | - Generate time response message |
| - Included NTPv4 extension fields | | - Included NTPv4 extension fields |
| o Unique Identifier EF | | o Unique Identifier EF |
| o NTS Authentication and | | o NTS Authentication and |
| Encrypted Extension Fields EF | | Encrypted Extension Fields EF |
| - NTS Cookie EF | | - NTS Cookie EF |
| - <NTS Cookie EF> | | - <NTS Cookie EF> |
| - Transmit time request packet | | - Transmit time request packet |
skipping to change at page 28, line 34 skipping to change at page 30, line 34
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
According to RFC 7942, "this will allow reviewers and working groups According to RFC 7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
8.1. Implementation PoC 1 8.1. Implementation 1
Organization: Ostfalia University of Applied Science Organization: Ostfalia University of Applied Science
Implementor: Martin Langer Implementor: Martin Langer
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. It also demonstrate completeness of this specification.
interoperability with NTP's client-server mode messages.
8.1.1. Coverage 8.1.1. Coverage
This implementation covers the complete specification. This implementation covers the complete specification.
8.1.2. Licensing 8.1.2. Licensing
The code is released under a Apache License 2.0 license. The code is released under a Apache License 2.0 license.
The source code is available at: https://gitlab.com/MLanger/nts/ The source code is available at: https://gitlab.com/MLanger/nts/
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 25. February 2019.
8.2. Implementation PoC 2 8.2. Implementation 2
Organization: Akamai Technologies Organization: Netnod
Implementor: Daniel Fox Franke Implementor: Christer Weinigel
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
This implementation provides the client and the server for the This implementation covers the complete specification.
initial TLS handshake and NTS key exchange. It provides the the
client part of the NTS protected NTP messages.
8.2.2. Licensing 8.2.2. Licensing
Public domain. The source code is available at: https://github.com/Netnod/nts-poc-
python.
The source code is available at: https://github.com/dfoxfranke/nts- See LICENSE file for details on licensing (BSD 2).
hackathon
8.2.3. Contact Information 8.2.3. Contact Information
Contact Daniel Fox Franke: dfoxfranke@gmail.com Contact Christer Weinigel: christer@weinigel.se
8.2.4. Last Update 8.2.4. Last Update
The implementation was updated 16th March 2018. The implementation was updated 31. January 2019.
8.3. Interoperability 8.3. Implementation 3
The Interoperability tests distinguished between NTS key exchange and Organization: Red Hat
NTS time exchange messages. For the NTS key exchange,
interoperability between the two implementations has been verified
successfully. Interoperability of NTS time exchange messages has
been verified successfully for the case that PoC 1 represents the
server and PoC 2 the client.
These tests successfully demonstrate that there are at least two Implementor: Miroslav Lichvar
Maturity: Prototype
This implementation was used to verify consistency and to ensure
completeness of this specification.
8.3.1. Coverage
This implementation covers the complete specification.
8.3.2. Licensing
Kicensing is GPLv2.
The source code is available at: https://github.com/mlichvar/chrony-
nts
8.3.3. Contact Information
Contact Miroslav Lichvar: mlichvar@redhat.com
8.3.4. Last Update
The implementation was updated 28. March 2019.
8.4. Implementation 4
Organization: NTPsec
Implementor: Hal Murray and NTPsec team
Maturity:Looking for testers. Servers running at
ntp1.glypnod.com:123 and ntp2.glypnod.com:123
This implementation was used to verify consistency and to ensure
completeness of this specification.
8.4.1. Coverage
This implementation covers the complete specification.
8.4.2. Licensing
The source code is available at: https://gitlab.com/NTPsec/ntpsec.
Licensing details in LICENSE.
8.4.3. Contact Information
Contact Hal Murray: hmurray@megapathdsl.net, devel@ntpsec.org
8.4.4. Last Update
The implementation was updated 2019-Apr-10.
8.5. Implementation 5
Organization: Cloudflare
Implementor: Watson Ladd
Maturity:
This implementation was used to verify consistency and to ensure
completeness of this specification.
8.5.1. Coverage
This implementation covers the server side of the NTS specification.
8.5.2. Licensing
The source code is available at: https://github.com/wbl/nts-rust
Licensing is ISC (details see LICENSE.txt file).
8.5.3. Contact Information
Contact Watson Ladd: watson@cloudflare.com
8.5.4. Last Update
The implementation was updated 21. March 2019.
8.6. Implementation 6
Organization: Netnod
Implementor: Michael Cardell Widerkrantz et. al.
Maturity: Early proof of concept
8.6.1. Coverage
NTS-KE client and server.
8.6.2. Licensing
????
The source code is available at: https://github.com/mchackorg/gonts
8.6.3. Contact Information
Contact Michael Cardell Widerkrantz: mc@netnod.se
8.6.4. Last Update
The implementation was updated 24. March 2019.
8.7. Interoperability
The Interoperability tests distinguished between NTS key
establishment protocol and NTS time exchange messages. For the
implementations 1, 2, 3, and 4 pairwise interoperability of the NTS
key establishment protocol and exchange of NTS protected NTP messages
have been verified successfully. The implementation 2 was able to
successfully perform the key establishment protocol against the
server side of the implementation 5.
These tests successfully demonstrate that there are at least four
running implementations of this draft which are able to interoperate. running implementations of this draft which are able to interoperate.
9. Security Considerations 9. Security Considerations
9.1. Sensitivity to DDoS attacks 9.1. Sensitivity to DDoS attacks
The introduction of NTS brings with it the introduction of asymmetric The introduction of NTS brings with it the introduction of asymmetric
cryptography to NTP. Asymmetric cryptography is necessary for cryptography to NTP. Asymmetric cryptography is necessary for
initial server authentication and AEAD key extraction. Asymmetric initial server authentication and AEAD key extraction. Asymmetric
cryptosystems are generally orders of magnitude slower than their cryptosystems are generally orders of magnitude slower than their
skipping to change at page 36, line 49 skipping to change at page 41, line 21
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-ntp-data-minimization] [I-D.ietf-ntp-data-minimization]
Franke, D. and A. Malhotra, "NTP Client Data Franke, D. and A. Malhotra, "NTP Client Data
Minimization", draft-ietf-ntp-data-minimization-02 (work Minimization", draft-ietf-ntp-data-minimization-04 (work
in progress), July 2018. 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, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
skipping to change at page 37, line 43 skipping to change at page 42, line 14
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[Shpiner] "Multi-path Time Protocols", in Proceedings of IEEE [Shpiner] Mizrahi, A. S. Y. R. A. T., "Multi-path Time Protocols",
International Symposium on Precision Clock Synchronization in Proceedings of IEEE International Symposium on
for Measurement, Control and Communication (ISPCS), Precision Clock Synchronization for Measurement, Control
September 2013. and Communication (ISPCS), September 2013.
Appendix A. Terms and Abbreviations Appendix A. Terms and Abbreviations
AEAD Authenticated Encryption with Associated Data [RFC5116] AEAD Authenticated Encryption with Associated Data [RFC5116]
ALPN Application-Layer Protocol Negotiation [RFC7301] ALPN Application-Layer Protocol Negotiation [RFC7301]
C2S Client-to-server C2S Client-to-server
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 IANA Internet Assigned Numbers Authority
 End of changes. 30 change blocks. 
97 lines changed or deleted 264 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/