draft-ietf-ntp-using-nts-for-ntp-24.txt   draft-ietf-ntp-using-nts-for-ntp-25.txt 
NTP Working Group D. Franke NTP Working Group D. Franke
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track D. Sibold Intended status: Standards Track D. Sibold
Expires: September 19, 2020 K. Teichel Expires: September 20, 2020 K. Teichel
PTB PTB
M. Dansarie M. Dansarie
R. Sundblad R. Sundblad
Netnod Netnod
March 18, 2020 March 19, 2020
Network Time Security for the Network Time Protocol Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-24 draft-ietf-ntp-using-nts-for-ntp-25
Abstract Abstract
This memo specifies Network Time Security (NTS), a mechanism for This memo specifies Network Time Security (NTS), a mechanism for
using Transport Layer Security (TLS) and Authenticated Encryption using Transport Layer Security (TLS) and Authenticated Encryption
with Associated Data (AEAD) to provide cryptographic security for the with Associated Data (AEAD) to provide cryptographic security for the
client-server mode of the Network Time Protocol (NTP). client-server mode of the Network Time Protocol (NTP).
NTS is structured as a suite of two loosely coupled sub-protocols. NTS is structured as a suite of two loosely coupled sub-protocols.
The first (NTS-KE) handles initial authentication and key The first (NTS-KE) handles initial authentication and key
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 19, 2020. This Internet-Draft will expire on September 20, 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 8, line 26 skipping to change at page 8, line 26
4. The NTS Key Establishment Protocol 4. The NTS Key Establishment Protocol
The NTS key establishment protocol is conducted via TCP port The NTS key establishment protocol is conducted via TCP port
[[TBD1]]. The two endpoints carry out a TLS handshake in conformance [[TBD1]]. The two endpoints carry out a TLS handshake in conformance
with Section 3, with the client offering (via an ALPN [RFC7301] with Section 3, with the client offering (via an ALPN [RFC7301]
extension), and the server accepting, an application-layer protocol extension), and the server accepting, an application-layer protocol
of "ntske/1". Immediately following a successful handshake, the of "ntske/1". Immediately following a successful handshake, the
client SHALL send a single request as Application Data encapsulated client SHALL send a single request as Application Data encapsulated
in the TLS-protected channel. Then, the server SHALL send a single in the TLS-protected channel. Then, the server SHALL send a single
response followed by a TLS "Close notify" alert and then discard the response. After sending their respective request and response, the
channel state. client and server SHALL send TLS "close_notify" alerts in accordance
with the TLS version in use, see RFC 8446 Section 6.1 [RFC8446].
The client's request and the server's response each SHALL consist of The client's request and the server's response each SHALL consist of
a sequence of records formatted according to Figure 2. The request a sequence of records formatted according to Figure 2. The request
and a non-error response each SHALL include exactly one NTS Next and a non-error response each SHALL include exactly one NTS Next
Protocol Negotiation record. The sequence SHALL be terminated by a Protocol Negotiation record. The sequence SHALL be terminated by a
"End of Message" record. The requirement that all NTS-KE messages be "End of Message" record. The requirement that all NTS-KE messages be
terminated by an End of Message record makes them self-delimiting. terminated by an End of Message record makes them self-delimiting.
Clients and servers MAY enforce length limits on requests and Clients and servers MAY enforce length limits on requests and
responses, however, servers MUST accept requests of at least 1024 responses, however, servers MUST accept requests of at least 1024
skipping to change at page 26, line 13 skipping to change at page 26, line 13
Reference: [[this memo]], Section 4 Reference: [[this memo]], Section 4
7.3. TLS Exporter Labels Registry 7.3. TLS Exporter Labels Registry
IANA is requested to allocate the following entry in the TLS Exporter IANA is requested to allocate the following entry in the TLS Exporter
Labels Registry [RFC5705]: Labels Registry [RFC5705]:
+--------------------+---------+-------------+---------------+------+ +--------------------+---------+-------------+---------------+------+
| Value | DTLS-OK | Recommended | Reference | Note | | Value | DTLS-OK | Recommended | Reference | Note |
+--------------------+---------+-------------+---------------+------+ +--------------------+---------+-------------+---------------+------+
| EXPORTER-network- | Y | N | [[this | | | EXPORTER-network- | Y | Y | [[this | |
| time-security/1 | | | memo]], | | | time-security/1 | | | memo]], | |
| | | | Section 4.2 | | | | | | Section 4.2 | |
+--------------------+---------+-------------+---------------+------+ +--------------------+---------+-------------+---------------+------+
7.4. NTP Kiss-o'-Death Codes Registry 7.4. NTP Kiss-o'-Death Codes Registry
IANA is requested to allocate the following entry in the registry of IANA is requested to allocate the following entry in the registry of
NTP Kiss-o'-Death Codes [RFC5905]: NTP Kiss-o'-Death Codes [RFC5905]:
+------+---------------------------------------+--------------------+ +------+---------------------------------------+--------------------+
skipping to change at page 27, line 37 skipping to change at page 27, line 37
The policy for allocation of new entries in this registry SHALL vary The policy for allocation of new entries in this registry SHALL vary
by the Record Type Number, as follows: by the Record Type Number, as follows:
0-1023: IETF Review 0-1023: IETF Review
1024-16383: Specification Required 1024-16383: Specification Required
16384-32767: Private and Experimental Use 16384-32767: Private and Experimental Use
Applications for new entries SHALL specify the contents of the
Description and Reference fields as well as which of the above ranges
the Record Type Number should be allocated from. Applicants MAY
request a specific Record Type Number and such 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]], | | 0 | End of Message | [[this memo]], |
| | | Section 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 |
 End of changes. 7 change blocks. 
13 lines changed or deleted 8 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/