Network Time Protocols S. Grant Internet-Draft 12 July 2025 Intended status: Informational Expires: 13 January 2026 Network Time Security over QUIC draft-grant-ntp-ntq-latest Abstract This document describes the use of the Network Time Security protocol over QUIC. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://signalsforgranted.github.io/draft-grant-ntp-ntq/draft-grant- ntp-ntq.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-grant-ntp-ntq/. Discussion of this document takes place on the Network Time Protocols Working Group mailing list (mailto:ntp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ntp/. Subscribe at https://www.ietf.org/mailman/listinfo/ntp/. Source for this draft and an issue tracker can be found at https://github.com/signalsforgranted/draft-grant-ntp-ntq. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 13 January 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 2. Conventions and Definitions 3. QUIC Connectivity 3.1. Connection Initiation 3.2. Connection Shutdown 3.3. Error Handling 4. Security Considerations 5. IANA Considerations 5.1. Service Name and Transport Protocol Port Number Registry 6. References 6.1. Normative References 6.2. Informative References Acknowledgments Author's Address 1. Introduction Network Time Security (NTS) [RFC8915] defines the NTS Key Establishment (NTS-KE) protocol, which uses TLS 1.3 [RFC8446] over TCP to secure the distribution of NTP server information and cookies. There are several key reasons to consider the use of QUIC for NTS Key Establishment services; QUIC like NTP is based on UDP, which means that networks or network segments. Not all of QUIC's capabilities are applicable to providing NTS-KE, however these should not pose any notable concerns for implementators who would most likely be using existing QUIC implementations. *TODO*: Define what QUIC features aren't of use 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. QUIC Connectivity 3.1. Connection Initiation By default, servers should listen and accept QUIC connections on UDP port 4460, unless there is a mutual agreement to use another port. NTS key establishment connections are established as described in the QUIC transport specification [RFC9000]. During connection establishment support is indicated with the client offering, and the server accepting the Application-Layer Protocol Negotiation (ALPN) token "ntske/1" as per [RFC8915]. All key establishment requests and responses MUST take place through the use of streams; datagrams and other types MUST NOT be used. The client must initiate the bidirectional stream, starting from 0. After each complete key establishment request has been sent, it MUST send a STREAM FIN message to indicate no further data be sent. All payloads sent within the stream must be in accordance with Section 4, [RFC8915]. 3.2. Connection Shutdown 3.3. Error Handling 4. Security Considerations General security considerations for time protocols are discussed in RFC 7384 [RFC7384]. *TODO*: Security considerations 5. IANA Considerations 5.1. Service Name and Transport Protocol Port Number Registry IANA is requested to allocate the following entry in the Service Name and Transport Protocol Port Number Registry [RFC6335]: Service Name: ntske Transport Protocol: udp Assignee: IESG iesg@ietf.org (mailto:iesg@ietf.org) Contact: IETF Chair chair@ietf.org (mailto:chair@ietf.org) Description: Network Time Security Key Establishment Reference: This Document Port Number: 4460 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Sundblad, "Network Time Security for the Network Time Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, . 6.2. Informative References [I-D.draft-ietf-ntp-ntpv5] Lichvar, M. and T. Mizrahi, "Network Time Protocol Version 5", Work in Progress, Internet-Draft, draft-ietf-ntp- ntpv5-05, 2 July 2025, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . Acknowledgments TODO acknowledge Author's Address Sarah Grant Email: sarah.grant.ietf@gmail.com