[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 5906

Network Working Group                                   B. Haberman, Ed.
Internet-Draft                                                   JHU/APL
Obsoletes: RFC 1305                                             D. Mills
(if approved)                                                U. Delaware
Intended status: Informational                         February 25, 2008
Expires: August 28, 2008


         Network Time Protocol Version 4 Autokey Specification
                       draft-ietf-ntp-autokey-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This memo describes the Autokey security model for authenticating
   servers to clients using the Network Time Protocol (NTP) and public
   key cryptography.  Its design is based on the premise that IPSEC
   schemes cannot be adopted intact, since that would preclude stateless
   servers and severely compromise timekeeping accuracy.  In addition,
   PKI schemes presume authenticated time values are always available to



Haberman & Mills         Expires August 28, 2008                [Page 1]

Internet-Draft                NTPv4 Autokey                February 2008


   enforce certificate lifetimes; however, cryptographically verified
   timestamps require interaction between the timekeeping and
   authentication functions.

   This memo includes the Autokey requirements analysis, design
   principles and protocol specification.  A detailed description of the
   protocol states, events and transition functions is included.  A
   prototype of the Autokey design based on this memo has been
   implemented, tested and documented in the NTP Version 4 (NTPv4)
   software distribution for Unix, Windows and VMS at
   http://www.ntp.org.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  NTP Security Model . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Approach . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Autokey Cryptography . . . . . . . . . . . . . . . . . . . . .  8
   5.  NTP Secure Groups  . . . . . . . . . . . . . . . . . . . . . . 11
   6.  Identity Schemes . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  Timestamps and Filestamps  . . . . . . . . . . . . . . . . . . 16
   8.  Autokey Protocol Overview  . . . . . . . . . . . . . . . . . . 18
   9.  Autokey Operations . . . . . . . . . . . . . . . . . . . . . . 20
   10. Autokey Protocol Messages  . . . . . . . . . . . . . . . . . . 21
     10.1.  No-Operation  . . . . . . . . . . . . . . . . . . . . . . 23
     10.2.  Association Message (ASSOC) . . . . . . . . . . . . . . . 24
     10.3.  Certificate Message (CERT)  . . . . . . . . . . . . . . . 24
     10.4.  Cookie Message (COOKIE) . . . . . . . . . . . . . . . . . 24
     10.5.  Autokey Message (AUTO)  . . . . . . . . . . . . . . . . . 24
     10.6.  Leapseconds Values Message (LEAP) . . . . . . . . . . . . 25
     10.7.  Sign Message (SIGN) . . . . . . . . . . . . . . . . . . . 25
     10.8.  Identity Messages (IFF, GQ, MV) . . . . . . . . . . . . . 25
   11. Autokey State Machine  . . . . . . . . . . . . . . . . . . . . 25
     11.1.  Status Word . . . . . . . . . . . . . . . . . . . . . . . 25
     11.2.  Host State Variables  . . . . . . . . . . . . . . . . . . 27
     11.3.  Client State Variables (all modes)  . . . . . . . . . . . 29
     11.4.  Server State Variables (broadcast and symmetric modes)  . 30
     11.5.  Protocol State Transitions  . . . . . . . . . . . . . . . 30
       11.5.1.  Server Dance  . . . . . . . . . . . . . . . . . . . . 30
       11.5.2.  Broadcast Dance . . . . . . . . . . . . . . . . . . . 31
       11.5.3.  Symmetric Dance . . . . . . . . . . . . . . . . . . . 32
     11.6.  Error Recovery  . . . . . . . . . . . . . . . . . . . . . 34
     11.7.  Security Considerations . . . . . . . . . . . . . . . . . 36
     11.8.  Protocol Vulnerability  . . . . . . . . . . . . . . . . . 36
     11.9.  Clogging Vulnerability  . . . . . . . . . . . . . . . . . 37
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38



Haberman & Mills         Expires August 28, 2008                [Page 2]

Internet-Draft                NTPv4 Autokey                February 2008


   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
     14.1.  Normative References  . . . . . . . . . . . . . . . . . . 38
     14.2.  Informative References  . . . . . . . . . . . . . . . . . 38
   Appendix A.  Timestamps, Filestamps and Partial Ordering . . . . . 39
   Appendix B.  Identity Schemes  . . . . . . . . . . . . . . . . . . 40
     B.1.   Private Certificate (PC) Scheme . . . . . . . . . . . . . 41
     B.2.   Trusted Certificate (TC) Scheme . . . . . . . . . . . . . 41
     B.3.   Schnorr (IFF) Identity Scheme . . . . . . . . . . . . . . 42
     B.4.   Guillard-Quisquater (GQ) Identity Scheme  . . . . . . . . 44
     B.5.   Mu-Varadharajan (MV) Identity Scheme  . . . . . . . . . . 46
   Appendix C.  ASN.1 Encoding Rules  . . . . . . . . . . . . . . . . 48
     C.1.   COOKIE request, IFF response, GQ response, MV response  . 49
     C.2.   Certificates  . . . . . . . . . . . . . . . . . . . . . . 49
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
   Intellectual Property and Copyright Statements . . . . . . . . . . 53




































Haberman & Mills         Expires August 28, 2008                [Page 3]

Internet-Draft                NTPv4 Autokey                February 2008


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 ctually sent by the intended server and
   not manufactured or modified by an intruder.  Ubiquity requires that
   a client can verify the authenticity of a server using only public
   information.  Survivability requires protection from faulty
   implementations, improper operation and possibly malicious clogging
   and replay attacks.

   This memo describes a cryptographically sound and efficient
   methodology for use in the Network Time Protocol (NTP) [1].  The
   various key agreement schemes [2][3][4] proposed require per-
   association state variables, which contradicts the principles of the
   remote procedure call (RPC) paradigm in which servers keep no state
   for a possibly large client population.  An evaluation of the PKI
   model and algorithms as implemented in the OpenSSL library leads to
   the conclusion that any scheme requiring every NTP packet to carry a
   PKI digital signature would result in unacceptably poor timekeeping
   performance.

   The Autokey protocol 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
   implemented, tested and deployed in the Internet of today.  A
   detailed description of the security model, design principles and
   implementation is presented in this memo.


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 esignated time intervals; but, time
   intervals can be enforced only when participating servers and clients
   are reliably synchronized to UTC.  In addition, 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 memo the notion of



Haberman & Mills         Expires August 28, 2008                [Page 4]

Internet-Draft                NTPv4 Autokey                February 2008


   "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
   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 mobilizes a
   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 the server certificate and identity have been verified
   by the means described in this memo.  However, 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
   associations and according to the NTP mitigation algorithms.

   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) [5] and Authentication Header (AH) [6] 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 recipient, 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, 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 memo 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



Haberman & Mills         Expires August 28, 2008                [Page 5]

Internet-Draft                NTPv4 Autokey                February 2008


   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 on-wire timestamp
   exchange scheme is inherently resistant to spoofing, packet loss 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 attacks.

   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, network
       or client can process them, especially if they require expensive
       cryptographic computations.

   3.  In a wiretap attack the intruder can intercept, modify and replay
       a packet.  However, it cannot permanently prevent onward
       transmission of the original packet; that is, it cannot break the
       wire, only tell lies and congest it.  Except in unlikely cases
       considered in Section 11.7, the modified packet cannot arrive at
       the victim before the original packet, nor does it have the
       server private keys or identity parameters.

   4.  In a middleman or masquerade attack the intruder is positioned
       between the server and client, so it can intercept, modify and
       replay a packet and prevent onward transmission of the original
       packet.  Except in unlikely cases considered in Section 11.7, the
       middleman does not have the server private keys.

   The NTP security model assumes the following possible limitations.

   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.



Haberman & Mills         Expires August 28, 2008                [Page 6]

Internet-Draft                NTPv4 Autokey                February 2008


   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.  Client security functions must involve only public values
       transmitted over the net.  Private values must never be disclosed
       beyond the machine on which they were created, except in the case
       of a special trusted agent (TA) assigned for this purpose.

   Unlike the Secure Shell security model, where the client must be
   securely authenticated to the server, in NTP the server must be
   securely authenticated to the client.  In ssh each different
   interface address can be bound to a different name, as returned by a
   reverse-DNS query.  In this design separate public/private key pairs
   may be required for each interface address with a distinct name.  A
   perceived advantage of this design is that the security compartment
   can be different for each interface.  This allows a firewall, for
   instance, to require some interfaces to authenticate the client and
   others not.


3.  Approach

   The Autokey protocol described in this memo is designed to meet the
   following objectives.  In-depth discussions on these objectives is in
   the web briefings and will not be elaborated in this memo.  Note that
   here and elsewhere in this memo mention of broadcast mode means
   multicast mode as well, with exceptions as noted in the 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 [7].  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 NTP packet is accepted for processing
       only when the required cryptographic values have been obtained
       and verified and the packet has passed all header 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.



Haberman & Mills         Expires August 28, 2008                [Page 7]

Internet-Draft                NTPv4 Autokey                February 2008


   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 and cookie encryption operations.

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


4.  Autokey Cryptography

   Autokey cryptography is based on the PKI algorithms commonly used in
   the Secure Shell and Secure Sockets Layer applications.  As in these
   applications Autokey uses message digests to detect packet
   modification, digital signatures to verify credentials and public
   certificates to provide traceable authority.  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.

   NTPv3 and NTPv4 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 with NTPv3, the NTPv4 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.

   Both symmetric key and public key cryptography authenticate as shown
   in Figure 1.  The server looks up the key associated with the key ID
   and calculates the message digest from the NTP header and extension
   fields together with the key value.  The key ID and digest form the
   message authentication code (MAC) included with the message.  The
   client does the same computation using its local copy of the key and
   compares the result with the digest in the MAC.  If the values agree,
   the message is assumed authentic.










Haberman & Mills         Expires August 28, 2008                [Page 8]

Internet-Draft                NTPv4 Autokey                February 2008


                +------------------+
                | NTP Header and   |
                | Extension Fields |
                +------------------+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |       |        |    Message Authenticator Code |
                     \|/     \|/       +              (MAC)            +
                ********************   | +-------------------------+   |
                *   Compute Hash   *<----| Key ID | Message Digest |   +
                ********************   | +-------------------------+   |
                          |            +-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+
                         \|/                        \|/
                +------------------+       +-------------+
                |  Message Digest  |------>|   Compare   |
                +------------------+       +-------------+

                     Figure 1: Message Authentication

   Autokey uses specially contrived session keys, called autokeys, and a
   precomputed pseudo-random sequence of autokeys which are saved in the
   autokey list.  The Autokey protocol operates separately for each
   association, so there may be several autokey sequences operating
   independently at the same time.

                   +-------------+-------------+--------+--------+
                   | Src Address | Dst Address | Key ID | Cookie |
                   +-------------+-------------+--------+--------+

                          Figure 2: NTPv4 Autokey

   An autokey is computed from four fields in network byte order as
   shown in Figure 2.  The four values are hashed by the MD5 message
   digest algorithm to produce the 128-bit 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.

   For use with IPv4 the Source Address and Dest Address 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 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 NTP mode.

   The NTP packet format has been augmented to include one or more
   extension fields piggybacked between the original NTP header and the
   MAC.  For packets without extension fields, the cookie is a shared
   private value.  For packets with extension fields, the cookie has a



Haberman & Mills         Expires August 28, 2008                [Page 9]

Internet-Draft                NTPv4 Autokey                February 2008


   default public value of zero, since these packets are 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 address
   fields visible in the transmitted packet must be the same as those
   used to construct the autokey list and that these fields be the same
   as those visible in the received packet.  [The use of alternative
   means, such as Autokey host names (discussed later) or hashes of
   these names may be a topic for future study.]

+-----------+-----------+------+------+   +---------+  +-----+------+
|Src Address|Dst Address|Key ID|Cookie|-->|         |  |Final|Final |
+-----------+-----------+------+------+   | Session |  |Index|Key ID|
     |           |         |        |     | Key ID  |  +-----+------+
    \|/         \|/       \|/      \|/    |  List   |     |       |
   *************************************  +---------+    \|/     \|/
   *          COMPUTE HASH             *             *******************
   *************************************             *COMPUTE SIGNATURE*
     |                    Index n                    *******************
    \|/                                                       |
   +--------+                                                 |
   |  Next  |                                                \|/
   | Key ID |                                           +-----------+
   +--------+                                           | Signature |
   Index n+1                                            +-----------+

                    Figure 3: Constructing the Key List

   Figure Figure 3 shows how the autokey list and autokey values are
   computed.  The key IDs used in the autokey list consists of a
   sequence starting with a random 32-bit nonce (autokey seed) equal to
   or greater than the pivot as the first key ID.  The first autokey is
   computed as above using the given cookie and autokey seed and
   assigned index 0.  The first 32 bits of the result in network byte
   order become the next THe MD5 hash of the autokey is the key value
   saved in the key cache along with the key ID.  The first 32 bits of
   the key become the key ID for the next autokey assigned index 1.

   Operations continue to generate the entire 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 occurs 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



Haberman & Mills         Expires August 28, 2008               [Page 10]

Internet-Draft                NTPv4 Autokey                February 2008


   terminated when the maximum key lifetime is about one hour, so for
   poll intervals above one hour a new key list containing only a single
   entry is regenerated for every poll.

                   +------------------+
                   |  NTP Header and  |
                   | Extension Fields |
                   +------------------+
                        |       |
                       \|/     \|/                     +---------+
                     ****************    +--------+    | Session |
                     * COMPUTE HASH *<---| Key ID |<---| Key ID  |
                     ****************    +--------+    |  List   |
                             |                |        +---------+
                            \|/              \|/
                   +----------------------------------+
                   | Message Authenticator Code (MAC) |
                   +----------------------------------+

                      Figure 4: Transmitting Messages

   The index of the last autokey in the list is saved along with the key
   ID for that entry, collectively called the autokey values.  The
   autokey values are then signed for use later.  The list is used in
   reverse order as shown in Figure 4, so that the first autokey used is
   the last one generated.

   The Autokey protocol includes a message to retrieve the autokey
   values and verify the signature, so that subsequent packets can be
   validated using one or more hashes that eventually match the 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 single packet
   is lost.


5.  NTP Secure Groups

   NTP secure groups are used to define cryptographic compartments and
   security hierarchies.  A secure group consists of a number of hosts
   dynamically assembled as a forest with roots the trusted hosts (THs)
   at the lowest stratum of the group.  The THs do not have to be, but
   often are, primary (stratum 1) servers.  A trusted authority (TA),
   not necessarily a group host, generates private identity keys for
   servers and public identity keys for clients at the leaves of the



Haberman & Mills         Expires August 28, 2008               [Page 11]

Internet-Draft                NTPv4 Autokey                February 2008


   forest.  The TA deploys the server keys to the THs and other
   designated servers using secure means and posts the client keys on a
   public web site.

   For Autokey purposes all hosts belonging to a secure group have the
   same group name but different host names, not necessarily related to
   the DNS names.  The group name is used in the subject and issuer
   fields of the TH certificates; the host name is used in these fields
   for other hosts.  Thus, all host certificates are self-signed.
   During the Autokey protocol a client requests the server to sign its
   certificate and caches the result.  A certificate trail is
   constructed by each host, possibly via intermediate hosts and ending
   at a TH.  Thus, each host along the trail retrieves the entire trail
   from its server(s) and provides this plus its own signed certicicates
   to its clients.

   Secure groups can be configured as hierarchies where a TH of one
   group can be a client of one or more other groups operating at a
   lower stratum.  In one scenario, groups RED and GREEN can be
   cryptographically distinct, but both be clients of group BLUE
   operating at a lower stratum.  In another scenario, group CYAN can be
   a client of multiple groups YELLOW and MAGENTA, both operating at a
   lower stratum.  There are many other scenarios, but all must be
   configured to include only acyclic certificate trails.

   In Figure 5, the Alice group consists of THs Alice, which is also the
   TA, and Carol.  Dependent servers Brenda and Denise have configured
   Alice and Carol, respectively, as their time sources.  Stratum 3
   server Eileen has configured both Brenda and Denise as her time
   sources.  Public certificates are identified by the subject and
   signed by the issuer.  Note that the server keys have been previously
   installed on Brenda and Denise and the client keys installed on all
   machines.

                     +-------------+ +-------------+ +-------------+
                     |   Alice     | |   Brenda    | |   Denise    |
                     |             | |             | |             |
                     | +-+-+-+-+   | | +-+-+-+-+   | | +-+-+-+-+   |
   Certificate       | | Alice |   | | | Brenda|   | | | Denise|   |
   +-+-+-+-+-+       | +-+-+-+-+   | | +-+-+-+-+   | | +-+-+-+-+   |
   | Subject |       | | Alice*| 1 | | | Alice | 4 | | | Carol | 4 |
   +-+-+-+-+-+       | +-+-+-+-+   | | +-+-+-+-+   | | +-+-+-+-+   |
   | Issuer  | S     |             | |             | |             |
   +-+-+-+-+-+       | +=======+   | | +-+-+-+-+   | | +-+-+-+-+   |
                     | ||Alice|| 3 | | | Alice |   | | | Carol |   |
    Group Key        | +=======+   | | +-+-+-+-+   | | +-+-+-+-+   |
   +=========+       +-------------+ | | Alice*| 2 | | | Carol*| 2 |
   || Group || S     |     Carol   | | +-+-+-+-+   | | +-+-+-+-+   |



Haberman & Mills         Expires August 28, 2008               [Page 12]

Internet-Draft                NTPv4 Autokey                February 2008


   +=========+       |             | |             | |             |
                     | +-+-+-+-+   | | +-+-+-+-+   | | +-+-+-+-+   |
    S = step         | | Carol |   | | | Brenda|   | | | Denise|   |
    * = trusted      | +-+-+-+-+   | | +-+-+-+-+   | | +-+-+-+-+   |
                     | | Carol*| 1 | | | Brenda| 1 | | | Denise| 1 |
                     | +-+-+-+-+   | | +-+-+-+-+   | | +-+-+-+-+   |
                     |             | |             | |             |
                     | +=======+   | | +=======+   | | +=======+   |
                     | ||Alice|| 3 | | ||Alice|| 3 | | ||Alice|| 3 |
                     | +=======+   | | +=======+   | | +=======+   |
                     +-------------+ +-------------+ +-------------+
                        Stratum 1                Stratum 2

                     +---------------------------------------------+
                     |                  Eileen                     |
                     |                                             |
                     |           +-+-+-+-+   +-+-+-+-+             |
                     |           | Eileen|   | Eileen|             |
                     |           +-+-+-+-+   +-+-+-+-+             |
                     |           | Brenda|   | Carol | 4           |
                     |           +-+-+-+-+   +-+-+-+-+             |
                     |                                             |
                     |           +-+-+-+-+   +-+-+-+-+             |
                     |           | Alice |   | Carol |             |
                     |           +-+-+-+-+   +-+-+-+-+             |
                     |           | Alice*|   | Carol*| 2           |
                     |           +-+-+-+-+   +-+-+-+-+             |
                     |                                             |
                     |           +-+-+-+-+   +-+-+-+-+             |
                     |           | Brenda|   | Denise|             |
                     |           +-+-+-+-+   +-+-+-+-+             |
                     |           | Alice |   | Carol | 2           |
                     |           +-+-+-+-+   +-+-+-+-+             |
                     |                                             |
                     |                 +-+-+-+-+                   |
                     |                 | Eileen|                   |
                     |                 +-+-+-+-+                   |
                     |                 | Eileen| 1                 |
                     |                 +-+-+-+-+                   |
                     |                                             |
                     |                 +=======+                   |
                     |                 ||Alice|| 3                 |
                     |                 +=======+                   |
                     +---------------------------------------------+
                                       Stratum 3

                        Figure 5: NTP Secure Groups




Haberman & Mills         Expires August 28, 2008               [Page 13]

Internet-Draft                NTPv4 Autokey                February 2008


   The steps in hiking the certificate trails and verifying identity are
   as follows.  Note the step number in the description matches the step
   number in the figure.

   1.  The girls start by loading the host key, sign key, self-signed
       certificate and group key.  They start the Autokey protocol by
       exchanging host names and negotiating digest/signature schemes
       and identity schemes.

   2.  They continue to load certificates recursively until a self-
       signed trusted certificate is found.  Brenda and Denise
       immediately find trusted certificates for Alice and Carol,
       respectively, but Eileen will loop because neither Brenda nor
       Denise have their own certificates signed by either Alice or
       Carol.

   3.  Brenda and Denise continue with the selected identity schemes to
       verify that Alice and Carol have the correct group key previously
       generated by Alice.  If this succeeds, each continues in step 4.

   4.  Brenda and Denise present their certificates for signature.  If
       this succeeds, either or both Brenda and Denise can now provide
       these signed certificates to Eileen, which may be looping in step
       2.  Eileen can now verify the trail via either Brenda or Denise
       to the trusted certificates for Alice and Carol.  Once this is
       done, Eileen can complete the protocol just as Brenda and Denise.

   For various reasons it may be convenient for a server to have client
   keys for more than one group.  For example, Figure 6 shows three
   secure groups Alice, Helen and Carol arranged in a hierarchy.  Hosts
   A, B, C and D belong to Alice, R, S to Helen and X, Y and Z belong to
   Carol.  While not strictly necessary, hosts A, B and R are stratum 1
   and presumed trusted, but the TA generating the identity keys could
   be one of them or another not shown.

















Haberman & Mills         Expires August 28, 2008               [Page 14]

Internet-Draft                NTPv4 Autokey                February 2008


                         *****     *****     @@@@@
           Stratum 1     * A *     * B *     @ R @
                         *****     *****     @@@@@
                             \     /         /
                              \   /         /
                              *****     @@@@@                *********
                   2          * C *     @ S @                * Alice *
                              *****     @@@@@                *********
                              /   \     /
                             /     \   /                     @@@@@@@@@
                         *****     #####                     @ Helen @
                   3     * D *     # X #                     @@@@@@@@@
                         *****     #####
                                   /   \                     #########
                                  /     \                    # Carol #
                              #####     #####                #########
                   4          # Y #     # Z #
                              #####     #####

                 Figure 6: Hierarchical Overlapping Groups

   The intent of the scenario is to provide security separation, so that
   servers cannot masquerade as in other groups and clients cannot
   masquerade as servers.  Assume for example that Alice and Helen
   belong to national standards laboratories and their server keys are
   used to confirm identity between members of each group.  Carol is a
   prominent corporation receiving standards products and requiring
   cryptographic authentication.  Perhaps under contract, host X
   belonging to Carol has client keys for both Alice and Helen and
   server keys for Carol.  The Autokey protocol operates for each group
   separately while preserving security separation.  Host X can prove
   identity in Carol to clients Y and Z, but cannot prove to anybody
   that it belongs to either Alice or Helen.


6.  Identity Schemes

   A digital signature scheme provides secure server authentication, but
   it does not provide protection against masquerade, unless the server
   identity is verified by other means.  The PKI model requires a server
   to prove identity to the client by a certificate trail, but
   independent means such as a drivers license are required for a CA to
   sign the server certificate.  While Autokey supports this model by
   default, in a hierarchical ad-hoc network, especially with server
   discovery schemes like NTP Manycast, proving identity at each rest
   stop on the trail must be an intrinsic capability of Autokey itself.

   While the identity scheme described in [8] is based on a ubiquitous



Haberman & Mills         Expires August 28, 2008               [Page 15]

Internet-Draft                NTPv4 Autokey                February 2008


   Diffie-Hellman infrastructure, it is expensive to generate and use
   when compared to others described in Appendix B.  In principle, an
   ordinary public key scheme could be devised for this purpose, but the
   most stringent Autokey design requires that every challenge, even if
   duplicated, results in a different acceptable response.

   There are five schemes now implemented in the NTPv4 reference
   implementation to prove identity: (1) private certificate (PC), (2)
   trusted certificate (TC), (3) a modified Schnorr algorithm (IFF aka
   Identify Friendly or Foe), (4) a modified Guillou-Quisquater
   algorithm (GQ), and (5) a modified Mu-Varadharajan algorithm (MV).
   Following is a summary description of each; details are given in
   Appendix B.

   The PC scheme involves a private certificate as group key.  The
   certificate is distributed to all other group members by secure means
   and is never revealed outside the group.  In effect, the private
   certificate is used as a symmetric key.  This scheme is used
   primarily for testing and development and is not recommended for
   regular use and is not considered further in this memo.

   All other schemes involve a conventional certificate trail as
   described in RFC 2510 [9].  This is the default scheme when an
   identity scheme is not specified.  While the remaining identity
   schemes incorporate TC, it is not by itself considered further in
   this memo.

   The three remaining schemes IFF, GQ and MV involve a
   cryptographically strong challenge-response exchange where an
   intruder cannot deduce the server key, even after repeated
   observations of multiple exchanges.  In addition, the MV scheme is
   properly described as a zero-knowledge proof, because the client can
   verify the server has the correct group key without either the server
   or client knowing its value.  These schemes start when the client
   sends a nonce to the server, which then rolls its own nonce, performs
   a mathematical operation and sends the results to the client.  The
   client performs another mathematical operation and verifies the
   results are correct.


7.  Timestamps and Filestamps

   While public key signatures provide strong protection against
   misrepresentation of source, computing them is expensive.  This
   invites the opportunity for an intruder to clog the client or server
   by replaying old messages or originating bogus messages.  A client
   receiving such messages might be forced to verify what turns out to
   be an invalid signature and consume significant processor resources.



Haberman & Mills         Expires August 28, 2008               [Page 16]

Internet-Draft                NTPv4 Autokey                February 2008


   In order to foil such attacks, every Autokey message carries a
   timestamp in the form of the NTP seconds when it was.  If the system
   clock is synchronized to a proventic source, a signature is produced
   with valid (nonzero) timestamp.  Otherwise, there is no signature and
   the timestamp is invalid (zero).  The protocol detects and discards
   extension fields with old or duplicate timestamps, before any values
   are used or signatures are verified.

   Signatures are computed only when cryptgraphic values are created or
   modified, which is by design not very ofter.  Extension fields
   carrying these signatures are copied to messages as needed, but the
   signarutres are not recomputed.  There are three signature tyupes:

   1.  Cookie signature/timestamp.  The cookie is signed when created by
       the server and sent to the cliente.

   2.  Autokey signature/timestamp.  The autokey values are signed when
       the key list is created.

   3.  Public values signature/timestamp.  The public key, certificate
       and leapsecond values are signed at the time of generation, which
       occurs when the system clock is first synchronized to a proventic
       source, when the values have changed and about once per day after
       that, even if these values have not changed.

   The most recent timestamp received of each type is saved for
   comparison.  Once a signature with valid timestamp has been received,
   messages with invalid timestamps or earlier valid timestamps of the
   same type are discarded before the signature is verified.  This is
   most important in broadcast mode, which could be vulnerable to a
   clogging attack without this test.

   All cryptographic values used by the protocol are time sensitive and
   are regularly refreshed.  In particular, files containing
   cryptographic 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 the file contents.  While
   cryptographic data files are not specifically signed, every file is
   associated with a filestamp showing the NTP seconds at the creation
   epoch.

   Filestamps and timestamps can be compared in any combination and use
   the same conventions.  It is necessary to compare them from time to
   time to determine which are earlier or later.  Since these quantities
   have a granularity only to the second, such comparisons are ambiguous
   if the values are in the same second.




Haberman & Mills         Expires August 28, 2008               [Page 17]

Internet-Draft                NTPv4 Autokey                February 2008


   It is important that filestamps be proventic data; thus, they cannot
   be produced unless the producer has been synchronized to a proventic
   source.  As such, the filestamps throughout the NTP subnet represent
   a partial ordering of all creation epochs and serve as means to
   expunge old data and insure new data are consistent.  As the data are
   forwarded from server to client, the filestamps are preserved,
   including those for certificate and leapseconds values.  Packets with
   older filestamps are discarded before spending cycles to verify the
   signature.


8.  Autokey Protocol Overview

   The Autokey protocol includes a number of request/response exchanges
   that must be completed in order.  In each exchange a client sends a
   request message with data and expects a server response message with
   data.  Requests and responses are containined in extension fields,
   one request or response in each field, as described later.  An NTP
   packet can contain one request message and one or more response
   messages.  Following is a list of these messages.

   o  Parameter exchange.  The request includes the client host name;
      the response one contains the server host name and status word.
      The status word specifies the digest/signature scheme it will use
      and the identity schemes it supports.

   o  Certificate exchange.  The request includes the subject name of a
      certificate; the response consists of a signed certificate with
      that subject name.  If the the issuer name is not the same as the
      subject name, it has been signed by a host one step closer to a
      trusted host and certificate retrieval continues for the issuer
      name.  If it is trusted and self-signed, the trail concludes at
      the trusted host.  If nontrusted and self-signed, the host
      certificate has not yet been signed, so the trail temporarily
      loops.  Completion of this exchange lights the VAL bit as
      described below.

   o  Indentity exchange.  The certificate trail is generally not
      considered sufficient protection against middleman attacks unless
      additional protection such as described inor proof-of-possession
      scheme in [8] is available, but this is expensive and requires
      servers to retain state.  Autokey can use one of the challenge/
      response identity schemes described in Appendix B.  Completion of
      this exchange lights the IFF bit as described below.

   o  Cookie exchange.  The request includes the public key of the
      client.  THe response includes the server cookie encrypted with
      thise key.  The client uses this value when constructing the key



Haberman & Mills         Expires August 28, 2008               [Page 18]

Internet-Draft                NTPv4 Autokey                February 2008


      list.  Completion of this exchange lights the CKY bit as described
      below.

   o  Autokey exchange.  The request includes either no data or the
      autokey values of the peer in symmetric modes.  The response
      includes the autiokey values of the server or peer.  These values
      are used to verify the autokey sequence.  Completion of this
      exchange lights the AUT bit as described below.

   o  Sign exchange.  This exchange is executed only when the client has
      synchronized to a proventic source.  The request includes the
      self-signed client certificate.  The server acting as CA
      interprets the certificate as a X.509v3 certificate request.  It
      extracts the subject, issuer, and extension fields, builds a new
      certificate with these data along with its own serial number and
      expiration time, then signs it using its own public key and
      includes it in the response.  The client uses the signed
      certificate in its own role as server for dependent clients.
      Completion of this exchange lights the SGN bit as described below.

   o  Leapseconds exchange.  This exchange is executed only when the
      client has synchronized to a proventic source.  This exchange
      occurs when the server has the leapseconds values, as indicated in
      the host status word.  If so, the client requests the values and
      compares them with its own values, if available.  If the server
      values are newer than the client values, the client replaces its
      own with the server values.  The client, acting as server, can now
      provide the most recent values to its dependent clients.  In
      symmetric mode, this results in both peers having the newest
      values.  Completion of this exchange lights the LPT bit as
      described below.

   Once the certificates and identity have been validated, subsequent
   packets are validated by digital signatures and autokey sequences.
   The association is now proventic with respect to the downstratum
   trusted host, but in not yet selectable to discipline the system
   clock.  The associations accumulate time values and the mitigation
   algorithms continue in the usual way.  When these algorithms have
   culled the falsetickers and cluster outlyers and at least three
   survivors remain, the system clock has been synchronized to a
   proventic sourc.

   The time values for truechimer sources form a proventic partial
   ordering relative to the applicable signature timestamps.  This
   raises the interesting issue of how to mitigate between the
   timestamps of different associations.  It might happen, for instance,
   that the timestamp of some Autokey message is ahead of the system
   clock by some presumably small amount.  For this reason, timestamp



Haberman & Mills         Expires August 28, 2008               [Page 19]

Internet-Draft                NTPv4 Autokey                February 2008


   comparisons between different associations and between associations
   and the system clock are avoided, except in the NTP intersection and
   clustering algorithms and when determining whether a certificate has
   expired.


9.  Autokey Operations

   The NTP protocol has three principal modes of operation: client/
   server, symmetric and broadast and each has its own Autokey program,
   or dance.  Autokey choreography is designed to be nonintrusive and to
   require no additional packets other than for regular NTP operations.
   The NTP and Autokey protocols operate simultaneously and
   independently.  When the dance is complete, subsequent packets are
   validated by the autokey sequence and thus considered proventic as
   well.  Autokey assumes NTP clients poll servers at a relatively low
   rate, such as once per minute or slower.  In particular, it is
   assumed that a request sent at one poll opportunity will normally
   result in a response before the next poll opportunity; however the
   protocol is robust against a missed or duplicate response.

   The 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 32-bit random
   private value (server seed) to regenerate the cookie upon arrival of
   a client packet.  The cookie is calculated as the first 32 bits of
   the autokey computed from the client and server addresses, key ID
   zero and the server seed as cookie.  The cookie is used for the
   actual autokey calculation by both the client and server and is thus
   specific to each client separately.

   In the server dance the client uses the cookie and each key ID on the
   key list in turn to retrieve the autokey and generate the MAC.  The
   server uses the same values to generate the message digest and
   verifies it matches the MAC.  It then generates the MAC for the
   response using the same values, but with the client and server
   addresses interchanged.  The client generates the message digest and
   verifies it matches the MAC.  In order to deflect old replays, the
   client verifies the key ID matches the last one sent.  In this dance
   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 the broadcast dance clients normally do not send packets to the
   server, except when first starting up.  At that time the client runs
   the server dance to verify the server credentials and calibrate the
   propagation delay.  The dance requires the association ID of the
   particular server association, since there can be more than one



Haberman & Mills         Expires August 28, 2008               [Page 20]

Internet-Draft                NTPv4 Autokey                February 2008


   operating in the same server.  For this purpose, the server packet
   includes the association ID in every response message sent and, when
   sending the first packet after generating a new key list, it sends
   the autokey values as well.  After obtaining and verifying the
   autokey values, no extension fields are necessary and the client
   verifies further server packets using the autokey sequence.

   The symmetric dance is similar to the server dance and requires only
   a small amount of state between the arrival of a request and
   departure of the response.  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 simple
   nonce.  There exists a possible race condition where each peer sends
   a cookie request 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 EXOR of the
   two values.

   Once the autokey dance has completed, it is normally dormant.  In all
   except the broadcast dance, packets are normally sent without
   extension fields, unless the packet is the first one sent after
   generating a new key list or unless the client has requested the
   cookie or autokey values.  If for some reason the client clock is
   stepped, rather than slewed, all cryptographic and time values for
   all associations are purged and the dances in all associations
   restarted from scratch.  This insures that stale values never
   propagate beyond a clock step.


10.  Autokey Protocol Messages

   The Autokey protocol data unit is the extension field, one or more of
   which can be piggybacked in the NTP packet.  An extension field
   contains either a request with optional data or a response with
   optional 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 most contain meaningful data only if the
   responder is synchronized to a proventic source.  Some requests and
   most responses carry timestamped signatures.  The signature covers
   the entire extension field, including the timestamp and filestamp,
   where applicable.  Only if the packet passes all extension field
   tests are cycles spent to verify the signature.

   There are currently eight Autokey requests and eight corresponding
   responses.  The NTP packet format is described in [1] and the



Haberman & Mills         Expires August 28, 2008               [Page 21]

Internet-Draft                NTPv4 Autokey                February 2008


   extension field format used for these messages is illustrated in
   Figure 7.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Field Type           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Association ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Filestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Value Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               /
   /                             Value                             \
   \                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Signature Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               /
   /                           Signature                           \
   \                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               /
   /                      Padding (if needed)                      \
   \                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 7: NTPv4 Extension Field Format

   Each extension field is zero-padded to a 4 octet boundary.  The
   Length field covers the entire extension field, including the Length
   and Padding fields.  While the minimum field length is 8 octets, a
   maximum field length remains to be established.  The reference
   implementation discards any packet with a field length more than 1024
   octets.

   If an extension field is present, the parser examines the Length
   field.  If the length is less than 4 or not a multiple of 4, a format
   error has occurred and the packet is discarded; otherwise, the parser
   increments the pointer by the length value.  The parser now uses the
   same rules as above to determine whether a MAC is present and/or
   another extension field.

   The 8-bit Code field specifies the request or response operation,



Haberman & Mills         Expires August 28, 2008               [Page 22]

Internet-Draft                NTPv4 Autokey                February 2008


   while the 4-bit Version Number (VN) field is 2 for the current
   protocol version.  There are four flag bits: bit 0 is the Response
   Flag (R) and bit 1 is the Error Flag (E); the other two bits are
   presently unused and should be set to 0.  The remaining fields will
   be described later.

   In the most common protocol operations, a client sends a request to a
   server with an operation code specified in the Code field and both
   the R bit and E bit dim.  The Association ID field is set to the
   value previously received from the server or 0 otherwise.  The server
   returns a response with the same operation code in the Code field and
   lights the R bit.  The server can also light the E bit in case of
   error.  The Association ID field is set to the association ID of the
   server as a handle for subsequent exchanges.  If for some reason the
   association ID value in a request does not match the association ID
   of any mobilized association, the server returns the request with
   both the R and E bits lit.  Note that it is not necessarily a
   protocol error to send an unsolicited response with no matching
   request.

   In some cases not all fields may be present.  For requests, until a
   client has synchronized to a proventic source, signatures are not
   valid.  In such cases the Timestamp and Signature Length fields are 0
   and the Signature field is empty.  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 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 the message, while the filestamp establishes the
   generation epoch of the file that ultimately produced the data that
   is signed.  A signature and timestamp are valid only when the signing
   host is synchronized to a proventic source; otherwise, the timestamp
   is zero.  A cryptographic data file can only be generated if a
   signature is possible; otherwise, the filestamp is zero, except in
   the ASSOC response message, where it contains the server status word.

   Unless specified otherwise in the descriptions to follow, the data
   referred to are stored in the Value field.

10.1.  No-Operation

   A No-operation request (Field Type = 0) does nothing except return an
   empty response which can be used as a crypto-ping.





Haberman & Mills         Expires August 28, 2008               [Page 23]

Internet-Draft                NTPv4 Autokey                February 2008


10.2.  Association Message (ASSOC)

   An Association Message (Field Type = 1) is used in the parameter
   exchange to obtain the host name and status word.  The request
   contains the client status word in the Filestamp field and the host
   name in the Value field.  The response contains the server status
   word in the Filestamp field and the host name in the Value field.  By
   default the host name is the 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.

   When multiple identity schemes are supported, the status words
   determine which one is used.  The request message contains bits
   corresponding to the schemes the client supports, while the response
   message contains bits corresponding to the schemes the server
   supports.  The server and client do an AND operation on the status
   words to select compatible identity schemes.  If multiple schemes
   result, the bits are ranked from right to left.

10.3.  Certificate Message (CERT)

   A Certificate Message (Field Type = 2) is used in the certificate
   exchange to obtain a certificate by name.  The request contains the
   subject name; the response contains the certificate encoded in X.509
   format with ASN.1 syntax as described in Appendix C.

   If the subject name in the response does not match the issuer name,
   the exchange continues with the issuer name replacing the subject
   name in the request.  The exchange continues until a trusted, self-
   signed certificate is found.

10.4.  Cookie Message (COOKIE)

   The Cookie Message (Field Type = 3) is used in server and symmetric
   modes to obtain the server cookie.  The request contains the host
   public key encoded with ASN.1 syntax as described in Appendix C.  The
   response contains the cookie encrypted by the public key in the
   request.

10.5.  Autokey Message (AUTO)

   The Autokey Message (Field Type = 4) is used to obtain the autokey
   values.  The request contains no value.  The response contains two
   32-bit words in network byte order.  The first word is the final key
   ID, while the second is the index of the final key ID.





Haberman & Mills         Expires August 28, 2008               [Page 24]

Internet-Draft                NTPv4 Autokey                February 2008


10.6.  Leapseconds Values Message (LEAP)

   The Leapseconds Values Message (Field Type = 5) is used to obtain the
   leapseconds values as parsed from the leapseconds table from NIST.
   The request and response messages have the same format, except that
   the R bit is set to 0 in the request and set to 1 in the response.
   Both the request and response contains three 32-bit integers, the NTP
   seconds of the latest leap event followed by the NTP seconds when the
   latest NIST table expires and then the TAI offset following the leap
   event.

10.7.  Sign Message (SIGN)

   The Sign Message (Field Type = 6) requests the server to sign and
   return a certificate presented in the request.  The request contains
   the client certificate encoded in X.509 format with ASN.1 syntax as
   described in Appendix C.  The response contains the client
   certificate signed by the server private key.

10.8.  Identity Messages (IFF, GQ, MV)

   The Identity Messages (Field Type = 7 (IFF), 8 (GQ), or 9 (MV))
   contains the client challenge, usually a 160- or 512-bit nonce.  The
   response contains the result of the mathematical operation defined in
   Appendix B.  The Response is encoded in ASN.1 syntax as described in
   Appendix C.


11.  Autokey State Machine

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

11.1.  Status Word

   Each server and client operating also as a server implements a host
   status word, while each client implements an association status word
   for each server.  Both words have the format and content shown in
   Figure 8.  The low order 16 bits of the status word define the state
   of the Autokey protocol, while the high order 16 bits specify the
   message digest/signature encryption scheme as encoded in the OpenSSL
   library.  Bits 24-31 of the status word are reserved for server use,
   while bits 16-23 are reserved for client association use.  In the
   host portion bits 24-27 specify the available identity schemes, while
   bits 28-31 specify the server capabilities.  There are two additional
   bits implemented separately.





Haberman & Mills         Expires August 28, 2008               [Page 25]

Internet-Draft                NTPv4 Autokey                February 2008


                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Digest / Signature NID     |    Client     | Ident |  Host |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 8: Status Word

   The host status word is included in the ASSOC request and response
   messages.  The client copies this word to the association status word
   and then lights additional status bits as the dance proceeds.  Once
   enabled, these bits never come dark unless a general reset occurs and
   the protocol is restarted from the beginning.  The status bits are
   defined as follows:

   o  ENB (31) - Lit if the server implements the Autokey protocol

   o  LPF (30) - Lit if the server has loaded leapseconds values

   o  IDN (24-27) - These four bits select which identity scheme is in
      use.  While specific coding for various schemes is yet to be
      determined, the schemes available in the reference implementation
      and described in Appendix B include the 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

      *  0x8 Mu-Varadharajan (MV) Scheme

   The PC scheme is exclusive of any other scheme.  Otherwise, the IFF,
   GQ and MV bits can be enabled in any combination.

   The association status bits are defined as follows:

   o  VAL (0x0100) - Lit when the server certificate and public key are
      validated.

   o  IFF (0x0200) - Lit when the server identity credentials are
      confirmed.

   o  PRV (0x0400) - Lit when the server signature is verified using the
      public key and identity credentials.  Also called the proventic
      bit elsewhere in this memo.  When enabled, signed values in



Haberman & Mills         Expires August 28, 2008               [Page 26]

Internet-Draft                NTPv4 Autokey                February 2008


      subsequent messages are presumed proventic.

   o  CKY (0x0800) - Lit when the cookie is received and validated.
      When enabled, key lists with nonzero cookies can be generated.

   o  AUT (0x1000) - Lit when the autokey values are received and
      validated.  When enabled, clients can validate packets without
      extension fields according to the autokey sequence.

   o  SGN (0x2000) - Lit when the host certificate is signed by the
      server.

   o  LPT (0x4000) - Lit when the leapseconds values are received and
      validated.

   There are four additional status bits LST and SYN not included in the
   status word.  LST is a client propertie, while SYN is a host
   property.  LST is lit when the key list is regenerated and signed and
   DIM when 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 never dim after that.

11.2.  Host State Variables

   Following is a list of state variables used by the server protocol.

   o  Host Name - The name of the host, by default the string returned
      by the Unix gethostname() library function.

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

   o  Host Key - The RSA public/private key pair used to encrypt/decrypt
      cookies.  This is also the default sign key.

   o  Sign Key - The RSA or DSA public/private key pair used to encrypt/
      decrypt signatures when the host key is not used for this purpose.

   o  Sign Digest - The message digest algorithm used to compute the
      signature before encryption.

   o  IFF Parameters - The parameters used in the optional IFF identity
      scheme described in Appendix B.

   o  GQ Parameters - The parameters used in the optional GQ identity
      scheme described in Appendix B.





Haberman & Mills         Expires August 28, 2008               [Page 27]

Internet-Draft                NTPv4 Autokey                February 2008


   o  MV Parameters - The parameters used in the optional MV identity
      scheme described in Appendix B.

   o  Server Seed - The private value hashed with the IP addresses to
      construct the cookie.

   o  Certificate Information Structure (CIS) - Certificates are used to
      construct certificate information structures (CIS) which are
      stored on the certificate cache.  The structure includes certain
      information fields from an X.509v3 certificate, together with the
      certificate itself encoded in ASN.1 syntax.  Each structure
      carries the public value timestamp and the filestamp of the
      certificate file where it was generated.  Elsewhere in this memo
      the CIS will not be distinguished from the certificate unless
      noted otherwise.  A flags field in the CIS determines the status
      of the certificate.  The field is encoded as follows:

      *  TRST (0x01) - 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 is lit
         when the CIS is constructed

      *  SIGN (0x02) - The certificate signature has been verified.  If
         the certificate is self-signed and verified using the contained
         public key, this bit is lit when the CIS is constructed.

      *  VALD (0x04) - The certificate is valid and can be used to
         verify signatures.  This bit is lit when a trusted certificate
         has been found on a valid certificate trail.

      *  PRIV (0x08) - 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 is lit when
         the CIS is constructed.

      *  ERRR (0x80) - The certificate is defective and not to be used
         in any way.

   o  Certificate List - CIS structures are stored on the certificate
      list in order of arrival, with the most recently received CIS
      placed first on the list.  The list is initialized with the CIS
      for the host certificate, which is read from the certificate file.
      Additional CIS entries are pushed on the list as certificates are
      obtained from the servers during the certificate exchange.  CIS
      entries are discarded if overtaken by newer ones or expire due to
      old age.





Haberman & Mills         Expires August 28, 2008               [Page 28]

Internet-Draft                NTPv4 Autokey                February 2008


   o  Host Certificate - The self-signed X.509v3 certificate for the
      host.  The subject and issuer fields consist of the host name,
      while the message digest/signature encryption scheme consists of
      the sign key and message digest defined above.  Optional
      information used in the identity schemes is carried in X.509v3
      extension fields compatible with [10].

   o  Public Key Values - The public encryption key for the COOKIE
      request, which consists of the public value of the host key.  It
      carries the public values timestamp and the filestamp of the host
      key file.

   o  Leapseconds Values.  The leapseconds values parsed from the NIST
      leapseconds file.  It carries the public values timestamp and the
      filestamp of the leapseconds values.

11.3.  Client State Variables (all modes)

   Following is a list of state variables used by the client association
   protocol in all modes.

   o  Association ID - The association ID used in responses.  It is
      assigned when the association is mobilized

   o  Server Association ID - The server association ID used in
      requests.  It is copied from the first nonzero association ID
      field in a response

   o  Server Subject Name - The server host name determined in the
      parameter exchange

   o  Server Issuer Name - The host name signing the certificate.  It is
      extracted from the current server certificate upon arrival and
      used to request the next item on the certificate trail

   o  Association Status Word - The host status word of the server
      determined in the parameter exchange

   o  Server Public Key - The public key used to decrypt signatures.  It
      is extracted from the first certificate received, which by design
      is the server host certificate

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

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




Haberman & Mills         Expires August 28, 2008               [Page 29]

Internet-Draft                NTPv4 Autokey                February 2008


   o  Group Key - A set of values used by the identification exchange.
      It identifies the cryptographic compartment shared by the server
      and client

   o  Receive Cookie Values - The cookie returned in a COOKIE response,
      together with its timestamp and filestamp

   o  Receive Autokey Values - The autokey values returned in an AUTO
      response, together with its timestamp and filestamp

11.4.  Server State Variables (broadcast and symmetric modes)

   Following is a list of server state variables used in broadcast and
   symmetric modes.

   o  Send Cookie Values - The cookie encryption values, signature and
      timestamps

   o  Send Autokey Values - The autokey values, signature and timestamps

   o  Key List - A sequence of key IDs starting with the autokey seed
      and each pointing to the next.  It is computed, timestamped and
      signed at the next poll opportunity when the key list becomes
      empty

   o  Current Key Number - The index of the entry on the Key List to be
      used at the next poll opportunity

11.5.  Protocol State Transitions

   The protocol state machine is very simple but robust.  The state is
   determined by the server status bits defined above.  The state
   transitions of the three dances are shown below.  The capitalized
   truth values represent the server status bits.  All server bits are
   initialized dark and are lit upon the arrival of a specific response
   message, as detailed above.

11.5.1.  Server Dance

   The server dance begins when the client sends an ASSOC request to the
   server.  It ends when the first signature is verified and PRV is lit.
   Subsequent packets received without extension fields are validated by
   the autokey sequence.  An optional LEAP exchange updates the
   leapseconds values.  Note the order of the identity exchanges and
   that only the first one will be used if multiple schemes are
   available.  Note also that the SIGN and LEAP requests are not issued
   until the client has synchronized to a proventic source.




Haberman & Mills         Expires August 28, 2008               [Page 30]

Internet-Draft                NTPv4 Autokey                February 2008


           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 (SYN && !SIG)
                           /* signe exchange */
                           SIGN_request(Host_Certificate);
                   else if (SYN && LPF & !LPT)
                           /* leapseconds exchange */
                           LEAP_request;

           }

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

11.5.2.  Broadcast Dance

   The only difference between the broadcast and server dances is the
   inclusion of an autokey values exchange following the cookie
   exchange.  The broadcast dance begins when the client receives the
   first broadcast packet, which includes an ASSOC response with
   association ID.  The broadcast client uses the association ID to
   initiate a server dance in order to calibrate the propagation delay.

   The dance ends when the first signature is verified and PRV is lit.
   Subsequent packets received without extension fields are validated by
   the autokey sequence.  An optional LEAP exchange updates the



Haberman & Mills         Expires August 28, 2008               [Page 31]

Internet-Draft                NTPv4 Autokey                February 2008


   leapseconds values.  When the server generates a new key list, the
   server replaces the ASSOC response with an AUTO response in the 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 ASSOC response lights VAL,
   IFF, and SIG; the COOKIE response lights CKY and AUT; and the first
   valid signature lights PRV.

11.5.3.  Symmetric Dance

   The symmetric dance is intricately choreographed.  It begins when the
   active peer sends an ASSOC request to the passive peer.  The passive
   peer mobilizes an association and both peers step the same dance from



Haberman & Mills         Expires August 28, 2008               [Page 32]

Internet-Draft                NTPv4 Autokey                February 2008


   the beginning.  Until the active peer is synchronized to a proventic
   source (which could be the passive peer) and can sign messages, the
   passive peer loops waiting for the 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, it
   includes timestamped signatures with its messages.  The first thing



Haberman & Mills         Expires August 28, 2008               [Page 33]

Internet-Draft                NTPv4 Autokey                February 2008


   it does after lighting timestamps is dance the sign exchange so that
   the passive peer can survive the default identity exchange, if
   necessary.  This is pretty weird, since the passive peer will find
   the active certificate signed by its own public key.

   The passive peer, which has been stalled waiting for the active
   timestamps to light up, now mates the dance.  The initial value of
   the cookie is zero.  If a COOKIE response has not been received by
   either peer, the next message sent is a COOKIE request.  The
   recipient rolls a random cookie, lights CKY and returns the encrypted
   cookie.  The recipient decrypts the cookie and lights CKY.  It is not
   a protocol error if both peers happen to send a COOKIE request at the
   same time.  In this case both peers will have two values, one
   generated by itself and the other received from the other peer.  In
   such cases the working cookie is constructed as the EXOR of the two
   values.

   At the next packet transmission opportunity, either peer generates a
   new key list and sets LST to 1; however, there may already be an AUTO
   request queued for transmission and the rules say no more than one
   request in a packet.  When available, either peer sends an AUTO
   response and dims LST.  The recipient initializes the autokey values
   and lights LST and AUT.  Subsequent packets received without
   extension fields are validated by the autokey sequence.

   The above description assumes the active peer synchronizes to the
   passive peer, which itself is synchronized to some other source, such
   as a radio clock or another NTP server.  In this case, the active
   peer is operating 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.

11.6.  Error Recovery

   The Autokey protocol state machine 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.  This section describes how the
   protocol responds to reachability and timeout events which can occur
   due to such errors.

   A persistent NTP association is mobilized by an entry in the
   configuration file, while an ephemeral association is mobilized upon
   the arrival of a broadcast, manycast or symmetric active packet with
   no matching association.  Subsequently, a general reset reinitializes
   all association variables to the initial state when first mobilized.
   In addition, if the association is ephemeral, the association is
   demobilized and all resources acquired are returned to the system.



Haberman & Mills         Expires August 28, 2008               [Page 34]

Internet-Draft                NTPv4 Autokey                February 2008


   Every NTP association has two variables which maintain the liveness
   state of the protocol, the 8-bit reachability register defined in [7]
   and the watchdog timer, which is new in NTPv4.  At every poll
   interval the reachability register is shifted left, the low order bit
   is dimmed and the high order bit is lost.  At the same time the
   watchdog counter is incremented by one.  If an arriving packet passes
   all authentication and sanity checks, the rightmost bit of the
   reachability register is lit and the watchdog counter is set to zero.
   If any bit in the reachability register is lit, the server is
   reachable, otherwise it is unreachable.

   When the first poll is sent from an association, the reachability
   register and watchdog counter are zero.  If the watchdog counter
   reaches 16 before the server becomes reachable, a general reset
   occurs.  This resets the protocol and clears any acquired resources
   before trying again.  If the server was once reachable and then
   becomes unreachable, a general reset occurs.  In addition, if the
   watchdog counter reaches 16 and the association is persistent, the
   poll interval is doubled.  This reduces the network load for packets
   that are unlikely to elicit a response.

   At each state in the protocol the client expects a particular
   response from the server.  A request is included in the NTP packet
   sent at each poll interval until a valid response is received or a
   general reset occurs, in which case the protocol restarts from the
   beginning.  A general reset also occurs for an association when an
   unrecoverable protocol error occurs.  A general reset occurs for all
   associations when the system clock is first synchronized or the clock
   is stepped or when the server seed is refreshed.

   There are special cases designed to quickly respond to broken
   associations, such as when a server restarts or refreshes keys.
   Since the client cookie is invalidated, the server rejects the next
   client request and returns a crypto-NAK packet.  Since the crypto-NAK
   has no MAC, the problem for the client is to determine whether it is
   legitimate or the result of intruder mischief.  In order to reduce
   the vulnerability in such cases, the crypto-NAK, as well as all
   responses, is believed only if the result of a previous packet sent
   by the client and not a replay, as confirmed by the NTP on-wire
   protocol.  While this defense can be easily circumvented by a
   middleman, it does deflect other kinds of intruder warfare.

   There are a number of situations where some event happens that causes
   the remaining autokeys on the key list to become invalid.  When one
   of these situations happens, the key list and associated autokeys in
   the key cache are purged.  A new key list, signature and timestamp
   are generated when the next NTP message is sent, assuming there is
   one.  Following is a list of these situations:



Haberman & Mills         Expires August 28, 2008               [Page 35]

Internet-Draft                NTPv4 Autokey                February 2008


   1.  When the cookie value changes for any reason.

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

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

   4.  If a problem is detected when an entry is fetched from the key
       list.  This could happen if the key was marked non-trusted or
       timed out, either of which implies a software bug.

11.7.  Security Considerations

   This section discusses the most obvious security vulnerabilities in
   the various Autokey dances.  In 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.

11.8.  Protocol Vulnerability

   While the protocol has not been subjected to a formal analysis, a few
   preliminary assertions can be made.  In the client/server and
   symmetric dances the underlying NTP on-wire protocol is resistant to
   lost, duplicate and bogus packets, even if the clock is not
   synchronized, so the protocol is not vulnerable to a wiretapper
   attack.  A middleman attack, even if it could simulate a valid
   cookie, could not present a valid signature.

   In the broadcast dance the client begins with a volley in client/
   server mode to obtain the autokey values and signature, so has the
   same protection as in that mode.  When continuing in receive-only
   mode, a wiretapper cannot produce a key list with valid signed
   autokey values.  The most it can do is replay an old packet causing
   clients to repeat the autokey hash operations until exceeding the
   maximum key number.

   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



Haberman & Mills         Expires August 28, 2008               [Page 36]

Internet-Draft                NTPv4 Autokey                February 2008


   paradox is resolved by assuming the primary (stratum 1) servers are
   proventicated by external phenomenological means.

11.9.  Clogging Vulnerability

   A self-induced clogging incident cannot happen, since signatures are
   computed only when the data have changed and the data do not change
   very often.  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 is updated during
   a dance or the server seed is refreshed, which happens about once per
   day.

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

   In client/server and peer dances an encryption hazard exists when a
   wiretapper replays prior cookie request messages at speed.  There is
   no obvious way to deflect such attacks, as the server retains no
   state between requests.  Replays of cookie response messages are
   detected and discarded by the NTP on-wire protocol.

   In broadcast mode a client a decription hazard exists when a
   wiretapper replays autokey response messages at speed.  Once
   synchronized to a proventic source, a legitimate extension field with
   timestamp the same as or earlier than the most recently received of
   that type is immediately discarded.  This foils a middleman cut-and-
   paste attack using an earlier 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.

   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 will be discarded by the NTP on-wire
   protocol.  However, a legitimate crypto-NAK is sent if the server has
   just refreshed the server seed.  In this case the the client performs
   a general reset and restarts the protocol as expected.






Haberman & Mills         Expires August 28, 2008               [Page 37]

Internet-Draft                NTPv4 Autokey                February 2008


12.  IANA Considerations

   Any IANA registries needed?


13.  Acknowledgements

   ...


14.  References

14.1.  Normative References

   [1]   Burbank, J., "Network Time Protocol Version 4 Protocol And
         Algorithms Specification", draft-ietf-ntp-ntpv4-proto-08 (work
         in progress), November 2007.

14.2.  Informative References

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

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

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

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

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

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

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

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

   [10]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
         Public Key Infrastructure Certificate and Certificate



Haberman & Mills         Expires August 28, 2008               [Page 38]

Internet-Draft                NTPv4 Autokey                February 2008


         Revocation List (CRL) Profile", RFC 3280, April 2002.

   [11]  Schnorr, C., "Efficient signature generation for smart cards",
         1991.

   [12]  Stinson, D., "Cryptography - Theory and Practice", 1995.

   [13]  Guillou, L. and J. Quisquatar, "A "paradoxical" identity-based
         signature scheme resulting from zero-knowledge", 1990.

   [14]  Mu, Y. and V. Varadharajan, "Robust and secure broadcasting",
         2001.

   [15]  Mills, D., ""Compouter Network Time Synchronization - the
         Network Time Protocol"", 2006.

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


Appendix A.  Timestamps, Filestamps and Partial Ordering

   When the host starts, it reads the host key and host certificate
   files, which are required for continued operation.  It also reads the
   sign key and leapseconds values, 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.  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.  It must not produce filestamps or timestamps until
   sunchronized to a proventic source.

   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:




Haberman & Mills         Expires August 28, 2008               [Page 39]

Internet-Draft                NTPv4 Autokey                February 2008


   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 filestamp
       must happen before the timestamp.  If not, 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 verify signatures if t --> B or E --> t, where t
       is the current proventic time.  Note that the public key
       previously extracted from the certificate continues to be valid
       for an indefinite time.  This raises the interesting possibility
       where a truechimer server with expired certificate or a
       falseticker with valid certificate are not detected until the
       client has synchronized to a proventic source.


Appendix B.  Identity Schemes

   There are five identity schemes in the NTPv4 reference
   implementation: (1) private certificate (PC), (2) trusted certificate
   (TC), (3) a modified Schnorr algorithm (IFF - Identify Friend or
   Foe), (4) a modified Guillou-Quisquater algorithm (GQ), and (5) a
   modified Mu-Varadharajan algorithm (MV).

   The PC scheme is intended for testing and development and not
   recommended for general use.  The TC scheme uses a certificate trail,
   but not an identity scheme.  The IFF, GQ and MV identity schemes use
   a cryptographically strong challenge-response exchange where an
   intruder cannot learn the group key, even after repeated observations



Haberman & Mills         Expires August 28, 2008               [Page 40]

Internet-Draft                NTPv4 Autokey                February 2008


   of multiple exchanges.  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 to the client.  The
   client performs a second mathematical operation to prove the server
   has the same group key as the client.

B.1.  Private Certificate (PC) Scheme

   The PC scheme shown in Figure Figure 12 uses a private certificate as
   the group key.


                             Trusted
                            Authority
              Secure     +-------------+    Secure
          +--------------| Certificate |-------------+
          |              +-------------+             |
          |                                          |
         \|/                                        \|/
   +-------------+                            +-------------+
   | Certificate |                            | Certificate |
   +-------------+                            +-------------+
       Server                                     Client


            Figure 12: Private Certificate (PC) Identity Scheme

   A certificate is designated private when the X509v3 Extended Key
   Usage extension field is present and contains "Private".  The private
   certificate is distributed to all other group members by secret
   means, so in fact becomes a symmetric key.  Private certificates are
   also trusted, so there is no need for a certificate trail or identity
   scheme.

B.2.  Trusted Certificate (TC) Scheme

   All other schemes involve a conventional certificate trail as shown
   in Figure Figure 13.













Haberman & Mills         Expires August 28, 2008               [Page 41]

Internet-Draft                NTPv4 Autokey                February 2008


                                                           Trusted
                   Host                 Host                 Host
              +-----------+        +-----------+        +-----------+
         +--->|  Subject  |   +--->|  Subject  |   +--->|  Subject  |
         |    +-----------+   |    +-----------+   |    +-----------+
   ...---+    |  Issuer   |---+    |  Issuer   |---+    |  Issuer   |
              +-----------+        +-----------+        +-----------+
              | Signature |        | Signature |        | Signature |
              +-----------+        +-----------+        +-----------+


            Figure 13: Trusted Certificate (TC) Identity Scheme

   As described in RFC-2510 [9], each certificate is signed by an issuer
   one step closer to the trusted host, which has a self-signed trusted
   certificate.  A certificate is designated trusted when an X509v3
   Extended Key Usage extension field is present and contains
   "trustRoot".  If no identity scheme is specified in the parameter
   exchange, this is the default scheme.

B.3.  Schnorr (IFF) Identity Scheme

   The IFF scheme is useful when the group key is concealed, so that
   client keys need not be protected.  The primary disacvantage is that
   when the server key is refreshed all hosts must update the client
   key.  The scheme shown in Figure Figure 14 involves a set of public
   parameters and a group key including both private and public
   components.  The public component is the client key.


                                     Trusted
                                    Authority
                                  +------------+
                                  | Parameters |
                       Secure     +------------+   Insecure
                    +-------------| Group Key  |-----------+
                    |             +------------+           |
                   \|/                                    \|/
              +------------+         Challenge       +------------+
              | Parameters |<------------------------| Parameters |
              +------------+                         +------------+
              |  Group Key |------------------------>| Client Key |
              +------------+         Response        +------------+
                  Server                                 Client


                 Figure 14: Schnorr (IFF) Identity Scheme




Haberman & Mills         Expires August 28, 2008               [Page 42]

Internet-Draft                NTPv4 Autokey                February 2008


   By happy coincidence, the mathematical principles on which IFF is
   based are similar to DSA.  The scheme is a modification an algorithm
   described in [11] and [12] p. 285.  The parameters are generated by
   routines in the OpenSSL library, but only the moduli p, q and
   generator g are used.  The p is a 512-bit prime, g a generator of the
   multiplicative group Z_p* and q a 160-bit prime that divides (p-1)
   and is a qth root of 1 mod p; that is, g^q = 1 mod p.  The TA rolls a
   private random group key b (0 < b < q), then computes public client
   key v = g^(q-b) mod p.  The TA distributes (p, q, g, b) to all
   servers using secure means and (p, q, g, v) to all clients not
   necessarily using secure means.

   The TA hides IFF parameters and keys in an OpenSSL DSA cuckoo
   structure.  The IFF parameters are identical to the DSA parameters,
   so the OpenSSL library can be used directly.  The structure shown in
   FigureFigure 15 is written to a file as a DSA private key encoded in
   PEM.  Unused structure members are set to one.


              +----------------------------------+-------------+
              |   IFF   |   DSA    |   Item      |   Include   |
              +=========+==========+=============+=============+
              |    p    |    p     | modulus     |    all      |
              +---------+----------+-------------+-------------+
              |    q    |    q     | modulus     |    all      |
              +---------+----------+-------------+-------------+
              |    g    |    g     | generator   |    all      |
              +---------+----------+-------------+-------------+
              |    b    | priv_key | group key   |   server    |
              +---------+----------+-------------+-------------+
              |    v    | pub_key  | client key  |   client    |
              +---------+----------+-------------+-------------+


                 Figure 15: IFF Identity Scheme Structure

   Alice challenges Bob to confirm identity using the following protocol
   exchange.

   1.  Alice rolls random r (0 < r < q) and sends to Bob.

   2.  Bob rolls random k (0 < k < q), computes y = k + br mod q and x =
       g^k mod p, then sends (y, hash(x)) to Alice.

   3.  Alice computes z = g^y * v^r mod p and verifies hash(z) equals
       hash(x).

   If the hashes match, Alice knows that Bob has the group key b.



Haberman & Mills         Expires August 28, 2008               [Page 43]

Internet-Draft                NTPv4 Autokey                February 2008


   Besides making the response shorter, the hash makes it effectively
   impossible for an intruder to solve for b by observing a number of
   these messages.  The signed response binds this knowledge to Bob's
   private key and the public key previously received in his
   certificate.

B.4.  Guillard-Quisquater (GQ) Identity Scheme

   The GQ scheme is useful when the server key must be refreshed from
   time to time without changing the group key.  The NTP utility
   programs include the GQ client key in the X509v3 Subject Key
   Identifier extension field.  The primary disadvantage of the scheme
   is that the group key must be protected in both the server and
   client.  A secondary disadvantage is that when a server key is
   refreshed, old extension fields no longer work.  The scheme is shown
   in Figure Figure 16a involves a set of public parameters and group
   key used to generate private server keys and client keys.


                                     Trusted
                                    Authority
                                  +------------+
                                  | Parameters |
                       Secure     +------------+   Secure
                    +-------------| Group Key  |-----------+
                    |             +------------+           |
                   \|/                                    \|/
              +------------+         Challenge       +------------+
              | Parameters |<------------------------| Parameters |
              +------------+                         +------------+
              |  Group Key |                         |  Group Key |
              +------------+         Response        +------------+
              | Server Key |------------------------>| Client Key |
              +------------+                         +------------+
                  Server                                 Client


                 Figure 16: Schnorr (IFF) Identity Scheme

   By happy coincidence, the mathematical principles on which GQ is
   based are similar to RSA.  The scheme is a modification of an
   algorithm described in [13] and [12] p. 300 (with errors).  The
   parameters are generated by routines in the OpenSSL library, but only
   the moduli p and q are used.  The 512-bit public modulus is n=pq,
   where p and q are secret large primes.  The TA rolls random large
   prime b (0 < b < n) and distributes (n, b) to all group servers and
   clients using secure means, since an intruder in possesion of these
   values could impersonate a legitimate server.  The private server key



Haberman & Mills         Expires August 28, 2008               [Page 44]

Internet-Draft                NTPv4 Autokey                February 2008


   and public client key are constructed later.

   The TA hides GQ parameters and keys in an OpenSSL RSA cuckoo
   structure.  The GQ parameters are identical to the RSA parameters, so
   the OpenSSL library can be used directly.  When generating a
   certificate, the server rolls random server key u (0 < u < n) and
   client key its inverse obscured by the group key v = (u^-1)^b mod n.
   These values replace the private and public keys normally generated
   by the RSA scheme.  The client key is conveyed in a X.509 certificate
   extension.  The updated GQ structure shown in Figure Figure 17 is
   written as an RSA private key encoded in PEM.  Unused structure
   members are set to one.


              +---------------------------------+-------------+
              |   GQ    |   RSA    |   Item     |   Include   |
              +=========+==========+============+=============+
              |    n    |    n     | modulus    |    all      |
              +---------+----------+------------+-------------+
              |    b    |    e     | group key  |    all      |
              +---------+----------+------------+-------------+
              |    u    |    p     | server key |   server    |
              +---------+----------+------------+-------------+
              |    v    |    q     | client key |   client    |
              +---------+----------+------------+-------------+


                  Figure 17: GQ Identity Scheme Structure

   Alice challenges Bob to confirm identity using the following
   exchange.

   1.  Alice rolls random r (0 < r < n) and sends to Bob.

   2.  Bob rolls random k (0 < k < n) and computes y = ku^r mod n and x
       = k^b mod n, then sends (y, hash(x)) to Alice.

   3.  Alice computes z = (v^r)*(y^b) mod n and verifies hash(z) equals
       hash(x).

   If the hashes match, Alice knows that Bob has the corresponding
   server key u.  Besides making the response shorter, the hash makes it
   effectively impossible for an intruder to solve for u by observing a
   number of these messages.  The signed response binds this knowledge
   to Bob's private key and the client key previously received in his
   certificate.





Haberman & Mills         Expires August 28, 2008               [Page 45]

Internet-Draft                NTPv4 Autokey                February 2008


B.5.  Mu-Varadharajan (MV) Identity Scheme

   The MV scheme is perhaps the most interesting and flexible of the
   three challenge/response schemes, but is devilishly complicated.  It
   is most useful when a small number of servers provide synchronization
   to a large client population where there might be considerable risk
   of compromise between and among the servers and clients.  The client
   population can be partitioned into a modest number of subgroups, each
   associated with an individual client key.

   The TA generates an intricate cryptosystem involving encryption and
   decryption keys, together with a number of activation keys and
   associated client keys.  The TA can activate and revoke individual
   client keys without changing the client keys themselves.  The TA
   provides to the servers an encryption key E and partial decryption
   keys g-bar and g-hat which depend on the activated keys.  The servers
   have no additional information and, in particular, cannot masquerade
   as a TA.  In addition, the TA provides to each client j individual
   partial decryption keys x-bar_j and x-hat_j, which do not need to be
   changed if the TA activates or deactivates any client key.  The
   clients have no further information and, in particular, cannot
   masquerade as a server or TA.

   The scheme uses an encryption algorithm similar to El Gamal
   cryptography and a polynomial formed from the expansion of product
   terms (x-x_1)(x-x_2)(x-x_3)...(x-x_n), as described in [14].  The
   paper has significant errors and serious omissions.  The cryptosystem
   is constructed so that, for every encrytion key E its iniverse is
   (g-bar^x-hat_j)(g-hat^x-bar_j) mod p for every j.  This remains true
   if both quantities are raised to the power k mod p.  The difficulty
   in finding E is equivalent to the descrete log problem.

   The scheme is shown in Figure Figure 18.  The TA generates the
   parameters, group key, server keys and client keys, one for each
   client, all of which must be protected to prevent theft of service.
   Note that only the TA has the group key, which is not known to either
   the servers or clients.  In this sense the MV scheme is a zero-
   knowledge proof.













Haberman & Mills         Expires August 28, 2008               [Page 46]

Internet-Draft                NTPv4 Autokey                February 2008


                                     Trusted
                                    Authority
                                  +------------+
                                  | Parameters |
                                  +------------+
                                  | Group Key  |
                                  +------------+
                                  | Server Key |
                       Secure     +------------+   Secure
                    +-------------| Client Key |-----------+
                    |             +------------+           |
                   \|/                                    \|/
              +------------+         Challenge       +------------+
              | Parameters |<------------------------| Parameters |
              +------------+                         +------------+
              | Server Key |------------------------>| Client Key |
              +------------+         Response        +------------+
                  Server                                 Client


              Figure 18: Mu-Varadharajan (MV) Identity Scheme

   The TA hides MV parameters and keys in OpenSSL DSA cuckoo structures.
   The MV parameters are identical to the DSA parameters, so the OpenSSL
   library can be used directly.  The structure shown in Figures below
   are written to files as a DSA private key encoded in PEM.  Unused
   structure members are set to one.  Figure Figure 19 shows the data
   structure used by the servers, while Figure Figure 20 shows the
   client data structure associated with each activation key.


              +---------------------------------+-------------+
              |   MV    |   DSA    |   Item     |   Include   |
              +=========+==========+============+=============+
              |    p    |    p     | modulus    |    all      |
              +---------+----------+------------+-------------+
              |    q    |    q     | modulus    |   server    |
              +---------+----------+------------+-------------+
              |    E    |    g     | private    |   server    |
              |         |          | encrypt    |             |
              +---------+----------+------------+-------------+
              |  g-bar  | priv_key | public     |   server    |
              |         |          | decrypt    |             |
              +---------+----------+------------+-------------+
              |  g-hat  | pub_key  | public     |   server    |
              |         |          | decrypt    |             |
              +---------+----------+------------+-------------+




Haberman & Mills         Expires August 28, 2008               [Page 47]

Internet-Draft                NTPv4 Autokey                February 2008


                   Figure 19: MV Scheme Server Structure



              +---------------------------------+-------------+
              |   MV    |   DSA    |   Item     |   Include   |
              +=========+==========+============+=============+
              |    p    |    p     | modulus    |    all      |
              +---------+----------+------------+-------------+
              | x-bar_j | priv_key | public     |   client    |
              |         |          | decrypt    |             |
              +---------+----------+------------+-------------+
              | x-hat_j | pub_key  | public     |   client    |
              |         |          | decrypt    |             |
              +---------+----------+------------+-------------+


                   Figure 20: MV Scheme Client Structure

   The devil is in the details, which are beyond the scope of this memo.
   The steps in generating the cryptosystem activating the keys and
   generating the partial decryption keys are in [15] page 170 ff.

   Alice challenges Bob to confirm identity using the following
   exchange.

   1.  Alice rolls random r (0 < r < q) and sends to Bob.

   2.  Bob rolls random k (0 < k < q) and computes the session
       encryption key E-prime = E^k mod p and partial decryption keys
       g-bar-prime = g-bar^k mod p and g-hat-prime = g-hat^k mod p.  He
       encrypts x = E-prime * r mod p and sends (x, g-bar-prime, g-hat-
       prime) to Alice.

   3.  Alice computes the session decryption key E^-1 = (g-bar-prime)^x-
       hat_j (g-hat-prime)^x-bar_j mod p and verifies that r = E^-1 x.


Appendix C.  ASN.1 Encoding Rules

   Certain value fields in request and response messages contain data
   encoded in ASN.1 distinguished encoding rules (DER).  The BNF grammar
   for each encoding rule is given below along with the OpenSSL routine
   used for the encoding in the reference implementation.  The object
   identifiers for the encryption algorithms and message digest/
   signature encryption schemes are specified in [16].  The particular
   algorithms required for conformance are not specified in this memo.




Haberman & Mills         Expires August 28, 2008               [Page 48]

Internet-Draft                NTPv4 Autokey                February 2008


C.1.  COOKIE request, IFF response, GQ response, MV response

   The value field of the COOKIE request message contains a sequence of
   two integers (n, e) encoded by the i2d_RSAPublicKey() routine in the
   OpenSSL distribution.  In the request, n is the RSA modulus in bits
   and e is the public exponent.

   RSAPublicKey ::= SEQUENCE {
           n ::= INTEGER,
           e ::= INTEGER
   }

   The IFF and GQ responses contain a sequence of two integers (r, s)
   encoded by the i2d_DSA_SIG() routine in the OpenSSL distribution.  In
   the responses, r is the challenge response and s is the hash of the
   private value.

   DSAPublicKey ::= SEQUENCE {
           r ::= INTEGER,
           s ::= INTEGER
   }

   The MV response contains a sequence of three integers (p, q, g)
   encoded by the i2d_DSAparams() routine in the OpenSSL library.  In
   the response, p is the hash of the encrypted challenge value and (q,
   g) is the client portion of the decryption key.

   DSAparameters ::= SEQUENCE {
           p ::= INTEGER,
           q ::= INTEGER,
           g ::= INTEGER
   }

C.2.  Certificates

   Certificate extension fields are used to convey information used by
   the identity schemes.  While the semantics of these fields generally
   conforms with conventional usage, there are subtle variations.  The
   fields used by Autokey Version 2 include:

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

   o  Key Usage.  This field defines the intended use of the public key
      contained in the certificate.  It contains the string



Haberman & Mills         Expires August 28, 2008               [Page 49]

Internet-Draft                NTPv4 Autokey                February 2008


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

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

   o  Subject Key Identifier.  This field contains the client identity
      key used in the GQ identity scheme.  It is present only if the GQ
      scheme is in use.

   The value field contains a X509v3 certificate encoded by the
   i2d_X509() routine in the OpenSSL distribution.  The encoding follows
   the rules stated in [10], including the use of X509v3 extension
   fields.

   Certificate ::= SEQUENCE {
           tbsCertificate                  TBSCertificate,
           signatureAlgorithm              AlgorithmIdentifier,
           signatureValue                  BIT STRING
   }

   The signatureAlgorithm is the object identifier of the message
   digest/signature encryption scheme used to sign the certificate.  The
   signatureValue is computed by the certificate issuer using this
   algorithm and 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 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



Haberman & Mills         Expires August 28, 2008               [Page 50]

Internet-Draft                NTPv4 Autokey                February 2008


   signatureAlgorithm.

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

   The notBefore and notAfter define the period of validity as defined
   in Appendix B.

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

   The AlgorithmIdentifier specifies the encryption algorithm for the
   subject public key.  The subjectPublicKey is the public key of 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 trusted host certificates the subject and issuer HostName is the
   NTP name of the group, while for all other host certificates the
   subject and issuer HostName is the NTP name of the host.  In the
   reference implementation if these names are not explicitly specified,
   they default to the 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 the host signing the
   certificate.










Haberman & Mills         Expires August 28, 2008               [Page 51]

Internet-Draft                NTPv4 Autokey                February 2008


Authors' Addresses

   Brian Haberman (editor)
   The Johns Hopkins University Applied Physics Laboratory
   11100 Johns Hopkins Road
   Laurel, MD  20723-6099
   US

   Phone: +1 443 778 1319
   Email: brian@innovationslab.net


   Dr. David L. Mills
   University of Delaware
   Newark, DE  19716
   US

   Phone: +1 302 831 8247
   Email: mills@udel.edu
































Haberman & Mills         Expires August 28, 2008               [Page 52]

Internet-Draft                NTPv4 Autokey                February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Haberman & Mills         Expires August 28, 2008               [Page 53]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/