idnits 2.17.1 draft-stenn-ntp-extension-fields-05.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], [RFC5906], [RFC7822]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC7822, but the abstract doesn't seem to directly say this. It does mention RFC7822 though, so this could be OK. -- 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 (February 21, 2018) is 2253 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) ** Downref: Normative reference to an Informational RFC: RFC 5906 ** Downref: Normative reference to an Experimental RFC: RFC 7821 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). 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 Obsoletes: 7822 (if approved) Network Time Foundation 5 Intended status: Standards Track February 21, 2018 6 Expires: August 25, 2018 8 Network Time Protocol Version 4 (NTPv4) Extension Fields 9 draft-stenn-ntp-extension-fields-05 11 Abstract 13 Network Time Protocol version 4 (NTPv4) defines the optional usage of 14 extension fields. An extension field, as defined in RFC 5905 15 [RFC5905] and RFC 5906 [RFC5906], resides after the end of the NTP 16 header and supplies optional capabilities or information that is not 17 conveyed in the standard NTP header. This document updates RFC 5905 18 [RFC5905] by clarifying some points regarding NTP extension fields 19 and their usage with legacy Message Authentication Codes (MACs). 21 This proposal deprecates RFC 7822 [RFC7822]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 25, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4 61 3. NTP MAC - RFC 5906 Update . . . . . . . . . . . . . . . . . . 4 62 3.1. RFC5906 Section 4. - Autokey Cryptography . . . . . . . . 4 63 3.2. RFC5906 Section 10. - Autokey Protocol Messages . . . . . 4 64 3.3. RFC5906 Section 11.5. - Error Recovery . . . . . . . . . 5 65 3.4. RFC5906 Section 13. - IANA Consideration . . . . . . . . 5 66 4. NTP Extension Fields - RFC 5905 Update . . . . . . . . . . . 5 67 4.1. OLD: RFC5905 7.5 - NTP Extension Field Format . . . . . . 5 68 4.2. NEW: RFC5905 Section 7.5 - NTP Extension Field Format . . 6 69 4.3. NEW: RFC5905 Section 7.5.1 - Extension Fields and MACs . 8 70 4.3.1. Legacy MAC/EF Parsing Pseudocode . . . . . . . . . . 10 71 4.4. OLD: RFC5905 Section 9.2. - Peer Process Operations . . . 13 72 4.5. NEW: RFC5905 Section 9.2. - Peer Process Operations . . . 14 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 8. Normative References . . . . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 The NTP header format consists of a set of fixed fields that may be 82 followed by optional fields. Two types of optional fields are 83 defined: extension fields (EFs) as defined in Section 7.5 of RFC 5905 84 [RFC5905], and legacy Message Authentication Codes (legacy MACs). 86 If a legacy MAC is used, it resides at the end of the packet. This 87 field can be either a 4-octet crypto-NAK or data that has 88 traditionally been 16, 20 or 24 octets long. 90 Additional information about the content of a MAC is specified in RFC 91 5906 [RFC5906], but since that RFC is Informational an implementor 92 that was not planning to provide Autokey would likely never read that 93 document. The result of this would be interoperability problems, at 94 least. To address this problem, this proposal also includes copying 95 and clarifying some of the content of RFC 5906 and putting it into 96 RFC 5905. Because there is a reasonable chance RFC 5906 will be 97 deprecated, this document does not propose changes or updates to RFC 98 5906. 100 NTP extension fields are defined in RFC 5905 [RFC5905] as a generic 101 mechanism that allows the addition of future extensions and features 102 without modifying the NTP header format (Section 16 of RFC 5905 103 [RFC5905]). 105 Section 7.5 of RFC 5905 [RFC5905] has always clearly stated that "one 106 or more extension fields can be inserted after the header and before 107 the MAC, which is always present when an extension field is present." 108 However, the experimental Checksum Complement RFC 7821 [RFC7821] 109 cannot be used if the NTP packet contains a MAC. Furthermore, while 110 it is clear that the type of assurance and protection offered by a 111 MAC or some other signature SHOULD be used, there can be benefit to 112 relaxing the current 'MUST' requirement. 114 To allow for this, changes to the NTPv4 specification must be made. 116 RFC 7822 [RFC7822] was an attempt to change the rules around MACs, 117 but in doing so, it completely removed the long-standing rule that 118 the presence of an extension field required MAC protection, created 119 additional requirements on new EFs that are not shown to be needed 120 (see Section 7.5.1.1 of RFC 7822), added an express ordinary limit to 121 the length of a MAC, and required that certain position-dependent EFs 122 be at least 28 octets long. Limiting the length of a MAC prohibits 123 the use of longer MACs, should that ever be needed. RFC 7822 makes 124 several other new requirements but does not offer any advice or 125 direction on how to meet those requirements. Requiring the last EF 126 to be at least 28 octets long is needlessly wasteful, especially if 127 the LAST-EF proposal is accepted and used. 129 The rules in RFC 7822 for the length requirement on EFs and any 130 legacy MAC are intricate and complex. 132 [There are other problems with Sections 7.5.1.1 thru 7.5.1.4, but we 133 won't describe those here unless there is clear need for it.] 135 This proposal adjusts the requirements around EFs and MACs, allows 136 EFs to be on 4-octet boundaries of any acceptable length, and 137 provides methods to disambiguate packet parsing in the unexpected and 138 unlikely case where an implementation would choose to send a packet 139 that could be ambiguously parsed. 141 This proposal deprecates RFC 7822 [RFC7822]. 143 This document better specifies and clarifies extension fields as well 144 as the requirements and parsing of a legacy MAC, with changes to 145 address errors found after the publication of RFC 5905 [RFC5905] with 146 respect to extension fields. Specifically, this document updates 147 Section 7.5 of RFC 5905 [RFC5905], clarifying the relationship 148 between extension fields and MACs, and expressly defines the behavior 149 of a host that receives an unknown extension field. 151 2. Conventions Used in This Document 153 2.1. Requirements Language 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 2.2. Terms and Abbreviations 161 EF - Extension Field 163 MAC - Message Authentication Code 165 NTPv4 - Network Time Protocol, Version 4 RFC 5905 [RFC5905] 167 3. NTP MAC - RFC 5906 Update 169 This document copies and updates some information in RFC 5906 170 [RFC5906] and puts it in to RFC 5905, as follows: 172 3.1. RFC5906 Section 4. - Autokey Cryptography 174 This section describes some of the cryptography aspects of Autokey. 175 The third paragraph describes the use of 128- and 160-bit message 176 digests. The enumeration of 128- and 160-bit message digests is not 177 meant to be limiting - other message digest lengths MAY be 178 implemented. This paragraph also describes some of the recommended 179 semantic ranges of the key ID. This information belongs in RFC 5905. 180 The key ID value is particularly significant because it provide 181 additional disambiguation protection when deciding if the next data 182 portion is either a legacy MAC or an extension field. 184 3.2. RFC5906 Section 10. - Autokey Protocol Messages 186 This section describes the extension field format, including initial 187 flag bits, a Code field, and 8-bit Field Type, and the 16-bit Length. 188 This proposal expands and clarifies this information and puts it into 189 RFC 5905. 191 This section says "The reference implementation discards any packet 192 with a field length of more than 1024 characters." but this is no 193 longer true. 195 3.3. RFC5906 Section 11.5. - Error Recovery 197 This section describes the crypto-NAK, which should be described in 198 RFC 5905. 200 3.4. RFC5906 Section 13. - IANA Consideration 202 This section lists the Autokey-related Extension Field Types, 203 including Flag Bits, Codes, and Field Types, which should be 204 described in RFC 5905, or perhaps in some other document. 206 4. NTP Extension Fields - RFC 5905 Update 208 This document updates Section 7.5 of RFC 5905 [RFC5905] as follows: 210 4.1. OLD: RFC5905 7.5 - NTP Extension Field Format 212 In NTPv4, one or more extension fields can be inserted after the 213 header and before the MAC, which is always present when an extension 214 field is present. Other than defining the field format, this 215 document makes no use of the field contents. An extension field 216 contains a request or response message in the format shown in 217 Figure 14. 219 0 1 2 3 220 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 221 +---------------+---------------+-------------------------------+ 222 | Field Type | Field Length | 223 +-------------------------------+-------------------------------+ 224 . . 225 . Value . 226 . . 227 +-------------------------------+-------------------------------+ 228 | Padding (as needed) | 229 +---------------------------------------------------------------+ 231 Figure 14: Extension Field Format 233 All extension fields are zero-padded to a word (four octets) 234 boundary. The Field Type field is specific to the defined function 235 and is not elaborated here. While the minimum field length 236 containing required fields is four words (16 octets), a maximum field 237 length remains to be established. 239 The Length field is a 16-bit unsigned integer that indicates the 240 length of the entire extension field in octets, including the Padding 241 field. 243 4.2. NEW: RFC5905 Section 7.5 - NTP Extension Field Format 245 In NTPv4, one or more extension fields can be inserted after the 246 header and before the possibly optional legacy MAC. A MAC SHOULD be 247 present when an extension field is present. A MAC is always present 248 in some form when NTP packets are authenticated. This MAC SHOULD be 249 either a legacy MAC or a MAC-EF. It MAY be both. Other than 250 defining the field format, this document makes no use of the field 251 contents. An extension field contains a request or response message 252 in the format shown in Figure 14. 254 0 1 2 3 255 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 256 +---------------+---------------+-------------------------------+ 257 | Field Type | Field Length | 258 +-------------------------------+-------------------------------+ 259 . . 260 . Value . 261 . . 262 +-------------------------------+-------------------------------+ 263 | Padding (as needed) | 264 +---------------------------------------------------------------+ 266 Figure 14: Extension Field Format 268 All extension fields are zero-padded to a word (four octet) boundary. 269 The Field Type is specific to the defined function and detailed 270 information about the Field Type is not elaborated here. The minimum 271 size of an Extension Field is a 32-bit word (4 octets), and while the 272 maximum extension field size MUST be 65532 octets or less, an NTP 273 packet SHOULD NOT exceed the network MTU. 275 The Length field is a 16-bit unsigned integer that indicates the 276 length of the entire extension field in octets, including any Padding 277 octets. The bottom two bits of the Field Length SHOULD be zero, and 278 the size of the extension field SHOULD end on a 32-bit (4 octet) 279 boundary. [RFC5905 Section 7.5 says "All extension fields are zero- 280 padded to a word (four octets) boundary." but does not use 'MUST' 281 language. Is it overkill to reiterate this requirement here? Should 282 we use SHOULD or MUST regarding the bottom two bits or the boundary 283 of the EF? It is possible, down the road, that we might find some 284 use for those bottom 2 bits, even if we require a 32-bit boundary on 285 the last octet of an EF.] 286 The Field Type contains the following sub-elements: 288 0 1 2 3 289 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 290 +---------------+---------------+-------------------------------+ 291 |R|E| Code | Type | (Field Length) | 292 +-------------------------------+-------------------------------+ 294 Field Type Format 296 Where the following Field Type flags are defined: 298 R: 0 for a "Query", 1 for a "Response" 300 E: 0 for "OK", 1 for an "Error". Unused, and will be deprecated. 302 [The 'R' flag is currently used by Autokey, and by the proposed I-DO 303 extension field. This flag is used after the packet is accepted.] 305 [The 'E' flag was proposed for use by Autokey, after the packet was 306 accepted. As it was never used and no other use-cases have been 307 identified, we are recommending this flag be deprecated at some point 308 in the future.] 310 [The EF Code subtype is currently used by RFC 5906, Autokey 311 [RFC5906]. The EF Code subtype is used by the proposed Extended 312 Information EF proposal, and is expected to be used by the NTS 313 Extension Field, at least.] 315 The Autokey EF currently uses the most Code values - 10 of them, 316 which equates to the least-significant 4 bits of the high-order 317 octet. It is possible that additional flag bits will be allocated; 318 in the past, the high-order 2 bits were reserved, and for a time two 319 additional bits were proposed. Make no assumptions about the unused 320 bits in this octet. 322 The Field Type, Value, and Padding fields are specific to the defined 323 function and are not elaborated here; appropriate Field Type flags, 324 the EF Code, and EF Type values are defined in an IANA registry, and 325 the Length, Value, and Padding values are defined by the document 326 referred to by the registry. If a host receives an extension field 327 with an unknown Field Type, the host SHOULD ignore the extension 328 field and MAY drop the packet altogether, depending on local policy. 330 The Length field is a 16-bit unsigned integer that indicates the 331 length of the entire extension field in octets, including any 332 Padding. 334 While the minimum field length containing required fields is four 335 words (16 octets), the maximum field length MUST NOT be longer than 336 65532 octets due to the maximum size of the data represented by the 337 Length field, and SHOULD be small enough that the size of the NTP 338 packet received by the client does not exceed the smallest MTU 339 between the sender and the recipient. The bottom two bits of the 340 Field Length SHOULD be zero and the EF data SHOULD be aligned to a 341 32-bit (4 octet) boundary. 343 4.3. NEW: RFC5905 Section 7.5.1 - Extension Fields and MACs 345 With the inclusion of additional Extension Fields, there is now a 346 potential that a poorly-designed implementation would produce an 347 ambiguous parsing in the presence of a legacy MAC. If an 348 implementation offers even a modicum of care, there will be no 349 ambiguity when parsing an NTP packet that contains a legacy MAC from 350 an existing implementation. 352 The first protection from this ambiguity comes from the fact that 353 current conforming implementations only support the Autokey EF, which 354 uses EF Type 2 and a legacy MAC. While the Experimental UDP Checksum 355 Complement specified by RFC 7821 [RFC7821] uses EF Type 5, it 356 specifically prohibits the use of a MAC, and the 0x2000 bit in its 357 assigned EF specification of 0x2005 originally signified that a MAC 358 is optional when this EF is seen. While the 0x2000 bit is no longer 359 proposed as a means to flag that the MAC is optional, any usage of 360 this EF with a Code field of either 0x2005 or 0x0005 can be trivially 361 recognized as an Experimental UDP Checksum Complement EF, which does 362 not, indeed, MUST NOT be followed by a MAC. 364 [As a side note, the requirement in RFC 7821 [RFC7821] that the UDP 365 Checksum Complement EF must have a 28 octet length is demonstrably 366 not needed if this proposal is accepted. It only needs 8 octets: 4 367 octets of EF header, 2 octets of must-be-zero padding, and 2 octets 368 of Checksum Complement.] 370 If an implementation uses the LAST-EF extension field, the presence 371 of this field means "I am the last EF in this NTP Packet. Any 372 subsequent packet data MUST be a legacy MAC." In this case, there is 373 no parsing ambiguity. 375 If a system sends its MAC as a MAC-EF and does not send a legacy MAC, 376 there is no parsing ambiguity. 378 The only time there is a potential for a parsing ambiguity is when a 379 legacy MAC is provided and neither of the previous two cases are 380 present. Even in this case, there is minimal risk. 382 An implementation MAY choose to add padding to any EF, or at least 383 any EF that comes before a legacy MAC, to avoid an EF that is 16, 20, 384 or 24 octets in length. Doing this would generally avoid any risk of 385 mis-parsing. But this should not be needed for the following 386 reasons. 388 An Extension Field contains a 2-octet Field Type, a 2-octet Field 389 Length, and any payload (data and/or padding). If the NTP Packet 390 parsing is at a point where it is evaluating data after the base 391 packet, one of the following situations exists: 393 If the Field Length is not an even multiple of 4, we are not 394 looking at an extension field. In this case, the only possibility 395 of having a valid packet is if the data is part of a legacy MAC. 397 If the Field Length is valid, i.e., an even multiple of 4 octets, 398 one of the following three cases must be present: 400 First, the Field Length will be less than the remaining data. 401 This means subsequent data must parse as some number of 402 Extension Fields, optionally followed by a legacy MAC. 404 Second, the Field Length will exactly match the remaining data. 406 The third case is where the Field Length is longer than the 407 remaining packet data. In this case, the current parse cannot 408 be a valid extension field, and if the packet is valid, the 409 data must be a legacy MAC. 411 Semantic checking may also be done to validate a potential legacy 412 MAC. A legacy MAC is a four-octet Key Identifier followed by a 413 message digest. The usual message digest is 16 octets long but may 414 be another size, depending on the digest algorithm. In the Reference 415 Implementation and in implementations that follow the guidelines for 416 the values of the Key Identifier, a Key Identifier between 1 and 417 65535, inclusive, is a symmetric key, while a Key Identifier that is 418 > 65535 is an Autokey RFC 5906 [RFC5906], or similar. If the 419 receiving system does not recognize the Key Identifier, the data 420 CANNOT be a valid legacy MAC. If the receiving system recognizes the 421 Key Identifier, then it also has knowledge of the digest algorithm 422 and can make sure the digest payload is the proper length. If this 423 is not the case, then the data CANNOT be a valid legacy MAC. In this 424 case, it MIGHT be a valid extension field. 426 It is trivial to parse the data after the base NTP packet and come up 427 with a list of potential parsings. A local policy choice can specify 428 the precedence of the parsing options in this case. 430 If none of the parsings validate, the packet fails authentication. 431 An implementation has three local policy choices available if LAST-EF 432 is not used and a legacy MAC may be provided. First, the 433 implementation may specify EF-precedence. Second, the implementation 434 may specify legacy-MAC-precedence. Finally, the implementation may 435 specify "best fit" precedence. In this last case, the packet will 436 meet one of the three following criteria: First, none of the parsings 437 will match. Again, this is a case of failed authentication. Second, 438 exactly one parsing will match and that parsing will be accepted. 439 Third, multiple parsings will match, in which case the implementation 440 may choose its behavior. 442 Additionally, most EFs will require a MAC. If there is a 443 syntactically-valid parsing that does not include a MAC but 444 previously scanned EFs require a MAC, then in a multiple-choice 445 parsing scenario where one of the choices does not include a MAC the 446 "no MAC provided" choice SHOULD be eliminated. 448 Note well that this rare situation can be completely avoided by using 449 LAST-EF, or by indicating that no legacy MAC will be used. 451 Finally, in many cases at least one side will know if a MAC is 452 required or not. Client configurations of all types, unicast, 453 broadcast, multicast, and manycast, that state that a key will be 454 used to communicate with a server SHOULD reject packets claiming to 455 be from the server that do not include a MAC. Symmetric associations 456 also are configured with similar knowledge and requirements. 458 4.3.1. Legacy MAC/EF Parsing Pseudocode 460 Here are two potential pseudocode implementations showing how data 461 after the base NTP packet could be analyzed to identify EFs and a 462 possible legacy MAC. 464 Example 1: Generate a list of possible parsings: 466 struct pkt_parse { 467 foo * ef_ptr; 468 foo * legacy_mac; 469 struct pkt_parse * next; 470 }; 472 struct pkt_parse pkt_parse_chain = NULL; 474 EOPacket = address of last data in packet; 475 here = address of the EOBasePacket; 476 more_efs = 1; 477 while (1) { 478 int candidate = 0; 479 int ef_len = 0; 481 if (EOPacket > here) { 482 p = emalloc(pkt_parse); // *p is zeroed 483 if (this could be a legacy MAC) { // we know the keyid 484 p->legacy_mac = here; 485 candidate = 1; 486 } 487 if (more_efs && this could be an EF) { // Length field valid 488 p->ef_ptr = here; 489 ef_len = (the length of the EF); 490 here += ef_len; 491 if (this is a LAST_EF) { 492 more_efs = 0; 493 } 494 candidate = 1; 495 } else { 496 more_efs = 0; 497 } 498 } 500 if (candidate) { 501 p->next = pkt_parse_chain; 502 pkt_parse_chain = p; 503 } else { 504 free(p); 505 break; 506 } 507 } 509 Example 1: Generate a list of possible parsings 511 and at this point we can scan thru the items in pkt_parse_chain to do 512 deeper checks, throwing away the parsings that don't make sense. 514 This opens up more questions if we get multiple parsings and at least 515 1 of them is "valid". It's also perfectly reasonable to decide to 516 produce a single parse based on precedence rules: Prefer legacy MAC, 517 or prefer EF. 519 Example 2: Another possible way to handle EF/legacy-MAC parsing: 521 // We're at the end of the base NTP packet. 522 // A legacy MAC is allowed: 523 // - immediately after the base packet 524 // - immediately after one or more Autokey EFs (a non-issue, below) 525 // - immediately after a LAST-EF 527 ef_ok = 1; // An EF is allowed here 528 legacy_mac_ok = 1; // Legacy MAC allowed here 529 saw_mac = 0; // We haven't seen a MAC yet 530 authlen = LEN_PKT_NOMAC; // Length of a base packet 531 leg_mac = rbufp->recv_length - authlen; // # bytes after base 533 while (leg_mac > 0) { // Data after base packet 534 if (leg_mac % 4 != 0 || leg_mac < MIN_MAC_LEN) { 535 return: Bad packet length; 536 } 538 // If ef_ok, this could be an EF or legacy MAC 539 skeyid = ntohl(pkt[authlen / 4]); 540 opcode = skeyid >> 16; 541 len = skeyid & 0xffff; 543 if (ef_ok && GET_EXT_FIELD_TYPE(opcode) == EF_FT_LAST) { 544 if (leg_mac > MAX_MAC_LEN) { 545 return: Too much data after LAST_EF; 546 } 547 // Anything here MUST be a legacy MAC 548 ef_ok = 0; 549 legacy_mac_ok = 1; 550 } else { 551 if (4 == leg_mac && 0 == skeyid) { 552 break; // Likely crypto-NAK 553 } 555 if (legacy_mac_ok && leg_mac <= MAX_MAC_LEN) { 556 int ksize; 558 // If we find a keyid, we know its alg/length 559 ksize = auth_findkeysize(skeyid); 560 if ( ksize != -1 561 && ksize == leg_mac 562 && (it validates)) { 563 saw_mac = 1; 564 break; 565 } 566 // If we got here, it can't be a valid 567 // legacy MAC. It's still a potential EF. 568 } 570 if (!ef_ok) { 571 break; 572 } 574 // At this point, this SHOULD be an EF 576 if ( len % 4 != 0 577 || len < 4 578 || len + authlen > rbufp-> recv_length) { 579 return: Bad length; 580 } 582 switch (GET_EXT_FIELD_TYPE(opcode)) { 583 case EF_FT_AK: // Autokey 584 // extract calling group name for later 585 break; 586 case EF_FT_LAST: // LAST-EF 587 legacy_mac_ok = 1; 588 break; 589 default: 590 legacy_mac_ok = 0; 591 break; 592 } 593 } 595 authlen += len; 596 leg_mac -= len; 597 } 599 if (leg_mac < 0) { 600 return: Malformed packet 601 } 603 Example 2: Another way to handle EF/legacy-MAC parsing 605 4.4. OLD: RFC5905 Section 9.2. - Peer Process Operations 607 ... 609 FXMIT. ... This message includes the normal NTP header data shown in 610 Figure 8, but with a MAC consisting of four octets of zeros. ... 612 4.5. NEW: RFC5905 Section 9.2. - Peer Process Operations 614 ... 616 FXMIT. ... This message includes the normal NTP header data shown in 617 Figure 8, but with a MAC consisting of four octets of zeros. This 618 MAC can be a legacy MAC or a MAC-EF. If it's a MAC-EF, the crypto- 619 NAK MUST be the only MAC in the MAC-EF payload. ... 621 5. Acknowledgements 623 The authors wish to acknowledge the contributions of Sam Weiler, 624 Danny Mayer, and Tal Mizrahi. 626 6. IANA Considerations 628 This memo requests IANA to allocate the following bits in the NTP 629 Extension Field Types table: 631 0x8000: R: Response (0: Request, 1: Response) 633 0x4000: E: Error (0: OK, 1: Error) - Unused, deprecation expected 635 The following table should be the functionally the same as the 636 existing NTP Extension Field Table. 638 0 1 639 0123 4567 89012345 What: 640 +---------+--------+ 641 |RE Code| Type | 642 +---------+--------+ 643 |00 0 | 0 | crypto-NAK (with Field Length of 0) 644 | | 0 | RESERVED: Permanently Unassigned 645 +---------+--------+ 646 | | 1 | RESERVED: Unassigned 647 +---------+--------+ 648 |00 0 | 2 | Autokey: No-Operation Request 649 |10 0 | 2 | Autokey: No-Operation Response 650 +---------+--------+ 651 |00 1 | 2 | Autokey: Association Message Request 652 |10 1 | 2 | Autokey: Association Message Response 653 +---------+--------+ 654 |00 2 | 2 | Autokey: Certificate Message Request 655 |10 2 | 2 | Autokey: Certificate Message Response 656 +---------+--------+ 657 |00 3 | 2 | Autokey: Cookie Message Request 658 |10 3 | 2 | Autokey: Cookie Message Response 659 +---------+--------+ 660 |00 4 | 2 | Autokey: Autokey Message Request 661 |10 4 | 2 | Autokey: Autokey Message Response 662 +---------+--------+ 663 |00 5 | 2 | Autokey: Leapseconds Value Message Request 664 |10 5 | 2 | Autokey: Leapseconds Value Message Response 665 +---------+--------+ 666 |00 6 | 2 | Autokey: Sign Message Request 667 |10 6 | 2 | Autokey: Sign Message Response 668 +---------+--------+ 669 |00 7 | 2 | Autokey: IFF Identity Message Request 670 |10 7 | 2 | Autokey: IFF Identity Message Response 671 +--------+--------+ 672 |00 8 | 2 | Autokey: GQ Identity Message Request 673 |10 8 | 2 | Autokey: GQ Identity Message Response 674 +---------+--------+ 675 |00 9 | 2 | Autokey: MV Identity Message Request 676 |10 9 | 2 | Autokey: MV Identity Message Response 677 +---------+--------+ 678 | 0 | 5 | Checksum Complement 679 |00100000 | 5 | Checksum Complement 680 +----+----+--------+ 682 Current Extension Fields 684 7. Security Considerations 686 Additional information TBD 688 8. Normative References 690 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 691 Requirement Levels", BCP 14, RFC 2119, 692 DOI 10.17487/RFC2119, March 1997, 693 . 695 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 696 "Network Time Protocol Version 4: Protocol and Algorithms 697 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 698 . 700 [RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol 701 Version 4: Autokey Specification", RFC 5906, 702 DOI 10.17487/RFC5906, June 2010, 703 . 705 [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time 706 Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 707 2016, . 709 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 710 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, 711 March 2016, . 713 Authors' Addresses 715 Harlan Stenn 716 Network Time Foundation 717 P.O. Box 918 718 Talent, OR 97540 719 US 721 Email: stenn@nwtime.org 723 David L. Mills 724 Network Time Foundation 725 P.O. Box 918 726 Talent, OR 97540 727 US 729 Email: mills@udel.edu