Clarifying Processing Expectations for Packets with keyid 0 in the Network Time Protocol Version 4
draft-dfranke-ntp-keyid0-00

Abstract

This memo clarifies that when a Network Time Protocol Version 4 packet has a keyid field of zero, the MAC is present solely to satisfy certain syntactic constraints, and is to be ignored.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 24, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

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 [RFC5905] (section 7.5) specifies that the MAC "is always present when an extension field is present". RFC 7822 [RFC7822] 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.

2. Requirements Terminology

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 [RFC2119].

3. Processing Expectations

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.

4. Security Considerations

The security considerations of time protocols in general are discussed in RFC 7384 [RFC7384], and the security considerations of NTP are discussed in RFC 5905 [RFC5905].

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. [draft-mayer-ntp-mac-extension-field]. 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 [confused-deputy]. 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.

5. IANA Considerations

None.

6. References

6.1. Normative References

6.2. Informative References

Author's Address

Table of Contents

• 1. Introduction
• 2. Requirements Terminology
• 3. Processing Expectations
• 4. Security Considerations
• 5. IANA Considerations
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Author's Address