idnits 2.17.1 draft-stenn-ntp-extension-fields-04.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 abstract seems to indicate that this document obsoletes RFC5905, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC5906, but the header doesn't have an 'Obsoletes:' line to match this. -- 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 (December 4, 2017) is 2334 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 (==), 4 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 Network Time Foundation 4 Obsoletes: 7822 (if approved) December 4, 2017 5 Intended status: Standards Track 6 Expires: June 7, 2018 8 Network Time Protocol Version 4 (NTPv4) Extension Fields 9 draft-stenn-ntp-extension-fields-04 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 obsoletes 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 June 7, 2018. 40 Copyright Notice 42 Copyright (c) 2017 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 . . . 14 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 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 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 is usually 20 88 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 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] has always clearly stated that "one 105 or more extension fields can be inserted after the header and before 106 the MAC, 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. 113 RFC 7822 [RFC7822] was an attempt to clarify and change the rules 114 around MACs, but in doing so, it completely removed the long-standing 115 rule that the presence of an extension field required MAC protection, 116 added an express limit to the length of a MAC, and required that all 117 EFs be at least 28 octets long. Pushing the decision about whether 118 or not a packet must be authenticated later in the process reduces 119 throughput performance and opens NTP up to clogging attacks. 120 Expressly limiting the length of a MAC prohibits the use of longer 121 MACs, should that ever be needed. Requiring EFs to be at least 28 122 octets long is needlessly wasteful. 124 This proposal follows existing and proposed behavior of the NTP 125 reference implementation in that it describes a simple and clean way 126 to identify the case where an extension field must not have or would 127 not require a MAC, allows EFs to be on 4-octet boundaries of any 128 acceptable length, and provides methods to disambiguate packet 129 parsing in the unexpected case where an implementation would choose 130 to send a packet that could be ambiguously parsed. This proposal 131 obsoletes RFC 7822 [RFC7822]. 133 This document better specifies and clarifies extension fields as well 134 as the requirements and parsing of a legacy MAC, with changes to 135 address errors found after the publication of RFC 5905 [RFC5905] with 136 respect to extension fields. Specifically, this document updates 137 Section 7.5 of RFC 5905 [RFC5905], clarifying the relationship 138 between extension fields and MACs, and expressly defines the behavior 139 of a host that receives an unknown extension field. 141 2. Conventions Used in This Document 143 2.1. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 2.2. Terms and Abbreviations 151 EF - Extension Field 153 MAC - Message Authentication Code 155 NTPv4 - Network Time Protocol, Version 4 RFC 5905 [RFC5905] 157 3. NTP MAC - RFC 5906 Update 159 This document copies and updates some information in RFC 5906 160 [RFC5906] and puts it in to RFC 5905, as follows: 162 3.1. RFC5906 Section 4. - Autokey Cryptography 164 This section describes some of the cryptography aspects of Autokey. 165 The third paragraph describes the use of 128- and 160-bit message 166 digests. The enumeration of 128- and 160-bit message digests is not 167 meant to be limiting - other message digest lengths MAY be 168 implemented. This paragraph also describes some of the recommended 169 semantic ranges of the key ID. This information belongs in RFC 5905. 170 The key ID value is particularly significant because it provide 171 additional disambiguation protection when deciding if the next data 172 portion is either a legacy MAC or an extension field. 174 3.2. RFC5906 Section 10. - Autokey Protocol Messages 176 This section describes the extension field format, including initial 177 flag bits, a Code field, and 8-bit Field Type, and the 16-bit Length. 178 This proposal expands and clarifies this information and puts it into 179 RFC 5905. 181 This section says "The reference implementation discards any packet 182 with a field length of more than 1024 characters." but this is no 183 longer true. 185 3.3. RFC5906 Section 11.5. - Error Recovery 187 This section describes the crypto-NAK, which should be described in 188 RFC 5905. 190 3.4. RFC5906 Section 13. - IANA Consideration 192 This section lists the Autokey-related Extension Field Types, 193 including Flag Bits, Codes, and Field Types, which should be 194 described in RFC 5905, or perhaps in some other document. 196 4. NTP Extension Fields - RFC 5905 Update 198 This document updates Section 7.5 of RFC 5905 [RFC5905] as follows: 200 4.1. OLD: RFC5905 7.5 - NTP Extension Field Format 202 In NTPv4, one or more extension fields can be inserted after the 203 header and before the MAC, which is always present when an extension 204 field is present. Other than defining the field format, this 205 document makes no use of the field contents. An extension field 206 contains a request or response message in the format shown in 207 Figure 14. 209 0 1 2 3 210 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 211 +---------------+---------------+-------------------------------+ 212 | Field Type | Field Length | 213 +-------------------------------+-------------------------------+ 214 . . 215 . Value . 216 . . 217 +-------------------------------+-------------------------------+ 218 | Padding (as needed) | 219 +---------------------------------------------------------------+ 221 Figure 14: Extension Field Format 223 All extension fields are zero-padded to a word (four octets) 224 boundary. The Field Type field is specific to the defined function 225 and is not elaborated here. While the minimum field length 226 containing required fields is four words (16 octets), a maximum field 227 length remains to be established. 229 The Length field is a 16-bit unsigned integer that indicates the 230 length of the entire extension field in octets, including the Padding 231 field. 233 4.2. NEW: RFC5905 Section 7.5 - NTP Extension Field Format 235 In NTPv4, one or more extension fields can be inserted after the 236 header and before the possibly optional legacy MAC. A MAC SHOULD be 237 present when an extension field is present. A MAC is always present 238 in some form when NTP packets are authenticated. This MAC SHOULD be 239 either a legacy MAC or a MAC-EF. It MAY be both. Other than 240 defining the field format, this document makes no use of the field 241 contents. An extension field contains a request or response message 242 in the format shown in Figure 14. 244 0 1 2 3 245 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 246 +---------------+---------------+-------------------------------+ 247 | Field Type | Field Length | 248 +-------------------------------+-------------------------------+ 249 . . 250 . Value . 251 . . 252 +-------------------------------+-------------------------------+ 253 | Padding (as needed) | 254 +---------------------------------------------------------------+ 256 Figure 14: Extension Field Format 258 All extension fields are zero-padded to a word (four octet) boundary. 259 The Field Type is specific to the defined function and detailed 260 information about the Field Type is not elaborated here. The minimum 261 size of an Extension Field is a 32-bit word (4 octets), and while the 262 maximum extension field size MUST be 65532 octets or less, an NTP 263 packet SHOULD NOT exceed the network MTU. 265 The Length field is a 16-bit unsigned integer that indicates the 266 length of the entire extension field in octets, including any Padding 267 octets. The bottom two bits of the Field Length SHOULD be zero, and 268 the size of the extension field SHOULD end on a 32-bit (4 octet) 269 boundary. [RFC5905 Section 7.5 says "All extension fields are zero- 270 padded to a word (four octets) boundary." but does not use 'MUST' 271 language. Is it overkill to reiterate this requirement here? Should 272 we use SHOULD or MUST regarding the bottom two bits or the boundary 273 of the EF? It is possible, down the road, that we might find some 274 use for those bottom 2 bits, even if we require a 32-bit boundary on 275 the last octet of an EF.] 277 The Field Type contains the following sub-elements: 279 0 1 2 3 280 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 281 +---------------+---------------+-------------------------------+ 282 |R|E|O|I| Code | Type | (Field Length) | 283 +-------------------------------+-------------------------------+ 285 Field Type Format 287 Where the following Field Type flags are defined: 289 R: 0 for a "Query", 1 for a "Response" 291 E: 0 for "OK", 1 for an "Error" 293 O: 0 for "MAC Required", 1 for "MAC Optional" 295 I: 0 for "MAC Not Included", 1 for "MAC Included" 297 [The 'R' flag is currently used by Autokey, and by the proposed I-DO 298 extension field. This flag is used after the packet is accepted.] 300 [The 'E' flag is currently used by Autokey. This flag is used after 301 the packet is accepted.] 303 [The 'O' flag is used by RFC 7821 [RFC7821], the I-DO, SUGGEST-REFID, 304 and the LAST-EF proposal. This flag is used during the initial 305 packet analysis.] 307 [The 'I' flag is used by the MAC-EF proposal, and would be used by 308 any EF proposal that includes a MAC in its data. This flag is used 309 during the initial packet analysis.] 311 [The EF Code subtype is currently used by RFC 5906, Autokey 312 [RFC5906]. The EF Code subtype is used by the Extended Information 313 EF proposal, and is expected to be used by the NTS Extension Field, 314 at least.] 316 The Field Type, Value, and Padding fields are specific to the defined 317 function and are not elaborated here; appropriate Field Type flags, 318 the EF Code, and EF Type values are defined in an IANA registry, and 319 the Length, Value, and Padding values are defined by the document 320 referred to by the registry. If a host receives an extension field 321 with an unknown Field Type, the host SHOULD ignore the extension 322 field and MAY drop the packet altogether, depending on local policy. 324 The Length field is a 16-bit unsigned integer that indicates the 325 length of the entire extension field in octets, including any 326 Padding. 328 While the minimum field length containing required fields is four 329 words (16 octets), the maximum field length MUST NOT be longer than 330 65532 octets due to the maximum size of the data represented by the 331 Length field, and SHOULD be small enough that the size of the NTP 332 packet received by the client does not exceed the smallest MTU 333 between the sender and the recipient. The bottom two bits of the 334 Field Length SHOULD be zero and the EF data SHOULD be aligned to a 335 32-bit (4 octet) boundary. 337 4.3. NEW: RFC5905 Section 7.5.1 - Extension Fields and MACs 339 With the inclusion of additional Extension Fields, there is now a 340 potential that a poorly-designed implementation would produce an 341 ambiguous parsing in the presence of a legacy MAC. If an 342 implementation offers even a modicum of care, there will be no 343 ambiguity when parsing an NTP packet that contains a legacy MAC from 344 an existing implementation. 346 The first protection from this ambiguity comes from the fact that 347 current conforming implementations only support the Autokey EF, which 348 uses EF Type 2 and a legacy MAC. While the Experimental UDP Checksum 349 Complement specified by RFC 7821 [RFC7821] uses EF Type 5, it 350 specifically prohibits the use of a MAC, and the 0x2000 bit in its 351 assigned EF specification of 0x2005 signifies that a MAC is optional 352 when this EF is provided. 354 [As a side note, the requirement in RFC 7821 [RFC7821] that the UDP 355 Checksum Complement EF must have a 28 octet length is demonstrably 356 not needed if this proposal is accepted. It only needs 8 octets: 4 357 octets of EF header, 2 octets of must-be-zero padding, and 2 octets 358 of Checksum Complement.] 360 If an implementation uses the LAST-EF extension field, the presence 361 of this field means "I am the last EF in this NTP Packet. Any 362 subsequent packet data MUST be a legacy MAC." In this case, there is 363 no parsing ambiguity. 365 If a system sends its MAC as a MAC-EF and does not send a legacy MAC, 366 there is no parsing ambiguity. 368 The only time there is a potential for a parsing ambiguity is when a 369 legacy MAC is provided and neither of the previous two cases are 370 present. Even in this case, there is minimal risk. 372 An Extension Field contains a 2-octet Field Type, a 2-octet Field 373 Length, and any payload (data and/or padding). If the NTP Packet 374 parsing is at a point where it is evaluating data after the base 375 packet, one of the following situations exists: 377 If the Field Length is not an even multiple of 4, we are not 378 looking at an extension field. In this case, the only possibility 379 of having a valid packet is if the data is part of a legacy MAC. 381 If the Field Length is valid, i.e., an even multiple of 4 octets, 382 one of the following three cases must be present: 384 First, the Field Length will be less than the remaining data. 385 This means subsequent data must parse as some number of 386 Extension Fields, optionally followed by a legacy MAC. 388 Second, the Field Length will exactly match the remaining data. 390 The third case is where the Field Length is longer than the 391 remaining packet data. In this case, the current parse cannot 392 be a valid extension field, and if the packet is valid, the 393 data must be a legacy MAC. 395 Semantic checking may also be done to validate a potential legacy 396 MAC. A legacy MAC is a four-octet Key Identifier followed by a 397 message digest. The usual message digest is 16 octets long but may 398 be another size, depending on the digest algorithm. In the Reference 399 Implementation, a Key Identifier between 1 and 65535, inclusive, is a 400 symmetric key, while a Key Identifier that is > 65535 is an Autokey 401 RFC 5906 [RFC5906], or similar. If the receiving system does not 402 recognize the Key Identifier, the data CANNOT be a valid legacy MAC. 403 If the receiving system recognizes the Key Identifier, then it also 404 has knowledge of the digest algorithm and can make sure the digest 405 payload is the proper length. If this is not the case, then the data 406 CANNOT be a valid legacy MAC. In this case, it MIGHT be a valid 407 extension field. 409 It is trivial to parse the data after the base NTP packet and come up 410 with a list of potential parsings. A local policy choice can specify 411 the precedence of the parsing options in this case. 413 If none of the parsings validate, the packet fails authentication. 414 An implementation has three local policy choices available if LAST-EF 415 is not used and a legacy MAC may be provided. First, the 416 implementation may specify EF-precedence. Second, the implementation 417 may specify legacy-MAC-precedence. Finally, the implementation may 418 specify "best fit" precedence. In this last case, the packet will 419 meet one of the three following criteria: First, none of the parsings 420 will match. Again, this is a case of failed authentication. Second, 421 exactly one parsing will match and that parsing will be accepted. 422 Third, multiple parsings will match, in which case the implementation 423 may choose its behavior. 425 Additionally, most EFs will require a MAC. If there is a 426 syntactically-valid parsing that does not include a MAC but 427 previously scanned EFs require a MAC, then in a multiple-choice 428 parsing scenario where one of the choices does not include a MAC the 429 "no MAC provided" choice SHOULD be eliminated. 431 Note well that this rare situation can be completely avoided by using 432 LAST-EF, or by indicating that no legacy MAC will be used. 434 4.3.1. Legacy MAC/EF Parsing Pseudocode 436 Here are two potential pseudocode implementations showing how data 437 after the base NTP packet could be analyzed to identify EFs and a 438 possible legacy MAC. 440 Example 1: Generate a list of possible parsings: 442 struct pkt_parse { 443 foo * ef_ptr; 444 foo * legacy_mac; 445 struct pkt_parse * next; 446 }; 448 struct pkt_parse pkt_parse_chain = NULL; 450 EOPacket = address of last data in packet; 451 here = address of the EOBasePacket; 452 more_efs = 1; 453 while (1) { 454 int candidate = 0; 455 int ef_len = 0; 457 if (EOPacket > here) { 458 p = emalloc(pkt_parse); // *p is zeroed 459 if (this could be a legacy MAC) { // we know the keyid 460 p->legacy_mac = here; 461 candidate = 1; 462 } 463 if (more_efs && this could be an EF) { // Length field valid 464 p->ef_ptr = here; 465 ef_len = (the length of the EF); 466 here += ef_len; 467 if (this is a LAST_EF) { 468 more_efs = 0; 469 } 470 candidate = 1; 471 } else { 472 more_efs = 0; 473 } 474 } 476 if (candidate) { 477 p->next = pkt_parse_chain; 478 pkt_parse_chain = p; 479 } else { 480 free(p); 481 break; 482 } 483 } 485 Example 1: Generate a list of possible parsings 487 and at this point we can scan thru the items in pkt_parse_chain to do 488 deeper checks, throwing away the parsings that don't make sense. 490 This opens up more questions if we get multiple parsings and at least 491 1 of them is "valid". It's also perfectly reasonable to decide to 492 produce a single parse based on precedence rules: Prefer legacy MAC, 493 or prefer EF. 495 Example 2: Another possible way to handle EF/legacy-MAC parsing: 497 // We're at the end of the base NTP packet. 498 // A legacy MAC is allowed: 499 // - immediately after the base packet 500 // - immediately after one or more Autokey EFs(a non-issue, below) 501 // - immediately after a LAST-EF 503 ef_ok = 1; // An EF is allowed here 504 legacy_mac_ok = 1; // Legacy MAC allowed here 505 req_mac = 0; // A MAC is not required 506 saw_mac = 0; // We haven't seen a MAC yet 507 authlen = LEN_PKT_NOMAC; // Length of a base packet 508 leg_mac = rbufp->recv_length - authlen; // # bytes after base 510 while (leg_mac > 0) { // Data after base packet 511 if (leg_mac % 4 != 0 || leg_mac < MIN_MAC_LEN) { 512 return: Bad packet length; 513 } 515 // If ef_ok, this could be an EF or legacy MAC 516 skeyid = ntohl(pkt[authlen / 4]); 517 opcode = skeyid >> 16; 518 len = skeyid & 0xffff; 520 if (ef_ok && GET_EXT_FIELD_TYPE(opcode) == EF_FT_LAST) { 521 if (leg_mac > MAX_MAC_LEN) { 522 return: Too much data after LAST_EF; 523 } 524 // Anything here MUST be a legacy MAC 525 ef_ok = 0; 526 legacy_mac_ok = 1; 527 } else { 528 if (4 == leg_mac && 0 == skeyid) { 529 break;// Likely crypto-NAK 530 } 532 if (legacy_mac_ok && leg_mac <= MAX_MAC_LEN) { 533 int ksize; 535 // If we find a keyid, we know its alg/length 536 ksize = auth_findkeysize(skeyid); 537 if (ksize != -1) { 538 saw_mac = 1; 539 break; 540 } 541 // If we didn't find it, it can't be a valid 542 // legacy MAC. It's still a potential EF. 543 } 545 if (!ef_ok) { 546 break; 547 } 549 // At this point, this SHOULD be an EF 551 if ( len % 4 != 0 552 || len < 4 553 || len + authlen > rbufp-> recv_length) { 554 return: Bad length; 555 } 557 if (opcode & EF_FL_reoI) { // EF contains MAC 558 saw_mac = 1; // Just a hint 559 } 560 if (opcode & EF_FL_reOi) { // MAC optional 561 // Empty 562 } else { 563 req_mac = 1; // MAC required 564 } 565 switch (GET_EXT_FIELD_TYPE(opcode)) { 566 case EF_FT_AK: // Autokey 567 // extract calling group name for later 568 break; 569 case EF_FT_LAST: // LAST-EF 570 legacy_mac_ok = 1; 571 break; 572 default: 573 legacy_mac_ok = 0; 574 break; 575 } 576 } 578 authlen += len; 579 leg_mac -= len; 580 } 582 if (leg_mac < 0) { 583 return: Malformed packet 584 } 585 Example 2: Another way to handle EF/legacy-MAC parsing 587 4.4. OLD: RFC5905 Section 9.2. - Peer Process Operations 589 ... 591 FXMIT. ... This message includes the normal NTP header data shown in 592 Figure 8, but with a MAC consisting of four octets of zeros. ... 594 4.5. NEW: RFC5905 Section 9.2. - Peer Process Operations 596 ... 598 FXMIT. ... This message includes the normal NTP header data shown in 599 Figure 8, but with a MAC consisting of four octets of zeros. This 600 can be a legacy MAC or a MAC-EF. If it's a MAC-EF, the crypto-NAK 601 MUST be the only MAC in the MAC-EF payload. ... 603 5. Acknowledgements 605 The author wishes to acknowledge the contributions of Sam Weiler. 607 6. IANA Considerations 609 This memo requests IANA to allocate the following bits in the NTP 610 Extension Field Types table: 612 0x8000: R: Response (0: Request, 1: Response) 614 0x4000: E: Error (0: OK, 1: Error) 616 0x2000: O: MAC Optional (0: MAC required, 1: MAC optional) 618 0x1000: I: MAC Included (0: MAC not included, 1: MAC included) 620 The following table should be the same as the existing NTP Extension 621 Field Table, reformatted to account for the new flag bits. 623 0 1 624 0123 4567 89012345 What: 625 +----+----+--------+ 626 |REOI|Code| Type | 627 +----+----+--------+ 628 |0000| 0 | 0 | crypto-NAK (with Field Length of 0) 629 | | | 0 | RESERVED: Permanently Unassigned 630 +----+----+--------+ 631 | | | 1 | RESERVED: Unassigned 632 +----+----+--------+ 633 |0000| 0 | 2 | Autokey: No-Operation Request 634 |1000| 0 | 2 | Autokey: No-Operation Response 635 |1100| 0 | 2 | Autokey: No-Operation Error Response 636 +----+----+--------+ 637 |0000| 1 | 2 | Autokey: Association Message Request 638 |1000| 1 | 2 | Autokey: Association Message Response 639 |1100| 1 | 2 | Autokey: Association Message Error Response 640 +----+----+--------+ 641 |0000| 2 | 2 | Autokey: Certificate Message Request 642 |1000| 2 | 2 | Autokey: Certificate Message Response 643 |1100| 2 | 2 | Autokey: Certificate Message Error Response 644 +----+----+--------+ 645 |0000| 3 | 2 | Autokey: Cookie Message Request 646 |1000| 3 | 2 | Autokey: Cookie Message Response 647 |1100| 3 | 2 | Autokey: Cookie Message Error Response 648 +----+----+--------+ 649 |0000| 4 | 2 | Autokey: Autokey Message Request 650 |1000| 4 | 2 | Autokey: Autokey Message Response 651 |1100| 4 | 2 | Autokey: Autokey Message Error Response 652 +----+----+--------+ 653 |0000| 5 | 2 | Autokey: Leapseconds Value Message Request 654 |1000| 5 | 2 | Autokey: Leapseconds Value Message Response 655 |1100| 5 | 2 | Autokey: Leapseconds Value Msg Error Response 656 +----+----+--------+ 657 |0000| 6 | 2 | Autokey: Sign Message Request 658 |1000| 6 | 2 | Autokey: Sign Message Response 659 |1100| 6 | 2 | Autokey: Sign Message Error Response 660 +----+----+--------+ 661 |0000| 7 | 2 | Autokey: IFF Identity Message Request 662 |1000| 7 | 2 | Autokey: IFF Identity Message Response 663 |1100| 7 | 2 | Autokey: IFF Identity Message Error Response 664 +----+----+--------+ 665 |0000| 8 | 2 | Autokey: GQ Identity Message Request 666 |1000| 8 | 2 | Autokey: GQ Identity Message Response 667 |1100| 8 | 2 | Autokey: GQ Identity Message Error Response 668 +----+----+--------+ 669 |0000| 9 | 2 | Autokey: MV Identity Message Request 670 |1000| 9 | 2 | Autokey: MV Identity Message Response 671 |1100| 9 | 2 | Autokey: MV Identity Message Error Response 672 +----+----+--------+ 673 |0010| 0 | 5 | Checksum Complement 674 +----+----+--------+ 676 Current Extension Fields 678 7. Security Considerations 680 Additional information TBD 682 8. Normative References 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", BCP 14, RFC 2119, 686 DOI 10.17487/RFC2119, March 1997, 687 . 689 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 690 "Network Time Protocol Version 4: Protocol and Algorithms 691 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 692 . 694 [RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol 695 Version 4: Autokey Specification", RFC 5906, 696 DOI 10.17487/RFC5906, June 2010, 697 . 699 [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time 700 Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 701 2016, . 703 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 704 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, 705 March 2016, . 707 Author's Address 709 Harlan Stenn 710 Network Time Foundation 711 P.O. Box 918 712 Talent, OR 97540 713 US 715 Email: stenn@nwtime.org