Skip to main content

Using NTP Extension Field without Authentication
draft-mizrahi-ntp-extension-field-00

The information below is for an old version of the document.
Document Type This is an older version of an Internet-Draft whose latest revision is Replaced
Author Tal Mizrahi
Last updated 2012-10-15
Replaced by RFC 7822
Stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-mizrahi-ntp-extension-field-00
NTP Working Group                                             T. Mizrahi
Internet Draft                                                   Marvell
Intended status: Informational
Expires: April 2013                                     October 15, 2012

              Using NTP Extension Field without Authentication
                 draft-mizrahi-ntp-extension-field-00.txt

Abstract

   The Network Time Protocol Version 4 (NTPv4) defines the optional
   usage of extension fields. An extension field is an optional field
   that resides at the end of the NTP header, and can be used to add
   optional capabilities or additional information that is not conveyed
   in the standard NTP header. The current definition of extension
   fields in NTPv4 is somewhat ambiguous regarding the connection
   between extension fields and the presence of a Message Authentication
   Code (MAC). This draft clarifies the usage of extension fields in the
   presence and in the absence of a MAC, while maintaining
   interoperability with existing implementations.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 15, 2013.

T. Mizrahi             Expires April 15, 2013                 [Page 1]
Internet-Draft           NTP Extension Field              October 2012

Copyright Notice

   Copyright (c) 2012 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.

Table of Contents

   1. Introduction ................................................. 2
   2. Conventions Used in this Document ............................ 3
      2.1. Terminology ............................................. 3
      2.2. Terms & Abbreviations ................................... 3
   3. NTP Extension Field Usage with and without a MAC ............. 4
      3.1. Extension Field Format .................................. 4
      3.2. Extension Fields in the Presence of a MAC ............... 4
      3.3. Extension Fields in the Absence of a MAC ................ 4
      3.4. Interoperability with Current Implementations ........... 4
      3.5. Interoperability with Current Implementations ........... 4
   4. Security Considerations ...................................... 5
   5. IANA Considerations .......................................... 5
   6. Acknowledgments .............................................. 5
   7. References ................................................... 5
      7.1. Normative References .................................... 5
   Appendix A. Requirements from NTPv4 and Autokey ................. 5
      A.1. NTP Extension Field for Future Extensions ............... 5
      A.2. NTP Extension Field in the Presence of a MAC ............ 6
      A.3. The NTP Extension Field Format .......................... 6
      A.4. NTP Extension Field in Autokey .......................... 6

1. Introduction

   The NTP header format consists of a set of fixed fields that may be
   followed by some optional fields. Two types of optional fields are
   defined, Message Authentication Codes (MAC), and extension fields.

   If a MAC is used, it resides at the end of the packet. This field can
   contain either a 20-octet digest, a 16-octet digest, or a 4-octet
   crypto-NAK.

T. Mizrahi             Expires April 15, 2013                 [Page 2]
Internet-Draft           NTP Extension Field              October 2012

   NTP extension fields were defined in [NTPv4] as a generic mechanism
   that allows to add future extensions and features without modifying
   the NTP header format.

   The only currently defined extension field is the one used by the
   AutoKey protocol [AutoKey].

   The NTP specification is somewhat ambiguous with regards to the
   connection between using extension fields and the presence of a MAC.

   o The definition of the NTP extension field implies that it was
      intended to be a generic mechanism that can be used for various
      future features of the protocol (see Section A.1. ).

   o On the other hand, the NTP extension field description in [NTPv4]
      states that a MAC is always present when an extension field is
      present (see Section A.2. ).

   The last two quotes seem to be in contradiction; since the extension
   field was defined as a generic future-compatible building block, it
   seems unlikely to bind it to a specific feature in the protocol.

   Moreover, the extension field parsing rules presented in [AutoKey]
   imply that an extension field can be present without a MAC, provided
   that the extension field is at least 7 words long.

   This document attempts to resolve the ambiguity with regards to the
   connection between NTP extension fields and MACs, and describes the
   usage of extension fields in the absence of a MAC in a way that is
   interoperable with current implementations.

2. Conventions Used in this Document

2.1. 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 [KEYWORDS].

2.2. Terms & Abbreviations

   NTPv4        Network Time Protocol Version 4

   MAC          Message Authentication Code

T. Mizrahi             Expires April 15, 2013                 [Page 3]
Internet-Draft           NTP Extension Field              October 2012

3. NTP Extension Field Usage with and without a MAC

3.1. Extension Field Format

   The NTP extension field is defined in [NTPv4]. The extension field
   format is quoted here in Section A.3.

   The minimal length of an extension field, as defined in [NTPv4], is
   16 octets.

3.2. Extension Fields in the Presence of a MAC

   The usage of extension fields in the presence of a MAC is specified
   in [NTPv4] and in [AutoKey].

3.3. Extension Fields in the Absence of a MAC

   Extension fields can be used when a MAC is not present in the NTP
   packet. In this case, the extension fields must comply to the parsing
   rules in Section A.4. Specifically:

   o If the packet includes a single extension field, the length of the
      extension field MUST be at least 7 words, i.e., at least 28 bytes.

   o If the packet includes more than one extension field, the length
      of the last extension field MUST be at least 28 octets. The length
      of the other extension fields in this case MUST be at least 16
      octets each, as defined in [NTPv4].

   A host that supports NTP extension fields MUST parse NTP extension
   fields as described in Section A.4.

3.4. Interoperability with Current Implementations

   The behavior described in Section 3.3. is compliant to [AutoKey], and
   thus should be compatible with existing implementations that support
   NTP extension fields.

3.5. Interoperability with Current Implementations

   This document currently clarifies the usage of extension fields in
   the absence of a MAC, in accordance with the definitions in [NTPv4]
   and [AutoKey].

   A future version of this document may define a more generic and
   flexible usage of extension fields.

T. Mizrahi             Expires April 15, 2013                 [Page 4]
Internet-Draft           NTP Extension Field              October 2012

4. Security Considerations

   The security considerations of the network time protocol are
   discussed in [NTPv4]. This document clarifies some ambiguity with
   regards to the usage of the NTP extension field, and thus the
   behavior described in this document does not introduce new security
   considerations.

5. IANA Considerations

   There are no new IANA considerations implied by this document.

6. Acknowledgments

   The author thanks Dave Mills and Danny Mayer for their insightful
   comments.

   This document was prepared using 2-Word-v2.0.template.dot.

7. References

7.1. Normative References

   [KEYWORDS]    Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [NTPv4]       Mills, D., Martin, J., Burbank, J., Kasch, W.,
                 "Network Time Protocol Version 4: Protocol and
                 Algorithms Specification", RFC 5905, June 2010.

   [AutoKey]     Haberman, B., Mills, D., "Network Time Protocol
                 Version 4: Autokey Specification", RFC 5906, June
                 2010.

Appendix A.                 Requirements from NTPv4 and Autokey

A.1. NTP Extension Field for Future Extensions

   The following paragraph is quoted from [NTPv4], Section 16.

   This document introduces NTP extension fields allowing for the
   development of future extensions to the protocol, where a particular
   extension is to be identified by the Field Type sub-field within the
   extension field.

T. Mizrahi             Expires April 15, 2013                 [Page 5]
Internet-Draft           NTP Extension Field              October 2012

A.2. NTP Extension Field in the Presence of a MAC

   The following paragraph is quoted from [NTPv4], Section 7.5.

   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.

A.3. The NTP Extension Field Format

   Figure 1 specifies the NTP extension field format, and is quoted from
   [NTPv4]. For further details refer to [NTPv4].

       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           |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      Value                              .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Padding (as needed)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 1 The NTP Extension Field Format

A.4. NTP Extension Field in Autokey

   The following paragraph is quoted from [AutoKey], Section 10.

   One or more extension fields follow the NTP packet header and the
   last followed by the MAC.  The extension field parser initializes a
   pointer to the first octet beyond the NTP packet header and
   calculates the number of octets remaining to the end of the packet If
   the remaining length is 20 (128-bit digest plus 4-octet key ID) or 22
   (160-bit digest plus 4-octet key ID), the remaining data are the MAC
   and parsing is complete.  If the remaining length is greater than 22,
   an extension field is present.  If the remaining length is less than
   8 or not a multiple of 4, a format error has occurred and the packet
   is discarded; otherwise, the parser increments the pointer by the
   extension field length and then uses the same rules as above to
   determine whether a MAC is present or another extension field.

T. Mizrahi             Expires April 15, 2013                 [Page 6]
Internet-Draft           NTP Extension Field              October 2012

Authors' Addresses

   Tal Mizrahi
   Marvell
   6 Hamada St.
   Yokneam, 20692 Israel

   Email: talmi@marvell.com

T. Mizrahi             Expires April 15, 2013                 [Page 7]