draft-ietf-stime-ntpauth-01.txt   draft-ietf-stime-ntpauth-02.txt 
Network Working Group David L. Mills Internet Engineering Task Force David L. Mills
Internet Draft University of Delaware Internet Draft University of Delaware
Category: Standards Track Standards Track September 2001
Public-Key Cryptography for the Network Time Protocol Public key Cryptography for the Network Time Protocol
Version 1 Version 2
< draft-ietf-stime-ntpauth-02.txt >
Status of this Memorandum Status of this Memorandum
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other
may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material time. It is inappropriate to use Internet- Drafts as reference
or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. This document is an Internet-Draft. http://www.ietf.org/shadow.html. This document is an Internet-
Draft.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1]. document are to be interpreted as described in RFC-2119 [1].
1. Abstract 1. Abstract
This memorandum describes a scheme for authenticating servers to clients This memorandum describes a scheme for authenticating servers to
in the Network Time Protocol. It extends prior schemes based on clients using the Network Time Protocol. It extends prior schemes
symmetric-key cryptography to a new scheme based on public-key based on symmetric key cryptography to a new scheme based on public
cryptography. The new scheme, called Autokey, is based on the premiss key cryptography. The new scheme, called Autokey, is based on the
that the IPSEC schemes proposed by the IETF cannot be adopted intact, premiss that the IPSEC schemes proposed by the IETF cannot be adopted
since that would preclude stateless servers and severely compromise intact, since that would preclude stateless servers and severely
timekeeping accuracy. In addition, the IPSEC model presumes compromise timekeeping accuracy. In addition, the IPSEC model presumes
authenticated timestamps are always available; however, authenticated timestamps are always available; however,
cryptographically verified timestamps require interaction between the cryptographically verified timestamps require interaction between the
timekeeping function and authentication function in ways not yet timekeeping function and authentication function in ways not yet
considered in the IPSEC model. considered in the IPSEC model.
The main body of this memorandum contains a description of the security The main body of this memorandum contains a description of the
model, approach rationale, protocol design and vulnerability analysis. security model, approach rationale, protocol design and vulnerability
It obsoletes a previous report [11] primarily in the schemes for analysis. It obsoletes a previous report [11] primarily in the schemes
distributing public keys and related values. A detailed description of for distributing public keys and related values. A detailed
the protocol states, events and transition functions is included. description of the protocol states, events and transition functions is
Detailed packet formats and field descriptions are given in the included. Detailed packet formats and field descriptions are given in
appendix. A prototype of the Autokey design based on this memorandum has the appendix. A prototype of the Autokey design based on this
been implemented, tested and documented in the NTP Version 4 software memorandum has been implemented, tested and documented in the NTP
distribution for Unix, Windows and VMS at www.ntp.org. Version 4 software distribution for Unix, Windows and VMS at
www.ntp.org.
While not strictly a security function, the Autokey protocol also While not strictly a security function, the Autokey protocol also
provides means to securely retrieve a table of historic leap seconds provides means to securely retrieve a table of historic leap seconds
necessary to convert ordinary civil time (UTC) to atomic time (TAI) necessary to convert ordinary civil time (UTC) to atomic time (TAI)
where needed. The tables can be retrieved either directly from national where needed. The tables can be retrieved either directly from
time servers operated by NIST or indirectly through intervening servers. national time servers operated by NIST or indirectly through NTP and
intervening servers.
Changes Since the Preceeding Draft
There are a number of changes scattered through this memorandum to
clarify the presentation and add a few new features. Among the most
important:
1. An optional parameter negotiation message has been added to the Changes Since the Preceding Draft
protocol state machine. The values it may carry and the interpretation
of these values are not defined in this memorandum.
2. A preliminary value exchange has been added to begin the protocol This is a major rewrite of the previous draft. There are numerous
dance. This is necessary to avoid a vulnerability where unsolicited changes scattered through this memorandum to clarify the presentation
public key responses could clog the victim with needless signature and add a few new features. Among the most important:
cycles.
3. The value exchange, which is piggybacked on the association ID 1. The reference implementation now uses the OpenSSL cryptographic
message, supports a timestamp-based agreement scheme which floods the software library. Besides being somewhat faster than the older
latest version of the agreement parameters and leapseconds table. Using RSAref2.0 library, it supports several different message digest and
this scheme any one of a clique of trusted primary servers running signature encryption schemes.
symmetric modes with each other and broadcast or client/server modes
with the secondary server population can refresh these data at any time
and the refreshed data will update all older data everywhere in the NTP
subnet within one day.
4. An optional certificate retrieval operation has been added to the 2. The Autokey protocol and reference implementation support the
protocol state machine. While the operation has been implemented and Public Key Infrastructure (PKI), including X.500 certificates.
tested, the contents of the certificate itself have not been determined.
5. A couple of subtle livelock problems with symmetric mode and 3. The Autokey protocol has been redesigned to be simpler, more
broadcast mode were found and fixed. The problem with source addresses uniform and more robust. There is only one generic message format and
not yet bound has been fixed in the reference implementation. all requests can carry signed parameters.
6. The protocol descriptions and state diagrams have been updated. Some 4. Strong assertions are now possible about the authentication of
packet formats have been changed in minor ways. timestamps and filestamps. This makes correctness modeling more robust
and simplifies vulnerability assessment.
7. Provisions for the use of IPv6 addresses in calculating the autokey 5. Certain security potholes have been filled in, in particular the
have been added. cookie in client/server and symmetric modes is now encrypted.
8. Provisions for the use of arbitrary identification values to be used 6. The description of the protocol, its state variables, transition
in lieu or IP addresses in calculating the autokey have been added. function, inputs and outputs are simpler, less wordy and more amenable
to correctness modelling.
9. A simplified version of the protocol appropriate for SNTP clients is 7. Provisions have been made to handle cases when the endpoint
proposed; details to follow. addresses are changed, as in mobile IP.
Introduction Introduction
A distributed network service requires reliable, ubiquitous and A distributed network service requires reliable, ubiquitous and
survivable provisions to prevent accidental or malicious attacks on the survivable provisions to prevent accidental or malicious attacks on
servers and clients in the network or the values they exchange. the servers and clients in the network or the values they exchange.
Reliability requires that clients can determine that received packets Reliability requires that clients can determine that received packets
are authentic; that is, were actually sent by the intended server and are authentic; that is, were actually sent by the intended server and
not manufactured or modified by an intruder. Ubiquity requires that any not manufactured or modified by an intruder. Ubiquity requires that
client can verify the authenticity of any server using only public any client can verify the authenticity of any server using only public
information. Survivability requires protection from faulty information. Survivability requires protection from faulty
implementations, improper operation and possibly malicious clogging and implementations, improper operation and possibly malicious clogging
replay attacks with or without data modification. These requirements are and replay attacks with or without data modification. These
especially stringent with widely distributed network services, since requirements are especially stringent with widely distributed network
damage due to failures can propagate quickly throughout the network, services, since damage due to failures can propagate quickly
devastating archives, routing databases and monitoring systems and even throughout the network, devastating archives, routing databases and
bring down major portions of the network. monitoring systems and even bring down major portions of the network.
The Network Time Protocol (NTP) contains provisions to cryptographically The Network Time Protocol (NTP) contains provisions to
authenticate individual servers as described in the most recent protocol cryptographically authenticate individual servers as described in the
specification RFC-1305 [7]; however, that specification does not provide most recent protocol specification RFC-1305 [7]; however, that
a scheme for the distribution of cryptographic keys, nor does it provide specification does not provide a scheme for the distribution of
for the retrieval of cryptographic media that reliably bind the server cryptographic keys, nor does it provide for the retrieval of
identification credentials with the associated keys and related public cryptographic media that reliably bind the server identification
values. However, conventional key agreement and digital signatures with credentials with the associated private keys and related public
large client populations can cause significant performance degradations, values. However, conventional key agreement and digital signatures
especially in time critical applications such as NTP. In addition, there with large client populations can cause significant performance
are problems unique to NTP in the interaction between the authentication degradations, especially in time critical applications such as NTP. In
and synchronization functions, since each requires the other. addition, there are problems unique to NTP in the interaction between
the authentication and synchronization functions, since each requires
the other.
This memorandum describes a cryptographically sound and efficient This memorandum describes a cryptographically sound and efficient
methodology for use in NTP and similar distributed protocols. As methodology for use in NTP and similar distributed protocols. As
demonstrated in the reports and briefings cited in the references at the demonstrated in the reports and briefings cited in the references at
end of this memorandum, there is a place for Public-Key Infrastructure the end of this memorandum, there is a place for PKI and related
(PKI) and related schemes, but none of these schemes alone satisfies the schemes, but none of these schemes alone satisfies the requirements of
requirements of the NTP security model. The various key agreement the NTP security model. The various key agreement schemes [2, 5, 12]
schemes [2, 5, 12] proposed by the IETF require per-association state proposed by the IETF require per-association state variables, which
variables, which contradicts the principles of the remote procedure call contradicts the principles of the remote procedure call (RPC) paradigm
(RPC) paradigm in which servers keep no state for a possibly large in which servers keep no state for a possibly large client population.
client population. An evaluation of the PKI model and algorithms as An evaluation of the PKI model and algorithms as implemented in the
implemented in the rsaref2.0 package formerly distributed by RSA RSAref2.0 package formerly distributed by RSA Laboratories leads to
Laboratories leads to the conclusion that any scheme requiring every NTP the conclusion that any scheme requiring every NTP packet to carry a
packet to carry a PKI digital signature would result in unacceptably PKI digital signature would result in unacceptably poor timekeeping
poor timekeeping performance. performance.
A revised security model and authentication scheme called Autokey was A revised security model and authentication scheme called Autokey was
proposed in earlier reports [5, 6, 8]. It has been evolved and refined proposed in earlier reports [5, 6, 8]. It has been evolved and refined
since then and implemented in NTP Version 4 for Unix, Windows and VMS since then and implemented in NTP Version 4 for Unix, Windows and VMS
[11]. It is based on a combination of PKI and a pseudo-random sequence [11]. It is based on a combination of PKI and a pseudo-random sequence
generated by repeated hashes of a cryptographic value involving both generated by repeated hashes of a cryptographic value involving both
public and private components. This scheme has been tested and evaluated public and private components. This scheme has been tested and
in a local environment and is being deployed now in the CAIRN experiment evaluated in a local environment and in the CAIRN experiment network
network funded by DARPA. A detailed description of the security model, funded by DARPA. A detailed description of the security model, design
design principles and implementation experience is presented in this principles and implementation experience is presented in this
memorandum. memorandum. Additional information about NTP, including executive
summaries, software documentation, briefings and bibliography can be
found at www.eecis.udel.edu/~mills/ntp.htm. Additional information
about the reference implementation can be found at
www.eecis.udel.edu/~ntp/ntp_spool/html/authopt.htm.
Security Model Security Model
NTP security requirements are even more stringent than most other NTP security requirements are even more stringent than most other
distributed services. First, the operation of the authentication distributed services. First, the operation of the authentication
mechanism and the time synchronization mechanism are inextricably mechanism and the time synchronization mechanism are inextricably
intertwined. Reliable time synchronization requires cryptographic keys intertwined. Reliable time synchronization requires cryptographic keys
which are valid only over designated time intervals; but, time intervals which are valid only over designated time intervals; but, time
can be enforced only when all servers and clients are reliably intervals can be enforced only when participating servers and clients
synchronized to UTC. Second, the NTP subnet is hierarchical by nature, are reliably synchronized to UTC. Second, the NTP subnet is
so time and trust flow from the primary servers at the root through hierarchical by nature, so time and trust flow from the primary
secondary servers to the clients at the leaves. A client can claim servers at the root through secondary servers to the clients at the
authentic only if all servers on the path to the primary servers are leaves.
bone-fide authentic. In order to emphasize this requirement, in this
memorandum, the notion of "authentic" is replaced by "proventic", a noun A client can claim authentic to dependent applications only if all
new to English and derived from provenance, as in the provenance of a servers on the path to the primary servers are bone-fide authentic. In
painting. Having abused the language this far, the suffixes fixable to order to emphasize this requirement, in this memorandum the notion of
the various noun and verb derivatives of authentic will be adopted for "authentic" is replaced by "proventic", a noun new to English and
proventic as well. In NTP each server authenticates the next lower derived from provenance, as in the provenance of a painting. Having
stratum servers and proventicates the lowest stratum (primary) servers. abused the language this far, the suffixes fixable to the various noun
and verb derivatives of authentic will be adopted for proventic as
well. In NTP each server authenticates the next lower stratum servers
and proventicates the lowest stratum (primary) servers. Serious
computer linguists would correctly interpret the proventic relation as
the transitive closure of the authentic relation.
It is important to note that the notion of proventic does not
necessarily imply the time is correct. A client considers a server
proventic if it can validate its certificate and its apparent time is
within the valid interval specified on the certificate. The statement
"the client is synchronized to proventic sources" means that the
system clock has been set using the time values of one or more
proventic client associations and according to the NTP mitigation
algorithms. While a certificate authority must satisfy this
requirement when signing a certificate request, the certificate itself
can be stored in public directories and retrieved over unsecured
networks.
Over the last several years the IETF has defined and evolved the IPSEC Over the last several years the IETF has defined and evolved the IPSEC
infrastructure for privacy protection and source authentication in the infrastructure for privacy protection and source authentication in the
Internet, The infrastructure includes the Encapsulating Security Payload Internet, The infrastructure includes the Encapsulating Security
(ESP) [4] and Authentication Header (AH) [3] for IPv4 and IPv6. Payload (ESP) [4] and Authentication Header (AH) [3] for IPv4 and
Cryptographic algorithms that use these headers for various purposes IPv6. Cryptographic algorithms that use these headers for various
include those developed for the PKI, including MD5 message digests, RSA purposes include those developed for the PKI, including MD5 message
digital signatures and several variations of Diffie-Hellman key digests, RSA digital signatures and several variations of Diffie-
agreements. The fundamental assumption in the security model is that Hellman key agreements. The fundamental assumption in the security
packets transmitted over the Internet can be intercepted by other than model is that packets transmitted over the Internet can be intercepted
the intended receiver, remanufactured in various ways and replayed in by other than the intended receiver, remanufactured in various ways
whole or part. These packets can cause the client to believe or produce and replayed in whole or part. These packets can cause the client to
incorrect information, cause protocol operations to fail, interrupt believe or produce incorrect information, cause protocol operations to
network service or consume processor resources with needless fail, interrupt network service or consume precious processor
cryptographic calculations. resources.
In the case of NTP, the assumed goal of the intruder is to inject false In the case of NTP, the assumed goal of the intruder is to inject
time values, disrupt the protocol or clog the network or servers or false time values, disrupt the protocol or clog the network or servers
clients with spurious packets that exhaust resources and deny service to or clients with spurious packets that exhaust resources and deny
legitimate processes. The mission of the algorithms and protocols service to legitimate applications. The mission of the algorithms and
described in this memorandum is to detect and discard spurious packets protocols described in this memorandum is to detect and discard
sent by other than the intended sender or sent by the intended sender spurious packets sent by other than the intended sender or sent by the
but modified or replayed by an intruder. The cryptographic means of the intended sender, but modified or replayed by an intruder. The
reference implementation are based on the rsaref2.0 algorithms, but cryptographic means of the reference implementation are based on the
other algorithms with equivalent functionality could be used as well. It OpenSSL cryptographic software library available at www.openssl.org,
is important for distribution and export purposes that the way in which but other libraries with equivalent functionality could be used as
these algorithms are used precludes encryption of any data other than well. It is important for distribution and export purposes that the
incidental to the construction of digital signatures. way in which these algorithms are used precludes encryption of any
data other than incidental to the construction of digital signatures.
There are a number of defense mechanisms already built in the NTP There are a number of defense mechanisms already built in the NTP
architecture, protocol and algorithms. The fundamental timestamp- architecture, protocol and algorithms. The fundamental timestamp
exchange scheme is inherently resistant to replay attacks. The exchange scheme is inherently resistant to replay attacks. The
engineered clock filter, selection and clustering algorithms are engineered clock filter, selection and clustering algorithms are
designed to defend against Byzantine traitors and evil cliques. While designed to defend against evil cliques of Byzantine traitors. While
not necessarily designed to defeat determined intruders, these not necessarily designed to defeat determined intruders, these
algorithms and accompanying sanity checks have functioned well over the algorithms and accompanying sanity checks have functioned well over
years to deflect improperly operating but presumably friendly scenarios. the years to deflect improperly operating but presumably friendly
scenarios. However, these mechanisms do not securely identify and
However, these mechanisms do not securely identify and authenticate authenticate servers to clients. Without specific further protection,
servers to clients. Without specific further protection, an intruder can an intruder can inject any or all of the following mischiefs. Further
inject any or all of the following mischiefs. Further discussion on the discussion on the assumed intruder model is given in [9], but beyond
assumed intruder model is given in [9], but beyond the scope of this the scope of this memorandum.
memorandum.
1. An intruder can intercept and archive packets forever and can archive 1. An intruder can intercept and archive packets forever, as well as
all the public values ever generated and transmitted over the net. all the public values ever generated and transmitted over the net.
2. An intruder can generate packets faster than the server or client can 2. An intruder can generate packets faster than the server or client
process them, especially if they require expensive PKI operations. can process them, especially if they require expensive cryptographic
computations.
3. An intruder can intercept, modify and replay a packet. However, it 3. An intruder can originate, intercept, modify and replay a packet.
cannot permanently prevent the original packet transmission over the However, it cannot permanently prevent packet transmission over the
net; that is, it cannot break the wire, only congest it. net; that is, it cannot break the wire, only tell lies and congest it.
In this memorandum a distinction is made between a middleman attack,
where the intruder can modify and replace an intercepted packet, and a
wiretap attack, where the intruder can modify and replay the packet
only after the original packet has been received.
The following assumptions are fundamental to the Autokey design. They The following assumptions are fundamental to the Autokey design. They
are discussed at some length in the briefing slides and links at are discussed at some length in the briefing slides and links at
www.eecis.udel.edu/~mills/ntp.htm and will not be further discussed in www.eecis.udel.edu/~mills/ntp.htm and will not be further elaborated
this memorandum. in this memorandum.
1. The running times for public-key algorithms are relatively long and 1. The running times for public key algorithms are relatively long and
highly variable. In general, the performance of the synchronization highly variable. In general, the performance of the synchronization
function is badly degraded if these algorithms must be used for every function is badly degraded if these algorithms must be used for every
NTP packet. NTP packet.
2. In some modes of operation it is not feasible for a server to retain 2. In some modes of operation it is not feasible for a server to
cryptographic state variables for every client. It is however feasible retain state variables for every client. It is however feasible to
to regenerated them for a client upon arrival of a packet from that regenerated them for a client upon arrival of a packet from that
client. client.
3. The lifetime of cryptographic values must be enforced, which requires 3. The lifetime of cryptographic values must be enforced, which
a reliable system clock. However, the sources that synchronize the requires a reliable system clock. However, the sources that
system clock must be cryptographically proventicated. This circular synchronize the system clock must be cryptographically proventicated.
interdependence of the timekeeping and proventication functions requires This circular interdependence of the timekeeping and proventication
special handling. functions requires special handling.
4. All proventication functions must involve only public values 4. All proventication functions must involve only public values
transmitted over the net. Private values must never be disclosed beyond transmitted over the net. Private values must never be disclosed
the machine on which they were created. beyond the machine on which they were created.
5. Public keys and agreement parameters, where necessary, must be 5. Public encryption keys and certificates must be retrievable
retrievable directly from servers without requiring secured channels; directly from servers without requiring secured channels; however, the
however, the fundamental security of identification credentials and fundamental security of identification credentials and public values
public values bound to those credentials must eventually be a function bound to those credentials must be a function of external certificate
of certificate authorities and/or webs of trust. authorities and/or webs of trust.
Unlike the ssh security model, where the client must be securely Unlike the ssh security model, where the client must be securely
identified to the server, in NTP the server must be securely identified identified to the server, in NTP the server must be securely
to the client. In ssh each different interface address can be bound to a identified to the client. In ssh each different interface address can
different name, as returned by a reverse-DNS query. In this design be bound to a different name, as returned by a reverse-DNS query. In
separate public/private key pairs may be required for each interface this design separate public/private key pairs may be required for each
address with a distinct name. A perceived advantage of this design is interface address with a distinct name. A perceived advantage of this
that the security compartment can be different for each interface. This design is that the security compartment can be different for each
allows a firewall, for instance, to require some interfaces to interface. This allows a firewall, for instance, to require some
proventicate the client and others not. interfaces to proventicate the client and others not.
However, the NTP security model specifically assumes all time values and However, the NTP security model specifically assumes all time values
cryptoraphic values are public, so there is no need to associate each and cryptographic values are public, so there is no need to associate
interface with different cryptoraphic values. In the NTP design the host each interface with different cryptographic values. In other words,
name, as returned by the gethostname() library function, represents all there is one set of private secrets for the host, not one for each
interface addresses. Since at least in some host configurations the host interface. In the NTP design the host name, as returned by the
name may not be identifiable in a DNS query, the name must be either gethostname() Unix library function, represents all interface
addresses. Since at least in some host configurations the host name
may not be identifiable in a DNS query, the name must be either
configured in advance or obtained directly from the server using the configured in advance or obtained directly from the server using the
Autokey protocol. Autokey protocol.
Approach Approach
The Autokey protocol described in this memorandum is designed to meet The Autokey protocol described in this memorandum is designed to meet
the following objectives. Again, in-depth discussions on these the following objectives. Again, in-depth discussions on these
objectives is in the web briefings and will not be elaborated in this objectives is in the web briefings and will not be elaborated in this
memorandum. Note that here and elsewhere in this memorandum mention of memorandum. Note that here and elsewhere in this memorandum mention of
broadcast mode means multicast mode as well, with exceptions as noted. broadcast mode means multicast mode as well, with exceptions noted in
the web page at www.eecis.udel.edu/~ntp/ntp_spool/html/assoc.htm.
1. It must interoperate with the existing NTP architecture model and 1. It must interoperate with the existing NTP architecture model and
protocol design. In particular, it must support the symmetric-key scheme protocol design. In particular, it must support the symmetric key
described in RFC-1305. As a practical matter, the reference scheme described in RFC-1305. As a practical matter, the reference
implementation must use the same internal key management system, implementation must use the same internal key management system,
including the use of 32-bit key IDs and existing mechanisms to store, including the use of 32-bit key IDs and existing mechanisms to store,
activate and revoke keys. activate and revoke keys.
2. It must provide for the independent collection of cryptographic 2. It must provide for the independent collection of cryptographic
values and time values. A client is proventicated only when the all values and time values. A client is synchronized to a proventic source
cryptographic values have been obtained and verified and the NTP only when the required cryptographic values have been obtained and
timestamps have passed all sanity checks. verified and the NTP timestamps have passed all sanity checks.
3. It must not significantly degrade the potential accuracy of the NTP 3. It must not significantly degrade the potential accuracy of the NTP
synchronization algorithms. In particular, it must not make unreasonable synchronization algorithms. In particular, it must not make
demands on the network or host processor and memory resources. unreasonable demands on the network or host processor and memory
resources.
4. It must be resistant to cryptographic attacks, including 4. It must be resistant to cryptographic attacks, specifically those
replay/modification and clogging attacks. In particular, it must be identified in the security model above. In particular, it must be
tolerant of operation or implementation variances, such as packet loss tolerant of operational or implementation variances, such as packet
or misorder, or suboptimal configuration. loss or misorder, or suboptimal configurations.
5. It must build on a widely available suite of cryptographic 5. It must build on a widely available suite of cryptographic
algorithms, yet be independent of the particular choice. In particular, algorithms, yet be independent of the particular choice. In
it must not require data encryption other than incidental to signature particular, it must not require data encryption other than incidental
and verification functions. to signature encryption and cookie encryption operations.
6. It must function in all the modes supported by NTP, including 6. It must function in all the modes supported by NTP, including
client/server, broadcast and symmetric active/passive modes. client/server, broadcast and symmetric modes.
7. It must not require intricate per-client or per-server configuration 7. It must not require intricate per-client or per-server
other than the availability of public/private key files and agreement configuration other than the availability of the required
parameter files, as required. cryptographic keys and certificates.
8. The reference implementation must contain provisions to generate 8. The reference implementation must contain provisions to generate
cryptographic key values, including private/public keys and agreement cryptographic key files specific to each client and server.
parameters specific to each client and server. Eventually, it must Eventually, it must contain provisions to validate public values using
contain provisions to validate public values using certificate certificate authorities and/or webs of trust.
authorities and/or webs of trust.
Autokey Proventication Scheme Autokey Proventication Scheme
Autokey public-key cryptography is based on the PKI algorithms of the Autokey public key cryptography is based on the PKI algorithms
rsaref2.0 library, although other libraries with a compatible interface commonly used in the Secure Shell and Secure Sockets Layer
could be used as well. The reference implementation uses keyed-MD5 applications. As in these applications Autokey uses keyed message
message digests to detect packet modification, timestamped RSA digital digests to detect packet modification, digital signatures to verify
signatures to verify the source, and Diffie-Hellman key agreements to the source and public key algorithms to encrypt session keys or
construct a private shared key from public values. However, there is no cookies. What makes Autokey cryptography unique is the way in which
reason why alternative signature schemes and agreement algorithms could these algorithms are used to deflect intruder attacks while
be supported. What makes Autokey cryptography unique is the way in which maintaining the integrity and accuracy of the time synchronization
these algorithms are used to deflect intruder attacks while maintaining function.
the integrity and accuracy of the time synchronization function.
The NTP Version 3 symmetric-key cryptography uses keyed-MD5 message The NTP Version 3 symmetric key cryptography uses keyed-MD5 message
digests with a 128-bit private key and 32-bit key ID. In order to retain digests with a 128-bit private key and 32-bit key ID. In order to
backward compatibility, the key ID space is partitioned in two subspaces retain backward compatibility, the key ID space is partitioned in two
at a pivot point of 65536. Symmetric key IDs have given values less than subspaces at a pivot point of 65536. Symmetric key IDs have values
65536 and indefinite lifetime. Autokey key IDs have pseudo-random values less than the pivot and indefinite lifetime. Autokey key IDs have
equal to or greater than 65536 and are expunged immediately after use. pseudo-random values equal to or greater than the pivot and are
expunged immediately after use.
There are three Autokey protocol variants corresponding to each of the There are three Autokey protocol variants corresponding to each of the
three NTP modes: client/server, broadcast and symmetric active/passive. three NTP modes: client/server, broadcast and symmetric. All three
All three variants make use of a specially contrived session key called variants make use of specially contrived session keys, called
an autokey and a pseudo-random sequence of key IDs called the key list. autokeys, and a precomputed pseudo-random sequence of autokeys with
As in the original NTP Version 3 authentication scheme, the Autokey the key IDs saved in a key list. As in the original NTP Version 3
protocol operates separately for each association, so there may be authentication scheme, the Autokey protocol operates separately for
several key lists operating independently at the same time and with each association, so there may be several autokey sequences operating
distinct associated values and signatures. independently at the same time.
An autokey consists of four fields in network byte order as shown below: An autokey is computed from four fields in network byte order as shown
below:
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| Source IP | Dest IP | Key ID | Cookie | | Source IP | Dest IP | Key ID | Cookie |
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
For use with IPv4, the Source IP and Dest IP fields contain 32 bits; for
use with IPv6, these fields contain 128 bits. In either case the Key ID
and Cookie fields contain 32 bits. Thus, an IPv4 autokey has four 32-bit
words, while an IPv6 autokey has ten 32-bit words. The source and
destination IP addresses and key ID are public values visible in the
packet, while the cookie can be a public value or a private value,
depending on the mode.
There are some scenarios where the use of endpoint IP addresses when The four values are hashed by the MD5 message digest algorithm to
calculating the autokey may be difficult or impossible. These include produce the 128-bit key value, which in the reference implementation
configurations where Network Address Translation (NAT) devices are in is stored along with the key ID in a cache used for symmetric keys as
use or when addresses are changed during an association lifetime due to well as autokeys. Keys are retrieved from the cache by key ID using
mobility constraints. As described below, NTP associations are hash tables and a fast lookup algorithm.
identified by the endpoint IP addresses, so the natural approach is to
authenticate associations using these values. For scenarios where this
is not possible, an optional identification value can be used instead of
the endpoint IP addresses. The Parameter Negotiation message contains an
option to specify these data; however, the format, encoding and use of
this option are not specified in this memorandum. For the purposes of
this memorandum, the endpoint IP addresses will be assumed.
The NTP packet format has been augmented to include one or more The NTP packet format has been augmented to include one or more
extension fields piggybacked between the original NTP header and the extension fields piggybacked between the original NTP header and the
message authenticator code (MAC) at the end of the packet. For packets message authenticator code (MAC) at the end of the packet. For packets
without extension fields, the cookie is a private value computed by an without extension fields, the cookie is a shared private value
agreement algorithm. For packets with extension fields, the cookie has a conveyed in encrypted form. For packets with extension fields, the
default public value of zero, since these packets can be validated cookie has a default public value of zero, since these packets can be
independently using signed data in the extension fields. The four values validated independently using digital signatures.
are hashed by the message digest algorithm to produce the actual key
value, which is stored along with the key ID in a cache used for
symmetric keys as well as autokeys. Keys are retrieved from the cache by
key ID using hash tables and a fast algorithm.
The key list consists of a sequence of key IDs starting with a random For use with IPv4, the Source IP and Dest IP fields contain 32 bits;
value and each pointing to the next. To generate the next autokey on the for use with IPv6, these fields contain 128 bits. In either case the
key list, the next key ID is the first 32 bits in network byte order of Key ID and Cookie fields contain 32 bits. Thus, an IPv4 autokey has
the previous key value. It may happen that a newly generated key ID is four 32-bit words, while an IPv6 autokey has ten 32-bit words. The
less than 65536 or collides with another one already generated (birthday source and destination IP addresses and key ID are public values
event). When this happens, which should occur only rarely, the key list visible in the packet, while the cookie can be a public value or
is terminated at that point. The lifetime of each key is set to expire shared private value, depending on the mode.
one poll interval after its scheduled use. In the reference
implementation, the list is terminated when the maximum key lifetime is There are some scenarios where the use of endpoint IP addresses may be
about one hour. difficult or impossible. These include configurations where network
address translation (NAT) devices are in use or when addresses are
changed during an association lifetime due to mobility constraints.
For Autokey, the only restriction is that the addresses visible in the
transmitted packet must be the same as those used to construct the
autokey sequence and key list and that these addresses be the same as
those visible in the received packet. Provisions are included in the
reference implementation to handle cases when these addresses change,
as possible in mobile IP. For scenarios where the endpoint IP
addresses are not available, an optional public identification value
could be used instead of the addresses. Examples include the
Interplanetary Internet, where bundles are identified by name rather
than address. Specific provisions are for further study.
The key list consists of a sequence of key IDs starting with a 32-bit
random private value called the autokey seed. The associated autokey
is computed as above using the specified cookie and the first 32 bits
in network byte order of this value become the next key ID. Operations
continue in this way to generate the entire list, which may have up to
100 entries. It may happen that a newly generated key ID is less than
the pivot or collides with another one already generated (birthday
event). When this happens, which should occur only rarely, the key
list is terminated at that point. The lifetime of each key is set to
expire one poll interval after its scheduled use. In the reference
implementation, the list is terminated when the maximum key lifetime
is about one hour.
The index of the last key ID in the list is saved along with the next The index of the last key ID in the list is saved along with the next
key ID of that entry, collectively called the autokey values. The list key ID for that entry, collectively called the autokey values. The
is used in reverse order, so that the first key ID used is the last one list is used in reverse order, so that the first autokey used is the
generated. The Autokey protocol includes a message to retrieve the last one generated. The Autokey protocol includes a message to
autokey values and signature, so that subsequent packets can be retrieve the autokey values and signature, so that subsequent packets
authenticated using one or more hashes that eventually match the first can be validated using one or more hashes that eventually match the
key ID (valid) or exceed the index (invalid). This is called the autokey first key ID (valid) or exceed the index (invalid). This is called the
test in the following and is done for every packet, including those with autokey test in the following and is done for every packet, including
and without extension fields. In the reference implementation the most those with and without extension fields. In the reference
recent key ID received is saved for comparison with the first 32 bits in implementation the most recent key ID received is saved for comparison
network byte order of the next following key value. This minimizes the with the first 32 bits in network byte order of the next following key
number of hash operations in case a packet is lost. value. This minimizes the number of hash operations in case a packet
is lost.
The scheme used in client/server mode was suggested by Steve Kent over Autokey Operations
lunch. The server keeps no state for each client, but uses a fast
algorithm and a private value to regenerate the cookie upon arrival of a Autokey works differently in the various NTP modes. The scheme used in
client packet. The cookie is calculated in a manner similar to the client/server mode was suggested by Steve Kent over lunch some time
ago, but considerably modified since that meal. The server keeps no
state for each client, but uses a fast algorithm and a private random
value called the server seed to regenerate the cookie upon arrival of
a client packet. The cookie is calculated in a manner similar to the
autokey, but the key ID field is zero and the cookie field is the autokey, but the key ID field is zero and the cookie field is the
private value. The first 32 bits of the hash is the cookie used for the server seed. The first 32 bits of the hash is the cookie used for the
actual autokey calculation and is returned to the client on request. It actual autokey calculation by both the client and server. It is thus
is thus specific to each client separately and of no use to other specific to each client separately and of no use to other clients or
clients or an intruder. A client obtains the cookie and signature using an intruder.
the Autokey protocol and saves it for later use.
In client/server mode the cookie is a relatively weak function of the IP In previous versions of the Autokey protocol the cookie was
addresses and a server private value. The client uses the cookie and transmitted in clear on the assumption it was not useful to a
each key ID on the key list in turn to calculate the MAC for the next wiretapper other than to launch an ineffective replay attack. However,
NTP packet. The server calculates these values and checks the MAC, then an middleman could intercept the cookie and manufacture bogus messages
acceptable to the client. In order to reduce the vulnerability to such
an attack, the Autokey Version 2 server encrypts the cookie using a
public key supplied by the client. While requiring additional
processor resources for the encryption, this makes it effectively
impossible to spoof a cookie.
[Note in passing. In an attempt to avoid the use of overt encryption
operations, an experimental scheme used a Diffie-Hellman agreed key as
a stream cipher to encrypt the cookie. However, not only was the
protocol extremely awkward, but the processing time to execute the
agreement, encrypt the key and sign the result was horrifically
expensive - 15 seconds(!) in a vintage Sun IPC. This scheme was
quickly dropped in favor of generic public key encryption.]
In client/server mode the client uses the cookie and each key ID on
the key list in turn to retrieve the autokey and generate the MAC in
the NTP packet. The server uses the same values to generate the
message digest and verifies it matches the MAC in the packet. It then
generates the MAC for the response using the same values, but with the generates the MAC for the response using the same values, but with the
IP source and destination addresses exchanged. The client calculates and IP source and destination addresses exchanged. The client generates
checks the MAC and verifies the key ID matches the one sent. In this the message digest and verifies it matches the MAC in the packet. In
mode the sequential structure of the key list is not exploited, but order to deflect old replays, the client verifies the key ID matches
doing it this way simplifies and regularizes the implementation. the last one sent. In this mode the sequential structure of the key
list is not exploited, but doing it this way simplifies and
regularizes the implementation while making it nearly impossible for
an intruder to guess the next key ID.
In broadcast mode, clients normally do not send packets to the server, In broadcast mode clients normally do not send packets to the server,
except when first starting up to calibrate the propagation delay in except when first starting up to calibrate the propagation delay in
client/server mode. At the same time the client temporarily client/server mode. At the same time the client runs the Autokey
authenticates as in that mode. After obtaining and verifying the cookie, protocol as in that mode. After obtaining and verifying the cookie,
the client continues to obtain and verify the autokey values. To obtain the client continues to obtain and verify the autokey values. To
these values, the client must provide the ID of the particular server obtain these values, the client must provide the ID of the particular
association, since there can be more than one operating in the same server association, since there can be more than one operating in the
machine. For this purpose, the broadcast server includes the association same server. For this purpose, the NTP broadcast packet includes the
ID in every packet sent, except when sending the first packet after association ID in every packet sent, except when sending the first
generating a new key list, when it sends the autokey values instead. packet after generating a new key list, when it sends the autokey
values instead.
In symmetric mode each peer keeps state variables related to the other, In symmetric mode each peer keeps state variables related to the
so that a private cookie can be computed by a strong agreement other. A shared private cookie is conveyed using the same scheme as in
algorithm. The cookie itself is the first 32 bits of the agreed key. The client/server mode, except that the cookie is a random value. The key
key list for each direction is generated separately by each peer and list for each direction is generated separately by each peer and used
used independently, but each is generated with the same cookie. independently, but each is generated with the same cookie. There
exists a possible race condition where each peer sends a cookie
request message before receiving the cookie response from the other
peer. In this case, each peer winds up with two values, one it
generated and one the other peer generated. The ambiguity is resolved
simply by computing the working cookie as the exclusive-OR of the two
values.
The server proventic bit is set only when the cookie or autokey values, Once the client receives and validates the certificate, subsequent
depending on mode, and the associated timestamp and signature are all packets containing valid signed extension fields are presumed to
valid. If the bit is set, the client processes NTP time values; if the contain valid time values, unless these values fall outside the valid
bit is not set, extension field messages are processed in order to run interval specified on the certificate. However, unless the system
the Autokey protocol, but the NTP time values are ignored. Packets with clock has already been set by some other proventic means, it is not
old timestamps are discarded immediately while avoiding expensive known whether these values actually represent a truechime or falsetick
cryptographic algorithms. Bogus packets with newer timestamps must pass source. As the protocol evolves, the NTP associations continue to
the MAC and autokey tests, which is highly unlikely. accumulated time values until a majority clique is available to
synchronize the system clock. At this point the NTP intersection
algorithm culls the falsetickers from the population and the remaining
truechimers are allowed to discipline the clock.
Once the proventic bit has been set, the Autokey protocol is normally The time values for even falsetick sources form a proventic total
dormant. In all modes except broadcast server, packets are normally sent ordering relative to the applicable signature timestamps. This raises
without an extension field, unless the packet is the first one sent the interesting issue of how to mitigate between the timestamps of
different associations. It might happen, for instance, that the
timestamp of some Autokey message is ahead of the system clock by some
presumably small amount. For this reason, timestamp comparisons
between different associations and between associations and the system
clock are avoided, except in the NTP intersection and clustering
algorithms.
Once the Autokey values have been instantiated, the protocol is
normally dormant. In all modes except broadcast, 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 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 cookie or autokey values. If for some reason the client clock is
stepped, rather than slewed, all cryptographic and time values for all stepped, rather than slewed, all cryptographic and time values for all
associations are purged and the Autokey protocol restarted from scratch. associations are purged and the Autokey protocol restarted from
This insures that stale values never propagate beyond a clock step. scratch in all associations. This insures that stale values never
propagate beyond a clock step.
Public-Key Signatures Public Key Signatures and Timestamps
Since public-key signatures provide strong protection against While public key signatures provide strong protection against
misrepresentation of sources, probably the most obvious intruder misrepresentation of source, computing them is expensive. This invites
strategy is to deny or restrict service by replaying old packets with the opportunity for an intruder to clog the client or server by
signed cryptographic values in a cut-and-paste attack. The basis values replaying old messages or to originate bogus messages. A client
on which the cryptographic operations depend are changed often to receiving such messages might be forced to verify what turns out to be
deflect brute force cryptanalysis, so the client must be prepared to an invalid signature and consume significant processor resources.
abandon an old key in favor of a refreshed one. This invites the
opportunity for an intruder to clog the client or server by replaying
old Autokey messages or to invent bogus new ones. A client receiving
such messages might be forced to refresh the correct value from the
legitimate server and consume significant processor resources.
In order to foil such attacks, every extension field carries a timestamp In order to foil such attacks, every signed extension field carries a
in the form of the NTP seconds at the signature time. The signature timestamp in the form of the NTP seconds at the signature epoch. The
includes the timestamp itself together with optional additional data. If signature span includes the timestamp itself together with optional
the Autokey protocol has verified a proventic source and the NTP additional data. If the Autokey protocol has verified a proventic
algorithms have validated the time values, the system clock is source and the NTP algorithms have validated the time values, the
synchronized and signatures carry a nonzero (valid) timestamp. Otherwise system clock can be synchronized and signatures will then carry a
the system clock is unsynchronized and signatures carry a zero (invalid) nonzero (valid) timestamp. Otherwise the system clock is
timestamp. Extension fields with invalid or old timestamps are discarded unsynchronized and signatures carry a zero (invalid) timestamp.
before any values are used or signatures verified. Extension fields with invalid timestamps are discarded before any
values are used or signatures verified.
There are three signature types and six values to be signed: There are three signature types currently defined:
1. The public value is signed at the time of generation, which occurs 1. Cookie signature/timestamp: Each association has a cookie for use
when the system clock is first synchronized and about once per day after when generating a key list. The cookie value is determined along with
that in the reference implementation. Besides the public value, the the cookie signature and timestamp upon arrival of a cookie request
public key/host name, agreement parameters and leapseconds table are all message. The values are returned in a a cookie response message.
signed as well, even if their values have not changed. All four of these
values carry the same timestamp. On request, each of these values and
associated signatures and timestamps are returned in an extension field.
2. The cookie value is computed and signed upon arrival of a cookie 2. Autokey signature/timestamp: Each association has a key list for
request message. The response message contains the cookie, signature and generating the autokey sequence. The autokey values are determined
timestamp in an extension field. along with the autokey signature and timestamp when a new key list is
generated, which occurs about once per hour in the reference
implementation. The values are returned in a autokey response message.
3. The autokey values are signed when a new key list is generated, which 3. Public values signature/timestamp: The public key, certificate and
occurs about once per hour in the reference implementation. On request, leapsecond table values are signed at the time of generation, which
the autokey values, signature and timestamp are returned in an extension occurs when the system clock is first synchronized to a proventic
field. source, when the values have changed and about once per day after
that, even if these values have not changed. During protocol
operations, each of these values and associated signatures and
timestamps are returned in the associated request or response message.
While there are in fact three public value signatures, the values are
all signed at the same time, so there is only one public value
timestamp.
The most recent timestamp for each of the six values is saved for The most recent timestamp of each type is saved for comparison. Once a
comparison. Once a signature with valid timestamp has been received, valid signature with valid timestamp has been received, messages with
packets carrying extension fields with invalid timestamps or older valid invalid timestamps or earlier valid timestamps of the same type are
timestamps for the same value are discarded before the signature is discarded before the signature is verified. For signed messages this
verified. For packets containing signed extension fields, the timestamp
deflects replays that otherwise might consume significant processor deflects replays that otherwise might consume significant processor
resources; for other packets the Autokey protocol deflects message resources; for other messages the Autokey protocol deflects message
modification and replay. In addition, the NTP protocol itself is modification or replay by a wiretapper, but not necessarily by a
inherently resistant to replays and consumes only minimal processor middleman. In addition, the NTP protocol itself is inherently
resources. resistant to replays and consumes only minimal processor resources.
All cryptographic values used by the protocol are time sensitive and are
regularly refreshed. In particular, files containing cryptographic basis
values used by signature and agreement algorithms are regenerated from
time to time. It is the intent that file regeneration and loading of
these values occur without specific warning and without requiring
distribution in advance. While files carrying cryptographic data are not
specifically signed, the file names have extensions called filestamps
which reliably determine the time of generation. The filestamp for a
file is a string of decimal digits representing the NTP seconds at the
time the file was created.
As the data are forwarded from server to client, the filestamps are All cryptographic values used by the protocol are time sensitive and
preserved, including those for the public key/host name, agreement are regularly refreshed. In particular, files containing cryptographic
parameters and leapseconds table. Packets with older filestamps are basis values used by signature and encryption algorithms are
discarded befor the signature is verified. Filestamps can in principle regenerated from time to time. It is the intent that file
be used as a total ordering function to verify that the data are regenerations occur without specific advance warning and without
consistent and represent the latest available generation. For this requiring prior distribution of the file contents. While cryptographic
reason, the files should always be generated on a machine when the data files are not specifically signed, every file name includes an
system clock is valid. extension called the filestamp, which is a string of decimal digits
representing the NTP seconds at the generation epoch.
When a client or server initializes, it reads its own public and private Filestamps and timestamps can be compared in any combination and use
key files, which are required for continued operation. Optionally, it the same conventions. It is necessary to compare them from time to
reads the agreement parameters file and constructs the public and time to determine which are earlier or later. Since these quantities
private values to be used later in the agreement algorithm. Also have a granularity only to the second, such comparisons are ambiguous
optionally, it reads the leapseconds table file. When reading these if the values are the same. Thus, the ambiguity must be resolved for
files it checks the filestamps for validity; for instance, all each comparison operation as described below.
filestamps must be later than the time the UTC timescale was established
in 1972.
When the client first validates a proventic source and when the clock is It is important that filestamps be proventic data; thus, they cannot
stepped and when new cryptographic values are loaded from a server, the be produced unless the producer has been synchronized to a proventic
client recomputes all signatures and checks the filestamps for validity source. As such, the filestamps represent a total ordering of creation
and consistency with the signature timestmaps: epoches and serve as means to expunge old data and insure new data are
consistent. As the data are forwarded from server to client, the
filestamps are preserved, including those for certificate and
leapseconds files. Packets with older filestamps are discarded before
spending cycles to verify the signature.
1. If the system clock if valid, all timestamps and filestamps must be Autokey Dances
earlier than the current clock time.
2. All signature timestamps must be later than the public key timestamp. This section presents an overview of the three Autokey protocols,
called dances, corresponding to the NTP client/server, broadcast and
symmetric active/passive modes. Each dance is designed to be
nonintrusive and to require no additional packets other than for
regular NTP operations. The NTP protocol and Autokey dance operate
independently and simultaneously and use the same packets. When the
Autokey dance is over, subsequent packets are authenticated by the
autokey sequence and thus considered proventic as well. Autokey
assumes clients poll servers at a relatively low rate, such as once
per minute. In particular, it is assumed that a request sent at one
poll opportunity will normally result in a response before the next
poll opportunity.
3. In broadcast client mode, the cookie timestamp must be later than the The Autokey protocol data unit is the extension field, one or more of
autokey timestamp. which can be piggybacked in the NTP packet. An extension field
contains either a request with optional data or a response with data.
To avoid deadlocks, any number of responses can be included in a
packet, but only one request. A response is generated for every
request, even if the requestor is not synchronized or proventicated.
Some requests and most responses carry timestamped signatures. The
signature covers the data, timestamp and filestamp, where applicable.
Only if the packet passes all extension field tests is the signature
verified.
4. In symmetric modes the autokey timestamp must be later than the Dance Steps
public value timestamp.
5. Timestamps for each cryptographic data type must be later than the The protocol state machine is very simple. The state is determined by
filestamps for that type. nine bits, four provided by the server, five determined by the client
association operations. The nine bits are stored along with the
digest/signature scheme identifier in the host status word of the
server and in the association status word of the client. In all dances
the client first sends an Association request message and receives the
Association response specifying which cryptographic values the server
is prepared to offer and the digest/signature scheme it will use.
In the above constraints, note that timestamps and filestamps have a If compatible, the client installs the server status word as the
granularity of one second, so that a difference of zero seconds is association status word and sends a Certificate request message to the
ambiguous. Furthermore, timestamps and filestamps can be in error as server. The server returns a Certificate response including the
much as the value of the synchronization distance; that is, the sum of certificate and signature. The reference implementation requires the
the root dispersion plus one-half the root delay. However, the NTP certificate to be self-signed, which serves as an additional
protocol normally operates with polling intervals much longer than one consistency check. This check may be removed in future and replaced
second, so that successive timestamps for the same data type are with a certificate trail mechanism. If the certificate contents and
nonambiguous. On most machines, the processor time to generate a signature are valid, NTP timestamps in this and subsequent messages
complete set of key files is longer than one second, so it is not with valid signatures are considered proventic.
possible to generate two generations in the same second.
However, it may happen that agreement parameters files may be generated In client/server mode the client sends a Cookie request message
on two machines with the same filestamps, which creates an ordering including the public key of the host key. The server constructs the
ambiguity. The filestamps for leapseconds files should also be cookie as described above and encrypts it using this key. It sends a
nonambiguous, since these files are created by NIST not more often than Cookie response including the encrypted cookie to the client and
twice per year. While filestamp collisions should be so rare as to be expunges all values resulting from the calculations in order to remain
safely ignored, a good management approach might require that these stateless. The client verifies the signature and decrypts the cookie.
files be generated only on a schedule that guarantees that no more than A similar dance is used in symmetric modes, but the cookie is
one client or server generates a new key file set on any one day. generated as a random value.
Certificates The cookie is used to construct the key list and autokey values in all
modes. In client/server mode there is no need to provide these values
to the server, so once the cookie has been obtained the client can
generate the key list and validate succeeding packets directly. In
other modes the client retrieves the autokey values from the server
using an Autokey message exchange. Once these values have been
received, the client validates succeeding packets using the autokey
sequence as described previously.
PKI principles call for the use of certificates to reliably bind the A final exchange occurs when the server has the leapseconds table, as
server distinguished name (host name), public key and related values to indicated in the host status word. If so, the client obtains the table
each other. The certificate includes these values together with the and compares the filestamp with its own leapseconds table filestamp,
distinguished name of the certificate atuthority (CA) and other values if available. If the server table is newer than the client table, the
such as serial number and valid lifetime. These values are then signed client replaces its table with the server table. The client, acting as
by the CA using its private key. The Autokey protocol includes server, can now provide the most recent table to any of its own
provisions to obtain the certificate, but at the present time does dependent clients. In symmetric modes, this results in both peers
nothing with the values. A future version of the protocol is to include having the newest table.
provisions to validate the binding using procedures established by the
IETF.
Packet Processing Rules Status Words
Exhaustive examination of possible vulnerabilities at the various Each sever and client operating as a server implements a host status
processing steps of the NTP protocol as specified in RFC-1305 have word and an association status word with the format and content shown
resulted in a revised list of packet sanity tests. These tests have been below. The low order four host status bits are lit during host
formulated to harden the protocol against defective header and data initialization, depending on whether cryptographic data files are
values. These are summarized below, since they are an integral component present or not; the next four association bits are dark. There are two
of the NTP cryptograhic defense mechanism. There are eleven tests, additional bits implemented separately. The high order 16 bits specify
called TEST1 through TEST11 in the reference implementation, which are the message digest/signature encryption scheme.
performed in a specific order designed to gain maximum diagnostic
information while protecting against accidental or malicious errors.
The tests are divided into three groups. The first group is designed to The host status word is provided to clients in the Association
deflect access control and authentication violations. While access response message. The client initializes the association status word
control and message digest violations always result immediate discard, and then lights and dims the association bits as the dance proceeds.
it is necessary when first mobilizing an association to disable the
autokey test and certain timestamp tests. However, after the proventic
bit is set, all tests are enforced.
The second group of tests is designed to deflect packets from broken or 1 2 3
unsynchronized servers and replays. In order to synchronize an 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
association in symmetric modes, it is necessary to save the originate +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and receive timestamps in order to send them at a later time. This | | |L|K|C|A|L|S|E|E|
happens for the first packet that arrives, even if it violates the | Digest/Signature NID | Reserved |P|E|K|U|P|I|N|N|
autokey test. In the normal case, the second packet to arrive will be | | |T|Y|Y|T|F|G|C|B|
accepted and the association marked reachable. However, an agressive +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
intruder could replay old packets that could disrupt the saved
timestamps. This could not result in incorrect time values, but could
prevent a legitimate client from synchronizing the association.
The third group of tests is designed to deflect packets with invalid The host status bits are defined as follows:
header fields or time values with excessive errors. However, these tests
do not directly affect cryptographic source proventication or
vulnerability, so are beyond the scope of discussion in this document.
For packets containing signed extension fields additional tests apply, ENB - Lit if the server implements the Autokey protocol and is
depending on request type. There are the usual tests for valid extension prepared to dance.
field format, length and values. An instantiated variable, such as the
public key/host name, agreement paramaters, public value, cookie or
autokey values, is valid when the accompaning timestamp and filestamp
are valid. The public key must be instantiated before any signatures can
be verified. In symmetric modes the agreement parameters must be
instantiated before the public and private agreement values can be
determined; the public agreement value must be instantiated before the
agreement algorithm can be run to determine the cookie. In all modes the
cookie value must be determined before the key list can be generated.
The object of the Autokey dances described below is to set the proventic ENC - Lit if the server has loaded a valid encryption key file. This
bit. In client/server mode this bit is set when the cookie is validated. bit is normally lit, but can dim if an error occurs.
In other modes this bit is set when the autokey values are validated.
The bit is cleared initially and when the autokey test fails. If once
the bit is set and then cleared, the protocol will send an autokey
request message at the next poll opportunity and continue to send this
message until receiving valid autokey values or a general reset occurs.
This behavior is a compromise between protocol responsiveness, where the SIG - Lit if the server has loaded a valid signature key file. This
current association can be maintained without interruption, and protocol bit is included primarily for error supervision and can be either lit
vulnerability, where an intruder can repeatedly clog the receiver with or dim.
replays that cause the client to needlessly poll the server and refresh
the values.
Error Recovery LPF - Lit if the server has loaded a valid leapseconds file. This bit
can be either lit or dim.
The protocol state machine which drives the various Autokey functions The client association status bits are defined as follows:
includes provisions for various kinds of error conditions that can arise
due to missing files, corrupted data, protocol violation and packet loss
or misorder, not to mention hostile intrusion. There are two mechanisms
which maintain the liveness state of the protocol, the reachability
register defined in RFC-1305 and the watchdog timer, which is new in NTP
Version 4.
The reachability register is an 8-bit register that shifts left with AUT - Lit when the certificate is present and validated. When lit,
zero replacing the rightmost bit. A shift occurs for every poll signed values in subsequent messages are presumed proventic.
interval, whether or not a poll is actually sent. If an arriving packet
passes all authentication and sanity checks, the rightmost bit is set to
one. If any bit in this register is one, the server is reachable,
otherwise it is unreachable. If the server was once reachable and then
becomes unreachable, a general reset is performed. A general reset
reinitializes all association variables to the state when first
mobilized and returns all acquired resources to the system. In addition,
if the association is not configured, it is demobilized until the next
packet is received.
The watchdog timer increments for every poll interval, whether or not a CKY - Lit when the cookie is first received and validated.
poll is actually sent and regardless of the reachability state. The
counter is set to zero upon arrival of a packet from a proventicated
source, as determined by the Autokey protocol. In the reference
implementation, if the counter reaches 16 a general reset is performed.
In addition, if the association is configured, 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 KEY - Lit when the autokey values are first received and validated.
from the server. A request is included in the NTP message sent at every When lit, clients can validate packets without extension fields
poll interval until the authentic response is received or a general according to the autokey sequence.
reset occurs, in which case the protocol restarts from the beginning.
While this behavior might be considered rather conservative, the
advantage is that old cryptographic and time values can never persist
from one mobilization to the next.
There are a number of situations where some action on an association LPT - Lit when the leapseconds table is received and validated.
causes the remaining autokeys on the key list to become invalid. When
one of these situations happens, the key list and associated keys 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.
1. When the cookie value changes for any reason. An additional bit LST not part of the association status word lights
when the key list is regenerated and signed and dims when the autokey
values are transmitted. This is necessary to avoid livelock under some
conditions.
2. When a client switches from client/server mode to broadcast client An additional bit LBK not part of the association status word lights
mode. There is no further need for the key list, since the client will when the association transmit timestamp matches the packet originate
not transmit again. timestamp and dims otherwise. If lit, this confirms the packet was
received in response to one previously sent by this association.
3. When the poll interval is changed. In this case the calculated Host State Variables
expiration times for the keys become invalid.
4. When a general reset is performed. Host Name
The name of the host returned by the Unix gethostname() library
function. It must agree with the subject and issuer name in the
certificate.
5. If a problem is detected when an entry is fetched from the key list. Host Key
This could happen if the key was marked non-trusted or timed out, either The RSA key from the host key file and used to encrypt/decrypt
of which implies a software bug. cookies. It carries the public value timestamp and the filestamp at
the host key file creation epoch. This is also the signature key,
unless a signature key is specified.
6. When the cryptographic values are refreshed, the key lists for all Public Key
associations are regenerated. The public encryption key for the Cookie request message and derived
from the host key. It carries the public value timestamp and the
filestamp at the host key file creation epoch.
7. When the client is first proventicated or the system clock is Sign Key
stepped, the key lists for all associations are regenerated. The RSA or DSA key from the sign key file and used to encrypt
signatures. It carries the public value timestamp and the filestamp at
the sign key file creation epoch.
Autokey Protocols Certificate
The X.509 certificate from the certificate file. It carries the public
value timestamp and the filestamp at the certificate file creation
epoch.
This section describes the Autokey protocols supporting Leapseconds Table, Leapseconds Table Filestamp
cryptographically secure server proventication. There are three The NIST leapseconds table from the NIST leapseconds file. It carries
subprotocols, called dances, corresponding to the NTP client/server, the public value timestamp and the filestamp at the leapseconds file
broadcast and symmetric active/passive modes. While Autokey messages are creation epoch.
piggybacked in NTP packets, the NTP protocol assumes clients poll
servers at a relatively low rate, such as once per minute, and where
possible avoids large packets. In particular, it is assumed that a
request sent at one poll opportunity will normally result in a response
before the next poll opportunity.
It is important to observe that, while the Autokey dances are obtaining Digest/signature NID
and validating cryptographic values, the underlying NTP protocol The identifier of the message digest/signature encryption scheme
continues to operate. Most packets used during the dances contain derived from the sign key. It must agree with the NID on the
signatures, so the values can be believed even before the dance has certificate.
concluded. Since signatures are valid once the certificate has been
validated during the initial steps of the dance, by the time the Autokey
values are validated the clock is usually already set. In this way the
sometimes intricate Autokey dance interactions do not delay the
accumulation of time values that will eventually set the clock. Each
autokey dance is designed to be nonintrusive and to require no
additional packets other than for regular NTP operations. Therefore, the
phrase "some time later" in the descriptions applies to the next poll
opportunity.
The Autokey protocol data unit is the extension field, one or more of Client Association State Variables
which can be piggybacked in the NTP packet. An extension field contains
either a request with optional data or a response with data. To avoid
deadlocks, any number of responses can be included in a packet, but only
one request. Some requests and most responses are protected by
timestamped signatures. The signature covers the data, timestamp and
filestamp, where applicable. The timestamp is set to the default (zero)
when the sender is not proventicated; otherwise, it is set to the NTP
seconds when the signature was generated. The following rules are
designed to detect invalid header or data fields and to deflect clogging
attacks. Each extension field is validated in the following order and
discarded if:
1. The request or response code is invalid or the data field has Peer Association ID
incorrect length. The association ID of the peer as received in a response message.
2. The signature field is either missing or has incorrect length. Host Name
The name of the host returned by the Association response. It must
agree with the subject name in the certificate.
3. The public key is missing or has incorrect length. Digest/Signature NID
The identifier of the message digest/signature encryption scheme
returned in the Association response message. It must agree with the
value encoded in the certificate.
4. In the case of the agreement algorithm, the agreement parameterss are Public Values Timestamp
missing or have incorrect lengths. The timestamp returned by the latest Certificate response, Cookie
request or Leapseconds message.
5. The signature timestamp is earlier than the last received timestamp Certificate
of the same type or the two timestamps are equal and the proventic bit The X.509 certificate returned in the certificate response message,
is set.. together with its timestamp and filestamp.
6. Where applicable, the filestamp is earlier than the last received Cookie
filiestamp of the same type. The cookie returned in a Cookie response message, together with its
timestamp and filestamp.
Only if the extension field passes all the above tests is the signature Receive Autokey values
verified using PKI algorithms. Otherwise and in general, a response is The autokey values returned in an Autokey response message, together
generated for every request, even if the requestor is not proventicated. with its timestamp and filestamp.
However, some responses may have truncated data or signature fields
under certain conditions. If these fields are present and have correct
length, signatures are present and verifiable.
In the Autokey protocol every transmitted packet is associated with an Server Association State Variables (broadcast and symmetric modes)
autokey previously computed and stored in the key list. When the last
entry in the list is used, a new list is constructed as described above.
This requires knowledge of the cookie value. If for some reason the
cookie value is changed, the remaining entries in the key list are
purged and a new one constructed. However, if an extension field is
present, the current autokey is discarded and the autokey reconstructed
using a cookie value of zero.
A timestamp-based agreement protocol is used to manage the distribution Association ID
of the certificate, agreement parameters and leapseconds table. The The association ID of the server for use in client request messages.
association ID request and response messages include the certificate,
agreement and leapseconds bits from the system status word. one or more
of these bits are set when the associated data are present, either
loaded from local files or retrieved from another server at some earlier
time. If any of these bits are set in the association ID response to a
client in client/server mode or a peer in symmetric mode, the data are
requested from the server or peer and, once obtained, the bits are
reset. However, the response data are stored only if more recent than
the data already stored.
In the descriptions below, it is assumed that the client and server have Send Autokey Values
loaded their own private key and public key, as well as certificate, The autokey values, signature and timestamp.
agreement parameters and leapseconds table, where available. Public keys
for other servers, as well as the agreement parameters and leapseconds
table, can be loaded from local files or retrieved from any server.
Further information on generating and managing these files is in
Appendix B.
Preliminaries Key List
A sequence of key IDs starting with a random autokey seed and each
pointing to the next. It is computed timestamped and signed at the
next poll opportunity when the key list is empty.
The first thing the server needs to do is obtain the system status word, Autokey Seed
which reveals which cryptographic values the server is prepared to The private value used to initialize the key list. It is randomized
offer, and then the public key and certificate. These steps are for each new key list.
independent of which mode the server is operating in - client/server,
broadcast or symmetric modes.
The following pseudo-code describes the client state machine operations. Current Key Number
Note that the packet can one request and one or more responses. The The index of the entry on the Key List to be used at the next poll
machine requires the association ID, public key and optional opportunity.
certificate, in that order. While not further specified in this
memorandum, an optional parameter request message can be used to
negotiate algorithm identifiers, parameters and alternate identification
values. Note that the association ID response message also contains the
system status word, which contains the certificate bit.
if (response_pending) Send Encrypt Values (symmetric modes only)
send_response; The encrypted cookie, signature and timestamp computed upon arrival of
if (!parameters) the Cookie request message. These data are held until the next poll
request_parameters; opportunity.
if (!association_ID)
request_association_ID;
else if (!public_key)
request_public_key;
else if (certificate_bit)
request_certificate;
The following diagram shows the preliminary protocol dance. In this and Server seed
following diagrams the NTP packet type is shown above the arrow and the The private value hashed with the IP addresses to construct the cookie
extension field(s) message type shown below. Note that in the used in client/server mode. It is randomized when the public value
client/server mode the server responds immediately to the request, but signatures are refreshed.
in the symmetric modes the response may be delayed for a period up to
the current poll interval. The following cryptographic values are
instantiated by the dance:
public key server public key Autokey Messages
host name server host name
CA name certificate authority host name (optional)
filestamp generation time of public key file
secure bit set when the public key is stored and validated
server client There are currently five Autokey request types and five corresponding
| | responses. An abbreviated description of these messages is given
| NTP client | below; the detailed formats are described in Appendix A.
1 |<-----------------| mobilize client association; generate key list
| assoc ID req | with default cookie; send status word
| |
| NTP server |
2 |----------------->| store status word
| assoc ID rsp |
| |
| NTP client |
3 |<-----------------| request public key and host name
| key/name req |
| |
| NTP server |
4 |----------------->| store public key, host name, filestamp and
| key/name rsp | timestamp
| ... |
| |
| NTP client |
5 |<-----------------| request certificate
| certif req |
| |
| NTP server |
6 |----------------->| store certificate; verify credentials; set
| certif rsp | secure bit
| ... |
The dance begins when the client (or symmetric-active peer) on the right Association Message (1)
mobilizes an association, generates a key list using the default cookie The client sends the request to retrieve the host status word and host
and sends an association ID request message (1) to the server (or name. The server responds with these values.
symmetric-passive peer) on the left. The server responds with an
association ID response message (2) including the server association ID
and status word. To protect against a clogging attack, the transmit
timestamp in the NTP header in the request must be identical to the
originate timestamp in the response. The client retransmits request (1)
at every poll opportunity until receiving a valid response (2) or
association timeout.
Some time later the client sends a public key/host name request (3) to Certificate Message (2)
the server. The server responds with the requested data and associated The client sends the request to retrieve the server certificate. The
timestamp and filestamp (4). The client checks the timestamp and server responds with the certificate.
filestamp, verifies the signature and initializes the public key and
host name. If the certificate bit in the status word is zero, indicating
the server is not prepared to send one, and if the client concurs, the
secure bit is set at this time and the certificate exchange is bypassed.
The client retransmits request (3) at every poll opportunity until
receiving a valid response (4) or association timeout.
The public key/host name message can be interpreted as a poor-man's Cookie Message (3)
certificate, since it is signed and timestamped. However, strong The client sends the request, including the public member of the host
security requires a CA sign the host name and public key values and key, to retrieve the cookie. The server responds with the cookie
establish a period of validity for the signature. As an optional encrypted with the public key.
feature, the client sends a certificate request (5) to the server. The
server responds with the requested data and assciated timestamp and
filestamp (6). The response is signed by the CA's public key, so a
further step may be necessary to obtain the CA's certificate, which
contains its public key. The details for these additional steps are for
further study.
Since (4) is the first signed message received, the timestamp and Autokey Message (4)
filestamp have only marginal utility, but do serve to avoid messages The client sends the request to retrieve the autokey values, if
from unsynchronized servers and deflect replays. The interesting available. The server responds with these values.
question is whether to provide automatic update when the server makes a
new key generation, since the new generation would have a later
filestamp and instantly deprecate all cryptographic values with earlier
timestamps. This brings up the question of a distributed greeting
protocol, which may be a topic for future study. Meanwhile, the
reference implementation accepts only the first message received and
discards all others.
When the secure bit is set, data in packets with signatures are valid Leapseconds Message (5)
and the NTP protocol continues in parallel with the Autokey protocol. The client sends the request including its leapseconds table, if
available. The server responds with its own leapseconds table. Both
the client and server agree to use the version with the latest
filestamp.
Client/Server Modes (3/4) State Transitions
In client/server modes the server keeps no state variables specific to The state transitions of the three dances are shown below. The
each of possibly very many clients and mobilizes no associations. The capitalized truth values represent the association status word bits,
server regenerates a cookie for each packet received from the client. except for the SYNC value, which is true when the host is synchronized
For this purpose, the server hashes the cookie from the IP addresses and to a proventic source and false otherwise. All truth values are
private value with the key ID field set to zero, as described initialized false and become true upon the arrival of a specific
previously, then provides it to the client. Both the client and server response messages, as detailed in the above status bits description.
use the cookie to generate the autokey which validates each packet
received. To further strengthen the validation process, the client
selects a new key ID for every packet and verifies that it matches the
key ID in the server response to that packet.
Before proceeding to the full protocol description, it should be noted Client/Server Dance
that in the case of lightweight SNTP protocol associations, it is not
necessary to proceed beyond the preliminary protocol defined above. Most
if not all SNTP implementations send only a single client-mode packet
and expect only a single NTP server-mode packet in return. Since the
Autokey protocol is piggybacked in the NTP packet, the clock can be set
and the server authenticated with a single packet exchange if a
certificate is not required and in two exchanges if it is. Details of
this simplified protocol remain to be determined.
The following pseudo-code describes the client state machine operations. The client/server dance begins when the client sends an Association
The machine requires the association ID, public key, optional request message to the server. It ends upon arrival of the Cookie
certificate, cookie, autokey values and leapseconds table in that order, response, which lights the CKY and KEY bits. Subsequent packets
but the autokey values are required only if broadcast client mode. received without extension fields are validated by the autokey
sequence. An optional final exchange is possible to retrieve the
leapseconds table.
if (response_pending) while (1) {
wait_for_next_packet;
make_NTP_header;
if (response_ready)
send_response; send_response;
if (!cookie) if (!ENB)
request_cookie; send_Association_request;
else if (!autokey_values && broadcast_client)) else if (!CRF)
request_autokey_values; send_Certificate_request;
else if (!leapseconds_table) else if (!CKY)
request_leapseconds_table; send_Cookie_request;
else if (LPF & !LPT)
The following diagram shows the protocol dance in client/server mode. send_Leapseconds_request;
The following cryptographic values are instantiated by the dance: }
Broadcast Client Dance
public key server public key
host name server host name
filestamp generation time of public key file
timestamp signature time of public key/host name values
cookie cookie determined by the server for this client
timestamp signature time of cookie
proventic bit set when client clock is synchronized to source
server client
| |
| NTP client |
7 |<-----------------| request cookie
| cookie req |
| |
| NTP server |
8 |----------------->| store cookie and timestamp; set proventic bit;
| cookie rsp |
| ... |
| |
| NTP client |
9 |<-----------------| regenerate key list with server cookie
| |
| NTP server |
10 |----------------->|
| |
| continue |
= client/server =
The dance begins when the client on the right mobilizes an association
and validates the public key as in the preliminary dance above. Some
time later the client sends a cookie request (7). The server immediately
responds with the cookie and timestamp (8). The client checks the
timestamp, verifies the signature and initializes the cookie and cookie
timestamp, then sets the proventic bit. Since the cookie has changed,
the client regenerates the key list with this cookie when the next
packet is sent. The client retransmits request (7) at every poll
opportunity until receiving a valid response (8) or association timeout.
After successful verification, there is no further need for extension
fields, unless an error occurs or the server generates a new private
value. When this happens, the server fails to authenticate packet (9)
and, following the original NTP protocol, responds with a NAK packet
(10), which the client ignores. Eventually, an association timeout and
general reset occurs and the dance restarts from the beginning. Of
course, the NAK client could interpret the NAK message to restart the
protocol immediately and avoid the timeout. However, this invites the
opportunity for an intruder to destabilize the state machine with
spurious NAK messages.
Broadcast Mode (5)
In broadcast mode, packets are always sent with an extension field.
Since the autokey values for these packets use a well known default
cookie (zero), they can in principle be remanufactured with a new MAC
acceptable to the receiver; however, the key list provides the
authentication function as described earlier. The broadcast server keeps
no state variables specific to each of possibly very many clients and
mobilizes no associations for them.
The following pseudo-code describes the broadcast server state machine
operations. Each broadcast packet includes one response message
containing either the signed autokey values, if the first autokey on the
key list, or the association ID and status word otherwise. Note however,
when a broadcast client first comes up, the state machine also responds
to client requests as in client/server mode without affecting the
broadcast packets. Note that the association ID request and response
messages also contain the system status word.
if (new_list)
send_autokey_values;
else
send_association_ID;
The server on the left in the diagram below sends packets that are
received by each of a possibly large number of clients, one of which is
shown on the right. Ordinarily, clients do not send packets to the
server, except to calibrate the propagation delay and to obtain
cryptographic values such as the cookie and autokey values. The
following diagram shows the protocol dance in broadcast mode. The
following cryptographic values are instantiated by the dance:
public key server public key
host name server host name
filestamp generation time of public key file
timestamp signature time of public key/host name values
cookie cookie determined by the server for this client
timestamp signature time of cookie
autokey values initial key ID, initial autokey
timestamp signature time of autokey values
proventic bit set when client clock is synchronized to source
server client
| |
| NTP broadcast |
1 |----------------->| mobilize broadcast client association; set
| assoc ID rsp | initially to operate in client/server mode
| |
| ... | continue as in preliminary protocol above
| |
| NTP client |
7 |<-----------------| request cookie
| cookie req |
| |
| NTP server |
8 |----------------->| store cookie and timestamp
| cookie rsp |
| ... |
| |
| NTP client |
9 |<-----------------| regenerate key list with server cookie
| autokey req |
| |
| NTP server |
10 |----------------->| store autokey values and timestamp; set
| autokey rsp | proventic bit
| ... |
| |
| NTP client |
|<-----------------| continue to accumulate time values
| |
| NTP server |
|----------------->|
| |
| continue |
= volley =
| |
| NTP client |
|<-----------------|
| |
| NTP server |
|----------------->| set clock and propagation estimate; discard
| | remaining keys; switch to broadcast client mode
| continue |
= broadcast =
| |
| NTP broadcast |
|----------------->| server rolls new key list; client refreshes
| autokey rsp | autokey values
| |
= =
The server sends broadcast packets (1) continuously at intervals of
about one minute using the key list and regenerating the list as
required. The first packet sent after regenerating the list includes the
autokey values and signature; other packets include only the association
ID and status word.
The dance begins when the client on the right receives a broadcast
message (1). It mobilizes a broadcast client association set initially
to operate in client/server mode. It then continues to operate as in the
prelimiary protocol to obtain and validate the public key and host name
values. However, the client does not initiate the dance until some time
later (to avoid implosion at the server). However, in addition to the
status word, the association ID response includes the association ID of
the server, so the correct association, if more than one, can be
identified.
Some time later the client sends a cookie request (7). The server
immediately responds with the requested value (8). The client checks the
timestamp, verifies the signature and initializes the cookie and cookie
timestamp. Since the cookie has changed, the client regenerates the key
list with this cookie when the next packet is sent. The client
retransmits request (7) at every poll opportunity until receiving a
valid response (8) or association timeout.
If an autokey response happens to be in one of the server packets (1),
the client has stored the autokey values and autokey timestamp, so can
switch immediately to broadcast client mode and send no further packets.
Otherwise, some time later the client sends an autokey request (9). The
server immediately responds with the values (10). The client checks the
timestamp, verifies the signature and initializes the autokey values and
autokey timestamp and sets the proventic bit. The client retransmits
packet (9) until receiving a valid response (10) or association timeout.
After successful verification, there is no further need for extension
fields and the client can switch to broadcast client mode and send no
additional packets. However, it is the usual practice to send additional
client/server packets in order for the client mitigation algorithms to
refine the clock offset/delay estimates. When a sufficient number of
estimates are available, the client discards the cookie and remaining
keys on the key list, switches to broadcast client mode, calculates the
propagation delay and sets the clock.
When the server regenerates the key list, it sends an autokey response The broadcast client dance begins when the client receives the first
in the first packet, which allows the clients to validate it and reset broadcast packet, which includes an Association response with the
the autokey values. Unless this packet happens to be lost, the clients association ID. The broadcast client uses the association ID to
can continue with no further interaction with the server. Otherwise, the initiate a client/server dance in order to calibrate the propagation
client fails to authenticate the packets (1). Eventually, an association delay. The dance ends upon arrival of the Autokey response, which
timeout and general reset occurs and the dance restarts from the lights the KEY bit. Subsequent packets received without extension
beginning. fields are validated by the autokey sequence. An optional final
exchange is possible to retrieve the leapseconds table. When the
server generates a new key list, the server replaces the Association
response with an Autokey response in the first packet sent.
Symmetric Active/Passive Mode (1/2) while (1) {
wait_for_next_packet;
make_NTP_header;
if (response_ready)
send_response;
if (!ENB)
send_Association_request;
else if (!CRF)
send_Certificate_request;
else if (!CKY)
send_Cookie_request;
else if (!KEY)
send_Autokey_request;
else if (LPF & !LPT)
send_Leapseconds_request;
}
In symmetric modes there is no explicit client/server relationship, Symmetric Dance
since each peer in the relationship can operate as a server with the
other operating as a client. Which peer acts as the server depends on
which peer has the smallest root synchronization distance to its
ultimate reference source, and the choice may change from time to time.
This requirement results in a quite complex interaction between the
peers, especially when considering the many possibilities of failure and
recovery.
There are two protocol scenarios involving symmetric modes. The simplest The symmetric active dance begins when the active peer sends an
scenario is where both peers have configured associations that operate Association request to the passive peer. The passive peer mobilizes an
continuously in symmetric active mode and cryptographic values such as association and steps the same dance from the beginning. Until the
the public key/host name, certificate, agreement parameters and public active peer is synchronized to a proventic source (which could be the
value can be configured in advance. A more interesting scenario is when passive peer) and can sign messages, the passive peer will loop
a symmetric active peer with a configured association begins operation waiting to light the CRF bit and the active peer will skip the cookie
with a symmetric-passive peer initially without such an association. exchange.
The following pseudo-code describes the symmetric state machine Meanwhile, the active peer retrieves the certificate and autokey
operations. Note that the packet can contain one request and one or two values from the passive peer and lights the KEY bit. When for some
responses. The machine requires the association ID, public key, reason either peer generates a new key list, at the first opportunity
certificate, agreement parameters, agreement public value, autokey the peer sends the autokey values; that is, it pushes the values
values and leapseconds table in that order. There is a provision to send rather than pulls them. This is to prevent a possible deadlock where
the current autokey values when the peer has not requested them. This each peer is waiting for values from the other one.
happens when a peer first proventicates and recomputes the key list
using the agreed cookie.
if (response_pending) while (1) {
wait_for_next_packet;
make_NTP_header;
if (response_ready)
send_response; send_response;
if (!agreement_parameters) if (!ENB)
request_agreement_parameters; send_Association_request;
else if (!agreement) else if (!CRF)
send_agreement; send_Certificate_request;
else if (!autokey_values) else if (!CKY & SYNC)
request_autokey_values; send_Cookie_request;
else if (!new_list) else if (LST)
send_autokey_values; send_Autokey_response;
else if (!leapseconds_table) else if (!KEY)
request_leapseconds_table; send_Autokey_request;
else if (LPF & !LPT & SYNC)
send_Leapseconds_request;
}
The following diagrams show the protocol dance in symmetric Once the active peer has synchronized to a proventic source, it
active/passive mode. The dance in symmetric active/active mode is much includes timestamped signatures with its messages. The passive peer,
simpler and similar to two independent client/server modes, one for each which has been stalled waiting for the CRF bit to light and the active
direction, but with the cookie requests replaced by an agreement peer, which now finds the SYNC bit lit, continues their respective
algorithm. Note that in the following the NTP client header is replaced dances. The next message sent by either peer is a Cookie request. The
by the NTP symmetric active header and the NTP server header is replaced recipient rolls a random cookie, lights its CKY bit and returns the
by the NTP symmetric passive header. The following cryptographic values encrypted cookie in the Cookie response. The recipient decrypts the
are instantiated by each peer in the dance: cookie and lights its CKY bit.
public key server public key It is not a protocol error if both peers happen to send a cookie
host name server host name request at the same time. In this case both peers will have two
filestamp generation time of public key file values, one generated by one peer and the other received from the
timestamp signature time of public key/host name values other peer. In such cases the working cookie is constructed as the
exclusive-OR of the two values.
cookie cookie determined by the agreement algorithm At the next packet transmission opportunity, either peer generates a
timestamp signature time of cookie new key list and lights the LST bit; however, there may already be an
Autokey request queued for transmission and the rules say no more than
one request in a packet. When available, either peer sends an Autokey
response and clears the LST bit. The recipient initializes the autokey
values, clears the LST bit and lights the KEY bit. Subsequent packets
received without extension fields are validated by the autokey
sequence.
autokey values initial key ID, initial autokey The above description assumes the active peer synchronizes to the
timestamp signature time of autokey values 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.
proventic bit set when client clock is synchronized to source Key Refreshment
passive active About once per day the server seed is randomized and the signatures
| | recomputed. The operations are:
| NTP active |
1 |<-----------------| mobilize symmetric active association; generate
| assocID req | key list with default cookie; send status word
| |
| ... | continue as in preliminary protocol above
| |
| NTP passive |
2 |----------------->| store status word
| assoc ID rsp |
| |
| NTP active |
1 |<-----------------| generate key list with default cookie; request
| key/name req | passive key/name
| ... |
| |
| NTP passive |
2 |----------------->| verify passive credentials
| key/name rsp |
| key/name req |
| ... |
| |
| NTP active |
3 |<-----------------| send active key/name; request agreement
| key/name rsp | parameters
| param req |
| ... |
| |
| NTP passive |
4 |----------------->| store agreement parameters; and timestamp; set
| param rsp | proventic bit
| agree rsp |
| ... |
| |
| NTP active |
3 |<-----------------| send active key/name; request agreement
| key/name rsp | parameters
| param req |
| ... |
| |
| NTP passive |
4 |----------------->| store autokey values and timestamp; set
| key/name req | proventic bit
| autokey rsp |
| ... |
| |
| NTP active |
5 |<-----------------| continue to accumulate time values
| key/name rsp |
| |
= continue =
| |
| NTP passive |
6 |----------------->| set clock
| key/name req |
| |
| continue below |
= =
The dance begins when the active peer on the right generates a key list while (1) {
with default cookie and timestamp and sends a public key/host name wait_for_next_refresh;
request to the passive peer on the left (1). The passive peer checks its crank_random_generator;
access control list and (optionally) queries the DNS using the server IP generate_autokey_private_value;
address to obtain related cryptographic values. If successful, the peer if (!SYNC)
mobilizes an association in symmetric passive mode, but takes no further continue;
action until the next poll interval, as required by the NTP protocol. update_public_value_timestamp;
From this point the passive peer responds to requests, but otherwise compute_signatures;
ignores all time values until the active peer has set its clock and can }
provide valid timestamps.
Some time later the passive peer generates a key list with default Error Recovery
cookie and timestamp and sends its public key/host name values along
with a request for the public key/host name values of the active peer
(2). Subsequently, the active peer sends these values, but they are
ignored since the timestamps are invalid. Meanwhile, the active peer
checks the timestamp, verifies the signature and initializes the public
key/host name values, filestamp and timestamp. The active peer
retransmits request (1) at every poll opportunity until receiving a
valid response (2) or until association timeout.
Some time later the active peer sends the requested public key/host name The protocol state machine which drives the various Autokey operations
values along with an autokey request (3). The passive peer retransmits includes provisions for various kinds of error conditions that can
request (2) at every poll opportunity until receiving a valid timestamp arise due to missing files, corrupted data, protocol violations and
and verified signature or until association timeout. Since the cookies packet loss or misorder, not to mention hostile intrusion. There are
for each peer already have a common value and the active peer is two mechanisms which maintain the liveness state of the protocol, the
unsynchronized, it is pointless to run the agreement algorithm. reachability register defined in RFC-1305 and the watchdog timer,
which is new in NTP Version 4.
Some time later the passive peer sends the requested autokey values (4). The reachability register is an 8-bit register that shifts left with 0
The active peer checks the timestamp, verifies the signature and replacing the rightmost bit. A shift occurs for every poll interval,
initializes the autokey values and timestamp and sets the proventic bit. whether or not a poll is actually sent. If an arriving packet passes
At this point the active peer has authenticated the passive peer, but all authentication and sanity checks, the rightmost bit is set to 1.
may not have accumulated sufficient time values to set the clock and If any bit in this register is a 1, the server is reachable, otherwise
provide valid timestamps. Operation continues in rounds where the it is unreachable. If the server was once reachable and then becomes
passive peer requests the public key/host name values and the active unreachable, a general reset is performed. A general reset
peer returns them, but the passive peer ignores them. Eventually, the reinitializes all association variables to the state when first
active peer accumulates sufficient time values to set the clock. While mobilized and returns all acquired resources to the system. In
the cookie has not changed, the timestamp has, so the key list is addition, if the association is not configured, it is demobilized
regenerated with the default key (strictly speaking, only the signature until the next packet is received.
needs to be recomputed). The active peer is now proventicated, but the
passive peer has not yet authenticated the active peer.
Some understanding of the tricky actions to follow can be gained from The watchdog timer increments for every poll interval, whether or not
the observation that, up until this point every message received by the a poll is actually sent and regardless of the reachability state. The
active peer had a signed response field, so that the cookie value is the counter is set to zero upon arrival of a packet from a proventicated
default. However, at this point the active peer has all the source, as determined by the Autokey protocol. In the reference
cryptographic means at hand and does not need to request anything implementation, if the counter reaches 16 a general reset is
further from the passive peer. Thus, the passive peer sends nothing but performed. In addition, if the association is configured, the poll
requests and these are not signed or timestamped. Since the cryptograhic interval is doubled. This reduces the network load for packets that
security relies entirely on the autokey test, it is important that both are unlikely to elicit a response.
peers generate key lists with the same cookie.
The steps now taken are shown below with the active peer on the left and At each state in the protocol the client expects a particular response
the passive peer on the right. from the server. A request is included in the NTP message 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. In
some cases noted below, certain kinds of errors cause appropriate
action which avoids the somewhat lengthy timeout/restart cycle. While
this behavior might be considered rather conservative, the advantage
is that old cryptographic and time values can never persist from one
mobilization to the next.
active passive 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
| NTP active | these situations happens, the key list and associated autokeys in the
1 |----------------->| validate active peer, compute agreed key, key cache are purged. A new key list, signature and timestamp are
| key/name rsp | regenerate key list with peer key generated when the next NTP message is sent, assuming there is one.
| public req | Following is a list of these situations.
| |
| NTP passive |
2 |<-----------------| active computes agreed key, regenerates key
| public rsp | list with agreed key
| autokey req |
| ... |
| |
| NTP active |
3 |----------------->| set authentic
| autokey rsp |
| autokey req |
| ... |
| |
| NTP passive |
4 |<-----------------|
| autokey rsp |
| ... |
| |
| NTP active |
5 |----------------->| regular operation (no extension fields)
| ... |
| |
| NTP passive |
6 |<-----------------|
| |
| continue |
= active/passive =
The agreement parameters must have been previously obtained by at least 1. When the cookie value changes for any reason.
one of the peers, either directly from a file or indirectly from another
server running the Autokey protocol. A peer needing the parameters sends
an agreement parameters request to the other peer and that peer responds
with the requested data. This exchange, along with the leapseconds table
exchange, is similar to the public key/host name exchange, but not shown
here.
Once the proventic bit is set, the next message sent by the active peer 2. When a client switches from client/server mode to broadcast mode.
contains the public key/host name requested by the passive peer, but now There is no further need for the key list, since the client will not
with valid timestamp, plus a public value request containing the active transmit again.
peer public value (1). The passive peer checks the public key/host name
filestamp and timestamp, verifies the signature and initializes the
values. Optionally, it checks its access control list and queries the
DNS using the server IP address to obtain related cryptographic values.
Conceivably, the active peer could be found bogus at this time; what to
do in this case is for further study.
The passive peer next checks the public value request timestamp, 3. When the poll interval is changed. In this case the calculated
verifies the signature and runs the agreement algorithm to construct the expiration times for the keys become invalid.
shared cookie. Since the cookie has changed, the peer regenerates the
key list with this cookie when the next packet is sent.
Some time later the passive peer sends a public value response including 4. When a general reset is performed.
its own public value together with an autokey request (2). The active
peer checks the timestamp, verifies the signature and runs the agreement
algorithm to construct the shared cookie. Since the cookie has changed,
the peer regenerates the key list with this cookie when the next packet
is sent. The active peer retransmits the public value request (only) (1)
at every poll opportunity until receiving a valid response (2) or
association timeout.
Some time later the active peer sends its autokey values as requested 5. If a problem is detected when an entry is fetched from the key
together with an autokey request (3). The passive peer checks the list. This could happen if the key was marked non-trusted or timed
timestamp, verifies the signature, initializes the autokey values and out, either of which implies a software bug.
sets its proventic bit. The passive peer retransmits request (2) at
every poll opportunity until receiving a valid response (3) or
association timeout.
Some time later the passive peer sends its autokey values as requested 6. When the signatures are refreshed, the key lists for all
(4). The active peer checks the timestamp, verifies the signature, and associations are purged.
initializes the autokey values (the proventic bit is already set). The
active retransmits the autokey request (only) (3) until receiving a
valid response (4) or association timeout.
At this point both peers have completed the Autokey dance and each is 7. When the client is first synchronized or the system clock is
authenticated to the other. However, note that the NTP rules require a stepped, the key lists for all associations are purged.
peer operating at a lower stratum disregards time values from a hither
stratum peer; so, while the peers continue to exchange time values, the
values will not be used unless the passive server for some reason loses
its synchronization source.
After successful authentication, there is no further need for extension There are special cases designed to quickly respond to broken
fields, unless an error occurs or one of the peers generates new public associations, such as when a server restarts or refreshes keys. Since
values. The protocol requires that, if a peer receives a public value the client cookie is invalidated, the server rejects the next client
resulting in a different cookie, it must send its own public value. request and returns a crypto-NAK packet. Since the crypto-NAK has no
Since the autokey values are included in an extension field when a new MAC, the problem for the client is to determine whether it is
key list is generated, there is ordinarily no need to request these legitimate or the result of intruder mischief. In order to reduce the
values, unless one or the other peer restarts the protocol or the packet vulnerability to such mischief, the crypto-NAK is believed only if the
containing the autokey values is lost. Eventually, an association result of a previous packet sent by the client, as confirmed by the
timeout and general reset occurs and the dance restarts from the LBK status bit. This bit is lit in the NTP protocol if the packet
beginning. originate timestamp matches the association transmit timestamp. While
this defense can be easily circumvented by a middleman, it does
deflect other kinds of intruder warfare. The LBK bit is also used to
validate most responses and some requests as well.
Security Analysis Security Analysis
This section discusses the most obvious security vulnerabilities in the This section discusses the most obvious security vulnerabilities in
various modes and phases of operation. Throughout the discussion the the various Autokey dances. Throughout the discussion the
cryptographic algorithms themselves are assumed secure; that is, a cryptographic algorithms themselves are assumed secure; that is, a
successful brute force attack on the algorithms or public/private keys brute force cryptanalytic attack will not reveal the host private key
or agreement values is unlikely. However, vulnerabilities remain in the or sign private key or cookie value or server seed or autokey seed or
way the actual cryptographic data, including the cookie and autokey be able to predict the random generator values.
values, are computed and used.
While the protocol has not been subjected to a formal analysis, a few There are three tiers of defense against intruder attacks. The first
preliminary observations are warranted. The protocol cannot loop forever is a keyed message digest including a secret cookie conveyed in
in any state, since the association timeout and general reset insure encrypted form. A packet is discarded if the message digest does not
that the association variables will eventually be purged and the match the MAC. The second tier is the autokey sequence, which is
protocol will start from the beginning. A general reset is performed on generated by repeated hashes starting from a secret server seed and
all associations when the clock is first set and when it is stepped used in reverse order. While any receiver can authenticate a packet
after that. This purges all cryptographic values and time values relative to the last one received and by induction to a signed
dependent on unproventicated sources. extension field, as a practical matter a wiretapper cannot predict the
next autokey and thus cannot spoof a valid packet. The third tier is
timestamped signatures which reliably bind the autokey values to the
private key of a trusted server.
The first exchange in all protocol modes involves an association ID In addition to the three-tier defense strategy, all packets are
request and response cycle. Bits in the server status word indicate protected by the NTP sanity checks. Since NTP packets carry time
whether the server has the agreement paramters and/or leapseconds table. values, replays of old or bogus packets can be deflected once the
The association ID messages are not protected by a signature, so client has synchronized to proventic sources. Additional sanity checks
presumably an intruder can manufacture fake bits causing a client involving timestamps and filestamps are summarized in Appendix C.
livelock or deadlock condition. To protect against this vulnerability,
the transmit timestamp of the request is matched against the originate
timestamp of the response. The response is accepted only if the two
values match. An intruder is unlikely to predict the transmit timestamp,
which in this case is an effective nonce.
Once the clock is set, and except for the special cases summarized During the Autokey dances when extension fields are in use, the cookie
below, no old or duplicate values will be accepted in any state and an is a public value (0) rather than a shared private value. Therefore,
intruder cannot induce a clogging attack, since the MAC, autokey and an intruder can easily construct a packet with a valid MAC; however,
timestamp tests will discard packets before a clogging vulnerability is once the certificate is stored, extension fields carry timestamped
exposed. While significant vulnerabilities exist during the initial signatures and bogus packets are readily avoided. While most request
protocol states while the necessary values are being obtained, the most messages are unsigned, only the Association response message is
an intruder can do is prevent the protocol dance from completing. If it unsigned. This message is used in the first packet sent by a server or
does complete, it must complete correctly. peer and in most NTP broadcast packets.
The cryptographic values are always obtained in the same order and in A bogus Association response message can cause a client livelock or
the same order as the dependency relationships between them. No deadlock condition. However, these packets do not affect NTP time
cryptographic variables or time variables are instantiated unless the values and do not consume significant resources. To reduce the
server is proventic and proventicated. The public key and host name must vulnerability to bogus packets, the NTP transmit timestamp in the
be obtained first and no other messages are accepted until they have Association and Certificate request messages is used as a nonce. The
been obtained. The cookie must be obtained before the autokey values NTP server copies this value to the originate timestamp in the NTP
that depend on them, etc. Finally, in symmetric modes, both peers obtain header, so that the client can verify that the message is a response
cryptographic values in the same order, so deadlock cannot occur. to the original request. To minimize the possibility that an intruder
can guess the nonce, the client should fill in the low order unused
bits in the transmit timestamp with random values. In addition,
replays of all except Autokey response messages are discarded before
the signatures are verified.
In client/server and symmetric modes extension fields are no longer
needed after the Autokey dance has concluded. The client validates the
packet using the message digest and autokey sequence. A successful
middleman attack is unlikely, since without the server seed the
intruder cannot produce the cookie and without the cookie cannot
produce a valid MAC. In broadcast mode a wiretapper cannot synthesize
a valid packet without the autokey seed, so cannot manufacture an
bogus packet acceptable to the receiver. The most the intruder can do
is replay an old packet causing the client to repeat hash operations
until exceeding the maximum key number. On the other hand, a middleman
could do real harm by intercepting a packet, using the key ID to
generate a correct autokey and then synthesizing a bogus packet. There
does not seem to be a suitable solution for this as long as the server
has no per-client state.
A client instantiates cryptographic variables only if the server is
synchronized to a proventic source. A host does not sign values or
generate cryptographic data files unless synchronized to a proventic
source. This raises an interesting issue; how does a client generate
proventic cryptographic files before it has ever been synchronized to
a proventic source? Who shaves the barber if the barber shaves
everybody in town who does not shave himself? In principle, this
paradox is resolved by assuming the primary (stratum 1) servers are
proventicated by external phenomological means.
Cryptanalysis
Some observations on the particular engineering constraints of the Some observations on the particular engineering constraints of the
Autokey protocol are in order. First, the number of bits in some Autokey protocol are in order. First, the number of bits in some
cryptographic values are considerably smaller than would ordinarily be cryptographic values are considerably smaller than would ordinarily be
expected for strong cryptography. One of the reasons for this is the expected for strong cryptography. One of the reasons for this is the
need for compatibility with previous NTP versions; another is the need need for compatibility with previous NTP versions; another is the need
for small and constant latencies and minimal processing requirements. for small and constant latencies and minimal processing requirements.
Therefore, what the scheme gives up on the strength of these values must Therefore, what the scheme gives up on the strength of these values
be regained by agility in the rate of change of the cryptographic basis must be regained by agility in the rate of change of the cryptographic
values. Thus, autokeys are used only once and basis values are basis values. Thus, autokeys are used only once and basis values are
regenerated frequently. However, in most cases even a successful regenerated frequently. However, in most cases even a successful
cryptanalysis of these values compromises only a particular cryptanalysis of these values compromises only a particular
client/server association and does not represent a danger to the general client/server association and does not represent a danger to the
population. general population.
There are three tiers of defense against hostile intruder interference.
The first is the message authentication code (MAC) based on a keyed
message digest or autokey generated as the hash of the IP address
fields, key ID field and a special cookie, which can be public or the
result of an agreement algorithm. If the message digest computed by the
client does not match the value in the MAC, either the autokey used a
different cookie than the server or the packet was modified by an
intruder. Packets that fail this test are discarded without further
processing; in particular, without spending processor cycles on
expensive public-key algorithms.
The second tier of defense involves the key list, which is generated as
a repeated hash of autokeys and used in the reverse order. While any
receiver can authenticate a message by hashing to match a previous key
ID, as a practical matter an intruder cannot predict the next key ID and
thus cannot spoof a packet acceptable to the client. In addition,
tedious hashing operations provoked by replays of old packets are
suppressed because of the basic NTP protocol design. Finally, spurious
public-key computations provoked by replays of old packets with
extension fields are suppressed because of the signature timestamp
check.
The third tier of defense is represented by the Autokey protocol and
extension fields with timestamped signatures. The signatures are used to
reliably bind the autokey values to the private key of a trusted server.
Once these values are instantiated, the key list authenticates each
packet relative to its predecessors and by induction to the instantiated
autokey values.
In addition to the three-tier defense strategy, all packets are
protected by the NTP sanity checks. Since all packets carry time values,
replays of old or bogus packets can be deflected once the client has
synchronized to proventic sources. However, the NTP sanity checks are
only effective once the packet has passed all cryptographic tests. This
is why the signature timestamp is necessary to avoid expensive
calculations that might be provoked by replays. Since the signature and
verify operations have a high manufacturing cost, in all except
client/server modes the protocol design protects against a clogging
attack by signing cryptographic values only when they are created or
changed and not on request.
Specific Attacks
While the above arguments suggest that the vulnerability of the Autokey While the protocol has not been subjected to a formal analysis, a few
protocols to cryptanalysis is suitably hard, the same cannot be said preliminary assertions can be made. The protocol cannot loop forever
about the vulnerability to a replay or clogging attack, especially when in any state, since the association timeout and general reset insure
a client is first mobilized and has not yet proventicated. In the that the association variables will eventually be purged and the
following discussion a clogging attack is considered a replay attack at protocol restarted from the beginning. However, if something is
high speed which can clog the network and deny service to other network seriously wrong, the timeout/restart cycle could continue indefinitely
users or clog the processor and deny service to other users on the same until whatever is wrong is fixed.
machine. While a clogging attack can be concentrated on any function or
algorithm of the Autokey protocol, the must vulnerable target is the
public key routines to sign and verify public values. It is vital to
shield these routines from a clogging attack.
In all modes the cryptographic seed data used to generate cookies and Clogging Attacks
autokey values are changed from time to time. Thus, a determined
intruder could save old request and response packets containing these
values and replay them before or after the seed data have changed. Once
the client has proventicated, the client will detect replays due to the
old timestamp and discard the data. This is why the timestamp test is
done first and before the signature is computed. However, before this
happens, the client is vulnerable to replays whether or not they result
in clogging.
There are two vulnerabilities exposed in the protocol design: a sign There are two clogging vulnerabilities exposed in the protocol design:
attack where the intruder hopes to clog the victim with needless a sign attack where the intruder hopes to clog the victim server with
signature computations, and a verify attack where the intruder attempts needless signature computations, and a verify attack where the
to clog the victim with needless verification computations. The intruder attempts to clog the victim client with needless verification
reference implementation uses the RSA public key algorithms for both computations. Autokey uses public key encryption algorithms for both
sign and verify functions and these algorithms require significant signature and cookie encryption and these algorithms require
processor resources. significant processor resources.
In order to reduce the exposure to a sign attack, signatures are In order to reduce the exposure to a sign attack, signatures are
computed only when the data have changed. For instance, the autokey computed only when the data have changed. For instance, the autokey
values are signed only when the key list is regenerated, which happens values are signed only when the key list is regenerated, which happens
about once an hour, while the public values are signed only when the about once an hour, while the public values are signed only when the
agreement values are regenerated, which happens about once per day. values are refreshed, which happens about once per day. However, in
However, a server is vulnerable to a sign attack where the intruder can client/server mode the protocol precludes server state variables on
clog the server with cookie-request messages. The protocol design behalf of an individual client, so the cookie must be computed,
precludes server state variables stored on behalf of any client, so the encrypted and signed for every cookie response. Ordinarily, cookie
signature must be recomputed for every cookie request. Ordinarily, requests are seldom used, except when the server seed or public value
cookie requests are seldom used, except when the private values are signatures are refreshed. However, a determined intruder could replay
regenerated. However, a determined intruder could replay intercepted cookie requests at high rate, which may very well clog the server.
cookie requests at high rate, which may very well clog the server. There There appears no easy countermeasure for this particular attack.
appears no easy countermeasure for this particular attack.
The intruder might be more successful with a verify attack. Once the
client has proventicated, replays are detected and discarded before the
signature is verified. However, if the cookie is known or compromised,
the intruder can replace the timestamp in an old message with one in the
future and construct a packet with a MAC acceptable to a client, even if
it has bogus signature and incorrect autokey sequence. The packet passes
the MAC test, but then tricks the client to verify the signature, which
of course fails. What makes this kind of attack more serious is the fact
that the cookie used when extension fields are present is well known
(zero). Since all broadcast packets have an extension field, all the
intruder has to do is clog the clients with responses including
timestamps in the future. Assuming the intruder has joined the NTP
broadcast group, the attack could clog all other members of the group.
This attack can be deflected by the autokey test, which in the reference
implementation is after extension field processing, but this requires
very intricate protocol engineering and is left for a future refinement.
An interesting vulnerability in client/server mode is for an intruder to
replay a recent client packet with an intentional bit error. This could
cause the server to return the special NAK packet. A naive client might
conclude the server had refreshed its private value and so attempt to
refresh the server cookie using a cookie-request message. This results
in the server and client burning spurious machine cycles and invites a
clogging attack. This is why the reference implementation simply
discards all protocol and procedure errors and waits for timeout in
order to refresh the values. However, a more clever client may notice
that the NTP originate timestamp does not match the most recent client
packet sent, so can discard the bogus NAK immediately.
In broadcast and symmetric modes the client must include the association
ID in the Autokey request. Since association ID values for different
invocations of the NTP daemon are randomized over the 16-bit space, it
is unlikely that a very old packet would contain a valid ID value. An
intruder could save old server packets and replay them to the client
population with the hope that the values will be accepted and cause
general chaos. The conservative client will discard them on the basis of
invalid timestamp.
As mentioned earlier in this memorandum, an intruder could pounce on the A verify attack attempts to clog the receiver by provoking spurious
initial volley between peers in symmetric mode before both peers have signature verifications. The signature timestamp is designed to
determined each other reachable. In this volley the peers are vulnerable deflect replays of packets with old or duplicate extension fields
to an intruder using fake timestamps. The result can be that the peers before invoking expensive signature operations. A bogus signature with
never synchronize the timestamps and never completely mobilize their a timestamp in the future could do this, but the autokey sequence
associations. would detect this, since success would require cryptanalysis of both
the server seed and autokey seed.
Present Status and Unifinished Business Since the Certificate response is signed, a middleman attack will not
compromise the certificate data; however, a determined middleman could
hammer the client with intentionally defective Certificate responses
before a valid one could be received and force spurious signature
verifications, which of course would fail. An intruder could flood the
server with Certificate request messages, but the Certificate response
message is signed only once, so the result would be no worse than
flooding the network with spurious packets.
The Autokey protocol described in this memorandu has been implemented in An interesting vulnerability in client/server mode is for an intruder
the public software distribution for NTP Version 4 and has been tested to replay a recent client packet with an intentional bit error. This
in machines of either endian persuasion and both 32- and 64-bit could cause the server to return a crypto-NAK packet, which would then
architectures and kernels. Testing the implementation has been cause the client to request the cookie and result in a sign attack on
complicated by the many combinations of modes and failure/recovery the server. This results in the server and client burning spurious
mechanisms, including daemon restarts, key expiration, communication machine cycles and resulting in denial of service. As in other cases
failures and various management mistakes. The experience points up the mentioned previously, the NTP timestamp check greatly reduces the
fact that many little gotchas that are survivable in ordinary protocol likelihood of a successful attack.
designs become showstoppers when strong cryptographic assurance is
required.
The analysis, design and implementation of the Autokey protocol is In broadcast and symmetric modes the client must include the
basically mature; however, There are several remaining implementation association ID in the Autokey request. Since association ID values for
issues. One has to do with cryptographic parameter negotiation, as in different invocations of the NTP daemon are randomized over the 16-bit
IPSEC protocols such as Photuris. As with Photuris, there may be a need space, it is unlikely that a very old packet would contain a valid
to offer and agree to one of possibly several hashing algorithms, association ID value. An intruder could save old server packets and
signature algorithms and agreement algorithms. A message type has been replay them to the client population with the hope that the values
defined for this purpose, but its syntax and semantics remain to be will be accepted and cause general chaos. The conservative client will
provoked. discard them on the basis of invalid timestamp.
Another issue is support for certificates and certificate authorities, As mentioned previously, an intruder could pounce on the initial
in particular Secure DNS services. In the reference implementation a volley between peers in symmetric mode before both peers have
complicating factor is the existing banal state of the configuration and determined each other reachable. In this volley the peers are
resolver code. Over the years this code has sprouted to a fractal-like vulnerable to an intruder using fake timestamps. The result can be
state where possibly the only correct repair is a complete rewrite. that the peers never synchronize the timestamps and never completely
mobilize their associations. A clever intruder might notice the
interval between public value signatures and concentrate attack on the
vulnerable intervals. An obvious countermeasure is to randomize these
intervals. A more comprehensive countermeasure remains to be devised.
Appendix A. Packet Formats Appendix A. Packet Formats
The NTP Version 4 packet consists of a number of fields made up of 32- The NTP Version 4 packet consists of a number of fields made up of 32-
bit (4 octet) words. The packet consists of three components, the bit (4 octet) words in network byte order. The packet consists of
header, one or more optional extension fields and an optional message three components, the header, one or more optional extension fields
authenticator code (MAC), consisting of the Key ID and Message Digest and an optional message authenticator code (MAC), consisting of the
fields. The format is shown below, where the size of some multiple word Key ID and Message Digest fields. The format is shown below, where the
fields is shown in bits. size of some multiple word fields is shown in words.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode | Stratum | Poll | Precision | |LI | VN |Mode | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay | | Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion | | Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference ID | | Reference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Reference Timestamp (64) | | Reference Timestamp (2) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Originate Timestamp (64) | | Originate Timestamp (2) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Receive Timestamp (64) | | Receive Timestamp (2) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Transmit Timestamp (64) | | Transmit Timestamp (2) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Extension Field(s) = = Extension Field(s) =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | | Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| Message Digest (128) | | Message Digest (4) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NTP header extends from the beginning of the packet to the end of The NTP header extends from the beginning of the packet to the end of
the Transmit Timestamp field. The format and interpretation of the the Transmit Timestamp field. The format and interpretation of the
header fields are backwards compatible with the NTP Version 3 header header fields are backwards compatible with the NTP Version 3 header
fields as described in RFC-1305, except for a slightly modified fields as described in RFC-1305, except for a slightly modified
computation for the Root Dispersion field. In NTP Version 3, this field computation for the Root Dispersion field. In NTP Version 3, this
includes an estimated jitter quantity based on weighted absolute field includes an estimated jitter quantity based on weighted absolute
differences, while in NTP Version 4 this quantity is based on weighted differences, while in NTP Version 4 this quantity is based on weighted
root-mean-square (RMS) differences. root-mean-square (RMS) differences.
An unauthenticated NTP packet includes only the NTP header, while an An unauthenticated NTP packet includes only the NTP header, while an
authenticated one contains a MAC. The format and interpretation of the authenticated one contains in addition a MAC. The format and
NTP Version 4 MAC is described in RFC-1305 when using the Digital interpretation of the NTP Version 4 MAC is described in RFC-1305 when
Encryption Standard (DES) algorithm operating in cipher block chaining using the Digital Encryption Standard (DES) algorithm operating in
(CBC) node. While this algorithm and mode of operation is supported in Cipher-Block Chaining (CBC) node. This algorithm and mode of operation
NTP Version 4, the DES algorithm has been removed from the standard is no longer supported in NTP Version 4. The preferred replacement in
software distribution and must be obtained via other sources. The both NTP Version 3 and 4 is the Message Digest 5 (MD5) algorithm,
preferred replacement for NTP Version 4 is the Message Digest 5 (MD5) which is included in the distribution. For MD5 the Message Digest
algorithm, which is included in the distribution. The Message Digest field is 4 words (8 octets), but the Key ID field remains 1 word (4
field is 64 bits for DES-CBC and 128 bits for MD5, while the Key ID octets).
field is 32 bits for either algorithm.
In NTP Version 4 one or more extension fields can be inserted after the Extension Field Format
NTP header and before the MAC, which is always present when an extension
field is present. Each extension field contains a request or response In NTP Version 4 one or more extension fields can be inserted after
message, which consists of a 16-bit length field, an 8-bit control the NTP header and before the MAC, which is always present when an
field, an 8-bit flags field and a variable length data field, all in extension field is present. The extension fields can occur in any
network byte order: order; however, in some cases there is a preferred order which
improves the protocol efficiency. While previous versions of the
Autokey protocol used several different extension field formats, in
version 2 of the protocol only a single extension field format is
used.
Each extension field contains a request or response message in the
following format:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|E| Version | Code | Length | |R|E| Version | Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Filestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
= Value =
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
= Signature =
| | | |
= Data =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are two flag bits defined. Bit 0 is the response flag (R) and bit Each extension field except the last is padded to a word (4 octets)
1 is the error flag (E); the other six bits are presently unused and boundary, while the last is padded to a doubleword (8 octets)
should be set to 0. The Version field identifies the version number of boundary. The Length field covers the entire field length, including
the extension field protocol; this memorandum specifies version 1. The the Length field itself and padding. While the minimum field length is
Code field specifies the operation in request and response messages. The 8 octets, a maximum field length remains to be established. The
length includes all octets in the extension field, including the length reference implementation discards any packet with an extension field
field itself. Each extension field is rounded up to the next multiple of length over 1024 octets.
4 octets and the last field rounded up to the next multiple of 8 octets.
The extension fields can occur in any order; however, in some cases
there is a preferred order which improves the protocol efficiency.
The presence of the MAC and extension fields in the packet is determined
from the length of the remaining area after the header to the end of the
packet. The parser initializes a pointer just after the header. If the
length is not a multiple of 4, a format error has occurred and the
packet is discarded. If the length is zero the packet is not
authenticated. If the length is 4 (1 word), the packet is an error
report resulting from a previous packet that failed the message digest
check. The 4 octets are presently unused and should be set to 0. If the
length is 12 (3 words), a MAC (DES-CBC) is present, but no extension
field; if 20 (5 words), a MAC (MD5) is present, but no extension field;
If the length is 8 (2 words) or 16 (4 words), the packet is discarded
with a format error. If the length is greater than 20 (5 words), one or
more extension fields are present.
If an extension field is present, the parser examines the length field. The presence of the MAC and extension fields in the packet is
If the length is less than 4 or not a multiple of 4, a format error has determined from the length of the remaining area after the header to
occurred and the packet is discarded; otherwise, the parser increments the end of the packet. The parser initializes a pointer just after the
the pointer by this value. The parser now uses the same rules as above header. If the length is not a multiple of 4, a format error has
to determine whether a MAC is present and/or another extension field. An occurred and the packet is discarded. If the length is zero the packet
additional implementation-dependent test is necessary to ensure the is not authenticated. If the length is 4 (1 word), the packet is an
pointer does not stray outside the buffer space occupied by the packet. error report or crypto-NAK resulting from a previous packet that
failed the message digest check. The 4 octets are presently unused and
should be set to 0. If the length is 8 (2 words), 12 (3 words) or 16
(4 words), the packet is discarded with a format error. If the length
is greater than 20 (5 words), one or more extension fields are
present.
In the most common protocol operations, a client sends a request to a If an extension field is present, the parser examines the length
server with an operation code specified in the Code field and the R bit field. If the length is less than 4 or not a multiple of 4, a format
set to 0. Ordinarily, the client sets the E bit to 0 as well, but may in error has occurred and the packet is discarded; otherwise, the parser
future set it to 1 for some purpose. The server returns a response with increments the pointer by this value. The parser now uses the same
the same operation code in the Code field and the R bit set to 1. The rules as above to determine whether a MAC is present and/or another
server can also set the E bit to 1 in case of error. However, it is not extension field. An additional implementation-dependent test is
a protocol error to send an unsolicited response with no matching necessary to ensure the pointer does not stray outside the buffer
request. space occupied by the packet.
There are currently five request and six response messages. All request In the Autokey Version 2 format, the Code field specifies the request
messages except the Association ID request message have the following or response operation, while the Version field is 2 identifying the
format: current protocol version. There are two flag bits defined. Bit 0 is
the response flag (R) and bit 1 is the error flag (E); the other six
bits are presently unused and should be set to 0. The remaining fields
will be described later.
1 2 3 In the most common protocol operations, a client sends a request to a
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 server with an operation code specified in the Code field and the R
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bit set to 0. Ordinarily, the client sets the E bit to 0 as well, but
|0|0| 1 | Code | Length | may in future set it to 1 for some purpose. The Association ID field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ is set to the value previously received from the server or 0
| Association ID | otherwise. The server returns a response with the same operation code
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ in the Code field and the R bit set to 1. The server can also set the
E bit to 1 in case of error. The Association ID field is set to the
association ID sending the response 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 set to 1. Note
that, it is not a protocol error to send an unsolicited response with
no matching request.
The Association ID field is used to match a client request to a In some cases not all fields may be present. For instance, when a
particular server association. By convention, servers set the client has not synchronized to a proventic source, signatures are not
association ID in the response and clients include the same value in valid. In such cases the Timestamp and Signature Length fields are 0
requests. Also by convention, until a client has received a response and the Signature field is empty. Some request and error response
from a server, the client sets the Association ID field to 0. If for messages carry no value or signature fields, so in these messages only
some reason the association ID value in a request does not match the the first two words are present. The extension field parser verifies
association ID of any mobilized association, the server returns the that the extension field length is at least 8 if no value field is
request with both the R and E bits set to 1. expected and at least 24 if it is. The parser also verifies that the
sum of the value and signature lengths is equal to or less than the
extension field length.
The following request and response messages have been defined. The Timestamp and Filestamp words carry the seconds field of the NTP
timestamp. The Timestamp field establishes the signature epoch of the
data field in the message, while the filestamp establishes the
generation epoch of the file that ultimately produced the data that
was signed. Since a signature and timestamp are valid only when the
signing host is synchronized to a proventic source and a cryptographic
data file can only be generated if a signature is possible, the
filestamp is always nonzero, except in the Association Response
message, where it contains the server status word.
Parameter Negotiation (1) Autokey Version 2 Messages
This extension field is reserved for future use as an algorithm and Association Message
algorithm parameter offer/select exchange, as well as to provide the
optional identification value to use in lieu of endpoint IP addresses
when calculating the autokey. The format, encoding and use of these data
remain to be specified. The command code is reserved.
Association ID (2) The Association message is used to obtain the host name and related
A client sends the request to obtain the association ID and status values. The request message has the following format:
flags. A broadcast server sends an unsolicited response for all except
the first autokey sent from the key list. The request and response have
the following format (except for the response bit):
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E| 1 | 2 | Length | |0|0| 1 | 1 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Association ID field contains the association ID of the server. The The response message has the following format:
status flags currently defined are
Bit Function
================
31 autokey is enabled
30 public and private keys have been loaded
29 agreement parameters have been loaded
28 leapseconds table has been loaded
Additional bits may be defined in future, so for now bits 0-27 should be
set to zero. There is no timestamp or signature associated with this
message.
Autokey (3)
A broadcast server or symmetric peer sends the request to obtain the
autokey values. The response has the following format:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E| 1 | 4 | Length | |1|E| 1 | 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Sequence | | Public Value Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Key ID | | Status Word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | | Host Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Signature = = Host Name =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The response is also sent unsolicited when the server or peer generates This is the only response that is accepted if the association status
a new key list. The Initial Sequence field contains the first key number word is zero; otherwise, it is ignored. As this is the first request
in the current key list and the Initial Key ID field contains the next sent and the response is not from an association, the Association ID
key ID associated with that number. If the server is not synchronized to fields are 0. The Host Name field contains the unterminated string
a proventicated source, the Timestamp field contains 0; otherwise, it returned by the Unix gethostname() library function. The Status Word
contains the NTP seconds when the key list was generated and signed. The is defined in previously in this memorandum. While minimum and maximum
signature covers all fields from the Timestamp field through the Initial host name lengths remain to be established, the reference
Key ID field. If for some reason these values are unavailable or the implementation uses the values 4 and 256, respectively.
signing operation fails, the Initial Sequence and Initial Key ID fields
contain 0 and the extension field is truncated following the Initial Key
ID field.
Cookie (4) Certificate Message
A client sends the request to obtain the server cookie. The response has The Certificate message is used to obtain the certificate and related
the following format: values. The request message has the following format:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E| 1 | 3 | Length | |0|0| 2 | 2 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID | | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
The response message has the following format:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie | |1|E| 2 | 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Values Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate Filestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Signature = = Certificate =
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
= Certificate Signature =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Since there is no server association matching the client, the The response is accepted only if the association status word is
association ID field for the request and response is 0. The Cookie field nonzero, AUT = 0 and LBK = 1. The certificate is encoded in X.509
contains the cookie used in client/server modes. If the server is not format using ASN.1 syntax. If the certificate has expired or for some
synchronized to a proventicated source, the Timestamp field contains 0; reason is no longer available, the response includes only the first
otherwise, it contains the NTP seconds when the cookie was computed and two words with the E bit set. The remaining fields are defined
signed. The signature covers the Timestamp and Cookie fields. If for previously in this memorandum.
some reason the cookie value is unavailable or the signing operation
fails, the Cookie field contains 0 and the extension field is truncated
following this field.
Diffie-Hellman Parameters (5) Cookie Message
A symmetric peer uses the request and response to send the public value
and signature to its peer. The response has the following format: The Cookie is used in client/server and symmetric modes to obtain the
server cookie. The request message has the following format:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E| 1 | 5 | Length | |0|0| 3 | 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID | | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Public Values Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameters Filestamp | | Certificate Filestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameters Length | | Public Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Parameters = = Public Key =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | | Public Key Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Signature = = Public Key Signature =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Parameters field contains the Diffie-Hellman parameters used to The request is accepted only if AUT = 1, CKY = 0 and LBK = 1. The
compute the public and private values. The Parameters Filestamp field Public Key field contains the server public key values to be used for
contains the NTP seconds when the Diffie-Hellman parameter file was cookie encryption. The values are encoded in ASN.1 format. The
generated. If the server is not synchronized to a proventicated source, remaining fields are defined previously in this memorandum.
the Timestamp field contains 0; otherwise, it contains the NTP seconds
when the public value was generated and signed. The signature covers the
Timestamp, Parameters Length and Parameters fields. If for some reason
these values are unavailable or the signing operation fails, the
Parameters Length field contains 0 and the extension field is truncated
following this field.
Public Value (6)
A symmetric peer uses the request and response to send the public value The response message has the following format:
and signature to its peer. The response has the following format:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E| 1 | 5 | Length | |1|E| 3 | 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID | | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Cookie Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Filestamp | | Certificate Filestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Value Length | | Encrypted Cookie Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Public Value = = Encrypted Cookie =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | | Cookie Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Signature = = Cookie Signature =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Public Value field contains the Diffie-Hellman public value used to The response is accepted only if AUT = 1 and LBK = 1. The Cookie
compute the agreed key. Timestamp, Encrypted Cookie and Cookie Signature fields are determined
upon arrival of the request message. The Encrypted Cookie field
contains the encrypted cookie value according to the public key
provided in the request. If CKY = 0, the decrypted cookie is used
directly. If CKY = 1, the decrypted cookie is exclusive-ORed with the
existing cookie. If an error occurs when decoding the public key or
encrypting the cookie, the response includes only the first two words
with the E bit set. The remaining fields are defined previously in
this memorandum.
The Filestamp field contains the NTP seconds when the Diffie-Hellman Autokey Message
parameter file was generated. If the server is not synchronized to a The Autokey message is used to obtain the autokey values. The request
proventicated source, the Timestamp field contains 0; otherwise, it message has the following format:
contains the NTP seconds when the public value was generated and signed.
The signature covers all fields from the Timestamp field through the
Public Value field. If for some reason these values are unavailable or
the signing operation fails, the Public Value Length field contains 0
and the extension field is truncated following this field.
Public Key/Host Name (7) 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| 2 | 4 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A client uses the request to retrieve the public key, host name and The response message has the following format:
signature. The response has the following format:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E| 1 | 7 | Length | |1|E| 4 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID | | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Autokey Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Filestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key Length | | Certificate Filestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | 8 |
| |
= Public Key =
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Name Length | | Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Key Number |
| |
= Host Name =
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | | Autokey Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Signature = = Autokey Signature =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Since the public key and host name are a property of the server and not The response is accepted only if AUT = 1 and KEY = 0 in the
any particular association, the association ID field for the request and association status word; otherwise, it is ignored. The Autokey
response is 0. The Public Key field contains the RSA public key in Timestamp, Key ID, Key Number and Autokey Signature fields are
rsaref2.0 format; that is, the modulus length (in bits) as the first determined when the most recent key list was generated. If a key list
word followed by the modulus bits. Note that in some architectures the has not been generated or the association ID matches no mobilized
rsaref2.0 modulus word may be something other than 32 bits. The Host association, the response includes only the first two words with the E
Name field contains the host name string returned by the Unix bit set. The remaining fields are defined previously in this
gethostname() library function. memorandum.
The Filestamp field contains the NTP seconds when the public/private key
files were generated. If the server is not synchronized to a
proventicated source, the Timestamp field contains 0; otherwise, it
contains the NTP seconds when the public value was generated and signed.
The signature covers all fields from the Timestamp field through the
Host Name field. If for some reason these values are unavailable or the
signing operation fails, the Host Name Length field contains 0 and the
extension field is truncated following this field.
Leapseconds table (8)
The civil timescale (UTC), which is based on Earth rotation, has been
diverging from atomic time (TAI), which is based on an ensemble of
cesium oscillators, at about one second per year. Since 1972 the
International Bureau of Weights and Measures (BIPM) declares on occasion
a leap second to be inserted in the UTC timescale on the last day of
June or December. Sometimes it is necessary to correct UTC as
disseminated by NTP to agree with TAI on the current or some previous
epoch.
A client uses the request to retrieve the leapseconds table and Leapseconds Table Message
signature. The response has the following format: The Leapseconds Table message is used to exchange leapseconds tables.
The request and response messages have the following format, except
that the R bit is set in the response:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E| 1 | 8 | Length | |0|0| 2 | 5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID | | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Public Values Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Filestamp | | Leapseconds Filestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leapseconds table Length | | Leapseconds Table Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Leapseconds table = = Leapseconds Table =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | | Leapseconds Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Signature = = Leapseconds Signature =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NTP extension field format consists of a table with one entry in NTP The response is accepted only if AUT = 1 and LPT = 0 in the
seconds for each leap second. association status word; otherwise, it is ignored. The Leapseconds
Table field contains the leapseconds table as parsed from the
leapseconds file available from NIST. In client/server mode the client
requests the table from the server when the LPF bit is set in the host
status word. If the client already has a copy, it uses the one with
the latest filestamp. In symmetric modes the peers exchange tables and
both use the one with the latest filestamp. If the leapseconds table
is requested but unavailable, the response includes only the first two
words with the E bit set. The remaining fields are defined previously
in this memorandum.
Since the leapseconds table is a property of the server and not any Appendix B. Key Generation and Management
particular association, the association ID field for the request and
response is 0. The Leapseconds table field contains a list of the
historic epoches that leap seconds were inserted in the UTC timescale.
Each list entry is a 32-bit word in NTP seconds, while the table is in
order from the most recent to the oldest insertion. At the first
insertion in January, 1972 UTC was ahead of TAI by 10 s and has
increased by 1 s for each insertion since then. Thus, the table length
in bytes divided by four plus nine is the current offset of UTC relative
to TAI.
The Filestamp field contains the NTP seconds when the leapseconds table The ntp-genkeys utility program in the NTP software distribution
was generated at the original host, in this case one of the public time generates public/private key, certificate request and certificate
servers operated by NIST. If the value of the filestamp is less than the files. A set of files is generated for every message digest and
first entry on the list, the first entry is the epoch of the predicted signature encryption scheme supported by the OpenSSL software library.
next leap insertion. The filestamp must always be greater than the All files are based on a pseudo-random number generator seeded in such
second entry in the list. If the server is not synchronized to a a way that random values are exceedingly unlikely to repeat. The files
proventicated source, the Timestamp field contains 0; otherwise, it are PEM encoded in printable ASCII format suitable for mailing as MIME
contains the NTP seconds when the public value was generated and signed. objects. The file names include the name of the generating host
The signature covers all fields from the Timestamp field through the together with the filestamp, as described previously in this
Leapseconds table field. If for some reason these values are unavailable memorandum.
or the signing operation fails, the Host Name Length field contains 0
and the extension field is truncated following this field.
Appendix B. Key Generation and Management The generated files are typically stored in a shared directory in NFS
mounted file systems, with files containing private keys obscured to
all but root. Links from default file names assumed by the NTP daemon
are installed to the selected files for the host key, sign key and
host certificate. Since the files of successive generations and
different hosts have unique names, there is no possibility of name
collisions. An extensive set of consistency checks avoids linking from
a particular host to the files of another host, for example.
In the reference implementation the lifetimes of various cryptographic The ntp-genkeys program generates public/private key files for both
values are carefully managed and frequently refreshed. While permanent the RSA and DSA encryption algorithms with a default modulus of 512
keys have lifetimes that expire only when manually revoked, autokeys bits. The host key used for cookie encryption must be RSA. By default,
have a lifetime specified at the time of generation. When generating a the same key is used for signature encryption. However, a different
key list for an association, the lifetime of each autokey is set to RSA key or a DSA key can be specified for signature encryption.
expire one poll interval later than it is scheduled to be used.
Ordinarily, key lists are regenerated and signed about once per hour and
private cookie values and public agreement values are refreshed and
signed about once per day. The protocol design is specially tailored to
make a smooth transition when these values are refreshed and to avoid
vulnerabilities due to clogging and replay attacks while refreshment is
in progress.
Autokey key management can be handled in much the same way as in the ssh The ntp-genkeys program also generates certificate request and self-
facility. A set of public and private keys and agreement parameters are signed certificate files. The X.509 certificate request used by
generated by a utility program designed for this purpose. The program Autokey includes at the minimum these values and possibly related
generates four files, one containing random DES/MD5 private keys, which information needed by an external certificate authority. Autokey
are not used in the Autokey protocol, a second containing the RSA expects the subject name and issuer name to be the same as the
private key, a third the RSA public key, and a fourth the Diffie-Hellman generating host name.
agreement parameters. In addition, the leapseconds table is generated
and stored in public time servers maintained by NIST. The means to do
this are beyond the scope of this memorandum.
All files are based on random strings seeded by the system clock at the The program avoids the need for a serial number file by using the
time of generation and are in printable ASCII format with PEM (base-64) filestamp as the certificate serial number. By default, certificates
encoding. The name of each file includes an extension consisting of the are valid for one year following the time of generation, although
NTP seconds at the time of generation. This is interpreted as a key ID these conventions may change. Also, the program assumes X.509 version
in order to detect incorrect keys and to handle key changeovers in an 1 formats, although this may change to version 3 in future. Other
orderly way. In the recommended method, all files except the RSA private implementations might have different conventions.
key file are installed in a shared directory /usr/local/etc, which is
where the daemon looks for them by default. The private RSA key file is
installed in an unshared directory such as /etc. It is convenient to
install links from the default file names, which do not have filestamp
extensions, to the current files, which do. This way when a new
generation of keys is installed, only the links need to be changed.
When a server or client first initializes, it loads the RSA public and Appendix C. Packet Processing Rules
private key files, which are required for continued operation. It then
attempts to load the agreement parameters file, certificate file and
leapseconds table file. If one or more of these files are present, the
associated bit is set in the system status word. Neither of these files
are necessary at this time, since the data can be retrieved later from
another server. If obtaining these data from another server is
considered a significant vulnerability, the files should be present.
In the current management model, the keys and parameter files are Exhaustive examination of possible vulnerabilities at the various
generated on each machine separately and the private key obscured. For processing steps of the NTP protocol as specified in RFC-1305 have
the most demanding applications, the public key files for a community of resulted in a revised list of packet sanity tests. There are 12 tests,
users can be copied to all of those users, while one of the parameter called TEST1 through TEST12 in the reference implementation, which are
files can be selected and copied to all users. However, if security performed in a specific order designed to gain maximum diagnostic
considerations permit, the public key and parameter values, as well as information while protecting against an accidental or malicious
the certificate file and leapseconds table file, can be obtained from clogging attack. These tests are described in detail in the Flash
other servers during operation. These data completely define the Codes section of the ntpq documentation page at
security community and the servers configured for each client. In www.eecis.udel.edu/~ntp/ntp_spool/html/ntpq.htm.
broadcast client and symmetric passive modes the identity of a
particular server may not be known in advance, so the protocol obtains
and verifies the public key and host name directly from the server.
Ultimately, these procedures may be automated using public certificates
retrieved from secure directory services.
Since all files carry a filestamp incorporated in the file name, newer The sanity tests are divided into three tiers as previously described.
file generations are detected in the data obtained from the one or more The first tier deflects access control and packet message digest
configured servers. When detected, the newer generations replace the violations. The second deflects packets from broken or unsynchronized
older ones automatically and the newer ones made available to dependent servers and replays. The third deflects packets with invalid header
clients as required. Since the filestamp signatures are refreshed once fields or time values with excessive errors. However, the tests in
per day, which causes all associations to reset, the newer generations this last group do not directly affect cryptographic the protocol
will eventually overtake all older ones throughout the subnet of servers vulnerability, so are beyond the scope of discussion here.
and dependent clients.
Where security considerations permit and the public key, certificate and When a host initializes, it reads its own host key, sign key and
agreement parameter files can be retrieved directly from the server, certificate files, which are required for continued operation.
these data can be easily automated. Each server and client runs a shell Optionally, it reads the leapseconds file, when available. When
script perhaps once per month. The script generates new key and reading these files the host checks the filestamps for validity; for
parameter files, updates the links and then restarts the daemon. The instance, all filestamps must be later than the time the UTC timescale
daemon loads the necessary files and then restarts the protocol with was established in 1972 and the certificate filestamp must not be
each of its servers, refreshing public keys and parameter files during earlier than the sign key filestamp (or host key filestamp, if that is
the process. Clients will not be able to authenticate following daemon the default sign key). In general, at the time the files are read, the
restart, but the protocol design is such that they will eventually time host is not synchronized, so it cannot determine whether the
out, restart the protocol and retrieve the latest data. filestamps are bogus other than these simple checks.
Once a client has synchronized to a proventic source, additional
checks are implemented as each message arrives. In the following the
relation A -> B is Lamport's "happens before" relation which is true
if event A happens before event B. Here the relation is assume to hold
if event A is simultaneous with event B, unless noted to the contrary.
The following assertions are required:
1. For timestamp T and filestamp F, F->T; that is, the timestamp must
not be earlier than the filestamp.
2. In client and symmetric modes, for host key filestamp H, public key
timestamp P, cookie timestamp C and autokey timestamp A, H->P->C->A;
that is, once the cookie is generated an earlier cookie will not be
accepted, and once the key list and autokey values are generated,
earlier autokey values will not be accepted.
3. For sign file S and certificate filestamp C specifying begin time B
and end time E, S->C->B->E; that is, the valid period must be nonempty
and not retroactive.
4. For timestamp T, begin time B and end time E, B->T->E; that is, the
timestamp T is valid from the beginning if second B through the end of
second E. This raises the interesting possibilities where a truechimer
server with expired certificate or a falseticker with valid
certificate are not detected until the client has synchronized to a
clique of proventic truechimers.
5. For each of signatures, the client saves the most recent valid
timestamp T0 and filestamp F0. For every received message carrying
timestamp T1 and filestamp F1, the message is discarded unless T0->T1
and F0->F1; however, if the KEY bit of the association status word is
dim, the message is not discarded if T1 = T0; that is, old messages
are discarded and, in addition, if the server is proventic, the
message is discarded if an old duplicate.
An interesting question is what happens if during regular operation a
certificate becomes invalid. The behavior assumed is identical to the
case where an incorrect sign key were used. Thus, the next time a
client attempts to verify an autokey signature, for example, the
operation would fail and eventually cause a general client reset and
restart.
Security Considerations Security Considerations
Security issues are the main topic of this memorandum. Security issues are the main topic of this memorandum.
References References
Note: Internet Engineering Task Force documents can be obtained at Note: Internet Engineering Task Force documents can be obtained at
www.ietf.org. Other papers and reports can be obtained at www.ietf.org. Other papers and reports can be obtained at
www.eecis.udel.edu/~mills. Additional briefings in PowerPoint, www.eecis.udel.edu/~mills. Additional briefings in PowerPoint,
PostScript and PDF are at that site in ./autokey.htm. PostScript and PDF are at that site in ./autokey.htm.
1. Bradner, S. Key words for use in RFCs to indicate requirement levels. 1. Bradner, S. Key words for use in RFCs to indicate requirement
Request for Comments RFC-2119, BCP 14, Internet Engineering Task Force, levels. Request for Comments RFC-2119, BCP 14, Internet Engineering
March 1997. Task Force, March 1997.
2. Karn, P., and W. Simpson. Photuris: session-key management protocol. 2. Karn, P., and W. Simpson. Photuris: session-key management
Request for Comments RFC-2522, Internet Engineering Task Force, March protocol. Request for Comments RFC-2522, Internet Engineering Task
1999. Force, March 1999.
3. Kent, S., R. Atkinson. IP Authentication Header. Request for Comments 3. Kent, S., R. Atkinson. IP Authentication Header. Request for
RFC-2402, Internet Engineering Task Force, November 1998. Comments RFC-2402, Internet Engineering Task Force, November 1998.
4. Kent, S., and R. Atkinson. IP Encapsulating security payload (ESP). 4. Kent, S., and R. Atkinson. IP Encapsulating security payload (ESP).
Request for Comments RFC-2406, Internet Engineering Task Force, November Request for Comments RFC-2406, Internet Engineering Task Force,
1998. November 1998.
5. Maughan, D., M. Schertler, M. Schneider, and J. Turner. Internet 5. Maughan, D., M. Schertler, M. Schneider, and J. Turner. Internet
security association and key management protocol (ISAKMP). Request for security association and key management protocol (ISAKMP). Request for
Comments RFC-2408, Internet Engineering Task Force, November 1998. Comments RFC-2408, Internet Engineering Task Force, November 1998.
6. Mills, D.L. Authentication scheme for distributed, ubiquitous, real- 6. Mills, D.L. Authentication scheme for distributed, ubiquitous,
time protocols. Proc. Advanced Telecommunications/Information real-time protocols. Proc. Advanced Telecommunications/Information
Distribution Research Program (ATIRP) Conference (College Park MD, Distribution Research Program (ATIRP) Conference (College Park MD,
January 1997), 293-298. January 1997), 293-298.
7. Mills, D.L. Cryptographic authentication for real-time network 7. Mills, D.L. Cryptographic authentication for real-time network
protocols. In: AMS DIMACS Series in Discrete Mathematics and Theoretical protocols. In: AMS DIMACS Series in Discrete Mathematics and
Computer Science, Vol. 45 (1999), 135-144. Theoretical Computer Science, Vol. 45 (1999), 135-144.
8. Mills, D.L. Network Time Protocol (Version 3) specification, 8. Mills, D.L. Network Time Protocol (Version 3) specification,
implementation and analysis. Network Working Group Report RFC-1305, implementation and analysis. Network Working Group Report RFC-1305,
University of Delaware, March 1992, 113 pp. University of Delaware, March 1992, 113 pp.
9. Mills, D.L. Proposed authentication enhancements for the Network Time 9. Mills, D.L. Proposed authentication enhancements for the Network
Protocol version 4. Electrical Engineering Report 96-10-3, University of Time Protocol version 4. Electrical Engineering Report 96-10-3,
Delaware, October 1996, 36 pp. University of Delaware, October 1996, 36 pp.
10. Mills, D.L, and A. Thyagarajan. Network time protocol version 4 10. Mills, D.L, and A. Thyagarajan. Network time protocol version 4
proposed changes. Electrical Engineering Department Report 94-10-2, proposed changes. Electrical Engineering Department Report 94-10-2,
University of Delaware, October 1994, 32 pp. University of Delaware, October 1994, 32 pp.
11. Mills, D.L. Public key cryptography for the Network Time Protocol. 11. Mills, D.L. Public key cryptography for the Network Time Protocol.
Electrical Engineering Report 00-5-1, University of Delaware, May 2000. Electrical Engineering Report 00-5-1, University of Delaware, May
23 pp. 2000. 23 pp.
12. Orman, H. The OAKLEY key determination protocol. Request for 12. Orman, H. The OAKLEY key determination protocol. Request for
Comments RFC-2412, Internet Engineering Task Force, November 1998. Comments RFC-2412, Internet Engineering Task Force, November 1998.
Author's Address Author's Address
David L. Mills David L. Mills
Electrical and Computer Engineering Department Electrical and Computer Engineering Department
University of Delaware University of Delaware
Newark, DE 19716 Newark, DE 19716
mail mills@udel.edu, phone 302 831 8247, fax 302 831 4316 mail mills@udel.edu, phone 302 831 8247, fax 302 831 4316
web www.eecis.udel.edu/~mills web www.eecis.udel.edu/~mills
Edited into Internet-draft form by:
Patrick Cain. Please notify pcain@genuity.com of editorial omissions or
errors.
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. This "Copyright (C) The Internet Society, 2001. All Rights Reserved. This
document and translations of it may be copied and furnished to others, document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist and derivative works that comment on or otherwise explain it or assist
in its implmentation may be prepared, copied, published and distributed, in its implmentation may be prepared, copied, published and
in whole or in part, without restriction of any kind, provided that the distributed, in whole or in part, without restriction of any kind,
above copyright notice and this paragraph are included on all such provided that the above copyright notice and this paragraph are
copies and derivative works. However, this document itself may not be included on all such copies and derivative works. However, this
modified in any way, such as by removing the copyright notice or document itself may not be modified in any way, such as by removing
references to the Internet Society or other Internet organizations, the copyright notice or references to the Internet Society or other
except as needed for the purpose of developing Internet standards in Internet organizations, except as needed for the purpose of developing
which case the procedures for copyrights defined in the Internet Internet standards in which case the procedures for copyrights defined
Standards process must be followed, or as required to translate it into. in the Internet Standards process must be followed, or as required to
translate it into.
 End of changes. 289 change blocks. 
1778 lines changed or deleted 1385 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/