Internet Engineering Task Force
Secure Time Working Group                                 David L. Mills
Internet Draft                                    University of Delaware
     Standards Track                                           February
Document: draft-ietf-stime-ntpauth-04.txt                  November 2002
         Public key Key Cryptography for the Network Time Protocol
                               Version 2
                       < draft-ietf-stime-ntpauth-03.txt >

                          Status of this Memorandum Memo

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

   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.

   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 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.

   Copyright (C), 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. Internet Society, 2002. All rights reserved.

                                Abstract

   This memorandum document describes a scheme the Autokey security model for authenticating
   servers to clients using the Network Time Protocol. It extends prior schemes based on
     symmetric key cryptography to a new scheme based on Protocol (NTP) and public
   key cryptography. The new scheme, called Autokey, its design 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
   PKI schemes presume authenticated timestamps time values are always available; available to
   enforce certificate lifetimes; however, cryptographically verified
   timestamps require interaction between the timekeeping function and
   authentication function in ways not yet considered in by the IPSEC model.

     The main body of this memorandum contains a description of IETF.

   This Document includes the security
     model, approach rationale, protocol Autokey requirements analysis, design
   principles and vulnerability analysis.

     It obsoletes a previous report [11] primarily in the schemes for
     distributing public keys and related values. protocol specification. 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 document has been
   implemented, tested and documented in the NTP Version 4 (NTPv4)
   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.
   http://www.ntp.org.

                   Conventions used in this document

   The tables can be retrieved either directly from national
     time servers operated by NIST or indirectly through NTP key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and intervening
     servers.

     Changes Since the Preceding Draft

     This is a major rewrite of the previous draft. There are numerous
     changes scattered through "OPTIONAL" in this memorandum
   document are to clarify the presentation
     and add a few new features. Among the most important: be interpreted as described in RFC-2119 [RFC-2119].

                           Table of Contents

   1. The reference implementation now uses the OpenSSL cryptographic
     software library. Besides being somewhat faster than the older RSAref2.0
     library, it supports several different message digest and signature
     encryption schemes. Introduction...................................................4
   2. The NTP Security Model.............................................5
   3. Approach.......................................................8
   4. Autokey protocol and reference implementation support the Cryptography...........................................9
   5. Autokey Operations............................................11
   6. Public Key Infrastructure (PKI), including X.500 certificates.

     3. The Signatures and Timestamps..........................14
   7. Autokey protocol has been redesigned to be simpler, more uniform Protocol Overview.....................................16
   8. Autokey State Machine.........................................18
      8.1 Status Word...............................................18
      8.2 Host State Variables......................................20
      8.3 Client State Variables (all modes)........................21
      8.4 Server State Variables (broadcast and more robust. There is only one generic message format symmetric modes)....22
      8.5 Autokey Messages..........................................23
   9. Error Recovery................................................27
   10. References...................................................29
   Appendix A. Packet Formats.......................................31
      A.1 Extension Field Format....................................32
      A.2 Autokey Version 2 Messages................................34
   Appendix B. Cryptographic Key and all
     requests can carry signed parameters.

     4. Strong assertions are now possible about the authentication of
     timestamps Certificate Management.........43
   Appendix C. Autokey Error Checking...............................45
      C.1 Packet Processing Rules...................................45
      C.2 Timestamps, Filestamps and filestamps. This makes correctness modeling more robust Partial Ordering...............47
   Appendix D. Security Analysis....................................49
      D.1 Protocol Vulnerability....................................49
      D.2 Clogging Vulnerability....................................50
   Appendix E. Identity Schemes.....................................53
      E.1 Private Certificate (PC) Scheme...........................55
      E.2 Trusted Certificate (TC) Scheme...........................55
      E.3 Schnorr (IFF) Scheme......................................55
      E.4 Guillard-Quisquater (GQ) Scheme...........................56
      E.5 Interoperability Issues...................................57
   Appendix F. File Examples........................................60
      F.1 RSA-MD5cert File and simplifies vulnerability assessment.

     5. Certain security potholes have been filled in, in particular the
     cookie in client/server ASN.1 Encoding.......................60
      F.2 GQkey File and symmetric modes is now encrypted.

     6. The description of the protocol, its state variables, transition
     function, inputs ASN.1 Encoding.............................61
      F.3 GQpar File and outputs are simpler, less wordy ASN.1 Encoding.............................61
      F.4 RSAkey File and more amenable
     to correctness modelling.

     7. Provisions have been made to handle cases when the endpoint addresses
     are changed, as in mobile IP. ASN.1 Encoding............................61
      F.5 IFFpar File and ASN.1 Encoding............................62
   Appendix G. ASN.1 Encoding Rules.................................63
      G.1 COOKIE request, IFF response, GQ response.................63
      G.2 CERT response, SIGN request and response..................63
   Security Considerations..........................................66
   Author's Addresses...............................................66

1. 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 NTP Version 3 (NTPv3) specification RFC-1305 [7]; [RFC-1305];
   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 document 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, document, there is a place for 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] [RFC-
   2408], RFC-2412], [RFC-2522] proposed by the IETF require per-association 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 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]. [MILLS96], [MILLS00]. 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 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. document.

   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 on the NTP project page
   linked from www.ntp.org. The NTPv4 reference implementation can be found at
     www.eecis.udel.edu/~ntp/ntp_spool/html/authopt.htm.

     Security Model for Unix
   and Windows, including sources and documentation in HTML, is
   available from the NTP security requirements are even more stringent than most other
     distributed services. First, repository at the operation same site. All of the authentication
     mechanism and the time synchronization
   features described in this document, including support for both IPv4
   and IPv6 address families, are included in the current development
   version at that repository. The reference implementation is not
   intended to become part of any standard that may be evolved from this
   document, but to serve as an example of how the procedures described
   in this document can be implemented in a practical way.

2. NTP 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 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 document 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 (authenticates by induction) 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 NTP client considers mobilizes a server
   number of concurrent associations with different servers and uses a
   crafted agreement algorithm to pluck truechimers from the population
   possibly including falsetickers. A particular association is
   proventic if it can validate its the server certificate and its apparent time is
     within identity have been verified
   by the valid interval specified on means described in this document. However, 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. network paths.

   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] [RFC-2406] and Authentication Header (AH) [3]
   [RFC-2402] 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 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 network and processor 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 network, servers
   or clients with spurious packets that exhaust resources and deny
   service to legitimate applications. The mission of the algorithms and
   protocols described in this memorandum document is to detect and discard
   spurious packets sent by other than the intended sender or sent by
   the intended sender, but modified or replayed by an intruder. The
   cryptographic means of the reference implementation are based on the
   OpenSSL cryptographic software library available at www.openssl.org,
   but other 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
   exchange scheme is inherently resistant to spoof and replay attacks.
   The engineered clock filter, selection and clustering algorithms are
   designed to defend against evil 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.

   The NTP security model assumes the following possible threats.
   Further discussion on the assumed
     intruder model is given in [9], [MILLS00] and in the briefings at the NTP
   project page, but beyond the scope of this memorandum. document.

   1. An intruder can intercept and archive packets 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 server, network
   or client can process them, especially if they require expensive
   cryptographic computations.

   3. An In a wiretap attack the intruder can originate, intercept, modify and replay
   a packet. However, it cannot permanently prevent packet onward transmission over
   of the net; original packet; that is, it cannot break the wire, only tell
   lies and congest it. Except in unlikely cases considered in Appendix
   D, the modified packet cannot arrive at the victim before the
   original packet.

   4. In
     this memorandum a distinction is made between a middleman attack, where or masquerade attack the intruder can modify and replace an intercepted packet, and a wiretap
     attack, where is positioned
   between the intruder server anc client, so it can intercept, modify and replay the
   a packet only after and prevent onward transmission of the original packet has been received.

     The following assumptions are fundamental to the Autokey design. They
     are discussed at some length packet.
   Except in unlikely cases considered in Appendix D, the briefing slides and links at
     www.eecis.udel.edu/~mills/ntp.htm and will middleman does
   not be further elaborated have the server private keys or identity parameters.

   The NTP security model assumes the following possible limitations.
   Further discussion is in [MILLS00] and in the briefings at the NTP
   project page, but beyond the scope of this memorandum. document.

   1. The running times for public key algorithms are relatively long
   and highly variable. In general, the performance of the time
   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 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. net with the single exception of encrypted
   signatures and cookies intended only to authenticate the source.
   Private values must never be disclosed beyond the machine on which
   they were created.

   5. Public encryption keys and 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 be a function of external certificate
   authorities and/or webs of trust.

   6. Error checking must be at the enhanced paranoid level, as network
   terrorists may be able to craft errored packets that consume
   excessive cycles with needless result. While this document includes
   an informal vulnerability analysis and error protection paradigm, a
   formal model based on communicating finite-state machine analysis
   remains to be developed.

   Unlike the ssh Secure Shell security model, where the client must be
   securely
     identified authenticated to the server, in NTP the server must be
   securely identified authenticated to the client. In ssh each different interface
   address can be bound to a different name, as returned by a reverse-DNS 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 that access
   control is performed by means external to the protocol and that all
   time values and cryptographic values are public, so there is no need
   to associate each interface with different cryptographic values. To
   do so would create the possibility of a two-faced clock, which is
   ordinarily considered a Byzantine hazard. 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
   gethostname() library function, represents all interface addresses.
   Since at least in some host configurations the host name may not be
   identifiable in a DNS query, the name must be either configured in
   advance or obtained directly from the server using the Autokey
   protocol.

3. Approach

   The Autokey protocol described in this memorandum document 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.
   document. Note that here and elsewhere in this memorandum document mention of
   broadcast mode means multicast mode as well, with exceptions noted in
   the web page at www.eecis.udel.edu/~ntp/ntp_spool/html/assoc.htm. NTP software documentation.

   1. It must interoperate with the existing NTP architecture model and
   protocol design. In particular, it must support the symmetric key
   scheme described in RFC-1305. [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 NTP packet is synchronized to a proventic source accepted for processing only
   when the required cryptographic values have been obtained and
   verified and the NTP timestamps have header has 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, specifically those
   identified in the security model above. In particular, it must be
   tolerant of operational or implementation variances, such as packet
   loss or misorder, or suboptimal 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 cookie encryption operations.

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

   7. It must not require intricate per-client or per-server
   configuration other than the availability of the required
   cryptographic keys and certificates.

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

4. Autokey Proventication Scheme Cryptography

   Autokey public key cryptography is based on the PKI algorithms
   commonly used in the Secure Shell and Secure Sockets Layer
   applications. As in these applications Autokey uses keyed message
   digests to detect packet modification, digital signatures to verify
   the source and public key algorithms 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 NTPv3 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 values
   less than the pivot and indefinite lifetime. Autokey key IDs have
   pseudo-random values equal to or greater than 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 server, symmetric and symmetric. broadcast. All three
   variants make use of specially contrived session keys, called
   autokeys, and a precomputed pseudo-random sequence of autokeys with
   the key IDs saved in a key list. As in the original NTP Version 3 NTPv3
   authentication scheme, the Autokey protocol operates separately for
   each association, so there may be several autokey sequences operating
   independently at the same time.

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

      +-----------+-----------+-----------+-----------+
      | Source IP |  Dest IP  |  Key ID   |  Cookie   |
      +-----------+-----------+-----------+-----------+

   The four values are hashed by the MD5 message digest algorithm to
   produce the 128-bit key autokey 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 use 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, 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
   shared private value, depending on the mode.

   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.

   There are some scenarios where the use of endpoint IP addresses may
   be difficult or impossible. These include configurations where
   network address translation (NAT) devices are in use or when
   addresses are changed during an association lifetime due to mobility
   constraints. For Autokey, the only restriction is that the addresses address
   fields visible in the transmitted packet must be the same as those
   used to construct the autokey sequence and key list and that these addresses
   fields 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 the endpoint IP addresses are not available, an
   optional public identification value could be used instead of the
   addresses. Examples include the Interplanetary Internet, where
   bundles are identified by name rather than address. Specific
   provisions are for further study.

   The key list consists of a sequence of key IDs starting with a 32-bit random private value called
   32-bit nonce (autokey seed) equal to or greater than the autokey seed. pivot as the
   first key ID. The associated first autokey is computed as above using the specified given
   cookie and the first 32 bits of the result in network byte order of this value
   become the next key ID. Operations continue in this way to generate
   the entire list, which may have up to
     100 entries. list. It may happen that a newly generated key ID is less
   than 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. hour, so for poll intervals above one hour a
   new key list containing only a single entry is regenerated for every
   poll.

   The index of the last key ID in the list is saved along with the next
   key ID for that entry, collectively called the autokey values. The
   autokey values are then signed. The list is used in reverse order, so
   that the first 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 validated using one or
   more hashes that eventually match the first last 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.

5. Autokey Operations

   The Autokey works differently in protocol has three variations, called dances,
   corresponding to the various NTP server, symmetric and broadcast modes. The scheme used in
     client/server mode
   server dance was suggested by Steve Kent over 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 32-bit random
   private value called
     the server seed (server seed) to regenerate the cookie upon arrival of
   a client packet. The cookie is calculated in a manner similar to as the autokey, but first 32 bits of the
   autokey computed from the client and server addresses, a key ID field is of
   zero and the cookie field is the server seed. seed as cookie. The
     first 32 bits of the hash is the cookie is used for the actual
   autokey calculation by both the client and server. It server and is thus
   specific to each client separately and of no use to other clients or an intruder. separately.

   In previous versions of the Autokey protocol versions the cookie was transmitted in clear on
   the assumption it was not useful to a wiretapper other than to launch
   an ineffective replay attack. However, an a middleman could intercept
   the cookie and manufacture bogus messages acceptable to the client.
   In order to reduce the vulnerability to risk of 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. cookie or masquerade
   as the server.

   [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 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(!) seconds in a vintage Sun IPC. This scheme was quickly
   dropped in favor of generic public key encryption.]
     In client/server mode the client uses

   The server dance uses the cookie and each key ID on the key list in
   turn to retrieve the autokey and generate the MAC in the NTP packet.
   The server uses the same values to generate the message digest and
   verifies it matches the MAC in the packet. It then generates the MAC
   for the response using the same values, but with the IP source client and
     destination
   server addresses exchanged. The client generates the message digest
   and verifies it matches the MAC 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 while making it nearly impossible for an intruder to
   guess the next key ID.

   In broadcast mode dance clients normally do not send packets to the
   server, except when first starting up to verify credentials and
   calibrate the propagation delay in
     client/server mode. delay. At the same time the client runs the Autokey
     protocol as in that mode. After obtaining and verifying the cookie, the
     client continues
   broadcast dance to obtain and verify the autokey values. To obtain
     these values, the client must provide The dance requires the
   association ID of the particular server association, since there can
   be more than one operating in the same server. For this purpose, the NTP broadcast
   server packet includes the association ID in every packet sent, except response message
   sent and, 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 as well. After obtaining and
   verifying the other.
     A shared private cookie is conveyed using autokey values, the same scheme as in
     client/server mode, except that client verifies further server
   packets using the cookie autokey sequence.

   The symmetric dance is similar to the server dance and keeps only a random value.
   small amount of state between the arrival of a packet and departure
   of the reply. The key list for each direction is generated separately
   by each peer and used independently, but each is generated with the
   same cookie. The cookie is conveyed in a way similar to the server
   dance, except that the cookie is a random value. There exists a
   possible race condition where each peer sends a cookie request
   message before receiving the cookie response from the other peer. In
   this case, each peer winds up with two values, one it generated and
   one the other peer generated. The ambiguity is resolved simply by
   computing the working cookie as the exclusive-OR EXOR of the two values.

     Once the

   Autokey choreography includes one or more exchanges, each with a
   specific purpose, that must be completed in order. The client receives obtains
   the server host name, digest/signature scheme and validates identity shcme in
   the certificate, subsequent
     packets containing valid signed extension fields are presumed parameter exchange. It recursively obtains and verifies
   certificates on the trail leading to contain
     valid time values, unless these values fall outside a trusted certificate in the valid interval
     specified on
   certificate exchange and verifies the certificate. However, unless server identity in the identity
   exchange. In 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 exchange the
     protocol evolves, client obtains 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 cookie and
   autokey values, depending on the remaining truechimers are
     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 particular dance. Finally, the interesting issue of how
   client presents its self-signed certificate to mitigate between the timestamps of
     different associations. It might happen, server for instance, that
   signature in the
     timestamp sign exchange.

   The ultimate security of some Autokey message is ahead of the system clock by some
     presumably small amount. For this reason, timestamp comparisons between
     different associations based on digitally signed
   certificates and between associations a certificate infrastructure compatible with [RFC-
   2510] and [RFC-3280]. The Autokey protocol builds the system clock are
     avoided, except in certificate
   trail from the NTP intersection primary servers, which presumably have trusted self-
   signed certificates, recursively by stratum. Each stratum n + 2
   server obtains the certificate of a stratum n server, presumably
   signed by a stratum n - 1 server, and clustering algorithms.

     Once then the Autokey values have been instantiated, stratum n + 1 server
   presentes its own self-signed certificate for signature by the protocol is normally
     dormant. In all modes except broadcast, packets are normally sent
     without extension fields, unless
   stratum n server. As the packet is NTP subnet forms from the first one sent after
     generating a new key list or unless primary servers at
   the client has requested root outward to the cookie
     or autokey values. If leaves, each server accumulates non-
   duplicative certificates for some reason the client clock is stepped,
     rather than slewed, all cryptographic associations and time values for all
     associations are purged and the Autokey protocol restarted from scratch trails. In
   typical NTP subnets, this results in all associations. This insures that stale values never propagate
     beyond a clock step.

     Public Key Signatures and Timestamps

     While public key signatures provide strong protection against
     misrepresentation good deal of source, computing them is expensive. This invites useful
   redundancy, so far not explointed in the opportunity for an intruder present implementation.

   In order to clog prevent masquerade, it is necessary for the client or stratum n
   server by
     replaying old messages or to originate bogus messages. A client
     receiving such messages might be forced to verify what turns out prove identity to be
     an invalid signature and consume significant processor resources. the stratum n + 1 server when signing its
   certificate. In order to foil such attacks, every signed extension field carries many applications a
     timestamp in the form number of servers share a single
   security compartment, so it is only necessary that each server
   verifies identity to the NTP seconds at the signature epoch. group. Although no specific identity scheme
   is specified in this document, Appendix E describes a number of them
   based on cryptographic challenge-response algorithms. The
     signature span reference
   implementation includes the timestamp itself together all of them with optional
     additional data. If provision to add more if
   required.

   Once the Autokey protocol has verified a proventic source certificates and the NTP algorithms identity have been validated, subsequent
   packets are validated the time values, the system clock
     can be synchronized and by digital signatures will then carry a nonzero (valid)
     timestamp. Otherwise or autokey sequences.
   These packets are presumed to contain valid time values; however,
   unless the system clock has already been set by some other proventic
   means, it is unsynchronized and signatures
     carry a zero (invalid) timestamp. Extension fields with invalid
     timestamps are discarded before any not known whether these values are used actually represent a
   truechime or signatures
     verified.

     There are three signature types currently defined:

     1. Cookie signature/timestamp: Each association has a cookie for use
     when generating falsetick source. As the protocol evolves, the NTP
   associations continue to accumulate time values until a key list. The cookie value majority
   clique is determined along with available to synchronize the cookie signature system clock. At this point
   the NTP intersection algorithm culls the falsetickers from the
   population and timestamp upon arrival of a cookie request
     message. The values the remaining truechimers are returned in a a cookie response message.

     2. Autokey signature/timestamp: Each association has a key list for
     generating allowed to discipline
   the autokey sequence. clock.

   The autokey time values are determined along
     with for truechimer sources form a proventic partial
   ordering relative to the autokey applicable signature and timestamps. This raises
   the interesting issue of how to mitigate between the timestamps of
   different associations. It might happen, for instance, that the
   timestamp when a new key list of some Autokey message is
     generated, which occurs about once per hour in ahead of the reference
     implementation. The values system clock by
   some presumably small amount. For this reason, timestamp comparisons
   between different associations and between associations and the
   system clock are returned avoided, except in the NTP intersection and
   clustering algorithms and when determining whether a autokey response message.

     3. Public values signature/timestamp: The public key, certificate and
     leapsecond table has
   expired.

   Once the Autokey values have been instantiated, the dances are signed at
   normally dormant. In all except the time of generation, which
     occurs when broadcast dance, packets are
   normally sent without extension fields, unless the system clock packet is the
   first synchronized to one sent after generating a proventic
     source, when new key list or unless the values have changed client
   has requested the cookie or autokey values. If for some reason the
   client clock is stepped, rather than slewed, all cryptographic and about once per day after that,
     even if these values have not changed. During protocol operations, each
     of these
   time values and associated signatures and timestamps for all associations are returned in purged and the associated request or response message. While there are dances in fact
     three public value signatures, the all
   associations restarted from scratch. This insures that stale values are
   never propagate beyond a clock step. At intervals of about one day
   the reference implementation purges all signed at associations, refreshes all
   signatures, garbage collects expired certificates and refreshes the same
     time, so there is only one
   server seed.

6. Public Key Signatures and Timestamps

   While public value timestamp.

     The most recent timestamp key signatures provide strong protection against
   misrepresentation of each type source, computing them is saved expensive. This
   invites the opportunity for comparison. Once a
     valid signature with valid timestamp has been received, an intruder to clog the client or server
   by replaying old messages with
     invalid timestamps or earlier valid timestamps of the same type are
     discarded before the signature is verified. For signed to originate bogus messages. A client
   receiving such messages this
     deflects replays that otherwise might be forced to verify what turns out to
   be an invalid signature and consume significant processor
     resources; for other messages the Autokey protocol deflects message
     modification or replay by a wiretapper, but not necessarily by a
     middleman. resources.

   In addition, order to foil such attacks, every signed extension field carries a
   timestamp in the form of the NTP protocol itself is inherently resistant
     to replays and consumes only minimal processor resources.

     All cryptographic values used by seconds at the protocol are time sensitive and are
     regularly refreshed. In particular, files containing cryptographic basis
     values used by signature and encryption algorithms are regenerated from
     time to time. It is the intent that file regenerations occur without
     specific advance warning and without requiring prior distribution of epoch. The
   signature spans the
     file contents. While cryptographic data files are not specifically
     signed, every file name includes an entire extension called field including the filestamp,
     which is timestamp.
   If the Autokey protocol has verified a string of decimal digits representing proventic source and the NTP seconds at
   algorithms have validated the
     generation epoch.

     Filestamps and timestamps time values, the system clock can be compared in any combination
   synchronized and use signatures will then carry a nonzero (valid)
   timestamp. Otherwise the
     same conventions. It system clock is necessary to compare them from time to time to
     determine which unsynchronized and
   signatures carry a zero (invalid) timestamp. The protocol detects and
   discards replayed extension fields with old or duplicate timestamps,
   as well fabricated extension fields with bogus timestamps, before any
   values are earlier used or later. Since these quantities have signatures verified.

   There are three signature types currently defined:

   1. Cookie signature/timestamp: Each association has a
     granularity only to cookie for use
   when generating a key list. The cookie value is determined along with
   the second, such comparisons cookie signature and timestamp upon arrival of a cookie request
   message. The values are ambiguous if 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 same. Thus, the ambiguity must be resolved for each
     comparison operation as described below.

     It autokey signature and timestamp when a new key list is important that filestamps be proventic data; thus, they cannot be
     produced unless
   generated, which occurs about once per hour in the producer has been reference
   implementation. The values are returned in a autokey response
   message.

   3. Public values signature/timestamp: All 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. As such,
   source, when the filestamps represent a total ordering values have changed and about once per day after
   that, even if these values have not changed. During protocol
   operations, each of creation
     epoches these values and serve as means to expunge old data associated signatures and insure new data
   timestamps are
     consistent. As returned in the data associated request or response
   message. While there are forwarded from server to client, in fact several public value signatures,
   depending on the
     filestamps number of entries on the certificate list, the
   values are preserved, including those all signed at the same time, so there is only one public
   value timestamp.

   The most recent timestamp received of each type is saved for certificate and
     leapseconds files. Packets
   comparison. Once a valid signature with older filestamps valid timestamp has been
   received, messages with invalid timestamps or earlier valid
   timestamps of the same type are discarded before
     spending cycles to verify the signature.

     Autokey Dances

     This section presents an overview of signature is
   verified. For signed messages this deflects replays that otherwise
   might consume significant processor resources; for other messages the three
   Autokey protocols, called
     dances, corresponding to protocol deflects message modification or replay by a
   wiretapper, but not necessarily by a middleman. In addition, the NTP client/server, broadcast and symmetric
     active/passive modes. Each dance
   protocol itself is designed to be nonintrusive and inherently resistant to
     require no additional packets other than for regular NTP operations. The
     NTP protocol and Autokey dance operate independently and simultaneously replays and use the same packets. When the Autokey dance is over, subsequent
     packets are authenticated consumes only
   minimal processor resources.

   All cryptographic values used by the autokey sequence protocol are time sensitive and thus considered
     proventic as well. Autokey assumes clients poll servers at a relatively
     low rate, such as once per minute.
   are regularly refreshed. In particular, it files containing
   cryptographic basis values used by signature and encryption
   algorithms are regenerated from time to time. It is assumed the intent that a
     request sent at one poll opportunity will normally result in a response
     before
   file regenerations occur without specific advance warning and without
   requiring prior distribution of the next poll opportunity.

     The Autokey protocol file contents. While
   cryptographic data unit files are not specifically signed, every file is
   associated with a filestamp in the extension field, one or more form of
     which can be piggybacked in the NTP packet. An extension field contains
     either a request with optional data seconds at the
   creation epoch. It is not the intent in this document to specify file
   formats or names or encoding rules; however, whatever conventions are
   used must support a response with data. To avoid
     deadlocks, any number of responses NTP filestamp in one form or another. Additional
   details specific to the reference implementation are in Appendix B.

   Filestamps and timestamps can be included compared in a packet, but only
     one request. A response is generated for every request, even if any combination and use
   the
     requestor same conventions. It is not synchronized necessary to compare them from time to
   time to determine which are earlier or proventicated. Some requests and most
     responses carry timestamped signatures. The signature covers later. Since these quantities
   have a granularity only to the data,
     timestamp and filestamp, where applicable. Only second, such comparisons are ambiguous
   if the packet passes all
     extension field tests is the signature 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 client
     association operations. The nine bits values are stored along with the
     digest/signature scheme identifier same. Thus, the ambiguity must be resolved for
   each comparison operation as described in Appendix C.

   It is important that filestamps be proventic data; thus, they cannot
   be produced unless the host status word of producer has been synchronized to a proventic
   source. As such, the server
     and in filestamps throughout the association status word NTP subnet represent a
   partial ordering of the client. In all dances the
     client first sends an Association request message creation epoches and receives the
     Association response specifying which cryptographic values the server is
     prepared serve as means to offer
   expunge old data and insure new data are consistent. As the digest/signature scheme it will use.

     If compatible, the client installs the data are
   forwarded from server status word as the
     association status word and sends a Certificate request message to client, the
     server. The server returns a Certificate response filestamps are preserved,
   including the those for certificate and signature. The reference implementation requires the
     certificate to be self-signed, which serves as an additional consistency
     check. This check may be removed in future and replaced with a
     certificate trail mechanism. If the certificate contents and signature
     are valid, NTP timestamps in this and subsequent messages leapseconds files. Packets with valid
     signatures
   older filestamps are considered proventic.

     In client/server mode the client sends a Cookie request message
     including discarded before spending cycles to verify the public key
   signature.

7. Autokey Protocol Overview

   This section presents an overview of the host key. The server constructs the
     cookie as described above three server, symmetric and encrypts it using this key. It sends a
     Cookie response including the encrypted cookie
   broadcast dances. Each dance is designed to the client be nonintrusive and
     expunges all values resulting from the calculations in order to remain
     stateless.
   require no additional packets other than for regular NTP operations.
   The client verifies the signature NTP and decrypts Autokey protocols operate independently and
   simultaneously and use the cookie. A
     similar same packets. When the preliminary dance is used in symmetric modes, but
   exchanges are complete, subsequent packets are validated by the cookie is generated
   autokey sequence and thus considered proventic as well. Autokey
   assumes clients poll servers at a random value.

     The cookie is used to construct the key list and autokey values in all
     modes. relatively low rate, such as once
   per minute. In client/server mode there particular, it is no need to provide these values to
     the server, so once assumed that a request sent at one
   poll opportunity will normally result in a response before the cookie has been obtained next
   poll opportunity.

   The Autokey protocol data unit is the client extension field, one or more of
   which can generate be piggybacked in the key list 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 requestor is not synchronized to a proventic
   source, but contain meaningful data only if the responder is
   synchronized to a proventic source. Some requests and validate succeeding packets directly. In other modes most responses
   carry timestamped signatures. The signature covers the client retrieves entire
   extension field, including the autokey values from timestamp and filestamp, where
   applicable. Only if the server using an Autokey
     message exchange. Once these values have been received, packet passes all extension field tests are
   cycles spent to verify the client
     validates succeeding packets using signature.

   All dances begin with the autokey sequence as described
     previously.

     A final parameter exchange occurs when the server has where the leapseconds table, as
     indicated in client obtains
   the server host name and status word. If so, the client obtains word specifying the table digest/signature
   scheme it will use and compares the filestamp identity schemes it supports. The dance
   continues with its own leapseconds table filestamp, if
     available. If the server table is newer than the client table, certificate exchange where the client replaces its table with obtains and
   verifies the server table. The client, acting as
     server, can now provide certificates along the most recent table trail to any of its own
     dependent clients. In symmetric modes, this results in both peers having
     the newest table.

     Status Words

     Each sever and client operating as a server implements trusted, self-cigned
   certifidate, usually, but not necessarily, provided by a host status
     word and an association status word with the format and content shown
     below. The low order four host status bits are lit during host
     initialization, depending on whether cryptographic data files primary
   (stratum 1) server. Primary servers are
     present by design proventic with
   trusted, self-signed certificates.

   However, the certificate trail is not sufficient protection against
   middleman attacks unless an identity scheme such as described in
   Appendix E or not; proof-of-posession scheme in [RFC-2875] is available.
   While the next four association bits are dark. There protocol for a generic challenge/response scheme is defined
   in this document, the choice of one or another required or optional
   identification schemes is yet to be determined. If all certificate
   signatures along the trail are two
     additional bits implemented separately. The high order 16 bits specify verified and the message digest/signature encryption scheme.

     The host status word server identity is provided
   confirmed, the server is declared proventic. Once declared proventic,
   the client verifies packets using digital signatures and/or the
   autokey sequence.

   Once synchronized to clients in a proventic source, the Association response
     message. The client initializes continues with
   the association status word and then
     lights and dims sign exchange where the association bits server acting as CA signs 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|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ client
   certificate. The host status bits are defined as follows:

     ENB - Lit if CA interprets the server implements certificate as a X.509v3
   certificate request, but verifies the Autokey protocol and is prepared
     to dance.

     ENC - Lit signature if it is self-signed.
   The CA extracts the server has loaded subject, issuer, extension fields and public key,
   then builds a valid encryption key file. This bit
     is normally lit, but can dim if an error occurs.

     SIG - Lit if new certificate with these data along with its own
   serial number and begin and end times, then signs it using its own
   public key. The client uses the signed certificate in its own role as
   CA for dependent clients.

   In the server has loaded a valid signature dance the client presents its public key file. This bit
     is included primarily for error supervision and can be either lit or
     dim.

     LPF - Lit if requests
   the server has loaded to generate and return a valid leapseconds file. This bit
     can be either lit or dim. cookie encrypted with this key.
   The client association status bits are defined as follows:

     AUT - Lit when server constructs the certificate is present cookie as described above and validated. When lit,
     signed values in subsequent messages are presumed proventic.

     CKY - Lit when encrypts it
   using this key. The client decrypts the cookie for use in generating
   the key list. A similar dance is first received and validated.

     KEY - Lit when used in symmetric mode, where one
   peer acts as the autokey values are first received client and validated. When
     lit, clients can validate packets without extension fields according to the autokey sequence.

     LPT - Lit when other the leapseconds table is received server. In case of
   overlapping messages, each peer generates a cookie and validated.

     An additional bit LST not part the agreed
   common value is computed as the EXOR of the association status word lights
     when two cookies.

   The cookie is used to generate the key list is regenerated and signed and dims when the autokey values are transmitted. This is necessary to avoid livelock under some
     conditions.

     An additional bit LBK not part of the association status word lights
     when the association transmit timestamp matches the packet originate
     timestamp and dims otherwise. If lit, this confirms the packet was
     received in response to one previously sent by this association.

     Host State Variables

     Host Name
     The name of all
   dances. In the host returned by server dance there is no need to provide these values
   to the Unix gethostname() library
     function. It must agree with server, so once the subject and issuer name in cookie has been obtained the
     certificate.

     Host Key
     The RSA key from client can
   generate the host key file list and used to encrypt/decrypt cookies.
     It carries validate succeeding packets directly. In
   other dances the public value timestamp and client requests the filestamp at autokey values from the host key
     file creation epoch. This is also server
   or, in some modes, the signature key, unless a signature server provides them as each new key list is specified.

     Public Key
     The public encryption key for
   generated. Once these values have been received, the Cookie request message and derived
     from client validates
   succeeding packets using the host key. It carries autokey sequence as described
   previously.

   A final exchange occurs when the public value timestamp and server has the
     filestamp at leapseconds table, as
   indicated in the host key file creation epoch.

     Sign Key
     The RSA or DSA key from status word. If so, the sign key file and used to encrypt
     signatures. It carries client requests the public value timestamp
   table and compares the filestamp at
     the sign key file creation epoch.

     Certificate
     The X.509 certificate from with its own leapseconds table
   filestamp, if available. If the certificate file. It carries the public
     value timestamp and the filestamp at the certificate file creation
     epoch.

     Leapseconds Table, Leapseconds Table Filestamp
     The NIST leapseconds server table from the NIST leapseconds file. It carries is newer than the public value timestamp and client
   table, the filestamp at client replaces its table with the leapseconds file
     creation epoch.

     Digest/signature NID server table. The identifier of the message digest/signature encryption scheme derived
     from the sign key. It must agree with
   client, acting as server, can now provide the NID on most recent table to
   any of its dependent clients. In symmetric mode, this results in both
   peers having the certificate.

     Client Association newest table.

8. Autokey State Variables

     Peer Association ID
     The association ID Machine

   This section describes the formal model of the peer Autokey state machine,
   its state variables and the state transition functions.

8.1 Status Word

   Each server and client operating also as received in a response message.

     Host Name server implements a host
   status word, while each client implements a server status word for
   each server. Both words have the format and content shown below. The name
   low order 16 bits of the host returned by status words define the Association response. It must agree
     with state of the subject name in Autokey
   protocol, while the certificate.

     Digest/Signature NID
     The identifier of high order 16 bits specify the message
   digest/signature encryption scheme
     returned in the Association response message. It must agree with scheme. Bits 24-31 of the
     value encoded status word are
   reserved for server use, while bits 16-23 are reserved for client
   use. There are four additional bits implemented separately.

   The host status word is included in the certificate.

     Public Values Timestamp ASSOC request and response
   messages. The timestamp returned by client copies this word to the latest Certificate response, Cookie
     request or Leapseconds message.

     Certificate
     The X.509 certificate returned in the certificate response message,
     together with its timestamp and filestamp.

     Cookie
     The cookie returned in a Cookie response message, together with its
     timestamp and filestamp.

     Receive Autokey values
     The autokey values returned in an Autokey response message, together
     with its timestamp and filestamp.

     Server Association State Variables (broadcast associatino status word
   and symmetric modes)

     Association ID
     The then lights additional association ID of bits as the server for use in client request messages.

     Send Autokey Values
     The autokey values, signature and timestamp.

     Key List
     A sequence of key IDs starting with dance proceeds.
   Once lit, these bits never come dark unless a random autokey seed general reset occurs
   and each
     pointing to the next. It protocol is computed timestamped and signed at restarted from the next
     poll opportunity when beginning.

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

   The host status bits are defined as follows:

   ENB - Lit if the server implements the key list is empty. Autokey Seed
     The private value used protocol and is
   prepared to initialize dance.

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

   IDN
   These three bits select which identity scheme is randomized in use. While
   specific coding for
     each new key list.

     Current Key Number
     The index of various schemes is yet to be determined, the entry on
   schemes available in the Key List to be used at reference implementation and described in
   Appendix E include the next poll
     opportunity.

     Send Encrypt Values (symmetric modes only) following.

   0x0 Trusted Certificate (TC) Scheme (default)
   0x1 Private Certificate (PC) Scheme
   0x2 Schnorr aka Identify-Friendly-or-Foe (IFF) Scheme
   0x4 Guillard-Quisquater (GC) Scheme

   The encrypted cookie, signature and timestamp computed upon arrival PC scheme is exclusive of any other scheme. Otherwise, either
   none or the Cookie request message. These data are held until IFF scheme or the next poll
     opportunity.

     Server seed GC scheme or both can be selected.

   The private value hashed with the IP addresses to construct the cookie
     used in client/server mode. It is randomized server status bits are defined as follows:

   VAL 0x0100
   Lit when the server certificate and public value
     signatures are refreshed.

     Autokey Messages

     There key are currently five Autokey request types and five corresponding
     responses. An abbreviated description of these messages is given below; validated.

   IFF 0x0200
   Lit when the detailed formats server identity credentials are confirmed by one of
   several schemes described in Appendix A.

     Association Message (1)
     The client sends the request to retrieve later.

   PRV 0x0400
   Lit when the host status word and host
     name. The server responds with these values.

     Certificate Message (2)
     The client sends signature is verified using the request to retrieve public key and
   identity credentials. Also called the server certificate. The
     server responds with proventic bit elsewhere in this
   document. When lit, signed values in subsequent messages are presumed
   proventic, but not necessarily time-synchronized.

   CKY 0x0800
   Lit when the certificate.

     Cookie Message (3)
     The client sends cookie is received and validated. When lit, key lists
   can be generated.

   AUT 0x1000
   Lit when the request, including autokey values are received and validated. When lit,
   clients can validate packets without extension fields according to
   the public member of autokey sequence.

   SGN 0x2000
   Lit when the host
     key, to retrieve certificate is signed by the cookie. The server responds with the cookie
     encrypted with the public key.

     Autokey Message (4)
     The client sends the request to retrieve the autokey values, if
     available. The server responds with these values.

     Leapseconds Message (5)
     The client sends server.

   LPT 0x4000
   Lit when the request including its leapseconds table, if
     available. The server responds with its own leapseconds table. Both the
     client table is received and server agree to use the version with the latest filestamp.

     State Transitions

     The state transitions of the three dances validated.

   There are shown below. The
     capitalized truth values represent four additional status bits LST, LBK, DUP and SYN not
   included in the association status word bits, word. All except for SYN are association
   properties, while SYN is a host property. These bits may be lit or
   dim as the SYNC value, which protocol proceeds; all except LST are active whether or
   not the protocol is true running. LST is lit when the host key list is
   regenerated and signed and comes dim after the autokey values have
   been transmitted. This is necessary to avoid livelock under some
   conditions. SYN is lit when the client has synchronized to a
   proventic source and false otherwise. All truth values never dim after that. There are
     initialized false and become true upon two error bits:
   LBK indicates the arrival of received packet does not match the last one sent
   and DUP indicates a specific
     response messages, as detailed duplicate packet. These bits, which are described
   in Appendix C, are lit if the above status bits description.

     Client/Server Dance

     The client/server dance begins when the client sends an Association
     request message to corresponding error has occurred for
   the server. It ends upon arrival current packet and dim otherwise.

8.2 Host State Variables

   Host Name
   The name of the Cookie
     response, which lights host returned by the CKY and KEY bits. Subsequent packets received
     without extension fields are validated by Unix gethostname() library
   function. The name must agree with the autokey sequence. An
     optional final exchange subject name in the host
   certificate.

   Host Status Word
   This word is possible initialized when the host first starts up. The format is
   described above.

   Host Key
   The RSA public/private key used to retrieve encrypt/decrypt cookies. This is
   also the leapseconds table.

             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 (LPF & !LPT)
                             send_Leapseconds_request;
             }

     Broadcast Client Dance default sign key.

   Sign Key
   The broadcast client dance begins RSA or DSA public/private key used to encrypt/decrypt signatures
   when the client receives host key is not used for this purpose.

   Sign Digest
   The message digest algorithm used to compute the first
     broadcast packet, which includes an Association response with signature before
   encryption.

   IFF Parameters
   The parameters used in the
     association ID. IFF identity scheme described in Appendix
   E.

   GQ Parameters
   The broadcast client uses parameters used in the association ID to initiate
     a client/server dance GQ identity scheme described in Appendix
   E.

   GQ keys
   The public/private key used in order to calibrate the propagation delay. GQ identity scheme described in
   Appendix E.

   Server Seed
   The
     dance ends upon arrival of private value hashed with the Autokey response, which lights IP addresses to construct the KEY
     bit. Subsequent packets received without extension
   cookie.

   Certificate Information Structure (CIS)
   A structure including certain information fields are validated
     by the autokey sequence. An optional final exchange is possible to
     retrieve from an X.509v3
   certificate, together with the leapseconds table. When certificate itself encoded in ASN.1
   syntax and including X.509v3 extension fields. Each structure carries
   the server generates a new key
     list, public value timestamp and the server replaces filestamp of the Association response with an Autokey
     response certificate file
   where it was generated. Elsewhere in this document the CIS will not
   be distinguished from the certificate unless noted otherwise.

   Certificate List
   CIS structures are stored on the certificate list in order of
   arrival, with the most recently received CIS placed first 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 on the
   list. The symmetric active dance begins when list is initialized with the active peer sends an
     Association request to CIS for the passive peer. The passive peer mobilizes an
     association and steps host certificate,
   which is read from the same dance certificate file. Additional CIS entries are
   pushed on the list as certificates are obtained from the beginning. Until servers
   during the
     active peer is synchronized certificate exchange. CIS entries are discarded if
   overtaken by newer ones or expire due to a proventic source (which could be old age.

   Host Certificate
   The self-signed X.509v3 certificate for the
     passive peer) host. The subject and can sign messages,
   issuer fields consist of the passive peer will loop waiting
     to light host name, while the CRF bit message
   digest/signature encryption scheme consists of the sign key and
   message digest defined above. Optional information used in the active peer will skip
   identity schemes is carried in X.509v3 extension fields compatible
   with [RFC-3280].

   Public Key Values
   The public encryption key for the cookie exchange.

     Meanwhile, COOKIE request, which consists of
   the active peer retrieves public value of the certificate and autokey values
     from host key. It carries the passive peer public values
   timestamp and lights the KEY bit. When for some reason
     either peer generates a new key list, at filestamp of the first opportunity host key file.

   Leapseconds Table Values
   The NIST leapseconds table from the peer
     sends NIST leapseconds file. It carries
   the autokey values; that is, it pushes the values rather than
     pulls them. This is to prevent a possible deadlock where each peer is
     waiting for public values from timestamp and the 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 filestamp of the active peer has synchronized to a proventic source, it includes
     timestamped signatures with its messages. leapseconds
   file.

8.3 Client State Variables (all modes)

   Association ID
   The passive peer, which has
     been stalled waiting for the CRF bit to light and the active peer, which
     now finds association ID used in responses. It is assigned when the SYNC bit lit, continues their respective dances.
   association is mobilized.

   Server Association ID
   The next
     message sent by either peer server association ID used in requests. It is initialized from
   the first nonzero association ID field in a Cookie request. response.

   Server Subject Name
   The recipient rolls a
     random cookie, lights its CKY bit and returns the encrypted cookie server host name determined in the Cookie response. parameter exchange.

   Server Issuer Name
   The recipient decrypts host name signing the cookie and lights its
     CKY bit. certificate. It is not a protocol error if both peers happen extracted from the
   current server certificate upon arrival and used to send a cookie request
     at the same time. In this case both peers will have two values, one
     generated by one peer and next
   item on the other received from certificate trail.

   Server Status Word
   The host status word of the other peer. In
     such cases server determined in the working cookie parameter
   exchange.

   Server Public Key
   The public key used to decrypt signatures. It is constructed as the exclusive-OR of the
     two values.

     At extracted from the next packet transmission opportunity, either peer generates a new
   first certificate received, which by design is the server host
   certificate.

   Server Message Digest
   The digest/signature scheme determined in the parameter exchange.

   Identification Challenge
   A 512-bit nonce used in the identification exchange.

   Group Key
   A 512-bit secret group key list and lights used in the LST bit; however, there may already be an
     Autokey request queued for transmission and identification exchange. It
   identifies the rules say no more than
     one request cryptographic compartment shared by the server and
   client.

   Receive Cookie Values
   The cookie returned in a packet. When available, either peer sends an COOKIE response, together with its timestamp
   and filestamp.

   Receive Autokey
     response Values
   The autokey values returned in an AUTO response, together with its
   timestamp and clears the LST bit. filestamp.

   Receive Leapsecond Values
   The leapsecond table returned by a LEAP response, together with its
   timestamp and filestamp.

8.4 Server State Variables (broadcast and symmetric modes)

   Send Cookie Values
   The cookie encryption values, signature and timestamps.

   Send Autokey Values
   The recipient initializes the autokey values, clears signature and timestamps.

   Key List
   A sequence of key IDs starting with the LST bit autokey seed and lights each
   pointing to the KEY bit. Subsequent packets
     received without extension fields are validated by next. It is computed, timestamped and signed at the autokey sequence.
   next poll opportunity when the key list becomes empty.

   Current Key Number
   The above description assumes index of the active peer synchronizes to entry on the
     passive peer, which itself is synchronized Key List to some other source, such as
     a radio clock or another NTP server. In this case, the active peer is
     operating be used at a stratum level one greater than the passive peer and so
     the passive peer will not synchronize to it unless it loses its own
     sources and the active peer itself has another source.

     Key Refreshment

     About once per day the server seed is randomized and the signatures
     recomputed. The 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 next poll
   opportunity.

8.5 Autokey operations
     includes provisions for various kinds of error conditions that can arise
     due to missing files, corrupted data, protocol violations and packet
     loss or misorder, not to mention hostile intrusion. Messages

   There are two
     mechanisms which maintain the liveness state currently eight Autokey requests and eight corresponding
   responses. An abbreviated description of these messages is given
   below; the protocol, the
     reachability register defined detailed formats are described in RFC-1305 and the watchdog timer, which Appendix A.

   Association Message (ASSOC)
   This message is new used in NTP Version 4. the parameter exchange. The reachability register is an 8-bit register that shifts left with 0
     replacing client sends the rightmost bit. A shift occurs for every poll interval,
     whether or not a poll is actually sent. If an arriving packet passes all
     authentication
   request with its host name and sanity checks, status word. The server sends the rightmost bit is set to 1.
   response with its host name and status word. If any
     bit in this register is a 1, the server response
   is reachable, otherwise it acceptable, ENB is
     unreachable. If lit. When the server was once reachable and then becomes
     unreachable, a general reset PC identity scheme is performed. A general reset reinitializes
     all association variables to in use, the state when first mobilized
   ASSOC response lights VAL, IFF and returns
     all acquired resources to SIG, since the system. IFF exchange is
   complete at this point.

   Certificate Message (CERT)
   In addition, if the association is
     not configured, it is demobilized until certificate exchange the next packet is received.

     The watchdog timer increments for every poll interval, whether or not a
     poll is actually sent client sends the request with the
   server subject name and regardless of the reachability state. The
     counter is set to zero upon arrival of a packet from a proventicated
     source, as determined by server responds with the Autokey protocol. certificate with
   that subject name. In the reference
     implementation, if TC identity scheme the counter reaches 16 a general reset is performed.
     In addition, if client sends the association is configured,
   request with the poll interval is
     doubled. This reduces server issuer name and the network load for packets server responds with the
   certificate with that are unlikely to
     elicit a response.

     At each state in subject name. In either case if the protocol certificate
   is valid, the client expects a particular response
     from lights VAL.

   Cookie Message (COOKIE)
   The client sends the server. A request is included in with its public key. The server responds
   with the NTP message sent at each
     poll interval until a valid response cookie encrypted with this public key. If the cookie is received or a general reset
     occurs, in which case
   valid, the protocol restarts from client lights CKY.

   Autokey Message (AUTO)
   The client sends the beginning. In some
     cases noted below, certain kinds of errors cause appropriate action
     which avoids request to retrieve the somewhat lengthy timeout/restart cycle. While this
     behavior might be considered rather conservative, Autokey values. The
   server responds with these values. If the advantage is that
     old cryptographic and time values can never persist from one
     mobilization to the next.

     There are a number of situations where some event happens that causes valid, the remaining autokeys on
   client lights AUT.

   Leapseconds Message (LEAP)
   The client sends the key list to become invalid. When one of
     these situations happens, request with its leapseconds table, if
   available. The server responds with its own leapseconds table. Both
   the key list client and associated autokeys in server agree to use the
     key cache are purged. A new key list, signature and timestamp are
     generated when version with the next NTP message is sent, assuming there is one.
     Following is a list of these situations.

     1. latest
   filestamp. When the cookie value changes for any reason.

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

     3. When the poll interval is changed. In this case lights
   LPT.

   Sign Message (SIGN)
   The client sends the calculated
     expiration times for request with its host certificate. The server
   extracts the keys become invalid.

     4. When subject, public key and optional extension fields, then
   returns a general reset is performed.

     5. certificate signed using its own public key. If a problem the
   certificate is detected valid when an entry received by the client, it is fetched from linked in the key list.
     This could happen if
   certificate list and the key was marked non-trusted or timed out, either
     of which implies a software bug.

     6. When client lights SGN.

   IFF Message (IFF)
   This exchange is used with the signatures are refreshed, IFF identity scheme described in
   Appendix E. If the key lists for all associations
     are purged.

     7. When server identity is confirmed, the client lights
   IFF and PRV.

   GQ Message (GQ)
   This exchange is first synchronized or used with the system clock GQ identity scheme described in
   Appendix E. If the server identity is stepped,
     the key lists for all associations are purged.

     There are special cases designed to quickly respond to broken
     associations, such as when a server restarts or refreshes keys. Since confirmed, the client cookie lights
   IFF and PRV.

   8.5 Protocol State Transitions

   The protocol state machine is invalidated, very simple but robust. The state is
   determined by the server rejects status bits defined above. The state
   transitions of the next client
     request three dances are shown below. The capitalized
   truth values represent the server status bits. All server bits are
   initialized dark and returns light up upon the arrival of a crypto-NAK packet. Since specific response
   message, as detailed above.

   When the crypto-NAK has no
     MAC, system clock is first set and about once per day after that,
   or when the problem for system clock is stepped, the client server seed is to determine whether it refreshed,
   signatures and timestamps updated and the protocol restarted in all
   associations. When the server seed is legitimate refreshed or a new certificate
   or leapsecond table is received, the result of intruder mischief. In order public values timestamp is reset
   to reduce the vulnerability current time and all signatures are recomputed.

   8.5.1 Server Dance

   The server dance begins when the client sends an ASSOC request to such mischief, the crypto-NAK is believed only if
   server. It ends when the result of a
     previous packet sent first signature is verified and PRV is lit.
   Subsequent packets received without extension fields are validated by
   the client, as confirmed by autokey sequence. An optional LEAP exchange updates the LBK status bit.
     This bit is lit in
   leapseconds table. Note the NTP protocol if order of the packet originate timestamp
     matches identity exchanges and that
   only the association transmit timestamp. While this defense can first one will be
     easily circumvented by a middleman, it does deflect other kinds of
     intruder warfare. The LBK bit is also used to validate most responses if multiple schemes are available.
   Note also that the SIGN and some LEAP requests as well.

     Security Analysis

     This section discusses the most obvious security vulnerabilities in the
     various Autokey dances. Throughout the discussion the cryptographic
     algorithms themselves are assumed secure; that is, a brute force
     cryptanalytic attack will not reveal issued until the host private key or sign
     private key or cookie value or server seed or autokey seed or be able
   client has synchronized to
     predict the random generator values.

     There are three tiers of defense against intruder attacks. The first is
     a keyed message digest including a secret proventic source.

       while (1) {
      wait_for_next_poll;
      make_NTP_header;
      if (response_ready)
          send_response;
      if (!ENB)      /* parameters exchange */
          ASSOC_request;
      else if (!VAL)       /* certificate exchange */
          CERT_request(Host_Name);
      else if (IDN & GQ && !IFF) /* GQ identity exchange */
          GQ_challenge;
      else if (IDN & IFF && !IFF)/* IFF identity exchange */
          IFF_challenge;
      else if (!IFF)       /* TC identity exchange */
          CERT_request(Issuer_Name);
      else if (!CKY)       /* cookie conveyed in encrypted
     form. A packet is discarded exchange */
          COOKIE_request;
      else if (SYN && !SIG)   /* sign exchange */
          SIGN_request(Host_Certificate);
      else if (SYN && LPF & !LPT)/* leapseconds exchange */
          LEAP_request;
      }

   When the message digest does not match the
     MAC. The second tier is the autokey sequence, which PC identity scheme 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 use, the last
     one received ASSOC response lights VAL,
   IFF and by induction to a signed extension field, as a
     practical matter a wiretapper cannot predict SIG, the next autokey COOKIE response lights CKY and thus
     cannot spoof a AUT and the first
   valid packet. The third tier signature lights PRV.

   8.5.2 Broadcast Dance

   THe only difference between the broadcast and server dances is timestamped signatures
     which reliably bind the
   inclusion of an autokey values to the private key of a trusted
     server.

     In addition to exchange following the three-tier defense strategy, all packets are
     protected by cookie
   exchange. The broadcast dance begins when the NTP sanity checks. Since NTP packets carry time values,
     replays of old or bogus packets can be deflected once client receives the
   first broadcast packet, which includes an ASSOC response with
   association ID. The broadcast client has
     synchronized uses the association ID to proventic sources. Additional sanity checks involving
     timestamps and filestamps are summarized
   initiate a server dance in Appendix C.

     During order to calibrate the Autokey dances propagation delay.

   The dance ends when extension fields are in use, the cookie first signature is a public value (0) rather than a shared private value. Therefore, an
     intruder can easily construct a packet with a valid MAC; however, once
     the certificate verified and PRV is stored, lit.
   Subsequent packets received without extension fields carry timestamped signatures
     and bogus packets are readily avoided. While most request messages are
     unsigned, only the Association response message is unsigned. This
     message is used in the first packet sent validated by a server or peer and in most
     NTP broadcast packets.

     A bogus Association response message can cause a client livelock or
     deadlock condition. However, these packets do not affect NTP time values
     and do not consume significant resources. To reduce
   the vulnerability to
     bogus packets, autokey sequence. An optional LEAP exchange updates the NTP transmit timestamp in
   leapseconds table. When the Association and
     Certificate request messages is used as a nonce. The NTP server copies
     this value to the originate timestamp in the NTP header, so that the
     client can verify that the message is generates a response to new key list, the original
     request. To minimize
   server replaces the possibility that ASSOC response with an intruder can guess the
     nonce, the client should fill AUTO response in the low order unused bits first
   packet sent.

       while (1) {
      wait_for_next_poll;
      make_NTP_header;
      if (response_ready)
          send_response;
      if (!ENB)      /* parameters exchange */
          ASSOC_request;
      else if (!VAL)       /* certificate exchange */
          CERT_request(Host_Name);
      else if (IDN & GQ && !IFF) /* GQ identity exchange */
          GQ_challenge;
      else if (IDN & IFF && !IFF)/* IFF identity exchange */
          IFF_challenge;
      else if (!IFF)       /* TC identity exchange */
          CERT_request(Issuer_Name);
      else if (!CKY)       /* cookie exchange */
          COOKIE_request;
      else if (!AUT)       /* autokey values exchange */
          AUTO_request;
      else if (SYN && !SIG)   /* sign exchange */
          SIGN_request(Host_Certificate);
      else if (SYN && LPF & !LPT)/* leapseconds exchange */
          LEAP_request;
      }

   When the PC identity scheme is in use, the
     transmit timestamp with random values. In addition, replays of all
     except Autokey ASSOC response messages are discarded before the signatures are
     verified.

     In client/server lights VAL,
   IFF and symmetric modes extension fields are no longer
     needed after the Autokey dance has concluded. The client validates the
     packet using SIG, the message digest COOKIE response lights CKY and autokey sequence. A successful
     middleman attack is unlikely, since without the server seed the intruder
     cannot produce the cookie AUT and without the cookie cannot produce a valid
     MAC. In broadcast mode a wiretapper cannot synthesize a first
   valid packet
     without signature lights PRV.

   8.5.3 Symmetric Dance

   The symmetric dance is intricately choreographed. It begins when the autokey seed, so cannot manufacture
   active peer sends an bogus packet
     acceptable ASSOC request to the receiver. passive peer. The most the intruder can do is replay passive
   peer mobilizes an
     old packet causing association and both peers step the client to repeat hash operations until exceeding same dance from
   the maximum key number. On beginning. Until the other hand, active peer is synchronized to a middleman proventic
   source (which could do real
     harm by intercepting a packet, using be the key ID to generate a correct
     autokey passive peer) and then synthesizing a bogus packet. There does not seem to be
     a suitable solution can sign messages, the
   passive peer loops waiting for this as long as the server has no per-client
     state.

     A client instantiates cryptographic variables only if timestamp in the ASSOC response to
   light up. Until then, the active peer dances the server steps, but
   skips the sign, cookie and leapseconds exchanges.

      while (1) {
         wait_for_next_poll;
         make_NTP_header;
      if (!ENB)      /* parameters exchange */
          ASSOC_request;
      else if (!VAL)       /* certificate exchange */
          CERT_request(Host_Name);
      else if (IDN & GQ && !IFF) /* GQ identity exchange */
          GQ_challenge;
      else if (IDN & IFF && !IFF)/* IFF identity exchange */
          IFF_challenge;
      else if (!IFF)       /* TC identity exchange */
          CERT_request(Issuer_Name);
      else if (SYN && !SIG)   /* sign exchange */
          SIGN_request(Host_Certificate);
      else if (SYN && !CKY)   /* cookie exchange */
          COOKIE_request;
      else if (!LST)       /* autokey values response */
          AUTO_response;
      else if (!AUT)       /* autokey values exchange */
          AUTO_request;
      else if (SYN && LPF & !LPT)/* leapseconds exchange */
          LEAP_request;
      }

   When the PC identity scheme is in use, the ASSOC response lights VAL,
   IFF and SIG, the COOKIE response lights CKY and AUT and the first
   valid signature lights PRV.

   Once the active peer has synchronized to a proventic source. A host source, it
   includes timestamped signatures with its messages. The first thing it
   does not after lighting timestamps is dance the sign values or
     generate cryptographic data files unless synchronized to a proventic
     source. exchange so that the
   passive peer can survive the default identity exchange, if necessary.
   This raises an interesting issue; how does a client generate
     proventic cryptographic files before it is pretty wierd, since the passive peer will find the active
   certificate signed by its own public key.

   The passive peer, which has ever been synchronized stalled waiting for the active
   timestamps to a
     proventic source? Who shaves light up, now mates the barber if dance. The initial value of the barber shaves everybody
     in town who does not shave himself? In principle, this paradox
   cookie is
     resolved zero. If a COOKIE response has not been received by assuming either
   peer, the primary (stratum 1) servers are proventicated
     by external phenomological means.

     Cryptanalysis

     Some observations on next message sent is a COOKIE request. The recipient rolls
   a random cookie, lights CKY and returns the particular engineering constraints of encrypted cookie. The
   recipient decrypts the
     Autokey cookie and lights CKY. It is not a protocol are in order. First, the number of bits in some
     cryptographic values are considerably smaller than would ordinarily be
     expected for strong cryptography. One of
   error if both peers happen to send a COOKIE request at the reasons for same time.
   In this is the
     need for compatibility with previous NTP versions; another is the need
     for small and constant latencies case both peers will have two values, one generated by itself
   peer and minimal processing requirements.
     Therefore, what the scheme gives up on other received from the strength of these values must
     be regained by agility in other peer. In such cases the rate of change
   working cookie is constructed as the EXOR of the cryptographic basis two values. Thus, autokeys are used only once and basis values are
     regenerated frequently. However, in most cases even a successful
     cryptanalysis of these values compromises only

   At the next packet transmission opportunity, either peer generates a particular
     client/server association
   new key list and lights LST; however, there may already be an AUTO
   request queued for transmission and does not represent a danger to the general
     population.

     While the protocol has not been subjected to a formal analysis, rules say no more than one
   request in a few
     preliminary assertions can be made. packet. When available, either peer sends an AUTO
   response and dims LST. The protocol cannot loop forever in
     any state, since recipient initializes the association timeout autokey values,
   dims LST and general reset insure that lights AUT. Subsequent packets received without
   extension fields are validated by the association variables will eventually be purged and autokey sequence.

   The above description assumes the protocol
     restarted from active peer synchronizes to the beginning. However, if something
   passive peer, which itself is seriously wrong, synchronized to some other source, such
   as a radio clock or another NTP server. In this case, the timeout/restart cycle could continue indefinitely until whatever is
     wrong active peer
   is fixed.

     Clogging Attacks

     There are two clogging vulnerabilities exposed in the protocol design: operating at a
     sign attack where the intruder hopes to clog stratum level one greater than the victim server with
     needless signature computations, passive peer and a verify attack where
   so the intruder
     attempts passive peer will not synchronize to clog it unless it loses its
   own sources and the victim client with needless verification
     computations. active peer itself has another source.

9. Error Recovery

   The Autokey uses public key encryption algorithms protocol state machine includes provisions for both
     signature and cookie encryption various
   kinds of error conditions that can arise due to missing files,
   corrupted data, protocol violations and these algorithms require significant
     processor resources.

     In order packet loss or misorder, not
   to reduce mention hostile intrusion. This section describes how the exposure protocol
   responds 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, reachability and timeout events which happens
     about once can occur due to
   such errors. Appendix C contains an hour, while the public values are signed only when the
     values are refreshed, which happens about once per day. However, extended discussion on error
   checking and timestamp validation.

   A persistent NTP association is mobilized by an entry in
     client/server mode the protocol precludes server state variables on
     behalf of
   configuration file, while an individual client, so ephemeral association is mobilized upon
   the cookie must be computed,
     encrypted and signed for every cookie response. Ordinarily, cookie
     requests are seldom used, except when the server seed or public value
     signatures are refreshed. However, arrival of a determined intruder could replay
     cookie requests at high rate, which may very well clog the server. There
     appears no easy countermeasure for this particular attack. broadcast, manycast or symmetric active packet. A verify attack attempts
   general reset reinitializes all association variables to clog the receiver by provoking spurious
     signature verifications. The signature timestamp initial
   state when first mobilized. In addition, if the association is designed
   ephemeral, the association is demobilized and all resources acquired
   are returned to deflect
     replays of packets with old or duplicate extension fields before
     invoking expensive signature operations. A bogus signature with a
     timestamp in the future could do this, but system.

   Every NTP association has two variables which maintain the autokey sequence would
     detect this, since success would require cryptanalysis liveness
   state of both the
     server seed protocol, the 8-bit reachability register defined in
   [RFC-1305] and autokey seed.

     Since the Certificate response watchdog timer, which is signed, a middleman attack will not
     compromise new in NTPv4. At every
   poll interval the certificate data; however, a determined middleman could
     hammer reachability register is shifted left, the client with intentionally defective Certificate responses
     before a valid one could be received low
   order bit is dimmed and force spurious signature
     verifications, which of course would fail. An intruder could flood the
     server with Certificate request messages, but the Certificate response
     message high order bit is signed only once, so lost. At the result would be no worse than
     flooding same time
   the network with spurious packets.

     An interesting vulnerability in client/server mode watchdog counter is for incremented by one. If an intruder to
     replay a recent client arriving packet with an intentional
   passes all authentication and sanity checks, the rightmost bit error. This could
     cause of the server to return a crypto-NAK packet, which would then cause
   reachability register is lit and the client watchdog counter is set to request zero.
   If any bit in the cookie reachability register is lit, the server is
   reachable, otherwise it is unreachable.

   When the first poll is sent by an association, the reachability
   register and result in a sign attack on watchdog counter are zero. If the
     server. watchdog counter
   reaches 16 before the server becomes reachable, a general reset
   occurs. This results in resets the protocol and clears any acquired state before
   trying again. If the server was once reachable and client burning spurious machine
     cycles then becomes
   unreachable, a general reset occurs. In addition, if the watchdog
   counter reaches 16 and resulting in denial of service. As in other cases mentioned
     previously, the NTP timestamp check greatly association is persistent, the poll
   interval is doubled. This reduces the likelihood of network load for packets that
   are unlikely to elicit a
     successful attack.

     In broadcast and symmetric modes response.

   At each state in the protocol the client must include expects a particular
   response from the association
     ID server. A request is included 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
   sent at each poll interval until a valid association ID
     value. An intruder could save old server packets and replay them to the
     client population with response is received or a
   general reset occurs, in which case the hope that protocol restarts from the values will be accepted and
     cause
   beginning. A general chaos. The conservative client will discard them on the
     basis of invalid timestamp.

     As mentioned previously, reset also occurs for an intruder could pounce on association when an
   unrecoverable protocol error occurs. A general reset occurs for all
   associations when the initial volley
     between peers in symmetric mode before both peers have determined each
     other reachable. In this volley system clock is first synchronized or the peers clock
   is stepped or when the server seed is refreshed.

   There are vulnerable special cases designed to an intruder
     using fake timestamps. The result can be that quickly respond to broken
   associations, such as when a server restarts or refreshes keys. Since
   the peers never
     synchronize client cookie is invalidated, the timestamps and never completely mobilize their
     associations. A clever intruder might notice server rejects the interval between public
     value signatures next client
   request and concentrate attack on returns a crypto-NAK packet. Since the vulnerable intervals. An
     obvious countermeasure crypto-NAK has no
   MAC, the problem for the client is to randomize these intervals. A more
     comprehensive countermeasure remains determine whether it is
   legitimate or the result of intruder mischief. In order to be devised.

     Appendix A. Packet Formats
     The NTP Version 4 packet consists reduce the
   vulnerability in such cases, the crypto-NAK, as well as all
   responses, is believed only if the result of a number of fields made up of 32-
     bit (4 octet) words in network byte order. The previous packet consists of three
     components, sent
   by the header, one or more optional extension fields client and an
     optional message authenticator code (MAC), consisting of not a replay, as confirmed by the Key ID LBK and
     Message Digest fields. The format is shown below, where the size DUP
   status bits described above. While this defense can be easily
   circumvented by a middleman, it does deflect other kinds of some
     multiple word fields is shown in 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 (2)                    |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                   Originate Timestamp (2)                    |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                    Receive Timestamp (2)                     |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                    Transmit Timestamp (2)                    |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                                                               |
     =                      Extension Field(s)                       =
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Key ID                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                                                               |
     |                      Message Digest (4)                       |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     The NTP header extends from the beginning intruder
   warfare.

   There are a number of situations where some event happens that causes
   the packet to remaining autokeys on the end key list to become invalid. When one of
   these situations happens, the Transmit Timestamp field. The format key list and interpretation of associated autokeys in the
     header fields
   key cache are backwards compatible with purged. A new key list, signature and timestamp are
   generated when the next NTP Version 3 header
     fields as described in RFC-1305, except 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 slightly modified
     computation client switches from server mode to broadcast mode. There
   is no further need 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 (CBC) node. This algorithm and mode of operation
     is no longer supported in NTP Version 4. The preferred replacement in
     both NTP Version 3 and 4 is the Message Digest 5 (MD5) algorithm, which
     is included in key list, since the distribution. For MD5 client will not
   transmit again.

   3. When the Message Digest field poll interval is 4
     words (8 octets), but the Key ID field remains 1 word (4 octets).

     Extension Field Format changed. In NTP Version 4 one or more extension fields can be inserted after this case the
     NTP header and before calculated
   expiration times for the MAC, which keys become invalid.

   4. If a problem is always present detected when an extension
     field is present. The extension fields can occur in any order; however,
     in some cases there entry is a preferred order which improves fetched from the protocol
     efficiency. While previous versions of key
   list. This could happen if the Autokey protocol used several
     different extension field formats, in version 2 key was marked non-trusted or timed
   out, either of the protocol only a
     single extension field format is used.

     Each extension field contains which implies a request or response message in the
     following format:

                          1                   2                   3
      0 1 2 3 software bug.

10. References

   [RFC-1305] Mills, D.L., "Network Time Protocol (Version 3)
   Specification, Implementation and Analysis," RFC-1305, March 1992.

    [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision
   3", BCP 9, RFC 2026, October 1996.

   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

    [RFC-2402] Kent, S., R. Atkinson, "IP Authentication Header," RFC-
   2402, November 1998.

   [RFC-2406] Kent, S., and R. Atkinson, "IP Encapsulating Security
   Payload (ESP)," RFC-2406, November 1998.

   [RFC-2408] Maughan, D., M. Schertler, M. Schneider, and J. Turner,
   "Internet Security Association and Key Management Protocol (ISAKMP),"
   RFC-2408, November 1998.

   [RFC-2412] Orman, H., "The OAKLEY Key Determination Protocol," RFC-
   2412, November 1998.

   [RFC-2510] Adams, C., S. Farrell, "Internet X.509 Public Key
   Infrastructure Certificate Management Protocols," RFC-2510, March
   1999.

   [RFC-2522] Karn, P., and W. Simpson, "Photuris: Session-key
   Management Protocol", RFC-2522, March 1999.

   [RFC-2875] Prafullchandra, H., and J. Schaad, "Diffie-Hellman Proof-
   of-Possession Algorithms," RFC-2875, July 2000, 23 pp.

   [RFC-3279] Bassham, L., W. Polk and R. Housley, "Algorithms and
   Identifiers for the Internet X.509 Public Key Infrastructure
   Certificate and Certificate Revocation Lists (CRL) Profile," RFC-
   3279, April 2002.

   [RFC-3280] Housley, R., et al., "Internet X.509 Public Key
   Infrastructure Certificate and Certificate Revocation List (CRL)
   Profile," RFC-3280, April 2002.

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

   [MILLS96] 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.

   [STIMSON] Stimson, D.R. Cryptography - Theory and Practice. CRC
   Press, Boca Raton, FA, 1995, ISBN 0-8493-8521-0.

Appendix A. Packet Formats

   The NTPv4 packet consists of a number of fields made up of 32-bit (4
   octet) 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 header format is shown below, where
   the size of some multiple word fields is shown in 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |R|E|  Version
   |LI |     Code VN  |Mode |            Length    Stratum    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Poll      |                         Association ID   Precision   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                          Root Delay                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Filestamp                       Root Dispersion                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Value Length                         Reference ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                   Reference Timestamp (2)                    |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                   Originate Timestamp (2)                    |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
     =                             Value                             =
   |                    Receive Timestamp (2)                     |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Signature Length                                                               |
   |                    Transmit Timestamp (2)                    |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                           Signature                      Extension Field(s)                       =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Each extension field except the last is padded to a word (4 octets)
     boundary, while the last is padded to a doubleword (8 octets) boundary.
     The Length field covers the entire field length, including the Length
     field itself and padding. While the minimum field length is 8 octets, a
     maximum field length remains to be established. The reference
     implementation discards any packet with an extension field length over
     1024 octets.
   |                           Key ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                      Message Digest (4)                       |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The presence of the MAC and extension fields in the packet is determined NTP header extends from the length beginning of the remaining area after the header packet to the end of
   the
     packet. Transmit Timestamp field. The parser initializes a pointer just after the header. If the
     length is not a multiple of 4, a format error has occurred and interpretation of the
     packet is discarded. If the length is zero
   header fields are backwards compatible with the NTPv3 header fields
   as described in [RFC-1305].

   A non-authenticated NTP packet is not
     authenticated. If the length is 4 (1 word), includes only the packet is NTP header, while an error
     report or crypto-NAK resulting from
   authenticated one contains in addition a previous packet that failed the
     message digest check. MAC. The 4 octets are presently unused format and should be
     set to 0. If
   interpretation of the length NTPv4 MAC is 8 (2 words), 12 (3 words) or 16 (4 words), described in [RFC-1305] when using
   the packet Digital Encryption Standard (DES) algorithm operating in Cipher-
   Block Chaining (CBC) node. This algorithm and mode of operation is no
   longer supported in NTPv4. The preferred replacement in both NTPv3
   and NTPv4 is discarded with a format error. If the length Message Digest 5 (MD5) algorithm, which is greater
     than 20 (5 words), included
   in the reference implementation. For MD5 the Message Digest field is
   4 words (8 octets), but the Key ID field remains 1 word (4 octets).

A.1 Extension Field Format

   In NTPv4 one or more extension fields are present.

     If an extension field is present, the parser examines the length field.
     If can be inserted after the length is less than 4 or not a multiple of 4, a format error has
     occurred NTP
   header and before 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 MAC, which is always present and/or another when an extension field. An
     additional implementation-dependent test
   field is necessary to ensure the
     pointer does not stray outside the buffer space occupied by present. The extension fields can occur in any order;
   however, in some cases there is a preferred order which improves the packet.

     In
   protocol efficiency. While previous versions of the Autokey Version protocol
   used several different extension field formats, in version 2 format, of the Code
   protocol only a single extension field specifies the format is used.

   Each extension field contains a request or response operation, while message in the Version field is
   following format:

                        1                   2 identifying the current
     protocol version. There are two flag bits defined. Bit                   3
    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 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                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                             Value                             =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Signature Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                           Signature                           =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Padding                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Each extension field except the most common protocol operations, a client sends a request last is zero-padded to a
     server with an operation code specified in word (4
   octets) boundary, while the Code last is zero-padded to a doubleword (8
   octets) boundary. The Length field and covers the R bit
     set to 0. Ordinarily, entire extension field,
   including the client sets Length and Padding fields. While the E bit to 0 as well, but may in
     future set it to 1 for some purpose. The Association ID minimum field
   length is set 8 octets, a maximum field length remains to
     the value previously received from the server or 0 otherwise. be established.
   The server
     returns a response reference implementation discards any packet with a field length
   more than 1024 octets.

   The presence of the same operation code MAC and extension fields in the Code field and packet is
   determined from the R bit set length of the remaining area after the header to 1. The server can also set
   the E bit to 1 in case end of
     error. The Association ID field is set to the association ID sending the
     response as packet. The parser initializes a handle for subsequent exchanges. pointer just after
   the header. If for some reason the
     association ID value in a request does length is not match the association ID a multiple of
     any mobilized association, the server returns 4, a format error has
   occurred and the request with both packet is discarded. The following cases are
   possible based on the
     R and E bits set to 1. Note that, it remaining length in words.

   0  The packet is not a protocol error to send authenticated.
   4  The packet is 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 error report or crypto-NAK resulting from a proventic source, signatures are not valid. In
     such cases
   previous packet that failed the Timestamp and Signature Length fields message digest check. The 4 octets
   are 0 presently unused and should be set to 0.
   2, 3, 4  The packet is discarded with a format error.
   5  The remainder of the
     Signature field packet is empty. Some request and error response messages carry
     no value or signature fields, so in these messages only the first two
     words MAC.
   >5 One or more extension fields are present. The extension field parser verifies that the

   If an extension field length is at least 8 if no value field is expected and
     at least 24 if it is. The present, the parser also verifies that examines the sum of Length
   field. If the value
     and signature lengths length is equal to or less than the extension field
     length.

     The Timestamp 4 or not a multiple of 4, a format
   error has occurred and Filestamp words carry the seconds field of packet is discarded; otherwise, the NTP
     timestamp. parser
   increments the pointer by this value. The Timestamp field establishes parser now uses the signature epoch of 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
     data field in pointer does not stray outside the message, while buffer
   space occupied by the filestamp establishes packet.

   In the
     generation epoch of Autokey Version 2 format, the file that ultimately produced Code field specifies the data that was
     signed. Since a signature and timestamp request
   or response operation, while the Version field is 2 for the current
   protocol version. There are valid only when two flag bits defined. Bit 0 is the signing
     host
   response flag (R) and bit 1 is synchronized 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 proventic source and client sends a cryptographic data file
     can only be generated if request to a signature is possible, the filestamp is
     always nonzero, except
   server with an operation code specified in the Association Response message, where it
     contains Code field and lights
   the server status word.

     Autokey Version 2 Messages

     Association Message R bit. Ordinarily, the client dims the E bit as well, but may in
   future light it for some purpose. The Association message ID field is used set to obtain the host name and related
     values. The 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|0|     1     |       1       |              8                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | value previously received from the server or 0                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ otherwise. The
   server returns a response message has with 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               0                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Public Value Timestamp                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Status Word                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Host Name Length                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                                                               |
     =                           Host Name                           =
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               0                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     This same operation code in the Code
   field and the R bit lit. The server can also light E bit in case of
   error. The Association ID field is set to the association ID sending
   the only response that is accepted if as a handle for subsequent exchanges. If for some reason
   the association status
     word is zero; otherwise, it is ignored. As this is ID value in a request does not match the association
   ID of any mobilized association, the server returns the first request
     sent and with
   both the response R and E bits lit. Note that it is not from a protocol error to
   send an association, the Association ID unsolicited response with no matching request.

   In some cases not all fields are 0. The Host Name field contains may be present. For requests, until a
   client has synchronized to a proventic source, signatures are not
   valid. In such cases the unterminated string
     returned by Timestamp and Signature Length fields are 0
   and the Unix gethostname() library function. The Status Word Signature field is
     defined empty. Responses are generated only when
   the responder has synchronized to a proventic source; otherwise, an
   error response message is sent. Some request and error response
   messages carry no value or signature fields, so in previously these messages
   only the first two words are present.

   The Timestamp and Filestamp words carry the seconds field of an NTP
   timestamp. The Timestamp field establishes the signature epoch of the
   data field in this memorandum. While minimum the message, while the filestamp establishes the
   generation epoch of the file that ultimately produced the data that
   is signed. Since a signature and maximum timestamp are valid only when the
   signing host
     name lengths remain is synchronized to a proventic source and a
   cryptographic data file can only be established, generated if a signature is
   possible, the reference implementation uses response filestamp is always nonzero, except in the values 4 and 256, respectively.

     Certificate
   Association response message, where it contains the server status
   word.

A.2 Autokey Version 2 Messages

   Following is a list of the messages used by the protocol.

   A.2.1 Association Message (ASSOC)

   The Certificate Association message is used to obtain the certificate host name and related
   values. The request message has and response are unsigned and 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|     2
   |1|E|     1     |       2       1       |              8            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Association ID                               0                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     The response message has the following format:

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1
   |                    Public Values Timestamp                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Host Status Word                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Host Name Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                           Host Name                           =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Host Name field contains the unterminated string returned by the
   Unix gethostname() library function. While minimum and maximum host
   name lengths remain to be established, the reference implementation
   uses the values 4 and 256, respectively. The remaining fields are
   defined previously in this document.

   A.2.2. Certificate Message (CERT)

   The Certificate message is used to obtain a certificate and related
   values by subject name. The unsigned request 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|
   |0|0|     2     |       2       |            Length              8                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Association ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Public Values Timestamp                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Certificate Filestamp                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Certificate Length                          Current Time                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
     |                                                               |
     =                          Certificate                          =
     |                                                               |
     |                    Public Values Timestamp                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Certificate Signature                       Subject Name Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                     Certificate Signature                          Subject Name                          =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     The response is accepted only if the association status word is nonzero,
     AUT = 0 and LBK = 1. The certificate is encoded in X.509 format using
     ASN.1 syntax. If the certificate has expired or for some reason is no
     longer available,
   For the response includes purposes of interoperability with older Autokey versions, if
   only the first two words with
     the E bit set. The remaining fields are defined previously in this
     memorandum.

     Cookie Message

     The Cookie sent, the request is used in client/server and symmetric modes to obtain for the
     server cookie. host
   certificate. The request message response 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|0|     3
   |1|E|     2     |       3       2       |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Association ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Public Values Timestamp                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Certificate Filestamp                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Public Key                       Certificate Length                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                            Public Key                          Certificate                          =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Public Key                  Certificate Signature Length                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                       Public Key                     Certificate Signature                     =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The request certificate is accepted only if AUT = 1, CKY = 0 and LBK = 1. The Public
     Key field contains the server public key values to be used for cookie
     encryption. The values are encoded in X.509 format with ASN.1 format. syntax as
   described in Appendix G. The remaining fields are defined previously
   in this memorandum. document.

   A.2.3 Cookie Message (COOKIE)

   The response Cookie message is used in server and symmetric modes to obtain
   the server cookie. The request 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|
   |0|0|     3     |       3       |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Association ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Cookie                    Public Values Timestamp                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Certificate                      Host Key Filestamp                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Encrypted Cookie                       Public Key Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                        Encrypted Cookie                            Public Key                         =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Cookie                   Public Key Signature Length                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                        Cookie                       Public Key Signature                    =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The 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 Public Key field contains the encrypted cookie value according to the public key provided in the
     request. If CKY = 0, the decrypted cookie is used directly. If CKY = 1,
     the decrypted cookie is exclusive-ORed with the existing cookie. If an
     error occurs when decoding the host public key or encrypting the cookie, the
     response includes only the first two words encoded with the E bit set. ASN.1
   syntax as described in Appendix G. The remaining fields are defined
   previously in this memorandum.

     Autokey Message

     The Autokey message is used to obtain the autokey values. The 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|0|     2     |       4       |              8                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Association ID                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ document.

   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|     4     3     |       4       3       |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Association ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Autokey                        Cookie Timestamp                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Certificate Filestamp                      Public Key Timestamp                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               8                    Encrypted Cookie Length                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Key ID                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                                               |                          Key Number
   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                                               |                    Autokey
   =                        Encrypted Cookie                       =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Cookie Signature Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                        Cookie Signature                       =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Encrypted Cookie field contains the raw cookie value encrypted by
   the public key in the request. The Cookie Signature and Timestamp are
   determined when the response is sent. The Public Key Timestamp is
   copied from the request. The remaining fields are defined previously
   in this document.

   A.2.4 Autokey Message (AUTO)

   The Autokey message is used to obtain the autokey values. The 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |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|     4     |       4       |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Association ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Autokey Timestamp                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Public Values Timestamp                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               8                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Key ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Key Number                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Autokey Signature Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                       Autokey Signature                       =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The response Autokey Signature and Timestamp are determined when the key list
   is generated. The remaining fields are defined previously in this
   document.

   A.2.5 Leapseconds Table Message (LEAP)

   The Leapseconds Table message is used to exchange leapseconds tables.
   The request and response messages have the following format, except
   that the R bit is dim in the request and lit 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|E|     2     |       5       |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Association ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Public Values Timestamp                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Leapseconds Filestamp                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Leapseconds Table Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                        Leapseconds Table                      =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Leapseconds Signature Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                      Leapseconds Signature                    =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Leapseconds Table field contains the leapseconds table as parsed
   from the leapseconds file from NIST. If the client already has a copy
   of the leapseconds data, it uses the one with the latest filestamp
   and discards the other. The remaining fields are defined previously
   in this document.

   A.2.6 Sign Message (SIGN)
   The Sign message requests the server to sign and return a certificate
   presented in the request. The request and response messages have the
   following format, except that the R bit is dim in the request and lit
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|E|     2     |       6       |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Association ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Public Values Timestamp                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Certificate Filestamp                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Certificate Length                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                          Certificate                          =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Certificate Signature Length                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                     Certificate Signature                     =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The certificate is in X.509 format encoded in ASN.1 syntax as
   described in Appendix G. The remaining fields are defined previously
   in this document.

   A.2.7 Identity Messages (IFF, GQ)

   The Identity request asks the server to perform a mathematical
   operation on the challenge and return the results in the response.
   The request message has the following format, where 7 is the IFF
   scheme and 8 is the GQ shseme:

                        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|     2     |      7/8      |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Association ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Challenge Timestamp                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Public Values Timestamp                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Challenge Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                      Challenge (512 bits)                     =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Challenge Signature Length                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                       Challenge Signature                     =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Challenge is a raw 512-bit nonce. The remaining fields are
   defined previously in this document.

   The Identity response contains the result of the mathematical
   operation and is in two parts, the results and a message digest. The
   response message has the following format, where 7 is the IFF scheme
   and 8 is for the GQ shseme:

                        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|     2     |      7/8      |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Association ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Response Timestamp                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Public Values Timestamp                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Response Length                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                            Response                           =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Resonse Signature Length                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   =                        Response Signature                     =
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Response is encoded in ASN.1 syntax as described in Appendix G.
   The Response Signature and Timestamp are determined when the response
   is sent. The Parameters Filestamp is copied from the request.

Appendix B. Cryptographic Key and Certificate Management

   This appendix describes how cryptographic keys and certificates are
   generated and managed in the NTPv4 reference implementation. These
   means are not intended to become part of any standard that may be
   evolved from this document, but to serve as an example of how these
   functions can be implemented and managed in a typical operational
   environment.

   The ntp-keygen utility program in the NTP software library generates
   public/private key files, certificate files, identity parameter files
   and public/private identity key files. By default the modulus of all
   encryption and identity keys is 512 bits. All random cryptographic
   data are based on a 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.

   Every file has a filestamp, which is a string of decimal digits
   representing the NTP seconds the file was created. The file name is
   formed from the concatenation of the host name, filestamp and
   constant strings, so files can be copied from one environment to
   another while preserving the original filestamp. The file header
   includes the file name and date and generation time in printable
   ASCII. The utility assumes the host is synchronized to a proventic
   source at the time of generation, so that filestamps are proventic
   data. This raises an interesting circularity issue that will not be
   further explored here.

   The generated files are typically stored in NFS mounted file systems,
   with files containing private keys obscured to all but root. Symbolic
   links are installed from default file names assumed by the NTP daemon
   to the selected files. Since the files of successive generations and
   different hosts have unique names, there is no possibility of name
   collisions.

   Public/private keys must be generated by the host to which they
   belong. OpenSSL public/private RSA and DSA keys are generated as an
   OpenSSL structure, which is then PEM encoded in ASN.1 syntax and
   written to the host key file. The host key must be RSA, since it is
   used to encrypt the cookie, as well as encrypt signatures by default.
   In principle, these files could be generated directly by OpenSSL
   utility programs, as long as the symbolic links are consistent. The
   optional sign key can be RSA or DSA, since it is used only to encrypt
   signatures.

   Identity parameters must be generated by the ntp-keygen utility,
   since they have proprietary formats. Since these are private to the
   group, they are generated by one machine acting as a trusted
   authority and then distributed to all other members of the group by
   secure means. Public/private identity keys are generated by the host
   to which they belong along with certificates with the public identity
   key.

   Certificates are usually, but not necessarily, generated by the host
   to which they belong. The ntp-keygen utility generates self-signed
   X.509v3 host certificate files with optional extension fields.
   Certificate requests are not used, since the certificate itself is
   used as a request to be signed. OpenSSL X.509v3 certificates are
   generated as an OpenSSL structure, which is then PEM encoded in ASN.1
   syntax and written to the host certificate file. The string returned
   by the Unix gethostname() routine is used for both the subject and
   issuer fields. The serial number and begin time fields are derived
   from the filestamp; the end time is one year hence. The host
   certificate is signed by the sign key or host key by default.

   An important design goal is to make cryptographic data refreshment as
   simple and intuitive as possible, so it can be driven by scripts on a
   periodic basis. When the ntp-keygen utility is run for the first
   time, it creates by default a RSA host key file and RSA-MD5 host
   certificate file and necessary symbolic links. After that, it creates
   a new certificate file and symbolic link using the existing host key.
   The program run with given options creates identity parameter files
   for one or both the IFF or GQ identity schemes. The parameter files
   must then be securely copied to all other group members and symbolic
   links installed from the default names to the installed files. In the
   GQ scheme the next and each subsequent time the ntp-keygen utility
   runs, it automatically creates or updates the private/public identity
   key file and certificate file using the existing identity parameters.

Appendix C. Autokey Error Checking

   Exhaustive examination of possible vulnerabilities at the various
   processing steps of the NTPv3 protocol as specified in [RFC-1305]
   have resulted in a revised list of packet sanity tests. There are 12
   tests in the NTPv4 reference implementation, called TEST1 through
   TEST12, which are performed in a specific order designed to gain
   maximum diagnostic information while protecting against an accidental
   or malicious clogging attacks. These tests are described in detail in
   the NTP software documentation. Those relevant to the Autokey
   protocol are described in this appendix.

   The sanity tests are classified in four tiers. The first tier
   deflects access control and message digest violations. The second,
   represented by the autokey sequence, deflects spoofed or replayed
   packets. The third, represented by timestamped digital signatures,
   binds cryptographic values to verifiable credentials. The fourth
   deflects packets with invalid NTP header fields or out of bounds time
   values. However, the tests in this last group do not directly affect
   cryptographic protocol vulnerability, so are beyond the scope of
   discussion here.

C.1 Packet Processing Rules

   Every arriving NTP packet is checked enthusiastically for format,
   content and protocol errors. Some packet header fields are checked by
   the main NTP code path both before and after the Autokey protocol
   engine cranks. These include the NTP version number, overall packet
   length and extension field lengths. Extension fields may be no longer
   than 1024 octets in the reference implementation. Packets failing any
   of these checks are discarded immediately. Packets denied by the
   access control mechanism will be discarded later, but processing
   continues temporarily in order to gather further information useful
   for error recovery and reporting.

   Next, the cookie and session key are determined and the MAC computed
   as described above. If the MAC fails to match the value included in
   the packet, the action depends on the mode and the type of packet.
   Packets failing the MAC check will be discarded later, but processing
   continues temporarily in order to gather further information useful
   for error recovery and reporting.

   The NTP transmit and receive timestamps are in effect nonces, since
   an intruder cannot effectively guess either value in advance. To
   minimize the possibility that an intruder can guess the nonces, the
   low order unused bits in all timestamps are obscured with random
   values. If the transmit timestamp matches the transmit timestamp in
   the last packet received, the packet is a duplicate, so the DUP bit
   is lit. If the packet mode is not broadcast and the last transmit
   timestamp does not match the originate timestamp in the packet,
   either it was delivered out of order or an intruder has injected a
   rogue packet, so the LBK bit is lit. Packets with either the DUP or
   LBK bit lie be discarded later, but processing continues temporarily
   in order to gather further information useful for error recovery and
   reporting.

   Further indicators of the server and client state are apparent from
   the transmit and receive timestamps of both the packet and the
   association. The quite intricate rules take into account these and
   the above error indicators They are designed to discriminate between
   legitimate cases where the server or client are in inconsistent
   states and recoverable, and when an intruder is trying to destabilize
   the protocol or force consumption of needless resources. The exact
   behavior is beyond the scope of discussion, but is clearly described
   in the source code documentation.

   Next, the Autokey protocol engine is cranked and the dances evolve as
   described above. Some requests and all responses have value fields
   which carry timestamps and filestamps. When the server or client is
   synchronized to a proventic source, most requests and responses with
   value fields carry signatures with valid timestamps. When not
   synchronized to a proventic source, value fields carry an invalid
   (zero) timestamp and the signature field and signature length word
   are omitted.

   The extension field parser checks that the Autokey version number,
   operation code and field length are valid. If the error bit is lit in
   a request, the request is discarded without response; if an error is
   discovered in processing the request, or if the responder is not
   synchronized to a proventic source, the response contains only the
   first two words of the request with the response and error bits lit.
   For messages with signatures, the parser requires that timestamps and
   filestampes are valid and not a replay, that the signature length
   matches the certificate public key length and only then verifies the
   signature. Errors are reported via the security logging facility.

   All certificates must have correct ASN.1 encoding, supported
   digest/signature scheme and valid subject, issuer, public key and,
   for self-signed certificates, valid signature. While the begin and
   end times can be checked relative to the filestamp and each other,
   whether the certificate is valid relative to the actual time cannot
   be determined until the client is synchronized to a proventic source
   and the certificate is signed and verified by the server.

   When the protocol starts the only response accepted is ASSOC with
   valid timestamp, after which the server status word must be nonzero.
   ASSOC responses are discarded if this word is nonzero. The only
   responses accepted after that and until the PRV bit is lit are CERT,
   IFF and GQ. Once identity is confirmed and IFF is lit, these
   responses are no longer accepted, but all other responses are
   accepted only if in response to a previously sent request and only in
   the order prescribed in the protocol dances. Additional checks are
   implemented for each request type and dance step.

C.2 Timestamps, Filestamps and Partial Ordering

   When the host starts, it reads the host key and certificate files,
   which are required for continued operation. It also reads the sign
   key and leapseconds files, when available. When reading these files
   the host checks the file formats and filestamps for validity; for
   instance, all filestamps must be later than the time the UTC
   timescale was established in 1972 and the certificate filestamp must
   not be earlier than its associated sign key filestamp. In general, at
   the time the files are read, the host is not synchronized, so it
   cannot determine whether the filestamps are bogus other than these
   simple checks.

   In the following the relation A->B is Lamport's "happens before"
   relation, which is true if event A happens before event B. When
   timestamps are compared to timestamps, the relation is false if A ==
   B; that is, false if the events are simultaneous. For timestamps
   compared to filestamps and filestamps compared to filestamps, the
   relation is true if A == B. Note that the current time plays no part
   in these assertions except in (6) below; however, the NTP protocol
   itself insures a correct partial ordering for all current time
   values.

   The following assertions apply to all relevant responses:

   1. The client saves the most recent timestamp T0 and filestamp F0 for
   the respective signature type. For every received message carrying
   timestamp T1 and filestamp F1, the message is discarded unless T0->T1
   and F0->F1. The requirement that T0->T1 is the primary defense
   against replays of old messages.

   2. For timestamp T and filestamp F, F->T; that is, the timestamp must
   not be earlier than the filestamp. This could be due to a file
   generation error or a significant error in the system clock time.

   3. For sign key filestamp S, certificate filestamp C, cookie
   timestamp D and autokey timestamp A, S->C->D->A; that is, the autokey
   must be generated after the cookie, the cookie after the certificate
   and the certificate after the sign key.

   4. For sign key filestamp S and certificate filestamp C specifying
   begin time B and end time E, S->C->B->E; that is, the valid period
   must not be retroactive.

   5. A certificate for subject S signed by issuer I and with filestamp
   C1 obsoletes, but does not necessarily invalidate, another
   certificate with the same subject and issuer but with filestamp C0,
   where C0->C1.

   6. A certificate with begin time B and end time E is invalid and can
   not be used to sign certificates if t->B or E->t, where t is the
   current time. Note that the public key previously extracted from the
   certificate continues to be valid for an indefinite time. This raises
   the 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.

Appendix D. Security Analysis

   This section discusses the most obvious security vulnerabilities in
   the various Autokey dances. First, some observations on the
   particular engineering parameters of the Autokey protocol are in
   order. The number of bits in some cryptographic values are
   considerably smaller than would ordinarily be expected for strong
   cryptography. One of the reasons for this is the need for
   compatibility with previous NTP versions; another is the need for
   small and constant latencies and minimal processing requirements.
   Therefore, what the scheme gives up on the strength of these values
   must be regained by agility in the rate of change of the
   cryptographic basis values. Thus, autokeys are used only once and
   seed values are regenerated frequently. However, in most cases even a
   successful cryptanalysis of these values compromises only a
   particular association and does not represent a danger to the general
   population.

   Throughout the following discussion the cryptographic algorithms and
   private values themselves are assumed secure; that is, a brute force
   cryptanalytic attack will not reveal the host private key, sign
   private key, cookie value, identity parameters, server seed or
   autokey seed. In addition, an intruder will not be able to predict
   random generator values or predict the next autokey. On the other
   hand, the intruder can remember the totality of all past values for
   all packets ever sent.

D.1 Protocol Vulnerability

   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 watchdog counter and general reset insure
   that the association variables will eventually be purged and the
   protocol restarted from the beginning. However, if something is
   seriously wrong, the timeout/restart cycle could continue
   indefinitely until whatever is wrong is fixed. This is not a clogging
   hazard, as the timeout period is very long compared to expected
   network delays.

   The LBK and DUP bits described in the main body and Appendix C are
   effective whether or not cryptographic means are in use. The DUP bit
   deflects duplicate packets in any mode, while the LBK bit deflects
   bogus packets in all except broadcast mode. All packets must have the
   correct MAC, as verified with correct key ID and cookie. In all modes
   the next key ID cannot be predicted by a wiretapper, so are of no use
   for cryptanalysis.

   As long as the client has validated the server certificate trail, a
   wiretapper cannot produce a convincing signature and cannot produce
   cryptographic values acceptable to the client. As long as the
   identity values are not compromised, a middleman cannot masquerade as
   a legitimate group member and produce convincing certificates or
   signatures. In server and symmetric modes after the preliminary
   exchanges have concluded, extension fields are no longer used, a
   client validates the packet using the autokey sequence. A wiretapper
   cannot predict the next Key IDs, so cannot produce a valid MAC. A
   middleman cannot successfully modify and replay a message, since he
   does not know the cookie and without the cookie cannot produce a
   valid MAC.

   In broadcast mode a wiretapper cannot produce a key list with signed
   autokey values that a client will accept. The most it can do is
   replay an old packet causing clients to repeat the autokey hash
   operations until exceeding the maximum key number. However, a
   middleman could intercept an otherwise valid broadcast packet and
   produce a bogus packet with acceptable MAC, since in this case it
   knows the key ID before the clients do. Of course, the middleman key
   list would eventually be used up and clients would discover the ruse
   when verifying the signature of the autokey values. There does not
   seem to be a suitable defense against this attack.

   During the exchanges where extension fields are in use, the cookie is
   a public value rather than a shared secret and an intruder can easily
   construct a packet with a valid MAC, but not a valid signature. In
   the certificate and identity exchanges an intruder can generate fake
   request messages which may evade server detection; however, the LBK
   and DUP bits minimize the client exposure to the resulting rogue
   responses. A wiretapper might be able to intercept a request,
   manufacture a fake response and loft it swiftly to the client before
   the real server response. A middleman could do this without even
   being swift. However, once the identity exchange has completed and
   the PRV bit lit, these attacks are readily deflected.

   A client instantiates cryptographic variables only if the server is
   synchronized to a proventic source. A server does not sign values or
   generate cryptographic data files unless synchronized to a proventic
   source. This raises an interesting issue: how does a client generate
   proventic cryptographic 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 shave himself?] In principle, this
   paradox is resolved by assuming the primary (stratum 1) servers are
   proventicated by external phenomological means.

D.2 Clogging Vulnerability

   There are two clogging vulnerabilities exposed in the protocol
   design: a encryption attack where the intruder hopes to clog the
   victim server with needless cookie or signature encryptions or
   identity calculations, and a decryption attack where the intruder
   attempts to clog the victim client with needless cookie or
   verification decryptions. Autokey uses public key cryptography and
   the algorithms that perform these functions consume significant
   processor resources.

   In order to reduce exposure to decryption attacks the LBK and DUP
   bits deflect bogus and replayed packets before invoking any
   cryptographic operations. In order to reduce exposure to encryption
   attacks, 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 one of them changes or the server seed is
   refreshed, which happens about once per day.

   In some Autokey dances the protocol precludes server state variables
   on behalf of an individual client, so a request message must be
   processed and the response message sent without delay. The identity,
   cookie and sign exchanges are particularly vulnerable to a clogging
   attack, since these exchanges can involve expensive cryptographic
   algorithms as well as digital signatures. A determined intruder could
   replay identity, cookie or sign requests at high rate, which may very
   well be a useful munition for an encryption attack. Ordinarily, these
   requests are seldom used, except when the protocol is restarted or
   the server seed or public values are refreshed.

   Once synchronized to a proventic source, a legitimate extension field
   with timestamp the same as or earlier than the most recent received
   of that type is immediately discarded. This foils a middleman cut-
   and-paste attack using an earlier AUTO response, for example. A
   legitimate extension field with timestamp in the future is unlikely,
   as that would require predicting the autokey sequence. In either case
   the extension field is discarded before expensive signature
   computations. This defense is most useful in symmetric mode, but a
   useful redundancy in other modes.

   The client is vulnerable to a certificate clogging attack until
   declared proventic, after which CERT responses are discarded. Before
   that, a determined intruder could flood the client with bogus
   certificate responses and force spurious signature verifications,
   which of course would fail. The intruder could flood the server with
   bogus certificate requests and cause similar mischief. Once declared
   proventic, further certificate responses are discard, so these
   attacks would fail. The intruder could flood the server with replayed
   sign requests and cause the server to verify the request and sign the
   response, although the client would drop the response due invalid
   timestamp.

   An interesting adventure is when an intruder replays a recent packet
   with an intentional bit error. A stateless server will return a
   crypto-NAK message which the client will notice and discard, since
   the LBK bit is lit. However, a legitimate crypto-NAK is sent if the
   server has just refreshed the server seed. In this case the LBK bit
   is dim and the client performs a general reset and restarts the
   protocol as expected. Another adventure is to replay broadcast mode
   packets at high rate. These will be rejected by the clients by the
   timestamp check and before consuming signature cycles.

   In broadcast and symmetric modes the client must include the
   association ID in the AUTO request. Since association ID values for
   different invocations of the NTP daemon are randomized over the 16-
   bit space, it is unlikely that a bogus request would match a valid
   association with different IP addresses, for example, and cause
   confusion.

Appendix E. Identity Schemes

   The Internet infrastructure model described in [RFC-2510] is based on
   certificate trails where a subject proves identity to a certificate
   authority (CA) who then signs the subject certificate using the CA
   issuer key. The CA in turn proves identity to the next CA and obtains
   its own signed certificate. The trail continues to a CA with a self-
   signed trusted root certificate independently validated by other
   means. If it is possible to prove identity at each step, each
   certificate along the trail can be considered trusted relative to the
   identity scheme and trusted root certificate.

   The import issue with respect to NTP and ad hoc sensor networks is
   the cryptographic strength of the identity scheme, since if a
   middleman could compromise it, the trail would have a security
   breach. In electric mail and commerce the identity scheme can be
   based on handwritten signatures, photographs, fingerprints and other
   things very hard to counterfeit. As applied to NTP subnets and
   identity proofs, the scheme must allow a client to securely verify
   that a server knows the same secret that it does, presuming the
   secret was previously instantiated by secure means, but without
   revealing the secret to members outside the group.

   The Autokey Version 2 reference implementation supports four identity
   schemes of varying cryptographic strengths: one using private
   certificates (PC), a second using trusted certificates (TC), a third
   using a modified Schnorr (IFF aka Identify Friend or Foe) algorithm,
   and the fourth using a modified Guillou-Quisquater (GQ) algorithm.
   The available schemes are selected during the key generation phase,
   with the particular scheme selected during the parameter exchange.

   The IFF and GQ schemes involve a cryptographically strong challenge-
   response exchange. These schemes begin when the client sends a nonce
   to the server, which then rolls its own nonce, performs a
   mathematical operation and sends the results along with a message
   digest to the client. The client performs a second mathematical
   operation to produce a digest that must match the one included in the
   message. Still another scheme based on a modified Diffie-Hellman
   agreement algorithm described in [RFC-2875], was considered, but the
   computation resources required are considerably more than the IFF and
   GQ schemes.

   Certificate extension fields are used to convey information used by
   the identity schemes, such as whether the certificate is private,
   trusted or contains a public identity key. While the semantics of
   these fields generally conforms with conventional usage, there are
   subtle variations. The fields used by Autokey Version 2 include:

   Basic Constraints
   This field defines the basic functions of the certificate. It
   contains the string "critical,CA:TRUE", which means the field must be
   interpreted and the associated private key can be used to sign other
   certificates. While included for compatibility, Autokey makes no use
   of this field.

   Key Usage
   This field defines the intended use of the public key contained in
   the certificate. It contains the string
   "digitalSignature,keyCertSign", which means the contained public key
   can be used to verify signatures on data and other certificates.
   While included for compatibility, Autokey makes no use of this field.

   Extended Key Usage
   This field further refines the intended use of the public key
   contained in the certificate and is present only in self-signed
   certificates. It contains the string "Private" if the certificate is
   designated private or the string "trustRoot" if it is designated
   trusted. A private certificate is always trusted.

   Subject Key Identifier:
   This field contains the public identity key used in the GQ identity
   scheme. It is present only if the GQ scheme is configured.

   Certificates are used to construct certificate information structures
   (CIS) which are stored on the certificate list. A flags field in the
   CIS determines the status of the certificate. The field is encoded as
   follows:

   Sign 0x01
   The certificate signature has been verified. If the certificate is
   self-signed and verified using the contained public key, this bit
   will be lit when the CIS is constructed.

   Trust 0x02
   The certificate has been signed by a trusted issuer. If the
   certificate is self-signed and contains "trustRoot" in the Extended
   Key Usage field, this bit will be lit when the CIS is constructed.

   Private 0x04
   The certificate is private and not to be revealed. If the certificate
   is self-signed and contains "Private" in the Extended Key Usage
   field, this bit will be lit when the CIS is constructed.

   Error 0x80
   The certificate is defective and not to be used in any way.

   These flags can also be set by the identity schemes described below.

E.1 Private Certificate (PC) Scheme

   The PC scheme uses a private certificate as group key. A certificate
   is designated private for the purpose of the this scheme if the CIS
   Private bit is lit. The certificate is distributed to all other group
   members by secret means and never revealed outside the group. There
   is no identity exchange, since the certificate itself is the group
   key. Therefore, when the parameter exchange completes the VAL, IFF
   and SGN bits are lit in the server status word. When the following
   cookie exchange is complete, the PRV bit is lit and operation
   continues as described in the main body of this document.

E.2 Trusted Certificate (TC) Scheme

   The TC identification exchange follows the parameter exchange in
   which the VAL bit is lit. It involves a conventional certificate
   trail and a sequence of certificates, each signed by an issuer one
   stratum level lower than the client, and terminating at a trusted
   certificate, as described in [RFC-2510]. A certificate is designated
   trusted for the purpose of the TC scheme if the CIS Trust bit is lit
   and the certificate is self-signed. Such would normally be the case
   when the trail ends at a primary (stratum 1) server, but the trail
   can end at a secondary server if the security model permits this.

   When a certificate is obtained from a server, or when a certificate
   is signed by a server, A CIS for the new certificate is pushed on the
   certificate list, but only if the certificate filestamp is greater
   than any with the same subject name and issuer name already on the
   list. The list is then scanned looking for signature opportunities.
   If a CIS issuer name matches the subject name of another CIS and the
   issuer certificate is verified using the public key of the subject
   certificate, the Sign bit is lit in the issuer CIS. Furthermore, if
   the Trust bit is lit in the subject CIS, the Trust bit is lit in the
   issuer CIS.

   The client continues to follow the certificate trail to a self-signed
   certificate, lighting the Sign and Trust bits as it proceeds. If it
   finds a self-signed certificate with Trust bit lit, the client lights
   the IFF and PRV bits and the exchange completes. It can, however,
   happen that the client finds a self-signed certificate with Trust bit
   dark. This can happen when a server is just coming up, has
   synchronized to a proventic source, but has not yet completed the
   sign exchange. This is considered a temporary condition, so the
   client simply retries at poll opportunities until the server
   certificate is signed.

E.3 Schnorr (IFF) Scheme
   The Schnorr (IFF) identity scheme is useful when certificates are
   generated by means other than the NTP software library, such as a
   trusted public authority. In this case a X.509v3 extension field
   might not be available to convey the identity public key. The scheme
   involves a set of parameters which persist for the life of the
   scheme. New generations of these parameters must be securely
   transmitted to all members of the group before use. The scheme is accepted only if AUT = 1
   self contained and KEY = 0 in the association
     status word; otherwise, it is ignored. independent of new generations of host keys, sign
   keys and certificates.

   The Autokey Timestamp, Key ID,
     Key Number IFF identity scheme is based on DSA cryptography and Autokey Signature fields algorithms
   adapted from Stimson p. 285 [STIMSON]. The IFF parameters are determined when the most
     recent key list was generated. If a key list has not been
   generated or
     the association ID matches no mobilized association, by OpenSSL routines normally used to generate DSA
   parameters. By happy coincidence, the response
     includes mathematical principles on
   which IFF is based are similar to DSA, but only the first two words with the E bit set. The remaining
     fields prime p,
   generator g and prime q are defined previously used in this memorandum.

     Leapseconds Table Message identity calculations. The Leapseconds Table message p is used to exchange leapseconds tables.
     The request a
   512-bit prime and response messages have the following format, except q a 160-bit prime 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 divides p - 1 2 3 4 5 6 7 8 9 0 and is a qth
   root of 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|0|     2     |       5       |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Association ID                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Public Values Timestamp                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Leapseconds Filestamp                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Leapseconds Table Length                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                                                               |
     =                        Leapseconds Table                      =
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Leapseconds Signature Length                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                                                               |
     =                      Leapseconds Signature mod p; that is, g^q =
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 mod p. The response is accepted trusted authority rolls
   random group key a, computes public identity key v = g^(q - a) and
   shares (p, g, q, a, v) with the group members. These values are never
   revealed, although only if AUT a need be truly secret.

   Alice challenges Bob to confirm identity using the following
   exchange. Alice rolls new random challenge r and sends to Bob in the
   IFF request message. Bob rolls new random k, then computes y = 1 k + a
   r mod q and LPT x = 0 g^k mod p and sends (y, hash(x)) to Alice in the association
     status word; otherwise, IFF
   response message. Besides making the response shorter, the hash makes
   it is ignored. The Leapseconds Table field
     contains effectively impossible for an intruder to solve for k and the leapseconds table as parsed from
   unpredictable nonces make it effectively impossible to solve for a by
   monitoring multiple request and response message.

   Alice receives the leapseconds file
     available from NIST. In client/server mode response and computes g^y v^r mod p. After a bit
   of modular algebra, this simplifies to g^k. If hash(g^k) matches x,
   Alice knows that Bob has the client requests group key a. The signed response binds
   this knowledge to Bob's private key and the table
     from public key previously
   received in his certificate. On success the IFF and PRV bits are lit
   in the server status word.

E.4 Guillard-Quisquater (GQ) Scheme

   The Guillou-Quisquater (GQ) identity scheme is useful when
   certificates are generated using the LPF bit is set NTP software library. These
   routines convey the GQ public key in a X.509v3 extension field. The
   scheme involves a set of parameters which persist for the host status word. If life of the
     client already has
   scheme and a copy, it uses private/public identity key, which is refreshed each
   time a new certificate is generated. The scheme is self contained and
   independent of new generations of host keys and sign keys and
   certificates.

   The GQ identity scheme is based on RSA cryptography and algorithms
   adapted from Stimson p. 300 [STIMSON] (with errors corrected). The GQ
   parameters are generated by OpenSSL routines normally used to
   generate RSA keys. By happy coincidence, the one mathematical principles
   on which GQ is based are similar to RSA, but only the modulus n is
   used in identity calculations. The 512-bit public modulus is n = p q,
   where p and q are secret large primes, but not used in identity
   calculations. The trusted authority rolls random group key b and
   shares (n, b) with the latest filestamp. In
     symmetric modes the peers exchange tables group members. These values are never
   revealed, although only b need be truly secret.

   When generating a new certificate, group members roll a random nonce
   u and both use the one with compute its inverse v = (u^-1)^b obscured by the
     latest filestamp. If group key b.
   Thus, each has a private identity key u and a public identity key v,
   but not necessarily the leapseconds table same ones. The public key is requested but unavailable, conveyed on the response includes only
   certificate in an extension field; the first two words with private key is never revealed.

   Alice challenges Bob to confirm identity using the E bit set. The
     remaining fields are defined previously in this memorandum.

     Appendix B. Key Generation following
   exchange. Alice rolls new random challenge r and Management

     The ntp-genkeys utility program sends to Bob in the NTP software distribution
     generates public/private key, certificate
   GQ request message. Bob rolls new random k, then computes y = k u^r
   mod n and certificate files.
     A set of files is generated for every message digest x = k^b mod n and signature
     encryption scheme supported by the OpenSSL software library. All files
     are based on a pseudo-random number generator seeded in such a way that
     random values are exceedingly unlikely sends (y, hash(x)) to repeat. The files are PEM
     encoded Alice in printable ASCII format suitable for mailing as MIME objects.
     The file names include the name of GQ
   response message. Besides making the generating host together with response shorter, the
     filestamp, as described previously in this memorandum.

     The generated files are typically stored in a shared directory in NFS
     mounted file systems, with files containing private keys obscured hash makes
   it effectively impossible for an intruder to all
     but root. Links from default file names assumed solve for b by observing
   a number of these messages.

   Alice receives the response and computes y^b v^r mod n. After a bit
   of modular algebra, this simplifies to k^b. If hash(k^b) matches x,
   Alice knows that Bob has the NTP daemon are
     installed group key b. The signed response binds
   this knowledge to Bob's private key and the selected files for public key previously
   received in his certificate. Further evidence is the host certificate
   containing the public identity key, sign key since this is also signed with
   Bob's private key. On success the IFF and host
     certificate. Since PRV bits are lit in the files
   server status word.

E.5 Interoperability Issues

   A specific combination of successive generations authentication scheme (none, symmetric key,
   Autokey), digest/signature scheme and different
     hosts have unique names, there identity scheme (PC, TC, GQ,
   IFF) is no possibility of name collisions. An
     extensive set of consistency checks avoids linking from called a particular
     host to the files of another host, for example.

     The ntp-genkeys program generates public/private key files for both cryptotype, although not all combinations are
   possible. There may be management configurations where the
     RSA servers
   and DSA encryption algorithms with a default modulus of 512 bits.
     The host key used for cookie encryption must be RSA. By default, clients may not all support the same key is used for signature encryption. However, a different RSA key
     or a DSA key cryptotypes. A secure NTPv4
   subnet can be specified for signature encryption.

     The ntp-genkeys program also generates certificate request and self-
     signed certificate files. configured in several ways while keeping in mind the
   principles explained in this section. Note however that some
   cryptotype combinations may successfully interoperate with each
   other, but may not represent good security practice.

   The X.509 certificate request used by Autokey
     includes cryptotype of an association is determined at the minimum these values and possibly related information
     needed by an external certificate authority. time of
   mobilization, either at configuration time or some time later when a
   packet of appropriate cryptotype arrives. When a client, broadcast or
   symmetric active association is mobilized at configuration time, it
   can be designated non-authentic, authenticated with symmetric key or
   authenticated with some Autokey expects the subject
     name scheme, and issuer name to be subsequently it will send
   packets with that cryptotype. When a responding server, broadcast
   client or symmetric passive association is mobilized, it is
   designated with the same cryptotype as the generating host name. received packet.

   When multiple identity schemes are supported, the parameter exchange
   determines which one is used. The program avoids request message contains bits
   corresponding to the need for schemes it supports, while the response message
   contains bits corresponding to the schemes it supports. The client
   matches the server bits with its own and selects a serial number file compatible
   identity scheme. The server is driven entirely by using the
     filestamp as the certificate serial number. By default, certificates client
   selection and remains stateless. When multiple selections are
     valid for one year following the time of generation, although these
     conventions may change. Also,
   possible, the program assumes X.509 version 1
     formats, although this may change order from most secure to version 3 in future. Other
     implementations might have different conventions.

     Appendix C. Packet Processing Rules

     Exhaustive examination least is GC, IFF, TC. Note
   that PC does not interoperate with any of possible vulnerabilities at the various
     processing steps of others, since they
   require the NTP protocol as specified in RFC-1305 have
     resulted in host certificate which a revised list of packet sanity tests. There are 12 tests,
     called TEST1 through TEST12 in PC server will not reveal.

   Following the reference implementation, which are
     performed in principle that time is a specific order designed public value, a server
   responds to gain maximum diagnostic
     information any client packet that matches its cryptotype
   capabilities. Thus, a server receiving a non-authenticated packet
   will respond with a non-authenticated packet, while protecting against an accidental the same server
   receiving a packet of a cryptotype it supports will respond with
   packets of that cryptotype. However, new broadcast or malicious clogging
     attack. These tests are described in detail in manycast client
   associations or symmetric passive associations will not be mobilized
   unless the Flash Codes section
     of server supports a cryptotype compatible with the ntpq documentation page at
     www.eecis.udel.edu/~ntp/ntp_spool/html/ntpq.htm.

     The sanity tests are divided into three tiers as previously described.
     The first tier deflects access control and
   packet message digest
     violations. The second deflects received. By default, non-authenticated associations will not
   be mobilized unless overridden in a decidedly dangerous way.

   Some examples may help to reduce confusion. Client Alice has no
   specific cryptotype selected. Server Bob supports both symmetric key
   and Autokey cryptography. Alice's non-authenticated packets from broken or unsynchronized
     servers arrive at
   Bob, who replies with non-authenticated packets. Cathy has a copy of
   Bob's symmetric key file and replays. The third deflects has selected key ID 4 in packets to Bob.
   If Bob verifies the packet with invalid header
     fields or time values key ID 4, he sends Cathy a reply with excessive errors. However, the tests in this
     last group do not directly affect cryptographic
   that key. If authentication fails, Bob sends Cathy a thing called a
   crypto-NAK, which tells her something broke. She can see the protocol
     vulnerability, so are beyond evidence
   using the scope utility programs of discussion here.

     When a host initializes, it reads its the NTP software library.

   Symmetric peers Bob and Denise have rolled their own host key, sign key keys,
   certificates and
     certificate files, which are required for continued operation.
     Optionally, it reads the leapseconds file, when available. When reading
     these files identity parameters and lit the host checks the filestamps for validity; status bits for instance,
     all filestamps must be later than
   the time identity schemes they can support. Upon completion of the UTC timescale was
     established in 1972
   parameter exchange, both parties know the digest/signature scheme and
   available identity schemes of the certificate filestamp must other party. They do not have to
   use the same schemes, but each party must use the digest/signature
   scheme and one of the identity schemes supported by the other party.

   It should be earlier
     than clear from the sign key filestamp (or host key filestamp, if above that is Bob can support all the
     default sign key). In general, girls
   at the time the files are read, the host
     is not synchronized, so it cannot determine whether the filestamps are
     bogus other than these simple checks.

     Once a client has synchronized to a proventic source, additional checks
     are implemented same time, as each message arrives. In the following the relation A
     -> B is Lamport's "happens before" relation which is true if event A
     happens before event B. Here long as he has compatible authentication and
   identification credentials. Now, Bob can act just like the relation is assume to hold if event A
     is simultaneous girls in
   his own choice of servers; he can run multiple configured
   associations with event B, unless noted to multiple different servers (or the contrary. The
     following assertions are required:

     1. For timestamp T and filestamp F, F->T; same server,
   although that is, the timestamp must might not be earlier than the filestamp.

     2. In client and symmetric modes, useful). But, wise security policy might
   preclude some cryptotype combinations; for host key filestamp H, public key
     timestamp P, cookie timestamp C and autokey timestamp A, H->P->C->A;
     that is, once the cookie is generated instance, running an earlier cookie will
   identity scheme with one server and no authentication with another
   might not be
     accepted, wise.

Appendix F. File Examples

   This appendix shows the file formats used by the OpenSSL library and once
   the key list reference implementation. These are not included in the
   specification and are given here only as examples. In each case the
   actual file contents are shown followed by a dump produced by the
   OpenSSL asn1 program.

F.1 RSA-MD5cert File and ASN.1 Encoding

   # ntpkey_RSA-MD5cert_whimsy.udel.edu.3236983143
   # Tue Jul 30 01:59:03 2002
   -----BEGIN CERTIFICATE-----
   MIIBkTCCATugAwIBAgIEwPBxZzANBgkqhkiG9w0BAQQFADAaMRgwFgYDVQQDEw93
   aGltc3kudWRlbC5lZHUwHhcNMDIwNzMwMDE1OTA3WhcNMDMwNzMwMDE1OTA3WjAa
   MRgwFgYDVQQDEw93aGltc3kudWRlbC5lZHUwWjANBgkqhkiG9w0BAQEFAANJADBG
   AkEA2PpOz6toSQ3BtdGrBt+F6cSSde6zhayOwRj5nAkOvtQ505hdxWhudfKe7ZOY
   HRLLqACvVJEfBaSvE5OFWldUqQIBA6NrMGkwDwYDVR0TAQH/BAUwAwEB/zALBgNV
   HQ8EBAMCAoQwSQYDVR0OBEIEQEVFGZar3afoZcHDmhbgiOmaBrtWTlLHRwIJswge
   LuqB1fbsNEgUqFebBR1Y9qLwYQUm7ylBD+3z9PlhcUOwtnIwDQYJKoZIhvcNAQEE
   BQADQQAVZMiNbYV2BjvFH9x+t0PB9//giOV3fQoLK8hXXpyiAF4KLleEqP13pK0H
   TceF3e3bxSRTndkIhklEAcbYXm66
   -----END CERTIFICATE-----

     0:d=0  hl=4 l= 401 cons: SEQUENCE
     4:d=1  hl=4 l= 315 cons: SEQUENCE
     8:d=2  hl=2 l=   3 cons: cont [ 0 ]
    10:d=3  hl=2 l=   1 prim: INTEGER  :02
    13:d=2  hl=2 l=   4 prim: INTEGER  :-3F0F8E99
    19:d=2  hl=2 l=  13 cons: SEQUENCE
    21:d=3  hl=2 l=   9 prim: OBJECT:md5WithRSAEncryption
    32:d=3  hl=2 l=   0 prim: NULL
    34:d=2  hl=2 l=  26 cons: SEQUENCE
    36:d=3  hl=2 l=  24 cons: SET
    38:d=4  hl=2 l=  22 cons: SEQUENCE
    40:d=5  hl=2 l=   3 prim: OBJECT:commonName
    45:d=5  hl=2 l=  15 prim: PRINTABLESTRING :whimsy.udel.edu
    62:d=2  hl=2 l=  30 cons: SEQUENCE
    64:d=3  hl=2 l=  13 prim: UTCTIME  :020730015907Z
    79:d=3  hl=2 l=  13 prim: UTCTIME  :030730015907Z
    94:d=2  hl=2 l=  26 cons: SEQUENCE
    96:d=3  hl=2 l=  24 cons: SET
    98:d=4  hl=2 l=  22 cons: SEQUENCE
   100:d=5  hl=2 l=   3 prim: OBJECT:commonName
   105:d=5  hl=2 l=  15 prim: PRINTABLESTRING :whimsy.udel.edu
   122:d=2  hl=2 l=  90 cons: SEQUENCE
   124:d=3  hl=2 l=  13 cons: SEQUENCE
   126:d=4  hl=2 l=   9 prim: OBJECT:rsaEncryption
   137:d=4  hl=2 l=   0 prim: NULL
   139:d=3  hl=2 l=  73 prim: BIT STRING
   214:d=2  hl=2 l= 107 cons: cont [ 3 ]
   216:d=3  hl=2 l= 105 cons: SEQUENCE
   218:d=4  hl=2 l=  15 cons: SEQUENCE
   220:d=5  hl=2 l=   3 prim: OBJECT:X509v3 Basic Constraints
   225:d=5  hl=2 l=   1 prim: BOOLEAN  :255
   228:d=5  hl=2 l=   5 prim: OCTET STRING
   235:d=4  hl=2 l=  11 cons: SEQUENCE
   237:d=5  hl=2 l=   3 prim: OBJECT:X509v3 Key Usage
   242:d=5  hl=2 l=   4 prim: OCTET STRING
   248:d=4  hl=2 l=  73 cons: SEQUENCE
   250:d=5  hl=2 l=   3 prim: OBJECT:X509v3 Subject Key Identifier
   255:d=5  hl=2 l=  66 prim: OCTET STRING
   323:d=1  hl=2 l=  13 cons: SEQUENCE
   325:d=2  hl=2 l=   9 prim: OBJECT:md5WithRSAEncryption
   336:d=2  hl=2 l=   0 prim: NULL
   338:d=1  hl=2 l=  65 prim: BIT STRING

F.2 GQkey File and autokey values are generated,
     earlier autokey values will not be accepted.

     3. For sign file S ASN.1 Encoding

   # ntpkey_GQkey_whimsy.udel.edu.3236983143
   # Tue Jul 30 01:59:03 2002
   -----BEGIN RSA PUBLIC KEY-----
   MIGEAkAbYA9K8kpo2ki7Vq6cSkDccqe0RV6MTrFgjt/sp7E8Ki1mng45PJneAq9B
   ZO4rlLYrftLoejQY/nJA2q3MK7iMAkBFRRmWq92n6GXBw5oW4Ijpmga7Vk5Sx0cC
   CbMIHi7qgdX27DRIFKhXmwUdWPai8GEFJu8pQQ/t8/T5YXFDsLZy
   -----END RSA PUBLIC KEY-----

     0:d=0  hl=3 l= 132 cons: SEQUENCE
     3:d=1  hl=2 l=  64 prim: INTEGER  :<hex string omitted>
    69:d=1  hl=2 l=  64 prim: INTEGER  :<hex string omitted>

F.3 GQpar File and certificate filestamp C specifying begin time B ASN.1 Encoding

   # ntpkey_GQpar_whimsy.udel.edu.3236983143
   # Tue Jul 30 01:59:03 2002
   -----BEGIN RSA PUBLIC KEY-----
   MIGFAkEAvojViJ3TowkOKpsb6HBZ50SfzC1M4mAGd51q91WhT7S7IZBfIF/emwXe
   yJmZijRqYkCpQj+fp528yRwefq+IowJADgw/uaQ0qU/Q2JeMQ2JtSHKHCTmnVVPE
   mXPvH9UU/AnMEuiG0LL6AkdxIZiXRuUrOtXsb22tifzMnc/yrus+2g==
   -----END RSA PUBLIC KEY-----

     0:d=0  hl=3 l= 133 cons: SEQUENCE
     3:d=1  hl=2 l=  65 prim: INTEGER  :<hex string omitted>
    70:d=1  hl=2 l=  64 prim: INTEGER  :<hex string omitted>

F.4 RSAkey File and end time E, S->C->B->E; that is, the valid period must be nonempty ASN.1 Encoding

   # ntpkey_RSAkey_whimsy.udel.edu.3236983143
   # Tue Jul 30 01:59:03 2002
   -----BEGIN RSA PRIVATE KEY-----
   MIIBOgIBAAJBANj6Ts+raEkNwbXRqwbfhenEknXus4WsjsEY+ZwJDr7UOdOYXcVo
   bnXynu2TmB0Sy6gAr1SRHwWkrxOThVpXVKkCAQMCQQCQpt81HPAws9Z5NnIElQPx
   Lbb5Sc0DyF8rZfu9W18p4Zb5UH3KYqZfAO4K0GTmxuriFphgS9bELSw5L6ow4t6D
   AiEA7ACLlKZtCp91CaDohViPhs7KBdRVq7DG9n88z9MM/gMCIQDrXRQMb2dqR/ww
   PHJ7aljkhhTE78mxLpn2Po82PfYI4wIhAJ1VsmMZngcU+LEV8FjltQSJ3APi48fL
   L07/fd/iCKlXAiEAnOi4CEpE8YVSytL2/PGQmFljLfUxIMm7+X8KJClOsJcCICgU
   1w07kRO2ycicL2QRVh8J8vQL68VfH53H+oobKDCd
   -----END RSA PRIVATE KEY-----

     0:d=0  hl=4 l= 314 cons: SEQUENCE
     4:d=1  hl=2 l=   1 prim: INTEGER  :00
     7:d=1  hl=2 l=  65 prim: INTEGER  :<hex string omitted>
    74:d=1  hl=2 l=   1 prim: INTEGER  :03
    77:d=1  hl=2 l=  65 prim: INTEGER  :<hex string omitted>
   144:d=1  hl=2 l=  33 prim: INTEGER  :<hex string omitted>
   179:d=1  hl=2 l=  33 prim: INTEGER  :<hex string omitted>
   214:d=1  hl=2 l=  33 prim: INTEGER  :<hex string omitted>
   249:d=1  hl=2 l=  33 prim: INTEGER  :<hex string omitted>
   284:d=1  hl=2 l=  32 prim: INTEGER  :<hex string omitted>

F.5 IFFpar File and not retroactive.

     4. For timestamp T, begin time B ASN.1 Encoding

   # ntpkey_IFFpar_whimsy.udel.edu.3236983143
   # Tue Jul 30 01:59:03 2002
   -----BEGIN DSA PRIVATE KEY-----
   MIH4AgEAAkEA7fBvqq9+3DH5BnBScMkruqH4QEB76oec1zjWQ23gyoP2U+L8tHfv
   z2LmogOqE1c0McgQynyfQMSDUEmxMyiDwQIVAJ18qdV84wmiCGmWgsHKbpAwepDX
   AkA4y42QqZ8aUzQRwkMuYTKbyRRnCG1TJi5eVJcCq65twl5c1bnn24xkbl+FXqck
   G6w9NcDtSzuYg1gFLxEuWsYaAkEAjc+nPJR7VY4BjDleVTna07edDfcySl9vy8Pa
   B4qArk51LdJlJ49yxEPUxFy/KBIFEHCwRZMc1J7z7dQ/Af26zQIUMXkbVz0D+2Yo
   YlG0C/F33Q+N5No=
   -----END DSA PRIVATE KEY-----

                    0:d=0  hl=3 l= 248 cons: SEQUENCE
                   3:d=1  hl=2 l=   1 prim: INTEGER :00
          6:d=1  hl=2 l=  65 prim: INTEGER :<hex string omitted>
         73:d=1  hl=2 l=  21 prim: INTEGER :<hex string omitted>
         96:d=1  hl=2 l=  64 prim: INTEGER :<hex string omitted>
        162:d=1  hl=2 l=  65 prim: INTEGER :<hex string omitted>
        229:d=1  hl=2 l=  20 prim: INTEGER :<hex string omitted>

Appendix G. ASN.1 Encoding Rules

   Certain value fields in request and end time E, B->T->E; that is, the
     timestamp T response messages contain data
   encoded in ASN.1 distinguished encoding rules (DER). The BNF grammer
   for each encoding rule is valid from given below along with the beginning if second B through OpenSSL routine
   used for the end of
     second E. This raises encoding in the interesting possibilities where a truechimer
     server with expired certificate or a falseticker with valid certificate reference implementation. The object
   identifiers for the encryption algorithms and message
   digest/signature encryption schemes are specified in [RFC-3279]. The
   particular algorithms required for conformance are not detected until the client has synchronized to specified in
   this document.

G.1 COOKIE request, IFF response, GQ response

   The value field of these messages contains a clique sequence of
     proventic truechimers.

     5. two integers
   (x, y). For each of signatures, the client saves COOKIE request, the most recent valid
     timestamp T0 and filestamp F0. values are encoded by the
   i2d_RSAPublicKey() routine in the OpenSSL distribution. For every received message carrying
     timestamp T1 and filestamp F1, the message is discarded unless T0->T1 IFF
   and F0->F1; however, if GQ responses, the KEY bit of values are encoded by the association status word is
     dim, i2d_DSA_SIG()
   routine.

   In the message is not discarded if T1 = T0; that is, old messages are
     discarded and, in addition, if COOKIE request, x is the server RSA modulus in bits and y is proventic, the message
   public exponent. In the IFF and GQ responses, x is
     discarded if an old duplicate.

     An interesting question the challenge
   response and y is what happens if during regular operation the hash of the private value.

   RSAPublicKey ::= SEQUENCE {
      x ::= INTEGER,
      y ::= INTEGER
   }

G.2 CERT response, SIGN request and response

   The value field contains a X509v3 certificate becomes invalid. encoded by the
   i2d_X509() routine in the OpenSSL distribution. The behavior assumed encoding follows
   the rules stated in [RFC-3280], including the use of X509v3 extension
   fields.

   Certificate ::= SEQUENCE {
      tbsCertificate    TBSCertificate,
      signatureAlgorithmAlgorithmIdentifier,
      signatureValue    BIT STRING
   }
   The signatureAlgorithm is identical to the
     case where an incorrect sign key were used. Thus, object identifier of the next time a client
     attempts message
   digest/signature encryption scheme used to verify an autokey signature, for example, sign the operation
     would fail and eventually cause a general client reset and restart.

     Security Considerations

     Security issues are certificate. The
   signatureValue is computed by the main topic of certificate issuer using 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
   algorithm and key management protocol (ISAKMP). Request for
     Comments RFC-2408, Internet Engineering Task Force, November 1998.

     6. Mills, D.L. Authentication scheme for distributed, ubiquitous, real-
     time protocols. Proc. Advanced Telecommunications/Information
     Distribution Research Program (ATIRP) Conference (College Park MD,
     January 1997), 293-298.

     7. Mills, D.L. Cryptographic authentication the issuer private key.

   TBSCertificate ::= SEQUENCE {
      version        EXPLICIT v3(2),
      serialNumber   CertificateSerialNumber,
      signature   AlgorithmIdentifier,
      issuer         Name,
      validity    Validity,
      subject        Name,
      subjectPublicKeyInfo SubjectPublicKeyInfo,
      extensions     EXPLICIT Extensions OPTIONAL
   }

   The serialNumber is an integer guaranteed to be unique 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, the
   generating host. The reference implementation uses the NTP seconds
   when the certificate was generated. The signature is the object
   identifier of the message digest/signature encryption scheme used to
   sign the certificate. It must be identical to the signatureAlgorithm.

   CertificateSerialNumber ::= INTEGER

   Validity ::= SEQUENCE {
      notBefore   UTCTime,
      notAfter    UTCTime
   }

   The notBefore and analysis. Network Working Group Report RFC-1305,
     University notAfter define the period of Delaware, March 1992, 113 pp.

     9. Mills, D.L. Proposed authentication enhancements validity as defined
   in and certificate filestamp are summarized in Appendix X.

   SubjectPublicKeyInfo ::= SEQUENCE {
      algorithm   AlgorithmIdentifier,
      subjectPublicKey  BIT STRING
   }

   The AlgorithmIdentifier specifies the encryption algorithm for the Network Time
     Protocol version 4. Electrical Engineering Report 96-10-3, University
   subject public key. The subjectPublicKey is the public key 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 the
   subject.

   Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension

   Extension ::= SEQUENCE {
      extnID         OBJECT IDENTIFIER,
      critical    BOOLEAN DEFAULT FALSE,
      extnValue   OCTET STRING
   }

   Name ::= SEQUENCE {
      OBJECT IDENTIFIER commonName
      PrintableString   HostName
   }

   For all certificates, the subject HostName is the unique DNS name of Delaware, October 1994, 32 pp.

     11. Mills, D.L. Public
   the host to which the public key cryptography for belongs. The reference
   implementation uses the Network Time Protocol.
     Electrical Engineering Report 00-5-1, University string returned by the Unix gethostname()
   routine (trailing NUL removed). For other than self-signed
   certificates, the issuer HostName is the unique DNS name 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. the host
   signing the certificate.

Security Considerations

   Security issues are the main topic of this document.

Author's Address Addresses

   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
   USA

   Email: mills@udel.edu
                        Full Copyright Statement

     "Copyright

    Copyright (C) The Internet Society, 2001. Society (2002).  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 implementation 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. into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.