| Internet Engineering Task Force | T. Mizrahi |
| Internet-Draft | Marvell |
| Intended status: Standards Track | D. Mayer |
| Expires: April 2, 2018 | H. Stenn |
| Network Time Foundation | |
| September 29, 2017 |
Network Time Protocol Version 4 (NTPv4) Extension Fields
draft-stenn-ntp-extension-fields-02
Network Time Protocol version 4 (NTPv4) defines the optional usage of extension fields. An extension field, as defined in RFC 5905, resides after the end of the NTP header, and supplies optional capabilities or information that is not conveyed in the standard NTP header. This document updates RFC 5905 by clarifying some points regarding NTP extension fields and their usage with legacy Message Authentication Codes (MACs).
With the adoption of this update, the authors recommend rescinding [Err3627].
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 https://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 April 2, 2018.
Copyright (c) 2017 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 (https://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.
The NTP header format consists of a set of fixed fields that may be followed by optional fields. Two types of optional fields are defined: extension fields as defined in Section 7.5 of RFC 5905, and legacy Message Authentication Codes (legacy MACs).
If a legacy MAC is used, it resides at the end of the packet. This field can be either a 4-octet crypto-NAK or data that is usually 20 or 24 octets long.
Additional information about the content of a MAC is specifieded in RFC 5906, but since that RFC is Informational an implementor that was not planning to provide Autokey would likely never read that document. The result of this would be interoperability problems, at least. To address this problem, this proposal also includes copying and clarifying some of the content of RFC 5906 and putting it into RFC 5905. Because there is a reasonable chance RFC 5906 will be deprecated, this document does not propose changes to RFC 5906.
NTP extension fields are defined in RFC 5905 as a generic mechanism that allows the addition of future extensions and features without modifying the NTP header format (Section 16 of RFC 5905).
Section 7.5 of RFC 5905 clearly states that "one or more extension fields can be inserted after the header and before the MAC, which is always present when an extension field is present." However, the experimental Checksum Complement RFC 7821 cannot be used if the NTP packet contains a MAC.
To allow for extension fields that do not require a MAC, changes to the NTPv4 specification must be made. [Err3627] was an attempt to clarify the rules around MACs, but with the adoption of this proposal the authors recommend rescinding [Err3627].
This document better specifies and clarifies both Extention Fields and the requirements and parsing of a legacy MAC, with changes to address errors found after the publication of RFC 5905 with respect to extension fields. Specifically, this document updates Section 7.5 of RFC 5905, clarifying the relationship between extension fields and MACs, and defines the behavior of a host that receives an unknown extension field.
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.
MAC - Message Authentication Code
NTPv4 - Network Time Protocol, Version 4 RFC 5905
This document copies and updates some information in RFC 5906 and puts it in to RFC 5905, as follows:
This section describes some of the cryptography aspects of Autokey. The third paragraph describes the use of 128- and 160-bit message digests. The enumeration of 128- and 160-bit message digests is not meant to be limiting - other message digest lengths MAY be implemented. This paragraph also describes some of the recommended semantic ranges of the key ID. This information belongs in RFC 5905. The key ID ranges are particularly significant because they provide addtional disambiguation protection when deciding if the next data portion is either a legacy MAC or an Extension Field.
This section describes the Extension Field format, including initial flag bits, a Code field, and 8-bit Field Type, and the 16-bit Length. This proposal expands and clarifies this information and puts it into RFC 5905.
This section says "The reference implementation discards any packet with a field length of more than 1024 characters." but this is no longer true.
This section describes the crypto-NAK, which should be described in RFC 5905.
This section lists the Autokey-related Extension Field Types, including Flag Bits, Codes, and Field Types, which should be described in RFC 5905, or perhaps in some other document.
This document updates Section 7.5 of RFC 5905 as follows:
In NTPv4, one or more extension fields can be inserted after the header and before the MAC, which is always present when an extension field is present. Other than defining the field format, this document makes no use of the field contents. An extension field contains a request or response message in the format shown in Figure 14.
0 1 2 3 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 +---------------+---------------+-------------------------------+ | Field Type | Field Length | +-------------------------------+-------------------------------+ . . . Value . . . +-------------------------------+-------------------------------+ | Padding (as needed) | +---------------------------------------------------------------+
Figure 14: Extension Field Format
All extension fields are zero-padded to a word (four octets) boundary. The Field Type field is specific to the defined function and is not elaborated here. While the minimum field length containing required fields is four words (16 octets), a maximum field length remains to be established.
The Length field is a 16-bit unsigned integer that indicates the length of the entire extension field in octets, including the Padding field.
In NTPv4, one or more extension fields can be inserted after the header and before the possibly optional legacy MAC. A MAC SHOULD be present when an extension field is present. A MAC is always present in some form when NTP packets are authenticated. This MAC SHOULD be either a legacy MAC or a MAC-EF. It MAY be both. Other than defining the field format, this document makes no use of the field contents. An extension field contains a request or response message in the format shown in Figure 14.
0 1 2 3 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 +---------------+---------------+-------------------------------+ | Field Type | Field Length | +-------------------------------+-------------------------------+ . . . Value . . . +-------------------------------+-------------------------------+ | Padding (as needed) | +---------------------------------------------------------------+
Figure 14: Extension Field Format
All extension fields are zero-padded to a word (four octet) boundary. The Field Type is specific to the defined function and detailed information about the Field Type is not elaborated here. While the minimum extension field is a 32-bit word (4 octets), the minimum length of an extension field is usually four 32-bit words (16 octets), and while a maximum extension field size MUST be 65532 octets or less, an NTP packet SHOULD NOT exceed the network MTU.
The Length field is a 16-bit unsigned integer that indicates the length of the entire extension field in octets, including any Padding octets. The bottom two bits of the Field Length SHOULD be zero.
The Field Type contains the following sub-elements:
0 1 2 3 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 +---------------+---------------+-------------------------------+ |R|E|O|I|EF Code EF Type | (Field Length) | +-------------------------------+-------------------------------+
Field Type Format
Where the following Field Type flags are defined:
[The EF Code subtype is currently only used by RFC 5906, Autokey. The EF Code subtype is expected to be used by the NTS Extension Field, and the Extended Information Extension Field, at least.]
The Field Type, Value, and Padding fields are specific to the defined function and are not elaborated here; appropriate Field Type flags, the EF Code, and EF Type values are defined in an IANA registry, and the Length, Value, and Padding values are defined by the document referred to by the registry. If a host receives an extension field with an unknown Field Type, the host SHOULD ignore the extension field and MAY drop the packet altogether if policy requires it.
The Length field is a 16-bit unsigned integer that indicates the length of the entire extension field in octets, including any Padding.
While the minimum field length containing required fields is four words (16 octets), the maximum field length MUST NOT be longer than 65532 octets due to the maximum size of the data represented by the Length field, and SHOULD be small enough that the size of the NTP packet received by the client does not exceed the smallest MTU between the sender and the recipient. The bottom two bits of the Field Length SHOULD be zero.
With the inclusion of additional Extension Fields, there is now a possibility of an ambiguous parsing in the presence of a legacy MAC. If an implementation offers even a modicum of care, there will be no ambiguity when parsing an NTP packet that contains a legacy MAC from an existing implementation.
The first protection from this ambiguity comes from the fact that current conforming implementations only support the Autokey EF, which uses EF Type 2 and a legacy MAC. While the Experimental UDP Checksum Complement specified by RFC 7821 uses EF Type 5, it specifically prohibits the use of a MAC, and the 0x2000 bit in its assigned EF type of 0x2005 specifies that a MAC is optional when this EF is provided.
[As a side note, the requirement in RFC 7821 that the UDP Checksum Complement EF must have a 28 octet length is demonstrably not needed if this proposal is accepted. It only needs 8 octets: 4 octets of EF header, 2 octets of MBZ padding, and 2 octets of Checksum Complement.]
If an implementation uses the LAST-EF extension field, the presence of this field means "I am the last EF in this NTP Packet. Any subsequent packet data MUST be a legacy MAC." In this case, there is no parsing ambiguity.
If a system sends its MAC as a MAC-EF and does not send a legacy MAC, there is no parsing ambiguity.
The only time there is a potential for a parsing ambiguity is when a legacy MAC is provided and neither of the previous two cases are present. Even in this case, there is minimal risk.
An Extension Field contains a 2-octet Field Type, a 2-octet Field Length, and any payload (data and/or padding). If the NTP Packet parsing is at a point where it is evaluating data after the base packet, one of the following situations exists:
Semantic checking may also be done to validate a potential legacy MAC. A legacy MAC is a four-octet Key Identifier followed by a message digest. The usual message digest is 16 octets long but may be another size, depending on the digest algorithm. In the Reference Implementation, a Key Identifier between 1 and 65535, inclusive, is a symmetric key, while a Key Identifier that is > 65535 is an Autokey RFC 5906, or similar. If the receiving system does not recognize the Key Identifier, the data CANNOT be a valid legacy MAC. If the receiving system recognizes the Key Identifier, then it also has knowledge of the digest algorithm and can make sure the digest payload is the proper length. If this is not the case, then the data CANNOT be a valid legacy MAC. In this case, it MIGHT be a valid extension field.
It is trivial to parse the data after the base NTP packet and come up with a list of potential parsings. A local policy choice can specify the precedence of the parsing options in this case.
If none of the parsings validate, the packet fails authentication. An implementation has three local policy choices available if LAST-EF is not used and a legacy MAC may be provided. First, the implementation may specify EF-precedence. Second, the implementation may specify legacy-MAC-precedence. Finally, the implementation may specify "best fit" precedence. In this last case, the packet will meet one of the three following criteria: First, none of the parsings will match. Again, this is a case of failed authentication. Second, exactly one parsing will match and that parsing will be accepted. Third, multiple parsings will match, in which case the implementation may choose its behavior.
Additionally, most EFs will require a MAC. If there is a syntactically-valid parsing that does not include a MAC but previously scanned EFs require a MAC, then in a multiple-choice parsing scenario where one of the choices does not include a MAC the "no MAC provided" choice SHOULD be eliminated.
Note well that this rare situation can be completely avoided by using LAST-EF, or by indicating that no legacy MAC will be used.
Here are two potential pseudocode implementations showing how data after the base NTP packet could be analyzed to identify EFs and a possible legacy MAC.
[Example 1: high-level parsing algorithm]
[Example 2: the pseudocode Harlan sent to Tal and Danny]
This memo requests IANA to allocate the following bits in the NTP Extension Field Types table:
Additional information TBD
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC5905] | Mills, D., Martin, J., Burbank, J. and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010. |
| [RFC5906] | Haberman, B. and D. Mills, "Network Time Protocol Version 4: Autokey Specification", RFC 5906, DOI 10.17487/RFC5906, June 2010. |
| [RFC7821] | Mizrahi, T., "UDP Checksum Complement in the Network Time Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 2016. |