idnits 2.17.1 draft-stenn-ntp-extension-fields-06.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 (March 21, 2018) is 2221 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 March 21, 2018 6 Expires: September 22, 2018 8 Network Time Protocol Version 4 (NTPv4) Extension Fields 9 draft-stenn-ntp-extension-fields-06 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 September 22, 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 . . . . . . . . . . . . . . 3 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . 4 65 3.4. RFC5906 Section 13. - IANA Consideration . . . . . . . . 4 66 4. NTP Extension Fields - RFC 5905 Update . . . . . . . . . . . 4 67 4.1. OLD: RFC5905 7.5 - NTP Extension Field Format . . . . . . 4 68 4.2. NEW: RFC5905 Section 7.5 - NTP Extension Field Format . . 5 69 4.3. NEW: RFC5905 Section 7.5.1 - Extension Fields and MACs . 7 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 . . . . . . . . . . . . . . . . . . . 15 76 8. Normative References . . . . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 An NTP packet consists of a set of fixed fields that may be followed 82 by optional fields. Two types of optional fields are defined: 83 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 expectation that RFC 5906 97 will be deprecated, this document does not propose changes or updates 98 to RFC 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 With the knowledge and experience we have gained over time, it has 106 become clear that simplifications, clarifications, and improvements 107 can be made to the NTP specification around EFs and MACs. 109 This proposal adjusts the requirements around EFs and MACs, allows 110 EFs to be on 4-octet boundaries of any acceptable length, and 111 provides methods to disambiguate packet parsing in the unexpected and 112 unlikely case where an implementation would choose to send a packet 113 that could be ambiguously parsed by the receiver. 115 This proposal deprecates RFC 7822 [RFC7822]. 117 This document better specifies and clarifies extension fields as well 118 as the requirements and parsing of a legacy MAC, with changes to 119 address errors found after the publication of RFC 5905 [RFC5905] with 120 respect to extension fields. Specifically, this document updates 121 Section 7.5 of RFC 5905 [RFC5905], clarifying the relationship 122 between extension fields and MACs, and expressly defines the behavior 123 of a host that receives an unknown extension field. 125 2. Conventions Used in This Document 127 2.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 2.2. Terms and Abbreviations 135 EF - Extension Field 137 MAC - Message Authentication Code 139 NTPv4 - Network Time Protocol, Version 4 RFC 5905 [RFC5905] 141 3. NTP MAC - RFC 5906 Update 143 This document copies and updates some information in RFC 5906 144 [RFC5906] and puts it in to RFC 5905, as follows: 146 3.1. RFC5906 Section 4. - Autokey Cryptography 148 This section describes some of the cryptography aspects of Autokey. 149 The third paragraph describes the use of 128- and 160-bit message 150 digests. The enumeration of 128- and 160-bit message digests is not 151 meant to be limiting - other message digest lengths MAY be 152 implemented. This paragraph also describes some of the recommended 153 semantic ranges of the key ID. This information belongs in RFC 5905. 154 The key ID value is particularly significant because it provide 155 additional disambiguation protection when deciding if the next data 156 portion is either a legacy MAC or an extension field. 158 3.2. RFC5906 Section 10. - Autokey Protocol Messages 160 This section describes the extension field format, including initial 161 flag bits, a Code field, and 8-bit Field Type, and the 16-bit Length. 162 This proposal expands and clarifies this information and puts it into 163 RFC 5905. 165 This section says "The reference implementation discards any packet 166 with a field length of more than 1024 characters." but this is no 167 longer true. 169 3.3. RFC5906 Section 11.5. - Error Recovery 171 This section describes the crypto-NAK, which should be described in 172 RFC 5905. 174 3.4. RFC5906 Section 13. - IANA Consideration 176 This section lists the Autokey-related Extension Field Types, 177 including Flag Bits, Codes, and Field Types, which should be 178 described in RFC 5905, or perhaps in some other document. 180 4. NTP Extension Fields - RFC 5905 Update 182 This document updates Section 7.5 of RFC 5905 [RFC5905] as follows: 184 4.1. OLD: RFC5905 7.5 - NTP Extension Field Format 186 In NTPv4, one or more extension fields can be inserted after the 187 header and before the MAC, which is always present when an extension 188 field is present. Other than defining the field format, this 189 document makes no use of the field contents. An extension field 190 contains a request or response message in the format shown in 191 Figure 14. 193 0 1 2 3 194 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 195 +---------------+---------------+-------------------------------+ 196 | Field Type | Field Length | 197 +-------------------------------+-------------------------------+ 198 . . 199 . Value . 200 . . 201 +-------------------------------+-------------------------------+ 202 | Padding (as needed) | 203 +---------------------------------------------------------------+ 205 Figure 14: Extension Field Format 207 All extension fields are zero-padded to a word (four octets) 208 boundary. The Field Type field is specific to the defined function 209 and is not elaborated here. While the minimum field length 210 containing required fields is four words (16 octets), a maximum field 211 length remains to be established. 213 The Length field is a 16-bit unsigned integer that indicates the 214 length of the entire extension field in octets, including the Padding 215 field. 217 4.2. NEW: RFC5905 Section 7.5 - NTP Extension Field Format 219 In NTPv4, one or more extension fields can be inserted after the 220 header and before the possibly optional legacy MAC. A MAC SHOULD be 221 present when an extension field is present. A MAC is always present 222 in some form when NTP packets are authenticated. This MAC SHOULD be 223 either a legacy MAC or a MAC-EF. It MAY be both. Other than 224 defining the field format, this document makes no use of the field 225 contents. An extension field contains a request or response message 226 in the format shown in Figure 14. 228 0 1 2 3 229 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 230 +---------------+---------------+-------------------------------+ 231 | Field Type | Field Length | 232 +-------------------------------+-------------------------------+ 233 . . 234 . Value . 235 . . 236 +-------------------------------+-------------------------------+ 237 | Padding (as needed) | 238 +---------------------------------------------------------------+ 240 Figure 14: Extension Field Format 242 All extension fields are zero-padded to a word (four octet) boundary. 243 The Field Type is specific to the defined function and detailed 244 information about the Field Type is not elaborated here. The minimum 245 size of an Extension Field is a 32-bit word (4 octets), and while the 246 maximum extension field size MUST be 65532 octets or less, an NTP 247 packet SHOULD NOT exceed the network MTU. 249 The Length field is a 16-bit unsigned integer that indicates the 250 length of the entire extension field in octets, including any Padding 251 octets. The bottom two bits of the Field Length SHOULD be zero, and 252 the size of the extension field SHOULD end on a 32-bit (4 octet) 253 boundary. [RFC5905 Section 7.5 says "All extension fields are zero- 254 padded to a word (four octets) boundary." but does not use 'MUST' 255 language. Is it overkill to reiterate this requirement here? Should 256 we use SHOULD or MUST regarding the bottom two bits or the boundary 257 of the EF? It is possible, down the road, that we might find some 258 use for those bottom 2 bits, even if we require a 32-bit boundary on 259 the last octet of an EF.] 261 The Field Type contains the following sub-elements: 263 0 1 2 3 264 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 265 +---------------+---------------+-------------------------------+ 266 |R|E| Code | Type | (Field Length) | 267 +-------------------------------+-------------------------------+ 269 Field Type Format 271 Where the following Field Type flags are defined: 273 R: 0 for a "Query", 1 for a "Response" 275 E: 0 for "OK", 1 for an "Error". Unused, and will be deprecated. 277 [The 'R' flag is currently used by Autokey, and by the proposed I-DO 278 extension field. This flag is used after the packet is accepted.] 280 [The 'E' flag was proposed for use by Autokey, after the packet was 281 accepted. As it was never used and no other use-cases have been 282 identified, we are recommending this flag be deprecated at some point 283 in the future.] 285 [The EF Code subtype is currently used by RFC 5906, Autokey 286 [RFC5906]. The EF Code subtype is used by the proposed Extended 287 Information EF proposal, and is expected to be used by the NTS 288 Extension Field, at least.] 290 The Autokey EF currently uses the most Code values - 10 of them, 291 which equates to the least-significant 4 bits of the high-order 292 octet. It is possible that additional flag bits will be allocated; 293 in the past, the high-order 2 bits were reserved, and for a time two 294 additional bits were proposed. Make no assumptions about the unused 295 bits in this octet. 297 The Field Type, Value, and Padding fields are specific to the defined 298 function and are not elaborated here; appropriate Field Type flags, 299 the EF Code, and EF Type values are defined in an IANA registry, and 300 the Length, Value, and Padding values are defined by the document 301 referred to by the registry. If a host receives an extension field 302 with an unknown Field Type, the host SHOULD ignore the extension 303 field and MAY drop the packet altogether, depending on local policy. 305 The Length field is a 16-bit unsigned integer that indicates the 306 length of the entire extension field in octets, including any 307 Padding. 309 While the minimum field length of an EF that contains no value fields 310 is one word (four octets), and the minimum field length of an EF that 311 contains required fields is two words (8 octets), the maximum field 312 length MUST NOT be longer than 65532 octets due to the maximum size 313 of the data represented by the Length field, and SHOULD be small 314 enough that the size of the NTP packet received by the client does 315 not exceed the smallest MTU between the sender and the recipient. 316 The bottom two bits of the Field Length SHOULD be zero and the EF 317 data SHOULD be aligned to a 32-bit (4 octet) boundary. 319 4.3. NEW: RFC5905 Section 7.5.1 - Extension Fields and MACs 321 With the inclusion of additional Extension Fields, there is now a 322 potential that a poorly-designed implementation would produce an 323 ambiguous parsing in the presence of a legacy MAC. If an 324 implementation offers even a modicum of care, there will be no 325 ambiguity when parsing an NTP packet that contains a legacy MAC from 326 an existing implementation. 328 The first protection from this ambiguity comes from the fact that 329 current conforming implementations only support the Autokey EF, which 330 uses EF Type 2 and a legacy MAC. While the Experimental UDP Checksum 331 Complement specified by RFC 7821 [RFC7821] uses EF Type 5, it 332 specifically prohibits the use of a MAC, and the 0x2000 bit in its 333 assigned EF specification of 0x2005 originally signified that a MAC 334 is optional when this EF is seen. While the 0x2000 bit is no longer 335 proposed as a means to flag that the MAC is optional, any usage of 336 this EF with a Code field of either 0x2005 or 0x0005 can be trivially 337 recognized as an Experimental UDP Checksum Complement EF, which does 338 not, indeed, MUST NOT be followed by a MAC. 340 [As a side note, the requirement in RFC 7821 [RFC7821] that the UDP 341 Checksum Complement EF must have a 28 octet length is demonstrably 342 not needed if this proposal is accepted. It only needs 8 octets: 4 343 octets of EF header, 2 octets of must-be-zero padding, and 2 octets 344 of Checksum Complement.] 346 If an implementation uses the LAST-EF extension field, the presence 347 of this field means "I am the last EF in this NTP Packet. Any 348 subsequent packet data MUST be a legacy MAC." In this case, there is 349 no parsing ambiguity. 351 If a system sends its MAC as a MAC-EF and does not send a legacy MAC, 352 there is no parsing ambiguity. 354 The only time there is a potential for a parsing ambiguity is when a 355 legacy MAC is provided and neither of the previous two cases are 356 present. Even in this case, there is minimal risk. 358 An implementation MAY choose to add padding to any EF, or at least 359 any EF that comes before a legacy MAC, to avoid an EF that is 16, 20, 360 or 24 octets in length. Doing this would generally avoid any risk of 361 mis-parsing. But this should not be needed for the following 362 reasons. 364 An Extension Field contains a 2-octet Field Type, a 2-octet Field 365 Length, and any payload (data and/or padding). If the NTP Packet 366 parsing is at a point where it is evaluating data after the base 367 packet, one of the following situations exists: 369 If the Field Length is not an even multiple of 4, we are not 370 looking at an extension field. In this case, the only possibility 371 of having a valid packet is if the data is part of a legacy MAC. 373 If the Field Length is valid, i.e., an even multiple of 4 octets, 374 one of the following three cases must be present: 376 First, the Field Length will be less than the remaining data. 377 This means subsequent data must parse as some number of 378 Extension Fields, optionally followed by a legacy MAC. 380 Second, the Field Length will exactly match the remaining data. 382 The third case is where the Field Length is longer than the 383 remaining packet data. In this case, the current parse cannot 384 be a valid extension field, and if the packet is valid, the 385 data must be a legacy MAC. 387 Semantic checking may also be done to validate a potential legacy 388 MAC. A legacy MAC is a four-octet Key Identifier followed by a 389 message digest. The usual message digest is 16 octets long but may 390 be another size, depending on the digest algorithm. In the Reference 391 Implementation and in implementations that follow the guidelines for 392 the values of the Key Identifier, a Key Identifier between 1 and 393 65535, inclusive, is a symmetric key, while a Key Identifier that is 394 > 65535 is an Autokey RFC 5906 [RFC5906], or similar. If the 395 receiving system does not recognize the Key Identifier, the data 396 CANNOT be a valid legacy MAC. If the receiving system recognizes the 397 Key Identifier, then it also has knowledge of the digest algorithm 398 and can make sure the digest payload is the proper length. If this 399 is not the case, then the data CANNOT be a valid legacy MAC. In this 400 case, it MIGHT be a valid extension field. 402 It is trivial to parse the data after the base NTP packet and come up 403 with a list of potential parsings. A local policy choice can specify 404 the precedence of the parsing options in this case. 406 If none of the parsings validate, the packet fails authentication. 407 An implementation has three local policy choices available if LAST-EF 408 is not used and a legacy MAC may be provided. First, the 409 implementation may specify EF-precedence. Second, the implementation 410 may specify legacy-MAC-precedence. Finally, the implementation may 411 specify "best fit" precedence. In this last case, the packet will 412 meet one of the three following criteria: First, none of the parsings 413 will match. Again, this is a case of failed authentication. Second, 414 exactly one parsing will match and that parsing will be accepted. 415 Third, multiple parsings will match, in which case the implementation 416 may choose its behavior. 418 Additionally, most EFs will require a MAC. If there is a 419 syntactically-valid parsing that does not include a MAC but 420 previously scanned EFs require a MAC, then in a multiple-choice 421 parsing scenario where one of the choices does not include a MAC the 422 "no MAC provided" choice SHOULD be eliminated. 424 Note well that this rare situation can be completely avoided by using 425 LAST-EF, or by indicating that no legacy MAC will be used. 427 Finally, in many cases at least one side will know if a MAC is 428 required or not. Client configurations of all types, unicast, 429 broadcast, multicast, and manycast, that state that a key will be 430 used to communicate with a server SHOULD reject packets claiming to 431 be from the server that do not include a MAC. Symmetric associations 432 also are configured with similar knowledge and requirements. 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 saw_mac = 0; // We haven't seen a MAC yet 506 authlen = LEN_PKT_NOMAC; // Length of a base packet 507 leg_mac = rbufp->recv_length - authlen; // # bytes after base 509 while (leg_mac > 0) { // Data after base packet 510 if (leg_mac % 4 != 0 || leg_mac < MIN_MAC_LEN) { 511 return: Bad packet length; 512 } 514 // If ef_ok, this could be an EF or legacy MAC 515 skeyid = ntohl(pkt[authlen / 4]); 516 opcode = skeyid >> 16; 517 len = skeyid & 0xffff; 519 if (ef_ok && GET_EXT_FIELD_TYPE(opcode) == EF_FT_LAST) { 520 if (leg_mac > MAX_MAC_LEN) { 521 return: Too much data after LAST_EF; 522 } 523 // Anything here MUST be a legacy MAC 524 ef_ok = 0; 525 legacy_mac_ok = 1; 526 } else { 527 if (4 == leg_mac && 0 == skeyid) { 528 break; // Likely crypto-NAK 529 } 531 if (legacy_mac_ok && leg_mac <= MAX_MAC_LEN) { 532 int ksize; 534 // If we find a keyid, we know its alg/length 535 ksize = auth_findkeysize(skeyid); 536 if ( ksize != -1 537 && ksize == leg_mac 538 && (it validates)) { 539 saw_mac = 1; 540 break; 541 } 542 // If we got here, it can't be a valid 543 // legacy MAC. It's still a potential EF. 544 } 546 if (!ef_ok) { 547 break; 548 } 550 // At this point, this SHOULD be an EF 552 if ( len % 4 != 0 553 || len < 4 554 || len + authlen > rbufp-> recv_length) { 555 return: Bad length; 556 } 558 switch (GET_EXT_FIELD_TYPE(opcode)) { 559 case EF_FT_AK: // Autokey 560 // extract calling group name for later 561 break; 562 case EF_FT_LAST: // LAST-EF 563 legacy_mac_ok = 1; 564 break; 565 default: 566 legacy_mac_ok = 0; 567 break; 568 } 569 } 571 authlen += len; 572 leg_mac -= len; 573 } 575 if (leg_mac < 0) { 576 return: Malformed packet 577 } 579 Example 2: Another way to handle EF/legacy-MAC parsing 581 4.4. OLD: RFC5905 Section 9.2. - Peer Process Operations 583 ... 585 FXMIT. ... This message includes the normal NTP header data shown in 586 Figure 8, but with a MAC consisting of four octets of zeros. ... 588 4.5. NEW: RFC5905 Section 9.2. - Peer Process Operations 590 ... 592 FXMIT. ... This message includes the normal NTP header data shown in 593 Figure 8, but with a MAC consisting of four octets of zeros. This 594 MAC can be a legacy MAC or a MAC-EF. If it's a MAC-EF, the crypto- 595 NAK MUST be the only MAC in the MAC-EF payload. ... 597 5. Acknowledgements 599 The authors wish to acknowledge the contributions of Sam Weiler, 600 Danny Mayer, and Tal Mizrahi. 602 6. IANA Considerations 604 This memo requests IANA to allocate the following bits in the NTP 605 Extension Field Types table: 607 0x8000: R: Response (0: Request, 1: Response) 609 0x4000: E: Error (0: OK, 1: Error) - Unused, deprecation expected 611 The following table should be the functionally the same as the 612 existing NTP Extension Field Table. 614 +------------+---------------------------------------------+ 615 | Field Type | Meaning | 616 +------------+---------------------------------------------+ 617 | 0x0000 | crypto-NAK (with Field Length of 0) | 618 | 0x0000 | RESERVED: Permanently Unassigned | 619 | 0x0001 | RESERVED: Unassigned | 620 | 0x0002 | Autokey: No-Operation Request | 621 | 0x8002 | Autokey: No-Operation Response | 622 | 0x0102 | Autokey: Association Message Request | 623 | 0x8102 | Autokey: Association Message Response | 624 | 0x0202 | Autokey: Certificate Message Request | 625 | 0x8202 | Autokey: Certificate Message Response | 626 | 0x0302 | Autokey: Cookie Message Request | 627 | 0x8302 | Autokey: Cookie Message Response | 628 | 0x0402 | Autokey: Autokey Message Request | 629 | 0x8402 | Autokey: Autokey Message Response | 630 | 0x0502 | Autokey: Leapseconds Value Message Request | 631 | 0x8502 | Autokey: Leapseconds Value Message Response | 632 | 0x0602 | Autokey: Sign Message Request | 633 | 0x8602 | Autokey: Sign Message Response | 634 | 0x0702 | Autokey: IFF Identity Message Request | 635 | 0x8702 | Autokey: IFF Identity Message Response | 636 | 0x0802 | Autokey: GQ Identity Message Request | 637 | 0x8802 | Autokey: GQ Identity Message Response | 638 | 0x0902 | Autokey: MV Identity Message Request | 639 | 0x8902 | Autokey: MV Identity Message Response | 640 | 0x0005 | Checksum Complement | 641 | 0x1005 | Checksum Complement | 642 +------------+---------------------------------------------+ 644 Current Extension Fields 646 7. Security Considerations 648 Additional information TBD 650 8. Normative References 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, 654 DOI 10.17487/RFC2119, March 1997, 655 . 657 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 658 "Network Time Protocol Version 4: Protocol and Algorithms 659 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 660 . 662 [RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol 663 Version 4: Autokey Specification", RFC 5906, 664 DOI 10.17487/RFC5906, June 2010, 665 . 667 [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time 668 Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 669 2016, . 671 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 672 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, 673 March 2016, . 675 Authors' Addresses 677 Harlan Stenn 678 Network Time Foundation 679 P.O. Box 918 680 Talent, OR 97540 681 US 683 Email: stenn@nwtime.org 685 David L. Mills 686 Network Time Foundation 687 P.O. Box 918 688 Talent, OR 97540 689 US 691 Email: mills@udel.edu