RFC 5906
Network Time Protocol Version 4: Autokey Specification
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.
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
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.
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.
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
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.
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.
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.
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.
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
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.
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.
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.
* 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.
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.
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.
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
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.
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.
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
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)
