draft-ietf-stime-ntpauth-00.txt		draft-ietf-stime-ntpauth-01.txt
	Network Working Group David L. Mills		Network Working Group David L. Mills
	Internet Draft University of Delaware		Internet Draft University of Delaware
	Category: Standards Track		Category: Standards Track
	Public-Key Cryptography for the Network Time Protocol		Public-Key Cryptography for the Network Time Protocol
	Version 1		Version 1
	Status of this Memorandum		Status of this Memorandum
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with all
	all provisions of Section 10 of RFC2026.		provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering Task
	Task Force (IETF), its areas, and its working groups. Note that other		Force (IETF), its areas, and its working groups. Note that other groups
	groups may also distribute working documents as Internet-Drafts.		may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet- Drafts as reference		time. It is inappropriate to use Internet- Drafts as reference material
	material or to cite them other than as "work in progress."		or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft		http://www.ietf.org/ietf/1id-abstracts.txt
	Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html. This document is an Internet-Draft.
	This document is an Internet-Draft.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119 [12].		document are to be interpreted as described in RFC-2119 [1].
	1. Abstract		1. Abstract
	This memorandum describes a scheme for authenticating servers to		This memorandum describes a scheme for authenticating servers to clients
	clients for the Network Time Protocol. It extends prior schemes based		in the Network Time Protocol. It extends prior schemes based on
	on symmetric-key cryptography to a new scheme based on public-key		symmetric-key cryptography to a new scheme based on public-key
	cryptography. The new scheme, called Autokey, is based on the premiss		cryptography. The new scheme, called Autokey, is based on the premiss
	that the IPSEC schemes proposed by the IETF cannot be adopted		that the IPSEC schemes proposed by the IETF cannot be adopted intact,
	intact,since that would preclude stateless servers and severely		since that would preclude stateless servers and severely compromise
	compromise timekeeping accuracy. In addition, the IPSEC model		timekeeping accuracy. In addition, the IPSEC model presumes
	presumes timestamps are always available using authenticated means;		authenticated timestamps are always available; however,
	however, cryptographically verified timestamps require interaction		cryptographically verified timestamps require interaction between the
	between the timekeeping function and authentication function in ways		timekeeping function and authentication function in ways not yet
	not yet considered in the IPSEC model.		considered in the IPSEC model.
	The main body of the memorandum contains a description of the		The main body of this memorandum contains a description of the security
	security model, approach rationale, protocol design and vulnerability		model, approach rationale, protocol design and vulnerability analysis.
	analysis. It obsoletes a previous report [10] primarily in the		It obsoletes a previous report [11] primarily in the schemes for
	schemes for distributing public keys and related values. A detailed		distributing public keys and related values. A detailed description of
	description of the protocol states, events and transition functions		the protocol states, events and transition functions is included.
	is included. Detailed packet formats and field descriptions are given		Detailed packet formats and field descriptions are given in the
	in the appendix. A prototype of the Autokey design based on this		appendix. A prototype of the Autokey design based on this memorandum has
	document and improvements described in this memorandum has been		been implemented, tested and documented in the NTP Version 4 software
	implemented, tested and documented in the NTP Version 4 software		distribution for Unix, Windows and VMS at www.ntp.org.
	distribution for Unix, Windows and VMS.
	While not strictly a security function, the Autokey scheme also		While not strictly a security function, the Autokey protocol also
	provides means to securely retrieve a table of historic leap seconds		provides means to securely retrieve a table of historic leap seconds
	necessary to convert ordinary civil time (UTC) to atomic time (TAI)		necessary to convert ordinary civil time (UTC) to atomic time (TAI)
	where needed. The tables can be retrieved either directly from		where needed. The tables can be retrieved either directly from national
	national time servers operated by NIST or indirectly through		time servers operated by NIST or indirectly through intervening servers.
	intervening servers.
	2. Introduction		Changes Since the Preceeding Draft
	A reliable distributed network service requires provisions to prevent		There are a number of changes scattered through this memorandum to
	accidental or malicious attacks on the servers and clients in the		clarify the presentation and add a few new features. Among the most
	network. Reliability requires that clients can determine that		important:
	received packets are authentic; that is, were actually sent by the
	intended server and not manufactured or modified by an intruder.
	Ubiquity requires that any client can verify the authenticity of any
	server using only public information. This is especially important in
	such ubiquitous network services as directory services, cryptographic
	key management and time synchronization.
	The Network Time Protocol (NTP) contains provisions to		1. An optional parameter negotiation message has been added to the
	cryptographically authenticate individual servers as described in the		protocol state machine. The values it may carry and the interpretation
	most recent protocol specification RFC-1305 [7]; however, that		of these values are not defined in this memorandum.
	specification does not provide a scheme for the distribution of
	cryptographic keys, nor does it provide for the retrieval of		2. A preliminary value exchange has been added to begin the protocol
	cryptographic media that reliably bind the server identification		dance. This is necessary to avoid a vulnerability where unsolicited
	credentials with the associated keys and related public values.		public key responses could clog the victim with needless signature
	However, conventional key agreement and digital signatures with large		cycles.
	client populations can cause significant performance degradations,
	especially in time critical applications such as NTP. In addition,		3. The value exchange, which is piggybacked on the association ID
	there are problems unique to NTP in the interaction between the		message, supports a timestamp-based agreement scheme which floods the
	authentication and synchronization functions, since each requires the		latest version of the agreement parameters and leapseconds table. Using
	other.		this scheme any one of a clique of trusted primary servers running
			symmetric modes with each other and broadcast or client/server modes
			with the secondary server population can refresh these data at any time
			and the refreshed data will update all older data everywhere in the NTP
			subnet within one day.
			4. An optional certificate retrieval operation has been added to the
			protocol state machine. While the operation has been implemented and
			tested, the contents of the certificate itself have not been determined.
			5. A couple of subtle livelock problems with symmetric mode and
			broadcast mode were found and fixed. The problem with source addresses
			not yet bound has been fixed in the reference implementation.
			6. The protocol descriptions and state diagrams have been updated. Some
			packet formats have been changed in minor ways.
			7. Provisions for the use of IPv6 addresses in calculating the autokey
			have been added.
			8. Provisions for the use of arbitrary identification values to be used
			in lieu or IP addresses in calculating the autokey have been added.
			9. A simplified version of the protocol appropriate for SNTP clients is
			proposed; details to follow.
			Introduction
			A distributed network service requires reliable, ubiquitous and
			survivable provisions to prevent accidental or malicious attacks on the
			servers and clients in the network or the values they exchange.
			Reliability requires that clients can determine that received packets
			are authentic; that is, were actually sent by the intended server and
			not manufactured or modified by an intruder. Ubiquity requires that any
			client can verify the authenticity of any server using only public
			information. Survivability requires protection from faulty
			implementations, improper operation and possibly malicious clogging and
			replay attacks with or without data modification. These requirements are
			especially stringent with widely distributed network services, since
			damage due to failures can propagate quickly throughout the network,
			devastating archives, routing databases and monitoring systems and even
			bring down major portions of the network.
			The Network Time Protocol (NTP) contains provisions to cryptographically
			authenticate individual servers as described in the most recent protocol
			specification RFC-1305 [7]; however, that specification does not provide
			a scheme for the distribution of cryptographic keys, nor does it provide
			for the retrieval of cryptographic media that reliably bind the server
			identification credentials with the associated keys and related public
			values. However, conventional key agreement and digital signatures with
			large client populations can cause significant performance degradations,
			especially in time critical applications such as NTP. In addition, there
			are problems unique to NTP in the interaction between the authentication
			and synchronization functions, since each requires the other.
	This memorandum describes a cryptographically sound and efficient		This memorandum describes a cryptographically sound and efficient
	methodology for use in NTP and similar distributed protocols. As		methodology for use in NTP and similar distributed protocols. As
	demonstrated in the reports and briefings cited in the references at		demonstrated in the reports and briefings cited in the references at the
	the end of this memorandum, there is a place for Public-Key		end of this memorandum, there is a place for Public-Key Infrastructure
	Infrastructure (PKI) and related schemes, but none of these schemes		(PKI) and related schemes, but none of these schemes alone satisfies the
	alone satisfies the requirements of the NTP security model. The		requirements of the NTP security model. The various key agreement
	various key agreement schemes [1, 4, 11] proposed by the IETF require		schemes [2, 5, 12] proposed by the IETF require per-association state
	per-association state variables, which contradicts the principles of		variables, which contradicts the principles of the remote procedure call
	the remote procedure call (RPC) paradigm in which servers keep no		(RPC) paradigm in which servers keep no state for a possibly large
	state for a possibly large client population. An evaluation of the		client population. An evaluation of the PKI model and algorithms as
	PKI model and algorithms as implemented in the rsaref2.0 package		implemented in the rsaref2.0 package formerly distributed by RSA
	formerly distributed by RSA Laboratories leads to the conclusion that		Laboratories leads to the conclusion that any scheme requiring every NTP
	any scheme requiring every NTP packet to carry a PKI digital		packet to carry a PKI digital signature would result in unacceptably
	signature would result in unacceptably poor timekeeping performance.		poor timekeeping performance.
	A revised security model and authentication scheme called Autokey was		A revised security model and authentication scheme called Autokey was
	proposed in earlier reports [5, 6, 8]. It has been evolved and		proposed in earlier reports [5, 6, 8]. It has been evolved and refined
	refined since then and implemented in NTP Version 4 for Unix, Windows		since then and implemented in NTP Version 4 for Unix, Windows and VMS
	and VMS [10]. It is based on a combination of PKI and a pseudo-random		[11]. It is based on a combination of PKI and a pseudo-random sequence
	sequence generated by repeated hashes of a cryptographic value		generated by repeated hashes of a cryptographic value involving both
	involving both public and private components. This scheme has been		public and private components. This scheme has been tested and evaluated
	tested and evaluated in a local environment and is being deployed now		in a local environment and is being deployed now in the CAIRN experiment
	in the CAIRN experiment network funded by DARPA. A detailed		network funded by DARPA. A detailed description of the security model,
	description of the security model, design principles and		design principles and implementation experience is presented in this
	implementation experience is presented in this memorandum.		memorandum.
	3. Security Model		Security Model
	Over the last several years the IETF has defined and evolved the		NTP security requirements are even more stringent than most other
	IPSEC infrastructure for the protection of privacy and authentication		distributed services. First, the operation of the authentication
	of sources in the Internet, The infrastructure includes the		mechanism and the time synchronization mechanism are inextricably
	Encapsulating Security Payload (ESP) [3] and Authentication Header		intertwined. Reliable time synchronization requires cryptographic keys
	(AH) [2] for IPv4 and IPv6. Cryptographic algorithms that use these		which are valid only over designated time intervals; but, time intervals
	headers for various purposes include those developed for the PKI,		can be enforced only when all servers and clients are reliably
	including MD5 message digests, RSA digital signatures and several		synchronized to UTC. Second, the NTP subnet is hierarchical by nature,
	variations of Diffie-Hellman key agreements. The fundamental		so time and trust flow from the primary servers at the root through
	assumption in the security model is that packets transmitted over the		secondary servers to the clients at the leaves. A client can claim
	Internet can be intercepted by other than the intended receiver,		authentic only if all servers on the path to the primary servers are
	remanufactured in various ways and replayed in whole or part. These		bone-fide authentic. In order to emphasize this requirement, in this
	packets can cause the client to believe or produce incorrect		memorandum, the notion of "authentic" is replaced by "proventic", a noun
	information, cause protocol operations to fail, interrupt network		new to English and derived from provenance, as in the provenance of a
	service or consume processor resources with needless cryptographic		painting. Having abused the language this far, the suffixes fixable to
	calculations.		the various noun and verb derivatives of authentic will be adopted for
			proventic as well. In NTP each server authenticates the next lower
			stratum servers and proventicates the lowest stratum (primary) servers.
	In the case of NTP, the assumed goal of the intruder is to inject		Over the last several years the IETF has defined and evolved the IPSEC
	false time values, disrupt the protocol or clog the network and		infrastructure for privacy protection and source authentication in the
	receiver with spurious packets that exhaust resources and deny		Internet, The infrastructure includes the Encapsulating Security Payload
	service to legitimate processes. The mission of the algorithms and		(ESP) [4] and Authentication Header (AH) [3] for IPv4 and IPv6.
	protocols described in this memorandum is to detect and discard		Cryptographic algorithms that use these headers for various purposes
	spurious packets sent by other than the intended sender or sent by		include those developed for the PKI, including MD5 message digests, RSA
	the intended sender but modified or replayed by an intruder. The		digital signatures and several variations of Diffie-Hellman key
	cryptographic means of the reference implementation are based on the		agreements. The fundamental assumption in the security model is that
	rsaref2.0 algorithms, but other algorithms with equivalent		packets transmitted over the Internet can be intercepted by other than
	functionality could be used as well. It is important for distribution		the intended receiver, remanufactured in various ways and replayed in
	purposes that the way in which these algorithms are used precludes		whole or part. These packets can cause the client to believe or produce
	encryption of any data other than incidental to the construction of		incorrect information, cause protocol operations to fail, interrupt
	digital signatures.		network service or consume processor resources with needless
			cryptographic calculations.
			In the case of NTP, the assumed goal of the intruder is to inject false
			time values, disrupt the protocol or clog the network or servers or
			clients with spurious packets that exhaust resources and deny service to
			legitimate processes. The mission of the algorithms and protocols
			described in this memorandum is to detect and discard spurious packets
			sent by other than the intended sender or sent by the intended sender
			but modified or replayed by an intruder. The cryptographic means of the
			reference implementation are based on the rsaref2.0 algorithms, but
			other algorithms with equivalent functionality could be used as well. It
			is important for distribution and export purposes that the way in which
			these algorithms are used precludes encryption of any data other than
			incidental to the construction of digital signatures.
	There are a number of defense mechanisms already built in the NTP		There are a number of defense mechanisms already built in the NTP
	architecture, protocol and algorithms. The fundamental timestamp-		architecture, protocol and algorithms. The fundamental timestamp-
	exchange scheme is inherently resistant to replay attacks. The		exchange scheme is inherently resistant to replay attacks. The
	engineered clock filter, intersection and clustering algorithms are		engineered clock filter, selection and clustering algorithms are
	designed to fend off Byzantine sources and cliques. While not		designed to defend against Byzantine traitors and evil cliques. While
	necessarily designed to defeat determined intruders, these algorithms		not necessarily designed to defeat determined intruders, these
	and accompanying eleven sanity checks have functioned well over the		algorithms and accompanying sanity checks have functioned well over the
	years to deflect improperly operating but presumably friendly		years to deflect improperly operating but presumably friendly scenarios.
	scenarios.
	However, these mechanisms do not securely identify and authenticate		However, these mechanisms do not securely identify and authenticate
	the servers themselves. Without specific further protection, an		servers to clients. Without specific further protection, an intruder can
	intruder can do any or all of the following mischiefs. Further		inject any or all of the following mischiefs. Further discussion on the
	discussion on the assumed intruder model is given in [8], but beyond		assumed intruder model is given in [9], but beyond the scope of this
	the scope of this memorandum.		memorandum.
	1. An intruder can intercept and archive packets forever and can		1. An intruder can intercept and archive packets forever and can archive
	archive all the public values ever generated and transmitted over the		all the public values ever generated and transmitted over the net.
	net.
	2. An intruder can generate packets faster than the server or client		2. An intruder can generate packets faster than the server or client can
	can process them if they require expensive PKI operations.		process them, especially if they require expensive PKI operations.
	3. An intruder can intercept, modify and replay a packet. However, it		3. An intruder can intercept, modify and replay a packet. However, it
	cannot permanently prevent packet transmission over the net; that is,		cannot permanently prevent the original packet transmission over the
	it cannot break the wire, only congest it.		net; that is, it cannot break the wire, only congest it.
	The following assumptions are fundamental to the Autokey design. They		The following assumptions are fundamental to the Autokey design. They
	are discussed at some length in the briefing slides and links at		are discussed at some length in the briefing slides and links at
	www.eecis.udel.edu/~mills/ntp.htm and will not be further discussed		www.eecis.udel.edu/~mills/ntp.htm and will not be further discussed in
	in this memorandum.		this memorandum.
	1. The running times for public-key algorithms are relatively long		1. The running times for public-key algorithms are relatively long and
	and highly variable. In general, the performance of the		highly variable. In general, the performance of the synchronization
	synchronization function is badly degraded if these algorithms must		function is badly degraded if these algorithms must be used for every
	be used for every NTP packet.		NTP packet.
	2. In some modes of operation it is not feasible for a server to		2. In some modes of operation it is not feasible for a server to retain
	retain cryptographic state variables for every client. It is however		cryptographic state variables for every client. It is however feasible
	feasible to regenerated them for a client upon arrival of a packet		to regenerated them for a client upon arrival of a packet from that
	from that client.		client.
	3. The lifetime of cryptographic values must be enforced, which		3. The lifetime of cryptographic values must be enforced, which requires
	requires a reliable system clock. However, the sources that		a reliable system clock. However, the sources that synchronize the
	synchronize the system clock must be cryptographically authenticated.		system clock must be cryptographically proventicated. This circular
	This circular interdependence of the timekeeping and authentication		interdependence of the timekeeping and proventication functions requires
	functions requires special handling.		special handling.
	4. All authentication functions must involve only public values		4. All proventication functions must involve only public values
	transmitted over the net. Private values must never be disclosed		transmitted over the net. Private values must never be disclosed beyond
	beyond the machine on which they were created.		the machine on which they were created.
	5. Public keys and agreement parameters, where necessary, must be		5. Public keys and agreement parameters, where necessary, must be
	retrievable directly from servers without requiring secured channels;		retrievable directly from servers without requiring secured channels;
	however, the fundamental security of identification credentials and		however, the fundamental security of identification credentials and
	public values bound to those credentials must eventually be a		public values bound to those credentials must eventually be a function
	function of certificate authorities and webs of trust.		of certificate authorities and/or webs of trust.
	4. Approach		Unlike the ssh security model, where the client must be securely
			identified to the server, in NTP the server must be securely identified
			to the client. In ssh each different interface address can be bound to a
			different name, as returned by a reverse-DNS query. In this design
			separate public/private key pairs may be required for each interface
			address with a distinct name. A perceived advantage of this design is
			that the security compartment can be different for each interface. This
			allows a firewall, for instance, to require some interfaces to
			proventicate the client and others not.
			However, the NTP security model specifically assumes all time values and
			cryptoraphic values are public, so there is no need to associate each
			interface with different cryptoraphic values. In the NTP design the host
			name, as returned by the gethostname() library function, represents all
			interface addresses. Since at least in some host configurations the host
			name may not be identifiable in a DNS query, the name must be either
			configured in advance or obtained directly from the server using the
			Autokey protocol.
			Approach
	The Autokey protocol described in this memorandum is designed to meet		The Autokey protocol described in this memorandum is designed to meet
	the following objectives. Again, in-depth discussions on these		the following objectives. Again, in-depth discussions on these
	objectives is in the web briefings and will not be elaborated in this		objectives is in the web briefings and will not be elaborated in this
	memorandum.		memorandum. Note that here and elsewhere in this memorandum mention of
			broadcast mode means multicast mode as well, with exceptions as noted.
	1. It must interoperate with the existing NTP architecture model and		1. It must interoperate with the existing NTP architecture model and
	protocol design. In particular, it must support the symmetric-key		protocol design. In particular, it must support the symmetric-key scheme
	scheme described in RFC-1305. As a practical matter, the reference		described in RFC-1305. As a practical matter, the reference
	implementation must use the same internal key management system,		implementation must use the same internal key management system,
	including the use of 32-bit key IDs and existing mechanisms to store,		including the use of 32-bit key IDs and existing mechanisms to store,
	activate and revoke keys.		activate and revoke keys.
	2. It must provide for the independent collection of cryptographic		2. It must provide for the independent collection of cryptographic
	values and time values. A client is synchronized to an authentic		values and time values. A client is proventicated only when the all
	source only when the all cryptographic values have been obtained and		cryptographic values have been obtained and verified and the NTP
	verified and the NTP timestamps have passed all sanity checks.		timestamps have passed all sanity checks.
	3. It must not significantly degrade the potential accuracy of the		3. It must not significantly degrade the potential accuracy of the NTP
	NTP synchronization algorithms. In particular, it must not make		synchronization algorithms. In particular, it must not make unreasonable
	unreasonable demands on the network or host processor and memory		demands on the network or host processor and memory resources.
	resources.
	4. It must be resistant to cryptographic attacks, including		4. It must be resistant to cryptographic attacks, including
	replay/modification and clogging attacks. In particular, it must be		replay/modification and clogging attacks. In particular, it must be
	tolerant of operation or implementation variances, such as packet		tolerant of operation or implementation variances, such as packet loss
	loss or misorder, or suboptimal configuration.		or misorder, or suboptimal configuration.
	5. It must build on a widely available suite of cryptographic		5. It must build on a widely available suite of cryptographic
	algorithms, yet be independent of the particular choice. In		algorithms, yet be independent of the particular choice. In particular,
	particular, it must not require data encryption other than incidental		it must not require data encryption other than incidental to signature
	to signature and verification functions.		and verification functions.
	6. It must function in all the modes supported by NTP, including		6. It must function in all the modes supported by NTP, including
	client/server, multicast/manycast and symmetric active/passive modes.		client/server, broadcast and symmetric active/passive modes.
	7. It must not require intricate per-client or per-server		7. It must not require intricate per-client or per-server configuration
	configuration other than the availability of public/private key files		other than the availability of public/private key files and agreement
	and agreement parameter files, as required.		parameter files, as required.
	8. The reference implementation must contain provisions to generate		8. The reference implementation must contain provisions to generate
	cryptographic key values, including private/public keys and agreement		cryptographic key values, including private/public keys and agreement
	parameters specific to each client and server. Eventually, it must		parameters specific to each client and server. Eventually, it must
	contain provisions to validate public values using certificate		contain provisions to validate public values using certificate
	authorities and webs of trust.		authorities and/or webs of trust.
	4.1 Autokey Authentication Scheme		Autokey Proventication Scheme
	The Autokey public-key cryptography is based on the PKI algorithms of		Autokey public-key cryptography is based on the PKI algorithms of the
	the rsaref2.0 library, although other libraries with a compatible		rsaref2.0 library, although other libraries with a compatible interface
	interface could be used as well. The reference implementation uses		could be used as well. The reference implementation uses keyed-MD5
	MD5 message digests to detect packet modification, timestamped RSA		message digests to detect packet modification, timestamped RSA digital
	digital signatures to verify the source, and Diffie-Hellman key		signatures to verify the source, and Diffie-Hellman key agreements to
	agreements to construct a private key from public values. However,		construct a private shared key from public values. However, there is no
	there is no reason why alternative signature schemes and agreement		reason why alternative signature schemes and agreement algorithms could
	algorithms could be supported. What makes the Autokey scheme unique		be supported. What makes Autokey cryptography unique is the way in which
	is the way in which these algorithms are used to deflect intruder		these algorithms are used to deflect intruder attacks while maintaining
	attacks while maintaining the integrity and accuracy of the time		the integrity and accuracy of the time synchronization function.
	synchronization function.
	The NTP Version 3 symmetric-key cryptography uses keyed-MD5 message		The NTP Version 3 symmetric-key cryptography uses keyed-MD5 message
	digests with a 128-bit private key and 32-bit key ID. In order to		digests with a 128-bit private key and 32-bit key ID. In order to retain
	retain backward compatibility, the key ID space is partitioned in two		backward compatibility, the key ID space is partitioned in two subspaces
	subspaces at a pivot point of 65536. Symmetric key IDs have values		at a pivot point of 65536. Symmetric key IDs have given values less than
	less than 65536 and indefinite lifetime. Autokey keys have pseudo-		65536 and indefinite lifetime. Autokey key IDs have pseudo-random values
	random values equal to or greater than 65536 and are expunged		equal to or greater than 65536 and are expunged immediately after use.
	immediately after use.
	There are three Autokey protocol variants corresponding to each of		There are three Autokey protocol variants corresponding to each of the
	the three NTP modes: client/server, multicast/manycast and symmetric		three NTP modes: client/server, broadcast and symmetric active/passive.
	active/passive. All three variants make use of a specially contrived		All three variants make use of a specially contrived session key called
	session key called an autokey and a pseudo-random sequence of key Ids		an autokey and a pseudo-random sequence of key IDs called the key list.
	called the key list. As in the original NTP Version 3 authentication		As in the original NTP Version 3 authentication scheme, the Autokey
	scheme, the Autokey scheme operates separately for each association,		protocol operates separately for each association, so there may be
	so there may be several key lists operating independently at the same		several key lists operating independently at the same time and with
	time and with associated values and signatures.		distinct associated values and signatures.
	An autokey consists of four 32-bit fields in the network order shown		An autokey consists of four fields in network byte order as shown below:
	below:
	+-----------+-----------+-----------+-----------+		+-----------+-----------+-----------+-----------+
	| Source IP | Dest IP | key ID | cookie |		| Source IP | Dest IP | Key ID | Cookie |
	+-----------+-----------+-----------+-----------+		+-----------+-----------+-----------+-----------+
			For use with IPv4, the Source IP and Dest IP fields contain 32 bits; for
			use with IPv6, these fields contain 128 bits. In either case the Key ID
			and Cookie fields contain 32 bits. Thus, an IPv4 autokey has four 32-bit
			words, while an IPv6 autokey has ten 32-bit words. The source and
			destination IP addresses and key ID are public values visible in the
			packet, while the cookie can be a public value or a private value,
			depending on the mode.
	The source and destination IP addresses and key ID are public values		There are some scenarios where the use of endpoint IP addresses when
	visible in the packet, while the cookie can be a public value or a		calculating the autokey may be difficult or impossible. These include
	private value, depending on the mode.		configurations where Network Address Translation (NAT) devices are in
			use or when addresses are changed during an association lifetime due to
			mobility constraints. As described below, NTP associations are
			identified by the endpoint IP addresses, so the natural approach is to
			authenticate associations using these values. For scenarios where this
			is not possible, an optional identification value can be used instead of
			the endpoint IP addresses. The Parameter Negotiation message contains an
			option to specify these data; however, the format, encoding and use of
			this option are not specified in this memorandum. For the purposes of
			this memorandum, the endpoint IP addresses will be assumed.
	The NTP packet format has been augmented to include one or more		The NTP packet format has been augmented to include one or more
	extension fields piggybacked between the original NTP header and the		extension fields piggybacked between the original NTP header and the
	message authenticator code (MAC) at the end of the packet. For		message authenticator code (MAC) at the end of the packet. For packets
	packets without extension fields, the cookie is a private value		without extension fields, the cookie is a private value computed by an
	computed by an agreement algorithm. For packets with extension		agreement algorithm. For packets with extension fields, the cookie has a
	fields, the cookie is a public value (0), since these packets can be		default public value of zero, since these packets can be validated
	validated independently using signed data in an extension field. The		independently using signed data in the extension fields. The four values
	four values are hashed by the message digest algorithm to produce the		are hashed by the message digest algorithm to produce the actual key
	actual key value, which is stored along with the key ID in a cache		value, which is stored along with the key ID in a cache used for
	used for symmetric keys as well as autokeys. Keys are retrieved from		symmetric keys as well as autokeys. Keys are retrieved from the cache by
	the cache by key ID using hash tables and a fast algorithm.		key ID using hash tables and a fast algorithm.
	The key list consists of a sequence of key IDs starting with a random		The key list consists of a sequence of key IDs starting with a random
	value and each pointing to the next. To generate the next autokey on		value and each pointing to the next. To generate the next autokey on the
	the key list, the next key ID is the first 32 bits of the previous		key list, the next key ID is the first 32 bits in network byte order of
	key value. It may happen that a newly generated key ID is less than		the previous key value. It may happen that a newly generated key ID is
	65536 or collides with another one already generated. When this		less than 65536 or collides with another one already generated (birthday
	happens, which can occur only rarely, the key list is terminated at		event). When this happens, which should occur only rarely, the key list
	that point. The lifetime of each key is set to expire one poll		is terminated at that point. The lifetime of each key is set to expire
	interval after its scheduled use. In the reference implementation,		one poll interval after its scheduled use. In the reference
	the list is terminated when the maximum key lifetime is about one		implementation, the list is terminated when the maximum key lifetime is
	hour.		about one hour.
	The index of the last key ID in the list is saved along with the next		The index of the last key ID in the list is saved along with the next
	key ID of that entry, collectively called the autokey values. The		key ID of that entry, collectively called the autokey values. The list
	list is used in reverse order, so that the first key ID used is the		is used in reverse order, so that the first key ID used is the last one
	last one generated. The autokey protocol includes a message to		generated. The Autokey protocol includes a message to retrieve the
	retrieve the autokey values and signature, so that subsequent packets		autokey values and signature, so that subsequent packets can be
	can be authenticated using one or more hashes that eventually match		authenticated using one or more hashes that eventually match the first
	the first key ID (valid) or exceed the index (invalid). In the		key ID (valid) or exceed the index (invalid). This is called the autokey
	reference implementation the most recent key ID received is saved for		test in the following and is done for every packet, including those with
	comparison with the first 32 bits of the next following key value.		and without extension fields. In the reference implementation the most
	This minimizes the number of hash operations in case a packet is		recent key ID received is saved for comparison with the first 32 bits in
	lost.		network byte order of the next following key value. This minimizes the
			number of hash operations in case a packet is lost.
	In client/server mode the server keeps no state for each client, but		The scheme used in client/server mode was suggested by Steve Kent over
	uses a fast algorithm and a private value to regenerate the cookie		lunch. The server keeps no state for each client, but uses a fast
	upon arrival of a client packet. The cookie is calculated in a manner		algorithm and a private value to regenerate the cookie upon arrival of a
	similar to the autokey, where the key ID field is zero and the cookie		client packet. The cookie is calculated in a manner similar to the
	field is the private value. The first 32 bits of the hash is the		autokey, but the key ID field is zero and the cookie field is the
	cookie used for the actual autokey calculation and is returned to the		private value. The first 32 bits of the hash is the cookie used for the
	client on request. It is thus specific to each client separately and		actual autokey calculation and is returned to the client on request. It
	of no use to other clients or an intruder. A client obtains the		is thus specific to each client separately and of no use to other
	cookie and signature using the Autokey protocol and saves it for		clients or an intruder. A client obtains the cookie and signature using
	later use.		the Autokey protocol and saves it for later use.
	In client/server mode the cookie is a relatively weak function of the		In client/server mode the cookie is a relatively weak function of the IP
	IP addresses and a server private value. The client uses the cookie		addresses and a server private value. The client uses the cookie and
	and each key ID on the key list in turn to calculate the MAC for the		each key ID on the key list in turn to calculate the MAC for the next
	next NTP packet. The server calculates these values and checks the		NTP packet. The server calculates these values and checks the MAC, then
	MAC, then generates the MAC for the response using the same values,		generates the MAC for the response using the same values, but with the
	but with the IP addresses reversed. The client calculates and checks		IP source and destination addresses exchanged. The client calculates and
	the MAC and verifies the key ID matches the one sent. In this mode		checks the MAC and verifies the key ID matches the one sent. In this
	the sequential structure of the key list is not exploited, but doing		mode the sequential structure of the key list is not exploited, but
	it this way simplifies and regularizes the implementation.		doing it this way simplifies and regularizes the implementation.
	In multicast/manycast mode, clients normally do not send packets to		In broadcast mode, clients normally do not send packets to the server,
	the server, except when first starting up to calibrate the		except when first starting up to calibrate the propagation delay in
	propagation delay in client/server mode. At the same time the client		client/server mode. At the same time the client temporarily
	temporarily authenticates as in that mode. After obtaining and		authenticates as in that mode. After obtaining and verifying the cookie,
	verifying the cookie, the client continues to obtain and verify the		the client continues to obtain and verify the autokey values. To obtain
	autokey values. To obtain these values, the client must provide the		these values, the client must provide the ID of the particular server
	ID of the particular server association, since there can be more than		association, since there can be more than one operating in the same
	one operating in the same machine. For this purpose, the multicast		machine. For this purpose, the broadcast server includes the association
	server includes the association ID in every packet sent, except when		ID in every packet sent, except when sending the first packet after
	sending the first packet after generating a new key list, when it		generating a new key list, when it sends the autokey values instead.
	sends the autokey values instead.
	In symmetric mode each peer keeps state variables related to the		In symmetric mode each peer keeps state variables related to the other,
	other, so that a private cookie can be computed by a strong agreement		so that a private cookie can be computed by a strong agreement
	algorithm. The cookie itself is the first 32 bits of the agreed key.		algorithm. The cookie itself is the first 32 bits of the agreed key. The
	The key list for each direction is generated separately by each peer		key list for each direction is generated separately by each peer and
	and used independently.		used independently, but each is generated with the same cookie.
	The server authentic bit is set only when the cookie or autokey		The server proventic bit is set only when the cookie or autokey values,
	values, depending on mode, and signature are both valid. If the bit		depending on mode, and the associated timestamp and signature are all
	is set, the client sends valid timestamps in signed responses. If the		valid. If the bit is set, the client processes NTP time values; if the
	bit is not set, the data and signature are processed in order to run		bit is not set, extension field messages are processed in order to run
	the Autokey protocol, but the NTP time values are ignored. Packets		the Autokey protocol, but the NTP time values are ignored. Packets with
	with old timestamps are discarded immediately while avoiding		old timestamps are discarded immediately while avoiding expensive
	expensive cryptographic algorithms. Bogus packets with newer		cryptographic algorithms. Bogus packets with newer timestamps must pass
	timestamps must pass the MAC and autokey tests, which is highly		the MAC and autokey tests, which is highly unlikely.
	unlikely.
	Once the authentic bit is set, the NTP time values are processed, so		Once the proventic bit has been set, the Autokey protocol is normally
	that eventually the client will synchronize to an authentic source.		dormant. In all modes except broadcast server, packets are normally sent
	In client/server and symmetric modes, packets are normally sent
	without an extension field, unless the packet is the first one sent		without an extension field, unless the packet is the first one sent
	after generating a new key list or unless the client has requested		after generating a new key list or unless the client has requested the
	the cookie or autokey values. If for some reason the client clock is		cookie or autokey values. If for some reason the client clock is
	stepped, rather than slewed, all cryptographic data and time values		stepped, rather than slewed, all cryptographic and time values for all
	for all associations are cleared and the synchronization and		associations are purged and the Autokey protocol restarted from scratch.
	authentication procedures start over from scratch. This insures that		This insures that stale values never propagate beyond a clock step.
	old cryptographic and synchronization values never propagate beyond a
	clock reset.
	4.2 Public-Key Signatures		Public-Key Signatures
	Since public-key signatures provide strong protection against		Since public-key signatures provide strong protection against
	misrepresentation of sources, probably the most obvious intruder		misrepresentation of sources, probably the most obvious intruder
	strategy is to deny or restrict service by replaying old packets with		strategy is to deny or restrict service by replaying old packets with
	signed cryptographic values in a cut-and-paste attack. The basis		signed cryptographic values in a cut-and-paste attack. The basis values
	values on which the cryptographic operations depend are changed often		on which the cryptographic operations depend are changed often to
	to deflect brute force cryptanalysis, so the client must be prepared		deflect brute force cryptanalysis, so the client must be prepared to
	to abandon an old key in favor of a refreshed one. This invites the		abandon an old key in favor of a refreshed one. This invites the
	opportunity for an intruder to clog the client or server by replaying		opportunity for an intruder to clog the client or server by replaying
	old Autokey messages or to invent bogus new ones. A client receiving		old Autokey messages or to invent bogus new ones. A client receiving
	such messages might be forced to refresh the correct value from the		such messages might be forced to refresh the correct value from the
	legitimate server and consume significant processor resources.		legitimate server and consume significant processor resources.
	In order to foil such attacks, every extension field carries a		In order to foil such attacks, every extension field carries a timestamp
	timestamp in the form of the NTP seconds at the signature time. The		in the form of the NTP seconds at the signature time. The signature
	signature includes the timestamp itself together with optional		includes the timestamp itself together with optional additional data. If
	additional data. If the Autokey protocol has verified the source is		the Autokey protocol has verified a proventic source and the NTP
	authentic and the NTP algorithms have validated the time values, the		algorithms have validated the time values, the system clock is
	system clock is synchronized and signatures carry a nonzero (valid)		synchronized and signatures carry a nonzero (valid) timestamp. Otherwise
	timestamp. Otherwise the system clock is unsynchronized and		the system clock is unsynchronized and signatures carry a zero (invalid)
	signatures carry a zero (invalid) timestamp. Extension fields with		timestamp. Extension fields with invalid or old timestamps are discarded
	invalid or old timestamps are discarded before any values are used or		before any values are used or signatures verified.
	signatures verified.
	There are three signature types:		There are three signature types and six values to be signed:
	1. The public agreement value is signed at the time of generation,		1. The public value is signed at the time of generation, which occurs
	which occurs when the system clock is first synchronized and about		when the system clock is first synchronized and about once per day after
	once per day after that in the reference implementation. For		that in the reference implementation. Besides the public value, the
	convenience, the public key/host name, agreement parameters and leap		public key/host name, agreement parameters and leapseconds table are all
	table signatures are recomputed at the same time as the public value		signed as well, even if their values have not changed. All four of these
	signature and carries the same timestamp. On request, each of these		values carry the same timestamp. On request, each of these values and
	values and associated signatures and timestamps are returned in an		associated signatures and timestamps are returned in an extension field.
	extension field.
	2. The cookie value is computed and signed upon arrival of a request		2. The cookie value is computed and signed upon arrival of a cookie
	message. On request, the cookie, signature and timestamp are returned		request message. The response message contains the cookie, signature and
	in an extension field.		timestamp in an extension field.
	3. The autokey values are signed when a new key list is generated,		3. The autokey values are signed when a new key list is generated, which
	which occurs about once per hour in the reference implementation. On		occurs about once per hour in the reference implementation. On request,
	request, the autokey values, signature and timestamp are returned in		the autokey values, signature and timestamp are returned in an extension
	an extension field.		field.
	The most recent timestamp for each of the three signature types is		The most recent timestamp for each of the six values is saved for
	saved for comparison. Once a signature with valid timestamp has been		comparison. Once a signature with valid timestamp has been received,
	received, packets carrying extension fields with invalid timestamps		packets carrying extension fields with invalid timestamps or older valid
	or older valid timestamps of the same type are discarded before any		timestamps for the same value are discarded before the signature is
	values are used or signatures verified. For packets containing signed		verified. For packets containing signed extension fields, the timestamp
	extension fields, the timestamp deflects replays that otherwise might		deflects replays that otherwise might consume significant processor
	consume significant processor resources; for other packets the		resources; for other packets the Autokey protocol deflects message
	Autokey protocol deflects message modification and replay. In		modification and replay. In addition, the NTP protocol itself is
	addition, the NTP protocol itself is inherently resistant to replays		inherently resistant to replays and consumes only minimal processor
	and consumes only minimal processor resources.		resources.
	While files carrying cryptographic data not specifically signed, the		All cryptographic values used by the protocol are time sensitive and are
	file names have timestamp extensions which reliably determine the		regularly refreshed. In particular, files containing cryptographic basis
	time of generation. As the data are forwarded from machine to		values used by signature and agreement algorithms are regenerated from
	machine, the filestamps are preserved. This can in principle be used		time to time. It is the intent that file regeneration and loading of
	as a total ordering function to verify that the data are consistent		these values occur without specific warning and without requiring
	and represent the latest available generation. For this reason, the		distribution in advance. While files carrying cryptographic data are not
	files should always be generated on a machine when the system clock		specifically signed, the file names have extensions called filestamps
	is valid.		which reliably determine the time of generation. The filestamp for a
			file is a string of decimal digits representing the NTP seconds at the
			time the file was created.
	In order to further reduce the window of opportunity, even for a		As the data are forwarded from server to client, the filestamps are
	fanatical intruder, additional causality constraints can be checked.		preserved, including those for the public key/host name, agreement
			parameters and leapseconds table. Packets with older filestamps are
			discarded befor the signature is verified. Filestamps can in principle
			be used as a total ordering function to verify that the data are
			consistent and represent the latest available generation. For this
			reason, the files should always be generated on a machine when the
			system clock is valid.
	1. If the system clock if valid, all timestamps and filestamps must		When a client or server initializes, it reads its own public and private
	be earlier than the current clock time.		key files, which are required for continued operation. Optionally, it
			reads the agreement parameters file and constructs the public and
			private values to be used later in the agreement algorithm. Also
			optionally, it reads the leapseconds table file. When reading these
			files it checks the filestamps for validity; for instance, all
			filestamps must be later than the time the UTC timescale was established
			in 1972.
	2. All signature timestamps must be later than the public key		When the client first validates a proventic source and when the clock is
	timestamp.		stepped and when new cryptographic values are loaded from a server, the
			client recomputes all signatures and checks the filestamps for validity
			and consistency with the signature timestmaps:
	3. In multicast client mode, the cookie timestamp must be later than		1. If the system clock if valid, all timestamps and filestamps must be
	the autokey timestamp.		earlier than the current clock time.
			2. All signature timestamps must be later than the public key timestamp.
			3. In broadcast client mode, the cookie timestamp must be later than the
			autokey timestamp.
	4. In symmetric modes the autokey timestamp must be later than the		4. In symmetric modes the autokey timestamp must be later than the
	public value timestamp.		public value timestamp.
	5. Timestamps for each cryptographic data type must be later than the		5. Timestamps for each cryptographic data type must be later than the
	filestamps for that type.		filestamps for that type.
	In the above constraints, note the public key timestamp and signature		In the above constraints, note that timestamps and filestamps have a
	timestamps have a granularity of one second, so that a timestamp		granularity of one second, so that a difference of zero seconds is
	difference of zero seconds is ambiguous. Furthermore, timestamps can		ambiguous. Furthermore, timestamps and filestamps can be in error as
	be in error as much as the value of the synchronization distance;		much as the value of the synchronization distance; that is, the sum of
	that is, the sum of the root dispersion plus one-half the root delay.		the root dispersion plus one-half the root delay. However, the NTP
	However, the NTP protocol operates with polling intervals much longer		protocol normally operates with polling intervals much longer than one
	than one second, so that successive timestamps for the same data type		second, so that successive timestamps for the same data type are
	can never by ambiguous.		nonambiguous. On most machines, the processor time to generate a
			complete set of key files is longer than one second, so it is not
			possible to generate two generations in the same second.
	4.3 Filestamps		However, it may happen that agreement parameters files may be generated
			on two machines with the same filestamps, which creates an ordering
			ambiguity. The filestamps for leapseconds files should also be
			nonambiguous, since these files are created by NIST not more often than
			twice per year. While filestamp collisions should be so rare as to be
			safely ignored, a good management approach might require that these
			files be generated only on a schedule that guarantees that no more than
			one client or server generates a new key file set on any one day.
	All cryptographic values used by the protocol are time sensitive and		Certificates
	are regularly refreshed. In particular, files containing
	cryptographic basis values used by signature and agreement algorithms
	are regenerated from time to time. It is the intent that file
	regeneration and loading of these values occur without specific
	warning and without requiring distribution in advance. For these
	reasons, the name of every cryptographic value file includes a
	filestamp consisting of the decimal NTP seconds at the time of
	generation.
	When a client or server initializes, it reads its own public and		PKI principles call for the use of certificates to reliably bind the
	private key files, which are required for continued operation.		server distinguished name (host name), public key and related values to
	Optionally, it reads the agreement parameter file and constructs the		each other. The certificate includes these values together with the
	public and private values to be used later in the agreement protocol.		distinguished name of the certificate atuthority (CA) and other values
	Also optionally, it reads the leap table file. When loading these		such as serial number and valid lifetime. These values are then signed
	files it checks the filestamps for consistency and validity. When the		by the CA using its private key. The Autokey protocol includes
	client is eventually synchronized to an authentic source, it checks		provisions to obtain the certificate, but at the present time does
	the filestamps for validity relative to the system clock time. If the		nothing with the values. A future version of the protocol is to include
	filestamps are later than the clock time, something is seriously		provisions to validate the binding using procedures established by the
	wrong and either the time has synchronized in error or the data files		IETF.
	are defective.
	When a client mobilizes an association, it retrieves the server host		Packet Processing Rules
	name and public key from the server using the Autokey protocol.
	Optionally, it retrieves the agreement parameters and leap table, if
	required, and constructs the public and private values. Optionally,
	and before going further, it verifies the server credentials using
	certificate authorities and a web of trust. As above, when the client
	is eventually synchronized to an authentic source, it again checks
	the filestamps for validity.
	4.4 Error Recovery		Exhaustive examination of possible vulnerabilities at the various
			processing steps of the NTP protocol as specified in RFC-1305 have
			resulted in a revised list of packet sanity tests. These tests have been
			formulated to harden the protocol against defective header and data
			values. These are summarized below, since they are an integral component
			of the NTP cryptograhic defense mechanism. There are eleven tests,
			called TEST1 through TEST11 in the reference implementation, which are
			performed in a specific order designed to gain maximum diagnostic
			information while protecting against accidental or malicious errors.
	The protocol state machine which drives the various autokey functions		The tests are divided into three groups. The first group is designed to
	includes provisions for various kinds of error conditions that can		deflect access control and authentication violations. While access
	arise due to missing key or agreement parameter files, corrupted		control and message digest violations always result immediate discard,
	data, protocol state mismatches and packet loss or misorder, not to		it is necessary when first mobilizing an association to disable the
	mention hostile intrusion. There are two mechanisms which maintain		autokey test and certain timestamp tests. However, after the proventic
	the liveness state of the protocol, the reachability register defined		bit is set, all tests are enforced.
	in RFC-1305 and the watchdog timer, which is new in NTP Version 4.
			The second group of tests is designed to deflect packets from broken or
			unsynchronized servers and replays. In order to synchronize an
			association in symmetric modes, it is necessary to save the originate
			and receive timestamps in order to send them at a later time. This
			happens for the first packet that arrives, even if it violates the
			autokey test. In the normal case, the second packet to arrive will be
			accepted and the association marked reachable. However, an agressive
			intruder could replay old packets that could disrupt the saved
			timestamps. This could not result in incorrect time values, but could
			prevent a legitimate client from synchronizing the association.
			The third group of tests is designed to deflect packets with invalid
			header fields or time values with excessive errors. However, these tests
			do not directly affect cryptographic source proventication or
			vulnerability, so are beyond the scope of discussion in this document.
			For packets containing signed extension fields additional tests apply,
			depending on request type. There are the usual tests for valid extension
			field format, length and values. An instantiated variable, such as the
			public key/host name, agreement paramaters, public value, cookie or
			autokey values, is valid when the accompaning timestamp and filestamp
			are valid. The public key must be instantiated before any signatures can
			be verified. In symmetric modes the agreement parameters must be
			instantiated before the public and private agreement values can be
			determined; the public agreement value must be instantiated before the
			agreement algorithm can be run to determine the cookie. In all modes the
			cookie value must be determined before the key list can be generated.
			The object of the Autokey dances described below is to set the proventic
			bit. In client/server mode this bit is set when the cookie is validated.
			In other modes this bit is set when the autokey values are validated.
			The bit is cleared initially and when the autokey test fails. If once
			the bit is set and then cleared, the protocol will send an autokey
			request message at the next poll opportunity and continue to send this
			message until receiving valid autokey values or a general reset occurs.
			This behavior is a compromise between protocol responsiveness, where the
			current association can be maintained without interruption, and protocol
			vulnerability, where an intruder can repeatedly clog the receiver with
			replays that cause the client to needlessly poll the server and refresh
			the values.
			Error Recovery
			The protocol state machine which drives the various Autokey functions
			includes provisions for various kinds of error conditions that can arise
			due to missing files, corrupted data, protocol violation and packet loss
			or misorder, not to mention hostile intrusion. There are two mechanisms
			which maintain the liveness state of the protocol, the reachability
			register defined in RFC-1305 and the watchdog timer, which is new in NTP
			Version 4.
	The reachability register is an 8-bit register that shifts left with		The reachability register is an 8-bit register that shifts left with
	zero replacing the rightmost bit. A shift occurs for every poll		zero replacing the rightmost bit. A shift occurs for every poll
	interval, whether or not a poll is actually sent. If an arriving		interval, whether or not a poll is actually sent. If an arriving packet
	packet passes all authentication and sanity checks, the rightmost bit		passes all authentication and sanity checks, the rightmost bit is set to
	is set to one. Thus, the pattern of ones and zeros in this register		one. If any bit in this register is one, the server is reachable,
	reveals the reachability status of the server for the last eight poll		otherwise it is unreachable. If the server was once reachable and then
	intervals.		becomes unreachable, a general reset is performed. A general reset
			reinitializes all association variables to the state when first
	With respect to the issues at hand, if this register is nonzero, the		mobilized and returns all acquired resources to the system. In addition,
	server is reachable, otherwise it is unreachable. If the server was		if the association is not configured, it is demobilized until the next
	once reachable and then becomes unreachable, a general reset is		packet is received.
	performed. A general reset reinitializes all association variables to
	the state when first mobilized and returns all acquired resources to
	the system. In addition, if the association is not configured, it is
	demobilized until the next server packet is received.
	The watchdog timer increments for every poll interval, whether or not		The watchdog timer increments for every poll interval, whether or not a
	a poll is actually sent and regardless of the reachability state. The		poll is actually sent and regardless of the reachability state. The
	counter is set to zero upon arrival of a cryptographically		counter is set to zero upon arrival of a packet from a proventicated
	authenticated packet, as determined by the Autokey protocol. In the		source, as determined by the Autokey protocol. In the reference
	reference implementation, if the counter reaches 16 a general reset		implementation, if the counter reaches 16 a general reset is performed.
	is performed.
	In addition, if the association is configured, the poll interval is		In addition, if the association is configured, the poll interval is
	doubled. This reduces the network load for packets that are unlikely		doubled. This reduces the network load for packets that are unlikely to
	to elicit a response.		elicit a response.
	The general approach to Autokey error recovery is to retry the		At each state in the protocol the client expects a particular response
	request message at intervals of about one minute until the watchdog		from the server. A request is included in the NTP message sent at every
	timer expires and then restart the protocol from the beginning. At		poll interval until the authentic response is received or a general
	each state in the protocol the client expects a particular variable		reset occurs, in which case the protocol restarts from the beginning.
	to be received from the server. A NTP packet including the		While this behavior might be considered rather conservative, the
	appropriate request is sent at every poll interval until the variable		advantage is that old cryptographic and time values can never persist
	is received or a general reset occurs. While this behavior might be		from one mobilization to the next.
	considered rather conservative, the advantage is that old
	cryptographic values can never persist from one mobilization to the
	next.
	There are a number of situations where some action causes the		There are a number of situations where some action on an association
	remaining autokeys on the key list to become invalid. When one of		causes the remaining autokeys on the key list to become invalid. When
	these situations happens, the key list and associated keys in the key		one of these situations happens, the key list and associated keys in the
	cache are purged.		key cache are purged. A new key list, signature and timestamp are
	A new key list is generated when the next NTP message is sent,		generated when the next NTP message is sent, assuming there is one.
	assuming there is one. Following is a list of these situations.		Following is a list of these situations.
	1. When a client switches from client/server mode to multicast client		1. When the cookie value changes for any reason.
	mode. There is no further need for the key list, since the client
	will not transmit again.
	2. When the poll interval is changed in an association. In this case		2. When a client switches from client/server mode to broadcast client
	the calculated expiration times for the keys become invalid.		mode. There is no further need for the key list, since the client will
			not transmit again.
	3. When a general reset is performed in an association.		3. When the poll interval is changed. In this case the calculated
			expiration times for the keys become invalid.
	4. If a problem is detected when an entry is fetched from the key		4. When a general reset is performed.
	list for an association. This could happen if the key was marked non-
	trusted or timed out, either of which implies a software bug.
	5. When the cryptographic values are refreshed, the key lists for all		5. If a problem is detected when an entry is fetched from the key list.
			This could happen if the key was marked non-trusted or timed out, either
			of which implies a software bug.
			6. When the cryptographic values are refreshed, the key lists for all
	associations are regenerated.		associations are regenerated.
	6. When the client is first synchronized to an authentic source or		7. When the client is first proventicated or the system clock is
	the system clock is stepped, the key lists for all associations are		stepped, the key lists for all associations are regenerated.
	regenerated.
	5 Autokey Protocols		Autokey Protocols
	This section describes the Autokey protocols supporting		This section describes the Autokey protocols supporting
	cryptographically secure server and peer authentication. There are		cryptographically secure server proventication. There are three
	three protocols corresponding to the NTP client/server,		subprotocols, called dances, corresponding to the NTP client/server,
	multicast/manycast and symmetric active/passive modes.		broadcast and symmetric active/passive modes. While Autokey messages are
			piggybacked in NTP packets, the NTP protocol assumes clients poll
			servers at a relatively low rate, such as once per minute, and where
			possible avoids large packets. In particular, it is assumed that a
			request sent at one poll opportunity will normally result in a response
			before the next poll opportunity.
	In the descriptions below, it is assumed that the client has the		It is important to observe that, while the Autokey dances are obtaining
	public key and agreement parameters, where required, for the server.		and validating cryptographic values, the underlying NTP protocol
	These data can be loaded from local files or automatically retrieved		continues to operate. Most packets used during the dances contain
	from the server as described later in this memorandum. Further		signatures, so the values can be believed even before the dance has
	information on generating and managing these files is in Appendix B.		concluded. Since signatures are valid once the certificate has been
			validated during the initial steps of the dance, by the time the Autokey
			values are validated the clock is usually already set. In this way the
			sometimes intricate Autokey dance interactions do not delay the
			accumulation of time values that will eventually set the clock. Each
			autokey dance is designed to be nonintrusive and to require no
			additional packets other than for regular NTP operations. Therefore, the
			phrase "some time later" in the descriptions applies to the next poll
			opportunity.
	The Autokey protocol data unit is the extension field, which contains		The Autokey protocol data unit is the extension field, one or more of
			which can be piggybacked in the NTP packet. An extension field contains
	either a request with optional data or a response with data. To avoid		either a request with optional data or a response with data. To avoid
	deadlocks, any number of responses can be included in a packet, but		deadlocks, any number of responses can be included in a packet, but only
	only one request. Some requests and most responses are protected by		one request. Some requests and most responses are protected by
	timestamped signatures. The signature covers the data, timestamp,		timestamped signatures. The signature covers the data, timestamp and
	which is set valid (nonzero) only if the sender is synchronized to an		filestamp, where applicable. The timestamp is set to the default (zero)
	authentic source. An extension fields are discarded before the		when the sender is not proventicated; otherwise, it is set to the NTP
	signature is verified if a signature timestamp is the same as or		seconds when the signature was generated. The following rules are
	earlier than the last received timestamp of the same type.		designed to detect invalid header or data fields and to deflect clogging
			attacks. Each extension field is validated in the following order and
			discarded if:
	An extension field is also discarded if a protocol or procedure error		1. The request or response code is invalid or the data field has
	occurs or the required cryptographic data are incomplete or		incorrect length.
	unavailable or the field values are inconsistent with these data.
	Otherwise and in general, a response is generated for every request,
	even if the requestor is not synchronized to an authentic source.
	However, some responses may have truncated data fields under certain
	conditions, although the signatures are always present and
	verifiable.
	5.1 Client/Server Modes (3/4)		2. The signature field is either missing or has incorrect length.
	In client/server modes the server keeps no state variables specific		3. The public key is missing or has incorrect length.
	to each of possibly very many clients and mobilizes no associations.
	The server regenerates a cookie for each packet received from the		4. In the case of the agreement algorithm, the agreement parameterss are
	client. For this purpose, the cookie is hashed from the IP addresses		missing or have incorrect lengths.
	and private value with the key ID field set to zero, as described
	previously. Both the client and server use the cookie to generate the		5. The signature timestamp is earlier than the last received timestamp
	autokey which validates each packet received. To further strengthen		of the same type or the two timestamps are equal and the proventic bit
	the validation process, the client selects a new key ID for every		is set..
	packet and verifies that it matches the key ID in the server response
	to that packet.		6. Where applicable, the filestamp is earlier than the last received
			filiestamp of the same type.
			Only if the extension field passes all the above tests is the signature
			verified using PKI algorithms. Otherwise and in general, a response is
			generated for every request, even if the requestor is not proventicated.
			However, some responses may have truncated data or signature fields
			under certain conditions. If these fields are present and have correct
			length, signatures are present and verifiable.
			In the Autokey protocol every transmitted packet is associated with an
			autokey previously computed and stored in the key list. When the last
			entry in the list is used, a new list is constructed as described above.
			This requires knowledge of the cookie value. If for some reason the
			cookie value is changed, the remaining entries in the key list are
			purged and a new one constructed. However, if an extension field is
			present, the current autokey is discarded and the autokey reconstructed
			using a cookie value of zero.
			A timestamp-based agreement protocol is used to manage the distribution
			of the certificate, agreement parameters and leapseconds table. The
			association ID request and response messages include the certificate,
			agreement and leapseconds bits from the system status word. one or more
			of these bits are set when the associated data are present, either
			loaded from local files or retrieved from another server at some earlier
			time. If any of these bits are set in the association ID response to a
			client in client/server mode or a peer in symmetric mode, the data are
			requested from the server or peer and, once obtained, the bits are
			reset. However, the response data are stored only if more recent than
			the data already stored.
			In the descriptions below, it is assumed that the client and server have
			loaded their own private key and public key, as well as certificate,
			agreement parameters and leapseconds table, where available. Public keys
			for other servers, as well as the agreement parameters and leapseconds
			table, can be loaded from local files or retrieved from any server.
			Further information on generating and managing these files is in
			Appendix B.
			Preliminaries
			The first thing the server needs to do is obtain the system status word,
			which reveals which cryptographic values the server is prepared to
			offer, and then the public key and certificate. These steps are
			independent of which mode the server is operating in - client/server,
			broadcast or symmetric modes.
			The following pseudo-code describes the client state machine operations.
			Note that the packet can one request and one or more responses. The
			machine requires the association ID, public key and optional
			certificate, in that order. While not further specified in this
			memorandum, an optional parameter request message can be used to
			negotiate algorithm identifiers, parameters and alternate identification
			values. Note that the association ID response message also contains the
			system status word, which contains the certificate bit.
			if (response_pending)
			send_response;
			if (!parameters)
			request_parameters;
			if (!association_ID)
			request_association_ID;
			else if (!public_key)
			request_public_key;
			else if (certificate_bit)
			request_certificate;
			The following diagram shows the preliminary protocol dance. In this and
			following diagrams the NTP packet type is shown above the arrow and the
			extension field(s) message type shown below. Note that in the
			client/server mode the server responds immediately to the request, but
			in the symmetric modes the response may be delayed for a period up to
			the current poll interval. The following cryptographic values are
			instantiated by the dance:
			public key server public key
			host name server host name
			CA name certificate authority host name (optional)
			filestamp generation time of public key file
			secure bit set when the public key is stored and validated
			server client
			| |
			| NTP client |
			1 |<-----------------| mobilize client association; generate key list
			| assoc ID req | with default cookie; send status word
			| |
			| NTP server |
			2 |----------------->| store status word
			| assoc ID rsp |
			| |
			| NTP client |
			3 |<-----------------| request public key and host name
			| key/name req |
			| |
			| NTP server |
			4 |----------------->| store public key, host name, filestamp and
			| key/name rsp | timestamp
			| ... |
			| |
			| NTP client |
			5 |<-----------------| request certificate
			| certif req |
			| |
			| NTP server |
			6 |----------------->| store certificate; verify credentials; set
			| certif rsp | secure bit
			| ... |
			The dance begins when the client (or symmetric-active peer) on the right
			mobilizes an association, generates a key list using the default cookie
			and sends an association ID request message (1) to the server (or
			symmetric-passive peer) on the left. The server responds with an
			association ID response message (2) including the server association ID
			and status word. To protect against a clogging attack, the transmit
			timestamp in the NTP header in the request must be identical to the
			originate timestamp in the response. The client retransmits request (1)
			at every poll opportunity until receiving a valid response (2) or
			association timeout.
			Some time later the client sends a public key/host name request (3) to
			the server. The server responds with the requested data and associated
			timestamp and filestamp (4). The client checks the timestamp and
			filestamp, verifies the signature and initializes the public key and
			host name. If the certificate bit in the status word is zero, indicating
			the server is not prepared to send one, and if the client concurs, the
			secure bit is set at this time and the certificate exchange is bypassed.
			The client retransmits request (3) at every poll opportunity until
			receiving a valid response (4) or association timeout.
			The public key/host name message can be interpreted as a poor-man's
			certificate, since it is signed and timestamped. However, strong
			security requires a CA sign the host name and public key values and
			establish a period of validity for the signature. As an optional
			feature, the client sends a certificate request (5) to the server. The
			server responds with the requested data and assciated timestamp and
			filestamp (6). The response is signed by the CA's public key, so a
			further step may be necessary to obtain the CA's certificate, which
			contains its public key. The details for these additional steps are for
			further study.
			Since (4) is the first signed message received, the timestamp and
			filestamp have only marginal utility, but do serve to avoid messages
			from unsynchronized servers and deflect replays. The interesting
			question is whether to provide automatic update when the server makes a
			new key generation, since the new generation would have a later
			filestamp and instantly deprecate all cryptographic values with earlier
			timestamps. This brings up the question of a distributed greeting
			protocol, which may be a topic for future study. Meanwhile, the
			reference implementation accepts only the first message received and
			discards all others.
			When the secure bit is set, data in packets with signatures are valid
			and the NTP protocol continues in parallel with the Autokey protocol.
			Client/Server Modes (3/4)
			In client/server modes the server keeps no state variables specific to
			each of possibly very many clients and mobilizes no associations. The
			server regenerates a cookie for each packet received from the client.
			For this purpose, the server hashes the cookie from the IP addresses and
			private value with the key ID field set to zero, as described
			previously, then provides it to the client. Both the client and server
			use the cookie to generate the autokey which validates each packet
			received. To further strengthen the validation process, the client
			selects a new key ID for every packet and verifies that it matches the
			key ID in the server response to that packet.
			Before proceeding to the full protocol description, it should be noted
			that in the case of lightweight SNTP protocol associations, it is not
			necessary to proceed beyond the preliminary protocol defined above. Most
			if not all SNTP implementations send only a single client-mode packet
			and expect only a single NTP server-mode packet in return. Since the
			Autokey protocol is piggybacked in the NTP packet, the clock can be set
			and the server authenticated with a single packet exchange if a
			certificate is not required and in two exchanges if it is. Details of
			this simplified protocol remain to be determined.
			The following pseudo-code describes the client state machine operations.
			The machine requires the association ID, public key, optional
			certificate, cookie, autokey values and leapseconds table in that order,
			but the autokey values are required only if broadcast client mode.
			if (response_pending)
			send_response;
			if (!cookie)
			request_cookie;
			else if (!autokey_values && broadcast_client))
			request_autokey_values;
			else if (!leapseconds_table)
			request_leapseconds_table;
	The following diagram shows the protocol dance in client/server mode.		The following diagram shows the protocol dance in client/server mode.
	In this and following diagrams the NTP packet type is shown above the		The following cryptographic values are instantiated by the dance:
	arrow and the extension field(s) message type shown below. There are
	three cryptographic values instantiated by the dance: the cookie,		public key server public key
	signature timestamp and authentic bit.		host name server host name
			filestamp generation time of public key file
			timestamp signature time of public key/host name values
			cookie cookie determined by the server for this client
			timestamp signature time of cookie
			proventic bit set when client clock is synchronized to source
	server client		server client
	| |		| |
	| NTP client |		| NTP client |
	1 |<-----------------| mobilize association; generate key list;		7 |<-----------------| request cookie
	| cookie req | DNS lookup for canonical name, certificate		| cookie req |
	| | and public key		| |
	| NTP server |		| NTP server |
	2 |----------------->| store cookie; verify server credentials		8 |----------------->| store cookie and timestamp; set proventic bit;
	| cookie rsp |		| cookie rsp |
	| ... |		| ... |
	| |		| |
	| NTP client |		| NTP client |
	3 |<-----------------|		9 |<-----------------| regenerate key list with server cookie
	| |		| |
	| NTP server |		| NTP server |
	4 |----------------->|		10 |----------------->|
	| |		| |
	| continue |		| continue |
	= client/server =		= client/server =
	The dance begins when the client on the right sends a packet (1)
	including a cookie request to the server on the left. The server		The dance begins when the client on the right mobilizes an association
	immediately responds with the cookie, signature and timestamp. Upon		and validates the public key as in the preliminary dance above. Some
	arrival of this packet (2), the client checks the timestamp, verifies		time later the client sends a cookie request (7). The server immediately
	the signature and, if successful, initializes the cookie and		responds with the cookie and timestamp (8). The client checks the
	signature timestamp and sets the authentic bit. The client will		timestamp, verifies the signature and initializes the cookie and cookie
	retransmit packet (1) until receiving a valid timestamp and verified		timestamp, then sets the proventic bit. Since the cookie has changed,
	signature (2) or until association timeout.		the client regenerates the key list with this cookie when the next
			packet is sent. The client retransmits request (7) at every poll
			opportunity until receiving a valid response (8) or association timeout.
	After successful verification, there is no further need for extension		After successful verification, there is no further need for extension
	fields, unless an error occurs or the server generates a new private		fields, unless an error occurs or the server generates a new private
	value. When this happens, the server fails to authenticate the packet		value. When this happens, the server fails to authenticate packet (9)
	(3) and, following the original NTP protocol, responds with a NAK		and, following the original NTP protocol, responds with a NAK packet
	packet (4), which the client ignores. Eventually, a general reset		(10), which the client ignores. Eventually, an association timeout and
	occurs and the dance restarts from the beginning.		general reset occurs and the dance restarts from the beginning. Of
			course, the NAK client could interpret the NAK message to restart the
			protocol immediately and avoid the timeout. However, this invites the
			opportunity for an intruder to destabilize the state machine with
			spurious NAK messages.
	5.2 Multicast/Manycast Mode (5)		Broadcast Mode (5)
	In multicast mode, packets are always sent with an extension field.		In broadcast mode, packets are always sent with an extension field.
	Since the autokey values for these packets use a well known cookie		Since the autokey values for these packets use a well known default
	(zero), they can in principle be remanufactured with a new MAC		cookie (zero), they can in principle be remanufactured with a new MAC
	acceptable to the receiver; however, the key list provides the		acceptable to the receiver; however, the key list provides the
	authentication function as described earlier. The multicast server		authentication function as described earlier. The broadcast server keeps
	keeps no state variables specific to each of possibly very many		no state variables specific to each of possibly very many clients and
	clients and mobilizes no associations for them. The server on the		mobilizes no associations for them.
	left in the diagram below sends packets that are received by each of
	a possibly large number of clients, one of which is shown on the
	right. Ordinarily, clients do not send packets to the server, except
	to calibrate the propagation delay and to obtain cryptographic values
	such as the cookie and autokey values.
	The following diagram shows the protocol dance in multicast mode.		The following pseudo-code describes the broadcast server state machine
	There are four cryptographic values instantiated by the dance: the		operations. Each broadcast packet includes one response message
	signature timestamp, cookie, autokey values and authentic bit.		containing either the signed autokey values, if the first autokey on the
			key list, or the association ID and status word otherwise. Note however,
			when a broadcast client first comes up, the state machine also responds
			to client requests as in client/server mode without affecting the
			broadcast packets. Note that the association ID request and response
			messages also contain the system status word.
			if (new_list)
			send_autokey_values;
			else
			send_association_ID;
			The server on the left in the diagram below sends packets that are
			received by each of a possibly large number of clients, one of which is
			shown on the right. Ordinarily, clients do not send packets to the
			server, except to calibrate the propagation delay and to obtain
			cryptographic values such as the cookie and autokey values. The
			following diagram shows the protocol dance in broadcast mode. The
			following cryptographic values are instantiated by the dance:
			public key server public key
			host name server host name
			filestamp generation time of public key file
			timestamp signature time of public key/host name values
			cookie cookie determined by the server for this client
			timestamp signature time of cookie
			autokey values initial key ID, initial autokey
			timestamp signature time of autokey values
			proventic bit set when client clock is synchronized to source
	server client		server client
	| |		| |
	| NTP multicast |		| NTP broadcast |
	1 |----------------->| mobilize association; generate key list;		1 |----------------->| mobilize broadcast client association; set
	| assoc ID rsp | reverse DNS lookup for canonical name,		| assoc ID rsp | initially to operate in client/server mode
	| ... | certificate and public key		| |
			| ... | continue as in preliminary protocol above
	| |		| |
	| NTP client |		| NTP client |
	2 |<-----------------|		7 |<-----------------| request cookie
	| cookie req |		| cookie req |
	| |		| |
	| NTP server |		| NTP server |
	3 |----------------->| store cookie; verify server credentials		8 |----------------->| store cookie and timestamp
	| cookie rsp |		| cookie rsp |
	| ... |		| ... |
	| |		| |
	| NTP client |		| NTP client |
	4 |<-----------------|		9 |<-----------------| regenerate key list with server cookie
	| autokey req |		| autokey req |
	| |		| |
	| NTP server |		| NTP server |
	5 |----------------->| store autokey		10 |----------------->| store autokey values and timestamp; set
	| autokey rsp |		| autokey rsp | proventic bit
	| ... |		| ... |
	| |		| |
	| NTP client |		| NTP client |
	|<-----------------|		|<-----------------| continue to accumulate time values
	| |		| |
	| NTP server |		| NTP server |
	|----------------->|		|----------------->|
	| |		| |
	| continue |		| continue |
	= volley =		= volley =
	| |		| |
	| NTP client |		| NTP client |
	|<-----------------|		|<-----------------|
	| |		| |
	| NTP server |		| NTP server |
	|----------------->| initialize delay estimate; discard cookie		|----------------->| set clock and propagation estimate; discard
	| | and remaining keys; switch to multicast		| | remaining keys; switch to broadcast client mode
	| | client mode
	| continue |		| continue |
	= multicast =		= broadcast =
	| |		| |
	| NTP multicast |		| NTP broadcast |
	|----------------->| server rolls new key list; client refreshes		|----------------->| server rolls new key list; client refreshes
	| autokey rsp | autokey		| autokey rsp | autokey values
	| signature |		| |
	= =		= =
	The server sends multicast packets continuously at intervals of about		The server sends broadcast packets (1) continuously at intervals of
	one minute (1) using the key list and regenerating the list as		about one minute using the key list and regenerating the list as
	required. The first packet sent after regenerating the list includes		required. The first packet sent after regenerating the list includes the
	an extension field containing the autokey values and signature; other		autokey values and signature; other packets include only the association
	packets include an extension field containing only the association		ID and status word.
	ID.
	Upon arrival of the first packet (1), the multicast client mobilizes		The dance begins when the client on the right receives a broadcast
	an association and loads the canonical name and public key as		message (1). It mobilizes a broadcast client association set initially
	described above. Alternately, it queries the DNS and loads the		to operate in client/server mode. It then continues to operate as in the
	canonical name, certificate and server public key.		prelimiary protocol to obtain and validate the public key and host name
			values. However, the client does not initiate the dance until some time
			later (to avoid implosion at the server). However, in addition to the
			status word, the association ID response includes the association ID of
			the server, so the correct association, if more than one, can be
			identified.
	Some time later the client generates a key list and sends a packet		Some time later the client sends a cookie request (7). The server
	(2) requesting the cookie as in client/server mode. The server		immediately responds with the requested value (8). The client checks the
	immediately responds (3) with the cookie, signature and timestamp.		timestamp, verifies the signature and initializes the cookie and cookie
	The client checks the timestamp, verifies the signature and, if		timestamp. Since the cookie has changed, the client regenerates the key
	successful, initializes the cookie and signature timestamp. The		list with this cookie when the next packet is sent. The client
	client retransmits packet (2) until receiving a valid timestamp and		retransmits request (7) at every poll opportunity until receiving a
	verified signature (3) or until a general reset occurs.		valid response (8) or association timeout.
	If an autokey response happens to be in one of the server packets (1,		If an autokey response happens to be in one of the server packets (1),
	3), the client can switch to multicast client mode and send no		the client has stored the autokey values and autokey timestamp, so can
	further packets. Otherwise, some time later the client sends a packet		switch immediately to broadcast client mode and send no further packets.
	(4) requesting the autokey values. The server immediately responds		Otherwise, some time later the client sends an autokey request (9). The
	(5) with the values. The client checks the timestamp, verifies the		server immediately responds with the values (10). The client checks the
	signature and, if successful, initializes the autokey values and		timestamp, verifies the signature and initializes the autokey values and
	signature timestamp and sets the authentic bit. The client		autokey timestamp and sets the proventic bit. The client retransmits
	retransmits packet (4) until receiving a valid timestamp and verified		packet (9) until receiving a valid response (10) or association timeout.
	signature (5) or until a general reset occurs.
	After successful verification, there is no further need for extension		After successful verification, there is no further need for extension
	fields, unless the server regenerates the cookie or the server		fields and the client can switch to broadcast client mode and send no
	regenerates the key list and the Autokey response message happens to		additional packets. However, it is the usual practice to send additional
	be lost. When this happens, the server fails to authenticate the		client/server packets in order for the client mitigation algorithms to
	packets (1). Eventually, a general reset occurs and the dance		refine the clock offset/delay estimates. When a sufficient number of
	restarts from the beginning. However, it is the usual practice to		estimates are available, the client discards the cookie and remaining
	send additional client/server packets in order for the client		keys on the key list, switches to broadcast client mode, calculates the
	mitigation algorithms to refine the clock offset/delay estimates.		propagation delay and sets the clock.
	When a sufficient number of estimates have been accumulated, the
	client discards the cookie and remaining keys on the key list,
	switches to multicast client mode and sets the clock.
	5.3 Symmetric Active/Passive Mode (1/2)		When the server regenerates the key list, it sends an autokey response
			in the first packet, which allows the clients to validate it and reset
			the autokey values. Unless this packet happens to be lost, the clients
			can continue with no further interaction with the server. Otherwise, the
			client fails to authenticate the packets (1). Eventually, an association
			timeout and general reset occurs and the dance restarts from the
			beginning.
			Symmetric Active/Passive Mode (1/2)
	In symmetric modes there is no explicit client/server relationship,		In symmetric modes there is no explicit client/server relationship,
	since each peer in the relationship can operate as a server with the		since each peer in the relationship can operate as a server with the
	other operating as a client. The particular choice of server depends		other operating as a client. Which peer acts as the server depends on
	on which peer has the smallest root synchronization distance to its		which peer has the smallest root synchronization distance to its
	ultimate reference source, and the choice may change from time to		ultimate reference source, and the choice may change from time to time.
	time.		This requirement results in a quite complex interaction between the
			peers, especially when considering the many possibilities of failure and
			recovery.
	There are two protocol scenarios involving symmetric modes. The		There are two protocol scenarios involving symmetric modes. The simplest
	simplest scenario is where both peers have configured associations		scenario is where both peers have configured associations that operate
	that operate continuously in symmetric-active mode and cryptographic		continuously in symmetric active mode and cryptographic values such as
	values such as host name and public key can be configured in advance.		the public key/host name, certificate, agreement parameters and public
	The other scenario is when one peer operates with a configured		value can be configured in advance. A more interesting scenario is when
	association and begins operation with another peer without a		a symmetric active peer with a configured association begins operation
	configured association and begins operation in symmetric-passive		with a symmetric-passive peer initially without such an association.
	mode.
	The following diagram shows the protocol dance in symmetric-		The following pseudo-code describes the symmetric state machine
	active/passive mode. The exchange is similar in the symmetric-		operations. Note that the packet can contain one request and one or two
	active/active mode, although the order can change depending on which		responses. The machine requires the association ID, public key,
	peer starts the dance. There are four cryptographic values		certificate, agreement parameters, agreement public value, autokey
	instantiated by the dance: the signature timestamp, cookie, autokey		values and leapseconds table in that order. There is a provision to send
	values and authentic bit.		the current autokey values when the peer has not requested them. This
			happens when a peer first proventicates and recomputes the key list
			using the agreed cookie.
	active passive		if (response_pending)
			send_response;
			if (!agreement_parameters)
			request_agreement_parameters;
			else if (!agreement)
			send_agreement;
			else if (!autokey_values)
			request_autokey_values;
			else if (!new_list)
			send_autokey_values;
			else if (!leapseconds_table)
			request_leapseconds_table;
			The following diagrams show the protocol dance in symmetric
			active/passive mode. The dance in symmetric active/active mode is much
			simpler and similar to two independent client/server modes, one for each
			direction, but with the cookie requests replaced by an agreement
			algorithm. Note that in the following the NTP client header is replaced
			by the NTP symmetric active header and the NTP server header is replaced
			by the NTP symmetric passive header. The following cryptographic values
			are instantiated by each peer in the dance:
			public key server public key
			host name server host name
			filestamp generation time of public key file
			timestamp signature time of public key/host name values
			cookie cookie determined by the agreement algorithm
			timestamp signature time of cookie
			autokey values initial key ID, initial autokey
			timestamp signature time of autokey values
			proventic bit set when client clock is synchronized to source
			passive active
	| |		| |
	| NTP active |		| NTP active |
	1 |----------------->| mobilize association; query DNS for		1 |<-----------------| mobilize symmetric active association; generate
	| public rsp | canonical name, certificate and public key;		| assocID req | key list with default cookie; send status word
	| | verify public signature, compute and		| |
	| public req | initialize agreed key		| ... | continue as in preliminary protocol above
			| |
			| NTP passive |
			2 |----------------->| store status word
			| assoc ID rsp |
			| |
			| NTP active |
			1 |<-----------------| generate key list with default cookie; request
			| key/name req | passive key/name
	| ... |		| ... |
	| |		| |
	| NTP passive |		| NTP passive |
	2 |<-----------------|		2 |----------------->| verify passive credentials
	| public rsp |		| key/name rsp |
			| key/name req |
			| ... |
			| |
			| NTP active |
			3 |<-----------------| send active key/name; request agreement
			| key/name rsp | parameters
			| param req |
			| ... |
			| |
			| NTP passive |
			4 |----------------->| store agreement parameters; and timestamp; set
			| param rsp | proventic bit
			| agree rsp |
			| ... |
			| |
			| NTP active |
			3 |<-----------------| send active key/name; request agreement
			| key/name rsp | parameters
			| param req |
			| ... |
			| |
			| NTP passive |
			4 |----------------->| store autokey values and timestamp; set
			| key/name req | proventic bit
			| autokey rsp |
			| ... |
			| |
			| NTP active |
			5 |<-----------------| continue to accumulate time values
			| key/name rsp |
			| |
			= continue =
			| |
			| NTP passive |
			6 |----------------->| set clock
			| key/name req |
			| |
			| continue below |
			= =
			The dance begins when the active peer on the right generates a key list
			with default cookie and timestamp and sends a public key/host name
			request to the passive peer on the left (1). The passive peer checks its
			access control list and (optionally) queries the DNS using the server IP
			address to obtain related cryptographic values. If successful, the peer
			mobilizes an association in symmetric passive mode, but takes no further
			action until the next poll interval, as required by the NTP protocol.
			From this point the passive peer responds to requests, but otherwise
			ignores all time values until the active peer has set its clock and can
			provide valid timestamps.
			Some time later the passive peer generates a key list with default
			cookie and timestamp and sends its public key/host name values along
			with a request for the public key/host name values of the active peer
			(2). Subsequently, the active peer sends these values, but they are
			ignored since the timestamps are invalid. Meanwhile, the active peer
			checks the timestamp, verifies the signature and initializes the public
			key/host name values, filestamp and timestamp. The active peer
			retransmits request (1) at every poll opportunity until receiving a
			valid response (2) or until association timeout.
			Some time later the active peer sends the requested public key/host name
			values along with an autokey request (3). The passive peer retransmits
			request (2) at every poll opportunity until receiving a valid timestamp
			and verified signature or until association timeout. Since the cookies
			for each peer already have a common value and the active peer is
			unsynchronized, it is pointless to run the agreement algorithm.
			Some time later the passive peer sends the requested autokey values (4).
			The active peer checks the timestamp, verifies the signature and
			initializes the autokey values and timestamp and sets the proventic bit.
			At this point the active peer has authenticated the passive peer, but
			may not have accumulated sufficient time values to set the clock and
			provide valid timestamps. Operation continues in rounds where the
			passive peer requests the public key/host name values and the active
			peer returns them, but the passive peer ignores them. Eventually, the
			active peer accumulates sufficient time values to set the clock. While
			the cookie has not changed, the timestamp has, so the key list is
			regenerated with the default key (strictly speaking, only the signature
			needs to be recomputed). The active peer is now proventicated, but the
			passive peer has not yet authenticated the active peer.
			Some understanding of the tricky actions to follow can be gained from
			the observation that, up until this point every message received by the
			active peer had a signed response field, so that the cookie value is the
			default. However, at this point the active peer has all the
			cryptographic means at hand and does not need to request anything
			further from the passive peer. Thus, the passive peer sends nothing but
			requests and these are not signed or timestamped. Since the cryptograhic
			security relies entirely on the autokey test, it is important that both
			peers generate key lists with the same cookie.
			The steps now taken are shown below with the active peer on the left and
			the passive peer on the right.
			active passive
			| |
			| NTP active |
			1 |----------------->| validate active peer, compute agreed key,
			| key/name rsp | regenerate key list with peer key
			| public req |
			| |
			| NTP passive |
			2 |<-----------------| active computes agreed key, regenerates key
			| public rsp | list with agreed key
	| autokey req |		| autokey req |
	| ... |		| ... |
	| |		| |
	| NTP active |		| NTP active |
	3 |----------------->| verify autokey signature, initialize		3 |----------------->| set authentic
	| autokey rsp | autokey key; sign public values		| autokey rsp |
	| autokey req |		| autokey req |
	| ... |		| ... |
	| |		| |
	| NTP passive |		| NTP passive |
	4 |<-----------------|		4 |<-----------------|
	| autokey rsp |		| autokey rsp |
	| ... |		| ... |
	| |		| |
	| NTP active |		| NTP active |
	|----------------->| regular operation		5 |----------------->| regular operation (no extension fields)
	| ... |		| ... |
	| |		| |
	| NTP passive |		| NTP passive |
	|<-----------------|		6 |<-----------------|
	| |		| |
	| continue |		| continue |
	= active/passive =		= active/passive =
	The dance begins when the active peer on the left in the diagram		The agreement parameters must have been previously obtained by at least
	sends a packet (1) to the passive peer on the right. Before sending		one of the peers, either directly from a file or indirectly from another
	the first packet, the active peer generates a key list using the		server running the Autokey protocol. A peer needing the parameters sends
	default key (zero) and initializes the autokey values and signature		an agreement parameters request to the other peer and that peer responds
	along with the public agreement value and signature.		with the requested data. This exchange, along with the leapseconds table
			exchange, is similar to the public key/host name exchange, but not shown
			here.
	The first packet from the active peer includes its public value and		Once the proventic bit is set, the next message sent by the active peer
	signature along with a request for the public value of the passive		contains the public key/host name requested by the passive peer, but now
	peer. Upon arrival of this packet, the passive peer mobilizes an		with valid timestamp, plus a public value request containing the active
	association and loads the canonical name and public key as described		peer public value (1). The passive peer checks the public key/host name
	above. Alternately, it queries the DNS and loads the canonical name,		filestamp and timestamp, verifies the signature and initializes the
	certificate and public key of the active peer. The passive peer		values. Optionally, it checks its access control list and queries the
	checks the timestamp, verifies the signature and, if successful,		DNS using the server IP address to obtain related cryptographic values.
	executes the agreements algorithm and initializes the cookie and		Conceivably, the active peer could be found bogus at this time; what to
	signature timestamp. As the cookie affects the autokey values, the		do in this case is for further study.
	key list is regenerated with the cookie. The active peer retransmits
	packet (1) until receiving a valid public value (2) or until a
	general reset occurs.
	Some time later the passive peer sends a packet (2) to the active		The passive peer next checks the public value request timestamp,
	peer including its public value and signature along with a request		verifies the signature and runs the agreement algorithm to construct the
	for the autokey values of the active peer. Upon arrival of this		shared cookie. Since the cookie has changed, the peer regenerates the
	packet, the active peer checks the timestamp, verifies the signature		key list with this cookie when the next packet is sent.
	and, if successful, executes the agreements algorithm and initializes
	the cookie and signature timestamp. As the cookie affects the autokey
	values, the key list is regenerated with the cookie. The passive peer
	retransmits packet (2) until receiving a valid autokey values (3) or
	until a general reset occurs.
	Some time later the active peer sends a packet (3) to the passive		Some time later the passive peer sends a public value response including
	peer including its autokey values and signature along with a request		its own public value together with an autokey request (2). The active
	for the autokey values of the passive peer. Upon arrival of this		peer checks the timestamp, verifies the signature and runs the agreement
	packet, the passive peer checks the timestamp, verifies the signature		algorithm to construct the shared cookie. Since the cookie has changed,
	and, if successful, initializes the autokey values and sets its		the peer regenerates the key list with this cookie when the next packet
	authentic bit. The active peer retransmits packet (3) until receiving		is sent. The active peer retransmits the public value request (only) (1)
	a valid autokey values (4) or until a general reset occurs.		at every poll opportunity until receiving a valid response (2) or
			association timeout.
	Some time later the passive peer sends a packet (4) to the active		Some time later the active peer sends its autokey values as requested
	peer including its autokey values and signature. Upon arrival of this		together with an autokey request (3). The passive peer checks the
	packet, the active peer checks the timestamp, verifies the signature		timestamp, verifies the signature, initializes the autokey values and
	and, if successful, initializes the autokey values and sets the		sets its proventic bit. The passive peer retransmits request (2) at
	authentic bit.		every poll opportunity until receiving a valid response (3) or
			association timeout.
	After successful verification, there is no further need for extension		Some time later the passive peer sends its autokey values as requested
	fields, unless an error occurs or one of the peers generates new		(4). The active peer checks the timestamp, verifies the signature, and
	public values. The protocol requires that, if a peer receives a		initializes the autokey values (the proventic bit is already set). The
	public value resulting in a different cookie, it must send its own		active retransmits the autokey request (only) (3) until receiving a
	public value. Since the autokey values are included in an extension		valid response (4) or association timeout.
	field when a new key list is generated, there is ordinarily no need
	to request these values, unless one or the other peer restarts the
	protocol or the packet containing the autokey values is lost. In any
	case, the request will be retransmitted at intervals until a general
	reset occurs.
	6. Additional Protocols		At this point both peers have completed the Autokey dance and each is
			authenticated to the other. However, note that the NTP rules require a
			peer operating at a lower stratum disregards time values from a hither
			stratum peer; so, while the peers continue to exchange time values, the
			values will not be used unless the passive server for some reason loses
			its synchronization source.
	While not mentioned in the above protocol descriptions, there are		After successful authentication, there is no further need for extension
	provisions to negotiate the algorithms and algorithm parameters,		fields, unless an error occurs or one of the peers generates new public
	retrieve the public key and host name, and retrieve the agreement		values. The protocol requires that, if a peer receives a public value
	parameters and ancillary data using the defined requests summarized		resulting in a different cookie, it must send its own public value.
	in Appendix A. Ordinarily, a client or peer requests the public key		Since the autokey values are included in an extension field when a new
	and host name in the first message from an association to a server or		key list is generated, there is ordinarily no need to request these
	peer. The response includes the filestamp and is signed by the server		values, unless one or the other peer restarts the protocol or the packet
	using its private key. The signature and filestamp is useful to		containing the autokey values is lost. Eventually, an association
	confirm the correct key generation and to verify correct procedure.		timeout and general reset occurs and the dance restarts from the
			beginning.
	Each association requiring public key authentication cannot proceed		Security Analysis
	until the response has been received.
	The NIST provides a table showing the epoch for all occasions of leap		This section discusses the most obvious security vulnerabilities in the
	second insertions since 1972. The table is maintained in a file		various modes and phases of operation. Throughout the discussion the
	called pub/leap-seconds and available for anonymous FTP download.		cryptographic algorithms themselves are assumed secure; that is, a
	While not strictly a security function, the table can be retrieved		successful brute force attack on the algorithms or public/private keys
	from an NTP server using the Autokey protocol if the feature is		or agreement values is unlikely. However, vulnerabilities remain in the
	enabled. If enabled and the leap table is not available, a request is		way the actual cryptographic data, including the cookie and autokey
	included in the next Autokey message. The response includes the		values, are computed and used.
	original filestamp generated by the NIST and is signed and
	timestamped. Note that the table will be requested by all
	associations, either configured or not; but, none of the associations
	can proceed until one of them has received the response. After this,
	the table can be provided on request to other clients and servers.
	If any associations are operating in symmetric modes, the agreement		While the protocol has not been subjected to a formal analysis, a few
	parameters are required to complete the protocol. If the parameters		preliminary observations are warranted. The protocol cannot loop forever
	are needed and not currently available, they are requested in the		in any state, since the association timeout and general reset insure
	next message. The response includes the original filestamp and is		that the association variables will eventually be purged and the
	signed as before. Note that the parameters will be requested by all		protocol will start from the beginning. A general reset is performed on
	associations needing them, either configured or not; but, none of the		all associations when the clock is first set and when it is stepped
	associations can proceed until one of them has received the response.		after that. This purges all cryptographic values and time values
	After this, the parameters can be provided on request to other		dependent on unproventicated sources.
	clients and servers.
	7 Security Analysis		The first exchange in all protocol modes involves an association ID
			request and response cycle. Bits in the server status word indicate
			whether the server has the agreement paramters and/or leapseconds table.
			The association ID messages are not protected by a signature, so
			presumably an intruder can manufacture fake bits causing a client
			livelock or deadlock condition. To protect against this vulnerability,
			the transmit timestamp of the request is matched against the originate
			timestamp of the response. The response is accepted only if the two
			values match. An intruder is unlikely to predict the transmit timestamp,
			which in this case is an effective nonce.
	This section discusses the most obvious security vulnerabilities in		Once the clock is set, and except for the special cases summarized
	the various modes and phases of operation. Throughout the discussion		below, no old or duplicate values will be accepted in any state and an
	the cryptographic algorithms themselves are assumed secure; that is,		intruder cannot induce a clogging attack, since the MAC, autokey and
	a successful brute force attack on the algorithms or public/private		timestamp tests will discard packets before a clogging vulnerability is
	keys or agreement parameters is unlikely. However, vulnerabilities		exposed. While significant vulnerabilities exist during the initial
	remain in the way the actual cryptographic data, including the cookie		protocol states while the necessary values are being obtained, the most
	and autokey values, are computed and used.		an intruder can do is prevent the protocol dance from completing. If it
			does complete, it must complete correctly.
			The cryptographic values are always obtained in the same order and in
			the same order as the dependency relationships between them. No
			cryptographic variables or time variables are instantiated unless the
			server is proventic and proventicated. The public key and host name must
			be obtained first and no other messages are accepted until they have
			been obtained. The cookie must be obtained before the autokey values
			that depend on them, etc. Finally, in symmetric modes, both peers obtain
			cryptographic values in the same order, so deadlock cannot occur.
	Some observations on the particular engineering constraints of the		Some observations on the particular engineering constraints of the
	Autokey protocol are in order. First, the number of bits in some		Autokey protocol are in order. First, the number of bits in some
	cryptographic values are considerably smaller than would ordinarily		cryptographic values are considerably smaller than would ordinarily be
	be expected for strong cryptography. One of the reasons for this is		expected for strong cryptography. One of the reasons for this is the
	the need for compatibility with previous NTP versions; another is the		need for compatibility with previous NTP versions; another is the need
	need for small and constant latencies and minimal processing		for small and constant latencies and minimal processing requirements.
	requirements. Therefore, what the scheme gives up on the strength of		Therefore, what the scheme gives up on the strength of these values must
	these values must be regained by agility in the rate of change of the		be regained by agility in the rate of change of the cryptographic basis
	cryptographic basis values. Thus, autokeys are used only once and		values. Thus, autokeys are used only once and basis values are
	basis values are regenerated frequently. However, in most cases even		regenerated frequently. However, in most cases even a successful
	a successfulcryptanalysis of these values compromises only a		cryptanalysis of these values compromises only a particular
	particular client/server association and does not represent a danger		client/server association and does not represent a danger to the general
	to the general population.		population.
	There are three tiers of defense against hostile intruder		There are three tiers of defense against hostile intruder interference.
	interference. The first is the message authentication code (MAC)		The first is the message authentication code (MAC) based on a keyed
	based on a keyed message digest or autokey generated as the hash of		message digest or autokey generated as the hash of the IP address
	the IP address fields, key ID field and a special cookie, which can		fields, key ID field and a special cookie, which can be public or the
	be public or the result of an agreement algorithm. If the message		result of an agreement algorithm. If the message digest computed by the
	digest computed by the client does not match the value in the MAC,		client does not match the value in the MAC, either the autokey used a
	either the autokey used a different cookie than the server or the		different cookie than the server or the packet was modified by an
	packet was modified by an intruder. Packets that fail this test are		intruder. Packets that fail this test are discarded without further
	discarded without further processing; in particular, without spending		processing; in particular, without spending processor cycles on
	processor cycles on expensive public-key algorithms.		expensive public-key algorithms.
	The second tier of defense involves the key list, which is generated		The second tier of defense involves the key list, which is generated as
	as a repeated hash of autokeys and used in the reverse order. While		a repeated hash of autokeys and used in the reverse order. While any
	any receiver can authenticate a message by hashing to match a		receiver can authenticate a message by hashing to match a previous key
	previous key ID, as a practical matter an intruder cannot predict the		ID, as a practical matter an intruder cannot predict the next key ID and
	next key ID and thus cannot spoof a packet acceptable to the client.		thus cannot spoof a packet acceptable to the client. In addition,
	In addition, tedious hashing operations provoked by replays of old		tedious hashing operations provoked by replays of old packets are
	packets are suppressed because of the basic NTP protocol design.		suppressed because of the basic NTP protocol design. Finally, spurious
	Finally, spurious public-key computations provoked by replays of old		public-key computations provoked by replays of old packets with
	packets with extension fields are suppressed because of the signature		extension fields are suppressed because of the signature timestamp
	timestamp check.		check.
	The third tier of defense is represented by the Autokey protocol and		The third tier of defense is represented by the Autokey protocol and
	extension fields with timestamped signatures. The signatures are used		extension fields with timestamped signatures. The signatures are used to
	to reliably bind the autokey values to the private key of a trusted		reliably bind the autokey values to the private key of a trusted server.
	server. Once these values are instantiated, the key list		Once these values are instantiated, the key list authenticates each
	authenticates each packet relative to its predecessors and by		packet relative to its predecessors and by induction to the instantiated
	induction to the instantiated autokey values.		autokey values.
	In addition to the three-tier defense strategy, all packets are		In addition to the three-tier defense strategy, all packets are
	protected by the NTP sanity checks. Since all packets carry time		protected by the NTP sanity checks. Since all packets carry time values,
	values, replays of old or bogus packets can be deflected once the		replays of old or bogus packets can be deflected once the client has
	client has synchronized to authentic sources. However, the NTP sanity		synchronized to proventic sources. However, the NTP sanity checks are
	checks are only effective once the packet has passed all		only effective once the packet has passed all cryptographic tests. This
	cryptographic tests. This is why the signature timestamp is necessary		is why the signature timestamp is necessary to avoid expensive
	to avoid expensive calculations that might be provoked by replays.		calculations that might be provoked by replays. Since the signature and
	Since the signature and verify operations have a high manufacturing		verify operations have a high manufacturing cost, in all except
	cost, in all except client/server modes the protocol design protects		client/server modes the protocol design protects against a clogging
	against a clogging attack by signing cryptographic values only when		attack by signing cryptographic values only when they are created or
	they are created or changed and not on request.		changed and not on request.
	7.1 Specific Attacks		Specific Attacks
	While the above arguments suggest that the vulnerability of the		While the above arguments suggest that the vulnerability of the Autokey
	Autokey protocols to cryptanalysis is suitably hard, the same cannot		protocols to cryptanalysis is suitably hard, the same cannot be said
	be said about the vulnerability to a replay or clogging attack,		about the vulnerability to a replay or clogging attack, especially when
	especially when a client is first mobilized and has not yet		a client is first mobilized and has not yet proventicated. In the
	synchronized to an authentic source. In the following discussion a		following discussion a clogging attack is considered a replay attack at
	clogging attack is considered a replay attack at high speed which can		high speed which can clog the network and deny service to other network
	clog the network and deny service to other network users or clog the		users or clog the processor and deny service to other users on the same
	processor and deny service to other users on the same machine. While		machine. While a clogging attack can be concentrated on any function or
	a clogging attack can be concentrated on any function or algorithm of		algorithm of the Autokey protocol, the must vulnerable target is the
	the Autokey protocol, the must vulnerable target is the public key		public key routines to sign and verify public values. It is vital to
	routines to sign and verify public values. It is vital to shield		shield these routines from a clogging attack.
	these routines from a clogging attack.
	In all modes the cryptographic seed data used to generate cookies and		In all modes the cryptographic seed data used to generate cookies and
	autokey values are changed from time to time. Thus, a determined		autokey values are changed from time to time. Thus, a determined
	intruder could save old request and response packets containing these		intruder could save old request and response packets containing these
	values and replay them before or after the seed data have changed.		values and replay them before or after the seed data have changed. Once
	Once the client has synchronized to an authentic source, the client		the client has proventicated, the client will detect replays due to the
	will detect replays due to the old timestamp and discard the data.		old timestamp and discard the data. This is why the timestamp test is
	This is why the timestamp test is done first and before the signature		done first and before the signature is computed. However, before this
	is computed. However, before this happens, the client is vulnerable		happens, the client is vulnerable to replays whether or not they result
	to replays whether or not they result in clogging.		in clogging.
	There are two vulnerabilities exposed in the protocol design: a sign		There are two vulnerabilities exposed in the protocol design: a sign
	attack where the intruder hopes to clog the victim with needless		attack where the intruder hopes to clog the victim with needless
	signature computations, and a verify attack where the intruder		signature computations, and a verify attack where the intruder attempts
	attempts to clog the victim with needless verification computations.		to clog the victim with needless verification computations. The
	The reference implementation uses the RSA public key algorithms for		reference implementation uses the RSA public key algorithms for both
	both sign and verify functions and these algorithms require		sign and verify functions and these algorithms require significant
	significant processor resources.		processor resources.
	In order to reduce the exposure to a sign attack, signatures are		In order to reduce the exposure to a sign attack, signatures are
	computed only when the data have changed. For instance, the autokey		computed only when the data have changed. For instance, the autokey
	values are signed only when the key list is regenerated, which		values are signed only when the key list is regenerated, which happens
	happens about once an hour, while the public values are signed only		about once an hour, while the public values are signed only when the
	when the agreement values are regenerated, which happens about once		agreement values are regenerated, which happens about once per day.
	per day. However, a server is vulnerable to a sign attack where the		However, a server is vulnerable to a sign attack where the intruder can
	intruder can clog the server with cookie-request messages. The		clog the server with cookie-request messages. The protocol design
	protocol design precludes server state variables stored on behalf of		precludes server state variables stored on behalf of any client, so the
	any client, so the signature must be recomputed for every cookie		signature must be recomputed for every cookie request. Ordinarily,
	request. Ordinarily, cookie requests are seldom used, except when the		cookie requests are seldom used, except when the private values are
	private values are regenerated. However, a determined intruder could		regenerated. However, a determined intruder could replay intercepted
	replay intercepted cookie requests at high rate, which may very well		cookie requests at high rate, which may very well clog the server. There
	clog the server. There appears no easy countermeasure for this		appears no easy countermeasure for this particular attack.
	particular attack.
	The intruder might be more successful with a verify attack. Once the		The intruder might be more successful with a verify attack. Once the
	client has synchronized to an authentic source, replays are detected		client has proventicated, replays are detected and discarded before the
	and discarded before the signature is verified. However, if the		signature is verified. However, if the cookie is known or compromised,
	cookie is known or compromised, the intruder can replace the		the intruder can replace the timestamp in an old message with one in the
	timestamp in an old message with one in the future and construct a		future and construct a packet with a MAC acceptable to a client, even if
	packet with a MAC acceptable to a client, even if it has bogus		it has bogus signature and incorrect autokey sequence. The packet passes
	signature and incorrect autokey sequence. The packet passes the MAC		the MAC test, but then tricks the client to verify the signature, which
	test, but then tricks the client to verify the signature, which of		of course fails. What makes this kind of attack more serious is the fact
	course fails. What makes this kind of attack more serious is the fact
	that the cookie used when extension fields are present is well known		that the cookie used when extension fields are present is well known
	(zero). Since all multicast packets have an extension field, all the		(zero). Since all broadcast packets have an extension field, all the
	intruder has to do is clog the clients with responses including		intruder has to do is clog the clients with responses including
	timestamps in the future. Assuming the intruder has joined the NTP		timestamps in the future. Assuming the intruder has joined the NTP
	multicast group, the attack could clog all other members of the		broadcast group, the attack could clog all other members of the group.
	group. This attack can be deflected by the autokey test, which in the		This attack can be deflected by the autokey test, which in the reference
	reference implementation is after extension field processing, but		implementation is after extension field processing, but this requires
	this requires very intricate protocol engineering and is left for a		very intricate protocol engineering and is left for a future refinement.
	future refinement.
	An interesting vulnerability in client/server mode is for an intruder		An interesting vulnerability in client/server mode is for an intruder to
	to replay a recent client packet with an intentional bit error. This		replay a recent client packet with an intentional bit error. This could
	could cause the server to return the special NAK packet. A naive		cause the server to return the special NAK packet. A naive client might
	client might conclude the server had refreshed its private value and		conclude the server had refreshed its private value and so attempt to
	so attempt to refresh the server cookie using a cookie-request		refresh the server cookie using a cookie-request message. This results
	message. This results in the server and client burning spurious		in the server and client burning spurious machine cycles and invites a
	machine cycles and invites a clogging attack. This is why the		clogging attack. This is why the reference implementation simply
	reference implementation simply discards all protocol and procedure		discards all protocol and procedure errors and waits for timeout in
	errors and waits for timeout in order to refresh the values. However,		order to refresh the values. However, a more clever client may notice
	a more clever client may notice that the NTP originate timestamp does		that the NTP originate timestamp does not match the most recent client
	not match the most recent client packet sent, so can discard the		packet sent, so can discard the bogus NAK immediately.
	bogus NAK immediately.
	In multicast and symmetric modes the client must include the		In broadcast and symmetric modes the client must include the association
	association ID in the Autokey request. Since association ID values		ID in the Autokey request. Since association ID values for different
	for different invocations of the NTP daemon are randomized over the		invocations of the NTP daemon are randomized over the 16-bit space, it
	16-bit space, it is unlikely that a very old packet would contain a		is unlikely that a very old packet would contain a valid ID value. An
	valid ID value. An intruder could save old server packets and replay		intruder could save old server packets and replay them to the client
	them to the client population with the hope that the values will be		population with the hope that the values will be accepted and cause
	accepted and cause general chaos. The conservative client will		general chaos. The conservative client will discard them on the basis of
	discard them on the basis of invalid timestamp.		invalid timestamp.
	8 Present Status		As mentioned earlier in this memorandum, an intruder could pounce on the
			initial volley between peers in symmetric mode before both peers have
			determined each other reachable. In this volley the peers are vulnerable
			to an intruder using fake timestamps. The result can be that the peers
			never synchronize the timestamps and never completely mobilize their
			associations.
	The Autokey scheme has been implemented in the public software		Present Status and Unifinished Business
	distribution for NTP Version 4 and has been tested in all machines of
	either endian persuasion and both 32- and 64-bit architectures.
	Testing the implementation has been complicated by the many
	combinations of modes and failure/recovery mechanisms, including
	daemon restarts, key expiration, communication failures and various
	management mistakes. The experience points up the fact that many
	little gotchas that are survivable in ordinary protocol designs
	become showstoppers when strong cryptographic assurance is required.
	9 Future Plans		The Autokey protocol described in this memorandu has been implemented in
			the public software distribution for NTP Version 4 and has been tested
			in machines of either endian persuasion and both 32- and 64-bit
			architectures and kernels. Testing the implementation has been
			complicated by the many combinations of modes and failure/recovery
			mechanisms, including daemon restarts, key expiration, communication
			failures and various management mistakes. The experience points up the
			fact that many little gotchas that are survivable in ordinary protocol
			designs become showstoppers when strong cryptographic assurance is
			required.
	The analysis, design and implementation of the Autokey scheme is		The analysis, design and implementation of the Autokey protocol is
	basically mature; however, There are two remaining implementation		basically mature; however, There are several remaining implementation
	issues. One has to do with the Unix sockets semantics used for		issues. One has to do with cryptographic parameter negotiation, as in
	multicast. The problem is how to set the source address when more		IPSEC protocols such as Photuris. As with Photuris, there may be a need
	than one interface is present. Since the Autokey scheme hashes the IP		to offer and agree to one of possibly several hashing algorithms,
	addresses, as well as the NTP header, it is necessary that the		signature algorithms and agreement algorithms. A message type has been
	correct address be known before the hash can be computed. In the		defined for this purpose, but its syntax and semantics remain to be
	present implementation the address is not known until the first		provoked.
	packet arrives, which considerably complicates the protocol. Probably
	nothing short of a complete rewrite of the I/O code will fix this.
	The other issue is support for Secure DNS services, especially the		Another issue is support for certificates and certificate authorities,
	retrieval of public certificates. A complicating factor is the		in particular Secure DNS services. In the reference implementation a
	existing banal state of the configuration and resolver code in the		complicating factor is the existing banal state of the configuration and
	NTP daemon. Over the years this code has sprouted to a fractal-like		resolver code. Over the years this code has sprouted to a fractal-like
	state where possibly the only correct repair is a complete rewrite.		state where possibly the only correct repair is a complete rewrite.
	Appendix A. Packet Formats		Appendix A. Packet Formats
	The NTP Version 4 packet consists of a number of fields made up of		The NTP Version 4 packet consists of a number of fields made up of 32-
	32-bit (4 octet) words. The packet consists of three components, the		bit (4 octet) words. The packet consists of three components, the
	header, one or more optional extension fields and an optional message		header, one or more optional extension fields and an optional message
	authenticator code (MAC), consisting of the Key ID and Message Digest		authenticator code (MAC), consisting of the Key ID and Message Digest
	fields. The format is shown below, where the size of some multiple		fields. The format is shown below, where the size of some multiple word
	word fields is shown in bits.		fields is shown in bits.
	1 2 3		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		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 |		|LI | VN |Mode | Stratum | Poll | Precision |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Root Delay |		| Root Delay |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Root Dispersion |		| Root Dispersion |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 24, line 17		skipping to change at page 33, line 54
	| |		| |
	| Message Digest (128) |		| Message Digest (128) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The NTP header extends from the beginning of the packet to the end of		The NTP header extends from the beginning of the packet to the end of
	the Transmit Timestamp field. The format and interpretation of the		the Transmit Timestamp field. The format and interpretation of the
	header fields are backwards compatible with the NTP Version 3 header		header fields are backwards compatible with the NTP Version 3 header
	fields as described in RFC-1305, except for a slightly modified		fields as described in RFC-1305, except for a slightly modified
	computation for the Root Dispersion field. In NTP Version 3, this		computation for the Root Dispersion field. In NTP Version 3, this field
	field includes an estimated jitter quantity based on weighted		includes an estimated jitter quantity based on weighted absolute
	absolute differences, while in NTP Version 4 this quantity is based		differences, while in NTP Version 4 this quantity is based on weighted
	on weighted root-mean-square (RMS) differences.		root-mean-square (RMS) differences.
	An unauthenticated NTP packet includes only the NTP header, while an		An unauthenticated NTP packet includes only the NTP header, while an
	authenticated one contains a MAC. The format and interpretation of		authenticated one contains a MAC. The format and interpretation of the
	the NTP Version 4 MAC is described in RFC-1305 when using the Digital		NTP Version 4 MAC is described in RFC-1305 when using the Digital
	Encryption Standard (DES) algorithm operating in cipher block		Encryption Standard (DES) algorithm operating in cipher block chaining
	chaining (CBC) node. While this algorithm and mode of operation is		(CBC) node. While this algorithm and mode of operation is supported in
	supported in NTP Version 4, the DES algorithm has been removed from		NTP Version 4, the DES algorithm has been removed from the standard
	the standard software distribution and must be obtained via other		software distribution and must be obtained via other sources. The
	sources. The preferred replacement for NTP Version 4 is the Message		preferred replacement for NTP Version 4 is the Message Digest 5 (MD5)
	Digest 5 (MD5) algorithm, which is included in the distribution. The		algorithm, which is included in the distribution. The Message Digest
	Message Digest field is 64 bits for DES-CBC and 128 bits for MD5,		field is 64 bits for DES-CBC and 128 bits for MD5, while the Key ID
	while the Key ID field is 32 bits for either algorithm.		field is 32 bits for either algorithm.
	In NTP Version 4 one or more extension fields can be inserted after		In NTP Version 4 one or more extension fields can be inserted after the
	the NTP header and before the MAC, which is always present when an		NTP header and before the MAC, which is always present when an extension
	extension field is present. Each extension field contains a request		field is present. Each extension field contains a request or response
	or response message, which consists of a 16-bit length field, an 8-		message, which consists of a 16-bit length field, an 8-bit control
	bit control field, an 8-bit flags field and a variable length data		field, an 8-bit flags field and a variable length data field, all in
	field, all in network byte order:		network byte order:
	1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R|E| Version | Code | Length |		|R|E| Version | Code | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	= Data =		= Data =
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	There are two flag bits defined. Bit 0 is the response flag (R) and		There are two flag bits defined. Bit 0 is the response flag (R) and bit
	bit 1 is the error flag (E); the other six bits are presently unused		1 is the error flag (E); the other six bits are presently unused and
	and should be set to 0. The Version field identifies the version		should be set to 0. The Version field identifies the version number of
	number of the extension field protocol; this memorandum specifies		the extension field protocol; this memorandum specifies version 1. The
	version 1. The Code field specifies the operation in request and		Code field specifies the operation in request and response messages. The
	response messages. The length includes all octets in the extension		length includes all octets in the extension field, including the length
	field, including the length field itself. Each extension field is		field itself. Each extension field is rounded up to the next multiple of
	rounded up to the next multiple of 4 octets and the last field		4 octets and the last field rounded up to the next multiple of 8 octets.
	rounded up to the next multiple of 8 octets. The extension fields can		The extension fields can occur in any order; however, in some cases
	occur in any order; however, in some cases there is a preferred order		there is a preferred order which improves the protocol efficiency.
	which improves the protocol efficiency. The presence of the MAC and
	extension fields in the packet is determined from the length of the		The presence of the MAC and extension fields in the packet is determined
	remaining area after the header to the end of the packet. The parser		from the length of the remaining area after the header to the end of the
	initializes a pointer just after the header. If the length is not a		packet. The parser initializes a pointer just after the header. If the
	multiple of 4, a format error has occurred and the packet is		length is not a multiple of 4, a format error has occurred and the
	discarded. If the length is zero the packet is not authenticated. If		packet is discarded. If the length is zero the packet is not
	the length is 4 (1 word), the packet is an error report resulting		authenticated. If the length is 4 (1 word), the packet is an error
	from a previous packet that failed the message digest check. The 4		report resulting from a previous packet that failed the message digest
	octets are presently unused and should be set to 0. If the length is		check. The 4 octets are presently unused and should be set to 0. If the
	12 (3 words), a MAC (DES-CBC) is present, but no extension field; if		length is 12 (3 words), a MAC (DES-CBC) is present, but no extension
	20 (5 words), a MAC (MD5) is present, but no extension field; If the		field; if 20 (5 words), a MAC (MD5) is present, but no extension field;
	length is 8 (2 words) or 16 (4 words), the packet is discarded with a		If the length is 8 (2 words) or 16 (4 words), the packet is discarded
	format error. If the length is greater than 20 (5 words), one or		with a format error. If the length is greater than 20 (5 words), one or
	more extension fields are present.		more extension fields are present.
	If an extension field is present, the parser examines the length		If an extension field is present, the parser examines the length field.
	field. If the length is less than 4 or not a multiple of 4, a format		If the length is less than 4 or not a multiple of 4, a format error has
	error has occurred and the packet is discarded; otherwise, the parser		occurred and the packet is discarded; otherwise, the parser increments
	increments the pointer by this value. The parser now uses the same		the pointer by this value. The parser now uses the same rules as above
	rules as above to determine whether a MAC is present and/or another		to determine whether a MAC is present and/or another extension field. An
	extension field. An additional implementation-dependent test is		additional implementation-dependent test is necessary to ensure the
	necessary to ensure the pointer does not stray outside the buffer		pointer does not stray outside the buffer space occupied by the packet.
	space occupied by the packet.
	In the most common protocol operations, a client sends a request to a		In the most common protocol operations, a client sends a request to a
	server with an operation code specified in the Code field and the R		server with an operation code specified in the Code field and the R bit
	bit set to 0. Ordinarily, the client sets the E bit to 0 as well, but		set to 0. Ordinarily, the client sets the E bit to 0 as well, but may in
	may in future set it to 1 for some purpose. The server returns a		future set it to 1 for some purpose. The server returns a response with
	response with the same operation code in the Code field and the R bit		the same operation code in the Code field and the R bit set to 1. The
	set to 1. The server can also set the E bit to 1 in case of error.		server can also set the E bit to 1 in case of error. However, it is not
	However, it is not a protocol error to send an unsolicited response		a protocol error to send an unsolicited response with no matching
	with no matching request.		request.
	There are currently five request and six response messages. All		There are currently five request and six response messages. All request
	request messages have the following format:		messages except the Association ID request message have the following
			format:
	1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|0| 1 | Code | Length |		|0|0| 1 | Code | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Association ID |		| Association ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Association ID field is used to match a client request to a		The Association ID field is used to match a client request to a
	particular server association. By convention, servers set the		particular server association. By convention, servers set the
	association ID in the response and clients include the same value in		association ID in the response and clients include the same value in
	requests. Also by convention, until a client has received a response		requests. Also by convention, until a client has received a response
	from a server, the client sets the Association ID field to 0. If for		from a server, the client sets the Association ID field to 0. If for
	some reason the association ID value in a request does not match the		some reason the association ID value in a request does not match the
	association ID of any mobilized association, the server returns the		association ID of any mobilized association, the server returns the
	request with both the R and E bits set to 1.		request with both the R and E bits set to 1.
	The following request and response messages have been defined.		The following request and response messages have been defined.
	skipping to change at page 26, line 15		skipping to change at page 35, line 48
	particular server association. By convention, servers set the		particular server association. By convention, servers set the
	association ID in the response and clients include the same value in		association ID in the response and clients include the same value in
	requests. Also by convention, until a client has received a response		requests. Also by convention, until a client has received a response
	from a server, the client sets the Association ID field to 0. If for		from a server, the client sets the Association ID field to 0. If for
	some reason the association ID value in a request does not match the		some reason the association ID value in a request does not match the
	association ID of any mobilized association, the server returns the		association ID of any mobilized association, the server returns the
	request with both the R and E bits set to 1.		request with both the R and E bits set to 1.
	The following request and response messages have been defined.		The following request and response messages have been defined.
	Public Key (1)		Parameter Negotiation (1)
	This extension field is reserved for future use as an algorithm and		This extension field is reserved for future use as an algorithm and
	algorithm parameter offer/select exchange. The command code is		algorithm parameter offer/select exchange, as well as to provide the
	reserved.		optional identification value to use in lieu of endpoint IP addresses
			when calculating the autokey. The format, encoding and use of these data
			remain to be specified. The command code is reserved.
	Association ID (2)		Association ID (2)
			A client sends the request to obtain the association ID and status
	This message is sent by a multicast server as an unsolicited response		flags. A broadcast server sends an unsolicited response for all except
	only; there is no corresponding request message of this type. The		the first autokey sent from the key list. The request and response have
	response has the following format:		the following format (except for the response bit):
	1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1|E| 1 | 2 | Length |		|0|E| 1 | 2 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Association ID |		| Association ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Flags |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Association ID field contains the association ID of the server.		The Association ID field contains the association ID of the server. The
	This response is included in every packet sent by a multicast server,		status flags currently defined are
	except when a new key list is generated. There is no timestamp or
	signature associated with this message.
	Cookie (3)		Bit Function
			================
			31 autokey is enabled
			30 public and private keys have been loaded
			29 agreement parameters have been loaded
			28 leapseconds table has been loaded
	A client sends the request to obtain the server cookie. The response		Additional bits may be defined in future, so for now bits 0-27 should be
	has the following format:		set to zero. There is no timestamp or signature associated with this
			message.
			Autokey (3)
			A broadcast server or symmetric peer sends the request to obtain the
			autokey values. The response has the following format:
	1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1|E| 1 | 3 | Length |		|1|E| 1 | 4 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Association ID |		| Association ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Timestamp |		| Timestamp |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cookie |		| Initial Sequence |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Initial Key ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Signature Length |		| Signature Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| |		| |
	= Signature =		= Signature =
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Since there is no server association matching the client, the		The response is also sent unsolicited when the server or peer generates
	association ID field for the request and response is 0. The Cookie		a new key list. The Initial Sequence field contains the first key number
	field contains the cookie used in client/server modes. If the server		in the current key list and the Initial Key ID field contains the next
	is not synchronized to an authenticated source, the Timestamp field		key ID associated with that number. If the server is not synchronized to
	contains 0; otherwise, it contains the NTP seconds when the cookie		a proventicated source, the Timestamp field contains 0; otherwise, it
	was computed and signed. The signature covers the Timestamp and		contains the NTP seconds when the key list was generated and signed. The
	Cookie fields. If for some reason the cookie value is unavailable or		signature covers all fields from the Timestamp field through the Initial
	the signing operation fails, the Cookie field contains 0 and the		Key ID field. If for some reason these values are unavailable or the
	extension field is truncated following this field.		signing operation fails, the Initial Sequence and Initial Key ID fields
			contain 0 and the extension field is truncated following the Initial Key
			ID field.
	Autokey (4)		Cookie (4)
	A multicast server or symmetric peer sends the request to obtain the		A client sends the request to obtain the server cookie. The response has
	autokey values. The response has the following format:		the following format:
	1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1|E| 1 | 4 | Length |		|1|E| 1 | 3 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Association ID |		| Association ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Timestamp |		| Timestamp |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Initial Sequence |		| Cookie |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Initial Key ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Signature Length |		| Signature Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| |		| |
	= Signature =		= Signature =
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The response is also sent unsolicited when the server or peer		Since there is no server association matching the client, the
	generates a new key list. The Initial Sequence field contains the		association ID field for the request and response is 0. The Cookie field
	first key number in the current key list and the Initial Key ID field		contains the cookie used in client/server modes. If the server is not
	contains the next key ID associated with that number. If the server		synchronized to a proventicated source, the Timestamp field contains 0;
	is not synchronized to an authenticated source, the Timestamp field		otherwise, it contains the NTP seconds when the cookie was computed and
	contains 0; otherwise, it contains the NTP seconds when the key list		signed. The signature covers the Timestamp and Cookie fields. If for
	was generated and signed. The signature covers all fields from the		some reason the cookie value is unavailable or the signing operation
	Timestamp field through the Initial Key ID field. If for some reason		fails, the Cookie field contains 0 and the extension field is truncated
	these values are unavailable or the signing operation fails, the		following this field.
	Initial Sequence and Initial Key ID fields contain 0 and the
	extension field is truncated following the Initial Key ID field.
	Diffie-Hellman Parameters (5)		Diffie-Hellman Parameters (5)
			A symmetric peer uses the request and response to send the public value
	A symmetric peer uses the request and response to send the public		and signature to its peer. The response has the following format:
	value and signature to its peer. The response has the following
	format:
	1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1|E| 1 | 5 | Length |		|1|E| 1 | 5 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Association ID |		| Association ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Timestamp |		| Timestamp |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 28, line 49		skipping to change at page 38, line 38
	| |		| |
	| |		| |
	= Signature =		= Signature =
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Parameters field contains the Diffie-Hellman parameters used to		The Parameters field contains the Diffie-Hellman parameters used to
	compute the public and private values. The Parameters Filestamp field		compute the public and private values. The Parameters Filestamp field
	contains the NTP seconds when the Diffie-Hellman parameter file was		contains the NTP seconds when the Diffie-Hellman parameter file was
	generated. If the server is not synchronized to an authenticated		generated. If the server is not synchronized to a proventicated source,
	source, the Timestamp field contains 0; otherwise, it contains the		the Timestamp field contains 0; otherwise, it contains the NTP seconds
	NTP seconds when the public value was generated and signed. The		when the public value was generated and signed. The signature covers the
	signature covers the Timestamp, Parameters Length and Parameters		Timestamp, Parameters Length and Parameters fields. If for some reason
	fields. If for some reason these values are unavailable or the		these values are unavailable or the signing operation fails, the
	signing operation fails, the Parameters Length field contains 0 and		Parameters Length field contains 0 and the extension field is truncated
	the extension field is truncated following this field.		following this field.
	Public Value (6)		Public Value (6)
	A symmetric peer uses the request and response to send the public
	value and signature to its peer. The response has the following		A symmetric peer uses the request and response to send the public value
	format:		and signature to its peer. The response has the following format:
	1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1|E| 1 | 5 | Length |		|1|E| 1 | 5 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Association ID |		| Association ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Timestamp |		| Timestamp |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 29, line 40		skipping to change at page 39, line 26
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Signature Length |		| Signature Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| |		| |
	= Signature =		= Signature =
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Public Value field contains the Diffie-Hellman public value used		The Public Value field contains the Diffie-Hellman public value used to
	to compute the agreed key.		compute the agreed key.
	The Filestamp field contains the NTP seconds when the Diffie-Hellman		The Filestamp field contains the NTP seconds when the Diffie-Hellman
	parameter file was generated. If the server is not synchronized to an		parameter file was generated. If the server is not synchronized to a
	authenticated source, the Timestamp field contains 0; otherwise, it		proventicated source, the Timestamp field contains 0; otherwise, it
	contains the NTP seconds when the public value was generated and		contains the NTP seconds when the public value was generated and signed.
	signed. The signature covers all fields from the Timestamp field		The signature covers all fields from the Timestamp field through the
	through the Public Value field. If for some reason these values are		Public Value field. If for some reason these values are unavailable or
	unavailable or the signing operation fails, the Public Value Length		the signing operation fails, the Public Value Length field contains 0
	field contains 0 and the extension field is truncated following this		and the extension field is truncated following this field.
	field.
	Public Key/Host Name (7)		Public Key/Host Name (7)
	A client uses the request to retrieve the public key, host name and		A client uses the request to retrieve the public key, host name and
	signature. The response has the following format:		signature. The response has the following format:
	1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1|E| 1 | 7 | Length |		|1|E| 1 | 7 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Public Key ID |		| Public Key ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 30, line 45		skipping to change at page 40, line 28
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Signature Length |		| Signature Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| |		| |
	= Signature =		= Signature =
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Since the public key and host name are a property of the server and		Since the public key and host name are a property of the server and not
	not any particular association, the association ID field for the		any particular association, the association ID field for the request and
	request and response is 0. The Public Key field contains the RSA		response is 0. The Public Key field contains the RSA public key in
	public key in rsaref2.0 format; that is, the modulus length (in bits)		rsaref2.0 format; that is, the modulus length (in bits) as the first
	as the first word followed by the modulus bits. Note that in some		word followed by the modulus bits. Note that in some architectures the
	architectures the rsaref2.0 modulus word may be something other than		rsaref2.0 modulus word may be something other than 32 bits. The Host
	32 bits. The Host Name field contains the host name string returned		Name field contains the host name string returned by the Unix
	by the Unix gethostname() library function.		gethostname() library function.
	The Filestamp field contains the NTP seconds when the public/private		The Filestamp field contains the NTP seconds when the public/private key
	key files were generated. If the server is not synchronized to an		files were generated. If the server is not synchronized to a
	authenticated source, the Timestamp field contains 0; otherwise, it		proventicated source, the Timestamp field contains 0; otherwise, it
	contains the NTP seconds when the public value was generated and		contains the NTP seconds when the public value was generated and signed.
	signed. The signature covers all fields from the Timestamp field		The signature covers all fields from the Timestamp field through the
	through the Host Name field. If for some reason these values are		Host Name field. If for some reason these values are unavailable or the
	unavailable or the signing operation fails, the Host Name Length		signing operation fails, the Host Name Length field contains 0 and the
	field contains 0 and the extension field is truncated following this		extension field is truncated following this field.
	field.
	TAI Leap Second Table (8)		Leapseconds table (8)
	The civil timescale (UTC), which is based on Earth rotation, has been		The civil timescale (UTC), which is based on Earth rotation, has been
	diverging from atomic time (TAI), which is based on an ensemble of		diverging from atomic time (TAI), which is based on an ensemble of
	cesium oscillators, at about one second per year. Since 1972 the		cesium oscillators, at about one second per year. Since 1972 the
	International Bureau of Weights and Measures (BIPM) declares on		International Bureau of Weights and Measures (BIPM) declares on occasion
	occasion a leap second to be inserted in the UTC timescale on the		a leap second to be inserted in the UTC timescale on the last day of
	last day of June or December. Sometimes it is necessary to correct		June or December. Sometimes it is necessary to correct UTC as
	UTC as disseminated by NTP to agree with TAI on the current or some		disseminated by NTP to agree with TAI on the current or some previous
	previous epoch.		epoch.
	A client uses the request to retrieve the leap second table and		A client uses the request to retrieve the leapseconds table and
	signature. The response has the following format:		signature. The response has the following format:
	1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1|E| 1 | 8 | Length |		|1|E| 1 | 8 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Public Key ID |		| Public Key ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Association ID |		| Association ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Timestamp |		| Timestamp |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Filestamp |		| Filestamp |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Leap Second Table Length |		| Leapseconds table Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| |		| |
	= Leap Second Table =		= Leapseconds table =
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Signature Length |		| Signature Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| |		| |
	= Signature =		= Signature =
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The NTP extension field format consists of a table with one entry in		The NTP extension field format consists of a table with one entry in NTP
	NTP seconds for each leap second insertion and in the order from the		seconds for each leap second.
	most recent insertion to the first. Since UTC led TAI by ten seconds
	at the first insertion and each insertion since then adds one second,
	the current UTC-TAI offset is simply the sum of these values.
	Since the leap second table is a property of the server and not any		Since the leapseconds table is a property of the server and not any
	particular association, the association ID field for the request and		particular association, the association ID field for the request and
	response is 0. The Leap Second Table field contains a list of the		response is 0. The Leapseconds table field contains a list of the
	historic epoches that leap seconds were inserted in the UTC		historic epoches that leap seconds were inserted in the UTC timescale.
	timescale. Each list entry is a 32-bit word in NTP seconds, while the		Each list entry is a 32-bit word in NTP seconds, while the table is in
	table is in order from the most recent to the oldest insertion. At		order from the most recent to the oldest insertion. At the first
	the first insertion in January, 1972 UTC was ahead of TAI by 10 s and		insertion in January, 1972 UTC was ahead of TAI by 10 s and has
	has increased by 1 s for each insertion since then. Thus, the table		increased by 1 s for each insertion since then. Thus, the table length
	length in bytes divided by four plus nine is the current offset of		in bytes divided by four plus nine is the current offset of UTC relative
	UTC relative to TAI.		to TAI.
	The Filestamp field contains the NTP seconds when the leap second		The Filestamp field contains the NTP seconds when the leapseconds table
	table was generated at the original host, in this case one of the		was generated at the original host, in this case one of the public time
	public time servers operated by NIST. If the value of the filestamp		servers operated by NIST. If the value of the filestamp is less than the
	is less than the first entry on the list, the first entry is the		first entry on the list, the first entry is the epoch of the predicted
	epoch of the predicted next leap insertion. The filestamp must always		next leap insertion. The filestamp must always be greater than the
	be greater than the second entry in the list. If the server is not		second entry in the list. If the server is not synchronized to a
	synchronized to an authenticated source, the Timestamp field contains		proventicated source, the Timestamp field contains 0; otherwise, it
	0; otherwise, it contains the NTP seconds when the public value was		contains the NTP seconds when the public value was generated and signed.
	generated and signed.
	The signature covers all fields from the Timestamp field through the		The signature covers all fields from the Timestamp field through the
	Leap Second Table field. If for some reason these values are		Leapseconds table field. If for some reason these values are unavailable
	unavailable or the signing operation fails, the Host Name Length		or the signing operation fails, the Host Name Length field contains 0
	field contains 0 and the extension field is truncated following this		and the extension field is truncated following this field.
	field.
	Appendix B. Key Generation and Management		Appendix B. Key Generation and Management
	In the reference implementation the lifetimes of various		In the reference implementation the lifetimes of various cryptographic
	cryptographic values are carefully managed and frequently refreshed.		values are carefully managed and frequently refreshed. While permanent
	While permanent keys have lifetimes that expire only when manually		keys have lifetimes that expire only when manually revoked, autokeys
	revoked, autokeys have a lifetime specified at the time of		have a lifetime specified at the time of generation. When generating a
	generation. When generating a key list for an association, the		key list for an association, the lifetime of each autokey is set to
	lifetime of each autokey is set to expire one poll interval later		expire one poll interval later than it is scheduled to be used.
	than it is scheduled to be used.		Ordinarily, key lists are regenerated and signed about once per hour and
	Ordinarily, key lists are regenerated and signed about once per hour		private cookie values and public agreement values are refreshed and
	and private cookie values and public agreement values are refreshed		signed about once per day. The protocol design is specially tailored to
	and signed about once per day. The protocol design is specially		make a smooth transition when these values are refreshed and to avoid
	tailored to make a smooth transition when these values are refreshed		vulnerabilities due to clogging and replay attacks while refreshment is
	and to avoid vulnerabilities due to clogging and replay attacks while		in progress.
	refreshment is in progress.
	In the reference implementation, Autokey key management is handled in		Autokey key management can be handled in much the same way as in the ssh
	much the same way as in the ssh facility. A set of public and private		facility. A set of public and private keys and agreement parameters are
	keys and agreement parameters are generated by a utility program		generated by a utility program designed for this purpose. The program
	designed for this purpose. From these data the program generates four		generates four files, one containing random DES/MD5 private keys, which
	files, one containing random DES/MD5 private keys, which are not used		are not used in the Autokey protocol, a second containing the RSA
	in the Autokey scheme, another containing the RSA private key, a		private key, a third the RSA public key, and a fourth the Diffie-Hellman
	third the RSA public key, and a fourth the agreement parameters. In		agreement parameters. In addition, the leapseconds table is generated
	addition, the leap second table is generated and stored in public		and stored in public time servers maintained by NIST. The means to do
	time servers maintained by NIST. The means to do this are beyond the		this are beyond the scope of this memorandum.
	scope of this memorandum.
	All files are based on random strings seeded by the system clock at		All files are based on random strings seeded by the system clock at the
	the time of generation and are in printable ASCII format with base-64		time of generation and are in printable ASCII format with PEM (base-64)
	encoding. The name of each file includes an extension consisting of		encoding. The name of each file includes an extension consisting of the
	the NTP seconds at the time of generation. This is interpreted as a		NTP seconds at the time of generation. This is interpreted as a key ID
	key ID in order to detect incorrect keys and to handle key		in order to detect incorrect keys and to handle key changeovers in an
	changeovers in an orderly way. In the recommended method, all files		orderly way. In the recommended method, all files except the RSA private
	except the RSA private key file are stored in shared directory		key file are installed in a shared directory /usr/local/etc, which is
	/usr/local/etc, which is where the daemon looks for them by default.		where the daemon looks for them by default. The private RSA key file is
	The private RSA key file should be stored in an unshared directory		installed in an unshared directory such as /etc. It is convenient to
	such as /etc. It is convenient to install links from the default file		install links from the default file names, which do not have filestamp
	names, which do not have filestamp extensions, to the current files,		extensions, to the current files, which do. This way when a new
	which do. This way when a new generation of keys is installed, only		generation of keys is installed, only the links need to be changed.
	the links need to be changed.
	When a server or client first initializes, it loads the RSA public		When a server or client first initializes, it loads the RSA public and
	and private key files, which are required for continued operation. It		private key files, which are required for continued operation. It then
	then attempts to load the agreement parameter file and, if enabled by		attempts to load the agreement parameters file, certificate file and
	a configuration file bit, it attempts to load the leap second table		leapseconds table file. If one or more of these files are present, the
	file. Neither of these files are necessary at this time, since the		associated bit is set in the system status word. Neither of these files
	data can be retrieved later from another server. If obtaining these		are necessary at this time, since the data can be retrieved later from
	data from another server is considered a significant vulnerability,		another server. If obtaining these data from another server is
	the files should be present.		considered a significant vulnerability, the files should be present.
	In the current management model, the keys and parameter files are		In the current management model, the keys and parameter files are
	generated on each machine separately and the private key obscured.		generated on each machine separately and the private key obscured. For
	The set of public key files for a community of users can be copied to		the most demanding applications, the public key files for a community of
	all of those users, while one of the parameter files can be selected		users can be copied to all of those users, while one of the parameter
	and copied to all users. However, if security considerations permit,		files can be selected and copied to all users. However, if security
	the public key and parameter values, as well as the leap second table		considerations permit, the public key and parameter values, as well as
	can be obtained from other servers during operation. These data		the certificate file and leapseconds table file, can be obtained from
	completely define the security community and the servers configured		other servers during operation. These data completely define the
	for each client. In multicast client and symmetric passive modes the		security community and the servers configured for each client. In
	identity of a particular server may not be known in advance, so the		broadcast client and symmetric passive modes the identity of a
	protocol obtains and verifies the public key and host name directly		particular server may not be known in advance, so the protocol obtains
	from the server. Ultimately, these procedures will be automated using		and verifies the public key and host name directly from the server.
	public certificates retrieved from secure directory services.		Ultimately, these procedures may be automated using public certificates
			retrieved from secure directory services.
	Where security considerations permit and the public key and parameter		Since all files carry a filestamp incorporated in the file name, newer
	data can be retrieved directly from the server, key and parameter		file generations are detected in the data obtained from the one or more
	refreshment can be easily automated. Each server and client runs a		configured servers. When detected, the newer generations replace the
	shell script perhaps once per month to generate new key and parameter		older ones automatically and the newer ones made available to dependent
	files, update the links and then restarts the daemon. The daemon will		clients as required. Since the filestamp signatures are refreshed once
	load the necessary files and then restart the protocol with each of		per day, which causes all associations to reset, the newer generations
	its servers or peers, refreshing public keys and parameter files		will eventually overtake all older ones throughout the subnet of servers
	during the process.		and dependent clients.
	Clients of the daemon will not be able to authenticate following
	daemon restart, of course, but the protocol design is such that they
	will eventually time out, restart the protocol and retrieve the
	latest data.
	The parameters and leap second table files are a special case, since		Where security considerations permit and the public key, certificate and
	the expectation is that all servers and clients in the network have		agreement parameter files can be retrieved directly from the server,
	the same versions. Therefore, the scripts should provide for		these data can be easily automated. Each server and client runs a shell
	automatic, secure transfer of these files to all the lowest-stratum		script perhaps once per month. The script generates new key and
	servers in the security compartment.		parameter files, updates the links and then restarts the daemon. The
			daemon loads the necessary files and then restarts the protocol with
			each of its servers, refreshing public keys and parameter files during
			the process. Clients will not be able to authenticate following daemon
			restart, but the protocol design is such that they will eventually time
			out, restart the protocol and retrieve the latest data.
	Unlike ssh, where the client must be securely identified to the		Security Considerations
	server, in NTP the server must be securely identified to the client.
	In ssh each different interface address can be bound to a different
	name as returned by a reverse-DNS query. In this design separate
	public/private key pairs are required for each interface address with
	a distinct name. In the NTP design the canonical host name, as
	returned by the gethostname() library function, represents all
	interface addresses. Since at least in some host configurations the
	canonical name may not be identifiable in a DNS query, the name must
	be either configured in advance or obtained directly from the server
	using the Autokey protocol.
	10 References		Security issues are the main topic of this memorandum.
			References
	Note: Internet Engineering Task Force documents can be obtained at		Note: Internet Engineering Task Force documents can be obtained at
	www.ietf.org. Other papers and reports can be obtained at		www.ietf.org. Other papers and reports can be obtained at
	www.eecis.udel.edu/~mills. Additional briefings in PowerPoint,		www.eecis.udel.edu/~mills. Additional briefings in PowerPoint,
	PostScript and PDF are at that site in ./autokey.htm.		PostScript and PDF are at that site in ./autokey.htm.
	1. Karn, P., and W. Simpson. Photuris: session-key management		1. Bradner, S. Key words for use in RFCs to indicate requirement levels.
	protocol. Request for Comments RFC-2522, Internet Engineering Task		Request for Comments RFC-2119, BCP 14, Internet Engineering Task Force,
	Force, March 1999.		March 1997.
	2. Kent, S., R. Atkinson. IP Authentication Header. Request for		2. Karn, P., and W. Simpson. Photuris: session-key management protocol.
	Comments RFC-2402, Internet Engineering Task Force, November 1998.		Request for Comments RFC-2522, Internet Engineering Task Force, March
			1999.
	3. Kent, S., and R. Atkinson. IP Encapsulating security payload		3. Kent, S., R. Atkinson. IP Authentication Header. Request for Comments
	(ESP). Request for Comments RFC-2406, Internet Engineering Task		RFC-2402, Internet Engineering Task Force, November 1998.
	Force, November 1998.
	4. Maughan, D., M. Schertler, M. Schneider, and J. Turner. Internet		4. Kent, S., and R. Atkinson. IP Encapsulating security payload (ESP).
	security association and key management protocol (ISAKMP). Request		Request for Comments RFC-2406, Internet Engineering Task Force, November
	for Comments RFC-2408, Internet Engineering Task Force, November
	1998.		1998.
	5. Mills, D.L. Authentication scheme for distributed, ubiquitous,		5. Maughan, D., M. Schertler, M. Schneider, and J. Turner. Internet
	real- time protocols. Proc. Advanced Telecommunications/Information		security association and key management protocol (ISAKMP). Request for
			Comments RFC-2408, Internet Engineering Task Force, November 1998.
			6. Mills, D.L. Authentication scheme for distributed, ubiquitous, real-
			time protocols. Proc. Advanced Telecommunications/Information
	Distribution Research Program (ATIRP) Conference (College Park MD,		Distribution Research Program (ATIRP) Conference (College Park MD,
	January 1997), 293-298.		January 1997), 293-298.
	6. Mills, D.L. Cryptographic authentication for real-time network		7. Mills, D.L. Cryptographic authentication for real-time network
	protocols. In: AMS DIMACS Series in Discrete Mathematics and		protocols. In: AMS DIMACS Series in Discrete Mathematics and Theoretical
	Theoretical Computer Science, Vol. 45 (1999), 135-144.		Computer Science, Vol. 45 (1999), 135-144.
	7. Mills, D.L. Network Time Protocol (Version 3) specification,		8. Mills, D.L. Network Time Protocol (Version 3) specification,
	implementation and analysis. Network Working Group Report RFC-1305,		implementation and analysis. Network Working Group Report RFC-1305,
	University of Delaware, March 1992, 113 pp.		University of Delaware, March 1992, 113 pp.
	8. Mills, D.L. Proposed authentication enhancements for the Network		9. Mills, D.L. Proposed authentication enhancements for the Network Time
	Time Protocol version 4. Electrical Engineering Report 96-10-3,		Protocol version 4. Electrical Engineering Report 96-10-3, University of
	University of Delaware, October 1996, 36 pp.		Delaware, October 1996, 36 pp.
	9. Mills, D.L, and A. Thyagarajan. Network time protocol version 4		10. Mills, D.L, and A. Thyagarajan. Network time protocol version 4
	proposed changes. Electrical Engineering Department Report 94-10-2,		proposed changes. Electrical Engineering Department Report 94-10-2,
	University of Delaware, October 1994, 32 pp.		University of Delaware, October 1994, 32 pp.
	10. Mills, D.L. Public key cryptography for the Network Time		11. Mills, D.L. Public key cryptography for the Network Time Protocol.
	Protocol. Electrical Engineering Report 00-5-1, University of		Electrical Engineering Report 00-5-1, University of Delaware, May 2000.
	Delaware, May 2000. 23 pp.		23 pp.
	11. Orman, H. The OAKLEY key determination protocol. Request for		12. Orman, H. The OAKLEY key determination protocol. Request for
	Comments RFC-2412, Internet Engineering Task Force, November 1998.		Comments RFC-2412, Internet Engineering Task Force, November 1998.
	12. Bradner, S., "Key words for use in RFCs to Indicate Requirement		Author's Address
	11. Author's Address
	David L. Mills		David L. Mills
	Electrical and Computer Engineering Department		Electrical and Computer Engineering Department
	University of Delaware		University of Delaware
	Newark, DE 19716		Newark, DE 19716
	mail mills@udel.edu, phone 302 831 8247, fax 302 831 4316		mail mills@udel.edu, phone 302 831 8247, fax 302 831 4316
	web www.eecis.udel.edu/~mills		web www.eecis.udel.edu/~mills
			Edited into Internet-draft form by:
			Patrick Cain. Please notify pcain@genuity.com of editorial omissions or
			errors.
	Full Copyright Statement		Full Copyright Statement
	"Copyright (C) The Internet Society (date). All Rights Reserved. This		"Copyright (C) The Internet Society (date). All Rights Reserved. This
	document and translations of it may be copied and furnished to		document and translations of it may be copied and furnished to others,
	others, and derivative works that comment on or otherwise explain it		and derivative works that comment on or otherwise explain it or assist
	or assist in its implmentation may be prepared, copied, published and		in its implmentation may be prepared, copied, published and distributed,
	distributed, in whole or in part, without restriction of any kind,		in whole or in part, without restriction of any kind, provided that the
	provided that the above copyright notice and this paragraph are		above copyright notice and this paragraph are included on all such
	included on all such copies and derivative works. However, this		copies and derivative works. However, this document itself may not be
	document itself may not be modified in any way, such as by removing		modified in any way, such as by removing the copyright notice or
	the copyright notice or references to the Internet Society or other		references to the Internet Society or other Internet organizations,
	Internet organizations, except as needed for the purpose of		except as needed for the purpose of developing Internet standards in
	developing Internet standards in which case the procedures for		which case the procedures for copyrights defined in the Internet
	copyrights defined in the Internet Standards process must be		Standards process must be followed, or as required to translate it into.
	followed, or as required to translate it into.
End of changes. 233 change blocks.
	1118 lines changed or deleted		1675 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/