idnits 2.17.1 draft-dfranke-ntp-keyid0-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 22, 2016) is 2864 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Time Protocol Working Group D. Franke 3 Internet-Draft Akamai 4 Intended status: Standards Track June 22, 2016 5 Expires: December 24, 2016 7 Clarifying Processing Expectations for Packets with keyid 0 in the 8 Network Time Protocol Version 4 9 draft-dfranke-ntp-keyid0-00 11 Abstract 13 This memo clarifies that when a Network Time Protocol Version 4 14 packet has a keyid field of zero, the MAC is present solely to 15 satisfy certain syntactic constraints, and is to be ignored. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 24, 2016. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 A Network Time Protocol Version 4 (NTPv4) packet consists of 48 52 octets of required fields, followed by zero or more extension fields, 53 possibly followed by a keyid field and a MAC. RFC 5905 [RFC5905] 54 (section 7.5) specifies that the MAC "is always present when an 55 extension field is present". RFC 7822 [RFC7822] relaxes this 56 requirement by permitting the keyid and MAC fields to be omitted, 57 provided that the last extension field has a length of at least 28 58 octets. This minimum length requirement is necessary to prevent 59 syntactic ambiguity. 61 Neither RFC 5905 nor RFC 7822 provides any clear guidance on what to 62 do when it is necessary to construct a packet which contains at least 63 one extension field but none with a length of 28 octets or more, and 64 no key has been agreed which could be used to compute a valid MAC. 65 This memo resolves this situation by codifying the convention, 66 already observed by the RFC 5905 reference implementation and other 67 existing implementations, that a keyid field of zero is a dummy value 68 indicating that the MAC field is to be ignored. 70 2. Requirements Terminology 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [RFC2119]. 76 3. Processing Expectations 78 In an NTPv4 packet, a keyid field with a value of zero denotes that 79 the keyid field and the MAC field which follows it have been inserted 80 solely to satisfy a syntactic requirement for the presence of a MAC 81 field. Implementations which receive such a packet MUST process it 82 in the same manner that they would if the keyid and MAC fields were 83 omitted (supposing this were syntactically possible). In particular, 84 implementations MUST NOT attempt to verify the MAC, and MUST NOT 85 respond to the sender with a crypto-NAK. 87 4. Security Considerations 89 The security considerations of time protocols in general are 90 discussed in RFC 7384 [RFC7384], and the security considerations of 91 NTP are discussed in RFC 5905 [RFC5905]. 93 Legacy MAC fields containing dummy values do not contribute any 94 information regarding the authenticity or inauthenticity of an NTP 95 packet. NTP packets with dummy MAC fields MAY prove their 96 authenticity by other mechanisms, e.g. 98 [draft-mayer-ntp-mac-extension-field]. See the previously-cited RFC 99 7384 and RFC 5905 for discussion of the security considerations 100 surrounding accepting unauthenticated time packets. 102 Whenever two cooperating principals have conflicting processing 103 expectations for a similar message, "confused deputy" vulnerabilities 104 may arise [confused-deputy]. Without speculating as to any specifics 105 as to how this class of vulnerability could arise from this instance 106 of confusion, by making the processing expectations clear we preclude 107 the possibility of it doing so. 109 5. IANA Considerations 111 None. 113 6. References 115 6.1. Normative References 117 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 118 Requirement Levels", BCP 14, RFC 2119, 119 DOI 10.17487/RFC2119, March 1997, 120 . 122 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 123 "Network Time Protocol Version 4: Protocol and Algorithms 124 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 125 . 127 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 128 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, 129 March 2016, . 131 6.2. Informative References 133 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 134 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 135 October 2014, . 137 [confused-deputy] 138 Hardy, N., "The Confused Deputy: (or why capabilities 139 might have been invented)", ACM SIGOPS Operating Systems 140 Review Volume 22 Issue 4, pp. 36-38, October 1988. 142 [draft-mayer-ntp-mac-extension-field] 143 Mayer, D. and H. Stenn, "The Network Time Protocol Version 144 4 (NTPv4) MAC Extension Field", March 2016, 145 . 148 Work in progress. 150 Author's Address 152 Daniel Fox Franke 153 Akamai Technologies, Inc. 154 150 Broadway 155 Cambridge, MA 02142 156 United States 158 Email: dafranke@akamai.com 159 URI: https://www.dfranke.us