| < draft-ietf-ntp-using-nts-for-ntp-22.txt | draft-ietf-ntp-using-nts-for-ntp-28.txt > | |||
|---|---|---|---|---|
| NTP Working Group D. Franke | NTP Working Group D. Franke | |||
| Internet-Draft Akamai | Internet-Draft Akamai | |||
| Intended status: Standards Track D. Sibold | Intended status: Standards Track D. Sibold | |||
| Expires: August 16, 2020 K. Teichel | Expires: September 26, 2020 K. Teichel | |||
| PTB | PTB | |||
| M. Dansarie | M. Dansarie | |||
| R. Sundblad | R. Sundblad | |||
| Netnod | Netnod | |||
| February 13, 2020 | March 25, 2020 | |||
| Network Time Security for the Network Time Protocol | Network Time Security for the Network Time Protocol | |||
| draft-ietf-ntp-using-nts-for-ntp-22 | draft-ietf-ntp-using-nts-for-ntp-28 | |||
| Abstract | Abstract | |||
| This memo specifies Network Time Security (NTS), a mechanism for | This memo specifies Network Time Security (NTS), a mechanism for | |||
| using Transport Layer Security (TLS) and Authenticated Encryption | using Transport Layer Security (TLS) and Authenticated Encryption | |||
| with Associated Data (AEAD) to provide cryptographic security for the | with Associated Data (AEAD) to provide cryptographic security for the | |||
| client-server mode of the Network Time Protocol (NTP). | client-server mode of the Network Time Protocol (NTP). | |||
| NTS is structured as a suite of two loosely coupled sub-protocols. | NTS is structured as a suite of two loosely coupled sub-protocols. | |||
| The first (NTS-KE) handles initial authentication and key | The first (NTS-KE) handles initial authentication and key | |||
| skipping to change at page 1, line 46 ¶ | skipping to change at page 1, line 46 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on August 16, 2020. | This Internet-Draft will expire on September 26, 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 2, line 29 ¶ | skipping to change at page 2, line 29 ¶ | |||
| Table of Contents | Table of Contents | |||
| 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 . . . . . . . . . . . . . . . . . . . 11 | |||
| 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 . . . . . . . . . . . . . . . . . . . . . . . 12 | 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 . . . . . . . . . . . . . . . . 13 | 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 . . . . . . . . . . . . . . . 14 | |||
| 4.2. Key Extraction (generally) . . . . . . . . . . . . . . . 14 | 4.2. Retry Intervals . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 5. NTS Extension Fields for NTPv4 . . . . . . . . . . . . . . . 14 | 4.3. Key Extraction (generally) . . . . . . . . . . . . . . . 15 | |||
| 5.1. Key Extraction (for NTPv4) . . . . . . . . . . . . . . . 14 | 5. NTS Extension Fields for NTPv4 . . . . . . . . . . . . . . . 15 | |||
| 5.2. Packet Structure Overview . . . . . . . . . . . . . . . . 15 | 5.1. Key Extraction (for NTPv4) . . . . . . . . . . . . . . . 15 | |||
| 5.3. The Unique Identifier Extension Field . . . . . . . . . . 15 | 5.2. Packet Structure Overview . . . . . . . . . . . . . . . . 16 | |||
| 5.4. The NTS Cookie Extension Field . . . . . . . . . . . . . 16 | 5.3. The Unique Identifier Extension Field . . . . . . . . . . 16 | |||
| 5.5. The NTS Cookie Placeholder Extension Field . . . . . . . 16 | 5.4. The NTS Cookie Extension Field . . . . . . . . . . . . . 17 | |||
| 5.5. The NTS Cookie Placeholder Extension Field . . . . . . . 17 | ||||
| 5.6. The NTS Authenticator and Encrypted Extension Fields | 5.6. The NTS Authenticator and Encrypted Extension Fields | |||
| Extension Field . . . . . . . . . . . . . . . . . . . . . 17 | Extension Field . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 5.7. Protocol Details . . . . . . . . . . . . . . . . . . . . 19 | 5.7. Protocol Details . . . . . . . . . . . . . . . . . . . . 20 | |||
| 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 . . . . . . . . . . . . . . . . . . 26 | |||
| 7.3. TLS Exporter Labels Registry . . . . . . . . . . . . . . 26 | 7.3. TLS Exporter Labels Registry . . . . . . . . . . . . . . 26 | |||
| 7.4. NTP Kiss-o'-Death Codes Registry . . . . . . . . . . . . 26 | 7.4. NTP Kiss-o'-Death Codes Registry . . . . . . . . . . . . 26 | |||
| 7.5. NTP Extension Field Types Registry . . . . . . . . . . . 26 | 7.5. NTP Extension Field Types Registry . . . . . . . . . . . 26 | |||
| 7.6. Network Time Security Key Establishment Record Types | 7.6. Network Time Security Key Establishment Record Types | |||
| Registry . . . . . . . . . . . . . . . . . . . . . . . . 27 | Registry . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 7.7. Network Time Security Next Protocols Registry . . . . . . 28 | 7.7. Network Time Security Next Protocols Registry . . . . . . 28 | |||
| 7.8. Network Time Security Error and Warning Codes Registries 29 | 7.8. Network Time Security Error and Warning Codes Registries 29 | |||
| 8. Implementation Status - RFC EDITOR: REMOVE BEFORE PUBLICATION 30 | 8. Implementation Status - RFC EDITOR: REMOVE BEFORE PUBLICATION 30 | |||
| 8.1. Implementation 1 . . . . . . . . . . . . . . . . . . . . 30 | 8.1. Implementation 1 . . . . . . . . . . . . . . . . . . . . 30 | |||
| 8.1.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 30 | 8.1.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| skipping to change at page 3, line 44 ¶ | skipping to change at page 3, line 46 ¶ | |||
| 8.5.3. Contact Information . . . . . . . . . . . . . . . . . 33 | 8.5.3. Contact Information . . . . . . . . . . . . . . . . . 33 | |||
| 8.5.4. Last Update . . . . . . . . . . . . . . . . . . . . . 33 | 8.5.4. Last Update . . . . . . . . . . . . . . . . . . . . . 33 | |||
| 8.6. Implementation 6 . . . . . . . . . . . . . . . . . . . . 33 | 8.6. Implementation 6 . . . . . . . . . . . . . . . . . . . . 33 | |||
| 8.6.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 34 | 8.6.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 34 | |||
| 8.6.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 34 | 8.6.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 34 | |||
| 8.6.3. Contact Information . . . . . . . . . . . . . . . . . 34 | 8.6.3. Contact Information . . . . . . . . . . . . . . . . . 34 | |||
| 8.6.4. Last Update . . . . . . . . . . . . . . . . . . . . . 34 | 8.6.4. Last Update . . . . . . . . . . . . . . . . . . . . . 34 | |||
| 8.7. Interoperability . . . . . . . . . . . . . . . . . . . . 34 | 8.7. Interoperability . . . . . . . . . . . . . . . . . . . . 34 | |||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 | |||
| 9.1. Protected Modes . . . . . . . . . . . . . . . . . . . . . 34 | 9.1. Protected Modes . . . . . . . . . . . . . . . . . . . . . 34 | |||
| 9.2. Sensitivity to DDoS Attacks . . . . . . . . . . . . . . . 35 | 9.2. Cookie Encryption Key Compromise . . . . . . . . . . . . 35 | |||
| 9.3. Avoiding DDoS Amplification . . . . . . . . . . . . . . . 35 | 9.3. Sensitivity to DDoS Attacks . . . . . . . . . . . . . . . 35 | |||
| 9.4. Initial Verification of Server Certificates . . . . . . . 36 | 9.4. Avoiding DDoS Amplification . . . . . . . . . . . . . . . 35 | |||
| 9.5. Delay Attacks . . . . . . . . . . . . . . . . . . . . . . 37 | 9.5. Initial Verification of Server Certificates . . . . . . . 36 | |||
| 9.6. Random Number Generation . . . . . . . . . . . . . . . . 37 | 9.6. Delay Attacks . . . . . . . . . . . . . . . . . . . . . . 37 | |||
| 9.7. NTS Stripping . . . . . . . . . . . . . . . . . . . . . . 38 | 9.7. NTS Stripping . . . . . . . . . . . . . . . . . . . . . . 38 | |||
| 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38 | 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38 | |||
| 10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 38 | 10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 38 | |||
| 10.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 39 | 10.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 39 | |||
| 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 | |||
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
| 12.1. Normative References . . . . . . . . . . . . . . . . . . 39 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 39 | |||
| 12.2. Informative References . . . . . . . . . . . . . . . . . 41 | 12.2. Informative References . . . . . . . . . . . . . . . . . 41 | |||
| Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 42 | Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 42 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
| skipping to change at page 4, line 23 ¶ | skipping to change at page 4, line 24 ¶ | |||
| 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 | |||
| The objectives of NTS are as follows: | The objectives of NTS are as follows: | |||
| o Identity: Through the use of the X.509 public key infrastructure, | o Identity: Through the use of a X.509 public key infrastructure, | |||
| implementations may cryptographically establish the identity of | implementations can cryptographically establish the identity of | |||
| the parties they are communicating with. | the parties they are communicating with. | |||
| o Authentication: Implementations may cryptographically verify that | o Authentication: Implementations can cryptographically verify that | |||
| any time synchronization packets are authentic, i.e., that they | any time synchronization packets are authentic, i.e., that they | |||
| were produced by an identified party and have not been modified in | were produced by an identified party and have not been modified in | |||
| transit. | transit. | |||
| o Confidentiality: Although basic time synchronization data is | o Confidentiality: Although basic time synchronization data is | |||
| considered non-confidential and sent in the clear, NTS includes | considered non-confidential and sent in the clear, NTS includes | |||
| support for encrypting NTP extension fields. | support for encrypting NTP extension fields. | |||
| o Replay prevention: Client implementations may detect when a | o Replay prevention: Client implementations can detect when a | |||
| received time synchronization packet is a replay of a previous | received time synchronization packet is a replay of a previous | |||
| packet. | packet. | |||
| o Request-response consistency: Client implementations may verify | o Request-response consistency: Client implementations can verify | |||
| that a time synchronization packet received from a server was sent | that a time synchronization packet received from a server was sent | |||
| in response to a particular request from the client. | in response to a particular request from the client. | |||
| o Unlinkability: For mobile clients, NTS will not leak any | o Unlinkability: For mobile clients, NTS will not leak any | |||
| information additional to NTP which would permit a passive | information additional to NTP which would permit a passive | |||
| adversary to determine that two packets sent over different | adversary to determine that two packets sent over different | |||
| networks came from the same client. | networks came from the same client. | |||
| o Non-amplification: Implementations (especially server | o Non-amplification: Implementations (especially server | |||
| implementations) may avoid acting as distributed denial-of-service | implementations) can avoid acting as distributed denial-of-service | |||
| (DDoS) amplifiers by never responding to a request with a packet | (DDoS) amplifiers by never responding to a request with a packet | |||
| larger than the request packet. | larger than the request packet. | |||
| o Scalability: Server implementations may serve large numbers of | o Scalability: Server implementations can serve large numbers of | |||
| clients without having to retain any client-specific state. | clients without having to retain any client-specific state. | |||
| o 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 RFC 7384, | ||||
| Section 5.7 [RFC7384]). | ||||
| 1.2. Protocol Overview | 1.2. Protocol Overview | |||
| The Network Time Protocol includes many different operating modes to | The Network Time Protocol includes many different operating modes to | |||
| support various network topologies (see RFC 5905, Section 3 | support various network topologies (see RFC 5905, Section 3 | |||
| [RFC5905]). In addition to its best-known and most-widely-used | [RFC5905]). In addition to its best-known and most-widely-used | |||
| client-server mode, it also includes modes for synchronization | client-server mode, it also includes modes for synchronization | |||
| between symmetric peers, a control mode for server monitoring and | between symmetric peers, a control mode for server monitoring and | |||
| administration, and a broadcast mode. These various modes have | administration, and a broadcast mode. These various modes have | |||
| differing and partly contradictory requirements for security and | differing and partly contradictory requirements for security and | |||
| performance. Symmetric and control modes demand mutual | performance. Symmetric and control modes demand mutual | |||
| skipping to change at page 5, line 50 ¶ | skipping to change at page 6, line 7 ¶ | |||
| securing client-server mode because the server can implement them | securing client-server mode because the server can implement them | |||
| without retaining per-client state. All state is kept by the | without retaining per-client state. All state is kept by the | |||
| client and provided to the server in the form of an encrypted | client and provided to the server in the form of an encrypted | |||
| cookie supplied with each request. On the other hand, the NTS | cookie supplied with each request. On the other hand, the NTS | |||
| Extension Fields are suitable *only* for client-server mode | Extension Fields are suitable *only* for client-server mode | |||
| because only the client, and not the server, is protected from | because only the client, and not the server, is protected from | |||
| replay. | replay. | |||
| The "NTS Key Establishment" protocol (NTS-KE) is a mechanism for | The "NTS Key Establishment" protocol (NTS-KE) is a mechanism for | |||
| 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 establish 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, the TLS channel is closed with no | |||
| with no per-client state remaining on the server side. | 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 an IP address to the NTP server for | supply of cookies along with an address and port of an NTP server for | |||
| which the cookies are valid. The parties use TLS key export | which the cookies are valid. The parties use TLS key export | |||
| [RFC5705] to extract key material which will be used in the next | [RFC5705] to extract key material which will be used in the next | |||
| phase of the protocol. This negotiation takes only a single round | phase of the protocol. This negotiation takes only a single round | |||
| trip, after which the server closes the connection and discards all | trip, after which the server closes the connection and discards all | |||
| associated state. At this point the NTS-KE phase of the protocol is | associated state. At this point the NTS-KE phase of the protocol is | |||
| complete. Ideally, the client never needs to connect to the NTS-KE | complete. Ideally, the client never needs to connect to the NTS-KE | |||
| server again. | server again. | |||
| Time synchronization proceeds with one of the indicated NTP servers | Time synchronization proceeds with the indicated NTP server. The | |||
| over the NTP UDP port. The client sends the server an NTP client | client sends the server an NTP client packet which includes several | |||
| packet which includes several extension fields. Included among these | extension fields. Included among these fields are a cookie | |||
| fields are a cookie (previously provided by the key exchange server) | (previously provided by the key establishment server) and an | |||
| and an authentication tag, computed using key material extracted from | authentication tag, computed using key material extracted from the | |||
| the NTS-KE handshake. The NTP server uses the cookie to recover this | NTS-KE handshake. The NTP server uses the cookie to recover this key | |||
| key material and send back an authenticated response. The response | 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 | |||
| cookies is necessary in order to achieve NTS's unlinkability goal.) | cookies is necessary in order to achieve NTS's unlinkability goal.) | |||
| Figure 1 provides an overview of the high-level interaction between | Figure 1 provides an overview of the high-level interaction between | |||
| the client, the NTS-KE server, and the NTP server. Note that the | the client, the NTS-KE server, and the NTP server. Note that the | |||
| cookies' data format and the exchange of secrets between NTS-KE and | cookies' data format and the exchange of secrets between NTS-KE and | |||
| NTP servers are not part of this specification and are implementation | NTP servers are not part of this specification and are implementation | |||
| dependent. However, a suggested format for NTS cookies is provided | dependent. However, a suggested format for NTS cookies is provided | |||
| in Section 6. | in Section 6. | |||
| skipping to change at page 7, line 52 ¶ | skipping to change at page 7, line 52 ¶ | |||
| BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 3. TLS profile for Network Time Security | 3. TLS profile for Network Time Security | |||
| Network Time Security makes use of TLS for NTS key establishment. | Network Time Security makes use of TLS for NTS key establishment. | |||
| Since the NTS protocol is new as of this publication, no backward- | Since the NTS protocol is new as of this publication, no backward- | |||
| compatibility concerns exist to justify using obsolete, insecure, or | compatibility concerns exist to justify using obsolete, insecure, or | |||
| otherwise broken TLS features or versions. Implementations MUST | otherwise broken TLS features or versions. Implementations MUST | |||
| conform with [RFC7525] or with a later revision of BCP 195. In | conform with RFC 7525 [RFC7525] or with a later revision of BCP 195. | |||
| particular, failure to use cipher suites that provide forward secrecy | ||||
| will make all negotiated NTS keys recoverable by anyone that gains | ||||
| access to the NTS-KE server's private certificate. Furthermore: | ||||
| Implementations MUST NOT negotiate TLS versions earlier than 1.2, | Implementations MUST NOT negotiate TLS versions earlier than 1.3 | |||
| SHOULD negotiate TLS 1.3 [RFC8446] or later when possible, and MAY | [RFC8446] and MAY refuse to negotiate any TLS version which has been | |||
| refuse to negotiate any TLS version which has been superseded by a | superseded by a later supported version. | |||
| later supported version. | ||||
| Use of the Application-Layer Protocol Negotiation Extension [RFC7301] | Use of the Application-Layer Protocol Negotiation Extension [RFC7301] | |||
| is integral to NTS and support for it is REQUIRED for | is integral to NTS and support for it is REQUIRED for | |||
| interoperability. | interoperability. | |||
| Implementations MUST follow the rules in RFC 5280 [RFC5280] and RFC | ||||
| 6125 [RFC6125] for the representation and verification of the | ||||
| application's service identity. When NTS-KE service discovery (out | ||||
| of scope for this document) produces one or more host names, use of | ||||
| the DNS-ID identifier type [RFC6125] is RECOMMENDED; specifications | ||||
| for service discovery mechanisms can provide additional guidance for | ||||
| certificate validation based on the results of discovery. | ||||
| Section 9.5 of this memo discusses particular considerations for | ||||
| certificate verification in the context of NTS. | ||||
| 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 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. Requests and | a sequence of records formatted according to Figure 2. The request | |||
| non-error responses each SHALL include exactly one NTS Next Protocol | and a non-error response each SHALL include exactly one NTS Next | |||
| Negotiation record. The sequence SHALL be terminated by a "End of | Protocol Negotiation record. The sequence SHALL be terminated by a | |||
| 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 | |||
| octets and clients SHOULD accept responses of at least 65536 octets. | octets and clients SHOULD accept responses of at least 65536 octets. | |||
| 0 1 2 3 | 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 | 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 | | |C| Record Type | Body Length | | |||
| skipping to change at page 9, line 24 ¶ | skipping to change at page 9, line 24 ¶ | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 2: NTS-KE Record Format | Figure 2: NTS-KE Record Format | |||
| The fields of an NTS-KE record are defined as follows: | The fields of an NTS-KE record are defined as follows: | |||
| C (Critical Bit): Determines the disposition of unrecognized | C (Critical Bit): Determines the disposition of unrecognized | |||
| Record Types. Implementations which receive a record with an | Record Types. Implementations which receive a record with an | |||
| unrecognized Record Type MUST ignore the record if the Critical | 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. | 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 | Record Type Number: A 15-bit integer in network byte order. The | |||
| semantics of record types 0-7 are specified in this memo. | semantics of record types 0-7 are specified in this memo. | |||
| Additional type numbers SHALL be tracked through the IANA Network | Additional type numbers SHALL be tracked through the IANA Network | |||
| Time Security Key Establishment Record Types registry. | Time Security Key Establishment Record Types registry. | |||
| Body Length: The length of the Record Body field, in octets, as a | 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 | 16-bit integer in network byte order. Record bodies MAY have any | |||
| 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 the C programming language, | |||
| `unsigned char b[]` containing an NTS-KE record, the critical bit is | given a network buffer `unsigned char b[]` containing an NTS-KE | |||
| `b[0] >> 7` while the record type is `((b[0] & 0x7f) << 8) + b[1]`. | record, the critical bit is `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 | 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 | is similar to that of an NTP extension field, the semantics of the | |||
| length field differ. While the length subfield of an NTP extension | length field differ. While the length subfield of an NTP extension | |||
| field gives the length of the entire extension field including the | field gives the length of the entire extension field including the | |||
| type and length subfields, the length field of an NTS-KE record gives | type and length subfields, the length field of an NTS-KE record gives | |||
| just the length of the body. | 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 establishment. 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 | | |||
| | o AEAD Algorithm Negotiation | | | o AEAD Algorithm Negotiation | | |||
| | o NTP Server Negotiation | | | o <NTPv4 Server Negotiation> | | |||
| | o <NTPv4 Port Negotiation> | | ||||
| | o New Cookie for NTPv4 | | | o New Cookie for NTPv4 | | |||
| | o <New Cookie for NTPv4> | | | o <New Cookie for NTPv4> | | |||
| | o End of Message | | | o End of Message | | |||
| +-----------------+---------------------+ | +-----------------+---------------------+ | |||
| | | | | |||
| | | | | |||
| Server -----------+---------------+-----+-----------------------> | Server -----------+---------------+-----+-----------------------> | |||
| ^ \ | ^ \ | |||
| / \ | / \ | |||
| / TLS application \ | / TLS application \ | |||
| skipping to change at page 10, line 34 ¶ | skipping to change at page 10, line 39 ¶ | |||
| / \ | / \ | |||
| / V | / V | |||
| Client -----+---------------------------------+-----------------> | Client -----+---------------------------------+-----------------> | |||
| | | | | | | |||
| | | | | | | |||
| | | | | | | |||
| +-----------+----------------------+ +------+-----------------+ | +-----------+----------------------+ +------+-----------------+ | |||
| |- Generate KE request message. | |- Verify server response| | |- Generate KE request message. | |- Verify server response| | |||
| | - Include Record Types: | | message. | | | - Include Record Types: | | message. | | |||
| | o NTS Next Protocol Negotiation | |- Extract cookie(s). | | | o NTS Next Protocol Negotiation | |- Extract cookie(s). | | |||
| | o AEAD Algorithm Negotiation | | | | | o AEAD Algorithm Negotiation | +------------------------+ | |||
| | o <NTP Server Negotiation> | | | | | o <NTPv4 Server Negotiation> | | |||
| | o End of Message | | | | | o <NTPv4 Port Negotiation> | | |||
| +----------------------------------+ +------------------------+ | | o End of Message | | |||
| +----------------------------------+ | ||||
| Figure 3: NTS Key Exchange Messages | Figure 3: NTS Key Establishment Messages | |||
| 4.1. NTS-KE Record Types | 4.1. NTS-KE Record Types | |||
| The following NTS-KE Record Types are defined: | The following NTS-KE Record Types are defined: | |||
| 4.1.1. End of Message | 4.1.1. End of Message | |||
| The End of Message record has a Record Type number of 0 and a zero- | The End of Message record has a Record Type number of 0 and a zero- | |||
| length body. It MUST occur exactly once as the final record of every | length body. It MUST occur exactly once as the final record of every | |||
| NTS-KE request and response. The Critical Bit MUST be set. | NTS-KE request and response. The Critical Bit MUST be set. | |||
| skipping to change at page 11, line 16 ¶ | skipping to change at page 11, line 22 ¶ | |||
| The NTS Next Protocol Negotiation record has a Record Type number of | The NTS Next Protocol Negotiation record has a Record Type number of | |||
| 1. It MUST occur exactly once in every NTS-KE request and response. | 1. It MUST occur exactly once in every NTS-KE request and response. | |||
| Its body consists of a sequence of 16-bit unsigned integers in | Its body consists of a sequence of 16-bit unsigned integers in | |||
| network byte order. Each integer represents a Protocol ID from the | network byte order. Each integer represents a Protocol ID from the | |||
| IANA Network Time Security Next Protocols registry. The Critical Bit | IANA Network Time Security Next Protocols registry. The Critical Bit | |||
| MUST be set. | MUST be set. | |||
| The Protocol IDs listed in the client's NTS Next Protocol Negotiation | The Protocol IDs listed in the client's NTS Next Protocol Negotiation | |||
| record denote those protocols which the client wishes to speak using | record denote those protocols which the client wishes to speak using | |||
| the key material established through this NTS-KE session. The | the key material established through this NTS-KE session. Protocol | |||
| Protocol IDs listed in the server's response MUST comprise a subset | IDs listed in the NTS-KE server's response MUST comprise a subset of | |||
| of those listed in the request and denote those protocols which the | those listed in the request and denote those protocols which the NTP | |||
| server is willing and able to speak using the key material | server is willing and able to speak using the key material | |||
| established through this NTS-KE session. The client MAY proceed with | established through this NTS-KE session. The client MAY proceed with | |||
| one or more of them. The request MUST list at least one protocol, | one or more of them. The request MUST list at least one protocol, | |||
| but the response MAY be empty. | but the response MAY be empty. | |||
| 4.1.3. Error | 4.1.3. Error | |||
| The Error record has a Record Type number of 2. Its body is exactly | The Error record has a Record Type number of 2. Its body is exactly | |||
| two octets long, consisting of an unsigned 16-bit integer in network | two octets long, consisting of an unsigned 16-bit integer in network | |||
| byte order, denoting an error code. The Critical Bit MUST be set. | byte order, denoting an error code. The Critical Bit MUST be set. | |||
| Clients MUST NOT include Error records in their request. If clients | Clients MUST NOT include Error records in their request. If clients | |||
| receive a server response which includes an Error record, they MUST | receive a server response which includes an Error record, they MUST | |||
| discard any negotiated key material and MUST NOT proceed to the Next | discard any key material negotiated during the initial TLS exchange | |||
| Protocol. | and MUST NOT proceed to the Next Protocol. Requirements for retry | |||
| intervals are described in Section 4.2. | ||||
| The following error codes are defined: | The following error codes are defined: | |||
| Error code 0 means "Unrecognized Critical Record". The server | Error code 0 means "Unrecognized Critical Record". The server | |||
| 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 the request is not complete and syntactically well- | |||
| timeout, it has not yet received a complete and syntactically | formed, or, upon the expiration of an implementation-defined | |||
| well-formed request from the client. | 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 | Error code 2 means "Internal Server Error". The server MUST | |||
| respond with this error if it is unable to respond properly due to | respond with this error if it is unable to respond properly due to | |||
| an internal condition. | an internal condition. The client MAY retry its request. | |||
| 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, | |||
| skipping to change at page 12, line 25 ¶ | skipping to change at page 12, line 31 ¶ | |||
| proceeding to the Next Protocol. Unrecognized warning codes MUST be | proceeding to the Next Protocol. Unrecognized warning codes MUST be | |||
| treated as errors. | treated as errors. | |||
| This memo defines no warning codes. | This memo defines no warning codes. | |||
| 4.1.5. AEAD Algorithm Negotiation | 4.1.5. AEAD Algorithm Negotiation | |||
| The AEAD Algorithm Negotiation record has a Record Type number of 4. | The AEAD Algorithm Negotiation record has a Record Type number of 4. | |||
| Its body consists of a sequence of unsigned 16-bit integers in | Its body consists of a sequence of unsigned 16-bit integers in | |||
| network byte order, denoting Numeric Identifiers from the IANA AEAD | network byte order, denoting Numeric Identifiers from the IANA AEAD | |||
| registry [RFC5116]. The Critical Bit MAY be set. | Algorithms registry [IANA-AEAD]. The Critical Bit MAY be set. | |||
| If the NTS Next Protocol Negotiation record offers Protocol ID 0 (for | If the NTS Next Protocol Negotiation record offers Protocol ID 0 (for | |||
| NTPv4), then this record MUST be included exactly once. Other | NTPv4), then this record MUST be included exactly once. Other | |||
| protocols MAY require it as well. | protocols MAY require it as well. | |||
| When included in a request, this record denotes which AEAD algorithms | When included in a request, this record denotes which AEAD algorithms | |||
| the client is willing to use to secure the Next Protocol, in | the client is willing to use to secure the Next Protocol, in | |||
| decreasing preference order. When included in a response, this | decreasing preference order. When included in a response, this | |||
| record denotes which algorithm the server chooses to use. It is | record denotes which algorithm the server chooses to use. It is | |||
| empty if the server supports none of the algorithms offered. In | empty if the server supports none of the algorithms offered. In | |||
| skipping to change at page 13, line 21 ¶ | skipping to change at page 13, line 23 ¶ | |||
| Clients MUST NOT send records of this type. Servers MUST send at | Clients MUST NOT send records of this type. Servers MUST send at | |||
| least one record of this type, and SHOULD send eight of them, if the | least one record of this type, and SHOULD send eight of them, if the | |||
| Next Protocol Negotiation response record contains Protocol ID 0 | Next Protocol Negotiation response record contains Protocol ID 0 | |||
| (NTPv4) and the AEAD Algorithm Negotiation response record is not | (NTPv4) and the AEAD Algorithm Negotiation response record is not | |||
| empty. The Critical Bit SHOULD NOT be set. | empty. The Critical Bit SHOULD NOT be set. | |||
| 4.1.7. NTPv4 Server Negotiation | 4.1.7. NTPv4 Server Negotiation | |||
| The NTPv4 Server Negotiation record has a Record Type number of 6. | The NTPv4 Server Negotiation record has a Record Type number of 6. | |||
| Its body consists of an ASCII-encoded [ANSI.X3-4.1986] string. The | Its body consists of an ASCII-encoded [RFC0020] string. The contents | |||
| contents of the string SHALL be either an IPv4 address in dotted | of the string SHALL be either an IPv4 address, an IPv6 address, or a | |||
| decimal notation, an IPv6 address, or a fully qualified domain name | fully qualified domain name (FQDN). IPv4 addresses MUST be in dotted | |||
| (FQDN). IPv6 addresses MUST conform to the "Text Representation of | decimal notation. IPv6 addresses MUST conform to the "Text | |||
| Addresses" as specified in [RFC4291] and MUST NOT include zone | Representation of Addresses" as specified in RFC 4291 [RFC4291] and | |||
| identifiers [RFC6874]. If internationalized labels are needed in the | MUST NOT include zone identifiers [RFC6874]. If a label contains at | |||
| domain name, the A-LABEL syntax specified in [RFC5891] MUST be used. | least one non-ASCII character, it is an internationalized domain name | |||
| and an A-LABEL MUST be used as defined in Section 2.3.2.1 of RFC 5890 | ||||
| [RFC5890]. If the record contains a domain name, the recipient MUST | ||||
| treat it as a FQDN, e.g. by making sure it ends with a dot. | ||||
| When NTPv4 is negotiated as a Next Protocol and this record is sent | When NTPv4 is negotiated as a Next Protocol and this record is sent | |||
| by the server, the body specifies the hostname or IP address of the | by the server, the body specifies the hostname or IP address of the | |||
| NTPv4 server with which the client should associate and which will | NTPv4 server with which the client should associate and which will | |||
| accept the supplied cookies. If no record of this type is sent, the | accept the supplied cookies. If no record of this type is sent, the | |||
| client SHALL interpret this as a directive to associate with an NTPv4 | client SHALL interpret this as a directive to associate with an NTPv4 | |||
| server at the same IP address as the NTS-KE server. Servers MUST NOT | server at the same IP address as the NTS-KE server. Servers MUST NOT | |||
| send more than one record of this type. | send more than one record of this type. | |||
| When this record is sent by the client, it indicates that the client | When this record is sent by the client, it indicates that the client | |||
| wishes to associate with the specified NTP server. The NTS-KE server | wishes to associate with the specified NTP server. The NTS-KE server | |||
| MAY incorporate this request when deciding what NTPv4 Server | MAY incorporate this request when deciding what NTPv4 Server | |||
| Negotiation records to respond with, but honoring the client's | Negotiation records to respond with, but honoring the client's | |||
| preference is OPTIONAL. The client MUST NOT send more than one | preference is OPTIONAL. The client MUST NOT send more than one | |||
| record of this type. | record of this type. | |||
| If the client has sent a record of this type, the NTS-KE server | ||||
| SHOULD reply with the same record if it is valid and the server is | ||||
| able to supply cookies for it. If the client has not sent any record | ||||
| of this type, the NTS-KE server SHOULD respond with either an NTP | ||||
| server address in the same family as the NTS-KE session or a FQDN | ||||
| that can be resolved to an address in that family, if such | ||||
| alternatives are available. | ||||
| Servers MAY set the Critical Bit on records of this type; clients | Servers MAY set the Critical Bit on records of this type; clients | |||
| SHOULD NOT. | SHOULD NOT. | |||
| 4.1.8. NTPv4 Port Negotiation | 4.1.8. NTPv4 Port Negotiation | |||
| The NTPv4 Port Negotiation record has a Record Type number of 7. Its | The NTPv4 Port Negotiation record has a Record Type number of 7. Its | |||
| body consists of a 16-bit unsigned integer in network byte order, | body consists of a 16-bit unsigned integer in network byte order, | |||
| denoting a UDP port number. | denoting a UDP port number. | |||
| When NTPv4 is negotiated as a Next Protocol and this record is sent | When NTPv4 is negotiated as a Next Protocol and this record is sent | |||
| skipping to change at page 14, line 21 ¶ | skipping to change at page 14, line 34 ¶ | |||
| When this record is sent by the client in conjunction with a NTPv4 | When this record is sent by the client in conjunction with a NTPv4 | |||
| Server Negotiation record, it indicates that the client wishes to | Server Negotiation record, it indicates that the client wishes to | |||
| associate with the NTP server at the specified port. The NTS-KE | associate with the NTP server at the specified port. The NTS-KE | |||
| server MAY incorporate this request when deciding what NTPv4 Server | server MAY incorporate this request when deciding what NTPv4 Server | |||
| Negotiation and NTPv4 Port Negotiation records to respond with, but | Negotiation and NTPv4 Port Negotiation records to respond with, but | |||
| honoring the client's preference is OPTIONAL. | honoring the client's preference is OPTIONAL. | |||
| Servers MAY set the Critical Bit on records of this type; clients | Servers MAY set the Critical Bit on records of this type; clients | |||
| SHOULD NOT. | SHOULD NOT. | |||
| 4.2. Key Extraction (generally) | 4.2. Retry Intervals | |||
| A mechanism for not unnecessarily overloading the NTS-KE server is | ||||
| REQUIRED when retrying the key establishment process due to protocol, | ||||
| communication, or other errors. The exact workings of this will be | ||||
| dependent on the application and operational experience gathered over | ||||
| time. Until such experience is available, this memo provides the | ||||
| following suggestion. | ||||
| Clients SHOULD use exponential backoff, with an initial and minimum | ||||
| retry interval of 10 seconds, a maximum retry interval of 5 days, and | ||||
| a base of 1.5. Thus, the minimum interval in seconds, `t`, for the | ||||
| nth retry is calculated with | ||||
| t = min(10 * 1.5^(n-1), 432000). | ||||
| Clients MUST NOT reset the retry interval until they have performed a | ||||
| successful key establishment with the NTS-KE server, followed by a | ||||
| successful use of the negotiated next protocol with the keys and data | ||||
| established during that transaction. | ||||
| 4.3. Key Extraction (generally) | ||||
| Following a successful run of the NTS-KE protocol, key material SHALL | Following a successful run of the NTS-KE protocol, key material SHALL | |||
| be extracted using the TLS pseudorandom function (PRF) [RFC5705] for | be extracted using the HMAC-based Extract-and-Expand Key Derivation | |||
| TLS version 1.2, or the HMAC-based Extract-and-Expand Key Derivation | ||||
| Function (HKDF) [RFC5869] in accordance with RFC 8446, Section 7.5 | Function (HKDF) [RFC5869] in accordance with RFC 8446, Section 7.5 | |||
| [RFC8446] for TLS version 1.3. Inputs to the exporter function are | [RFC8446]. Inputs to the exporter function are to be constructed in | |||
| to be constructed in a manner specific to the negotiated Next | a manner specific to the negotiated Next Protocol. However, all | |||
| Protocol. However, all protocols which utilize NTS-KE MUST conform | protocols which utilize NTS-KE MUST conform to the following two | |||
| to the following two rules: | rules: | |||
| The disambiguating label string MUST be "EXPORTER-network-time- | The disambiguating label string [RFC5705] MUST be "EXPORTER- | |||
| security/1". | network-time-security". | |||
| The per-association context value MUST be provided and MUST begin | The per-association context value [RFC5705] MUST be provided and | |||
| with the two-octet Protocol ID which was negotiated as a Next | MUST begin with the two-octet Protocol ID which was negotiated as | |||
| Protocol. | a Next Protocol. | |||
| 5. NTS Extension Fields for NTPv4 | 5. NTS Extension Fields for NTPv4 | |||
| 5.1. Key Extraction (for NTPv4) | 5.1. Key Extraction (for NTPv4) | |||
| Following a successful run of the NTS-KE protocol wherein Protocol ID | Following a successful run of the NTS-KE protocol wherein Protocol ID | |||
| 0 (NTPv4) is selected as a Next Protocol, two AEAD keys SHALL be | 0 (NTPv4) is selected as a Next Protocol, two AEAD keys SHALL be | |||
| extracted: a client-to-server (C2S) key and a server-to-client (S2C) | extracted: a client-to-server (C2S) key and a server-to-client (S2C) | |||
| key. These keys SHALL be computed with the PRF defined in RFC 5705 | key. These keys SHALL be computed with the HKDF defined in RFC 8446, | |||
| [RFC5705] for TLS version 1.2, or the HKDF defined in RFC 8446, | Section 7.5 [RFC8446] using the following inputs. | |||
| Section 7.5 [RFC8446] for TLS version 1.3, using the following | ||||
| inputs. | ||||
| The disambiguating label string (for PRF) or label (for HKDF) | The disambiguating label string [RFC5705] SHALL be "EXPORTER- | |||
| SHALL be "EXPORTER-network-time-security/1". | network-time-security". | |||
| The context value SHALL consist of the following five octets: | The per-association context value [RFC5705] SHALL consist of the | |||
| following five octets: | ||||
| The first two octets SHALL be zero (the Protocol ID for NTPv4). | The first two octets SHALL be zero (the Protocol ID for NTPv4). | |||
| The next two octets SHALL be the Numeric Identifier of the | The next two octets SHALL be the Numeric Identifier of the | |||
| negotiated AEAD Algorithm in network byte order. | negotiated AEAD Algorithm in network byte order. | |||
| The final octet SHALL be 0x00 for the C2S key and 0x01 for the | The final octet SHALL be 0x00 for the C2S key and 0x01 for the | |||
| S2C key. | S2C key. | |||
| Implementations wishing to derive additional keys for private or | Implementations wishing to derive additional keys for private or | |||
| skipping to change at page 15, line 42 ¶ | skipping to change at page 16, line 27 ¶ | |||
| authentication tag and possible ciphertext). The corresponding | authentication tag and possible ciphertext). The corresponding | |||
| plaintext, if non-empty, consists of some extension fields which | plaintext, if non-empty, consists of some extension fields which | |||
| benefit from both encryption and authentication. | benefit from both encryption and authentication. | |||
| Possibly, some additional extension fields which are neither | Possibly, some additional extension fields which are neither | |||
| encrypted nor authenticated. In general, these are discarded by | encrypted nor authenticated. In general, these are discarded by | |||
| the receiver. | the receiver. | |||
| Always included among the authenticated or authenticated-and- | Always included among the authenticated or authenticated-and- | |||
| encrypted extension fields are a cookie extension field and a unique | encrypted extension fields are a cookie extension field and a unique | |||
| identifier extension field. The purpose of the cookie extension | identifier extension field, as described in Section 5.7. The purpose | |||
| field is to enable the server to offload storage of session state | of the cookie extension field is to enable the server to offload | |||
| onto the client. The purpose of the unique identifier extension | storage of session state onto the client. The purpose of the unique | |||
| field is to protect the client from replay attacks. | identifier extension field is to protect the client from replay | |||
| attacks. | ||||
| 5.3. The Unique Identifier Extension Field | 5.3. The Unique Identifier Extension Field | |||
| The Unique Identifier extension field provides the client with a | The Unique Identifier extension field provides the client with a | |||
| cryptographically strong means of detecting replayed packets. It has | cryptographically strong means of detecting replayed packets. It has | |||
| a Field Type of [[TBD2]]. When the extension field is included in a | a Field Type of [[TBD2]]. When the extension field is included in a | |||
| client packet (mode 3), its body SHALL consist of a string of octets | client packet (mode 3), its body SHALL consist of a string of octets | |||
| generated uniformly at random. The string MUST be at least 32 octets | generated by a cryptographically secure random number generator | |||
| long. When the extension field is included in a server packet (mode | [RFC4086]. The string MUST be at least 32 octets long. When the | |||
| 4), its body SHALL contain the same octet string as was provided in | extension field is included in a server packet (mode 4), its body | |||
| the client packet to which the server is responding. All server | SHALL contain the same octet string as was provided in the client | |||
| packets generated by NTS-implementing servers in response to client | packet to which the server is responding. All server packets | |||
| packets containing this extension field MUST also contain this field | generated by NTS-implementing servers in response to client packets | |||
| with the same content as in the client's request. The field's use in | containing this extension field MUST also contain this field with the | |||
| modes other than client-server is not defined. | same content as in the client's request. The field's use in modes | |||
| other than client-server is not defined. | ||||
| This extension field MAY also be used standalone, without NTS, in | This extension field MAY also be used standalone, without NTS, in | |||
| which case it provides the client with a means of detecting spoofed | which case it provides the client with a means of detecting spoofed | |||
| packets from off-path attackers. Historically, NTP's origin | packets from off-path attackers. Historically, NTP's origin | |||
| timestamp field has played both these roles, but for cryptographic | timestamp field has played both these roles, but for cryptographic | |||
| purposes this is suboptimal because it is only 64 bits long and, | purposes this is suboptimal because it is only 64 bits long and, | |||
| depending on implementation details, most of those bits may be | depending on implementation details, most of those bits may be | |||
| predictable. In contrast, the Unique Identifier extension field | predictable. In contrast, the Unique Identifier extension field | |||
| enables a degree of unpredictability and collision resistance more | enables a degree of unpredictability and collision resistance more | |||
| consistent with cryptographic best practice. | consistent with cryptographic best practice. | |||
| skipping to change at page 16, line 49 ¶ | skipping to change at page 17, line 37 ¶ | |||
| send additional cookies in its response. This extension field MUST | send additional cookies in its response. This extension field MUST | |||
| NOT be included in NTP packets whose mode is other than 3. | NOT be included in NTP packets whose mode is other than 3. | |||
| Whenever an NTS Cookie Placeholder extension field is present, it | Whenever an NTS Cookie Placeholder extension field is present, it | |||
| MUST be accompanied by an NTS Cookie extension field. The body | MUST be accompanied by an NTS Cookie extension field. The body | |||
| length of the NTS Cookie Placeholder extension field MUST be the same | length of the NTS Cookie Placeholder extension field MUST be the same | |||
| as the body length of the NTS Cookie extension field. This length | as the body length of the NTS Cookie extension field. This length | |||
| requirement serves to ensure that the response will not be larger | requirement serves to ensure that the response will not be larger | |||
| than the request, in order to improve timekeeping precision and | than the request, in order to improve timekeeping precision and | |||
| prevent DDoS amplification. The contents of the NTS Cookie | prevent DDoS amplification. The contents of the NTS Cookie | |||
| Placeholder extension field's body are undefined and, aside from | Placeholder extension field's body SHOULD be all zeros and, aside | |||
| checking its length, MUST be ignored by the server. | from checking its length, MUST be ignored by the server. | |||
| 5.6. The NTS Authenticator and Encrypted Extension Fields Extension | 5.6. The NTS Authenticator and Encrypted Extension Fields Extension | |||
| Field | Field | |||
| The NTS Authenticator and Encrypted Extension Fields extension field | The NTS Authenticator and Encrypted Extension Fields extension field | |||
| is the central cryptographic element of an NTS-protected NTP packet. | is the central cryptographic element of an NTS-protected NTP packet. | |||
| Its Field Type is [[TBD5]]. It SHALL be formatted according to | Its Field Type is [[TBD5]]. It SHALL be formatted according to | |||
| Figure 4 and include the following fields: | Figure 4 and include the following fields: | |||
| Nonce Length: Two octets in network byte order, giving the length | Nonce Length: Two octets in network byte order, giving the length | |||
| of the Nonce field, excluding any padding, interpreted as an | of the Nonce field, excluding any padding, interpreted as an | |||
| unsigned integer. | unsigned integer. | |||
| Ciphertext Length: Two octets in network byte order, giving the | Ciphertext Length: Two octets in network byte order, giving the | |||
| length of the Ciphertext field, excluding any padding, interpreted | length of the Ciphertext field, excluding any padding, interpreted | |||
| as an unsigned integer. | as an unsigned integer. | |||
| Nonce: A nonce as required by the negotiated AEAD Algorithm. The | Nonce: A nonce as required by the negotiated AEAD Algorithm. The | |||
| field is zero-padded to a word (four octets) boundary. | end of the field is zero-padded to a word (four octets) boundary. | |||
| Ciphertext: The output of the negotiated AEAD Algorithm. The | Ciphertext: The output of the negotiated AEAD Algorithm. The | |||
| structure of this field is determined by the negotiated algorithm, | structure of this field is determined by the negotiated algorithm, | |||
| but it typically contains an authentication tag in addition to the | but it typically contains an authentication tag in addition to the | |||
| actual ciphertext. The field is zero-padded to a word (four | actual ciphertext. The end of the field is zero-padded to a word | |||
| octets) boundary. | (four octets) boundary. | |||
| Additional Padding: Clients which use a nonce length shorter than | Additional Padding: Clients which use a nonce length shorter than | |||
| the maximum allowed by the negotiated AEAD algorithm may be | the maximum allowed by the negotiated AEAD algorithm may be | |||
| required to include additional zero-padding. The necessary length | required to include additional zero-padding. The necessary length | |||
| of this field is specified below. | of this field is specified below. | |||
| 0 1 2 3 | 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 | 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 Length | Ciphertext Length | | |||
| skipping to change at page 19, line 28 ¶ | skipping to change at page 19, line 46 ¶ | |||
| `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 | Senders are always free to include more Additional Padding than | |||
| mandated by the above paragraph. Theoretically, it could be | mandated by the above paragraph. Theoretically, it could be | |||
| necessary to do so in order to bring the extension field to the | necessary to do so in order to bring the extension field to the | |||
| minimum length required by [RFC7822]. This should never happen in | minimum length required by RFC 7822 [RFC7822]. This should never | |||
| practice because any reasonable AEAD algorithm will have a nonce and | happen in practice because any reasonable AEAD algorithm will have a | |||
| an authenticator long enough to bring the extension field to its | nonce and an authenticator long enough to bring the extension field | |||
| required length already. Nonetheless, implementers are advised to | to its required length already. Nonetheless, implementers are | |||
| explicitly handle this case and ensure that the extension field they | advised to explicitly handle this case and ensure that the extension | |||
| emit is of legal length. | 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 | |||
| authenticated, MUST NOT be encrypted, and whose contents MUST NOT | authenticated, MUST NOT be encrypted, and whose contents MUST be | |||
| duplicate those of any previous request. | the output of a cryptographically secure random number generator. | |||
| [RFC4086] | ||||
| Exactly one NTS Cookie extension field which MUST be authenticated | Exactly one NTS Cookie extension field which MUST be authenticated | |||
| and MUST NOT be encrypted. The cookie MUST be one which has been | and MUST NOT be encrypted. The cookie MUST be one which has been | |||
| previously provided to the client; either from the key exchange | previously provided to the client, either from the key | |||
| server during the NTS-KE handshake or from the NTP server in | establishment server during the NTS-KE handshake or from the NTP | |||
| response to a previous NTS-protected NTP request. | server in response to a previous NTS-protected NTP request. | |||
| Exactly one NTS Authenticator and Encrypted Extension Fields | Exactly one NTS Authenticator and Encrypted Extension Fields | |||
| extension field, generated using an AEAD Algorithm and C2S key | extension field, generated using an AEAD Algorithm and C2S key | |||
| established through NTS-KE. | established through NTS-KE. | |||
| To protect the client's privacy, the client SHOULD avoid reusing a | To protect the client's privacy, the client SHOULD avoid reusing a | |||
| cookie. If the client does not have any cookies that it has not | cookie. If the client does not have any cookies that it has not | |||
| already sent, it SHOULD initiate a re-run the NTS-KE protocol. The | already sent, it SHOULD initiate a re-run of the NTS-KE protocol. | |||
| client MAY reuse cookies in order to prioritize resilience over | The client MAY reuse cookies in order to prioritize resilience over | |||
| unlinkability. Which of the two that should be prioritized in any | unlinkability. Which of the two that should be prioritized in any | |||
| particular case is dependent on the application and the user's | particular case is dependent on the application and the user's | |||
| preference. Section 10.1 describes the privacy considerations of | preference. Section 10.1 describes the privacy considerations of | |||
| this in further detail. | this in further detail. | |||
| The client MAY include one or more NTS Cookie Placeholder extension | The client MAY include one or more NTS Cookie Placeholder extension | |||
| fields which MUST be authenticated and MAY be encrypted. The number | fields which MUST be authenticated and MAY be encrypted. The number | |||
| 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 | |||
| skipping to change at page 20, line 37 ¶ | skipping to change at page 21, line 8 ¶ | |||
| 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 | In rare circumstances, it may be necessary to include fewer NTS | |||
| Cookie Placeholder extensions than recommended above in order to | Cookie Placeholder extensions than recommended above in order to | |||
| prevent datagram fragmentation. When cookies adhere the format | prevent datagram fragmentation. When cookies adhere the format | |||
| recommended in Section 6 and the AEAD in use is the mandatory-to- | 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 | implement AEAD_AES_SIV_CMAC_256, senders can include a cookie and | |||
| seven placeholders and still have packet size fall comfortably below | seven placeholders and still have packet size fall comfortably below | |||
| 1280 octets if no non-NTS-related extensions are used; 1280 octets is | 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 | the minimum prescribed MTU for IPv6 and is generally safe for | |||
| avoiding IPv4 fragmentation. Nonetheless, senders SHOULD include | avoiding IPv4 fragmentation. Nonetheless, senders SHOULD include | |||
| fewer cookies and placeholders than otherwise indicated if doing so | fewer cookies and placeholders than otherwise indicated if doing so | |||
| is necessary to prevent fragmentation. | 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 | | |||
| skipping to change at page 21, line 42 ¶ | skipping to change at page 21, line 50 ¶ | |||
| | o Unique Identifier EF | |- Extract cookie(s) | | | o Unique Identifier EF | |- Extract cookie(s) | | |||
| | o NTS Cookie EF | |- Time synchronization | | | o NTS Cookie EF | |- Time synchronization | | |||
| | o <NTS Cookie Placeholder EF> | | processing | | | o <NTS Cookie Placeholder EF> | | processing | | |||
| | | +------------------------+ | | | +------------------------+ | |||
| |- Generate AEAD tag of NTP message| | |- Generate AEAD tag of NTP message| | |||
| |- Add NTS Authentication and | | |- Add NTS Authentication and | | |||
| | Encrypted Extension Fields EF | | | Encrypted Extension Fields EF | | |||
| |- Transmit time request packet | | |- Transmit time request packet | | |||
| +----------------------------------+ | +----------------------------------+ | |||
| Figure 5: NTS Time Synchronization Messages | Figure 5: NTS-protected NTP Time Synchronization Messages | |||
| The client MAY include additional (non-NTS-related) extension fields | The client MAY include additional (non-NTS-related) extension fields | |||
| which MAY appear prior to the NTS Authenticator and Encrypted | which MAY appear prior to the NTS Authenticator and Encrypted | |||
| Extension Fields extension fields (therefore authenticated but not | Extension Fields extension fields (therefore authenticated but not | |||
| encrypted), within it (therefore encrypted and authenticated), or | encrypted), within it (therefore encrypted and authenticated), or | |||
| after it (therefore neither encrypted nor authenticated). In | after it (therefore neither encrypted nor authenticated). The server | |||
| general, however, the server MUST discard any unauthenticated | MUST discard any unauthenticated extension fields. Future | |||
| extension fields and process the packet as though they were not | specifications of extension fields MAY provide exceptions to this | |||
| present. Servers MAY implement exceptions to this requirement for | rule. | |||
| particular extension fields if their specification explicitly | ||||
| provides for such. | ||||
| Upon receiving an NTS-protected request, the server SHALL (through | Upon receiving an NTS-protected request, the server SHALL (through | |||
| some implementation-defined mechanism) use the cookie to recover the | some implementation-defined mechanism) use the cookie to recover the | |||
| AEAD Algorithm, C2S key, and S2C key associated with the request, and | AEAD Algorithm, C2S key, and S2C key associated with the request, and | |||
| then use the C2S key to authenticate the packet and decrypt the | then use the C2S key to authenticate the packet and decrypt the | |||
| ciphertext. If the cookie is valid and authentication and decryption | ciphertext. If the cookie is valid and authentication and decryption | |||
| succeed, the server SHALL include the following extension fields in | succeed, the server SHALL include the following extension fields in | |||
| its response: | its response: | |||
| Exactly one Unique Identifier extension field which MUST be | Exactly one Unique Identifier extension field which MUST be | |||
| skipping to change at page 22, line 48 ¶ | skipping to change at page 23, line 6 ¶ | |||
| within the NTS Authenticator and Encrypted Extensions extension | within the NTS Authenticator and Encrypted Extensions extension | |||
| field. While the body of an NTS Cookie extension field will | field. While the body of an NTS Cookie extension field will | |||
| generally consist of some sort of AEAD output (regardless of whether | generally consist of some sort of AEAD output (regardless of whether | |||
| the recommendations of Section 6 are precisely followed), this is not | the recommendations of Section 6 are precisely followed), this is not | |||
| sufficient to make the extension field "encrypted". | sufficient to make the extension field "encrypted". | |||
| The server MAY include additional (non-NTS-related) extension fields | The server MAY include additional (non-NTS-related) extension fields | |||
| which MAY appear prior to the NTS Authenticator and Encrypted | which MAY appear prior to the NTS Authenticator and Encrypted | |||
| Extension Fields extension field (therefore authenticated but not | Extension Fields extension field (therefore authenticated but not | |||
| encrypted), within it (therefore encrypted and authenticated), or | encrypted), within it (therefore encrypted and authenticated), or | |||
| after it (therefore neither encrypted nor authenticated). In | after it (therefore neither encrypted nor authenticated). The client | |||
| general, however, the client MUST discard any unauthenticated | MUST discard any unauthenticated extension fields. Future | |||
| extension fields and process the packet as though they were not | specifications of extension fields MAY provide exceptions to this | |||
| present. Clients MAY implement exceptions to this requirement for | rule. | |||
| particular extension fields if their specification explicitly | ||||
| provides for such. | ||||
| Upon receiving an NTS-protected response, the client MUST verify that | Upon receiving an NTS-protected response, the client MUST verify that | |||
| the Unique Identifier matches that of an outstanding request, and | the Unique Identifier matches that of an outstanding request, and | |||
| that the packet is authentic under the S2C key associated with that | that the packet is authentic under the S2C key associated with that | |||
| request. If either of these checks fails, the packet MUST be | request. If either of these checks fails, the packet MUST be | |||
| discarded without further processing. | discarded without further processing. In particular, the client MUST | |||
| discard unprotected responses to NTS-protected requests. | ||||
| If the server is unable to validate the cookie or authenticate the | If the server is unable to validate the cookie or authenticate the | |||
| request, it SHOULD respond with a Kiss-o'-Death (KoD) packet (see RFC | request, it SHOULD respond with a Kiss-o'-Death (KoD) packet (see RFC | |||
| 5905, Section 7.4 [RFC5905]) with kiss code "NTSN", meaning "NTS | 5905, Section 7.4 [RFC5905]) with kiss code "NTSN", meaning "NTS NAK" | |||
| negative-acknowledgment (NAK)". It MUST NOT include any NTS Cookie | (NTS negative-acknowledgment). It MUST NOT include any NTS Cookie or | |||
| or NTS Authenticator and Encrypted Extension Fields extension fields. | NTS Authenticator and Encrypted Extension Fields extension fields. | |||
| If the NTP server has previously responded with authentic NTS- | If the NTP server has previously responded with authentic NTS- | |||
| protected NTP packets (i.e., packets containing the NTS Authenticator | protected NTP packets, the client MUST verify that any KoD packets | |||
| and Encrypted Extension Fields extension field), the client MUST | received from the server contain the Unique Identifier extension | |||
| verify that any KoD packets received from the server contain the | field and that the Unique Identifier matches that of an outstanding | |||
| Unique Identifier extension field and that the Unique Identifier | request. If this check fails, the packet MUST be discarded without | |||
| matches that of an outstanding request. If this check fails, the | further processing. If this check passes, the client MUST comply | |||
| packet MUST be discarded without further processing. If this check | with RFC 5905, Section 7.4 [RFC5905] where required. | |||
| passes, the client MUST comply with RFC 5905, Section 7.4 [RFC5905] | ||||
| where required. A client MAY automatically re-run the NTS-KE | A client MAY automatically re-run the NTS-KE protocol upon forced | |||
| protocol upon forced disassociation from an NTP server. In that | disassociation from an NTP server. In that case, it MUST avoid | |||
| case, it MUST be able to detect and stop looping between the NTS-KE | quickly looping between the NTS-KE and NTP servers by rate limiting | |||
| and NTP servers by rate limiting the retries using e.g. exponential | the retries. Requirements for retry intervals in NTS-KE are | |||
| retry intervals. | described in Section 4.2. | |||
| Upon reception of the NTS NAK kiss code, the client SHOULD wait until | Upon reception of the NTS NAK kiss code, the client SHOULD wait until | |||
| the next poll for a valid NTS-protected response and if none is | the next poll for a valid NTS-protected response and if none is | |||
| received, initiate a fresh NTS-KE handshake to try to renegotiate new | received, initiate a fresh NTS-KE handshake to try to renegotiate new | |||
| cookies, AEAD keys, and parameters. If the NTS-KE handshake | cookies, AEAD keys, and parameters. If the NTS-KE handshake | |||
| succeeds, the client MUST discard all old cookies and parameters and | succeeds, the client MUST discard all old cookies and parameters and | |||
| use the new ones instead. As long as the NTS-KE handshake has not | use the new ones instead. As long as the NTS-KE handshake has not | |||
| succeeded, the client SHOULD continue polling the NTP server using | succeeded, the client SHOULD continue polling the NTP server using | |||
| the cookies and parameters it has. | the cookies and parameters it has. | |||
| skipping to change at page 23, line 46 ¶ | skipping to change at page 24, line 4 ¶ | |||
| cookies, AEAD keys, and parameters. If the NTS-KE handshake | cookies, AEAD keys, and parameters. If the NTS-KE handshake | |||
| succeeds, the client MUST discard all old cookies and parameters and | succeeds, the client MUST discard all old cookies and parameters and | |||
| use the new ones instead. As long as the NTS-KE handshake has not | use the new ones instead. As long as the NTS-KE handshake has not | |||
| succeeded, the client SHOULD continue polling the NTP server using | succeeded, the client SHOULD continue polling the NTP server using | |||
| the cookies and parameters it has. | the cookies and parameters it has. | |||
| To allow for NTP session restart when the NTS-KE server is | To allow for NTP session restart when the NTS-KE server is | |||
| unavailable and to reduce NTS-KE server load, the client SHOULD keep | unavailable and to reduce NTS-KE server load, the client SHOULD keep | |||
| at least one unused but recent cookie, AEAD keys, negotiated AEAD | at least one unused but recent cookie, AEAD keys, negotiated AEAD | |||
| algorithm, and other necessary parameters on persistent storage. | algorithm, and other necessary parameters on persistent storage. | |||
| This way, the client is able to resume the NTP session without | This way, the client is able to resume the NTP session without | |||
| performing renewed NTS-KE negotiation. | performing renewed NTS-KE negotiation. | |||
| 6. Suggested Format for NTS Cookies | 6. Suggested Format for NTS Cookies | |||
| This section is non-normative. It gives a suggested way for servers | This section is non-normative. It gives a suggested way for servers | |||
| to construct NTS cookies. All normative requirements are stated in | to construct NTS cookies. All normative requirements are stated in | |||
| Section 4.1.6 and Section 5.4. | Section 4.1.6 and Section 5.4. | |||
| The role of cookies in NTS is closely analogous to that of session | The role of cookies in NTS is closely analogous to that of session | |||
| cookies in TLS. Accordingly, the thematic resemblance of this | cookies in TLS. Accordingly, the thematic resemblance of this | |||
| section to RFC 5077 [RFC5077] is deliberate and the reader should | section to RFC 5077 [RFC5077] is deliberate and the reader should | |||
| likewise take heed of its security considerations. | likewise take heed of its security considerations. | |||
| Servers should select an AEAD algorithm which they will use to | Servers should select an AEAD algorithm which they will use to | |||
| encrypt and authenticate cookies. The chosen algorithm should be one | encrypt and authenticate cookies. The chosen algorithm should be one | |||
| such as AEAD_AES_SIV_CMAC_256 [RFC5297] which resists accidental | such as AEAD_AES_SIV_CMAC_256 [RFC5297] which resists accidental | |||
| nonce reuse. It need not be the same as the one that was negotiated | nonce reuse. It need not be the same as the one that was negotiated | |||
| with the client. Servers should randomly generate and store a master | with the client. Servers should randomly generate and store a secret | |||
| AEAD key `K`. Servers should additionally choose a non-secret, unique | master AEAD key `K`. Servers should additionally choose a non-secret, | |||
| value `I` as key-identifier for `K`. | unique value `I` as key-identifier for `K`. | |||
| Servers should periodically (e.g., once daily) generate a new pair | Servers should periodically (e.g., once daily) generate a new pair | |||
| (I,K) and immediately switch to using these values for all newly- | `(I,K)` and immediately switch to using these values for all newly- | |||
| generated cookies. Immediately following each such key rotation, | generated cookies. Following each such key rotation, servers should | |||
| servers should securely erase any keys generated two or more rotation | securely erase any previously generated keys that should now be | |||
| periods prior. Servers should continue to accept any cookie | expired. Servers should continue to accept any cookie generated | |||
| generated using keys that they have not yet erased, even if those | using keys that they have not yet erased, even if those keys are no | |||
| keys are no longer current. Erasing old keys provides for forward | longer current. Erasing old keys provides for forward secrecy, | |||
| secrecy, limiting the scope of what old information can be stolen if | limiting the scope of what old information can be stolen if a master | |||
| a master key is somehow compromised. Holding on to a limited number | key is somehow compromised. Holding on to a limited number of old | |||
| of old keys allows clients to seamlessly transition from one | keys allows clients to seamlessly transition from one generation to | |||
| generation to the next without having to perform a new NTS-KE | the next without having to perform a new NTS-KE handshake. | |||
| handshake. | ||||
| The need to keep keys synchronized between NTS-KE and NTP servers as | The need to keep keys synchronized between NTS-KE and NTP servers as | |||
| well as across load-balanced clusters can make automatic key rotation | well as across load-balanced clusters can make automatic key rotation | |||
| challenging. However, the task can be accomplished without the need | challenging. However, the task can be accomplished without the need | |||
| for central key-management infrastructure by using a ratchet, i.e., | for central key-management infrastructure by using a ratchet, i.e., | |||
| making each new key a deterministic, cryptographically pseudo-random | making each new key a deterministic, cryptographically pseudo-random | |||
| function of its predecessor. A recommended concrete implementation | function of its predecessor. A recommended concrete implementation | |||
| of this approach is to use HKDF [RFC5869] to derive new keys, using | of this approach is to use HKDF [RFC5869] to derive new keys, using | |||
| the key's predecessor as Input Keying Material and its key identifier | the key's predecessor as Input Keying Material and its key identifier | |||
| as a salt. | as a salt. | |||
| skipping to change at page 25, line 38 ¶ | skipping to change at page 25, line 40 ¶ | |||
| and Transport Protocol Port Number Registry [RFC6335]: | and Transport Protocol Port Number Registry [RFC6335]: | |||
| Service Name: ntske | Service Name: ntske | |||
| Transport Protocol: tcp | Transport Protocol: tcp | |||
| Assignee: IESG <iesg@ietf.org> | Assignee: IESG <iesg@ietf.org> | |||
| Contact: IETF Chair <chair@ietf.org> | Contact: IETF Chair <chair@ietf.org> | |||
| Description: Network Time Security Key Exchange | Description: Network Time Security Key Establishment | |||
| Reference: [[this memo]] | Reference: [[this memo]] | |||
| Port Number: [[TBD1]], selected by IANA from the User Port range | Port Number: [[TBD1]], selected by IANA from the User Port range | |||
| [[RFC EDITOR: Replace all instances of [[TBD1]] in this document with | [[RFC EDITOR: Replace all instances of [[TBD1]] in this document with | |||
| the IANA port assignment.]] | the IANA port assignment.]] | |||
| 7.2. TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs | 7.2. TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs | |||
| Registry | Registry | |||
| skipping to change at page 26, line 17 ¶ | skipping to change at page 26, line 24 ¶ | |||
| Identification Sequence: | Identification Sequence: | |||
| 0x6E 0x74 0x73 0x6B 0x65 0x2F 0x31 ("ntske/1") | 0x6E 0x74 0x73 0x6B 0x65 0x2F 0x31 ("ntske/1") | |||
| 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 | Y | [[this | | | | EXPORTER-network- | Y | Y | [[this memo]], | | | |||
| | time-security/1 | | | memo]], | | | | time-security | | | Section 4.3 | | | |||
| | | | | 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]: | |||
| +------+---------------------------------------+--------------------+ | +------+---------------------------------------+--------------------+ | |||
| | Code | Meaning | Reference | | | Code | Meaning | Reference | | |||
| +------+---------------------------------------+--------------------+ | +------+---------------------------------------+--------------------+ | |||
| | NTSN | Network Time Security (NTS) negative- | [[this memo]], | | | NTSN | Network Time Security (NTS) negative- | [[this memo]], | | |||
| skipping to change at page 27, line 11 ¶ | skipping to change at page 27, line 11 ¶ | |||
| IANA is requested to allocate the following entries in the NTP | IANA is requested to allocate the following entries in the NTP | |||
| Extension Field Types registry [RFC5905]: | Extension Field Types registry [RFC5905]: | |||
| +----------+-----------------------------+--------------------------+ | +----------+-----------------------------+--------------------------+ | |||
| | Field | Meaning | Reference | | | Field | Meaning | Reference | | |||
| | Type | | | | | Type | | | | |||
| +----------+-----------------------------+--------------------------+ | +----------+-----------------------------+--------------------------+ | |||
| | [[TBD2]] | Unique Identifier | [[this memo]], | | | [[TBD2]] | Unique Identifier | [[this memo]], | | |||
| | | | Section 5.3 | | | | | Section 5.3 | | |||
| | [[TBD3]] | NTS Cookie | [[this memo]], Section | | | [[TBD3]] | NTS Cookie | [[this memo]], | | |||
| | | | 5.4 | | | | | Section 5.4 | | |||
| | [[TBD4]] | NTS Cookie Placeholder | [[this memo]], | | | [[TBD4]] | NTS Cookie Placeholder | [[this memo]], | | |||
| | | | Section 5.5 | | | | | Section 5.5 | | |||
| | [[TBD5]] | NTS Authenticator and | [[this memo]], Section | | | [[TBD5]] | NTS Authenticator and | [[this memo]], | | |||
| | | Encrypted Extension Fields | 5.6 | | | | Encrypted Extension Fields | Section 5.6 | | |||
| +----------+-----------------------------+--------------------------+ | +----------+-----------------------------+--------------------------+ | |||
| [[RFC EDITOR: REMOVE BEFORE PUBLICATION - The NTP WG suggests that | ||||
| the following values be used: | ||||
| Unique Identifier 0x0104 | ||||
| NTS Cookie 0x0204 | ||||
| Cookie Placeholder 0x0304 | ||||
| NTS Authenticator 0x0404]] | ||||
| [[RFC EDITOR: Replace all instances of [[TBD2]], [[TBD3]], [[TBD4]], | [[RFC EDITOR: Replace all instances of [[TBD2]], [[TBD3]], [[TBD4]], | |||
| and [[TBD5]] in this document with the respective IANA assignments. | and [[TBD5]] in this document with the respective IANA assignments.]] | |||
| 7.6. Network Time Security Key Establishment Record Types Registry | 7.6. Network Time Security Key Establishment Record Types Registry | |||
| IANA is requested to create a new registry entitled "Network Time | IANA is requested to create a new registry entitled "Network Time | |||
| Security Key Establishment Record Types". Entries SHALL have the | Security Key Establishment Record Types". Entries SHALL have the | |||
| following fields: | following fields: | |||
| Record Type Number (REQUIRED): An integer in the range 0-32767 | Record Type Number (REQUIRED): An integer in the range 0-32767 | |||
| inclusive. | inclusive. | |||
| skipping to change at page 27, line 46 ¶ | skipping to change at page 28, line 5 ¶ | |||
| 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, Set Critical Bit, 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]], Section | | | 0 | End of Message | [[this memo]], | | |||
| | | | 4.1.1 | | | | | Section 4.1.1 | | |||
| | 1 | NTS Next Protocol | [[this memo]], | | | 1 | NTS Next Protocol | [[this memo]], | | |||
| | | Negotiation | Section 4.1.2 | | | | Negotiation | Section 4.1.2 | | |||
| | 2 | Error | [[this memo]], Section | | | 2 | Error | [[this memo]], | | |||
| | | | 4.1.3 | | | | | Section 4.1.3 | | |||
| | 3 | Warning | [[this memo]], Section | | | 3 | Warning | [[this memo]], | | |||
| | | | 4.1.4 | | | | | Section 4.1.4 | | |||
| | 4 | AEAD Algorithm | [[this memo]], Section | | | 4 | AEAD Algorithm | [[this memo]], | | |||
| | | Negotiation | 4.1.5 | | | | Negotiation | Section 4.1.5 | | |||
| | 5 | New Cookie for NTPv4 | [[this memo]], Section | | | 5 | New Cookie for NTPv4 | [[this memo]], | | |||
| | | | 4.1.6 | | | | | Section 4.1.6 | | |||
| | 6 | NTPv4 Server | [[this memo]], Section | | | 6 | NTPv4 Server | [[this memo]], | | |||
| | | Negotiation | 4.1.7 | | | | Negotiation | Section 4.1.7 | | |||
| | 7 | NTPv4 Port Negotiation | [[this memo]], Section | | | 7 | NTPv4 Port Negotiation | [[this memo]], | | |||
| | | | 4.1.8 | | | | | Section 4.1.8 | | |||
| | 16384-32767 | Reserved for Private & | [[this memo]] | | | 16384-32767 | Reserved for Private & | [[this memo]] | | |||
| | | Experimental Use | | | | | Experimental Use | | | |||
| +-------------+-------------------------+---------------------------+ | +-------------+-------------------------+---------------------------+ | |||
| 7.7. Network Time Security Next Protocols Registry | 7.7. Network Time Security Next Protocols Registry | |||
| IANA is requested to create a new registry entitled "Network Time | IANA is requested to create a new registry entitled "Network Time | |||
| Security Next Protocols". Entries SHALL have the following fields: | Security Next Protocols". Entries SHALL have the following fields: | |||
| Protocol ID (REQUIRED): An integer in the range 0-65535 inclusive, | Protocol ID (REQUIRED): An integer in the range 0-65535 inclusive, | |||
| skipping to change at page 33, line 49 ¶ | skipping to change at page 33, line 49 ¶ | |||
| 8.5.3. Contact Information | 8.5.3. Contact Information | |||
| Contact Watson Ladd: watson@cloudflare.com | Contact Watson Ladd: watson@cloudflare.com | |||
| 8.5.4. Last Update | 8.5.4. Last Update | |||
| The implementation was updated 21. March 2019. | The implementation was updated 21. March 2019. | |||
| 8.6. Implementation 6 | 8.6. Implementation 6 | |||
| Organization: Netnod | Organization: Hacklunch, independent | |||
| Implementor: Michael Cardell Widerkrantz et. al. | Implementor: Michael Cardell Widerkrantz, Daniel Lublin, Martin | |||
| Samuelsson et. al. | ||||
| Maturity: Early proof of concept | Maturity: interoperable client, immature server | |||
| 8.6.1. Coverage | 8.6.1. Coverage | |||
| NTS-KE client and server. | NTS-KE client and server. | |||
| 8.6.2. Licensing | 8.6.2. Licensing | |||
| ???? | Licensing is ISC (details in LICENSE file). | |||
| The source code is available at: https://github.com/mchackorg/gonts | Source code is available at: https://gitlab.com/hacklunch/ntsclient | |||
| 8.6.3. Contact Information | 8.6.3. Contact Information | |||
| Contact Michael Cardell Widerkrantz: mc@netnod.se | Contact Michael Cardell Widerkrantz: mc@netnod.se | |||
| 8.6.4. Last Update | 8.6.4. Last Update | |||
| The implementation was updated 24. March 2019. | The implementation was updated 6. February 2020. | |||
| 8.7. Interoperability | 8.7. Interoperability | |||
| The Interoperability tests distinguished between NTS key | The Interoperability tests distinguished between NTS key | |||
| establishment protocol and NTS time exchange messages. For the | establishment protocol and NTS time exchange messages. For the | |||
| implementations 1, 2, 3, and 4 pairwise interoperability of the NTS | implementations 1, 2, 3, and 4 pairwise interoperability of the NTS | |||
| key establishment protocol and exchange of NTS protected NTP messages | key establishment protocol and exchange of NTS protected NTP messages | |||
| have been verified successfully. The implementation 2 was able to | have been verified successfully. The implementation 2 was able to | |||
| successfully perform the key establishment protocol against the | successfully perform the key establishment protocol against the | |||
| server side of the implementation 5. | server side of the implementation 5. | |||
| skipping to change at page 35, line 5 ¶ | skipping to change at page 35, line 5 ¶ | |||
| 9.1. Protected Modes | 9.1. Protected Modes | |||
| NTP provides many different operating modes in order to support | NTP provides many different operating modes in order to support | |||
| different network topologies and to adapt to various requirements. | different network topologies and to adapt to various requirements. | |||
| This memo only specifies NTS for NTP modes 3 (client) and 4 (server) | This memo only specifies NTS for NTP modes 3 (client) and 4 (server) | |||
| (see Section 1.2). The best current practice for authenticating the | (see Section 1.2). The best current practice for authenticating the | |||
| other NTP modes is using the symmetric message authentication code | other NTP modes is using the symmetric message authentication code | |||
| feature as described in RFC 5905 [RFC5905] and RFC 8573 [RFC8573]. | feature as described in RFC 5905 [RFC5905] and RFC 8573 [RFC8573]. | |||
| 9.2. Sensitivity to DDoS Attacks | 9.2. Cookie Encryption Key Compromise | |||
| If the suggested format for NTS cookies in Section 6 of this draft is | ||||
| used, an attacker who has gained access to the secret cookie | ||||
| encryption key `K` can impersonate the NTP server, including | ||||
| generating new cookies. NTP and NTS-KE server operators SHOULD | ||||
| remove compromised keys as soon as the compromise is discovered. | ||||
| This will cause the NTP servers to respond with NTS NAK, thus forcing | ||||
| key renegotiation. Note that this measure does not protect against | ||||
| MITM attacks where the attacker has access to a compromised cookie | ||||
| encryption key. If another cookie scheme is used, there are likely | ||||
| similar considerations for that particular scheme. | ||||
| 9.3. 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 | |||
| symmetric counterparts. This makes it much harder to build systems | symmetric counterparts. This makes it much harder to build systems | |||
| that can serve requests at a rate corresponding to the full line | that can serve requests at a rate corresponding to the full line | |||
| speed of the network connection. This, in turn, opens up a new | speed of the network connection. This, in turn, opens up a new | |||
| possibility for DDoS attacks on NTP services. | possibility for DDoS attacks on NTP services. | |||
| The main protection against these attacks in NTS lies in that the use | The main protection against these attacks in NTS lies in that the use | |||
| of asymmetric cryptosystems is only necessary in the initial NTS-KE | of asymmetric cryptosystems is only necessary in the initial NTS-KE | |||
| phase of the protocol. Since the protocol design enables separation | phase of the protocol. Since the protocol design enables separation | |||
| of the NTS-KE and NTP servers, a successful DDoS attack on an NTS-KE | of the NTS-KE and NTP servers, a successful DDoS attack on an NTS-KE | |||
| server separated from the NTP service it supports will not affect NTP | server separated from the NTP service it supports will not affect NTP | |||
| users that have already performed initial authentication, AEAD key | users that have already performed initial authentication, AEAD key | |||
| extraction, and cookie exchange. | extraction, and cookie exchange. | |||
| NTS users should also consider that they are not fully protected | NTS users should also consider that they are not fully protected | |||
| against DDoS attacks by on-path adversaries. In addition to dropping | against DoS attacks by on-path adversaries. In addition to dropping | |||
| packets and attacks such as those described in Section 9.5, an on- | packets and attacks such as those described in Section 9.6, an on- | |||
| path attacker can send spoofed kiss-o'-death replies, which are not | path attacker can send spoofed kiss-o'-death replies, which are not | |||
| authenticated, in response to NTP requests. This could result in | authenticated, in response to NTP requests. This could result in | |||
| significantly increased load on the NTS-KE server. Implementers have | significantly increased load on the NTS-KE server. Implementers have | |||
| to weigh the user's need for unlinkability against the added | to weigh the user's need for unlinkability against the added | |||
| resilience that comes with cookie reuse in cases of NTS-KE server | resilience that comes with cookie reuse in cases of NTS-KE server | |||
| unavailability. | unavailability. | |||
| 9.3. Avoiding DDoS Amplification | 9.4. Avoiding DDoS Amplification | |||
| Certain non-standard and/or deprecated features of the Network Time | Certain non-standard and/or deprecated features of the Network Time | |||
| Protocol enable clients to send a request to a server which causes | Protocol enable clients to send a request to a server which causes | |||
| the server to send a response much larger than the request. Servers | the server to send a response much larger than the request. Servers | |||
| which enable these features can be abused in order to amplify traffic | which enable these features can be abused in order to amplify traffic | |||
| volume in DDoS attacks by sending them a request with a spoofed | volume in DDoS attacks by sending them a request with a spoofed | |||
| source IP. In recent years, attacks of this nature have become an | source IP. In recent years, attacks of this nature have become an | |||
| endemic nuisance. | endemic nuisance. | |||
| NTS is designed to avoid contributing any further to this problem by | NTS is designed to avoid contributing any further to this problem by | |||
| skipping to change at page 36, line 10 ¶ | skipping to change at page 36, line 21 ¶ | |||
| sent by the client. In particular, this is why the client is | sent by the client. In particular, this is why the client is | |||
| required to send a separate and appropriately padded-out NTS Cookie | required to send a separate and appropriately padded-out NTS Cookie | |||
| Placeholder extension field for every cookie it wants to get back, | Placeholder extension field for every cookie it wants to get back, | |||
| rather than being permitted simply to specify a desired quantity. | rather than being permitted simply to specify a desired quantity. | |||
| Due to the RFC 7822 [RFC7822] requirement that extensions be padded | Due to the RFC 7822 [RFC7822] requirement that extensions be padded | |||
| and aligned to four-octet boundaries, response size may still in some | and aligned to four-octet boundaries, response size may still in some | |||
| cases exceed request size by up to three octets. This is | cases exceed request size by up to three octets. This is | |||
| sufficiently inconsequential that we have declined to address it. | sufficiently inconsequential that we have declined to address it. | |||
| 9.4. Initial Verification of Server Certificates | 9.5. Initial Verification of Server Certificates | |||
| NTS's security goals are undermined if the client fails to verify | NTS's security goals are undermined if the client fails to verify | |||
| that the X.509 certificate chain presented by the NTS-KE server is | that the X.509 certificate chain presented by the NTS-KE server is | |||
| valid and rooted in a trusted certificate authority. RFC 5280 | valid and rooted in a trusted certificate authority. RFC 5280 | |||
| [RFC5280] and RFC 6125 [RFC6125] specify how such verification is to | [RFC5280] and RFC 6125 [RFC6125] specify how such verification is to | |||
| be performed in general. However, the expectation that the client | be performed in general. However, the expectation that the client | |||
| does not yet have a correctly-set system clock at the time of | does not yet have a correctly-set system clock at the time of | |||
| certificate verification presents difficulties with verifying that | certificate verification presents difficulties with verifying that | |||
| the certificate is within its validity period, i.e., that the current | the certificate is within its validity period, i.e., that the current | |||
| time lies between the times specified in the certificate's notBefore | time lies between the times specified in the certificate's notBefore | |||
| and notAfter fields. It may be operationally necessary in some cases | and notAfter fields. It may be operationally necessary in some cases | |||
| for a client to accept a certificate which appears to be expired or | for a client to accept a certificate which appears to be expired or | |||
| not yet valid. While there is no perfect solution to this problem, | not yet valid. While there is no perfect solution to this problem, | |||
| there are several mitigations the client can implement to make it | there are several mitigations the client can implement to make it | |||
| more difficult for an adversary to successfully present an expired | more difficult for an adversary to successfully present an expired | |||
| certificate: | certificate: | |||
| Check whether the system time is in fact unreliable. If the | Check whether the system time is in fact unreliable. On systems | |||
| system clock has previously been synchronized since last boot, | with the ntp_adjtime() system call, a return code other than | |||
| then on operating systems which implement a kernel-based phase- | TIME_ERROR indicates that some trusted software has already set | |||
| locked-loop API, a call to ntp_gettime() should show a maximum | the time and certificates can be strictly validated. | |||
| error less than NTP_PHASE_MAX. In this case, the clock SHOULD be | ||||
| considered reliable and certificates can be strictly validated. | ||||
| Allow the system administrator to specify that certificates should | Allow the system administrator to specify that certificates should | |||
| *always* be strictly validated. Such a configuration is | *always* be strictly validated. Such a configuration is | |||
| appropriate on systems which have a battery-backed clock and which | appropriate on systems which have a battery-backed clock and which | |||
| can reasonably prompt the user to manually set an approximately- | can reasonably prompt the user to manually set an approximately- | |||
| correct time if it appears to be needed. | correct time if it appears to be needed. | |||
| Once the clock has been synchronized, periodically write the | Once the clock has been synchronized, periodically write the | |||
| current system time to persistent storage. Do not accept any | current system time to persistent storage. Do not accept any | |||
| certificate whose notAfter field is earlier than the last recorded | certificate whose notAfter field is earlier than the last recorded | |||
| skipping to change at page 37, line 16 ¶ | skipping to change at page 37, line 26 ¶ | |||
| server, for example by picking a random time in the week preceding | server, for example by picking a random time in the week preceding | |||
| certificate expiry to perform the new handshake. | certificate expiry to perform the new handshake. | |||
| Use multiple time sources. The ability to pass off an expired | Use multiple time sources. The ability to pass off an expired | |||
| certificate is only useful to an adversary who has compromised the | certificate is only useful to an adversary who has compromised the | |||
| corresponding private key. If the adversary has compromised only | corresponding private key. If the adversary has compromised only | |||
| a minority of servers, NTP's selection algorithm (RFC 5905 section | a minority of servers, NTP's selection algorithm (RFC 5905 section | |||
| 11.2.1 [RFC5905]) will protect the client from accepting bad time | 11.2.1 [RFC5905]) will protect the client from accepting bad time | |||
| from the adversary-controlled servers. | from the adversary-controlled servers. | |||
| 9.5. Delay Attacks | 9.6. Delay Attacks | |||
| In a packet delay attack, an adversary with the ability to act as a | In a packet delay attack, an adversary with the ability to act as a | |||
| man-in-the-middle delays time synchronization packets between client | man-in-the-middle delays time synchronization packets between client | |||
| and server asymmetrically [RFC7384]. Since NTP's formula for | and server asymmetrically [RFC7384]. Since NTP's formula for | |||
| computing time offset relies on the assumption that network latency | computing time offset relies on the assumption that network latency | |||
| is roughly symmetrical, this leads to the client to compute an | is roughly symmetrical, this leads to the client to compute an | |||
| inaccurate value [Mizrahi]. The delay attack does not reorder or | inaccurate value [Mizrahi]. The delay attack does not reorder or | |||
| modify the content of the exchanged synchronization packets. | modify the content of the exchanged synchronization packets. | |||
| Therefore, cryptographic means do not provide a feasible way to | Therefore, cryptographic means do not provide a feasible way to | |||
| mitigate this attack. However, the maximum error that an adversary | mitigate this attack. However, the maximum error that an adversary | |||
| skipping to change at page 37, line 43 ¶ | skipping to change at page 38, line 5 ¶ | |||
| client will tolerate before concluding that the server is unsuitable | client will tolerate before concluding that the server is unsuitable | |||
| for synchronization. The standard value for MAXDIST is one second, | for synchronization. The standard value for MAXDIST is one second, | |||
| although some implementations use larger values. Whatever value a | although some implementations use larger values. Whatever value a | |||
| client chooses, the maximum error which can be introduced by a delay | client chooses, the maximum error which can be introduced by a delay | |||
| attack is MAXDIST/2. | attack is MAXDIST/2. | |||
| Usage of multiple time sources, or multiple network paths to a given | Usage of multiple time sources, or multiple network paths to a given | |||
| time source [Shpiner], may also serve to mitigate delay attacks if | time source [Shpiner], may also serve to mitigate delay attacks if | |||
| the adversary is in control of only some of the paths. | the adversary is in control of only some of the paths. | |||
| 9.6. Random Number Generation | ||||
| At various points in NTS, the generation of cryptographically secure | ||||
| random numbers is required. Whenever this draft specifies the use of | ||||
| random numbers, cryptographically secure random number generation | ||||
| MUST be used. RFC 4086 [RFC4086] contains guidelines concerning this | ||||
| topic. | ||||
| 9.7. NTS Stripping | 9.7. NTS Stripping | |||
| Implementers must be aware of the possibility of "NTS stripping" | Implementers must be aware of the possibility of "NTS stripping" | |||
| attacks, where an attacker tricks clients into reverting to plain | attacks, where an attacker attempts to trick clients into reverting | |||
| NTP. Naive client implementations might, for example, revert | to plain NTP. Naive client implementations might, for example, | |||
| automatically to plain NTP if the NTS-KE handshake fails. A man-in- | revert automatically to plain NTP if the NTS-KE handshake fails. A | |||
| the-middle attacker can easily cause this to happen. Even clients | man-in-the-middle attacker can easily cause this to happen. Even | |||
| that already hold valid cookies can be vulnerable, since an attacker | clients that already hold valid cookies can be vulnerable, since an | |||
| can force a client to repeat the NTS-KE handshake by sending faked | attacker can force a client to repeat the NTS-KE handshake by sending | |||
| NTP mode 4 replies with the NTS NAK kiss code. Forcing a client to | faked NTP mode 4 replies with the NTS NAK kiss code. Forcing a | |||
| repeat the NTS-KE handshake can also be the first step in more | client to repeat the NTS-KE handshake can also be the first step in | |||
| advanced attacks. | more advanced attacks. | |||
| For the reasons described here, implementations SHOULD NOT revert | For the reasons described here, implementations SHOULD NOT revert | |||
| from NTS-protected to unprotected NTP with any server without | from NTS-protected to unprotected NTP with any server without | |||
| explicit user action. | explicit user action. | |||
| 10. Privacy Considerations | 10. Privacy Considerations | |||
| 10.1. Unlinkability | 10.1. Unlinkability | |||
| Unlinkability prevents a device from being tracked when it changes | Unlinkability prevents a device from being tracked when it changes | |||
| skipping to change at page 38, line 44 ¶ | skipping to change at page 38, line 44 ¶ | |||
| recognizable data in the sense outlined above. | recognizable data in the sense outlined above. | |||
| NTS's unlinkability objective is merely to not leak any additional | NTS's unlinkability objective is merely to not leak any additional | |||
| data that could be used to link a device's network address. NTS does | data that could be used to link a device's network address. NTS does | |||
| not rectify legacy linkability issues that are already present in | not rectify legacy linkability issues that are already present in | |||
| NTP. Thus, a client that requires unlinkability must also minimize | NTP. Thus, a client that requires unlinkability must also minimize | |||
| information transmitted in a client query (mode 3) packet as | information transmitted in a client query (mode 3) packet as | |||
| described in the draft [I-D.ietf-ntp-data-minimization]. | described in the draft [I-D.ietf-ntp-data-minimization]. | |||
| The unlinkability objective only holds for time synchronization | The unlinkability objective only holds for time synchronization | |||
| traffic, as opposed to key exchange traffic. This implies that it | traffic, as opposed to key establishment traffic. This implies that | |||
| cannot be guaranteed for devices that function not only as time | it cannot be guaranteed for devices that function not only as time | |||
| clients, but also as time servers (because the latter can be | clients, but also as time servers (because the latter can be | |||
| externally triggered to send authentication data). | externally triggered to send linkable data, such as the TLS | |||
| certificate). | ||||
| It should also be noted that it could be possible to link devices | It should also be noted that it could be possible to link devices | |||
| that operate as time servers from their time synchronization traffic, | that operate as time servers from their time synchronization traffic, | |||
| using information exposed in (mode 4) server response packets (e.g. | using information exposed in (mode 4) server response packets (e.g. | |||
| reference ID, reference time, stratum, poll). Also, devices that | reference ID, reference time, stratum, poll). Also, devices that | |||
| respond to NTP control queries could be linked using the information | respond to NTP control queries could be linked using the information | |||
| revealed by control queries. | revealed by control queries. | |||
| Note that the unlinkability objective does not prevent a client | Note that the unlinkability objective does not prevent a client | |||
| device to be tracked by its time servers. | device to be tracked by its time servers. | |||
| 10.2. Confidentiality | 10.2. Confidentiality | |||
| NTS does not protect the confidentiality of information in NTP's | NTS does not protect the confidentiality of information in NTP's | |||
| skipping to change at page 39, line 29 ¶ | skipping to change at page 39, line 31 ¶ | |||
| and all other fields are set the same regardless of the identity of | and all other fields are set the same regardless of the identity of | |||
| the client making the request. | the client making the request. | |||
| Future extension fields could hypothetically contain sensitive | Future extension fields could hypothetically contain sensitive | |||
| information, in which case NTS provides a mechanism for encrypting | information, in which case NTS provides a mechanism for encrypting | |||
| them. | them. | |||
| 11. Acknowledgements | 11. Acknowledgements | |||
| The authors would like to thank Richard Barnes, Steven Bellovin, | The authors would like to thank Richard Barnes, Steven Bellovin, | |||
| Patrik Faeltstroem (Faltstrom), Scott Fluhrer, Sharon Goldberg, Russ | Scott Fluhrer, Patrik Faeltstroem (Faltstrom), Sharon Goldberg, Russ | |||
| Housley, Martin Langer, Miroslav Lichvar, Aanchal Malhotra, Dave | Housley, Benjamin Kaduk, Suresh Krishnan, Mirja Kuehlewind | |||
| Mills, Danny Mayer, Karen O'Donoghue, Eric K. Rescorla, Stephen | (Kuehlewind), Martin Langer, Barry Leiba, Miroslav Lichvar, Aanchal | |||
| Roettger, Kurt Roeckx, Kyle Rose, Rich Salz, Brian Sniffen, Susan | Malhotra, Danny Mayer, Dave Mills, Sandra Murphy, Hal Murray, Karen | |||
| Sons, Douglas Stebila, Harlan Stenn, Joachim Stroembergsson | O'Donoghue, Eric K. Rescorla, Kurt Roeckx, Stephen Roettger, Dan | |||
| (Strombergsson), Martin Thomson, Richard Welty, and Christer Weinigel | Romascanu, Kyle Rose, Rich Salz, Brian Sniffen, Susan Sons, Douglas | |||
| for contributions to this document and comments on the design of NTS. | Stebila, Harlan Stenn, Joachim Stroembergsson (Strombergsson), Martin | |||
| Thomson, Eric (Eric) Vyncke, Richard Welty, Christer Weinigel, and | ||||
| Magnus Westerlund for contributions to this document and comments on | ||||
| the design of NTS. | ||||
| 12. References | 12. References | |||
| 12.1. Normative References | 12.1. Normative References | |||
| [ANSI.X3-4.1986] | [IANA-AEAD] | |||
| American National Standards Institute, "Coded Character | IANA, "Authenticated Encryption with Associated Data | |||
| Set - 7-bit American Standard Code for Information | (AEAD) Parameters", | |||
| Interchange", ANSI X3.4, 1986. | <https://www.iana.org/assignments/aead-parameters/>. | |||
| [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, | ||||
| RFC 20, DOI 10.17487/RFC0020, October 1969, | ||||
| <https://www.rfc-editor.org/info/rfc20>. | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing | [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing | |||
| Architecture", RFC 4291, DOI 10.17487/RFC4291, February | Architecture", RFC 4291, DOI 10.17487/RFC4291, February | |||
| 2006, <https://www.rfc-editor.org/info/rfc4291>. | 2006, <https://www.rfc-editor.org/info/rfc4291>. | |||
| [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated | [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated | |||
| Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, | Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, | |||
| <https://www.rfc-editor.org/info/rfc5116>. | <https://www.rfc-editor.org/info/rfc5116>. | |||
| [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | ||||
| Housley, R., 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] Harkins, D., "Synthetic Initialization Vector (SIV) | [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) | |||
| Authenticated Encryption Using the Advanced Encryption | Authenticated Encryption Using the Advanced Encryption | |||
| Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October | Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October | |||
| 2008, <https://www.rfc-editor.org/info/rfc5297>. | 2008, <https://www.rfc-editor.org/info/rfc5297>. | |||
| [RFC5705] Rescorla, E., "Keying Material Exporters for Transport | [RFC5705] Rescorla, E., "Keying Material Exporters for Transport | |||
| Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, | Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, | |||
| March 2010, <https://www.rfc-editor.org/info/rfc5705>. | March 2010, <https://www.rfc-editor.org/info/rfc5705>. | |||
| [RFC5891] Klensin, J., "Internationalized Domain Names in | [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand | |||
| Applications (IDNA): Protocol", RFC 5891, | Key Derivation Function (HKDF)", RFC 5869, | |||
| DOI 10.17487/RFC5891, August 2010, | DOI 10.17487/RFC5869, May 2010, | |||
| <https://www.rfc-editor.org/info/rfc5891>. | <https://www.rfc-editor.org/info/rfc5869>. | |||
| [RFC5890] Klensin, J., "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] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, | [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, | |||
| "Network Time Protocol Version 4: Protocol and Algorithms | "Network Time Protocol Version 4: Protocol and Algorithms | |||
| Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, | Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, | |||
| <https://www.rfc-editor.org/info/rfc5905>. | <https://www.rfc-editor.org/info/rfc5905>. | |||
| [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | |||
| Verification of Domain-Based Application Service Identity | Verification of Domain-Based Application Service Identity | |||
| within Internet Public Key Infrastructure Using X.509 | within Internet Public Key Infrastructure Using X.509 | |||
| (PKIX) Certificates in the Context of Transport Layer | (PKIX) Certificates in the Context of Transport Layer | |||
| skipping to change at page 41, line 10 ¶ | skipping to change at page 41, line 29 ¶ | |||
| [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing | [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing | |||
| IPv6 Zone Identifiers in Address Literals and Uniform | IPv6 Zone Identifiers in Address Literals and Uniform | |||
| Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, | Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, | |||
| February 2013, <https://www.rfc-editor.org/info/rfc6874>. | February 2013, <https://www.rfc-editor.org/info/rfc6874>. | |||
| [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, | [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, | |||
| "Transport Layer Security (TLS) Application-Layer Protocol | "Transport Layer Security (TLS) Application-Layer Protocol | |||
| Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, | Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, | |||
| July 2014, <https://www.rfc-editor.org/info/rfc7301>. | July 2014, <https://www.rfc-editor.org/info/rfc7301>. | |||
| [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher | ||||
| Suite Value (SCSV) for Preventing Protocol Downgrade | ||||
| Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, | ||||
| <https://www.rfc-editor.org/info/rfc7507>. | ||||
| [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, | [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, | |||
| "Recommendations for Secure Use of Transport Layer | "Recommendations for Secure Use of Transport Layer | |||
| Security (TLS) and Datagram Transport Layer Security | Security (TLS) and Datagram Transport Layer Security | |||
| (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May | (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May | |||
| 2015, <https://www.rfc-editor.org/info/rfc7525>. | 2015, <https://www.rfc-editor.org/info/rfc7525>. | |||
| [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 | [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 | |||
| (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, | (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, | |||
| March 2016, <https://www.rfc-editor.org/info/rfc7822>. | March 2016, <https://www.rfc-editor.org/info/rfc7822>. | |||
| skipping to change at page 41, line 43 ¶ | skipping to change at page 42, line 8 ¶ | |||
| 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-04 (work | Minimization", draft-ietf-ntp-data-minimization-04 (work | |||
| in progress), March 2019. | in progress), March 2019. | |||
| [Mizrahi] Mizrahi, T., "A game theoretic analysis of delay attacks | [Mizrahi] Mizrahi, T., "A game theoretic analysis of delay attacks | |||
| against time synchronization protocols", in Proceedings | against time synchronization protocols", in Proceedings | |||
| of Precision Clock Synchronization for Measurement Control | of Precision Clock Synchronization for Measurement Control | |||
| and Communication, ISPCS 2012, pp. 1-6, September 2012. | and Communication, ISPCS 2012, pp. 1-6, | |||
| DOI 10.1109/ISPCS.2012.6336612, September 2012. | ||||
| [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | ||||
| DOI 10.17487/RFC0768, August 1980, | ||||
| <https://www.rfc-editor.org/info/rfc768>. | ||||
| [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | ||||
| RFC 793, DOI 10.17487/RFC0793, September 1981, | ||||
| <https://www.rfc-editor.org/info/rfc793>. | ||||
| [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, | [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, | |||
| "Randomness Requirements for Security", BCP 106, RFC 4086, | "Randomness Requirements for Security", BCP 106, RFC 4086, | |||
| DOI 10.17487/RFC4086, June 2005, | DOI 10.17487/RFC4086, June 2005, | |||
| <https://www.rfc-editor.org/info/rfc4086>. | <https://www.rfc-editor.org/info/rfc4086>. | |||
| [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, | [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, | |||
| "Transport Layer Security (TLS) Session Resumption without | "Transport Layer Security (TLS) Session Resumption without | |||
| Server-Side State", RFC 5077, DOI 10.17487/RFC5077, | Server-Side State", RFC 5077, DOI 10.17487/RFC5077, | |||
| January 2008, <https://www.rfc-editor.org/info/rfc5077>. | January 2008, <https://www.rfc-editor.org/info/rfc5077>. | |||
| [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | ||||
| Housley, R., 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>. | ||||
| [RFC5869] Krawczyk, H. 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>. | ||||
| [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>. | |||
| [RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code | [RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code | |||
| for the Network Time Protocol", RFC 8573, | for the Network Time Protocol", RFC 8573, | |||
| DOI 10.17487/RFC8573, June 2019, | DOI 10.17487/RFC8573, June 2019, | |||
| <https://www.rfc-editor.org/info/rfc8573>. | <https://www.rfc-editor.org/info/rfc8573>. | |||
| [Shpiner] Shpiner, A., Revah, Y., and T. Mizrahi, "Multi-path Time | [Shpiner] Shpiner, A., Revah, Y., and T. Mizrahi, "Multi-path Time | |||
| Protocols", in Proceedings of IEEE International Symposium | Protocols", in Proceedings of IEEE International Symposium | |||
| on Precision Clock Synchronization for Measurement, | on Precision Clock Synchronization for Measurement, | |||
| Control and Communication (ISPCS), September 2013. | Control and Communication (ISPCS), | |||
| DOI 10.1109/ISPCS.2013.6644754, 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] | ||||
| C2S Client-to-server | ||||
| DDoS Distributed Denial-of-Service | ||||
| EF Extension Field [RFC5905] | ALPN Application-Layer Protocol Negotiation [RFC7301] | |||
| HKDF Hashed Message Authentication Code-based Key Derivation | ||||
| Function [RFC5869] | ||||
| IANA Internet Assigned Numbers Authority | C2S Client-to-server | |||
| IP Internet Protocol | DoS Denial-of-Service | |||
| KoD Kiss-o'-Death [RFC5905] | DDoS Distributed Denial-of-Service | |||
| NTP Network Time Protocol [RFC5905] | EF Extension Field [RFC5905] | |||
| NTS Network Time Security | HKDF Hashed Message Authentication Code-based Key Derivation | |||
| Function [RFC5869] | ||||
| NTS-KE Network Time Security Key Exchange | KoD Kiss-o'-Death [RFC5905] | |||
| PRF Pseudorandom Function | NTP Network Time Protocol [RFC5905] | |||
| S2C Server-to-client | NTS Network Time Security | |||
| SCSV Signaling Cipher Suite Value [RFC7507] | NTS NAK NTS negative-acknowledgment | |||
| TCP Transmission Control Protocol [RFC0793] | NTS-KE Network Time Security Key Establishment | |||
| TLS Transport Layer Security [RFC8446] | S2C Server-to-client | |||
| UDP User Datagram Protocol [RFC0768] | TLS Transport Layer Security [RFC8446] | |||
| Authors' Addresses | Authors' Addresses | |||
| Daniel Fox Franke | Daniel Fox Franke | |||
| Akamai Technologies | Akamai Technologies | |||
| 150 Broadway | 145 Broadway | |||
| Cambridge, MA 02142 | Cambridge, MA 02142 | |||
| United States | United States | |||
| Email: dafranke@akamai.com | Email: dafranke@akamai.com | |||
| URI: https://www.dfranke.us | ||||
| Dieter Sibold | Dieter Sibold | |||
| Physikalisch-Technische | Physikalisch-Technische | |||
| Bundesanstalt | 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 | |||
| skipping to change at page 44, line 24 ¶ | skipping to change at page 44, line 4 ¶ | |||
| Kristof Teichel | Kristof Teichel | |||
| Physikalisch-Technische | Physikalisch-Technische | |||
| Bundesanstalt | Bundesanstalt | |||
| Bundesallee 100 | Bundesallee 100 | |||
| Braunschweig D-38116 | Braunschweig D-38116 | |||
| Germany | Germany | |||
| Phone: +49-(0)531-592-4471 | Phone: +49-(0)531-592-4471 | |||
| Email: kristof.teichel@ptb.de | Email: kristof.teichel@ptb.de | |||
| Marcus Dansarie | Marcus Dansarie | |||
| Sweden | ||||
| Email: marcus@dansarie.se | Email: marcus@dansarie.se | |||
| URI: https://orcid.org/0000-0001-9246-0263 | URI: https://orcid.org/0000-0001-9246-0263 | |||
| Ragnar Sundblad | Ragnar Sundblad | |||
| Netnod | Netnod | |||
| Sweden | ||||
| Email: ragge@netnod.se | Email: ragge@netnod.se | |||
| End of changes. 118 change blocks. | ||||
| 310 lines changed or deleted | 357 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||