Internet DRAFT - draft-mizrahi-ntp-extension-field
draft-mizrahi-ntp-extension-field
NTP Working Group T. Mizrahi
Internet Draft Marvell
Intended status: Standards Track D. Mayer
Updates: 5905 Network Time Foundation
Expires: July 2014 January 2, 2014
Using NTP Extension Fields without Authentication
draft-mizrahi-ntp-extension-field-03.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 July 2, 2014.
Mizrahi, Mayer Expires July 2, 2014 [Page 1]
Internet-Draft NTP Extension Field January 2014
Copyright Notice
Copyright (c) 2014 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 ................................................. 3
2. Conventions Used in this Document ............................ 4
2.1. Terminology ............................................. 4
2.2. Terms & Abbreviations ................................... 4
3. NTP Extension Fields with and without a MAC - Clarifications . 4
3.1. Extension Field Format .................................. 4
3.2. Extension Fields in the Absence of a MAC ................ 4
3.3. Unknown Extension Fields ................................ 5
3.4. Interoperability with Current Implementations ........... 5
4. NTP Extension Field Usage with and without a MAC - Extensions 5
4.1. Extension Fields in the Presence of a MAC ............... 5
4.2. Extension Fields in the Absence of a MAC ................ 5
4.3. Multiple Extension fields in an NTP packet .............. 6
4.4. MAC in the absence of an Extension field ................ 6
5. Security Considerations ...................................... 6
6. IANA Considerations .......................................... 6
7. Acknowledgments .............................................. 6
8. References ................................................... 6
8.1. Normative References .................................... 6
8.2. Informative References .................................. 7
Appendix A. Requirements from NTPv4 and Autokey ................. 7
A.1. NTP Extension Field for Future Extensions ............... 7
A.2. NTP Extension Field in the Presence of a MAC ............ 7
A.3. The NTP Extension Field Format .......................... 7
A.4. NTP Extension Field in Autokey .......................... 8
Mizrahi, Mayer Expires July 2, 2014 [Page 2]
Internet-Draft NTP Extension Field January 2014
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
be either 24 octets long, 20 octets long, or a 4-octet crypto-NAK.
NTP extension fields were defined in [RFC5905] 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 [RFC5906].
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
[RFC5905] 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 [RFC5906]
imply that an extension field can be present without a MAC, provided
that the extension field is at least 28 Octets long.
This document attempts to resolve the ambiguity with regards to the
connection between NTP extension fields and MACs, updating
Section 7.5 of [RFC5905], and describes the usage of extension fields
in the absence of a MAC in a way that is interoperable with current
implementations.
Mizrahi, Mayer Expires July 2, 2014 [Page 3]
Internet-Draft NTP Extension Field January 2014
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
3. NTP Extension Fields with and without a MAC - Clarifications
This section clarifies the usage of extension fields in the absence
of a MAC, in accordance with the definitions in [RFC5905] and
[RFC5906]. Section 4. defines a more generic and flexible usage of
extension fields.
3.1. Extension Field Format
The NTP extension field is defined in Section 7.5 of [RFC5905]. The
extension field format is quoted here in Section A.3.
The minimal length of an extension field, as defined in Section 7.5
of [RFC5905], is 16 octets.
3.2. 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 with 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
octets.
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 [RFC5905].
A host that supports NTP extension fields MUST parse NTP extension
fields as described in Section A.4.
Mizrahi, Mayer Expires July 2, 2014 [Page 4]
Internet-Draft NTP Extension Field January 2014
3.3. Unknown Extension Fields
If an extension field is unknown to the receiving server the server
should ignore the extension field and may optionally drop the packet
altogether if policy requires it. Note that in the presence of an
unknown extension field any MAC that may be present may be
misinterpreted as an unknown extension though in this case the
apparent extension length will be totally inconsistent with the total
length of the rest of the packet.
3.4. Interoperability with Current Implementations
The behavior described in Section 3.2. is compliant to [RFC5906], and
thus should be compatible with existing implementations that support
NTP extension fields.
4. NTP Extension Field Usage with and without a MAC - Extensions
This section updates [RFC5905] and [RFC5906] with respect to the
usage of extension fields, allowing a more flexible and unambiguous
usage.
4.1. Extension Fields in the Presence of a MAC
The usage of extension fields in the presence of a MAC is specified
in [RFC5905] and in [RFC5906]. The requirement for a MAC MUST be
specified by the specification for the extension field and the
specification MUST include both the algorithm to be used to create
the MAC and the length of the MAC thus created. An extension field
may allow for more than one algorithm to be used in which case the
information about which one was used MUST be included in the
extension field itself.
4.2. 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 with the
following:
o If the packet includes a single extension field, the length of the
extension field MUST be at least 16 octets. The extension length
is specified in the length field of the extension and is the
number of octets in the extension field.
Mizrahi, Mayer Expires July 2, 2014 [Page 5]
Internet-Draft NTP Extension Field January 2014
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 [RFC5905].
4.3. Multiple Extension fields in an NTP packet
If there are multiple extension fields that require a MAC they MUST
all require use of the same algorithm and MAC length. Extension
fields that do not require a MAC can be included with extension
fields that do require a MAC.
4.4. MAC in the absence of an Extension field
A MAC must not be any longer than 24 octets if there is no extension
field present unless through a previous exchange of packets with an
extension field which defines the size and algorithm of the MAC
transmitted in the packet and is agreed upon by both client and
server.
5. Security Considerations
The security considerations of the network time protocol are
discussed in [RFC5905]. 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.
6. IANA Considerations
There are no new IANA considerations implied by this document.
7. Acknowledgments
The authors thank Dave Mills for his insightful comments.
This document was prepared using 2-Word-v2.0.template.dot.
8. References
8.1. Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Mizrahi, Mayer Expires July 2, 2014 [Page 6]
Internet-Draft NTP Extension Field January 2014
[RFC5905] Mills, D., Martin, J., Burbank, J., Kasch, W.,
"Network Time Protocol Version 4: Protocol and
Algorithms Specification", RFC 5905, June 2010.
8.2. Informative References
[RFC5906] 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 Section 16 of [RFC5905].
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.
A.2. NTP Extension Field in the Presence of a MAC
The following paragraph is quoted from Section 7.5 of [RFC5905].
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
[RFC5905]. For further details refer to [RFC5905].
Mizrahi, Mayer Expires July 2, 2014 [Page 7]
Internet-Draft NTP Extension Field January 2014
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 Section 10 of [RFC5906].
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.
Authors' Addresses
Tal Mizrahi
Marvell
6 Hamada St.
Yokneam, 20692 Israel
Email: talmi@marvell.com
Mizrahi, Mayer Expires July 2, 2014 [Page 8]
Internet-Draft NTP Extension Field January 2014
Danny Mayer
Network Time Foundation
PO Box 918
Talent OR 97540
Email: mayer@ntp.org
Mizrahi, Mayer Expires July 2, 2014 [Page 9]
