Network Working Group David L. Mills (University of Delaware) Internet-Draft T. S. Glassey (Coastek InfoSys, Inc.) Expires in six months Michael E. McNeil (Coastek InfoSys, Inc.) May 26, 1998 November 26, 1997 Coexistence and Interoperability of NTP Authentication Schemes 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 This memorandum describes extensions to the Network Time Protocol (NTP) version 3, described in RFC 1305 [MIL92], and the Simple Network Time Protocol (SNTP) version 4, described in RFC 2030 [MIL96a], to create a framework for interoperability and coexistence of various cryptographic signature and authentication schemes that have been suggested as enhancements to NTP/SNTP [MIL96b]. Without describing any particular approach to authentication in detail, a framework is hereby established for these schemes and methods to coexist and interoperate on a single network or Internet. NTP v3, as specified in RFC 1305, provides support for a method of symmetric-key authentication. This model requires independent, out-of-band, distribution of cryptographic keys, with the associated risk of compromising those keys during distribution. This process is too costly and too great a security risk for universal application. The NTP protocol extensions described here allow for the creation of certified time from a certified and authenticated time source, for use in portable commercial-grade trust, non-repudiated logging, cryptographic synchronization, and other critical network management services. Newer cryptographic techniques involving public-key certificates and authentication (see the series of Internet-Drafts by the Public Key Infrastructure X.509 [PKIX] working groups of the IETF) can elevate timestamping to a trustable resource. Mills, Glassey, McNeil expires May 26, 1998 [Page 1] Internet-Draft November 26, 1997 Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Required NTP fields (as specified by NTP v3, via RFC 1305) . . . 2 3. Symmetric-key authentication (specified by NTP v3, RFC 1305) . . 3 4. NTP Extended Authentication . . . . . . . . . . . . . . . . . . 4 5. NTP Message Authenticator Code (MAC) Key Identifier . . . . . . 6 6. NTP Message Authenticator Code (MAC) Message Digest/Signature . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The purpose of this memorandum is to extend the NTP/SNTP authentication scheme so that various cryptographic authentication schemes can all coexist and interoperate on the same network and in the same protocol without interfering with one another's operation. This is accomplished by providing that any NTP/SNTP packet larger than the largest size supported for RFC 1305-type authentication (68 octets) must include an Extensions Length field immediately following the required (48-octet) portion of the NTP packet. The Extensions Length field contains the total number of octets of the Extensions field, including the Extensions Length field. The Extensions field, the internal contents of which are not defined in this memorandum, is then padded to the next 64-bit boundary with zero or more zero bits as required. The Extensions field is followed by the NTP Message Authenticator Code (MAC), which consists of the Key Identifier followed by the encrypted (that is, signed) Message Digest/Signature. The Message Digest/Signature within the MAC has a variable field length, depending on the digest/signature algorithm and selected algorithm parameters. This is to accommodate cryptographic digest/signature algorithms other than those described in the NTP specification and included in current implementations. These algorithms can include much more information in the generated signature than just the Message Digest/Signature of the data being signed. 2. Required NTP fields (as specified by NTP v3, via RFC 1305) As described in RFC 1305 and RFC 2030, NTP and SNTP packet headers are 48 octets in length and have the following format, whether or not the authentication scheme is in use. Mills, Glassey, McNeil expires May 26, 1998 [Page 2] Internet-Draft November 26, 1997 (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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 48) See the RFCs for detailed descriptions of these fields. The scheme proposed in this memorandum does not change the interpretation or use of any of these fields. 3. Symmetric-key authentication (specified by NTP v3, RFC 1305) RFC 1305 for NTP describes the specified authentication method thus: It employs a crypto-checksum, computed by the sender and checked by the receiver, together with a set of predistributed algorithms, certificates, and cryptographic keys indexed by a key identifier included in the message. The existing symmetric-key authentication schemes for NTP/SNTP v3 and proposed for NTP/SNTP v4 [MIL96b] continue as described and are unaffected by the scheme proposed herein. The proposed scheme is backwards compatible and, assuming the new features proposed herein are not used, existing implementations can continue to operate indefinitely. In both the existing and proposed schemes, the MAC includes a 32-bit Key Identifier field followed by a variable-length Message Digest/Signature field in the following format: Mills, Glassey, McNeil expires May 26, 1998 [Page 3] Internet-Draft November 26, 1997 (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Identifier (optional) (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Message Digest/Signature (optional) (variable) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 60 or 68) In the existing scheme, the Key Identifier is used to select a symmetric encryption/decryption key from a predistributed set of keys, requiring secure, out-of-band transfer of the keys prior to use. In this scheme the Message Digest/Signature must be either 8 octets (64 bits) or 16 octets (128 bits) in length. The 8-octet length supports the Data Encryption Standard Cipher-Block-Chaining (DES-CBC) algorithm, while the 128-bit length supports the Message Digest/Signature 5 (MD5) algorithm. Either algorithm hashes the 48- octet message header, but not the IP addresses or MAC itself, to produce the Message Digest/Signature contents. In the existing scheme, the particular algorithm which generates the Message Digest/Signature is determined by the packet length. If the overall packet length is 48 octets, no authentication scheme is used; if 60 octets, DES-CBC is used; if 68 octets, MD5 is used. Current NTP implementations support only these two algorithms; it is not anticipated that other algorithms will be supported in the existing scheme in future. Such algorithms would be supported in the scheme proposed herein. The total length of an NTP/SNTP packet in the above format (that is, the required NTP fields immediately followed by the MAC shown above) is not more than 68 octets (48 + 4 + 16), no matter whether DES-CBC or MD5 is used. An NTP packet longer than 68 octets implies that the Extended Authentication described in Sections 4, 5, and 6 is in use. The Extended Authentication NTP structure specified in Section 4 of this document must be used to accommodate a Message Digest/Signature algorithm that has a hash longer than 128 bits (16 octets), or a signature algorithm that produces a signature longer than 128 bits. This structure provides additional space for related cryptographic values, which are beyond the scope of this memorandum. 4. NTP Extended Authentication The original NTP authentication scheme is modified as follows: if the total size of the NTP/SNTP packet is greater than 68 octets, the Extended Authentication mode is in effect. In this mode, either symmetric key or public-key cryptography can be used, depending on Mills, Glassey, McNeil expires May 26, 1998 [Page 4] Internet-Draft November 26, 1997 the values defined in the Extensions field. In particular, the symmetric-key algorithms defined for NTP/SNTP Versions 3 and 4 can be used with no change, other than to extend the fields covered to include the Extensions field and padding. This feature provides a mechanism to convey the data used to verify the public values in the proposed NTP Version 4 multicast authentication scheme, as well as any others that may be devised. Whenever an NTP packet is longer than 68 octets and Extended Authentication mode is in effect, a 16-bit (in network octet order) Extensions Length field directly follows the NTP header. The value in this field specifies the size of the Extensions field, including the Extensions Length field itself. The value in this field must be such that the total packet length is greater than 68 octets, in order to avoid confusion with the existing scheme. This value, added to the offset of the Extensions field within the packet, points to the first octet following the Extensions field. The Extensions field, the internal contents of which are not defined in this memorandum, is then padded to the next 64-bit boundary with zero or more zero bits as required. The format of the Extensions field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions Length (16) | Extensions... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------ ------+ | | | Extensions (contd.)... | | | | +-----------------------------------------------+ | | * Padding to 64 bits (example) | +---------------+------ ------+ | Padding to 64 bits (contd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ** (Offset = 48 + Extensions Length + Padding) The single asterisk (*) at the beginning of the padding field shows where the Extensions Length field (lengthwise) points, as an example of where padding is necessary. If no padding is required (because the Extensions field is already aligned to end exactly on a 64-bit boundary), the Extensions Length field points (**) directly to the MAC Key Identifier field, which immediately follows the Extensions field. The NTP MAC, including the Key Identifier and Message Digest/Signature fields, follows the Extensions field and any necessary padding. These fields can have the same format and lengths as in the existing NTP authentication scheme and operate in the same way. However, to support other digest/signature schemes, the Message Digest/Signature field can take other lengths, depending on the algorithm and algorithm parameters. Mills, Glassey, McNeil expires May 26, 1998 [Page 5] Internet-Draft November 26, 1997 5. NTP Message Authenticator Code (MAC) Key Identifier In the original NTP authentication scheme, the reference implementation uses a key cache including structures which store the key identifier, algorithm selection, algorithm parameters and the key itself. The structures are accessed using a hash table for quick lookup. The key type, algorithm and algorithm parameters are selected at the time the key is installed in the cache. Thus, there is no fixed relationship between a particular key identifier value and the algorithm and algorithm parameters associated with it, and thus no additional cryptographic vulnerability. The scheme allows the addition of new algorithms, such as the Secure Hash Algorithm 1 (SHA-1), or other cryptographic signature algorithms, without changing current MAC formats. In the new authentication scheme for NTP Version 4 described in [MIL96b], Key Identifier values greater than or equal to 65,536 (hex range 00010000 through ffffffff) are reserved for use as random session key identifiers. If a randomly generated key happens to have values less than this, the random-number generator is spun again. In NTP Version 4, a new session key is generated for every NTP message sent by a client to a server and for the server to the client, so it is important to maintain as many bits of resolution as possible. It is expected that those schemes with fixed relationship between key identifier and key type, algorithm and parameters will use key identifiers with values less than 65,536. However, this convention does not preclude use of a reserved key identifier with value in the random-key range, since the intended key generation scheme watches for collisions (birthday events) and spins again if a collision occurs. The reserved identifier could be used for an arbitrary purpose, such as to designate features not implemented in the key cache. 6. NTP Message Authenticator Code (MAC) Message Digest/Signature Because some signature algorithms such as RSA typically store more information in a signature than just an encrypted hash, as in DES-CBC or MD5, the Message Digest/Signature field can have variable length. In the NTP reference implementation, after the signature of the packet fields is computed, the signing algorithm returns the signature length. This value must be saved (perhaps in an allocated subfield in the Extensions field) until the signature is verified, since there may be no other way to determine this from the received packet alone. The region to be signed includes everything in the NTP packet, except the MAC itself. The entire packet, from the beginning (at offset 0) of the required fields of the NTP packet, through the end of the Extensions field, up to but not including the MAC, is included in the encrypted Message Digest/Signature, which is stored in the Message Digest/Signature field in the MAC. Note that, in the new NTP Version Mills, Glassey, McNeil expires May 26, 1998 [Page 6] Internet-Draft November 26, 1997 4 scheme, the session key hash which produces the actual key identifier includes the IP addresses and Key Identifier field in the MAC, which provides additional cryptographic security. 7. Security Considerations Security issues are the main topic of this memorandum. 8. Acknowledgments Many thanks to Leonard Cutler, Robin Giffard, and others at Hewlett- Packard and HP Laboratories, as well as to Frank Acker, Joe Keefe, Ron Hughes, Linden Anderson, Carolyn Stallard, and others at Coastek, people too numerous to mention, but far, far too helpful to forget. 9. 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. 10. Authors' Addresses David L. Mills Electrical Engineering Department University of Delaware Newark, DE 19716 Phone: (302) 831-8247 E-mail: mills@udel.edu Mills, Glassey, McNeil expires May 26, 1998 [Page 7] Internet-Draft November 26, 1997 T. S. Glassey Coastek InfoSys, Inc. 5550 Scotts Valley Drive, Suite 700 Scotts Valley, CA 95066 Phone: (408) 440-0180 ext. 420 Fax: (408) 438-2979 E-mail: todd@coastek.com Michael E. McNeil Coastek InfoSys, Inc. 5550 Scotts Valley Drive, Suite 700 Scotts Valley, CA 95066 Phone: (408) 440-0180 ext. 404 Fax: (408) 438-2979 E-mail: michael@coastek.com Expires in six months: May 26, 1998 Mills, Glassey, McNeil expires May 26, 1998 [Page 8]