idnits 2.17.1 draft-stenn-ntp-secure-network-time-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5906]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 2, 2018) is 2125 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5905' is defined on line 119, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5906 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Stenn 3 Internet-Draft D. Mills 4 Intended status: Standards Track P. Prindeville 5 Expires: January 3, 2019 Network Time Foundation 6 July 2, 2018 8 Network Time Protocol: Secure Network Time 9 draft-stenn-ntp-secure-network-time-00 11 Abstract 13 The proposal specifies a means for NTP instances that can establish a 14 TCP connection between themselves to create secure ephemeral keys. 15 With the known weaknesses of the public-key security protocol, 16 Autokey, which is defined by RFC 5906 [RFC5906], a replacement for 17 Autokey that supports at least Client/Server and Symmetric modes must 18 be provided. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 3, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 56 2. Secure Network Time . . . . . . . . . . . . . . . . . . . . . 3 57 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 59 5. Normative References . . . . . . . . . . . . . . . . . . . . 3 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 3 62 1. Introduction 64 From almost the beginning, NTP has provided a mechanism to 65 authenticate an NTP packet. To date, that mechanism is a Message 66 Authentication Code, or MAC. The MAC is comprised of two subfields, 67 a 32-bit keyID and a signature. A keyID with a value between 1 and 68 65535, inclusive, is a symmetric key. A keyID with a value greater 69 than 65535 is not provided by the symmetric key file, and has 70 traditionally been negotiated ephemerally, with Autokey, defined by 71 RFC 5906 [RFC5906], being one example. 73 The mechanism by which keys are exchanged between NTP instance can be 74 thought of as a black-box exchange. One of these black-box key 75 exchange mechanisms is "the way the ntp.keys file containing 76 symmetric keys is distributed." Another way keys have been exchaned 77 is via Autokey. 79 This Secure Network Time proposal uses the NTP TCP Services mechanism 80 to perform key exchange, follwed by negotiation of a keyID, a hash 81 algorithm, and a secret key over a TLS connection. Once this has 82 been done, each participant can use the keyID, hash algorithm, and 83 secret key to provide MAC protection for NTP packets, using ephemeral 84 keys that can be re-negotiated as-needed. 86 Should additional security measures be desired, for example using a 87 cookie as additional replay prevention, that can be easily provided. 89 1.1. Requirements Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 2. Secure Network Time 97 Secure Network Time uses "NTP TCP Services" to perform key exchange 98 over a TLS connection, followed by an agreement on a keyID, hash 99 algorithm, and a secret. With the secure communication of a keyID, a 100 cryptographically strong hash algorithm, and a secret of sufficient 101 strength, we have an ephemeral key exchange mechanism that provides 102 MAC authentication for NTP packets. 104 3. IANA Considerations 106 TBD 108 4. Security Considerations 110 Additional information TBD 112 5. Normative References 114 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 115 Requirement Levels", BCP 14, RFC 2119, 116 DOI 10.17487/RFC2119, March 1997, 117 . 119 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 120 "Network Time Protocol Version 4: Protocol and Algorithms 121 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 122 . 124 [RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol 125 Version 4: Autokey Specification", RFC 5906, 126 DOI 10.17487/RFC5906, June 2010, 127 . 129 Authors' Addresses 131 Harlan Stenn 132 Network Time Foundation 133 P.O. Box 918 134 Talent, OR 97540 135 US 137 Email: stenn@nwtime.org 138 David L. Mills 139 Network Time Foundation 140 P.O. Box 918 141 Talent, OR 97540 142 US 144 Email: mills@udel.edu 146 Philip Prindeville 147 Network Time Foundation 148 P.O. Box 918 149 Talent, OR 97540 150 US 152 Email: prindeville@ntp.org