Network Working Group
 Internet Engineering Task Force                          David L. Mills
 Internet Draft                                   University of Delaware
     Category:
 Standards Track

              Public-Key                                          September 2001

          Public key Cryptography for the Network Time Protocol
                                Version 1 2
                   < draft-ietf-stime-ntpauth-02.txt >

 Status of this Memorandum

 This document is an Internet-Draft and is in full conformance with all
 provisions of Section 10 of RFC2026.

 Internet-Drafts are working documents of the Internet Engineering Task
 Force (IETF), its areas, and its working groups. Note that other
 groups may also distribute working documents as Internet-Drafts.

 Internet-Drafts are draft documents valid for a maximum of six months
 and may be updated, replaced, or obsoleted by other documents at any
 time. It is inappropriate to use Internet- Drafts as reference
 material or to cite them other than as "work in progress."

 The list of current Internet-Drafts can be accessed at
         http://www.ietf.org/ietf/1id-abstracts.txt
 The list of Internet-Draft Shadow Directories can be accessed at
         http://www.ietf.org/shadow.html. This document is an Internet-Draft. Internet-
 Draft.

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC-2119 [1].

 1. Abstract

 This memorandum describes a scheme for authenticating servers to
 clients
     in using the Network Time Protocol. It extends prior schemes
 based on
     symmetric-key symmetric key cryptography to a new scheme based on public-key public
 key cryptography. The new scheme, called Autokey, is based on the
 premiss that the IPSEC schemes proposed by the IETF cannot be adopted
 intact, since that would preclude stateless servers and severely
 compromise timekeeping accuracy. In addition, the IPSEC model presumes
 authenticated timestamps are always available; however,
 cryptographically verified timestamps require interaction between the
 timekeeping function and authentication function in ways not yet
 considered in the IPSEC model.

 The main body of this memorandum contains a description of the
 security model, approach rationale, protocol design and vulnerability
 analysis. It obsoletes a previous report [11] primarily in the schemes
 for distributing public keys and related values. A detailed
 description of the protocol states, events and transition functions is
 included. Detailed packet formats and field descriptions are given in
 the appendix. A prototype of the Autokey design based on this
 memorandum has been implemented, tested and documented in the NTP
 Version 4 software distribution for Unix, Windows and VMS at
 www.ntp.org.

 While not strictly a security function, the Autokey protocol also
 provides means to securely retrieve a table of historic leap seconds
 necessary to convert ordinary civil time (UTC) to atomic time (TAI)
 where needed. The tables can be retrieved either directly from
 national time servers operated by NIST or indirectly through NTP and
 intervening servers.

 Changes Since the Preceeding Preceding Draft

     There are

 This is a number major rewrite of the previous draft. There are numerous
 changes scattered through this memorandum to clarify the presentation
 and add a few new features. Among the most important:

 1. An optional parameter negotiation message has been added to the
     protocol state machine. The values reference implementation now uses the OpenSSL cryptographic
 software library. Besides being somewhat faster than the older
 RSAref2.0 library, it may carry supports several different message digest and the interpretation
     of these values are not defined in this memorandum.
 signature encryption schemes.

 2. A preliminary value exchange has been added to begin the The Autokey protocol
     dance. This is necessary to avoid a vulnerability where unsolicited
     public key responses could clog and reference implementation support the victim with needless signature
     cycles.
 Public Key Infrastructure (PKI), including X.500 certificates.

 3. The value exchange, which Autokey protocol has been redesigned to be simpler, more
 uniform and more robust. There is piggybacked on the association ID
     message, supports a timestamp-based agreement scheme which floods only one generic message format and
 all requests can carry signed parameters.

 4. Strong assertions are now possible about the
     latest version authentication of the agreement parameters
 timestamps and leapseconds table. Using
     this scheme any one of a clique of trusted primary servers running
     symmetric modes with each other filestamps. This makes correctness modeling more robust
 and broadcast or simplifies vulnerability assessment.

 5. Certain security potholes have been filled in, in particular the
 cookie in client/server and symmetric modes
     with is now encrypted.

 6. The description of the secondary server population can refresh these data at any time protocol, its state variables, transition
 function, inputs and the refreshed data will update all older data everywhere in the NTP
     subnet within one day.

     4. An optional certificate retrieval operation has outputs are simpler, less wordy and more amenable
 to correctness modelling.

 7. Provisions have been added made to handle cases when 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 endpoint
 addresses are changed, as in calculating the autokey have been added.

     9. A simplified version of the protocol appropriate for SNTP clients is
     proposed; details to follow. mobile IP.

 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 private 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
 methodology for use in NTP and similar distributed protocols. As
 demonstrated in the reports and briefings cited in the references at
 the end of this memorandum, there is a place for Public-Key Infrastructure
     (PKI) PKI and related
 schemes, but none of these schemes alone satisfies the requirements of
 the NTP security model. The various key agreement schemes [2, 5, 12]
 proposed by the IETF require per-association state variables, which
 contradicts the principles of the remote procedure call (RPC) paradigm
 in which servers keep no state for a possibly large client population.
 An evaluation of the PKI model and algorithms as implemented in the rsaref2.0
 RSAref2.0 package formerly distributed by RSA Laboratories leads to
 the conclusion that any scheme requiring every NTP packet to carry a
 PKI digital signature would result in unacceptably poor timekeeping
 performance.

 A revised security model and authentication scheme called Autokey was
 proposed in earlier reports [5, 6, 8]. It has been evolved and refined
 since then and implemented in NTP Version 4 for Unix, Windows and VMS
 [11]. It is based on a combination of PKI and a pseudo-random sequence
 generated by repeated hashes of a cryptographic value involving both
 public and private components. This scheme has been tested and
 evaluated in a local environment and is being deployed now in the CAIRN experiment network
 funded by DARPA. A detailed description of the security model, design
 principles and implementation experience is presented in this
 memorandum. Additional information about NTP, including executive
 summaries, software documentation, briefings and bibliography can be
 found at www.eecis.udel.edu/~mills/ntp.htm. Additional information
 about the reference implementation can be found at
 www.eecis.udel.edu/~ntp/ntp_spool/html/authopt.htm.

 Security Model

 NTP security requirements are even more stringent than most other
 distributed services. First, the operation of the authentication
 mechanism and the time synchronization mechanism are inextricably
 intertwined. Reliable time synchronization requires cryptographic keys
 which are valid only over designated time intervals; but, time
 intervals can be enforced only when all participating servers and clients
 are reliably synchronized to UTC. Second, the NTP subnet is
 hierarchical by nature, so time and trust flow from the primary
 servers at the root through secondary servers to the clients at the
 leaves.

 A client can claim authentic to dependent applications only if all
 servers on the path to the primary servers are bone-fide authentic. In
 order to emphasize this requirement, in this
     memorandum, memorandum the notion of
 "authentic" is replaced by "proventic", a noun new to English and
 derived from provenance, as in the provenance of a painting. Having
 abused the language this far, the suffixes fixable to 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. Serious
 computer linguists would correctly interpret the proventic relation as
 the transitive closure of the authentic relation.

 It is important to note that the notion of proventic does not
 necessarily imply the time is correct. A client considers a server
 proventic if it can validate its certificate and its apparent time is
 within the valid interval specified on the certificate. The statement
 "the client is synchronized to proventic sources" means that the
 system clock has been set using the time values of one or more
 proventic client associations and according to the NTP mitigation
 algorithms. While a certificate authority must satisfy this
 requirement when signing a certificate request, the certificate itself
 can be stored in public directories and retrieved over unsecured
 networks.

 Over the last several years the IETF has defined and evolved the IPSEC
 infrastructure for privacy protection and source authentication in the
 Internet, The infrastructure includes the Encapsulating Security
 Payload (ESP) [4] and Authentication Header (AH) [3] for IPv4 and
 IPv6. Cryptographic algorithms that use these headers for various
 purposes include those developed for the PKI, including MD5 message
 digests, RSA digital signatures and several variations of Diffie-Hellman Diffie-
 Hellman key agreements. The fundamental assumption in the security
 model is that packets transmitted over the Internet can be intercepted
 by other than the intended receiver, remanufactured in various ways
 and replayed in whole or part. These packets can cause the client to
 believe or produce incorrect information, cause protocol operations to
 fail, interrupt network service or consume precious processor resources with needless
     cryptographic calculations.
 resources.

 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. applications. 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 sender, but modified or replayed by an intruder. The
 cryptographic means of the reference implementation are based on the rsaref2.0 algorithms,
 OpenSSL cryptographic software library available at www.openssl.org,
 but other algorithms libraries 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
 architecture, protocol and algorithms. The fundamental timestamp- timestamp
 exchange scheme is inherently resistant to replay attacks. The
 engineered clock filter, selection and clustering algorithms are
 designed to defend against Byzantine traitors and evil cliques. cliques of Byzantine traitors. While
 not necessarily designed to defeat determined intruders, these
 algorithms and accompanying sanity checks have functioned well over
 the years to deflect improperly operating but presumably friendly
 scenarios. However, these mechanisms do not securely identify and
 authenticate servers to clients. Without specific further protection,
 an intruder can inject any or all of the following mischiefs. Further
 discussion on the assumed intruder model is given in [9], but beyond
 the scope of this memorandum.

 1. An intruder can intercept and archive packets forever and can archive forever, as well as
 all the public values ever generated and transmitted over the net.

 2. An intruder can generate packets faster than the server or client
 can process them, especially if they require expensive PKI operations. cryptographic
 computations.

 3. An intruder can originate, intercept, modify and replay a packet.
 However, it cannot permanently prevent the original packet transmission over the
 net; that is, it cannot break the wire, only tell lies and congest it.
 In this memorandum a distinction is made between a middleman attack,
 where the intruder can modify and replace an intercepted packet, and a
 wiretap attack, where the intruder can modify and replay the packet
 only after the original packet has been received.

 The following assumptions are fundamental to the Autokey design. They
 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 elaborated
 in this memorandum.

 1. The running times for public-key public key algorithms are relatively long and
 highly variable. In general, the performance of the synchronization
 function is badly degraded if these algorithms must be used for every
 NTP packet.

 2. In some modes of operation it is not feasible for a server to
 retain
     cryptographic state variables for every client. It is however feasible to
 regenerated them for a client upon arrival of a packet from that
 client.

 3. The lifetime of cryptographic values must be enforced, which
 requires a reliable system clock. However, the sources that
 synchronize the system clock must be cryptographically proventicated.
 This circular interdependence of the timekeeping and proventication
 functions requires special handling.

 4. All proventication functions must involve only public values
 transmitted over the net. Private values must never be disclosed
 beyond the machine on which they were created.

 5. Public encryption keys and agreement parameters, where necessary, certificates must be retrievable
 directly from servers without requiring secured channels; however, the
 fundamental security of identification credentials and public values
 bound to those credentials must eventually be a function of external certificate
 authorities and/or webs of trust.

 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 cryptographic values are public, so there is no need to associate
 each interface with different cryptoraphic cryptographic values. In other words,
 there is one set of private secrets for the host, not one for each
 interface. In the NTP design the host name, as returned by the
 gethostname() Unix 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 following objectives. Again, in-depth discussions on these
 objectives is in the web briefings and will not be elaborated in this
 memorandum. Note that here and elsewhere in this memorandum mention of
 broadcast mode means multicast mode as well, with exceptions as noted. noted in
 the web page at www.eecis.udel.edu/~ntp/ntp_spool/html/assoc.htm.

 1. It must interoperate with the existing NTP architecture model and
 protocol design. In particular, it must support the symmetric-key symmetric key
 scheme described in RFC-1305. As a practical matter, the reference
 implementation must use the same internal key management system,
 including the use of 32-bit key IDs and existing mechanisms to store,
 activate and revoke keys.

 2. It must provide for the independent collection of cryptographic
 values and time values. A client is proventicated synchronized to a proventic source
 only when the all required cryptographic values have been obtained and
 verified and the NTP timestamps have passed all sanity checks.

 3. It must not significantly degrade the potential accuracy of the NTP
 synchronization algorithms. In particular, it must not make
 unreasonable demands on the network or host processor and memory
 resources.

 4. It must be resistant to cryptographic attacks, including
     replay/modification and clogging attacks. specifically those
 identified in the security model above. In particular, it must be
 tolerant of operation operational or implementation variances, such as packet
 loss or misorder, or suboptimal configuration. configurations.

 5. It must build on a widely available suite of cryptographic
 algorithms, yet be independent of the particular choice. In
 particular, it must not require data encryption other than incidental
 to signature encryption and verification functions. cookie encryption operations.

 6. It must function in all the modes supported by NTP, including
 client/server, broadcast and symmetric active/passive modes.

 7. It must not require intricate per-client or per-server
 configuration other than the availability of public/private key files the required
 cryptographic keys and agreement
     parameter files, as required. certificates.

 8. The reference implementation must contain provisions to generate
 cryptographic key values, including private/public keys and agreement
     parameters files specific to each client and server.
 Eventually, it must contain provisions to validate public values using
 certificate authorities and/or webs of trust.

 Autokey Proventication Scheme

 Autokey public-key public key cryptography is based on the PKI algorithms of the
     rsaref2.0 library, although other libraries with a compatible interface
     could be
 commonly used as well. The reference implementation in the Secure Shell and Secure Sockets Layer
 applications. As in these applications Autokey uses keyed-MD5 keyed message
 digests to detect packet modification, timestamped RSA digital signatures to verify
 the source, source and Diffie-Hellman key agreements to
     construct a private shared key from public values. However, there is no
     reason why alternative signature schemes and agreement key algorithms could
     be supported. to encrypt session keys or
 cookies. What makes Autokey cryptography unique is the way in which
 these algorithms are used to deflect intruder attacks while
 maintaining the integrity and accuracy of the time synchronization
 function.

 The NTP Version 3 symmetric-key symmetric key cryptography uses keyed-MD5 message
 digests with a 128-bit private key and 32-bit key ID. In order to
 retain backward compatibility, the key ID space is partitioned in two
 subspaces at a pivot point of 65536. Symmetric key IDs have given values
 less than
     65536 the pivot and indefinite lifetime. Autokey key IDs have
 pseudo-random values equal to or greater than 65536 the pivot and are
 expunged immediately after use.

 There are three Autokey protocol variants corresponding to each of the
 three NTP modes: client/server, broadcast and symmetric active/passive. symmetric. All three
 variants make use of a specially contrived session key keys, called
     an autokey
 autokeys, and a precomputed pseudo-random sequence of autokeys with
 the key IDs called the saved in a key list. As in the original NTP Version 3
 authentication scheme, the Autokey protocol operates separately for
 each association, so there may be several key lists autokey sequences operating
 independently at the same time and with
     distinct associated values and signatures. time.

 An autokey consists of is computed from four fields in network byte order as shown
 below:

         +-----------+-----------+-----------+-----------+
         | Source IP |  Dest IP  |  Key ID   |  Cookie   |
         +-----------+-----------+-----------+-----------+
     For use with IPv4,

 The four values are hashed by the Source IP and Dest IP fields contain 32 bits; for
     use with IPv6, MD5 message digest algorithm to
 produce the 128-bit key value, which in the reference implementation
 is stored along with the key ID in a cache used for symmetric keys as
 well as autokeys. Keys are retrieved from the cache by key ID using
 hash tables and a fast lookup algorithm.

 The NTP packet format has been augmented to include one or more
 extension fields piggybacked between the original NTP header and the
 message authenticator code (MAC) at the end of the packet. For packets
 without extension fields, the cookie is a shared private value
 conveyed in encrypted form. For packets with extension fields, the
 cookie has a default public value of zero, since these packets can be
 validated independently using digital signatures.

 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
 shared private value, depending on the mode.

 There are some scenarios where the use of endpoint IP addresses when
     calculating the autokey may be
 difficult or impossible. These include configurations where Network Address Translation 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
 For Autokey, the natural approach only restriction is that the addresses visible in the
 transmitted packet must be the same as those used to
     authenticate associations using construct the
 autokey sequence and key list and that these values. addresses be the same as
 those visible in the received packet. Provisions are included in the
 reference implementation to handle cases when these addresses change,
 as possible in mobile IP. For scenarios where this
     is the endpoint IP
 addresses are not possible, available, an optional public identification value can
 could be used instead of the endpoint IP addresses. The Parameter Negotiation message contains an
     option to specify these data; however, Examples include the format, encoding and use of
     this option
 Interplanetary Internet, where bundles 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
     extension fields piggybacked between the original NTP header and the
     message authenticator code (MAC) at the end of the packet. For packets
     without extension fields, the cookie is a private value computed identified by an
     agreement algorithm. For packets with extension fields, the cookie has a
     default public value of zero, since these packets can be validated
     independently using signed data in the extension fields. The four values name rather
 than address. Specific provisions are hashed by the message digest algorithm to produce the actual key
     value, which is stored along with the key ID in a cache used for
     symmetric keys as well as autokeys. Keys are retrieved from the cache by
     key ID using hash tables and a fast algorithm. further study.

 The key list consists of a sequence of key IDs starting with a 32-bit
 random private value and each pointing to the next. To generate called the next autokey on the
     key list, the next key ID seed. The associated autokey
 is computed as above using the specified cookie and the first 32 bits
 in network byte order of this value become the previous next key value. ID. Operations
 continue in this way to generate the entire list, which may have up to
 100 entries. It may happen that a newly generated key ID is less than 65536
 the pivot or collides with another one already generated (birthday
 event). When this happens, which should occur only rarely, the key
 list is terminated at that point. The lifetime of each key is set to
 expire one poll interval after its scheduled use. In the reference
 implementation, the list is terminated when the maximum key lifetime
 is about one hour.

 The index of the last key ID in the list is saved along with the next
 key ID of for that entry, collectively called the autokey values. The
 list is used in reverse order, so that the first key ID autokey used is the
 last one generated. The Autokey protocol includes a message to
 retrieve the autokey values and signature, so that subsequent packets
 can be
     authenticated validated using one or more hashes that eventually match the
 first key ID (valid) or exceed the index (invalid). This is called the
 autokey test in the following and is done for every packet, including
 those with and without extension fields. In the reference
 implementation the most recent key ID received is saved for comparison
 with the first 32 bits in network byte order of the next following key
 value. This minimizes the number of hash operations in case a packet
 is lost.

 Autokey Operations

 Autokey works differently in the various NTP modes. The scheme used in
 client/server mode was suggested by Steve Kent over
     lunch. lunch some time
 ago, but considerably modified since that meal. The server keeps no
 state for each client, but uses a fast algorithm and a private random
 value called the server seed to regenerate the cookie upon arrival of
 a client packet. The cookie is calculated in a manner similar to the
 autokey, but the key ID field is zero and the cookie field is the
     private value.
 server seed. The first 32 bits of the hash is the cookie used for the
 actual autokey calculation and is returned to by both the client on request. and server. It is thus
 specific to each client separately and of no use to other clients or
 an intruder. A client obtains the cookie and signature using

 In previous versions of the Autokey protocol and saves it for later use.

     In client/server mode the cookie is a relatively weak function was
 transmitted in clear on the assumption it was not useful to a
 wiretapper other than to launch an ineffective replay attack. However,
 an middleman could intercept the cookie and manufacture bogus messages
 acceptable to the client. In order to reduce the vulnerability to such
 an attack, the Autokey Version 2 server encrypts the cookie using a
 public key supplied by the client. While requiring additional
 processor resources for the encryption, this makes it effectively
 impossible to spoof a cookie.

 [Note in passing. In an attempt to avoid the use of overt encryption
 operations, an experimental scheme used a Diffie-Hellman agreed key as
 a stream cipher to encrypt the IP
     addresses cookie. However, not only was the
 protocol extremely awkward, but the processing time to execute the
 agreement, encrypt the key and sign the result was horrifically
 expensive - 15 seconds(!) in a server private value. The vintage Sun IPC. This scheme was
 quickly dropped in favor of generic public key encryption.]

 In client/server mode the client uses the cookie and each key ID on
 the key list in turn to calculate retrieve the autokey and generate the MAC for in
 the next NTP packet. The server calculates these uses the same values to generate the
 message digest and checks verifies it matches the MAC, MAC in the packet. It then
 generates the MAC for the response using the same values, but with the
 IP source and destination addresses exchanged. The client calculates generates
 the message digest and
     checks verifies it matches the MAC and in the packet. In
 order to deflect old replays, the client verifies the key ID matches
 the last one sent. In this mode the sequential structure of the key
 list is not exploited, but doing it this way simplifies and
 regularizes the implementation. implementation while making it nearly impossible for
 an intruder to guess the next key ID.

 In broadcast mode, mode clients normally do not send packets to the server,
 except when first starting up to calibrate the propagation delay in
 client/server mode. At the same time the client temporarily
     authenticates runs the Autokey
 protocol as in that mode. After obtaining and verifying the cookie,
 the client continues to obtain and verify the autokey values. To
 obtain these values, the client must provide the ID of the particular
 server association, since there can be more than one operating in the
 same
     machine. server. For this purpose, the NTP broadcast server packet includes the
 association ID in every packet sent, except when sending the first
 packet after generating a new key list, when it sends the autokey
 values instead.

 In symmetric mode each peer keeps state variables related to the other,
     so that a
 other. A shared private cookie can be computed by a strong agreement
     algorithm. The cookie itself is conveyed using the first 32 bits of same scheme as in
 client/server mode, except that the agreed key. cookie is a random value. The key
 list for each direction is generated separately by each peer and used
 independently, but each is generated with the same cookie.

     The server proventic bit is set only when the cookie or autokey values,
     depending on mode, and There
 exists a possible race condition where each peer sends a cookie
 request message before receiving the associated timestamp cookie response from the other
 peer. In this case, each peer winds up with two values, one it
 generated and signature are all
     valid. If one the bit other peer generated. The ambiguity is set, resolved
 simply by computing the working cookie as the exclusive-OR of the two
 values.

 Once the client processes NTP time values; if receives and validates the
     bit is not set, certificate, subsequent
 packets containing valid signed extension field messages fields are processed in order presumed to run
 contain valid time values, unless these values fall outside the Autokey protocol, but valid
 interval specified on the certificate. However, unless the system
 clock has already been set by some other proventic means, it is not
 known whether these values actually represent a truechime or falsetick
 source. As the protocol evolves, the NTP associations continue to
 accumulated time values until a majority clique is available to
 synchronize the system clock. At this point the NTP intersection
 algorithm culls the falsetickers from the population and the remaining
 truechimers are ignored. Packets with
     old allowed to discipline the clock.

 The time values for even falsetick sources form a proventic total
 ordering relative to the applicable signature timestamps. This raises
 the interesting issue of how to mitigate between the timestamps of
 different associations. It might happen, for instance, that the
 timestamp of some Autokey message is ahead of the system clock by some
 presumably small amount. For this reason, timestamp comparisons
 between different associations and between associations and the system
 clock are discarded immediately while avoiding expensive
     cryptographic algorithms. Bogus packets with newer timestamps must pass avoided, except in the MAC NTP intersection and autokey tests, which is highly unlikely. clustering
 algorithms.

 Once the proventic bit has Autokey values have been set, instantiated, the Autokey protocol is
 normally dormant. In all modes except broadcast server, broadcast, packets are normally
 sent without an extension field, fields, unless the packet is the first one sent
 after generating a new key list or unless the client has requested the
 cookie or autokey values. If for some reason the client clock is
 stepped, rather than slewed, all cryptographic and time values for all
 associations are purged and the Autokey protocol restarted from scratch.
     This insures
 scratch in all associations. This insures that stale values never
 propagate beyond a clock step.

     Public-Key

 Public Key Signatures

     Since public-key and Timestamps

 While public key signatures provide strong protection against
 misrepresentation of sources, probably the most obvious intruder
     strategy source, computing them is to deny or restrict service by replaying old packets with
     signed cryptographic values in a cut-and-paste attack. The basis values
     on which the cryptographic operations depend are changed often to
     deflect brute force cryptanalysis, so the client must be prepared to
     abandon an old key in favor of a refreshed one. expensive. This invites
 the opportunity for an intruder to clog the client or server by
 replaying old Autokey messages or to invent originate bogus new ones. messages. A client
 receiving such messages might be forced to refresh the correct value from the
     legitimate server verify what turns out to be
 an invalid signature and consume significant processor resources.

 In order to foil such attacks, every signed extension field carries a
 timestamp in the form of the NTP seconds at the signature time. epoch. The
 signature span includes the timestamp itself together with optional
 additional data. If the Autokey protocol has verified a proventic
 source and the NTP algorithms have validated the time values, the
 system clock is can be synchronized and signatures will then carry a
 nonzero (valid) timestamp. Otherwise the system clock is
 unsynchronized and signatures carry a zero (invalid) timestamp.
 Extension fields with invalid or old timestamps are discarded before any
 values are used or signatures verified.

 There are three signature types and six values to be signed: currently defined:

 1. Cookie signature/timestamp: Each association has a cookie for use
 when generating a key list. The public cookie value is determined along with
 the cookie signature and timestamp upon arrival of a cookie request
 message. The values are returned in a a cookie response message.

 2. Autokey signature/timestamp: Each association has a key list for
 generating the autokey sequence. The autokey values are determined
 along with the autokey signature and timestamp when a new key list is
 generated, which occurs about once per hour in the reference
 implementation. The values are returned in a autokey response message.

 3. Public values signature/timestamp: The public key, certificate and
 leapsecond table values are signed at the time of generation, which
 occurs when the system clock is first synchronized to a proventic
 source, when the values have changed and about once per day after
     that in the reference implementation. Besides the public value, the
     public key/host name, agreement parameters and leapseconds table are all
     signed as well,
 that, even if their these values have not changed. All four of these
     values carry the same timestamp. On request, During protocol
 operations, each of these values and associated signatures and
 timestamps are returned in an extension field.

     2. The cookie value is computed and signed upon arrival of a cookie the associated request message. The or response message contains the cookie, signature and
     timestamp message.
 While there are in an extension field.

     3. The autokey fact three public value signatures, the values are
 all signed when a new key list is generated, which
     occurs about once per hour in the reference implementation. On request, at the autokey values, signature and timestamp are returned in an extension
     field. same time, so there is only one public value
 timestamp.

 The most recent timestamp for each of the six values each type is saved for comparison. Once a
 valid signature with valid timestamp has been received,
     packets carrying extension fields messages with
 invalid timestamps or older earlier valid timestamps for of the same value type are
 discarded before the signature is verified. For packets containing signed extension fields, the timestamp messages this
 deflects replays that otherwise might consume significant processor
 resources; for other packets messages the Autokey protocol deflects message
 modification and replay. or replay by a wiretapper, but not necessarily by a
 middleman. In addition, the NTP protocol itself is inherently
 resistant to replays and consumes only minimal processor resources.

 All cryptographic values used by the protocol are time sensitive and
 are regularly refreshed. In particular, files containing cryptographic
 basis values used by signature and agreement encryption algorithms are
 regenerated from time to time. It is the intent that file regeneration and loading of
     these values
 regenerations occur without specific advance warning and without
 requiring prior distribution in advance. of the file contents. While files carrying cryptographic
 data files are not specifically signed, the every file names have extensions name includes an
 extension called filestamps
     which reliably determine the time of generation. The filestamp for a
     file filestamp, which is a string of decimal digits
 representing the NTP seconds at the generation epoch.

 Filestamps and timestamps can be compared in any combination and use
 the same conventions. It is necessary to compare them from time to
 time to determine which are earlier or later. Since these quantities
 have a granularity only to the file was created. second, such comparisons are ambiguous
 if the values are the same. Thus, the ambiguity must be resolved for
 each comparison operation as described below.

 It is important that filestamps be proventic data; thus, they cannot
 be produced unless the producer has been synchronized to a proventic
 source. As such, the filestamps represent a total ordering of creation
 epoches and serve as means to expunge old data and insure new data are
 consistent. As the data are forwarded from server to client, the
 filestamps are preserved, including those for the public key/host name, agreement
     parameters certificate and
 leapseconds table. files. Packets with older filestamps are discarded befor the signature is verified. Filestamps can in principle
     be used as a total ordering function before
 spending cycles to verify that the data are
     consistent and represent the latest available generation. For this
     reason, signature.

 Autokey Dances

 This section presents an overview of the files should always be generated on a machine when three Autokey protocols,
 called dances, corresponding to the
     system clock NTP client/server, broadcast and
 symmetric active/passive modes. Each dance is valid.

     When a client or server initializes, it reads its own public designed to be
 nonintrusive and private
     key files, which are required to require no additional packets other than for continued operation. Optionally, it
     reads the agreement parameters file
 regular NTP operations. The NTP protocol and constructs the public Autokey dance operate
 independently and
     private values to be used later in the agreement algorithm. Also
     optionally, it reads simultaneously and use the leapseconds table file. same packets. When reading these
     files it checks the filestamps for validity; for instance, all
     filestamps must be later than the time
 Autokey dance is over, subsequent packets are authenticated by the UTC timescale was established
 autokey sequence and thus considered proventic as well. Autokey
 assumes clients poll servers at a relatively low rate, such as once
 per minute. In particular, it is assumed that a request sent at one
 poll opportunity will normally result in 1972.

     When the client first validates a proventic source and when response before the clock next
 poll opportunity.

 The Autokey protocol data unit is
     stepped and when new cryptographic values are loaded from a server, the
     client recomputes all signatures and checks extension field, one or more of
 which can be piggybacked in the filestamps for validity
     and consistency NTP packet. An extension field
 contains 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 only one request. A response is generated for every
 request, even if the signature timestmaps:

     1. If the system clock requestor is not synchronized or proventicated.
 Some requests and most responses carry timestamped signatures. The
 signature covers the data, timestamp and filestamp, where applicable.
 Only if valid, the packet passes all timestamps and filestamps must be
     earlier than extension field tests is the current clock time.

     2. All signature timestamps must be later than
 verified.

 Dance Steps

 The protocol state machine is very simple. The state is determined by
 nine bits, four provided by the server, five determined by the public key timestamp.

     3. In broadcast client mode,
 association operations. The nine bits are stored along with the cookie timestamp must be later than
 digest/signature scheme identifier in the
     autokey timestamp.

     4. In symmetric modes host status word of the autokey timestamp must be later than
 server and in the
     public value timestamp.

     5. Timestamps for each cryptographic data type must be later than association status word of the
     filestamps for that type. client. In all dances
 the above constraints, note that timestamps client first sends an Association request message and filestamps have a
     granularity of one second, so that a difference of zero seconds receives the
 Association response specifying which cryptographic values the server
 is
     ambiguous. Furthermore, timestamps prepared to offer and filestamps can be in error as
     much as the value of digest/signature scheme it will use.

 If compatible, the synchronization distance; that is, client installs the sum of server status word as the root dispersion plus one-half
 association status word and sends a Certificate request message to the root delay. However,
 server. The server returns a Certificate response including the NTP
     protocol normally operates with polling intervals much longer than one
     second, so that successive timestamps for the same data type are
     nonambiguous. On most machines,
 certificate and signature. The reference implementation requires the processor time to generate a
     complete set of key files is longer than one second, so it is not
     possible
 certificate to generate two generations in the same second.

     However, it may happen that agreement parameters files may be generated
     on two machines with the same filestamps, self-signed, 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 serves as to be
     safely ignored, a good management approach might require that these
     files an additional
 consistency check. This check may be generated only on removed in future and replaced
 with a schedule that guarantees that no more than
     one certificate trail mechanism. If the certificate contents and
 signature are valid, NTP timestamps in this and subsequent messages
 with valid signatures are considered proventic.

 In client/server mode the client or server generates sends a new key file set on any one day.

     Certificates

     PKI principles call for the use of certificates to reliably bind Cookie request message
 including the
     server distinguished name (host name), public key and related values to
     each other. The certificate includes these values together with the
     distinguished name of the certificate atuthority (CA) and other values
     such host key. The server constructs the
 cookie as serial number described above and valid lifetime. These values are then signed
     by the CA encrypts it using its private this key. The Autokey protocol includes
     provisions to obtain It sends a
 Cookie response including the certificate, but at encrypted cookie to the present time does
     nothing with client and
 expunges all values resulting from the values. A future version of the protocol is to include
     provisions to validate the binding using procedures established by the
     IETF.

     Packet Processing Rules

     Exhaustive examination of possible vulnerabilities at the various
     processing steps of the NTP protocol as specified in RFC-1305 have
     resulted calculations in a revised list of packet sanity tests. These tests have been
     formulated order to harden remain
 stateless. The client verifies the protocol against defective header signature and data
     values. These are summarized below, since they are an integral component
     of decrypts the NTP cryptograhic defense mechanism. There are eleven tests,
     called TEST1 through TEST11 cookie.
 A similar dance is used in symmetric modes, but the reference implementation, which are
     performed in cookie is
 generated as a specific order designed to gain maximum diagnostic
     information while protecting against accidental or malicious errors.

     The tests are divided into three groups. random value.

 The first group is designed to
     deflect access control and authentication violations. While access
     control and message digest violations always result immediate discard,
     it cookie is necessary when first mobilizing an association used to disable construct the
     autokey test key list and certain timestamp tests. However, after the proventic
     bit is set, autokey values in all tests are enforced.

     The second group of tests is designed to deflect packets from broken or
     unsynchronized servers and replays.
 modes. In order to synchronize an
     association in symmetric modes, it client/server mode there is necessary no need to save the originate
     and receive timestamps in order provide these values
 to send them at a later time. This
     happens for the first packet that arrives, even if it violates server, so once the
     autokey test. In cookie has been obtained the normal case, client can
 generate the second packet to arrive will be
     accepted key list and validate succeeding packets directly. In
 other modes 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 retrieves the association.

     The third group of tests is designed to deflect packets with invalid
     header fields or time autokey values with excessive errors. However, from the server
 using an Autokey message exchange. Once these tests
     do not directly affect cryptographic source proventication or
     vulnerability, so are beyond values have been
 received, the scope of discussion in this document.

     For client validates succeeding 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 using the
     public key/host name, agreement paramaters, public value, cookie or autokey values, is valid
 sequence as described previously.

 A final exchange occurs when the accompaning timestamp and filestamp
     are valid. The public key must be instantiated before any signatures can
     be verified. In symmetric modes server has the agreement parameters must be
     instantiated before leapseconds table, as
 indicated in the public host status word. If so, the client obtains the table
 and private agreement values can be
     determined; compares the public agreement value must be instantiated before filestamp with its own leapseconds table filestamp,
 if available. If the
     agreement algorithm can be run to determine server table is newer than the cookie. In all modes client table, the
     cookie value must be determined before
 client replaces its table with the key list can be generated. server table. The object of client, acting as
 server, can now provide the Autokey dances described below is most recent table to set the proventic
     bit. any of its own
 dependent clients. In client/server mode symmetric modes, this bit is set when results in both peers
 having the cookie is validated.
     In other modes this bit is set when the autokey values are validated.
     The bit is cleared initially newest table.

 Status Words

 Each sever and when the autokey test fails. If once
     the bit is set client operating as a server implements a host status
 word and then cleared, the protocol will send an autokey
     request message at association status word with the next poll opportunity format and continue to send this
     message until receiving valid autokey values content shown
 below. The low order four host status bits are lit during host
 initialization, depending on whether cryptographic data files are
 present or a general reset occurs.

     This behavior is a compromise between protocol responsiveness, where not; the
     current next four association can be maintained without interruption, and protocol
     vulnerability, where an intruder can repeatedly clog bits are dark. There are two
 additional bits implemented separately. The high order 16 bits specify
 the receiver with
     replays that cause message digest/signature encryption scheme.

 The host status word is provided to clients in the Association
 response message. The client to needlessly poll initializes the server association status word
 and then lights and refresh dims the values.

     Error Recovery association bits as the dance proceeds.

                      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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |               |L|K|C|A|L|S|E|E|
 |     Digest/Signature NID      | Reserved      |P|E|K|U|P|I|N|N|
 |                               |               |T|Y|Y|T|F|G|C|B|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The protocol state machine which drives host status bits are defined as follows:

 ENB - Lit if the server implements 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 is
 prepared to mention hostile intrusion. There are two mechanisms
     which maintain the liveness state of the protocol, the reachability
     register defined in RFC-1305 and dance.

 ENC - Lit if the watchdog timer, which is new in NTP
     Version 4.

     The reachability register server has loaded a valid encryption key file. This
 bit is normally lit, but can dim if an 8-bit register that shifts left with
     zero replacing error occurs.

 SIG - Lit if the rightmost bit. A shift occurs for every poll
     interval, whether or not server has loaded a poll valid signature key file. This
 bit is actually sent. If an arriving packet
     passes all authentication included primarily for error supervision and sanity checks, can be either lit
 or dim.

 LPF - Lit if the rightmost server has loaded a valid leapseconds file. This bit
 can be either lit or dim.

 The client association status bits are defined as follows:

 AUT - Lit when the certificate is set to
     one. If any bit present and validated. When lit,
 signed values in this register is one, subsequent messages are presumed proventic.

 CKY - Lit when the server is reachable,
     otherwise it cookie is unreachable. If the server was once reachable first received and then
     becomes unreachable, a general reset is performed. A general reset
     reinitializes all association variables to the state validated.

 KEY - Lit when the autokey values are first
     mobilized received and returns all acquired resources validated.
 When lit, clients can validate packets without extension fields
 according to the system. In addition,
     if autokey sequence.

 LPT - Lit when the association leapseconds table is received and validated.

 An additional bit LST not configured, it is demobilized until part of the next
     packet is received.

     The watchdog timer increments for every poll interval, whether or not a
     poll association status word lights
 when the key list is actually sent regenerated and regardless of signed and dims when the reachability state. The
     counter autokey
 values are transmitted. This is set necessary to zero upon arrival avoid livelock under some
 conditions.

 An additional bit LBK not part of a packet from a proventicated
     source, as determined by the Autokey protocol. In the reference
     implementation, if the counter reaches 16 a general reset is performed.
     In addition, if association status word lights
 when the association is configured, transmit timestamp matches the poll interval is
     doubled. This reduces packet originate
 timestamp and dims otherwise. If lit, this confirms the network load for packets that are unlikely to
     elicit a response.

     At each state packet was
 received in the protocol the client expects a particular response
     from to one previously sent by this association.

 Host State Variables

 Host Name
 The name of the server. A request is included in host returned by the NTP message sent at every
     poll interval until Unix gethostname() library
 function. It must agree with the authentic response is received or a general
     reset occurs, subject and issuer name in which case the protocol restarts
 certificate.

 Host Key
 The RSA key from the beginning.
     While this behavior might be considered rather conservative, the
     advantage is that old cryptographic host key file and time values can never persist
     from one mobilization used to encrypt/decrypt
 cookies. It carries the next.

     There are a number of situations where some action on an association
     causes the remaining autokeys on public value timestamp and the key list to become invalid. When
     one of these situations happens, filestamp at
 the host key list and associated keys in file creation epoch. This is also the signature key,
 unless a signature key cache are purged.  A new is specified.

 Public Key
 The public encryption key list, signature and timestamp are
     generated when for the next NTP message is sent, assuming there is one.
     Following is a list of these situations.

     1. When the cookie value changes for any reason.

     2. When a client switches Cookie request message and derived
 from client/server mode to broadcast client
     mode. There is no further need for the key list, since the client will
     not transmit again.

     3. When host key. It carries the poll interval is changed. In this case public value timestamp and the calculated
     expiration times for
 filestamp at the keys become invalid.

     4. When a general reset is performed.

     5. If a problem is detected when an entry is fetched host key file creation epoch.

 Sign Key
 The RSA or DSA key from the sign key list.
     This could happen if file and used to encrypt
 signatures. It carries the key was marked non-trusted or timed out, either
     of which implies a software bug.

     6. When public value timestamp and the cryptographic values are refreshed, filestamp at
 the sign key lists for all
     associations are regenerated.

     7. When file creation epoch.

 Certificate
 The X.509 certificate from the client is first proventicated or certificate file. It carries the system clock is
     stepped, public
 value timestamp and the key lists for all associations are regenerated.

     Autokey Protocols

     This section describes filestamp at the Autokey protocols supporting
     cryptographically secure server proventication. There are three
     subprotocols, called dances, corresponding to certificate file creation
 epoch.

 Leapseconds Table, Leapseconds Table Filestamp
 The NIST leapseconds table from the NTP client/server,
     broadcast NIST leapseconds file. It carries
 the public value timestamp and symmetric active/passive modes. While Autokey messages are
     piggybacked in NTP packets, the NTP protocol assumes clients poll
     servers filestamp 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.

     It is important to observe that, while the Autokey dances are obtaining
     and validating cryptographic values, the underlying NTP protocol
     continues to operate. Most packets used during leapseconds file
 creation epoch.

 Digest/signature NID
 The identifier of the dances contain
     signatures, so message digest/signature encryption scheme
 derived from the values can be believed even before sign key. It must agree with the dance has
     concluded. Since signatures are valid once NID on the certificate has been
     validated during
 certificate.

 Client Association State Variables

 Peer Association ID
 The association ID of the initial steps peer as received in a response message.

 Host Name
 The name of the dance, host returned by the time the Autokey
     values are validated the clock is usually already set. In this way Association response. It must
 agree with the
     sometimes intricate Autokey dance interactions do not delay subject name in the
     accumulation certificate.

 Digest/Signature NID
 The identifier 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" message digest/signature encryption scheme
 returned in the descriptions applies to Association response message. It must agree with the next poll
     opportunity.
 value encoded in the certificate.

 Public Values Timestamp
 The Autokey protocol data unit is timestamp returned by the extension field, one latest Certificate response, Cookie
 request or more of
     which can be piggybacked Leapseconds message.

 Certificate
 The X.509 certificate returned in the NTP packet. An extension field contains
     either a request with optional data or a certificate response message,
 together with data. To avoid
     deadlocks, any number of responses can be included its timestamp and filestamp.

 Cookie
 The cookie returned in a packet, but only
     one request. Some requests and most responses are protected by
     timestamped signatures. The signature covers the data, Cookie response message, together with its
 timestamp and
     filestamp, where applicable. filestamp.

 Receive Autokey values
 The autokey values returned in an Autokey response message, together
 with its timestamp is set to the default (zero)
     when the sender is not proventicated; otherwise, it is set to the NTP
     seconds when and filestamp.

 Server Association State Variables (broadcast and symmetric modes)

 Association ID
 The association ID of the signature was generated. server for use in client request messages.

 Send Autokey Values
 The following rules are
     designed to detect invalid header or data fields autokey values, signature and timestamp.

 Key List
 A sequence of key IDs starting with a random autokey seed and each
 pointing to deflect clogging
     attacks. Each extension field is validated in the following order and
     discarded if:

     1. The request or response code next. It is invalid or computed timestamped and signed at the data field has
     incorrect length.

     2. The signature field
 next poll opportunity when the key list is either missing or has incorrect length.

     3. empty.

 Autokey Seed
 The public private value used to initialize the key list. It is missing or has incorrect length.

     4. In the case randomized
 for each new key list.

 Current Key Number
 The index of the agreement algorithm, entry on the agreement parameterss are
     missing or have incorrect lengths.

     5. Key List to be used at the next poll
 opportunity.

 Send Encrypt Values (symmetric modes only)
 The encrypted cookie, signature and timestamp is earlier than the last received timestamp computed upon arrival of
 the same type or the two timestamps Cookie request message. These data are equal and the proventic bit
     is set..

     6. Where applicable, held until the filestamp is earlier than next poll
 opportunity.

 Server seed
 The private value hashed with the last received
     filiestamp of IP addresses to construct the same type.

     Only if the extension field passes all the above tests is the signature
     verified using PKI algorithms. Otherwise and cookie
 used in general, a response client/server mode. It is
     generated for every request, even if randomized when 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, public value
 signatures are present and verifiable.

     In the refreshed.

 Autokey protocol every transmitted packet is associated with an
     autokey previously computed Messages

 There are currently five Autokey request types 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 five corresponding
 responses. An abbreviated description of the cookie value. If for some reason the
     cookie value these messages is changed, given
 below; the remaining entries detailed formats are described in Appendix A.

 Association Message (1)
 The client sends the key list are
     purged and a new one constructed. However, if an extension field is
     present, request to retrieve the current autokey is discarded host status word and host
 name. The server responds with these values.

 Certificate Message (2)
 The client sends the autokey reconstructed
     using a cookie value of zero.

     A timestamp-based agreement protocol is used request to manage retrieve the distribution
     of server certificate. The
 server responds with the certificate, agreement parameters and leapseconds table. certificate.

 Cookie Message (3)
 The
     association ID request and response messages include client sends the certificate,
     agreement and leapseconds bits from request, including the system status word. one or more public member 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 host
 key, to a
     client in client/server mode or a peer in symmetric mode, the data are
     requested from retrieve the cookie. The server or peer and, once obtained, the bits are
     reset. However, responds with the response data are stored only if more recent than cookie
 encrypted with the data already stored.

     In public key.

 Autokey Message (4)
 The client sends the descriptions below, it is assumed that request to retrieve the client and server have
     loaded their own private key and public key, as well as certificate,
     agreement parameters and leapseconds table, where autokey values, if
 available. Public keys
     for other servers, as well as The server responds with these values.

 Leapseconds Message (5)
 The client sends the agreement parameters and request including its 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 if
 available. The first thing server responds with its own leapseconds table. Both
 the client and server needs agree to do is obtain use the system version with the latest
 filestamp.

 State Transitions

 The state transitions of the three dances are shown below. The
 capitalized truth values represent the association status word,
     which reveals word bits,
 except for the SYNC value, which cryptographic values is true when the server host is prepared synchronized
 to
     offer, and then the public key a proventic source and certificate. These steps false otherwise. All truth values are
     independent of which mode
 initialized false and become true upon the server is operating arrival of a specific
 response messages, as detailed in - client/server,
     broadcast or symmetric modes. the above status bits description.

 Client/Server Dance

 The following pseudo-code describes client/server dance begins when 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 sends an Association
 request message can be used to
     negotiate algorithm identifiers, parameters and alternate identification
     values. Note that the association ID response message also contains server. It ends upon arrival of the
     system status word, Cookie
 response, which contains lights the certificate bit. CKY and KEY bits. Subsequent packets
 received without extension fields are validated by the autokey
 sequence. An optional final exchange is possible to retrieve the
 leapseconds table.

         while (1) {
                 wait_for_next_packet;
                 make_NTP_header;
                 if (response_pending) (response_ready)
                         send_response;
                 if (!parameters)
                     request_parameters; (!ENB)
                         send_Association_request;
                 else if (!association_ID)
                     request_association_ID; (!CRF)
                         send_Certificate_request;
                 else if (!public_key)
                     request_public_key; (!CKY)
                         send_Cookie_request;
                 else if (certificate_bit)
                     request_certificate; (LPF & !LPT)
                         send_Leapseconds_request;
         }
 Broadcast Client Dance

 The following diagram shows the preliminary protocol dance. In this and
     following diagrams the NTP packet type is shown above broadcast client dance begins when the arrow and client receives the
     extension field(s) message type shown below. Note that in first
 broadcast packet, which includes an Association response with the
     client/server mode
 association ID. The broadcast client uses the server responds immediately association ID to the request, but
     in the symmetric modes the response may be delayed for
 initiate a period up client/server dance in order to calibrate the current poll interval. propagation
 delay. The following cryptographic values dance ends upon arrival of the Autokey response, which
 lights the KEY bit. Subsequent packets received without extension
 fields are
     instantiated validated  by the dance:

     public key      server public key
     host name autokey sequence. An optional final
 exchange is possible to retrieve the leapseconds table. When the
 server host name
     CA name         certificate authority host name (optional)
     filestamp       generation time of public generates a new key file
     secure bit      set when list, 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 replaces the Association
 response 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 Autokey 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 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
     proventic bit   set when client clock is synchronized to source

       server             client
         |                  |
         |    NTP client    |
       7 |<-----------------| request cookie
         |    cookie req    |
         |                  |
         |    NTP server    |
       8 |----------------->| store cookie and timestamp; set proventic bit;
         |    cookie rsp    |
         |       ...        |
         |                  |
         |    NTP client    |
       9 |<-----------------| regenerate key list with server cookie
         |                  |
         |    NTP server    |
      10 |----------------->|
         |                  |
         |     continue     |
         =  client/server   =

     The dance begins when the client on the right mobilizes an association
     and validates the public key as in the preliminary dance above. Some
     time later the client sends a cookie request (7). The server immediately
     responds with the cookie and timestamp (8). The client checks the
     timestamp, verifies the signature and initializes the cookie and cookie
     timestamp, then sets the proventic bit. Since the cookie has changed,
     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
     fields, unless an error occurs or the server generates a new private
     value. When this happens, the server fails to authenticate packet (9)
     and, following the original NTP protocol, responds with a NAK packet
     (10), which the client ignores. Eventually, an association timeout and
     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.

     Broadcast Mode (5)

     In broadcast mode, packets are always sent with an extension field.
     Since the autokey values for these packets use a well known default
     cookie (zero), they can in principle be remanufactured with a new MAC
     acceptable to the receiver; however, the key list provides the
     authentication function as described earlier. The broadcast server keeps
     no state variables specific to each of possibly very many clients and
     mobilizes no associations for them.

     The following pseudo-code describes the broadcast server state machine
     operations. Each broadcast packet includes one response message
     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
         |                  |
         |   NTP broadcast  |
       1 |----------------->| mobilize broadcast client association; set
         |   assoc ID rsp   | initially to operate in client/server mode
         |                  |
         |       ...        | continue as in preliminary protocol above
         |                  |
         |    NTP client    |
       7 |<-----------------| request cookie
         |    cookie req    |
         |                  |
         |    NTP server    |
       8 |----------------->| store cookie and timestamp
         |    cookie rsp    |
         |       ...        |
         |                  |
         |    NTP client    |
       9 |<-----------------| regenerate key list with server cookie
         |    autokey req   |
         |                  |
         |    NTP server    |
      10 |----------------->| store autokey values and timestamp; set
         |    autokey rsp   | proventic bit
         |       ...        |
         |                  |
         |    NTP client    |
         |<-----------------| continue to accumulate time values
         |                  |
         |    NTP server    |
         |----------------->|
         |                  |
         |     continue     |
         =      volley      =
         |                  |
         |    NTP client    |
         |<-----------------|
         |                  |
         |    NTP server    |
         |----------------->| set clock and propagation estimate; discard
         |                  | remaining keys; switch to broadcast client mode
         |     continue     |
         =     broadcast    =
         |                  |
         |   NTP broadcast  |
         |----------------->| server rolls new key list; client refreshes
         |    autokey rsp   | autokey values
         |                  |
         =                  =

     The server sends broadcast packets (1) continuously at intervals of
     about one minute using the key list and regenerating the list as
     required. The first packet sent after regenerating the list includes the
     autokey values and signature; other packets include only the association
     ID and status word.

     The dance begins when the client on the right receives a broadcast
     message (1). It mobilizes a broadcast client association set initially
     to operate in client/server mode. It then continues to operate as in the
     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 sends a cookie request (7). The server
     immediately responds with the requested value (8). The client checks the
     timestamp, verifies the signature and initializes the cookie and cookie
     timestamp. Since the cookie has changed, 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.

     If an autokey response happens to be in one of the server packets (1),
     the client has stored the autokey values and autokey timestamp, so can
     switch immediately to broadcast client mode and send no further packets.
     Otherwise, some time later the client sends an autokey request (9). The
     server immediately responds with the values (10). The client checks the
     timestamp, verifies the signature and initializes the autokey values and
     autokey timestamp and sets the proventic bit. The client retransmits
     packet (9) until receiving a valid response (10) or association timeout.

     After successful verification, there is no further need for extension
     fields and the client can switch to broadcast client mode and send no
     additional packets. However, it is the usual practice to send additional
     client/server packets in order for the client mitigation algorithms to
     refine the clock offset/delay estimates. When a sufficient number of
     estimates are available, the client discards the cookie and remaining
     keys on the key list, switches to broadcast client mode, calculates the
     propagation delay and sets the clock.

     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,
     since each peer in the relationship can operate as a server with the
     other operating as a client. Which peer acts as the server depends on
     which peer has the smallest root synchronization distance to its
     ultimate reference source, and the choice may change from time to 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 simplest
     scenario is where both peers have configured associations that operate
     continuously in symmetric active mode and cryptographic values such as
     the public key/host name, certificate, agreement parameters and public
     value can be configured in advance. A more interesting scenario is when
     a symmetric active peer with a configured association begins operation
     with a symmetric-passive peer initially without such an association.

     The following pseudo-code describes the symmetric state machine
     operations. Note that the packet can contain one request and one or two
     responses. The machine requires the association ID, public key,
     certificate, agreement parameters, agreement public value, autokey
     values and leapseconds table in that order. There is a provision to send
     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.

             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    |
       1 |<-----------------| mobilize symmetric active association; generate
         |   assocID req    | key list with default cookie; send status word
         |                  |
         |       ...        | 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   |
       2 |----------------->| verify passive credentials
         |   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   |
         |       ...        |
         |                  |
         |    NTP active    |
       3 |----------------->| set authentic
         |    autokey rsp   |
         |    autokey req   |
         |       ...        |
         |                  |
         |    NTP passive   |
       4 |<-----------------|
         |    autokey rsp   |
         |       ...        |
         |                  |
         |    NTP active    |
       5 |----------------->| regular operation (no extension fields)
         |       ...        |
         |                  |
         |    NTP passive   |
       6 |<-----------------|
         |                  |
         |     continue     |
         =  active/passive  =

     The agreement parameters must have been previously obtained by at least
     one of the peers, either directly from a file or indirectly from another
     server running packet sent.

         while (1) {
                 wait_for_next_packet;
                 make_NTP_header;
                 if (response_ready)
                         send_response;
                 if (!ENB)
                         send_Association_request;
                 else if (!CRF)
                         send_Certificate_request;
                 else if (!CKY)
                         send_Cookie_request;
                 else if (!KEY)
                         send_Autokey_request;
                 else if (LPF & !LPT)
                         send_Leapseconds_request;
         }

 Symmetric Dance

 The symmetric active dance begins when the Autokey protocol. A active peer needing the parameters sends an agreement parameters
 Association request to the other passive peer. The passive peer mobilizes an
 association and that peer responds
     with steps the requested data. This exchange, along with same dance from the leapseconds table
     exchange, beginning. Until the
 active peer is similar synchronized to a proventic source (which could be the public key/host name exchange, but not shown
     here.

     Once
 passive peer) and can sign messages, the proventic bit is set, passive peer will loop
 waiting to light the next message sent by CRF bit and the active peer
     contains the public key/host name requested by will skip the passive peer, but now
     with valid timestamp, plus a public value request containing cookie
 exchange.

 Meanwhile, the active peer public value (1). The passive peer checks the public key/host name
     filestamp and timestamp, verifies retrieves the signature certificate and initializes autokey
 values from the
     values. Optionally, it checks its access control list passive peer and queries lights the
     DNS using KEY bit. When for some
 reason either peer generates a new key list, at the server IP address to obtain related cryptographic values.
     Conceivably, first opportunity
 the active peer could be found bogus at this time; what sends the autokey values; that is, it pushes the values
 rather than pulls them. This is to
     do in this case prevent a possible deadlock where
 each peer is waiting for further study.

     The passive peer next checks the public value request timestamp,
     verifies values from the signature and runs other one.

         while (1) {
                 wait_for_next_packet;
                 make_NTP_header;
                 if (response_ready)
                         send_response;
                 if (!ENB)
                         send_Association_request;
                 else if (!CRF)
                         send_Certificate_request;
                 else if (!CKY & SYNC)
                         send_Cookie_request;
                 else if (LST)
                         send_Autokey_response;
                 else if (!KEY)
                         send_Autokey_request;
                 else if (LPF & !LPT & SYNC)
                         send_Leapseconds_request;
         }

 Once the agreement algorithm active peer has synchronized to construct the
     shared cookie. Since the cookie a proventic source, it
 includes timestamped signatures with its messages. The passive peer,
 which has changed, been stalled waiting for the peer regenerates CRF bit to light and the
     key list with this cookie when active
 peer, which now finds the SYNC bit lit, continues their respective
 dances. The next packet is sent.

     Some time later the passive message sent by either peer sends is a public value response including Cookie request. The
 recipient rolls a random cookie, lights its own public value together with an autokey request (2). CKY bit and returns the
 encrypted cookie in the Cookie response. The active
     peer checks recipient decrypts the timestamp, verifies
 cookie and lights its CKY bit.

 It is not a protocol error if both peers happen to send a cookie
 request at the signature same time. In this case both peers will have two
 values, one generated by one peer and runs the agreement
     algorithm to construct other received from the shared cookie. Since
 other peer. In such cases the working cookie has changed, is constructed as the peer regenerates
 exclusive-OR of the key list with this cookie when two values.

 At the next packet
     is sent. The active transmission opportunity, either peer retransmits generates a
 new key list and lights the public value LST bit; however, there may already be an
 Autokey request (only) (1)
     at every poll opportunity until receiving a valid response (2) or
     association timeout.

     Some time later queued for transmission and the active rules say no more than
 one request in a packet. When available, either peer sends its autokey values as requested
     together with an Autokey
 response and clears the LST bit. The recipient initializes the autokey request (3).
 values, clears the LST bit and lights the KEY bit. Subsequent packets
 received without extension fields are validated by the autokey
 sequence.

 The passive peer checks above description assumes the
     timestamp, verifies active peer synchronizes to the signature, initializes
 passive peer, which itself is synchronized to some other source, such
 as a radio clock or another NTP server. In this case, the autokey values and
     sets its proventic bit. The passive active peer retransmits request (2)
 is operating at
     every poll opportunity until receiving a valid response (3) or
     association timeout.

     Some time later stratum level one greater than the passive peer sends and
 so the passive peer will not synchronize to it unless it loses its autokey values as requested
     (4). The own
 sources and the active peer checks the timestamp, verifies itself has another source.

 Key Refreshment

 About once per day the signature, server seed is randomized and
     initializes the autokey values (the proventic bit is already set). signatures
 recomputed. The
     active retransmits the autokey request (only) (3) until receiving a
     valid response (4) or association timeout.

     At this point both peers have completed operations are:

         while (1) {
                 wait_for_next_refresh;
                 crank_random_generator;
                 generate_autokey_private_value;
                 if (!SYNC)
                         continue;
                 update_public_value_timestamp;
                 compute_signatures;
         }

 Error Recovery

 The protocol state machine which drives the various Autokey dance operations
 includes provisions for various kinds of error conditions that can
 arise due to missing files, corrupted data, protocol violations and each is
     authenticated
 packet loss or misorder, not to mention hostile intrusion. There are
 two mechanisms which maintain the other. However, note that liveness state of the protocol, the
 reachability register defined in RFC-1305 and the watchdog timer,
 which is new in NTP rules require Version 4.

 The reachability register is an 8-bit register that shifts left with 0
 replacing the rightmost bit. A shift occurs for every poll interval,
 whether or not a
     peer operating at poll is actually sent. If an arriving packet passes
 all authentication and sanity checks, the rightmost bit is set to 1.
 If any bit in this register is a lower stratum disregards time values from 1, the server is reachable, otherwise
 it is unreachable. If the server was once reachable and then becomes
 unreachable, a hither
     stratum peer; so, while general reset is performed. A general reset
 reinitializes all association variables to the peers continue state when first
 mobilized and returns all acquired resources to exchange time values, the
     values will system. In
 addition, if the association is not be used unless configured, it is demobilized
 until the passive server for some reason loses
     its synchronization source.

     After successful authentication, there next packet is no further need received.

 The watchdog timer increments for extension
     fields, unless an error occurs every poll interval, whether or one not
 a poll is actually sent and regardless of the peers generates new public
     values. reachability state. The protocol requires that, if a peer receives
 counter is set to zero upon arrival of a public value
     resulting in packet from a different cookie, it must send its own public value.
     Since proventicated
 source, as determined by the autokey values are included in an extension field when Autokey protocol. In the reference
 implementation, if the counter reaches 16 a new
     key list is generated, there general reset is ordinarily no need to request these
     values, unless one or
 performed. In addition, if the other peer restarts association is configured, the protocol or poll
 interval is doubled. This reduces the packet
     containing network load for packets that
 are unlikely to elicit a response.

 At each state in the autokey values is lost. Eventually, an association
     timeout and general reset occurs and protocol the dance restarts client expects a particular response
 from the
     beginning.

     Security Analysis

     This section discusses server. A request is included in the most obvious security vulnerabilities NTP message sent at each
 poll interval until a valid response is received or a general reset
 occurs, in which case the
     various modes and phases protocol restarts from the beginning. In
 some cases noted below, certain kinds of operation. Throughout errors cause appropriate
 action which avoids the discussion somewhat lengthy timeout/restart cycle. While
 this behavior might be considered rather conservative, the advantage
 is that old cryptographic algorithms themselves and time values can never persist from one
 mobilization to the next.

 There are assumed secure; that is, a
     successful brute force attack on the algorithms or public/private keys
     or agreement values is unlikely. However, vulnerabilities remain in number of situations where some event happens that causes
 the
     way remaining autokeys on the actual cryptographic data, including key list to become invalid. When one of
 these situations happens, the cookie key list and autokey
     values, associated autokeys in the
 key cache are computed purged. A new key list, signature and used.

     While timestamp are
 generated when the protocol has not been subjected to a formal analysis, next NTP message is sent, assuming there is one.
 Following is a few
     preliminary observations are warranted. The protocol cannot loop forever
     in list of these situations.

 1. When the cookie value changes for any state, reason.

 2. When a client switches from client/server mode to broadcast mode.
 There is no further need for the key list, since the association timeout and client will not
 transmit again.

 3. When the poll interval is changed. In this case the calculated
 expiration times for the keys become invalid.

 4. When a general reset insure
     that is performed.

 5. If a problem is detected when an entry is fetched from the association variables will eventually be purged and 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
     protocol will start from signatures are refreshed, the beginning. A general reset is performed on key lists for all
 associations when are purged.

 7. When the clock is first set and when it client is stepped
     after that. This purges all cryptographic values and time values
     dependent on unproventicated sources.

     The first exchange in all protocol modes involves an association ID
     request and response cycle. Bits in the server status word indicate
     whether synchronized or the server has system clock is
 stepped, the agreement paramters and/or leapseconds table.
     The association ID messages key lists for all associations are not protected by a signature, so
     presumably an intruder can manufacture fake bits causing purged.

 There are special cases designed to quickly respond to broken
 associations, such as when a client
     livelock server restarts or deadlock condition. To protect against this vulnerability, refreshes keys. Since
 the transmit timestamp of client cookie is invalidated, the server rejects the next client
 request is matched against and returns a crypto-NAK packet. Since the originate
     timestamp of crypto-NAK has no
 MAC, the response. The response problem for the client is accepted only if to determine whether it is
 legitimate or the two
     values match. An result of intruder is unlikely mischief. In order to predict reduce the transmit timestamp,
     which in this case is an effective nonce.

     Once
 vulnerability to such mischief, the clock crypto-NAK is set, and except for believed only if the special cases summarized
     below, no old or duplicate values will be accepted in any state and an
     intruder cannot induce
 result of a clogging attack, since previous packet sent by the MAC, autokey and
     timestamp tests will discard packets before a clogging vulnerability is
     exposed. While significant vulnerabilities exist during client, as confirmed by the
 LBK status bit. This bit is lit in the initial NTP protocol states while if the necessary values are being obtained, packet
 originate timestamp matches the most
     an intruder association transmit timestamp. While
 this defense can do is prevent the protocol dance from completing. If be easily circumvented by a middleman, it does complete, it must complete correctly.
 deflect other kinds of intruder warfare. The cryptographic values are always obtained in the same order LBK bit is also used to
 validate most responses and some requests as well.

 Security Analysis

 This section discusses the most obvious security vulnerabilities in
 the same order as various Autokey dances. Throughout the discussion the dependency relationships between them. No
 cryptographic variables or time variables algorithms themselves are instantiated unless assumed secure; that is, a
 brute force cryptanalytic attack will not reveal the
     server is proventic and proventicated. The public key and host name must private key
 or sign private key or cookie value or server seed or autokey seed or
 be obtained first and no other messages able to predict the random generator values.

 There are accepted until they have
     been obtained. three tiers of defense against intruder attacks. The first
 is a keyed message digest including a secret cookie must be obtained before conveyed in
 encrypted form. A packet is discarded if the message digest does not
 match the MAC. The second tier is the autokey values
     that depend on them, etc. Finally, in symmetric modes, both peers obtain
     cryptographic values sequence, which is
 generated by repeated hashes starting from a secret server seed and
 used in reverse order. While any receiver can authenticate a packet
 relative to the last one received and by induction to a signed
 extension field, as a practical matter a wiretapper cannot predict the
 next autokey and thus cannot spoof a valid packet. The third tier is
 timestamped signatures which reliably bind the same order, so deadlock cannot occur.

     Some observations on autokey values to the particular engineering constraints
 private key of a trusted server.

 In addition to the
     Autokey protocol three-tier defense strategy, all packets are in order. First,
 protected by the number NTP sanity checks. Since NTP packets carry time
 values, replays of bits old or bogus packets can be deflected once the
 client has synchronized to proventic sources. Additional sanity checks
 involving timestamps and filestamps are summarized in some
     cryptographic values Appendix C.

 During the Autokey dances when extension fields are considerably smaller than would ordinarily be
     expected for strong cryptography. One of in use, the reasons for this cookie
 is the
     need for compatibility a public value (0) rather than a shared private value. Therefore,
 an intruder can easily construct a packet with previous NTP versions; another is a valid MAC; however,
 once the need
     for small and constant latencies certificate is stored, extension fields carry timestamped
 signatures and minimal processing requirements.
     Therefore, what the scheme gives up on bogus packets are readily avoided. While most request
 messages are unsigned, only the strength of these values must
     be regained by agility Association response message is
 unsigned. This message is used in the rate of change of the cryptographic basis
     values. Thus, autokeys are used only once first packet sent by a server or
 peer and basis values are
     regenerated frequently. However, in most cases even NTP broadcast packets.

 A bogus Association response message can cause a successful
     cryptanalysis of client livelock or
 deadlock condition. However, these packets do not affect NTP time
 values compromises only a particular
     client/server association and does not represent do not consume significant resources. To reduce the
 vulnerability to bogus packets, the NTP transmit timestamp in the
 Association and Certificate request messages is used as a danger nonce. The
 NTP server copies this value to the general
     population.

     There are three tiers of defense against hostile intruder interference.
     The first is originate timestamp in the message authentication code (MAC) based on a keyed
     message digest or autokey generated as NTP
 header, so that the hash of client can verify that the IP address
     fields, key ID field and message is a special cookie, which can be public or response
 to the
     result of original request. To minimize the possibility that an agreement algorithm. If intruder
 can guess the message digest computed by nonce, the client does not match should fill in the value low order unused
 bits in the MAC, either transmit timestamp with random values. In addition,
 replays of all except Autokey response messages are discarded before
 the autokey used a
     different cookie than signatures are verified.

 In client/server and symmetric modes extension fields are no longer
 needed after the server or Autokey dance has concluded. The client validates the
 packet was modified by an
     intruder. Packets that fail this test are discarded without further
     processing; in particular, without spending processor cycles on
     expensive public-key algorithms.

     The second tier of defense involves using the key list, which is generated as
     a repeated hash of autokeys message digest and used in autokey sequence. A successful
 middleman attack is unlikely, since without the server seed the reverse order. While any
     receiver can authenticate a message by hashing to match a previous key
     ID, as a practical matter an
 intruder cannot predict produce the next key ID cookie and
     thus without the cookie cannot spoof
 produce a valid MAC. In broadcast mode a wiretapper cannot synthesize
 a valid packet without the autokey seed, so cannot manufacture an
 bogus packet acceptable to the client. In addition,
     tedious hashing operations provoked by replays of old packets are
     suppressed because of the basic NTP protocol design. Finally, spurious
     public-key computations provoked by replays of old packets with
     extension fields are suppressed because of the signature timestamp
     check. receiver. The third tier of defense is represented by most the Autokey protocol and
     extension fields with timestamped signatures. The signatures are used to
     reliably bind intruder can do
 is replay an old packet causing the autokey values client to repeat hash operations
 until exceeding the private maximum key of number. On the other hand, a trusted server.
     Once these values are instantiated, middleman
 could do real harm by intercepting a packet, using the key list authenticates each
     packet relative to its predecessors and by induction ID to the instantiated
 generate a correct autokey values.

     In addition to the three-tier defense strategy, all packets are
     protected by the NTP sanity checks. Since all packets carry time values,
     replays of old or and then synthesizing a bogus packets can packet. There
 does not seem to be deflected once a suitable solution for this as long as the client server
 has no per-client state.

 A client instantiates cryptographic variables only if the server is
 synchronized to a proventic sources. However, the NTP sanity checks are
     only effective once the packet has passed all source. A host does not sign values or
 generate cryptographic tests. This
     is why the signature timestamp is necessary data files unless synchronized to avoid expensive
     calculations that might be provoked by replays. Since the signature and
     verify operations have a high manufacturing cost, in all except
     client/server modes the protocol design protects against proventic
 source. This raises an interesting issue; how does a clogging
     attack by signing client generate
 proventic cryptographic values only when they are created or
     changed and files before it has ever been synchronized to
 a proventic source? Who shaves the barber if the barber shaves
 everybody in town who does not on request.

     Specific Attacks

     While shave himself? In principle, this
 paradox is resolved by assuming the above arguments suggest that primary (stratum 1) servers are
 proventicated by external phenomological means.

 Cryptanalysis

 Some observations on the vulnerability particular engineering constraints of the
 Autokey
     protocols to cryptanalysis is suitably hard, protocol are in order. First, the same cannot number of bits in some
 cryptographic values are considerably smaller than would ordinarily be said
     about
 expected for strong cryptography. One of the vulnerability to a replay or clogging attack, especially when
     a client reasons for this is first mobilized and has not yet proventicated. In the
     following discussion a clogging attack
 need for compatibility with previous NTP versions; another is considered a replay attack at
     high speed which can clog the network need
 for small and deny service to other network
     users or clog the processor constant latencies and deny service to other users on minimal processing requirements.
 Therefore, what the same
     machine. While a clogging attack can be concentrated scheme gives up on any function or
     algorithm of the Autokey protocol, the strength of these values
 must vulnerable target is be regained by agility in the
     public key routines to sign and verify public values. It is vital to
     shield these routines from a clogging attack.

     In all modes rate of change of the cryptographic seed data
 basis values. Thus, autokeys are used to generate cookies only once and
     autokey basis values are changed from time to time. Thus,
 regenerated frequently. However, in most cases even a determined
     intruder could save old request and response packets containing successful
 cryptanalysis of these values compromises only a particular
 client/server association and replay them before or after does not represent a danger to the seed data have changed. Once
 general population.

 While the protocol has not been subjected to a formal analysis, a few
 preliminary assertions can be made. The protocol cannot loop forever
 in any state, since the client has proventicated, association timeout and general reset insure
 that the client association variables will detect replays due to the
     old timestamp eventually be purged and discard the data. This is why
 protocol restarted from the timestamp test beginning. However, if something is
     done first and before
 seriously wrong, the signature timeout/restart cycle could continue indefinitely
 until whatever is computed. However, before this
     happens, the client wrong is vulnerable to replays whether or not they result
     in clogging. fixed.

 Clogging Attacks

 There are two clogging vulnerabilities exposed in the protocol design:
 a sign attack where the intruder hopes to clog the victim server with
 needless signature computations, and a verify attack where the
 intruder attempts to clog the victim client with needless verification
 computations. The
     reference implementation Autokey uses the RSA public key encryption algorithms for both
     sign
 signature and verify functions cookie encryption and these algorithms require
 significant processor resources.

 In order to reduce the exposure to a sign attack, signatures are
 computed only when the data have changed. For instance, the autokey
 values are signed only when the key list is regenerated, which happens
 about once an hour, while the public values are signed only when the
     agreement
 values are regenerated, refreshed, which happens about once per day. However, a server is vulnerable to a sign attack where the intruder can
     clog in
 client/server mode the server with cookie-request messages. The protocol design precludes server state variables stored on
 behalf of any an individual client, so the
     signature cookie must be recomputed computed,
 encrypted and signed for every cookie request. response. Ordinarily, cookie requests are seldom used, except when the private values are
     regenerated. However, a determined intruder could replay intercepted
     cookie requests at high rate, which may very well clog the server. There
     appears no easy countermeasure for this particular attack.

     The intruder might be more successful with a verify attack. Once the
     client has proventicated, replays are detected and discarded before the
     signature is verified. However, if the cookie is known or compromised,
     the intruder can replace the timestamp in an old message with one in the
     future and construct a packet with a MAC acceptable to a client, even if
     it has bogus signature and incorrect autokey sequence. The packet passes
     the MAC test, but then tricks the client to verify the signature, which
     of course fails. What makes this kind of attack more serious is the fact
     that the cookie used
 requests are seldom used, except when extension fields the server seed or public value
 signatures are present is refreshed. However, a determined intruder could replay
 cookie requests at high rate, which may very well known
     (zero). Since all broadcast packets have an extension field, all clog the
     intruder has server.
 There appears no easy countermeasure for this particular attack.

 A verify attack attempts to do is clog the clients receiver by provoking spurious
 signature verifications. The signature timestamp is designed to
 deflect replays of packets with responses including
     timestamps old or duplicate extension fields
 before invoking expensive signature operations. A bogus signature with
 a timestamp in the future. Assuming future could do this, but the intruder has joined autokey sequence
 would detect this, since success would require cryptanalysis of both
 the NTP
     broadcast group, server seed and autokey seed.

 Since the Certificate response is signed, a middleman attack will not
 compromise the certificate data; however, a determined middleman could clog all other members of
 hammer the group.
     This attack can client with intentionally defective Certificate responses
 before a valid one could be deflected by the autokey test, received and force spurious signature
 verifications, which in of course would fail. An intruder could flood the reference
     implementation is after extension field processing,
 server with Certificate request messages, but this requires
     very intricate protocol engineering and the Certificate response
 message is left for a future refinement. signed only once, so the result would be no worse than
 flooding the network with spurious packets.

 An interesting vulnerability in client/server mode is for an intruder
 to replay a recent client packet with an intentional bit error. This
 could cause the server to return the special NAK packet. A naive client might
     conclude the server had refreshed its private value and so attempt to
     refresh the server cookie using a cookie-request message. This results
     in the server and client burning spurious machine cycles and invites a
     clogging attack. This is why crypto-NAK packet, which would then
 cause the reference implementation simply
     discards all protocol and procedure errors and waits for timeout in
     order client to refresh request the values. However, cookie and result in a more clever sign attack on
 the server. This results in the server and client may notice
     that burning spurious
 machine cycles and resulting in denial of service. As in other cases
 mentioned previously, the NTP originate timestamp does not match the most recent client
     packet sent, so can discard check greatly reduces the bogus NAK immediately.
 likelihood of a successful attack.

 In broadcast and symmetric modes the client must include the
 association ID in the Autokey request. Since association ID values for
 different invocations of the NTP daemon are randomized over the 16-bit
 space, it is unlikely that a very old packet would contain a valid
 association ID value. An intruder could save old server packets and
 replay them to the client population with the hope that the values
 will be accepted and cause general chaos. The conservative client will
 discard them on the basis of invalid timestamp.

 As mentioned earlier in this memorandum, previously, 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.

     Present Status and Unifinished Business

     The Autokey protocol described in this memorandu has been implemented in A clever intruder might notice the
 interval between 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 value signatures and implementation of concentrate attack on the Autokey protocol
 vulnerable intervals. An obvious countermeasure is
     basically mature; however, There are several remaining implementation
     issues. One has to do with cryptographic parameter negotiation, as in
     IPSEC protocols such as Photuris. As with Photuris, there may be a need
     to offer and agree to one of possibly several hashing algorithms,
     signature algorithms and agreement algorithms. randomize these
 intervals. A message type has been
     defined for this purpose, but its syntax and semantics remain more comprehensive countermeasure remains to be
     provoked.

     Another issue is support for certificates and certificate authorities,
     in particular Secure DNS services. In the reference implementation a
     complicating factor is the existing banal state of the configuration and
     resolver code. Over the years this code has sprouted to a fractal-like
     state where possibly the only correct repair is a complete rewrite. devised.

 Appendix A. Packet Formats
 The NTP Version 4 packet consists of a number of fields made up of 32-
 bit (4 octet) words. words in network byte order. The packet consists of
 three components, the header, one or more optional extension fields
 and an optional message authenticator code (MAC), consisting of the
 Key ID and Message Digest fields. The format is shown below, where the
 size of some multiple word fields is shown in bits. words.

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |LI | VN  |Mode |    Stratum    |     Poll      |   Precision   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Root Delay                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Root Dispersion                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Reference ID                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                   Reference Timestamp (64) (2)                    |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                   Originate Timestamp (64) (2)                    |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                    Receive Timestamp (64) (2)                     |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                    Transmit Timestamp (64) (2)                    |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 =                      Extension Field(s)                       =
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           Key ID                              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 |                      Message Digest (128) (4)                       |
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The NTP header extends from the beginning of the packet to the end of
 the Transmit Timestamp field. The format and interpretation of the
 header fields are backwards compatible with the NTP Version 3 header
 fields as described in RFC-1305, except for a slightly modified
 computation for the Root Dispersion field. In NTP Version 3, this
 field includes an estimated jitter quantity based on weighted absolute
 differences, while in NTP Version 4 this quantity is based on weighted
 root-mean-square (RMS) differences.

 An unauthenticated NTP packet includes only the NTP header, while an
 authenticated one contains in addition a MAC. The format and
 interpretation of the NTP Version 4 MAC is described in RFC-1305 when
 using the Digital Encryption Standard (DES) algorithm operating in cipher block chaining
 Cipher-Block Chaining (CBC) node. While this This algorithm and mode of operation
 is no longer supported in NTP Version 4, the DES algorithm has been removed from the standard
     software distribution and must be obtained via other sources. 4. The preferred replacement for in
 both NTP Version 3 and 4 is the Message Digest 5 (MD5) algorithm,
 which is included in the distribution. The For MD5 the Message Digest
 field is 64 bits for DES-CBC and 128 bits for MD5, while 4 words (8 octets), but the Key ID field is 32 bits for either algorithm. remains 1 word (4
 octets).

 Extension Field Format

 In NTP Version 4 one or more extension fields can be inserted after
 the NTP header and before the MAC, which is always present when an
 extension field is present. The extension fields can occur in any
 order; however, in some cases there is a preferred order which
 improves the protocol efficiency. While previous versions of the
 Autokey protocol used several different extension field formats, in
 version 2 of the protocol only a single extension field format is
 used.

 Each extension field contains a request or response
     message, which consists of a 16-bit length field, an 8-bit control
     field, an 8-bit flags field and a variable length data field, all message in
     network byte order: the
 following format:

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |R|E|  Version  |     Code      |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Association ID                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           Timestamp                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           Filestamp                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Value Length                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 =                              Data                             Value                             =
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     There are two flag bits defined. Bit 0 is the response flag (R) and bit
     1 is the error flag (E); the other six bits are presently unused and
     should be set to 0. The Version field identifies the version number of
     the
 |                        Signature Length                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 =                           Signature                           =
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Each extension field protocol; this memorandum specifies version 1. The
     Code field specifies the operation in request and response messages. The
     length includes all octets in except the extension field, including last is padded to a word (4 octets)
 boundary, while the length
     field itself. Each extension field last is rounded up padded to a doubleword (8 octets)
 boundary. The Length field covers the next multiple of
     4 octets and entire field length, including
 the last Length field rounded up to itself and padding. While the next multiple of minimum field length is
 8 octets. octets, a maximum field length remains to be established. The extension fields can occur in
 reference implementation discards any order; however, in some cases
     there is a preferred order which improves the protocol efficiency. packet with an extension field
 length over 1024 octets.

 The presence of the MAC and extension fields in the packet is
 determined from the length of the remaining area after the header to
 the end of the packet. The parser initializes a pointer just after the
 header. If the length is not a multiple of 4, a format error has
 occurred and the packet is discarded. If the length is zero the packet
 is not authenticated. If the length is 4 (1 word), the packet is an
 error report or crypto-NAK resulting from a previous packet that
 failed the message digest check. The 4 octets are presently unused and
 should be set to 0. If the length is 12 (3 words), a MAC (DES-CBC) is present, but no extension
     field; if 20 (5 words), a MAC (MD5) is present, but no extension field;
     If the length is 8 (2 words), 12 (3 words) or 16
 (4 words), the packet is discarded with a format error. If the length
 is greater than 20 (5 words), one or more extension fields are
 present.

 If an extension field is present, the parser examines the length
 field. If the length is less than 4 or not a multiple of 4, a format
 error has occurred and the packet is discarded; otherwise, the parser
 increments the pointer by this value. The parser now uses the same
 rules as above to determine whether a MAC is present and/or another
 extension field. An additional implementation-dependent test is
 necessary to ensure the pointer does not stray outside the buffer
 space occupied by the packet.

 In the Autokey Version 2 format, the Code field specifies the request
 or response operation, while the Version field is 2 identifying the
 current protocol version. There are two flag bits defined. Bit 0 is
 the response flag (R) and bit 1 is the error flag (E); the other six
 bits are presently unused and should be set to 0. The remaining fields
 will be described later.

 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
 bit set to 0. Ordinarily, the client sets the E bit to 0 as well, but
 may in future set it to 1 for some purpose. The Association ID field
 is set to the value previously received from the server or 0
 otherwise. The server returns a response with the same operation code
 in the Code field and the R bit set to 1. The server can also set the E bit to 1 in case of error. However, it is not
     a protocol error to send an unsolicited response with no matching
     request.

     There are currently five request and six response messages. All request
     messages except the Association ID request message have the following
     format:

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|0| also set the
 E bit to 1     |      Code     |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Association ID                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ in case of error. The Association ID field is used to match a client request to a
     particular server association. By convention, servers set to the
 association ID in the response and clients include sending the same value in
     requests. Also by convention, until a client has received a response
     from as a server, the client sets the Association ID field to 0. handle for subsequent
 exchanges. If for some reason the association ID value in a request
 does not match the association ID of any mobilized association, the
 server returns the request with both the R and E bits set to 1.

     The following Note
 that, it is not a protocol error to send an unsolicited response with
 no matching request.

 In some cases not all fields may be present. For instance, when a
 client has not synchronized to a proventic source, signatures are not
 valid. In such cases the Timestamp and Signature Length fields are 0
 and the Signature field is empty. Some request and error response
 messages have been defined.

     Parameter Negotiation (1)

     This carry no value or signature fields, so in these messages only
 the first two words are present. The extension field parser verifies
 that the extension field length is reserved for future use as an algorithm at least 8 if no value field is
 expected and
     algorithm parameter offer/select exchange, as well as to provide at least 24 if it is. The parser also verifies that the
 sum of the
     optional identification value and signature lengths is equal to use or less than the
 extension field length.

 The Timestamp and Filestamp words carry the seconds field of the NTP
 timestamp. The Timestamp field establishes the signature epoch of the
 data field in lieu the message, while the filestamp establishes the
 generation epoch of endpoint IP addresses the file that ultimately produced the data that
 was signed. Since a signature and timestamp are valid only when calculating the autokey. The format, encoding
 signing host is synchronized to a proventic source and use of these a cryptographic
 data
     remain to file can only be specified. The command code generated if a signature is possible, the
 filestamp is reserved. always nonzero, except in the Association ID (2)
     A client sends Response
 message, where it contains the request server status word.

 Autokey Version 2 Messages

 Association Message

 The Association message is used to obtain the association ID host name and status
     flags. A broadcast server sends an unsolicited response for all except
     the first autokey sent from the key list. related
 values. The request and response have message has the following format (except for the response bit): format:

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|E|
 |0|0|     1     |       1       |              8                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               0                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The response message has the following format:

                     1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |1|E|     1     |       1       |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Association ID                               0                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Flags                     Public Value Timestamp                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     The Association ID field contains
 |                          Status Word                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Host Name Length                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 =                           Host Name                           =
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               0                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 This is the association ID of only response that is accepted if the server. The association status flags currently defined are

     Bit     Function
     ================
     31      autokey
 word is enabled
     30      public zero; otherwise, it is ignored. As this is the first request
 sent and private keys have been loaded
     29      agreement parameters have been loaded
     28      leapseconds table has been loaded

     Additional bits may be the response is not from an association, the Association ID
 fields are 0. The Host Name field contains the unterminated string
 returned by the Unix gethostname() library function. The Status Word
 is defined in future, so for now bits 0-27 should be
     set to zero. There is no timestamp or signature associated with previously in this
     message.

     Autokey (3)

     A broadcast server or symmetric peer sends memorandum. While minimum and maximum
 host name lengths remain to be established, the request reference
 implementation uses the values 4 and 256, respectively.

 Certificate Message

 The Certificate message is used to obtain the
     autokey certificate and related
 values. The response request message has the following format:

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|E|     1
 |0|0|     2     |       4       2       |            Length              8                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Association ID                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Timestamp                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Initial Sequence                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Initial Key ID                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Signature Length                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                                                               |
     =                           Signature                           =
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     The response is also sent unsolicited when the server or peer generates
     a new key list. The Initial Sequence field contains the first key number
     in the current key list and the Initial Key ID field contains the next
     key ID associated with that number. If the server is not synchronized to
     a proventicated source, the Timestamp field contains 0; otherwise, it
     contains the NTP seconds when the key list was generated and signed. The
     signature covers all fields from the Timestamp field through the Initial
     Key ID field. If for some reason these values are unavailable or the
     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.

     Cookie (4)

     A client sends the request to obtain the server cookie.

 The response message has the following format:

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |1|E|     1     2     |       3       2       |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Association ID                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Public Values Timestamp                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Cookie                     Certificate Filestamp                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Certificate Length                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 =                          Certificate                          =
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  Certificate Signature Length                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 =                     Certificate Signature                     =
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Since there

 The response is no server association matching the client, accepted only if the association ID field for the request and response status word is 0.
 nonzero, AUT = 0 and LBK = 1. The Cookie field
     contains the cookie used certificate is encoded in client/server modes. X.509
 format using ASN.1 syntax. If the server is not
     synchronized to a proventicated source, the Timestamp field contains 0;
     otherwise, it contains the NTP seconds when the cookie was computed and
     signed. The signature covers the Timestamp and Cookie fields. If certificate has expired or for some
 reason the cookie value is unavailable or no longer available, the signing operation
     fails, response includes only the Cookie field contains 0 and first
 two words with the extension field is truncated
     following E bit set. The remaining fields are defined
 previously in this field.

     Diffie-Hellman Parameters (5)
     A symmetric peer uses the request memorandum.

 Cookie Message

 The Cookie is used in client/server and response symmetric modes to send obtain the public value
     and signature to its peer.
 server cookie. The response request message has the following format:

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|E|     1
 |0|0|     3     |       5       3       |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Association ID                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Public Values Timestamp                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Parameters                     Certificate Filestamp                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Parameters                       Public Key Length                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 =                           Parameters                            Public Key                         =
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Public Key Signature Length                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 =                       Public Key Signature                    =
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The Parameters field contains the Diffie-Hellman parameters used to
     compute the public and private values. The Parameters Filestamp field
     contains the NTP seconds when the Diffie-Hellman parameter file was
     generated. If the server is not synchronized to a proventicated source,
     the Timestamp field contains 0; otherwise, it contains the NTP seconds
     when the public value was generated and signed. The signature covers the
     Timestamp, Parameters Length and Parameters fields. If for some reason
     these values are unavailable or the signing operation fails, the
     Parameters Length field contains 0 and the extension field is truncated
     following this field.

     Public Value (6)

     A symmetric peer uses the request is accepted only if AUT = 1, CKY = 0 and response to send LBK = 1. The
 Public Key field contains the server public value
     and signature key values to its peer. be used for
 cookie encryption. The values are encoded in ASN.1 format. The
 remaining fields are defined previously in this memorandum.

 The response message has the following format:

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |1|E|     1     3     |       5       3       |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Association ID                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Cookie Timestamp                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Certificate Filestamp                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Public Value                    Encrypted Cookie Length                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 =                          Public Value                        Encrypted Cookie                       =
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Cookie Signature Length                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 =                        Cookie Signature                       =
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The Public Value response is accepted only if AUT = 1 and LBK = 1. The Cookie
 Timestamp, Encrypted Cookie and Cookie Signature fields are determined
 upon arrival of the request message. The Encrypted Cookie field
 contains the Diffie-Hellman public encrypted cookie value used according to
     compute the agreed key.

     The Filestamp field contains the NTP seconds when public key
 provided in the Diffie-Hellman
     parameter file was generated. request. If CKY = 0, the server decrypted cookie is not synchronized to a
     proventicated source, used
 directly. If CKY = 1, the Timestamp field contains 0; otherwise, it
     contains decrypted cookie is exclusive-ORed with the NTP seconds
 existing cookie. If an error occurs when decoding the public value was generated and signed.
     The signature covers all fields from the Timestamp field through the
     Public Value field. If for some reason these values are unavailable key or
 encrypting the signing operation fails, cookie, the Public Value Length field contains 0
     and response includes only the extension field is truncated following first two words
 with the E bit set. The remaining fields are defined previously in
 this field.

     Public Key/Host Name (7)

     A client uses memorandum.

 Autokey Message
 The Autokey message is used to obtain the autokey values. The request to retrieve
 message has the public key, host name and
     signature. following format:

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0|0|     2     |       4       |              8                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Association ID                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The response message has the following format:

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |1|E|     1     4     |       7       4       |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Public Key ID                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Association ID                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Autokey Timestamp                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Certificate Filestamp                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Public Key Length                               8                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
     |                                                               |
     =                          Public                            Key                           =
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Host Name Length ID                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
     |                                                               |
     =                           Host Name                           =
     |                                                               |
     |                          Key Number                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Autokey Signature Length                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 =                       Autokey Signature                       =
 |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Since the public key and host name are a property of the server and not
     any particular association, the association ID field for the request and
     response is 0. The Public Key field contains the RSA public key in
     rsaref2.0 format; that is, the modulus length (in bits) as the first
     word followed by the modulus bits. Note that in some architectures the
     rsaref2.0 modulus word may be something other than 32 bits. The Host
     Name field contains the host name string returned by the Unix
     gethostname() library function.

     The Filestamp field contains the NTP seconds when the public/private key
     files were generated. If the server is not synchronized to a
     proventicated source, the Timestamp field contains 0; otherwise, it
     contains the NTP seconds when the public value was generated and signed.
     The signature covers all fields from the Timestamp field through the
     Host Name field. If for some reason these values are unavailable or the
     signing operation fails, the Host Name Length field contains 0 and the
     extension field is truncated following this field.

     Leapseconds table (8)

     The civil timescale (UTC), which is based on Earth rotation, has been
     diverging from atomic time (TAI), which is based on an ensemble of
     cesium oscillators, at about one second per year. Since 1972 the
     International Bureau of Weights                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The response is accepted only if AUT = 1 and Measures (BIPM) declares on occasion
     a leap second to be inserted KEY = 0 in the UTC timescale on the last day of
     June or December. Sometimes
 association status word; otherwise, it is necessary to correct UTC as
     disseminated by NTP to agree with TAI on ignored. The Autokey
 Timestamp, Key ID, Key Number and Autokey Signature fields are
 determined when the current most recent key list was generated. If a key list
 has not been generated or some previous
     epoch.

     A client uses the request to retrieve association ID matches no mobilized
 association, the response includes only the first two words with the E
 bit set. The remaining fields are defined previously in this
 memorandum.

 Leapseconds Table Message
 The Leapseconds Table message is used to exchange leapseconds table and
     signature. tables.
 The request and response has messages have the following format: format, except
 that the R bit is set in the response:

                      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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|E|     1
 |0|0|     2     |       8       5       |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Public Key ID                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Association ID                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Public Values Timestamp                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Leapseconds Filestamp                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Leapseconds table Table Length                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 =                        Leapseconds table Table                      =
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Leapseconds Signature Length                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 =                      Leapseconds Signature                    =
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     The NTP extension field format consists of a table with one entry in NTP
     seconds for each leap second.

     Since the leapseconds table is a property of the server and not any
     particular association, the association ID field for the request and
     response is 0. The Leapseconds table field contains a list of the
     historic epoches that leap seconds were inserted in the UTC timescale.
     Each list entry is a 32-bit word in NTP seconds, while the table is in
     order from the most recent to the oldest insertion. At the first
     insertion in January, 1972 UTC was ahead of TAI by 10 s and has
     increased by
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The response is accepted only if AUT = 1 s for each insertion since then. Thus, the table length and LPT = 0 in bytes divided by four plus nine is the current offset of UTC relative
     to TAI.
 association status word; otherwise, it is ignored. The Filestamp Leapseconds
 Table field contains the NTP seconds when leapseconds table as parsed from the
 leapseconds file available from NIST. In client/server mode the client
 requests the table
     was generated at from the original host, server when the LPF bit is set in this case one of the public time
     servers operated by NIST. host
 status word. If the value of client already has a copy, it uses the filestamp is less than one with
 the
     first entry on latest filestamp. In symmetric modes the list, peers exchange tables and
 both use the first entry one with the latest filestamp. If the leapseconds table
 is requested but unavailable, the epoch of response includes only the predicted
     next leap insertion. The filestamp must always be greater than first two
 words with the
     second entry E bit set. The remaining fields are defined previously
 in this memorandum.

 Appendix B. Key Generation and Management

 The ntp-genkeys utility program in the list. If the server NTP software distribution
 generates public/private key, certificate request and certificate
 files. A set of files is not synchronized to generated for every message digest and
 signature encryption scheme supported by the OpenSSL software library.
 All files are based on a
     proventicated source, pseudo-random number generator seeded in such
 a way that random values are exceedingly unlikely to repeat. The files
 are PEM encoded in printable ASCII format suitable for mailing as MIME
 objects. The file names include the Timestamp field contains 0; otherwise, it
     contains name of the NTP seconds when generating host
 together with the public value was generated and signed. filestamp, as described previously in this
 memorandum.

 The signature covers generated files are typically stored in a shared directory in NFS
 mounted file systems, with files containing private keys obscured to
 all fields but root. Links from default file names assumed by the Timestamp field through the
     Leapseconds table field. If for some reason these values NTP daemon
 are unavailable
     or the signing operation fails, installed to the Host Name Length field contains 0
     and selected files for the extension field is truncated following this field.

     Appendix B. Key Generation host key, sign key and Management

     In the reference implementation
 host certificate. Since the lifetimes files of various cryptographic
     values are carefully managed successive generations and frequently refreshed. While permanent
     keys have lifetimes that expire only when manually revoked, autokeys
 different hosts have unique names, there is no possibility of name
 collisions. An extensive set of consistency checks avoids linking from
 a lifetime specified at particular host to the time files of generation. When generating a another host, for example.

 The ntp-genkeys program generates public/private key list files for an association, both
 the lifetime of each autokey is set to
     expire one poll interval later than it is scheduled to be used.
     Ordinarily, key lists are regenerated and signed about once per hour and
     private cookie values and public agreement values are refreshed RSA and
     signed about once per day. The protocol design is specially tailored to
     make DSA encryption algorithms with a smooth transition when these values are refreshed and to avoid
     vulnerabilities due to clogging and replay attacks while refreshment is
     in progress.

     Autokey default modulus of 512
 bits. The host key management can used for cookie encryption must be handled in much RSA. By default,
 the same way as in the ssh
     facility. A set of public and private keys and agreement parameters are
     generated by key is used for signature encryption. However, a utility program designed different
 RSA key or a DSA key can be specified for this purpose. signature encryption.

 The ntp-genkeys program also generates four files, one containing random DES/MD5 private keys, which
     are not certificate request and self-
 signed certificate files. The X.509 certificate request used in the by
 Autokey protocol, a second containing includes at the RSA
     private key, a third minimum these values and possibly related
 information needed by an external certificate authority. Autokey
 expects the RSA public key, subject name and a fourth issuer name to be the Diffie-Hellman
     agreement parameters. In addition, same as the leapseconds table is generated
     and stored in public time servers maintained by NIST.
 generating host name.

 The means to do
     this are beyond program avoids the scope of this memorandum.

     All files are based on random strings seeded need for a serial number file by using the system clock at
 filestamp as the certificate serial number. By default, certificates
 are valid for one year following the time of generation and are generation, although
 these conventions may change. Also, the program assumes X.509 version
 1 formats, although this may change to version 3 in printable ASCII format with PEM (base-64)
     encoding. The name of each file includes an extension consisting future. Other
 implementations might have different conventions.

 Appendix C. Packet Processing Rules

 Exhaustive examination of the
     NTP seconds possible vulnerabilities at the time various
 processing steps of generation. This is interpreted the NTP protocol as a key ID specified in order to detect incorrect keys and to handle key changeovers RFC-1305 have
 resulted in a revised list of packet sanity tests. There are 12 tests,
 called TEST1 through TEST12 in an
     orderly way. In the recommended method, all files except the RSA private
     key file reference implementation, which are installed
 performed in a shared directory /usr/local/etc, which is
     where specific order designed to gain maximum diagnostic
 information while protecting against an accidental or malicious
 clogging attack. These tests are described in detail in the daemon looks for them by default. Flash
 Codes section of the ntpq documentation page at
 www.eecis.udel.edu/~ntp/ntp_spool/html/ntpq.htm.

 The private RSA key file is
     installed in an unshared directory such sanity tests are divided into three tiers as /etc. It is convenient to
     install links previously described.
 The first tier deflects access control and packet message digest
 violations. The second deflects packets from broken or unsynchronized
 servers and replays. The third deflects packets with invalid header
 fields or time values with excessive errors. However, the default file names, which tests in
 this last group do not have filestamp
     extensions, to directly affect cryptographic the current files, which do. This way when a new
     generation of keys is installed, only protocol
 vulnerability, so are beyond the links need to be changed. scope of discussion here.

 When a server or client first host initializes, it loads the RSA public and
     private reads its own host key, sign key and
 certificate files, which are required for continued operation. It then
     attempts to load the agreement parameters file, certificate file and
     leapseconds table file. If one or more of these files are present, the
     associated bit is set in the system status word. Neither of these files
     are necessary at this time, since the data can be retrieved later from
     another server. If obtaining these data from another server is
     considered a significant vulnerability, the files should be present.

     In the current management model, the keys and parameter files are
     generated on each machine separately and the private key obscured. For
     the most demanding applications, the public key files for a community of
     users can be copied to all of those users, while one of the parameter
     files can be selected and copied to all users. However, if security
     considerations permit, the public key and parameter values, as well as
 Optionally, it reads the certificate file and leapseconds table file, can be obtained from
     other servers during operation. These data completely define when available. When
 reading these files the
     security community and host checks the servers configured filestamps for each client. In
     broadcast client validity; for
 instance, all filestamps must be later than the time the UTC timescale
 was established in 1972 and symmetric passive modes the identity of a
     particular server may certificate filestamp must not be known in advance, so the protocol obtains
     and verifies
 earlier than the public sign key and filestamp (or host name directly from key filestamp, if that is
 the default sign key). In general, at the time the server.
     Ultimately, these procedures may be automated using public certificates
     retrieved from secure directory services.

     Since all files carry a filestamp incorporated in are read, the file name, newer
     file generations
 host is not synchronized, so it cannot determine whether the
 filestamps are detected in bogus other than these simple checks.

 Once a client has synchronized to a proventic source, additional
 checks are implemented as each message arrives. In the data obtained from following the one or more
     configured servers. When detected,
 relation A -> B is Lamport's "happens before" relation which is true
 if event A happens before event B. Here the newer generations replace relation is assume to hold
 if event A is simultaneous with event B, unless noted to the
     older ones automatically contrary.
 The following assertions are required:

 1. For timestamp T and filestamp F, F->T; that is, the newer ones made available to dependent
     clients as required. Since timestamp must
 not be earlier than the filestamp.

 2. In client and symmetric modes, for host key filestamp signatures are refreshed H, public key
 timestamp P, cookie timestamp C and autokey timestamp A, H->P->C->A;
 that is, once
     per day, which causes all associations to reset, the newer generations cookie is generated an earlier cookie will eventually overtake all older ones throughout not be
 accepted, and once the subnet of servers key list and dependent clients.

     Where security considerations permit autokey values are generated,
 earlier autokey values will not be accepted.

 3. For sign file S and the public key, certificate filestamp C specifying begin time B
 and
     agreement parameter files can be retrieved directly from end time E, S->C->B->E; that is, the server,
     these data can valid period must be easily automated. Each server nonempty
 and client runs a shell
     script perhaps once per month. The script generates new key not retroactive.

 4. For timestamp T, begin time B and
     parameter files, updates end time E, B->T->E; that is, the links and then restarts
 timestamp T is valid from the daemon. The
     daemon loads beginning if second B through the necessary files and then restarts end of
 second E. This raises the protocol interesting possibilities where a truechimer
 server with expired certificate or a falseticker with valid
 certificate are not detected until the client has synchronized to a
 clique of proventic truechimers.

 5. For each of its servers, refreshing public keys signatures, the client saves the most recent valid
 timestamp T0 and parameter files during filestamp F0. For every received message carrying
 timestamp T1 and filestamp F1, the process. Clients will not be able to authenticate following daemon
     restart, but message is discarded unless T0->T1
 and F0->F1; however, if the protocol design KEY bit of the association status word is such
 dim, the message is not discarded if T1 = T0; that they will eventually is, old messages
 are discarded and, in addition, if the server is proventic, the
 message is discarded if an old duplicate.

 An interesting question is what happens if during regular operation a
 certificate becomes invalid. The behavior assumed is identical to the
 case where an incorrect sign key were used. Thus, the next time
     out, restart a
 client attempts to verify an autokey signature, for example, the protocol
 operation would fail and retrieve the latest data. eventually cause a general client reset and
 restart.

 Security Considerations

 Security issues are the main topic of this memorandum.

 References

 Note: Internet Engineering Task Force documents can be obtained at
 www.ietf.org. Other papers and reports can be obtained at
 www.eecis.udel.edu/~mills. Additional briefings in PowerPoint,
 PostScript and PDF are at that site in ./autokey.htm.

 1. Bradner, S. Key words for use in RFCs to indicate requirement
 levels. Request for Comments RFC-2119, BCP 14, Internet Engineering
 Task Force, March 1997.

 2. Karn, P., and W. Simpson. Photuris: session-key management
 protocol. Request for Comments RFC-2522, Internet Engineering Task
 Force, March 1999.

 3. Kent, S., R. Atkinson. IP Authentication Header. Request for
 Comments RFC-2402, Internet Engineering Task Force, November 1998.

 4. Kent, S., and R. Atkinson. IP Encapsulating security payload (ESP).
 Request for Comments RFC-2406, Internet Engineering Task Force,
 November 1998.

 5. Maughan, D., M. Schertler, M. Schneider, and J. Turner. Internet
 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
 real-time protocols. Proc. Advanced Telecommunications/Information
 Distribution Research Program (ATIRP) Conference (College Park MD,
 January 1997), 293-298.

 7. Mills, D.L. Cryptographic authentication for real-time network
 protocols. In: AMS DIMACS Series in Discrete Mathematics and
 Theoretical Computer Science, Vol. 45 (1999), 135-144.

 8. Mills, D.L. Network Time Protocol (Version 3) specification,
 implementation and analysis. Network Working Group Report RFC-1305,
 University of Delaware, March 1992, 113 pp.

 9. Mills, D.L. Proposed authentication enhancements for the Network
 Time Protocol version 4. Electrical Engineering Report 96-10-3,
 University of Delaware, October 1996, 36 pp.

 10. Mills, D.L, and A. Thyagarajan. Network time protocol version 4
 proposed changes. Electrical Engineering Department Report 94-10-2,
 University of Delaware, October 1994, 32 pp.

 11. Mills, D.L. Public key cryptography for the Network Time Protocol.
 Electrical Engineering Report 00-5-1, University of Delaware, May
 2000. 23 pp.

 12. Orman, H. The OAKLEY key determination protocol. Request for
 Comments RFC-2412, Internet Engineering Task Force, November 1998.

 Author's Address

 David L. Mills
 Electrical and Computer Engineering Department
 University of Delaware
 Newark, DE 19716
 mail mills@udel.edu, phone 302 831 8247, fax 302 831 4316
 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

 "Copyright (C) The Internet Society (date). Society, 2001. All Rights Reserved. This
 document and translations of it may be copied and furnished to others,
 and derivative works that comment on or otherwise explain it or assist
 in its implmentation may be prepared, copied, published and
 distributed, in whole or in part, without restriction of any kind,
 provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works. However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of developing
 Internet standards in which case the procedures for copyrights defined
 in the Internet Standards process must be followed, or as required to
 translate it into.