[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group           David L. Mills (University of Delaware)
Internet-Draft                  T. S. Glassey     (GMT)
Expires in six months           Michael E. McNeil (GMT)
March 1, 1999                   September 1, 1998


Authentication Scheme Extensions to NTP
<draft-mills-ntp-auth-coexist-01.txt>


Status of this Memorandum

This document is an Internet-Draft. 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.

To view the entire list of current Internet-Drafts, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).


Abstract

The purpose of this document is to extend the NTP/SNTP authentication
scheme to support additional features, including Public Key
Infrastructure (PKI) cryptography, in order to certify the identity
of the sender and verify the integrity of the data included in an
NTP message, as well as provide support for other facilities such
as a timestamp and non-repudiation service.

This document describes a new extension field to support new services
for securely binding sender credentials to the NTP message stream.
One or more of these fields can be included in the NTP header to
support designated security services or other services should they
become necessary. The presence of these fields does not affect the
operation of the NTP timekeeping model and protocol in any other way.

Additional fields may provide means to securely bind arbitrary client
data to be signed along with the other information in the message.
The ability to sign arbitrary client data provides an important non-
repudiation feature that allows this data to be cryptographically bound
to an NTP timestamp, together with sender credentials and signature.







Mills, Glassey, McNeil          expires March 1, 1999          [Page 1]


Internet-Draft                                         September 1, 1998


Contents

Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
Authentication schemes  . . . . . . . . . . . . . . . . . . . . . . .  5
Extension fields  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
Type descriptors  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   Null   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   Certificate  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   Generic Signature  . . . . . . . . . . . . . . . . . . . . . . . .  7
   Autokey  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   Scheme   . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
Implementation  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
Security considerations   . . . . . . . . . . . . . . . . . . . . . .  8
References  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
Authors' addresses  . . . . . . . . . . . . . . . . . . . . . . . . .  9


Introduction

The purpose of this document is to extend the NTP/SNTP authentication
scheme to support additional features, including Public Key
Infrastructure (PKI) cryptography, in order to certify the identity
of the sender and verify the integrity of the data included in a NTP
message. The current scheme described in RFC1305 for NTP Version 3 uses
a secret key and cryptographic hash of the message contents to protect
against message modification. The NTP protocol itself is inherently
resistant to replay and spoofing attacks. Extensions to the current
scheme described in [MILLS96] provide one means of securely binding
sender credentials to the NTP message stream. Alternative schemes may
be developed which provide this feature, as well as others supporting
a signature, timestamp and non-repudiation service.

This document describes a new extension field to support the new
services. One or more of these fields can be included in the NTP header
to support designated security services or other services should they
become necessary. However, the presence of these fields does not affect
the operation of the NTP timekeeping model and protocol in any other
way. In order to preserve existing interoperability, the presence of
these fields is determined by the message length. Ordinary (unprotected)
NTP messages are 48 octets long. Protected messages include either a 12-
octet or 20-octet Message Authentication Code (MAC), depending on the
hash algorithm, presently either Data Encryption Standard/Cipher-Block
Chaining (DES-CBC) or Message Digest 5 (MD5). The extension fields are
inserted after the unprotected header and before the MAC. If the overall
length of the NTP message is greater than the sum of the protected
header length and the longest MAC length, one or more extension fields
are present.







Mills, Glassey, McNeil          expires March 1, 1999          [Page 2]


Internet-Draft                                         September 1, 1998


Following traditional formats used by Internet protocols, the NTP
message consists of some number of 4-octet words in big-endian format.
The first word contains the total length of the extension field in the
low-order two octets. The high-order two octets contain a type code
to identify the payload content and processing algorithm. In order to
preserve alignment appropriate for block-encryption algorithms such as
DES, the last extension field is zero-padded to the next larger integral
multiple of eight octets. The hashing algorithm processes the extension
fields along with the protected header to produce the MAC at the end
of the message. Other than hash processing, the extension fields are
invisible to the ordinary NTP protocol operations.

The payload may include cryptographic media to support any of several
cryptographic schemes, including the autokey scheme of NTP Version 4
and other schemes as they are developed. The data can include various
subfields containing sequence numbers, additional message digests,
signatures and certificates, as well as the length of these subfields.
Additional fields may provide means to securely bind arbitrary client
data to be signed along with the other information in the message.
The ability to sign arbitrary client data provides an important non-
repudiation feature that allows this data to be cryptographically bound
to an NTP timestamp, together with sender credentials and signature.

With respect to the unprotected NTP header described in RFC 1305 and
RFC 2030, the new NTP header has the following format:





























Mills, Glassey, McNeil          expires March 1, 1999          [Page 3]


Internet-Draft                                         September 1, 1998


(Offset = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN  |Mode |    Stratum    |     Poll      |   Precision   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Root Delay                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Root Dispersion                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Reference Identifier                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                   Reference Timestamp (64)                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                   Originate Timestamp (64)                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                     Receive Timestamp (64)                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    Transmit Timestamp (64)                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      Extension Fields (EF)                    |
//                                                              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                Message Authenticator Code (MAC)               |
//                                                              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The 48-octet fixed-length unprotected header includes all fields through
the Transmit Timestamp field. The MAC includes a 4-octet Key Identifier
field followed by a variable length Message Digest field in the
following format:

                     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Key Identifier (32)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                 Message Digest (64 or greater)                |
//                                                              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Mills, Glassey, McNeil          expires March 1, 1999          [Page 4]


Internet-Draft                                         September 1, 1998


The Message Digest field length is presently either 8 octets for DES-CBC
or 16 octets for MD5; SHA-1, which may be supported in the future, uses
a 20-octet message digest. Selection of which one of these two supported
algorithms, or more in the case of additional hash algorithms, is
determined from the Key Identifier field as described later.


Authentication Schemes

The original NTP Version 3 authentication scheme described in RFC 1305
uses a hashing algorithm (DES-CBC or MD5) to produce a cryptographic
checksum of the unprotected NTP header. The checksum is computed by the
sender and included along with a private key identifier in the MAC. The
receiver verifies the checksum using its own copy of the private key.
The extended scheme proposed for NTP Version 4 [MIL96b], which uses the
extension field described in this document, continues support for the
previous scheme and is compatible with the scheme proposed herein.

In both NTP versions a designated hashing algorithm is used to compute
the message digest. While only DES-CBC and MD5 algorithms are supported
in existing implementations, other algorithms may be supported in
future. Each algorithm may require a specific message digest field
length, but not less than 8 octets, nor more than 20 octets. For
instance, DES requires an 8-octet field, and MD5 requires a 16-octet
field, whereas the SHA-1 algorithm, which may be supported in the
future, requires a 20-octet field. Any of these algorithms hashes
the contents of the 48-octet unprotected header and variable length
extension fields, but not the IP addresses, ports or MAC itself, to
produce the message digest.

In the NTP Version 3 scheme, the key identifier is used to select a
private encryption/decryption key from a predistributed set of keys.
Associated with each key is an algorithm identifier, which is defined
when the key is created and remains with it for the lifetime of the key.
The key identifier is used to look up the key and associated algorithm
identifier. Thus, no specific algorithm identifier field is necessary in
the MAC. In the NTP Version 4 schema, this model is preserved; however,
there is a new scheme, called autokey, which does not require prior
distribution of keys. In order to preserve legacy, the key identifier
space is partitioned in two subspaces, one allocated for private keys,
the other for randomly generated autokey keys. With respect to the
description here, this distinction is necessary only to clarify how the
hashing algorithm is identified and by implication how the length of the
MAC can be determined.










Mills, Glassey, McNeil          expires March 1, 1999          [Page 5]


Internet-Draft                                         September 1, 1998


Extension Fields

Zero, one or more extension fields can be included between the
unprotected header and the MAC. Each extension field consists of a 4-
octet header and variable length payload. The first two octets of the
header (reading in big-endian order) contain the type descriptor. The
next two octets contain the total extension field length, including the
length and type octets, but not any padding at the end. Each extension
field is zero-padded, as necessary, to the next 4-octet alignment;
the last field is zero-padded to the next 8-octet alignment. The total
length of every extension field must be greater than 24 octets, in order
to reliably recognize its presence (see below). This value, added to the
offset of the extension field within the message, points to the first
octet following the extension field. The overall format of all extension
fields within a given NTP packet is as follows:


(Offset = 48)        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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type Descriptor (16)     |          Length (16)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            Payload                            |
//                                                              //
|               +-----------------------------------------------+
|               |          Padding to 4-octet multiple          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                               ...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type Descriptor (16)     |          Length (16)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            Payload                            |
//                                                              //
|               +-----------------------------------------------+
|               |          Padding to 8-octet multiple          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+














Mills, Glassey, McNeil          expires March 1, 1999          [Page 6]


Internet-Draft                                         September 1, 1998


Type Descriptors

The type descriptor identifies the algorithm that understands the
particular format of a given type of extension field. There may be
a mixture of ASN.1, binary, ASCII and printable data in each field,
depending on the algorithm involved. There is no specific requirement
on ordering, if more than one extension field is present. In general,
schemes that require multiple fields will have to scan through all
type descriptors to verify that all required fields are present and
to determine the sequence of processing steps.

Some fields, such as certificate and signature fields, may be considered
generic across several different schemes, while others may be specific
to each scheme. For instance, most schemes using PKI will use X.509
certificates, RSA signatures and Diffie-Hellman key agreement, if any
of these features are required. In order to support these schemes, the
following functional types are supported.

Null

   This field is ignored, except by the hashing algorithm. It is
   included for testing and debugging.

Certificate

   This field contains the X.509 certificate in ASN.1 format.

Generic Signature

   This field contains the RSA signature in PKCS-1 encrypted block
   format. For this purpose, the RSA modulus and public exponent must be
   derived from the certificate or known by other means. The data to be
   signed is the message digest included in the MAC at the end of the
   NTP message. Note, this does not preclude a proprietary signature
   scheme with different semantics.

Autokey

   The field contains the Autokey data TBD.

Scheme

   This field is scheme-specific. It contains such variables as version
   ID, source ID, serial number, request/response bits and so forth.
   There may be more than one scheme field if more than one scheme is
   operating simultaneously. This could occur, for example, if the NTP
   Version 4 Autokey scheme is in use along with timestamping service or
   non-repudiation service.






Mills, Glassey, McNeil          expires March 1, 1999          [Page 7]


Internet-Draft                                         September 1, 1998


Implementation

There may be data in an extension field that is known only after the
message digest has been computed; in particular, the signature. In
order to produce a deterministic result, it is necessary to temporarily
replace these data with zeros when the digest is computed and replace
them when the final result is known. This is the same action specified
in IPSEC documents.

The various fields in the NTP message are parsed as follows. The parsing
algorithm assumes a pointer initially positioned at the end of the
unprotected header; i.e., at offset 48 octets. At each step the
remaining payload from the pointer to the end of the message is
considered.

1. If the remaining payload length is zero, that is, the pointer is
   at the end of the message, then there is no NTP MAC and the NTP
   authentication scheme described above is not used. If extension
   fields have been found previously, they are processed at this
   time and may result in message authentication by other schemes.

2. If the remaining payload length is less than four octets, declare
   a format error and consider the message to be unauthenticated.

3. If the remaining payload length is not greater than 24 octets,
   the NTP authentication scheme is in use, perhaps along with any
   previously located extension fields. The first 4-octet word in the
   remaining payload contains the key identifier used to look up the
   key and algorithm identifier. Depending on the particular algorithm
   identifier, the expected MAC length is checked against the actual
   remaining length. If the lengths agree, the message is processed as
   described above. If not, declare a format error and consider the
   message unauthenticated. Following processing of the MAC, any
   extension fields are processed, which may involve separately
   signing (encrypting) the message digest located in the MAC.

4. The remaining payload length must be greater than 24 octets. An
   extension field is present. If an extension field was found prior
   to this one in the NTP message, and the earlier extension field
   was padded to a 4-octet alignment rather than 8, backtrack the
   pointer by 4 octets. Move the pointer over the next extension
   field by adding the contents of its 2-octet length word to the
   current pointer value. Round the pointer up to the next 8-octet
   alignment. Proceed in step 1.


Security Considerations

Security issues are the main topic of this memorandum.





Mills, Glassey, McNeil          expires March 1, 1999          [Page 8]


Internet-Draft                                         September 1, 1998


References

[DAR81] Postel, J., Internet Protocol, STD 5, RFC 791, USC Information
Sciences Institute, September 1981.

[DEE96] Deering, S., R. Hinden, Internet Protocol, Version 6 (IPv6)
Specification, RFC 1883, Xerox and Ipsilon, January 1996.

[HIN96] Hinden, R., and S. Deering, IP Version 6 addressing
architecture, RFC 1884, Ipsilon and Xerox, January 1996.

[MIL92] Mills, D., Network Time Protocol (Version 3) specification,
implementation and analysis, RFC 1305, University of Delaware, March
1992.

[MIL96a] Mills, D., Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI, RFC 2030, University of Delaware, October 1996.

[MIL96b] Mills, D., Proposed authentication enhancements for the Network
Time Protocol Version 4, Electrical Engineering Report 96-10-3,
University of Delaware, October 1996.

[POS80] Postel, J., User Datagram Protocol, STD 6, RFC 768, USC
Information Sciences Institute, August 1980.


Authors' Addresses

David L. Mills
Electrical and Computer Engineering Department
University of Delaware
Newark, DE 19716
Phone: (302) 831-8247
E-mail: mills@udel.edu

T. S. Glassey
GMT - Glassey-McNeil Technologies
109A Bluebonnet Lane
Scotts Valley, CA 95066
Phone: (831) 438-7811
E-mail: tsgman@earthlink.net

Michael E. McNeil
GMT - Glassey-McNeil Technologies
109A Bluebonnet Lane
Scotts Valley, CA 95066
Phone: (831) 438-7811
E-mail: memcneil@got.net

Expires in six months: March 1, 1999




Mills, Glassey, McNeil          expires March 1, 1999          [Page 9]