draft-ietf-ntp-using-nts-for-ntp-20.txt   draft-ietf-ntp-using-nts-for-ntp-21.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: January 9, 2020 K. Teichel Expires: August 2, 2020 K. Teichel
PTB PTB
M. Dansarie M. Dansarie
R. Sundblad R. Sundblad
Netnod Netnod
July 8, 2019 January 30, 2020
Network Time Security for the Network Time Protocol Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-20 draft-ietf-ntp-using-nts-for-ntp-21
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 January 9, 2020. This Internet-Draft will expire on August 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
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
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . 8 4. The NTS Key Establishment Protocol . . . . . . . . . . . . . 8
4.1. NTS-KE Record Types . . . . . . . . . . . . . . . . . . . 10 4.1. NTS-KE Record Types . . . . . . . . . . . . . . . . . . . 10
4.1.1. End of Message . . . . . . . . . . . . . . . . . . . 10 4.1.1. End of Message . . . . . . . . . . . . . . . . . . . 10
4.1.2. NTS Next Protocol Negotiation . . . . . . . . . . . . 11 4.1.2. NTS Next Protocol Negotiation . . . . . . . . . . . . 11
4.1.3. Error . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.3. Error . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.4. Warning . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.4. Warning . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.5. AEAD Algorithm Negotiation . . . . . . . . . . . . . 12 4.1.5. AEAD Algorithm Negotiation . . . . . . . . . . . . . 12
4.1.6. New Cookie for NTPv4 . . . . . . . . . . . . . . . . 12 4.1.6. New Cookie for NTPv4 . . . . . . . . . . . . . . . . 13
4.1.7. NTPv4 Server Negotiation . . . . . . . . . . . . . . 13 4.1.7. NTPv4 Server Negotiation . . . . . . . . . . . . . . 13
4.1.8. NTPv4 Port Negotiation . . . . . . . . . . . . . . . 13 4.1.8. NTPv4 Port Negotiation . . . . . . . . . . . . . . . 13
4.2. Key Extraction (generally) . . . . . . . . . . . . . . . 14 4.2. Key Extraction (generally) . . . . . . . . . . . . . . . 14
5. NTS Extension Fields for NTPv4 . . . . . . . . . . . . . . . 14 5. NTS Extension Fields for NTPv4 . . . . . . . . . . . . . . . 14
5.1. Key Extraction (for NTPv4) . . . . . . . . . . . . . . . 14 5.1. Key Extraction (for NTPv4) . . . . . . . . . . . . . . . 14
5.2. Packet Structure Overview . . . . . . . . . . . . . . . . 15 5.2. Packet Structure Overview . . . . . . . . . . . . . . . . 15
5.3. The Unique Identifier Extension Field . . . . . . . . . . 15 5.3. The Unique Identifier Extension Field . . . . . . . . . . 15
5.4. The NTS Cookie Extension Field . . . . . . . . . . . . . 16 5.4. The NTS Cookie Extension Field . . . . . . . . . . . . . 16
5.5. The NTS Cookie Placeholder Extension Field . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . 16 Extension Field . . . . . . . . . . . . . . . . . . . . . 17
5.7. Protocol Details . . . . . . . . . . . . . . . . . . . . 19 5.7. Protocol Details . . . . . . . . . . . . . . . . . . . . 19
6. Suggested Format for NTS Cookies . . . . . . . . . . . . . . 24 6. Suggested Format for NTS Cookies . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7.1. Service Name and Transport Protocol Port Number Registry 25 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 . . . . . . . . . . . . . . . . . . 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
skipping to change at page 6, line 9 skipping to change at page 6, line 9
establishing key material for use with the NTS Extension Fields establishing key material for use with the NTS Extension Fields
for NTPv4. It uses TLS to exchange keys, provide the client with for NTPv4. It uses TLS to exchange keys, provide the client with
an initial supply of cookies, and negotiate some additional an initial supply of cookies, and negotiate some additional
protocol options. After this exchange, the TLS channel is closed protocol options. After this exchange, the TLS channel is closed
with no per-client state remaining on the server side. with no per-client state remaining on the server side.
The typical protocol flow is as follows: The client connects to an The typical protocol flow is as follows: The client connects to an
NTS-KE server on the NTS TCP port and the two parties perform a TLS NTS-KE server on the NTS TCP port and the two parties perform a TLS
handshake. Via the TLS channel, the parties negotiate some handshake. Via the TLS channel, the parties negotiate some
additional protocol parameters and the server sends the client a additional protocol parameters and the server sends the client a
supply of cookies along with a list of one or more IP addresses to supply of cookies along with an IP address to the NTP server for
NTP servers for which the cookies are valid. The parties use TLS key which the cookies are valid. The parties use TLS key export
export [RFC5705] to extract key material which will be used in the [RFC5705] to extract key material which will be used in the next
next phase of the protocol. This negotiation takes only a single phase of the protocol. This negotiation takes only a single round
round trip, after which the server closes the connection and discards trip, after which the server closes the connection and discards all
all associated state. At this point the NTS-KE phase of the protocol associated state. At this point the NTS-KE phase of the protocol is
is complete. Ideally, the client never needs to connect to the NTS- complete. Ideally, the client never needs to connect to the NTS-KE
KE server again. server again.
Time synchronization proceeds with one of the indicated NTP servers Time synchronization proceeds with one of the indicated NTP servers
over the NTP UDP port. The client sends the server an NTP client over the NTP UDP port. The client sends the server an NTP client
packet which includes several extension fields. Included among these packet which includes several extension fields. Included among these
fields are a cookie (previously provided by the key exchange server) fields are a cookie (previously provided by the key exchange server)
and an authentication tag, computed using key material extracted from and an authentication tag, computed using key material extracted from
the NTS-KE handshake. The NTP server uses the cookie to recover this the NTS-KE handshake. The NTP server uses the cookie to recover this
key material and send back an authenticated response. The response key material and send back an authenticated response. The response
includes a fresh, encrypted cookie which the client then sends back includes a fresh, encrypted cookie which the client then sends back
in the clear in a subsequent request. (This constant refreshing of in the clear in a subsequent request. (This constant refreshing of
skipping to change at page 11, line 48 skipping to change at page 11, line 48
MUST respond with this error code if the request included a record MUST respond with this error code if the request included a record
which the server did not understand and which had its Critical Bit which the server did not understand and which had its Critical Bit
set. The client SHOULD NOT retry its request without set. The client SHOULD NOT retry its request without
modification. modification.
Error code 1 means "Bad Request". The server MUST respond with Error code 1 means "Bad Request". The server MUST respond with
this error if, upon the expiration of an implementation-defined this error if, upon the expiration of an implementation-defined
timeout, it has not yet received a complete and syntactically timeout, it has not yet received a complete and syntactically
well-formed request from the client. well-formed request from the client.
Error code 2 means "Internal Server Error". The server MUST
respond with this error if it is unable to respond properly due to
an internal condition.
4.1.4. Warning 4.1.4. Warning
The Warning record has a Record Type number of 3. Its body is The Warning record has a Record Type number of 3. Its body is
exactly two octets long, consisting of an unsigned 16-bit integer in exactly two octets long, consisting of an unsigned 16-bit integer in
network byte order, denoting a warning code. The Critical Bit MUST network byte order, denoting a warning code. The Critical Bit MUST
be set. be set.
Clients MUST NOT include Warning records in their request. If Clients MUST NOT include Warning records in their request. If
clients receive a server response which includes a Warning record, clients receive a server response which includes a Warning record,
they MAY discard any negotiated key material and abort without they MAY discard any negotiated key material and abort without
skipping to change at page 27, line 5 skipping to change at page 27, line 5
+------+---------------------------------------+--------------------+ +------+---------------------------------------+--------------------+
| NTSN | Network Time Security (NTS) negative- | [[this memo]], | | NTSN | Network Time Security (NTS) negative- | [[this memo]], |
| | acknowledgment (NAK) | Section 5.7 | | | acknowledgment (NAK) | Section 5.7 |
+------+---------------------------------------+--------------------+ +------+---------------------------------------+--------------------+
7.5. NTP Extension Field Types Registry 7.5. NTP Extension Field Types Registry
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]], | | [[TBD3]] | NTS Cookie | [[this memo]], Section |
| | | Section 5.4 | | | | 5.4 |
| [[TBD4]] | NTS Cookie Placeholder | [[this memo]], | | [[TBD4]] | NTS Cookie Placeholder | [[this memo]], |
| | | Section 5.5 | | | | Section 5.5 |
| [[TBD5]] | NTS Authenticator and Encrypted | [[this memo]], | | [[TBD5]] | NTS Authenticator and | [[this memo]], Section |
| | Extension Fields | Section 5.6 | | | Encrypted Extension Fields | 5.6 |
+----------+----------------------------------+---------------------+ +----------+-----------------------------+--------------------------+
[[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:
skipping to change at page 28, line 5 skipping to change at page 28, line 5
16384-32767: Private and Experimental Use 16384-32767: Private and Experimental Use
Applications for new entries SHALL specify the contents of the Applications for new entries SHALL specify the contents of the
Description, Set Critical Bit, and Reference fields as well as which Description, Set Critical Bit, and Reference fields as well as which
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]], | | 0 | End of Message | [[this memo]], Section |
| | | Section 4.1.1 | | | | 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]], | | 2 | Error | [[this memo]], Section |
| | | Section 4.1.3 | | | | 4.1.3 |
| 3 | Warning | [[this memo]], | | 3 | Warning | [[this memo]], Section |
| | | Section 4.1.4 | | | | 4.1.4 |
| 4 | AEAD Algorithm Negotiation | [[this memo]], | | 4 | AEAD Algorithm | [[this memo]], Section |
| | | Section 4.1.5 | | | Negotiation | 4.1.5 |
| 5 | New Cookie for NTPv4 | [[this memo]], | | 5 | New Cookie for NTPv4 | [[this memo]], Section |
| | | Section 4.1.6 | | | | 4.1.6 |
| 6 | NTPv4 Server Negotiation | [[this memo]], | | 6 | NTPv4 Server | [[this memo]], Section |
| | | Section 4.1.7 | | | Negotiation | 4.1.7 |
| 7 | NTPv4 Port Negotiation | [[this memo]], | | 7 | NTPv4 Port Negotiation | [[this memo]], Section |
| | | Section 4.1.8 | | | | 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,
functioning as an identifier. functioning as an identifier.
Protocol Name (REQUIRED): A short text string naming the protocol Protocol Name (REQUIRED): A short text string naming the protocol
skipping to change at page 29, line 46 skipping to change at page 29, line 46
The initial contents of the Network Time Security Error Codes The initial contents of the Network Time Security Error Codes
Registry SHALL be as follows: Registry SHALL be as follows:
+-------------+------------------------------+----------------------+ +-------------+------------------------------+----------------------+
| 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 |
| 2 | Internal Server Error | [[this memo]], |
| | | 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 initially 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]] |
+-------------+-------------------------------+---------------------+ +-------------+-------------------------------+---------------------+
skipping to change at page 43, line 18 skipping to change at page 43, line 18
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
Dieter Sibold Dieter Sibold
Physikalisch-Technische Bundesanstalt Physikalisch-Technische
Bundesanstalt
Bundesallee 100 Bundesallee 100
Braunschweig D-38116 Braunschweig D-38116
Germany Germany
Phone: +49-(0)531-592-8420 Phone: +49-(0)531-592-8420
Fax: +49-531-592-698420 Fax: +49-531-592-698420
Email: dieter.sibold@ptb.de Email: dieter.sibold@ptb.de
Kristof Teichel Kristof Teichel
Physikalisch-Technische Bundesanstalt Physikalisch-Technische
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
Email: marcus@dansarie.se Email: marcus@dansarie.se
 End of changes. 16 change blocks. 
55 lines changed or deleted 62 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/