idnits 2.17.1 draft-stenn-ntp-extension-fields-02.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 ([RFC5905], [Err3627]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document updates RFC5905, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 28, 2017) is 2402 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: 'Err3627' is mentioned on line 113, but not defined ** Downref: Normative reference to an Informational RFC: RFC 5906 ** Downref: Normative reference to an Experimental RFC: RFC 7821 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Mizrahi 3 Internet-Draft Marvell 4 Intended status: Standards Track D. Mayer 5 Expires: April 1, 2018 H. Stenn 6 Network Time Foundation 7 September 28, 2017 9 Network Time Protocol Version 4 (NTPv4) Extension Fields 10 draft-stenn-ntp-extension-fields-02 12 Abstract 14 Network Time Protocol version 4 (NTPv4) defines the optional usage of 15 extension fields. An extension field, as defined in RFC 5905 16 [RFC5905], resides after the end of the NTP header, and supplies 17 optional capabilities or information that is not conveyed in the 18 standard NTP header. This document updates RFC 5905 [RFC5905] by 19 clarifying some points regarding NTP extension fields and their usage 20 with legacy Message Authentication Codes (MACs). 22 With the adoption of this update, the authors recommend rescinding 23 [Err3627]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 1, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 63 3. NTP MAC - RFC 5906 Update . . . . . . . . . . . . . . . . . . 3 64 3.1. 4. Autokey Cryptography . . . . . . . . . . . . . . . . . 4 65 3.2. 10. Autokey Protocol Messages . . . . . . . . . . . . . . 4 66 3.3. 11.5. Error Recovery . . . . . . . . . . . . . . . . . . 4 67 3.4. 13. IANA Consideration . . . . . . . . . . . . . . . . . 4 68 4. NTP Extension Fields - RFC 5905 Update . . . . . . . . . . . 4 69 4.1. OLD: 7.5 NTP Extension Field Format . . . . . . . . . . . 4 70 4.2. NEW: 7.5 NTP Extension Field Format . . . . . . . . . . . 5 71 4.3. NEW: 7.5.1 Extension Fields and MACs . . . . . . . . . . 7 72 4.3.1. Legacy MAC/EF Parsing Pseudocode . . . . . . . . . . 9 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 The NTP header format consists of a set of fixed fields that may be 81 followed by optional fields. Two types of optional fields are 82 defined: extension fields as defined in Section 7.5 of RFC 5905 83 [RFC5905], and legacy Message Authentication Codes (legacy MACs). 85 If a legacy MAC is used, it resides at the end of the packet. This 86 field can be either a 4-octet crypto-NAK or data that is usually 20 87 or 24 octets long. 89 Additional information about the content of a MAC is specifieded in 90 RFC 5906 [RFC5906], but since that RFC is Informational an 91 implementor that was not planning to provide Autokey would likely 92 never read that document. The result of this would be 93 interoperability problems, at least. To address this problem, this 94 proposal also includes copying and clarifying some of the content of 95 RFC 5906 and putting it into RFC 5905. Because there is a reasonable 96 chance RFC 5906 will be deprecated, this document does not propose 97 changes to RFC 5906. 99 NTP extension fields are defined in RFC 5905 [RFC5905] as a generic 100 mechanism that allows the addition of future extensions and features 101 without modifying the NTP header format (Section 16 of RFC 5905 102 [RFC5905]). 104 Section 7.5 of RFC 5905 [RFC5905] clearly states that "one or more 105 extension fields can be inserted after the header and before the MAC, 106 which is always present when an extension field is present." 107 However, the experimental Checksum Complement RFC 7821 [RFC7821] 108 cannot be used if the NTP packet contains a MAC. 110 To allow for extension fields that do not require a MAC, changes to 111 the NTPv4 specification must be made. [Err3627] was an attempt to 112 clarify the rules around MACs, but with the adoption of this proposal 113 the authors recommend rescinding [Err3627]. 115 This document better specifies and clarifies both Extention Fields 116 and the requirements and parsing of a legacy MAC, with changes to 117 address errors found after the publication of RFC 5905 [RFC5905] with 118 respect to extension fields. Specifically, this document updates 119 Section 7.5 of RFC 5905 [RFC5905], clarifying the relationship 120 between extension fields and MACs, and defines the behavior of a host 121 that receives an unknown extension field. 123 2. Conventions Used in This Document 125 2.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 2.2. Terms and Abbreviations 133 MAC - Message Authentication Code 135 NTPv4 - Network Time Protocol, Version 4 RFC 5905 [RFC5905] 137 3. NTP MAC - RFC 5906 Update 139 This document copies and updates some information in RFC 5906 140 [RFC5906] and puts it in to RFC 5905, as follows: 142 3.1. 4. Autokey Cryptography 144 This section describes some of the cryptography aspects of Autokey. 145 The third paragraph describes the use of 128- and 160-bit message 146 digests. The enumeration of 128- and 160-bit message digests is not 147 meant to be limiting - other message digest lengths MAY be 148 implemented. This paragraph also describes some of the recommended 149 semantic ranges of the key ID. This information belongs in RFC 5905. 150 The key ID ranges are particularly significant because they provide 151 addtional disambiguation protection when deciding if the next data 152 portion is either a legacy MAC or an Extension Field. 154 3.2. 10. Autokey Protocol Messages 156 This section describes the Extension Field format, including initial 157 flag bits, a Code field, and 8-bit Field Type, and the 16-bit Length. 158 This proposal expands and clarifies this information and puts it into 159 RFC 5905. 161 This section says "The reference implementation discards any packet 162 with a field length of more than 1024 characters." but this is no 163 longer true. 165 3.3. 11.5. Error Recovery 167 This section describes the crypto-NAK, which should be described in 168 RFC 5905. 170 3.4. 13. IANA Consideration 172 This section lists the Autokey-related Extension Field Types, 173 including Flag Bits, Codes, and Field Types, which should be 174 described in RFC 5905, or perhaps in some other document. 176 4. NTP Extension Fields - RFC 5905 Update 178 This document updates Section 7.5 of RFC 5905 [RFC5905] as follows: 180 4.1. OLD: 7.5 NTP Extension Field Format 182 In NTPv4, one or more extension fields can be inserted after the 183 header and before the MAC, which is always present when an extension 184 field is present. Other than defining the field format, this 185 document makes no use of the field contents. An extension field 186 contains a request or response message in the format shown in 187 Figure 14. 189 0 1 2 3 190 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 191 +---------------+---------------+-------------------------------+ 192 | Field Type | Field Length | 193 +-------------------------------+-------------------------------+ 194 . . 195 . Value . 196 . . 197 +-------------------------------+-------------------------------+ 198 | Padding (as needed) | 199 +---------------------------------------------------------------+ 201 Figure 14: Extension Field Format 203 All extension fields are zero-padded to a word (four octets) 204 boundary. The Field Type field is specific to the defined function 205 and is not elaborated here. While the minimum field length 206 containing required fields is four words (16 octets), a maximum field 207 length remains to be established. 209 The Length field is a 16-bit unsigned integer that indicates the 210 length of the entire extension field in octets, including the Padding 211 field. 213 4.2. NEW: 7.5 NTP Extension Field Format 215 In NTPv4, one or more extension fields can be inserted after the 216 header and before the possibly optional legacy MAC. A MAC SHOULD be 217 present when an extension field is present. A MAC is always present 218 in some form when NTP packets are authenticated. This MAC SHOULD be 219 either a legacy MAC or a MAC-EF. It MAY be both. Other than 220 defining the field format, this document makes no use of the field 221 contents. An extension field contains a request or response message 222 in the format shown in Figure 14. 224 0 1 2 3 225 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 226 +---------------+---------------+-------------------------------+ 227 | Field Type | Field Length | 228 +-------------------------------+-------------------------------+ 229 . . 230 . Value . 231 . . 232 +-------------------------------+-------------------------------+ 233 | Padding (as needed) | 234 +---------------------------------------------------------------+ 236 Figure 14: Extension Field Format 238 All extension fields are zero-padded to a word (four octet) boundary. 239 The Field Type is specific to the defined function and detailed 240 information about the Field Type is not elaborated here. While the 241 minimum extension field is a 32-bit word (4 octets), the minimum 242 length of an extension field is usually four 32-bit words (16 243 octets), and while a maximum extension field size MUST be 65532 244 octets or less, an NTP packet SHOULD NOT exceed the network MTU. 246 The Length field is a 16-bit unsigned integer that indicates the 247 length of the entire extension field in octets, including any Padding 248 octets. The bottom two bits of the Field Length SHOULD be zero. 250 The Field Type contains the following sub-elements: 252 0 1 2 3 253 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 254 +---------------+---------------+-------------------------------+ 255 |R|E|O|I|EF Code EF Type | (Field Length) | 256 +-------------------------------+-------------------------------+ 258 Field Type Format 260 Where the following Field Type flags are defined: 262 R: 0 for a "Query", 1 for a "Response" 264 E: 0 for "OK", 1 for an "Error" 266 O: 0 for "MAC Required", 1 for "MAC Optional" 268 I: 0 for "MAC Not Included", 1 for "MAC Included" 270 [The EF Code subtype is currently only used by RFC 5906, Autokey 271 [RFC5906]. The EF Code subtype is expected to be used by the NTS 272 Extension Field, and the Extended Information Extension Field, at 273 least.] 275 The Field Type, Value, and Padding fields are specific to the defined 276 function and are not elaborated here; appropriate Field Type flags, 277 the EF Code, and EF Type values are defined in an IANA registry, and 278 the Length, Value, and Padding values are defined by the document 279 referred to by the registry. If a host receives an extension field 280 with an unknown Field Type, the host SHOULD ignore the extension 281 field and MAY drop the packet altogether if policy requires it. 283 The Length field is a 16-bit unsigned integer that indicates the 284 length of the entire extension field in octets, including any 285 Padding. 287 While the minimum field length containing required fields is four 288 words (16 octets), the maximum field length MUST NOT be longer than 289 65532 octets due to the maximum size of the data represented by the 290 Length field, and SHOULD be small enough that the size of the NTP 291 packet received by the client does not exceed the smallest MTU 292 between the sender and the recipient. The bottom two bits of the 293 Field Length SHOULD be zero. 295 4.3. NEW: 7.5.1 Extension Fields and MACs 297 With the inclusion of additional Extension Fields, there is now a 298 possibility of an ambiguous parsing in the presence of a legacy MAC. 299 If an implementation offers even a modicum of care, there will be no 300 ambiguity when parsing an NTP packet that contains a legacy MAC from 301 an existing implementation. 303 The first protection from this ambiguity comes from the fact that 304 current conforming implementations only support the Autokey EF, which 305 uses EF Type 2 and a legacy MAC. While the Experimental UDP Checksum 306 Complement specified by RFC 7821 [RFC7821] uses EF Type 5, it 307 specifically prohibits the use of a MAC, and the 0x2000 bit in its 308 assigned EF type of 0x2005 specifies that a MAC is optional when this 309 EF is provided. 311 [As a side note, the requirement in RFC 7821 [RFC7821] that the UDP 312 Checksum Complement EF must have a 28 octet length is demonstrably 313 not needed if this proposal is accepted. It only needs 8 octets: 4 314 octets of EF header, 2 octets of MBZ padding, and 2 octets of 315 Checksum Complement.] 317 If an implementation uses the LAST-EF extension field, the presence 318 of this field means "I am the last EF in this NTP Packet. Any 319 subsequent packet data MUST be a legacy MAC." In this case, there is 320 no parsing ambiguity. 322 If a system sends its MAC as a MAC-EF and does not send a legacy MAC, 323 there is no parsing ambiguity. 325 The only time there is a potential for a parsing ambiguity is when a 326 legacy MAC is provided and neither of the previous two cases are 327 present. Even in this case, there is minimal risk. 329 An Extension Field contains a 2-octet Field Type, a 2-octet Field 330 Length, and any payload (data and/or padding). If the NTP Packet 331 parsing is at a point where it is evaluating data after the base 332 packet, one of the following situations exists: 334 If the Field Length is not an even multiple of 4, we are not 335 looking at an extension field. In this case, the only possibility 336 of having a valid packet is if the data is part of a legacy MAC. 338 If the Field Length is valid, i.e., an even multiple of 4 octets, 339 one of the following three cases must be present: 341 First, the Field Length will be less than the remaining data. 342 This means subsequent data must parse as some number of 343 Extension Fields, optionally follwed by a legacy MAC. 345 Second, the Field Length will exactly match the remaining data. 347 The third case is where the Field Length is longer than the 348 remaining packet data. In this case, the current parse cannot 349 be a valid extension field, and if the packet is valid, the 350 data must be a legacy MAC. 352 Semantic checking may also be done to validate a potential legacy 353 MAC. A legacy MAC is a four-octet Key Identifier followed by a 354 message digest. The usual message digest is 16 octets long but may 355 be another size, depending on the digest algorithm. In the Reference 356 Implementation, a Key Identifier between 1 and 65535, inclusive, is a 357 symmetric key, while a Key Identifier that is > 65535 is an Autokey 358 RFC 5906 [RFC5906], or similar. If the receiving system does not 359 recognize the Key Identifier, the data CANNOT be a valid legacy MAC. 360 If the receiving system recognizes the Key Identifier, then it also 361 has knowledge of the digest algorithm and can make sure the digest 362 payload is the proper length. If this is not the case, then the data 363 CANNOT be a valid legacy MAC. In this case, it MIGHT be a valid 364 extension field. 366 It is trivial to parse the data after the base NTP packet and come up 367 with a list of potential parsings. A local policy choice can specify 368 the precedence of the parsing options in this case. 370 If none of the parsings validate, the packet fails authentication. 371 An implementation has three local policy choices available if LAST-EF 372 is not used and a legacy MAC may be provided. First, the 373 implementation may specify EF-precedence. Second, the implementation 374 may specify legacy-MAC-precedence. Finally, the implementation may 375 specify "best fit" precedence. In this last case, the packet will 376 meet one of the three following criteria: First, none of the parsings 377 will match. Again, this is a case of failed authentication. Second, 378 exactly one parsing will match and that parsing will be accepted. 379 Third, multiple parsings will match, in which case the implementation 380 may choose its behavior. 382 Additionally, most EFs will require a MAC. If there is a 383 syntactically-valid parsing that does not include a MAC but 384 previously scanned EFs require a MAC, then in a multiple-choice 385 parsing scenario where one of the choices does not include a MAC the 386 "no MAC provided" choice SHOULD be eliminated. 388 Note well that this rare situation can be completely avoided by using 389 LAST-EF, or by indicating that no legacy MAC will be used. 391 4.3.1. Legacy MAC/EF Parsing Pseudocode 393 Here are two potential pseudocode implementations showing how data 394 after the base NTP packet could be analyzed to identify EFs and a 395 possible legacy MAC. 397 [Example 1: high-level parsing algorithm] 399 [Example 2: the pseudocode Harlan sent to Tal and Danny] 401 5. IANA Considerations 403 This memo requests IANA to allocate the following bits in the NTP 404 Extension Field Types table: 406 0x8000: R: Response (0: Request, 1: Response) 408 0x4000: E: Error (0: OK, 1: Error) 410 0x8000: O: MAC Optional (0: MAC required, 1: MAC optional) 412 0x8000: I: MAC Included (0: MAC not included, 1: MAC included) 414 6. Security Considerations 416 Additional information TBD 418 7. Normative References 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, 422 DOI 10.17487/RFC2119, March 1997, 423 . 425 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 426 "Network Time Protocol Version 4: Protocol and Algorithms 427 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 428 . 430 [RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol 431 Version 4: Autokey Specification", RFC 5906, 432 DOI 10.17487/RFC5906, June 2010, 433 . 435 [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time 436 Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 437 2016, . 439 Authors' Addresses 441 Tal Mizrahi 442 Marvell 443 6 Hamda St. 444 Yokneam, 20692 445 Israel 447 Email: talmi@marvell.com 449 Danny Mayer 450 Network Time Foundation 451 P.O. Box 918 452 Talent, OR 97540 453 US 455 Email: mayer@ntp.org 457 Harlan Stenn 458 Network Time Foundation 459 P.O. Box 918 460 Talent, OR 97540 461 US 463 Email: stenn@nwtime.org