Clarifying Processing Expectations for Packets with keyid 0 in the Network Time Protocol Version 4

A Network Time Protocol Version 4 (NTPv4) packet consists of 48 octets of required fields, followed by zero or more extension fields, possibly followed by a keyid field and a MAC. RFC 5905 (section 7.5) specifies that the MAC "is always present when an extension field is present". RFC 7822 relaxes this requirement by permitting the keyid and MAC fields to be omitted, provided that the last extension field has a length of at least 28 octets. This minimum length requirement is necessary to prevent syntactic ambiguity. Neither RFC 5905 nor RFC 7822 provides any clear guidance on what to do when it is necessary to construct a packet which contains at least one extension field but none with a length of 28 octets or more, and no key has been agreed which could be used to compute a valid MAC. This memo resolves this situation by codifying the convention, already observed by the RFC 5905 reference implementation and other existing implementations, that a keyid field of zero is a dummy value indicating that the MAC field is to be ignored.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

In an NTPv4 packet, a keyid field with a value of zero denotes that the keyid field and the MAC field which follows it have been inserted solely to satisfy a syntactic requirement for the presence of a MAC field. Implementations which receive such a packet MUST process it in the same manner that they would if the keyid and MAC fields were omitted (supposing this were syntactically possible). In particular, implementations MUST NOT attempt to verify the MAC, and MUST NOT respond to the sender with a crypto-NAK.

The security considerations of time protocols in general are discussed in RFC 7384, and the security considerations of NTP are discussed in RFC 5905. Legacy MAC fields containing dummy values do not contribute any information regarding the authenticity or inauthenticity of an NTP packet. NTP packets with dummy MAC fields MAY prove their authenticity by other mechanisms, e.g. . See the previously-cited RFC 7384 and RFC 5905 for discussion of the security considerations surrounding accepting unauthenticated time packets. Whenever two cooperating principals have conflicting processing expectations for a similar message, "confused deputy" vulnerabilities may arise . Without speculating as to any specifics as to how this class of vulnerability could arise from this instance of confusion, by making the processing expectations clear we preclude the possibility of it doing so.

None.