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]
