idnits 2.17.1 draft-stenn-ntp-extension-fields-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5905], [Err3627]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document updates RFC5905, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 13, 2016) is 2719 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Err3627' is mentioned on line 97, but not defined ** Downref: Normative reference to an Informational RFC: RFC 5906 ** Downref: Normative reference to an Experimental RFC: RFC 7821 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Mizrahi 3 Internet-Draft Marvell 4 Intended status: Standards Track D. Mayer 5 Expires: May 17, 2017 H. Stenn 6 Network Time Foundation 7 November 13, 2016 9 Network Time Protocol Version 4 (NTPv4) Extension Fields 10 draft-stenn-ntp-extension-fields-00 12 Abstract 14 Network Time Protocol version 4 (NTPv4) defines the optional usage of 15 extension fields. An extension field, as defined in RFC 5905 16 [RFC5905], resides after the end of the NTP header, and supplies 17 optional capabilities or information that is not conveyed in the 18 standard NTP header. This document updates RFC 5905 [RFC5905] by 19 clarifying some points regarding NTP extension fields and their usage 20 with legacy Message Authentication Codes (MACs). 22 With the adoption of this update, the authors recommend rescinding 23 [Err3627]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 17, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 63 3. NTP Extension Fields - RFC 5905 Update . . . . . . . . . . . 3 64 3.1. OLD: 7.5 NTP Extension Field Format . . . . . . . . . . . 3 65 3.2. NEW: 7.5 NTP Extension Field Format . . . . . . . . . . . 4 66 3.3. NEW: 7.5.1 Extension Fields and MACs . . . . . . . . . . 6 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 6. Normative References . . . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 The NTP header format consists of a set of fixed fields that may be 75 followed by optional fields. Two types of optional fields are 76 defined: extension fields as defined in Section 7.5 of RFC 5905 77 [RFC5905], and legacy Message Authentication Codes (legacy MACs). 79 If a legacy MAC is used, it resides at the end of the packet. This 80 field can be either a 4-octet crypto-NAK or data that is usually 20 81 or 24 octets long. 83 NTP extension fields are defined in RFC 5905 [RFC5905] as a generic 84 mechanism that allows the addition of future extensions and features 85 without modifying the NTP header format (Section 16 of RFC 5905 86 [RFC5905]). 88 Section 7.5 of RFC 5905 [RFC5905] clearly states that "one or more 89 extension fields can be inserted after the header and before the MAC, 90 which is always present when an extension field is present." 91 However, the experimental Checksum Complement RFC 7821 [RFC7821] 92 cannot be used if the NTP packet contains a MAC. 94 To allow for extension fields that do not require a MAC, changes to 95 the NTPv4 specification must be made. [Err3627] was an attempt to 96 clarify the rules around MACs, but with the adoption of this proposal 97 the authors recommend rescinding [Err3627]. 99 This document better specifies and clarifies both Extention Fields 100 and the requirements and parsing of a legacy MAC, with changes to 101 address errors found after the publication of RFC 5905 [RFC5905] with 102 respect to extension fields. Specifically, this document updates 103 Section 7.5 of RFC 5905 [RFC5905], clarifying the relationship 104 between extension fields and MACs, and defines the behavior of a host 105 that receives an unknown extension field. 107 2. Conventions Used in This Document 109 2.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 2.2. Terms and Abbreviations 117 MAC - Message Authentication Code 119 NTPv4 - Network Time Protocol, Version 4 RFC 5905 [RFC5905] 121 3. NTP Extension Fields - RFC 5905 Update 123 This document updates Section 7.5 of RFC 5905 [RFC5905] as follows: 125 3.1. OLD: 7.5 NTP Extension Field Format 127 In NTPv4, one or more extension fields can be inserted after the 128 header and before the MAC, which is always present when an extension 129 field is present. Other than defining the field format, this 130 document makes no use of the field contents. An extension field 131 contains a request or response message in the format shown in 132 Figure 14. 134 0 1 2 3 135 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 136 +---------------+---------------+-------------------------------+ 137 | Field Type | Field Length | 138 +-------------------------------+-------------------------------+ 139 . . 140 . Value . 141 . . 142 +-------------------------------+-------------------------------+ 143 | Padding (as needed) | 144 +---------------------------------------------------------------+ 146 Figure 14: Extension Field Format 148 All extension fields are zero-padded to a word (four octets) 149 boundary. The Field Type field is specific to the defined function 150 and is not elaborated here. While the minimum field length 151 containing required fields is four words (16 octets), a maximum field 152 length remains to be established. 154 The Length field is a 16-bit unsigned integer that indicates the 155 length of the entire extension field in octets, including the Padding 156 field. 158 3.2. NEW: 7.5 NTP Extension Field Format 160 In NTPv4, one or more extension fields can be inserted after the 161 header and before the possibly optional legacy MAC. A MAC SHOULD be 162 present when an extension field is present. A MAC is always present 163 in some form when NTP packets are authenticated. This MAC can be 164 either a legacy MAC or a MAC-EF. Other than defining the field 165 format, this document makes no use of the field contents. An 166 extension field contains a request or response message in the format 167 shown in Figure 14. 169 0 1 2 3 170 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 171 +---------------+---------------+-------------------------------+ 172 | Field Type | Field Length | 173 +-------------------------------+-------------------------------+ 174 . . 175 . Value . 176 . . 177 +-------------------------------+-------------------------------+ 178 | Padding (as needed) | 179 +---------------------------------------------------------------+ 181 Figure 14: Extension Field Format 183 All extension fields are zero-padded to a word (four octets) 184 boundary. The Field Type field is specific to the defined function 185 and is not elaborated here. While the minimum field length 186 containing required fields is four words (16 octets), a maximum field 187 length remains to be established. 189 The Length field is a 16-bit unsigned integer that indicates the 190 length of the entire extension field in octets, including the Padding 191 field. 193 The Field Type contains the following sub-elements: 195 0 1 2 3 196 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 197 +---------------+---------------+-------------------------------+ 198 |R|E|O|I| Code Field Type | (Field Length) | 199 +-------------------------------+-------------------------------+ 201 Field Type Format 203 Where: 205 R: 0 for a "Query", 1 for a "Response" 207 E: 0 for "OK", 1 for an "Error" 209 O: 0 for "MAC Required", 1 for "MAC Optional" 211 I: 0 for "MAC Not Included", 1 for "MAC Included" 213 The Code subtype is currently only used by RFC 5906, Autokey 214 [RFC5906]. 216 The Field Type, Value, and Padding fields are specific to the defined 217 function and are not elaborated here; the Field Type value is defined 218 in an IANA registry, and the Length, Value, and Padding values are 219 defined by the document referred to by the registry. If a host 220 receives an extension field with an unknown Field Type, the host 221 SHOULD ignore the extension field and MAY drop the packet altogether 222 if policy requires it. 224 While the minimum field length containing required fields is four 225 words (16 octets), the maximum field length MUST NOT be longer than 226 65532 octets due to the maximum size of the data represented by the 227 Length field, and SHOULD be small enough that the size of the NTP 228 packet received by the client does not exceed the smallest MTU 229 between the sender and the recipient. 231 The Length field is a 16-bit unsigned integer that indicates the 232 length of the entire extension field in octets, including any Padding 233 . 235 3.3. NEW: 7.5.1 Extension Fields and MACs 237 With the inclusion of additional Extension Fields, there is now a 238 possibility of an ambiguous parsing of a legacy MAC. If an 239 implementation offers even a modicum of care, there will be no 240 ambiguity when parsing an NTP packet that contains a legacy MAC. 242 If an implementation uses the LAST-EF extension field, the presence 243 of this field means "I am the last EF in this NTP Packet. Any 244 subsequent packet data MUST be a legacy MAC." In this case, there is 245 no parsing ambiguity. 247 If a system sends its MAC as a MAC-EF and does not send a legacy MAC, 248 there is no parsing ambiguity. 250 The only time there is a potential for a parsing ambiguity is when a 251 legacy MAC is provided and neither of the previous two cases are 252 present. Even in this case, there is minimal risk. 254 An Extension Field contains a 2-octet Field Type, a 2-octet Field 255 Length, and any payload (data and/or padding). If the NTP Packet 256 parsing is at a point where it is evaluating data after the base 257 packet, one of the following situations exists: 259 If the Field Length is not an even multiple of 4, we are not 260 looking at an extension field. In this case, the only possibility 261 of having a valid packet is if the data is part of a legacy MAC. 263 If the Field Length is valid, i.e., an even multiple of 4 octets, 264 one of the following three cases must be present: 266 First, the Field Length will be less than the remaining data. 267 This means subsequent data must parse as some number of 268 Extension Fields, optionally follwed by a legacy MAC. 270 Second, the Field Length will exactly match the remaining data. 272 The third case is where the Field Length is longer than the 273 remaining packet data. In this case, the current parse cannot 274 be a valid extension field. 276 Semantic checking may also be done to validate a potential legacy 277 MAC. A legacy MAC is a four-octet Key Identifier followed by a 278 message digest. The usual message digest is 16 octets long but may 279 be another size, depending on the digest algorithm. In the Reference 280 Implementation, a Key Identifier between 1 and 65535, inclusive, is a 281 symmetric key, while a Key Identifier that is > 65535 is an Autokey 282 RFC 5905 [RFC5905], or similar. If the receiving system does not 283 recognize the Key Identifier, the data CANNOT be a valid legacy MAC. 284 If the receiving system recognizes the Key Identifier, then it also 285 has knowledge of the digest algorithm and can make sure the digest 286 payload is the proper length. If this is not the case, then the data 287 CANNOT be a valid legacy MAC. 289 It is trivial to parse the data after the base NTP packet and come up 290 with a list of potential parsings. A local policy choice can specify 291 the precedence of the parsing options in this case. 293 If none of the parsings validate, the packet fails authentication. 294 An implementation has three local policy choices available if LAST-EF 295 is not used and a legacy MAC may be provided. First, the 296 implementation may specify EF-precedence. Second, the implementation 297 may specify legacy-MAC-precedence. Finally, the implementation may 298 specify "best fit" precedence. In this last case, the packet will 299 meet one of the three following criteria: First, none of the parsings 300 will match. Again, this is a case of failed authentication. Second, 301 exactly one parsing will match and that parsing will be accepted. 302 Third, multiple parsings will match, in which case the implementation 303 may choose its behavior. 305 Additionally, most EFs will require a MAC. If there is a 306 syntactically-valid parsing that does not include a MAC but 307 previously scanned EFs require a MAC, then in a multiple-choice 308 parsing scenario where one of the choices does not include a MAC the 309 "no MAC provided" choice SHOULD be eliminated. 311 Note well that this rare situation can be completely avoided by using 312 LAST-EF, or by indicating that no legacy MAC will be used. 314 4. IANA Considerations 316 This memo requests IANA to allocate NTP Extension Field Types 0x0007 317 (I-Do), 0x2007 (I-Do, MAC OPTIONAL), 0x8007 (I-Do Response), and 318 0xA007 (I-Do Response, MAC OPTIONAL)for this proposal. 320 5. Security Considerations 322 Additional information TBD 324 6. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 332 "Network Time Protocol Version 4: Protocol and Algorithms 333 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 334 . 336 [RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol 337 Version 4: Autokey Specification", RFC 5906, 338 DOI 10.17487/RFC5906, June 2010, 339 . 341 [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time 342 Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 343 2016, . 345 Authors' Addresses 347 Tal Mizrahi 348 Marvell 349 6 Hamda St. 350 Yokneam, 20692 351 Israel 353 Email: talmi@marvell.com 355 Danny Mayer 356 Network Time Foundation 357 P.O. Box 918 358 Talent, OR 97540 359 US 361 Email: mayer@ntp.org 363 Harlan Stenn 364 Network Time Foundation 365 P.O. Box 918 366 Talent, OR 97540 367 US 369 Email: stenn@nwtime.org