Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5906

Network Time Protocol Version 4: Autokey Specification

Pages: 58
Informational
Errata
Part 2 of 3 – Pages 19 to 39
First   Prev   Next

Top   ToC   RFC5906 - Page 19   prevText

7. 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 driver's 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 [RFC2875] is based on a ubiquitous 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. 1. The scheme must have a relatively long lifetime, certainly longer than a typical certificate, and have no specific lifetime or expiration date. At the time the scheme is used, the host has not yet synchronized to a proventic source, so the scheme cannot depend on time. 2. As the scheme can be used many times where the data might be exposed to potential intruders, the data must be either nonces or encrypted nonces. 3. The scheme should allow designated servers to prove identity to designated clients, but not allow clients acting as servers to prove identity to dependent clients.
Top   ToC   RFC5906 - Page 20
   4.  To the greatest extent possible, the scheme should represent a
       zero-knowledge proof; that is, the client should be able to
       verify that the server has the correct group key, but without
       knowing the key itself.

   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 (GQ)
   algorithm, and (5) a modified Mu-Varadharajan (MV) algorithm.  Not
   all of these provide the same level of protection and one, TC,
   provides no protection but is included for comparison.  The following
   is a brief 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 [RFC5280].  This is the default scheme when an identity
   scheme is not required.  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.

8. 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. In order to foil such attacks, every Autokey message carries a
Top   ToC   RFC5906 - Page 21
   timestamp in the form of the NTP seconds when it was created.  If the
   system clock is synchronized to a proventic source, a signature is
   produced with a 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 cryptographic values are created or
   modified, which is by design not very often.  Extension fields
   carrying these signatures are copied to messages as needed, but the
   signatures are not recomputed.  There are three signature types:

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

   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 a 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.
Top   ToC   RFC5906 - Page 22
   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 ensure 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.

9. Autokey Operations

The NTP protocol has three principal modes of operation: client/ server, symmetric, and broadcast and each has its own Autokey program, or dance. Autokey choreography is designed to be non- intrusive 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 assumes 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 that 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.
Top   ToC   RFC5906 - Page 23
   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
   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 ensures 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 can be. 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
Top   ToC   RFC5906 - Page 24
   and filestamp, where applicable.  Only if the packet has correct
   format, length, and message digest are cycles spent to verify the
   signature.

   There are currently eight Autokey requests and eight corresponding
   responses.  The NTP packet format is described in [RFC5905] and the
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|E|   Code    |  Field Type   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Association ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Filestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Value Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               /

   /                             Value                             \
   \                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Signature Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               /
   /                           Signature                           \
   \                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               /
   /                      Padding (if needed)                      \
   \                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 7: NTPv4 Extension Field Format

   While each extension field is zero-padded to a 4-octet (word)
   boundary, the entire extension is not word-aligned.  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.
Top   ToC   RFC5906 - Page 25
   One or more extension fields follow the NTP packet header and the
   last followed by the MAC.  The extension field parser initializes a
   pointer to the first octet beyond the NTP packet header and
   calculates the number of octets remaining to the end of the packet.
   If the remaining length is 20 (128-bit digest plus 4-octet key ID) or
   22 (160-bit digest plus 4-octet key ID), the remaining data are the
   MAC and parsing is complete.  If the remaining length is greater than
   22, an extension field is present.  If the remaining length is less
   than 8 or not a multiple of 4, a format error has occurred and the
   packet is discarded; otherwise, the parser increments the pointer by
   the extension field length and then uses the same rules as above to
   determine whether a MAC is present or another extension field.

   In Autokey the 8-bit Field Type field is interpreted as the version
   number, currently 2.  For future versions, values 1-7 have been
   reserved for Autokey; other values may be assigned for other
   applications.  The 6-bit Code field specifies the request or response
   operation.  There are two flag bits: bit 0 is the Response Flag (R)
   and bit 1 is the Error Flag (E); the Reserved field is 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 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.  Note that it is not
   necessarily a protocol error to send an unsolicited response with no
   matching request.  If the R bit is dim, the client sets the
   Association ID field to the client association ID, which the server
   returns for verification.  If the two values do not match, the
   response is discarded as if never sent.  If the R bit is lit, the
   Association ID field is set to the server association ID obtained in
   the initial protocol exchange.  If the Association ID field does not
   match any mobilized association ID, the request is discarded as if
   never sent.

   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 field and Signature Length field
   (which specifies the length of the Signature) are zero and the
   Signature field is absent.  Some request and error response messages
   carry no value or signature fields, so in these messages only the
   first two words (8 octets) are present.

   The Timestamp and Filestamp words carry the seconds field of an NTP
   timestamp.  The timestamp 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.
Top   ToC   RFC5906 - Page 26
   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.

   As in all other TCP/IP protocol designs, all data are sent in network
   byte order.  Unless specified otherwise in the descriptions to
   follow, the data referred to are stored in the Value field.  The
   Value Length field specifies the length of the data in the Value
   field.

10.1. No-Operation

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

10.2. Association Message (ASSOC)

An Association Message (Code 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 Autokey host name in the Value field. The response contains the server status word in the Filestamp field and the Autokey host name in the Value field. The Autokey host name is not necessarily the DNS host name. A valid response lights the ENAB bit and possibly others in the association status word. When multiple identity schemes are supported, the host status word determines which ones are available. In server and symmetric modes, the response status word contains bits corresponding to the supported schemes. In all modes, the scheme is selected based on the client identity parameters that are loaded at startup.

10.3. Certificate Message (CERT)

A Certificate Message (Code 2) is used in the certificate exchange to obtain a certificate by subject 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 H. 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 and lights the CERT bit in the association status word.
Top   ToC   RFC5906 - Page 27

10.4. Cookie Message (COOKIE)

The Cookie Message (Code 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 H. The response contains the cookie encrypted by the public key in the request. A valid response lights the COOKIE bit in the association status word.

10.5. Autokey Message (AUTO)

The Autokey Message (Code 4) is used to obtain the autokey values. The request contains no value for a client or the autokey values for a symmetric peer. The response contains two 32-bit words, the first is the final key ID, while the second is the index of the final key ID. A valid response lights the AUTO bit in the association status word.

10.6. Leapseconds Values Message (LEAP)

The Leapseconds Values Message (Code 5) is used to obtain the leapseconds values as parsed from the leapseconds table from the National Institute of Standards and Technology (NIST). The request contains no values. The response contains three 32-bit integers: first 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. A valid response lights the LEAP bit in the association status word.

10.7. Sign Message (SIGN)

The Sign Message (Code 6) requests that the server 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 H. The response contains the client certificate signed by the server private key. A valid response lights the SIGN bit in the association status word.

10.8. Identity Messages (IFF, GQ, MV)

The Identity Messages (Code 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 H. A valid response lights the VRFY bit in the association status word.
Top   ToC   RFC5906 - Page 28

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

The server implements a host status word, while each client implements an association status word. These 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 dance, while the high-order 16 bits specify the Numerical Identifier (NID) as generated by the OpenSSL library of the OID for one of the message digest/signature encryption schemes defined in [RFC3279]. The NID values for the digest/signature algorithms defined in RFC 3279 are as follows: +------------------------+----------------------+-----+ | Algorithm | OID | NID | +------------------------+----------------------+-----+ | pkcs-1 | 1.2.840.113549.1.1 | 2 | | md2 | 1.2.840.113549.2.2 | 3 | | md5 | 1.2.840.113549.2.5 | 4 | | rsaEncryption | 1.2.840.113549.1.1.1 | 6 | | md2WithRSAEncryption | 1.2.840.113549.1.1.2 | 7 | | md5WithRSAEncryption | 1.2.840.113549.1.1.4 | 8 | | id-sha1 | 1.3.14.3.2.26 | 64 | | sha-1WithRSAEncryption | 1.2.840.113549.1.1.5 | 65 | | id-dsa-wth-sha1 | 1.2.840.10040.4.3 | 113 | | id-dsa | 1.2.840.10040.4.1 | 116 | +------------------------+----------------------+-----+ Bits 24-31 are reserved for server use, while bits 16-23 are reserved for client 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. 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
Top   ToC   RFC5906 - Page 29
   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 bits as the dance proceeds.  Once enabled,
   these bits ordinarily never become dark unless a general reset occurs
   and the protocol is restarted from the beginning.

   The host status bits are defined as follows:

   o  ENAB (31) is lit if the server implements the Autokey protocol.

   o  LVAL (30) is lit if the server has installed leapseconds values,
      either from the NIST leapseconds file or from another server.

   o  Bits (28-29) are reserved - always dark.

   o  Bits 24-27 select which server identity schemes are available.
      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:

      *  none - Trusted Certificate (TC) Scheme (default).

      *  PC (27) Private Certificate Scheme.

      *  IFF (26) Schnorr aka Identify-Friendly-or-Foe Scheme.

      *  GQ (25) Guillard-Quisquater Scheme.

      *  MV (24) Mu-Varadharajan Scheme.

   o  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  CERT (23): Lit when the trusted host certificate and public key
      are validated.

   o  VRFY (22): Lit when the trusted host identity credentials are
      confirmed.

   o  PROV (21): Lit when the server signature is verified using its
      public key and identity credentials.  Also called the proventic
      bit elsewhere in this memo.  When enabled, signed values in
      subsequent messages are presumed proventic.
Top   ToC   RFC5906 - Page 30
   o  COOK (20): Lit when the cookie is received and validated.  When
      lit, key lists with nonzero cookies are generated; when dim, the
      cookie is zero.

   o  AUTO (19): Lit when the autokey values are received and validated.
      When lit, clients can validate packets without extension fields
      according to the autokey sequence.

   o  SIGN (18): Lit when the host certificate is signed by the server.

   o  LEAP (17): Lit when the leapseconds values are received and
      validated.

   o  Bit 16: Reserved - always dark.

   There are three additional bits: LIST, SYNC, and PEER not included in
   the association status word.  LIST is lit when the key list is
   regenerated and dim when the autokey values have been transmitted.
   This is necessary to avoid livelock under some conditions.  SYNC is
   lit when the client has synchronized to a proventic source and never
   dim after that.  PEER is lit when the server has synchronized, as
   indicated in the NTP header, and never dim after that.

11.2. Host State Variables

The following is a list of host state variables. Host Name: The name of the host, by default the string returned by the Unix gethostname() library function. In the reference implementation, this is a configurable value. Host Status Word: This word is initialized when the host first starts up. The format is described above. Host Key: The RSA public/private key pair used to encrypt/ decrypt cookies. This is also the default sign key. Sign Key: The RSA or Digital Signature Algorithm (DSA) public/private key pair used to encrypt/decrypt signatures when the host key is not used for this purpose. Sign Digest: The message digest algorithm used to compute the message digest before encryption.
Top   ToC   RFC5906 - Page 31
   IFF Parameters:      The parameters used in the optional IFF identity
                        scheme described in Appendix B.

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

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

   Server Seed:         The private value hashed with the IP addresses
                        and key identifier to construct the cookie.

   CIS:                 Certificate Information Structure.  This
                        structure includes certain information fields
                        from an X.509v3 certificate, together with the
                        certificate itself.  The fields extracted
                        include the subject and issuer names, subject
                        public key and message digest algorithm
                        (pointers), and the beginning and end of the
                        valid period in NTP seconds.

                        The certificate itself is stored as an extension
                        field in network byte order so it can be copied
                        intact to the message.  The structure is signed
                        using the sign key and carries the public values
                        timestamp at signature time and the filestamp of
                        the original certificate file.  The structure is
                        used by the CERT response message and SIGN
                        request and response messages.

                        A flags field in the CIS determines the status
                        of the certificate.  The field is encoded as
                        follows:

                        *  TRUST (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.
Top   ToC   RFC5906 - Page 32
                        *  VALID (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.

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

   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 host
                        certificate file.  Additional CIS entries are
                        added to the list as certificates are obtained
                        from the servers during the certificate
                        exchange.  CIS entries are discarded if
                        overtaken by newer ones.

                        The following values are stored as an extension
                        field structure in network byte order so they
                        can be copied intact to the message.  They are
                        used to send some Autokey requests and
                        responses.  All but the Host Name Values
                        structure are signed using the sign key and all
                        carry the public values timestamp at signature
                        time.

   Host Name Values:    This is used to send ASSOC request and response
                        messages.  It contains the host status word and
                        host name.

   Public Key Values:   This is used to send the COOKIE request message.
                        It contains the public encryption key used for
                        the COOKIE response message.

   Leapseconds Values:  This is used to send the LEAP response message.
                        It contains the leapseconds values in the LEAP
                        message description.
Top   ToC   RFC5906 - Page 33

11.3. Client State Variables (all modes)

The following is a list of state variables used by the various dances in all modes. Association ID: The association ID used in responses. It is assigned when the association is mobilized. Association Status Word: The status word copied from the ASSOC response; subsequently modified by the state machine. Subject Name: The server host name copied from the ASSOC response. Issuer Name: The host name signing the certificate. It is extracted from the current server certificate upon arrival and used to request the next host on the certificate trail. Server Public Key: The public key used to decrypt signatures. It is extracted from the server host certificate. Server Message Digest: The digest/signature scheme determined in the parameter exchange. Group Key: A set of values used by the identity exchange. It identifies the cryptographic compartment shared by the server and client. Receive Cookie Values: The cookie returned in a COOKIE response, together with its timestamp and filestamp. Receive Autokey Values: The autokey values returned in an AUTO response, together with its timestamp and filestamp. Send Autokey Values: The autokey values with signature and timestamps.
Top   ToC   RFC5906 - Page 34
   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.

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

11.4. Protocol State Transitions

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

11.4.1. Server Dance

The server dance begins when the client sends an ASSOC request to the server. The clock is updated when PREV is lit and the dance ends when LEAP is lit. In this dance, the autokey values are not used, so an autokey exchange is not necessary. Note that the SIGN and LEAP requests are not issued until the client has synchronized to a proventic source. Subsequent packets without extension fields are validated by the autokey sequence. This example and others assumes the IFF identity scheme has been selected in the parameter exchange.
Top   ToC   RFC5906 - Page 35
1       while (1) {
2               wait_for_next_poll;
3               make_NTP_header;
4               if (response_ready)
5                       send_response;
6               if (!ENB)             /* parameter exchange */
7                       ASSOC_request;
8               else if (!CERT)       /* certificate exchange */
9                       CERT_request(Host_Name);
10              else if (!IFF)        /* identity exchange */
11                      IFF_challenge;
12              else if (!COOK)       /* cookie exchange */
13                      COOKIE_request;
14              else if (!SYNC)       /* wait for synchronization */
15                      continue;
16              else if (!SIGN)       /* sign exchange */
17                      SIGN_request(Host_Certificate);
18              else if (!LEAP)       /* leapsecond values exchange */
19                      LEAP_request;
20              send packet;
21      }

                         Figure 9: Server Dance

   If the server refreshes the private seed, the cookie becomes invalid.
   The server responds to an invalid cookie with a crypto-NAK message,
   which causes the client to restart the protocol from the beginning.

11.4.2. Broadcast Dance

The broadcast dance is similar to the server dance with the cookie exchange replaced by the autokey values exchange. The broadcast dance begins when the client receives a broadcast packet including an ASSOC response with the server association ID. This mobilizes a client association in order to proventicate the source and calibrate the propagation delay. The dance ends when the LEAP bit is lit, after which the client sends no further packets. Normally, the broadcast server includes an ASSOC response in each transmitted packet. However, when the server generates a new key list, it includes an AUTO response instead. In the broadcast dance, extension fields are used with every packet, so the cookie is always zero and no cookie exchange is necessary. As in the server dance, the clock is updated when PREV is lit and the
Top   ToC   RFC5906 - Page 36
   dance ends when LEAP is lit.  Note that the SIGN and LEAP requests
   are not issued until the client has synchronized to a proventic
   source.  Subsequent packets without extension fields are validated by
   the autokey sequence.
1       while (1) {
2               wait_for_next_poll;
3               make_NTP_header;
4               if (response_ready)
5                       send_response;
6               if (!ENB)              /* parameters exchange */
7                       ASSOC_request;
8               else if (!CERT)        /* certificate exchange */
9                       CERT_request(Host_Name);
10              else if (!IFF)         /* identity exchange */
11                      IFF_challenge;
12              else if (!AUT)         /* autokey values exchange */
13                      AUTO_request;
14              else if (!SYNC)        /* wait for synchronization */
15                      continue;
16              else if (!SIGN)        /* sign exchange */
17                      SIGN_request(Host_Certificate);
18              else if (!LEAP)        /* leapsecond values exchange */
19                      LEAP_request;
20              send NTP_packet;
21      }

                       Figure 10: Broadcast Dance

   If a packet is lost and the autokey sequence is broken, the client
   hashes the current autokey until either it matches the previous
   autokey or the number of hashes exceeds the count given in the
   autokey values.  If the latter, the client sends an AUTO request to
   retrieve the autokey values.  If the client receives a crypto-NAK
   during the dance, or if the association ID changes, the client
   restarts the protocol from the beginning.

11.4.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 a three-way dance where each peer completes a parameter exchange with the other. Until one of the peers has synchronized to a proventic source (which could be the other peer) and can sign messages, the other peer loops waiting for a valid timestamp in the ensuing CERT response.
Top   ToC   RFC5906 - Page 37
1       while (1) {
2               wait_for_next_poll;
3               make_NTP_header;
4               if (!ENB)             /* parameters exchange */
5                       ASSOC_request;
6               else if (!CERT)       /* certificate exchange */
7                       CERT_request(Host_Name);
8               else if (!IFF)        /* identity exchange */
9                       IFF_challenge;
10              else if (!COOK && PEER) /* cookie exchange */
11                      COOKIE_request);
12              else if (!AUTO)       /* autokey values exchange */
13                      AUTO_request;
14              else if (LIST)        /* autokey values response */
15                      AUTO_response;
16              else if (!SYNC)       /* wait for synchronization */
17                      continue;
18              else if (!SIGN)       /* sign exchange */
19                      SIGN_request;
20              else if (!LEAP)       /* leapsecond values exchange */
21                      LEAP_request;
22              send NTP_packet;
23      }

                       Figure 11: Symmetric Dance

   Once a peer has synchronized to a proventic source, it includes
   timestamped signatures in its messages.  The other peer, which has
   been stalled waiting for valid timestamps, now mates the dance.  It
   retrieves the now nonzero cookie using a cookie exchange and then the
   updated autokey values using an autokey exchange.

   As in the broadcast dance, if a packet is lost and the autokey
   sequence broken, the peer hashes the current autokey until either it
   matches the previous autokey or the number of hashes exceeds the
   count given in the autokey values.  If the latter, the client sends
   an AUTO request to retrieve the autokey values.  If the peer receives
   a crypto-NAK during the dance, or if the association ID changes, the
   peer restarts the protocol from the beginning.

11.5. 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 that can occur due to such errors.
Top   ToC   RFC5906 - Page 38
   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 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.

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

   When the first poll is sent from an association, the reach register
   and unreach counter are set to zero.  If the unreach counter reaches
   16, the poll interval is doubled.  In addition, if association is
   persistent, it is demobilized.  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 man-in-
   the-middle, 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
Top   ToC   RFC5906 - Page 39
   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.  The following is a list of these situations:

   1.  When the cookie value changes for any reason.

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

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



(page 39 continued on part 3)

Next Section