• Identity: Through the use of a X.509 public key infrastructure, implementations can cryptographically establish the identity of the parties they are communicating with.
• Authentication: Implementations can cryptographically verify that any time synchronization packets are authentic, i.e., that they were produced by an identified party and have not been modified in transit.
• Confidentiality: Although basic time synchronization data is considered nonconfidential and sent in the clear, NTS includes support for encrypting NTP extension fields.
• Replay prevention: Client implementations can detect when a received time synchronization packet is a replay of a previous packet.
• Request-response consistency: Client implementations can verify that a time synchronization packet received from a server was sent in response to a particular request from the client.
• Unlinkability: For mobile clients, NTS will not leak any information additional to NTP which would permit a passive adversary to determine that two packets sent over different networks came from the same client.
• Non-amplification: Implementations (especially server implementations) can avoid acting as distributed denial-of-service (DDoS) amplifiers by never responding to a request with a packet larger than the request packet.
• Scalability: Server implementations can serve large numbers of clients without having to retain any client-specific state.
• Performance: NTS must not significantly degrade the quality of the time transfer. The encryption and authentication used when actually transferring time should be lightweight (see Section 5.7 of [RFC 7384]).

AEAD

[RFC 5116]

ALPN

[RFC 7301]

C2S

Client-to-server

DoS

Denial-of-Service

DDoS

Distributed Denial-of-Service

EF

[RFC 5905]

HKDF

[RFC 5869]

KoD

[RFC 5905]

NTP

[RFC 5905]

NTS

Network Time Security

NTS NAK

NTS negative-acknowledgment

NTS-KE

Network Time Security Key Establishment

S2C

Server-to-client

TLS

[RFC 8446]

• The "NTS Extension Fields for NTPv4" define a collection of NTP extension fields for cryptographically securing NTPv4 using previously established key material. They are suitable for securing client-server mode because the server can implement them without retaining per-client state. All state is kept by the client and provided to the server in the form of an encrypted cookie supplied with each request. On the other hand, the NTS Extension Fields are suitable only for client-server mode because only the client, and not the server, is protected from replay.
• The "NTS Key Establishment" protocol (NTS-KE) is a mechanism for establishing key material for use with the NTS Extension Fields for NTPv4. It uses TLS to establish keys, to provide the client with an initial supply of cookies, and to negotiate some additional protocol options. After this, the TLS channel is closed with no per-client state remaining on the server side.

                                                     +--------------+
                                                     |              |
                                                 +-> | NTP Server 1 |
                                                 |   |              |
                           Shared cookie         |   +--------------+
+---------------+      encryption parameters     |   +--------------+
|               |    (Implementation dependent)  |   |              |
| NTS-KE Server | <------------------------------+-> | NTP Server 2 |
|               |                                |   |              |
+---------------+                                |   +--------------+
       ^                                         |          .
       |                                         |          .
       | 1. Negotiate parameters,                |          .
       |    receive initial cookie               |   +--------------+
       |    supply, generate AEAD keys,          |   |              |
       |    and receive NTP server IP            +-> | NTP Server N |
       |    addresses using "NTS Key                 |              |
       |    Establishment" protocol.                 +--------------+
       |                                                    ^
       |                                                    |
       |             +----------+                           |
       |             |          |                           |
       +-----------> |  Client  | <-------------------------+
                     |          |  2. Perform authenticated
                     +----------+     time synchronization
                                      and generate new
                                      cookies using "NTS
                                      Extension Fields for
                                      NTPv4".

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|         Record Type         |          Body Length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                           Record Body                         .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C (Critical Bit):

Determines the disposition of unrecognized Record Types. Implementations which receive a record with an unrecognized Record Type MUST ignore the record if the Critical Bit is 0 and MUST treat it as an error if the Critical Bit is 1 (see Section 4.1.3).

Record Type Number:

A 15-bit integer in network byte order. The semantics of Record Types 0-7 are specified in this memo. Additional type numbers SHALL be tracked through the IANA "Network Time Security Key Establishment Record Types" registry.

Body Length:

The length of the Record Body field, in octets, as a 16-bit integer in network byte order. Record bodies MAY have any representable length and need not be aligned to a word boundary.

Record Body:

The syntax and semantics of this field SHALL be determined by the Record Type.

                +---------------------------------------+
                | - Verify client request message.      |
                | - Extract TLS key material.           |
                | - Generate KE response message.       |
                |   - Include Record Types:             |
                |       o NTS Next Protocol Negotiation |
                |       o AEAD Algorithm Negotiation    |
                |       o <NTPv4 Server Negotiation>    |
                |       o <NTPv4 Port Negotiation>      |
                |       o New Cookie for NTPv4          |
                |       o <New Cookie for NTPv4>        |
                |       o End of Message                |
                +-----------------+---------------------+
                                  |
                                  |
Server -----------+---------------+-----+----------------------->
                  ^                      \
                 /                        \
                /    TLS application       \
               /     data                   \
              /                              \
             /                                V
Client -----+---------------------------------+----------------->
            |                                 |
            |                                 |
            |                                 |
+-----------+----------------------+   +------+-----------------+
|- Generate KE request message.    |   |- Verify server response|
| - Include Record Types:          |   |  message.              |
|  o NTS Next Protocol Negotiation |   |- Extract cookie(s).    |
|  o AEAD Algorithm Negotiation    |   +------------------------+
|  o <NTPv4 Server Negotiation>    |
|  o <NTPv4 Port Negotiation>      |
|  o End of Message                |
+----------------------------------+

• Error code 0 means "Unrecognized Critical Record". The server MUST respond with this error code if the request included a record that the server did not understand and that had its Critical Bit set. The client SHOULD NOT retry its request without modification.
• Error code 1 means "Bad Request". The server MUST respond with this error if the request is not complete and syntactically well-formed, or, upon the expiration of an implementation-defined timeout, it has not yet received such a request. The client SHOULD NOT retry its request without modification.
• 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. The client MAY retry its request.

• t = min(10 * 1.5^n-1, 432000).

• The [RFC 5705] MUST be "EXPORTER-network-time-security".
• The [RFC 5705] MUST be provided and MUST begin with the two-octet Protocol ID that was negotiated as a Next Protocol.

• The [RFC 5705] SHALL be "EXPORTER-network-time-security".
• The [RFC 5705] SHALL consist of the following five octets:
  • The first two octets SHALL be zero (the Protocol ID for NTPv4).
  • The next two octets SHALL be the Numeric Identifier of the negotiated AEAD algorithm in network byte order.
  • The final octet SHALL be 0x00 for the C2S key and 0x01 for the S2C key.

• The usual 48-octet NTP header, which is authenticated but not encrypted.
• Some extension fields, which are authenticated but not encrypted.
• An extension field that contains AEAD output (i.e., an authentication tag and possible ciphertext). The corresponding plaintext, if non-empty, consists of some extension fields that benefit from both encryption and authentication.
• Possibly, some additional extension fields that are neither encrypted nor authenticated. In general, these are discarded by the receiver.

Nonce Length:

Two octets in network byte order, giving the length of the Nonce field, excluding any padding, interpreted as an unsigned integer.

Ciphertext Length:

Two octets in network byte order, giving the length of the Ciphertext field, excluding any padding, interpreted as an unsigned integer.

Nonce:

A nonce as required by the negotiated AEAD algorithm. The end of the field is zero-padded to a word (four octets) boundary.

Ciphertext:

The output of the negotiated AEAD algorithm. The structure of this field is determined by the negotiated algorithm, but it typically contains an authentication tag in addition to the actual ciphertext. The end of the field is zero-padded to a word (four octets) boundary.

Additional Padding:

Clients that use a nonce length shorter than the maximum allowed by the negotiated AEAD algorithm may be required to include additional zero-padding. The necessary length of this field is specified below.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Nonce Length         |      Ciphertext Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.          Nonce, including up to 3 octets padding              .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.        Ciphertext, including up to 3 octets padding           .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                      Additional Padding                       .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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, the S2C key SHALL be used.

A:

The associated data SHALL consist of the portion of the NTP packet beginning from the start of the NTP header and ending at the end of the last extension field that precedes the NTS Authenticator and Encrypted Extension Fields extension field.

P:

The plaintext SHALL consist of all (if any) NTP extension fields to be encrypted; if multiple extension fields are present, they SHALL be joined by concatenation. Each such field SHALL be formatted in accordance with [RFC 7822], 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 AEAD algorithm.

• Exactly one Unique Identifier extension field that MUST be authenticated, MUST NOT be encrypted, and whose contents MUST be the output of a [RFC 4086].
• Exactly one NTS Cookie extension field that MUST be authenticated and MUST NOT be encrypted. The cookie MUST be one which has been previously provided to the client, either from the key establishment server during the NTS-KE handshake or from the NTP server in response to a previous NTS-protected NTP request.
• Exactly one NTS Authenticator and Encrypted Extension Fields extension field, generated using an AEAD algorithm and C2S key established through NTS-KE.

                +---------------------------------------+
                | - Verify time request message.        |
                | - Generate time response message.     |
                |   - Included NTPv4 extension fields:  |
                |      o Unique Identifier EF           |
                |      o NTS Authentication and         |
                |        Encrypted Extension Fields EF  |
                |        - NTS Cookie EF                |
                |        - <NTS Cookie EF>              |
                | - Transmit time request packet.       |
                +-----------------+---------------------+
                                  |
                                  |
Server -----------+---------------+-----+----------------------->
                  ^                      \
                 /                        \
  Time request  /                          \   Time response
  (mode 3)     /                            \  (mode 4)
              /                              \
             /                                V
Client -----+---------------------------------+----------------->
            |                                 |
            |                                 |
            |                                 |
+-----------+-----------------------+   +-----+------------------+
|- Generate time request message.   |   |- Verify time response  |
| - Include NTPv4 Extension fields: |   |  message.              |
|    o Unique Identifier EF         |   |- Extract cookie(s).    |
|    o NTS Cookie EF                |   |- Time synchronization  |
|    o <NTS Cookie Placeholder EF>  |   |  processing.           |
|                                   |   +------------------------+
|- Generate AEAD tag of NTP message.|
|- Add NTS Authentication and       |
|  Encrypted Extension Fields EF.   |
|- Transmit time request packet.    |
+-----------------------------------+

• Exactly one Unique Identifier extension field that MUST be authenticated, MUST NOT be encrypted, and whose contents SHALL echo those provided by the client.
• Exactly one NTS Authenticator and Encrypted Extension Fields extension field, generated using the AEAD algorithm and S2C key recovered from the cookie provided by the client.
• One or more NTS Cookie extension fields that MUST be authenticated and encrypted. The number of NTS Cookie extension fields included SHOULD be equal to, and MUST NOT exceed, one plus the number of valid NTS Cookie Placeholder extension fields included in the request. The cookies returned in those fields MUST be valid for use with the NTP server that sent them. They MAY be valid for other NTP servers as well, but there is no way for the server to indicate this.

• The AEAD algorithm negotiated during NTS-KE.
• The S2C key.
• The C2S key.

Service Name:

ntske

Port Number:

4460

Transport Protocol:

tcp

Description:

Network Time Security Key Establishment

Assignee:

IESG <iesg@ietf.org>

Contact:

IETF Chair <chair@ietf.org>

Registration Date:

2020-04-07

Reference:

RFC 8915

Protocol:

Network Time Security Key Establishment, version 1

Identification Sequence:

0x6E 0x74 0x73 0x6B 0x65 0x2F 0x31 ("ntske/1")

Reference:

RFC 8915, Section 4

Record Type Number (REQUIRED):

An integer in the range 0-32767 inclusive.

Description (REQUIRED):

A short text description of the purpose of the field.

Reference (REQUIRED):

A reference to a document specifying the semantics of the record.

0-1023:

IETF Review

1024-16383:

Specification Required

16384-32767:

Private or Experimental Use

Protocol ID (REQUIRED):

An integer in the range 0-65535 inclusive, functioning as an identifier.

Protocol Name (REQUIRED):

A short text string naming the protocol being identified.

Reference (REQUIRED):

A reference to a relevant specification document.

0-1023:

IETF Review

1024-32767:

Specification Required

32768-65535:

Private or Experimental Use

Number (REQUIRED):

An integer in the range 0-65535 inclusive

Description (REQUIRED):

A short text description of the condition.

Reference (REQUIRED):

A reference to a relevant specification document.

0-1023:

IETF Review

1024-32767:

Specification Required

32768-65535:

Private or Experimental Use

• Check whether the system time is in fact unreliable. On systems with the ntp_adjtime() system call, a return code other than TIME_ERROR indicates that some trusted software has already set the time and certificates can be strictly validated.
• Allow the system administrator to specify that certificates should always be strictly validated. Such a configuration is appropriate on systems that have a battery-backed clock or that can reasonably prompt the user to manually set an approximately correct time if it appears to be needed.
• Once the clock has been synchronized, periodically write the current system time to persistent storage. Do not accept any certificate whose notAfter field is earlier than the last recorded time.
• NTP time replies are expected to be consistent with the NTS-KE TLS certificate validity period, i.e. time replies received immediately after an NTS-KE handshake are expected to lie within the certificate validity period. Implementations are recommended to check that this is the case. Performing a new NTS-KE handshake based solely on the fact that the certificate used by the NTS-KE server in a previous handshake has expired is normally not necessary. Clients that still wish to do this must take care not to cause an inadvertent denial-of-service attack on the NTS-KE server, for example by picking a random time in the week preceding certificate expiry to perform the new handshake.
• Use multiple time sources. The ability to pass off an expired certificate is only useful to an adversary who has compromised the corresponding private key. If the adversary has compromised only a minority of servers, NTP's selection algorithm (Section 11.2.1 of [RFC 5905]) will protect the client from accepting bad time from the adversary-controlled servers.

[IANA-AEAD]

IANA, "Authenticated Encryption with Associated Data (AEAD) Parameters",
<https://www.iana.org/assignments/aead-parameters/>.

[RFC0020]

V.G. Cerf, "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC4291]

R. Hinden, and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006,
<https://www.rfc-editor.org/info/rfc4291>.

[RFC5116]

D. McGrew, "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.

[RFC5280]

D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.

[RFC5297]

D. Harkins, "Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 2008,
<https://www.rfc-editor.org/info/rfc5297>.

[RFC5705]

E. Rescorla, "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010,
<https://www.rfc-editor.org/info/rfc5705>.

[RFC5869]

H. Krawczyk, and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.

[RFC5890]

J. Klensin, "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.

[RFC5905]

D. Mills, J. Martin, J. Burbank, and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.

[RFC6125]

P. Saint-Andre, and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011,
<https://www.rfc-editor.org/info/rfc6125>.

[RFC6335]

M. Cotton, L. Eggert, J. Touch, M. Westerlund, and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>.

[RFC6874]

B. Carpenter, S. Cheshire, and R. Hinden, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, February 2013,
<https://www.rfc-editor.org/info/rfc6874>.

[RFC7301]

S. Friedl, A. Popov, A. Langley, and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014,
<https://www.rfc-editor.org/info/rfc7301>.

[RFC7525]

Y. Sheffer, R. Holz, and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015,
<https://www.rfc-editor.org/info/rfc7525>.

[RFC7822]

T. Mizrahi, and D. Mayer, "Network Time Protocol Version 4 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, March 2016,
<https://www.rfc-editor.org/info/rfc7822>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8446]

E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.

[Mizrahi]

T Mizrahi, "A game theoretic analysis of delay attacks against time synchronization protocols", DOI 10.1109/ISPCS.2012.6336612, September 2012,
<https://doi.org/10.1109/ISPCS.2012.6336612>.

[NTP-DATA-MIN]

Boston University, , and , "NTP Client Data Minimization", Internet-Draft draft-ietf-ntp-data-minimization-04, March 2019,
<https://tools.ietf.org/html/draft-ietf-ntp-data-minimization-04>.

[RFC4086]

D. Eastlake 3rd, J. Schiller, and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.

[RFC5077]

J. Salowey, H. Zhou, P. Eronen, and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008,
<https://www.rfc-editor.org/info/rfc5077>.

[RFC7384]

T. Mizrahi, "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014,
<https://www.rfc-editor.org/info/rfc7384>.

[RFC8573]

A. Malhotra, and S. Goldberg, "Message Authentication Code for the Network Time Protocol", RFC 8573, DOI 10.17487/RFC8573, June 2019,
<https://www.rfc-editor.org/info/rfc8573>.

[Shpiner]

A Shpiner, Y Revah, and T Mizrahi, "Multi-path Time Protocols", DOI 10.1109/ISPCS.2013.6644754, September 2013,
<https://doi.org/10.1109/ISPCS.2013.6644754>.

Daniel Fox Franke

Dieter Sibold

Kristof Teichel

Marcus Dansarie

Ragnar Sundblad