idnits 2.17.1 draft-mizrahi-ntp-extension-field-03.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 draft header indicates that this document updates RFC5905, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5905, updated by this document, for RFC5378 checks: 2005-07-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2, 2014) is 3761 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NTP Working Group T. Mizrahi 2 Internet Draft Marvell 3 Intended status: Standards Track D. Mayer 4 Updates: 5905 Network Time Foundation 5 Expires: July 2014 January 2, 2014 7 Using NTP Extension Fields without Authentication 8 draft-mizrahi-ntp-extension-field-03.txt 10 Abstract 12 The Network Time Protocol Version 4 (NTPv4) defines the optional 13 usage of extension fields. An extension field is an optional field 14 that resides at the end of the NTP header, and can be used to add 15 optional capabilities or additional information that is not conveyed 16 in the standard NTP header. The current definition of extension 17 fields in NTPv4 is somewhat ambiguous regarding the connection 18 between extension fields and the presence of a Message Authentication 19 Code (MAC). This draft clarifies the usage of extension fields in the 20 presence and in the absence of a MAC, while maintaining 21 interoperability with existing implementations. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 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 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on July 2, 2014. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction ................................................. 3 64 2. Conventions Used in this Document ............................ 4 65 2.1. Terminology ............................................. 4 66 2.2. Terms & Abbreviations ................................... 4 67 3. NTP Extension Fields with and without a MAC - Clarifications . 4 68 3.1. Extension Field Format .................................. 4 69 3.2. Extension Fields in the Absence of a MAC ................ 4 70 3.3. Unknown Extension Fields ................................ 5 71 3.4. Interoperability with Current Implementations ........... 5 72 4. NTP Extension Field Usage with and without a MAC - Extensions 5 73 4.1. Extension Fields in the Presence of a MAC ............... 5 74 4.2. Extension Fields in the Absence of a MAC ................ 5 75 4.3. Multiple Extension fields in an NTP packet .............. 6 76 4.4. MAC in the absence of an Extension field ................ 6 77 5. Security Considerations ...................................... 6 78 6. IANA Considerations .......................................... 6 79 7. Acknowledgments .............................................. 6 80 8. References ................................................... 6 81 8.1. Normative References .................................... 6 82 8.2. Informative References .................................. 7 83 Appendix A. Requirements from NTPv4 and Autokey ................. 7 84 A.1. NTP Extension Field for Future Extensions ............... 7 85 A.2. NTP Extension Field in the Presence of a MAC ............ 7 86 A.3. The NTP Extension Field Format .......................... 7 87 A.4. NTP Extension Field in Autokey .......................... 8 89 1. Introduction 91 The NTP header format consists of a set of fixed fields that may be 92 followed by some optional fields. Two types of optional fields are 93 defined, Message Authentication Codes (MAC), and extension fields. 95 If a MAC is used, it resides at the end of the packet. This field can 96 be either 24 octets long, 20 octets long, or a 4-octet crypto-NAK. 98 NTP extension fields were defined in [RFC5905] as a generic mechanism 99 that allows to add future extensions and features without modifying 100 the NTP header format. 102 The only currently defined extension field is the one used by the 103 AutoKey protocol [RFC5906]. 105 The NTP specification is somewhat ambiguous with regards to the 106 connection between using extension fields and the presence of a MAC. 108 o The definition of the NTP extension field implies that it was 109 intended to be a generic mechanism that can be used for various 110 future features of the protocol (see Section A.1.). 112 o On the other hand, the NTP extension field description in 113 [RFC5905] states that a MAC is always present when an extension 114 field is present (see Section A.2.). 116 The last two quotes seem to be in contradiction; since the extension 117 field was defined as a generic future-compatible building block, it 118 seems unlikely to bind it to a specific feature in the protocol. 120 Moreover, the extension field parsing rules presented in [RFC5906] 121 imply that an extension field can be present without a MAC, provided 122 that the extension field is at least 28 Octets long. 124 This document attempts to resolve the ambiguity with regards to the 125 connection between NTP extension fields and MACs, updating 126 Section 7.5 of [RFC5905], and describes the usage of extension fields 127 in the absence of a MAC in a way that is interoperable with current 128 implementations. 130 2. Conventions Used in this Document 132 2.1. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [KEYWORDS]. 138 2.2. Terms & Abbreviations 140 NTPv4 Network Time Protocol Version 4 142 MAC Message Authentication Code 144 3. NTP Extension Fields with and without a MAC - Clarifications 146 This section clarifies the usage of extension fields in the absence 147 of a MAC, in accordance with the definitions in [RFC5905] and 148 [RFC5906]. Section 4. defines a more generic and flexible usage of 149 extension fields. 151 3.1. Extension Field Format 153 The NTP extension field is defined in Section 7.5 of [RFC5905]. The 154 extension field format is quoted here in Section A.3. 156 The minimal length of an extension field, as defined in Section 7.5 157 of [RFC5905], is 16 octets. 159 3.2. Extension Fields in the Absence of a MAC 161 Extension fields can be used when a MAC is not present in the NTP 162 packet. In this case, the extension fields must comply with the 163 parsing rules in Section A.4. Specifically: 165 o If the packet includes a single extension field, the length of the 166 extension field MUST be at least 7 words, i.e., at least 28 167 octets. 169 o If the packet includes more than one extension field, the length 170 of the last extension field MUST be at least 28 octets. The length 171 of the other extension fields in this case MUST be at least 16 172 octets each, as defined in [RFC5905]. 174 A host that supports NTP extension fields MUST parse NTP extension 175 fields as described in Section A.4. 177 3.3. Unknown Extension Fields 179 If an extension field is unknown to the receiving server the server 180 should ignore the extension field and may optionally drop the packet 181 altogether if policy requires it. Note that in the presence of an 182 unknown extension field any MAC that may be present may be 183 misinterpreted as an unknown extension though in this case the 184 apparent extension length will be totally inconsistent with the total 185 length of the rest of the packet. 187 3.4. Interoperability with Current Implementations 189 The behavior described in Section 3.2. is compliant to [RFC5906], and 190 thus should be compatible with existing implementations that support 191 NTP extension fields. 193 4. NTP Extension Field Usage with and without a MAC - Extensions 195 This section updates [RFC5905] and [RFC5906] with respect to the 196 usage of extension fields, allowing a more flexible and unambiguous 197 usage. 199 4.1. Extension Fields in the Presence of a MAC 201 The usage of extension fields in the presence of a MAC is specified 202 in [RFC5905] and in [RFC5906]. The requirement for a MAC MUST be 203 specified by the specification for the extension field and the 204 specification MUST include both the algorithm to be used to create 205 the MAC and the length of the MAC thus created. An extension field 206 may allow for more than one algorithm to be used in which case the 207 information about which one was used MUST be included in the 208 extension field itself. 210 4.2. Extension Fields in the Absence of a MAC 212 Extension fields can be used when a MAC is not present in the NTP 213 packet. In this case, the extension fields must comply with the 214 following: 216 o If the packet includes a single extension field, the length of the 217 extension field MUST be at least 16 octets. The extension length 218 is specified in the length field of the extension and is the 219 number of octets in the extension field. 221 o If the packet includes more than one extension field, the length 222 of the last extension field MUST be at least 28 octets. The length 223 of the other extension fields in this case MUST be at least 16 224 octets each, as defined in [RFC5905]. 226 4.3. Multiple Extension fields in an NTP packet 228 If there are multiple extension fields that require a MAC they MUST 229 all require use of the same algorithm and MAC length. Extension 230 fields that do not require a MAC can be included with extension 231 fields that do require a MAC. 233 4.4. MAC in the absence of an Extension field 235 A MAC must not be any longer than 24 octets if there is no extension 236 field present unless through a previous exchange of packets with an 237 extension field which defines the size and algorithm of the MAC 238 transmitted in the packet and is agreed upon by both client and 239 server. 241 5. Security Considerations 243 The security considerations of the network time protocol are 244 discussed in [RFC5905]. This document clarifies some ambiguity with 245 regards to the usage of the NTP extension field, and thus the 246 behavior described in this document does not introduce new security 247 considerations. 249 6. IANA Considerations 251 There are no new IANA considerations implied by this document. 253 7. Acknowledgments 255 The authors thank Dave Mills for his insightful comments. 257 This document was prepared using 2-Word-v2.0.template.dot. 259 8. References 261 8.1. Normative References 263 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, March 1997. 266 [RFC5905] Mills, D., Martin, J., Burbank, J., Kasch, W., 267 "Network Time Protocol Version 4: Protocol and 268 Algorithms Specification", RFC 5905, June 2010. 270 8.2. Informative References 272 [RFC5906] Haberman, B., Mills, D., "Network Time Protocol 273 Version 4: Autokey Specification", RFC 5906, June 274 2010. 276 Appendix A. Requirements from NTPv4 and Autokey 278 A.1. NTP Extension Field for Future Extensions 280 The following paragraph is quoted from Section 16 of [RFC5905]. 282 This document introduces NTP extension fields allowing for the 283 development of future extensions to the protocol, where a particular 284 extension is to be identified by the Field Type sub-field within the 285 extension field. 287 A.2. NTP Extension Field in the Presence of a MAC 289 The following paragraph is quoted from Section 7.5 of [RFC5905]. 291 In NTPv4, one or more extension fields can be inserted after the 292 header and before the MAC, which is always present when an extension 293 field is present. 295 A.3. The NTP Extension Field Format 297 Figure 1 specifies the NTP extension field format, and is quoted from 298 [RFC5905]. For further details refer to [RFC5905]. 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Field Type | Length | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 . . 306 . Value . 307 . . 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Padding (as needed) | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 1 The NTP Extension Field Format 313 A.4. NTP Extension Field in Autokey 315 The following paragraph is quoted from Section 10 of [RFC5906]. 317 One or more extension fields follow the NTP packet header and the 318 last followed by the MAC. The extension field parser initializes a 319 pointer to the first octet beyond the NTP packet header and 320 calculates the number of octets remaining to the end of the packet If 321 the remaining length is 20 (128-bit digest plus 4-octet key ID) or 22 322 (160-bit digest plus 4-octet key ID), the remaining data are the MAC 323 and parsing is complete. If the remaining length is greater than 22, 324 an extension field is present. If the remaining length is less than 325 8 or not a multiple of 4, a format error has occurred and the packet 326 is discarded; otherwise, the parser increments the pointer by the 327 extension field length and then uses the same rules as above to 328 determine whether a MAC is present or another extension field. 330 Authors' Addresses 332 Tal Mizrahi 333 Marvell 334 6 Hamada St. 335 Yokneam, 20692 Israel 337 Email: talmi@marvell.com 338 Danny Mayer 339 Network Time Foundation 340 PO Box 918 341 Talent OR 97540 343 Email: mayer@ntp.org