idnits 2.17.1 draft-mills-ntp-auth-coexist-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MIL96b], [MILLS96]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1, 1998) is 9368 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) == Missing Reference: 'MILLS96' is mentioned on line 75, but not defined == Unused Reference: 'DAR81' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'DEE96' is defined on line 358, but no explicit reference was found in the text == Unused Reference: 'HIN96' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'MIL92' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'MIL96a' is defined on line 368, but no explicit reference was found in the text == Unused Reference: 'POS80' is defined on line 375, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1883 (ref. 'DEE96') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1884 (ref. 'HIN96') (Obsoleted by RFC 2373) ** Obsolete normative reference: RFC 1305 (ref. 'MIL92') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2030 (ref. 'MIL96a') (Obsoleted by RFC 4330) -- Possible downref: Non-RFC (?) normative reference: ref. 'MIL96b' Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group David L. Mills (University of Delaware) 2 Internet-Draft T. S. Glassey (GMT) 3 Expires in six months Michael E. McNeil (GMT) 4 March 1, 1999 September 1, 1998 6 Authentication Scheme Extensions to NTP 7 9 Status of this Memorandum 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas and 13 its working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as work in progress. 21 To view the entire list of current Internet-Drafts, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 The purpose of this document is to extend the NTP/SNTP authentication 30 scheme to support additional features, including Public Key 31 Infrastructure (PKI) cryptography, in order to certify the identity 32 of the sender and verify the integrity of the data included in an 33 NTP message, as well as provide support for other facilities such 34 as a timestamp and non-repudiation service. 36 This document describes a new extension field to support new services 37 for securely binding sender credentials to the NTP message stream. 38 One or more of these fields can be included in the NTP header to 39 support designated security services or other services should they 40 become necessary. The presence of these fields does not affect the 41 operation of the NTP timekeeping model and protocol in any other way. 43 Additional fields may provide means to securely bind arbitrary client 44 data to be signed along with the other information in the message. 45 The ability to sign arbitrary client data provides an important non- 46 repudiation feature that allows this data to be cryptographically bound 47 to an NTP timestamp, together with sender credentials and signature. 49 Contents 51 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 Authentication schemes . . . . . . . . . . . . . . . . . . . . . . . 5 53 Extension fields . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 Type descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 Null . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 Generic Signature . . . . . . . . . . . . . . . . . . . . . . . . 7 58 Autokey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 Security considerations . . . . . . . . . . . . . . . . . . . . . . 8 62 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 Authors' addresses . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 Introduction 67 The purpose of this document is to extend the NTP/SNTP authentication 68 scheme to support additional features, including Public Key 69 Infrastructure (PKI) cryptography, in order to certify the identity 70 of the sender and verify the integrity of the data included in a NTP 71 message. The current scheme described in RFC1305 for NTP Version 3 uses 72 a secret key and cryptographic hash of the message contents to protect 73 against message modification. The NTP protocol itself is inherently 74 resistant to replay and spoofing attacks. Extensions to the current 75 scheme described in [MILLS96] provide one means of securely binding 76 sender credentials to the NTP message stream. Alternative schemes may 77 be developed which provide this feature, as well as others supporting 78 a signature, timestamp and non-repudiation service. 80 This document describes a new extension field to support the new 81 services. One or more of these fields can be included in the NTP header 82 to support designated security services or other services should they 83 become necessary. However, the presence of these fields does not affect 84 the operation of the NTP timekeeping model and protocol in any other 85 way. In order to preserve existing interoperability, the presence of 86 these fields is determined by the message length. Ordinary (unprotected) 87 NTP messages are 48 octets long. Protected messages include either a 12- 88 octet or 20-octet Message Authentication Code (MAC), depending on the 89 hash algorithm, presently either Data Encryption Standard/Cipher-Block 90 Chaining (DES-CBC) or Message Digest 5 (MD5). The extension fields are 91 inserted after the unprotected header and before the MAC. If the overall 92 length of the NTP message is greater than the sum of the protected 93 header length and the longest MAC length, one or more extension fields 94 are present. 96 Following traditional formats used by Internet protocols, the NTP 97 message consists of some number of 4-octet words in big-endian format. 98 The first word contains the total length of the extension field in the 99 low-order two octets. The high-order two octets contain a type code 100 to identify the payload content and processing algorithm. In order to 101 preserve alignment appropriate for block-encryption algorithms such as 102 DES, the last extension field is zero-padded to the next larger integral 103 multiple of eight octets. The hashing algorithm processes the extension 104 fields along with the protected header to produce the MAC at the end 105 of the message. Other than hash processing, the extension fields are 106 invisible to the ordinary NTP protocol operations. 108 The payload may include cryptographic media to support any of several 109 cryptographic schemes, including the autokey scheme of NTP Version 4 110 and other schemes as they are developed. The data can include various 111 subfields containing sequence numbers, additional message digests, 112 signatures and certificates, as well as the length of these subfields. 113 Additional fields may provide means to securely bind arbitrary client 114 data to be signed along with the other information in the message. 115 The ability to sign arbitrary client data provides an important non- 116 repudiation feature that allows this data to be cryptographically bound 117 to an NTP timestamp, together with sender credentials and signature. 119 With respect to the unprotected NTP header described in RFC 1305 and 120 RFC 2030, the new NTP header has the following format: 122 (Offset = 0) 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 |LI | VN |Mode | Stratum | Poll | Precision | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Root Delay | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Root Dispersion | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Reference Identifier | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | | 134 | Reference Timestamp (64) | 135 | | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | | 138 | Originate Timestamp (64) | 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 | Receive Timestamp (64) | 143 | | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | | 146 | Transmit Timestamp (64) | 147 | | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | | 150 | Extension Fields (EF) | 151 // // 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | | 154 | Message Authenticator Code (MAC) | 155 // // 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 The 48-octet fixed-length unprotected header includes all fields through 159 the Transmit Timestamp field. The MAC includes a 4-octet Key Identifier 160 field followed by a variable length Message Digest field in the 161 following format: 163 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Key Identifier (32) | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | | 169 | Message Digest (64 or greater) | 170 // // 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 The Message Digest field length is presently either 8 octets for DES-CBC 173 or 16 octets for MD5; SHA-1, which may be supported in the future, uses 174 a 20-octet message digest. Selection of which one of these two supported 175 algorithms, or more in the case of additional hash algorithms, is 176 determined from the Key Identifier field as described later. 178 Authentication Schemes 180 The original NTP Version 3 authentication scheme described in RFC 1305 181 uses a hashing algorithm (DES-CBC or MD5) to produce a cryptographic 182 checksum of the unprotected NTP header. The checksum is computed by the 183 sender and included along with a private key identifier in the MAC. The 184 receiver verifies the checksum using its own copy of the private key. 185 The extended scheme proposed for NTP Version 4 [MIL96b], which uses the 186 extension field described in this document, continues support for the 187 previous scheme and is compatible with the scheme proposed herein. 189 In both NTP versions a designated hashing algorithm is used to compute 190 the message digest. While only DES-CBC and MD5 algorithms are supported 191 in existing implementations, other algorithms may be supported in 192 future. Each algorithm may require a specific message digest field 193 length, but not less than 8 octets, nor more than 20 octets. For 194 instance, DES requires an 8-octet field, and MD5 requires a 16-octet 195 field, whereas the SHA-1 algorithm, which may be supported in the 196 future, requires a 20-octet field. Any of these algorithms hashes 197 the contents of the 48-octet unprotected header and variable length 198 extension fields, but not the IP addresses, ports or MAC itself, to 199 produce the message digest. 201 In the NTP Version 3 scheme, the key identifier is used to select a 202 private encryption/decryption key from a predistributed set of keys. 203 Associated with each key is an algorithm identifier, which is defined 204 when the key is created and remains with it for the lifetime of the key. 205 The key identifier is used to look up the key and associated algorithm 206 identifier. Thus, no specific algorithm identifier field is necessary in 207 the MAC. In the NTP Version 4 schema, this model is preserved; however, 208 there is a new scheme, called autokey, which does not require prior 209 distribution of keys. In order to preserve legacy, the key identifier 210 space is partitioned in two subspaces, one allocated for private keys, 211 the other for randomly generated autokey keys. With respect to the 212 description here, this distinction is necessary only to clarify how the 213 hashing algorithm is identified and by implication how the length of the 214 MAC can be determined. 216 Extension Fields 218 Zero, one or more extension fields can be included between the 219 unprotected header and the MAC. Each extension field consists of a 4- 220 octet header and variable length payload. The first two octets of the 221 header (reading in big-endian order) contain the type descriptor. The 222 next two octets contain the total extension field length, including the 223 length and type octets, but not any padding at the end. Each extension 224 field is zero-padded, as necessary, to the next 4-octet alignment; 225 the last field is zero-padded to the next 8-octet alignment. The total 226 length of every extension field must be greater than 24 octets, in order 227 to reliably recognize its presence (see below). This value, added to the 228 offset of the extension field within the message, points to the first 229 octet following the extension field. The overall format of all extension 230 fields within a given NTP packet is as follows: 232 (Offset = 48) 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Type Descriptor (16) | Length (16) | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | | 238 | Payload | 239 // // 240 | +-----------------------------------------------+ 241 | | Padding to 4-octet multiple | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 ... 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Type Descriptor (16) | Length (16) | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 | Payload | 251 // // 252 | +-----------------------------------------------+ 253 | | Padding to 8-octet multiple | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Type Descriptors 257 The type descriptor identifies the algorithm that understands the 258 particular format of a given type of extension field. There may be 259 a mixture of ASN.1, binary, ASCII and printable data in each field, 260 depending on the algorithm involved. There is no specific requirement 261 on ordering, if more than one extension field is present. In general, 262 schemes that require multiple fields will have to scan through all 263 type descriptors to verify that all required fields are present and 264 to determine the sequence of processing steps. 266 Some fields, such as certificate and signature fields, may be considered 267 generic across several different schemes, while others may be specific 268 to each scheme. For instance, most schemes using PKI will use X.509 269 certificates, RSA signatures and Diffie-Hellman key agreement, if any 270 of these features are required. In order to support these schemes, the 271 following functional types are supported. 273 Null 275 This field is ignored, except by the hashing algorithm. It is 276 included for testing and debugging. 278 Certificate 280 This field contains the X.509 certificate in ASN.1 format. 282 Generic Signature 284 This field contains the RSA signature in PKCS-1 encrypted block 285 format. For this purpose, the RSA modulus and public exponent must be 286 derived from the certificate or known by other means. The data to be 287 signed is the message digest included in the MAC at the end of the 288 NTP message. Note, this does not preclude a proprietary signature 289 scheme with different semantics. 291 Autokey 293 The field contains the Autokey data TBD. 295 Scheme 297 This field is scheme-specific. It contains such variables as version 298 ID, source ID, serial number, request/response bits and so forth. 299 There may be more than one scheme field if more than one scheme is 300 operating simultaneously. This could occur, for example, if the NTP 301 Version 4 Autokey scheme is in use along with timestamping service or 302 non-repudiation service. 304 Implementation 306 There may be data in an extension field that is known only after the 307 message digest has been computed; in particular, the signature. In 308 order to produce a deterministic result, it is necessary to temporarily 309 replace these data with zeros when the digest is computed and replace 310 them when the final result is known. This is the same action specified 311 in IPSEC documents. 313 The various fields in the NTP message are parsed as follows. The parsing 314 algorithm assumes a pointer initially positioned at the end of the 315 unprotected header; i.e., at offset 48 octets. At each step the 316 remaining payload from the pointer to the end of the message is 317 considered. 319 1. If the remaining payload length is zero, that is, the pointer is 320 at the end of the message, then there is no NTP MAC and the NTP 321 authentication scheme described above is not used. If extension 322 fields have been found previously, they are processed at this 323 time and may result in message authentication by other schemes. 325 2. If the remaining payload length is less than four octets, declare 326 a format error and consider the message to be unauthenticated. 328 3. If the remaining payload length is not greater than 24 octets, 329 the NTP authentication scheme is in use, perhaps along with any 330 previously located extension fields. The first 4-octet word in the 331 remaining payload contains the key identifier used to look up the 332 key and algorithm identifier. Depending on the particular algorithm 333 identifier, the expected MAC length is checked against the actual 334 remaining length. If the lengths agree, the message is processed as 335 described above. If not, declare a format error and consider the 336 message unauthenticated. Following processing of the MAC, any 337 extension fields are processed, which may involve separately 338 signing (encrypting) the message digest located in the MAC. 340 4. The remaining payload length must be greater than 24 octets. An 341 extension field is present. If an extension field was found prior 342 to this one in the NTP message, and the earlier extension field 343 was padded to a 4-octet alignment rather than 8, backtrack the 344 pointer by 4 octets. Move the pointer over the next extension 345 field by adding the contents of its 2-octet length word to the 346 current pointer value. Round the pointer up to the next 8-octet 347 alignment. Proceed in step 1. 349 Security Considerations 351 Security issues are the main topic of this memorandum. 353 References 355 [DAR81] Postel, J., Internet Protocol, STD 5, RFC 791, USC Information 356 Sciences Institute, September 1981. 358 [DEE96] Deering, S., R. Hinden, Internet Protocol, Version 6 (IPv6) 359 Specification, RFC 1883, Xerox and Ipsilon, January 1996. 361 [HIN96] Hinden, R., and S. Deering, IP Version 6 addressing 362 architecture, RFC 1884, Ipsilon and Xerox, January 1996. 364 [MIL92] Mills, D., Network Time Protocol (Version 3) specification, 365 implementation and analysis, RFC 1305, University of Delaware, March 366 1992. 368 [MIL96a] Mills, D., Simple Network Time Protocol (SNTP) Version 4 for 369 IPv4, IPv6 and OSI, RFC 2030, University of Delaware, October 1996. 371 [MIL96b] Mills, D., Proposed authentication enhancements for the Network 372 Time Protocol Version 4, Electrical Engineering Report 96-10-3, 373 University of Delaware, October 1996. 375 [POS80] Postel, J., User Datagram Protocol, STD 6, RFC 768, USC 376 Information Sciences Institute, August 1980. 378 Authors' Addresses 380 David L. Mills 381 Electrical and Computer Engineering Department 382 University of Delaware 383 Newark, DE 19716 384 Phone: (302) 831-8247 385 E-mail: mills@udel.edu 387 T. S. Glassey 388 GMT - Glassey-McNeil Technologies 389 109A Bluebonnet Lane 390 Scotts Valley, CA 95066 391 Phone: (831) 438-7811 392 E-mail: tsgman@earthlink.net 394 Michael E. McNeil 395 GMT - Glassey-McNeil Technologies 396 109A Bluebonnet Lane 397 Scotts Valley, CA 95066 398 Phone: (831) 438-7811 399 E-mail: memcneil@got.net 401 Expires in six months: March 1, 1999