draft-ietf-stime-ntpauth-03.txt   draft-ietf-stime-ntpauth-04.txt 
Internet Engineering Task Force David L. Mills Secure Time Working Group David L. Mills
Internet Draft University of Delaware Internet Draft University of Delaware
Standards Track February 2002 Document: draft-ietf-stime-ntpauth-04.txt November 2002
Public Key Cryptography for the Network Time Protocol
Public key Cryptography for the Network Time Protocol
Version 2 Version 2
< draft-ietf-stime-ntpauth-03.txt >
Status of this Memorandum Status of this Memo
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
provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026 [RFC-2026]].
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that
may also distribute working documents as Internet-Drafts. other 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- http://www.ietf.org/shadow.html.
Draft.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
1. Abstract
This memorandum describes a scheme for authenticating servers to clients
using the Network Time Protocol. It extends prior schemes based on
symmetric key cryptography to a new scheme based on public key
cryptography. The new scheme, called Autokey, is based on the premiss
that the IPSEC schemes proposed by the IETF cannot be adopted intact,
since that would preclude stateless servers and severely compromise
timekeeping accuracy. In addition, the IPSEC model presumes
authenticated timestamps are always available; however,
cryptographically verified timestamps require interaction between the
timekeeping function and authentication function in ways not yet
considered in the IPSEC model.
The main body of this memorandum contains a description of the security
model, approach rationale, protocol design and vulnerability analysis.
It obsoletes a previous report [11] primarily in the schemes for
distributing public keys and related values. A detailed description of
the protocol states, events and transition functions is included.
Detailed packet formats and field descriptions are given in the
appendix. A prototype of the Autokey design based on this memorandum has
been implemented, tested and documented in the NTP Version 4 software
distribution for Unix, Windows and VMS at www.ntp.org.
While not strictly a security function, the Autokey protocol also
provides means to securely retrieve a table of historic leap seconds
necessary to convert ordinary civil time (UTC) to atomic time (TAI)
where needed. The tables can be retrieved either directly from national
time servers operated by NIST or indirectly through NTP and intervening
servers.
Changes Since the Preceding Draft
This is a major rewrite of the previous draft. There are numerous Copyright (C), The Internet Society, 2002. All rights reserved.
changes scattered through this memorandum to clarify the presentation
and add a few new features. Among the most important:
1. The reference implementation now uses the OpenSSL cryptographic Abstract
software library. Besides being somewhat faster than the older RSAref2.0
library, it supports several different message digest and signature
encryption schemes.
2. The Autokey protocol and reference implementation support the Public This document describes the Autokey security model for authenticating
Key Infrastructure (PKI), including X.500 certificates. servers to clients using the Network Time Protocol (NTP) and public
key cryptography. its design is based on the premiss that IPSEC
schemes cannot be adopted intact, since that would preclude stateless
servers and severely compromise timekeeping accuracy. In addition,
PKI schemes presume authenticated time values are always available to
enforce certificate lifetimes; however, cryptographically verified
timestamps require interaction between the timekeeping function and
authentication function in ways not yet considered by the IETF.
3. The Autokey protocol has been redesigned to be simpler, more uniform This Document includes the Autokey requirements analysis, design
and more robust. There is only one generic message format and all principles and protocol specification. A detailed description of the
requests can carry signed parameters. protocol states, events and transition functions is included. A
prototype of the Autokey design based on this document has been
implemented, tested and documented in the NTP Version 4 (NTPv4)
software distribution for Unix, Windows and VMS at
http://www.ntp.org.
4. Strong assertions are now possible about the authentication of Conventions used in this document
timestamps and filestamps. This makes correctness modeling more robust
and simplifies vulnerability assessment.
5. Certain security potholes have been filled in, in particular the The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
cookie in client/server and symmetric modes is now encrypted. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC-2119].
6. The description of the protocol, its state variables, transition Table of Contents
function, inputs and outputs are simpler, less wordy and more amenable
to correctness modelling.
7. Provisions have been made to handle cases when the endpoint addresses 1. Introduction...................................................4
are changed, as in mobile IP. 2. NTP Security Model.............................................5
3. Approach.......................................................8
4. Autokey Cryptography...........................................9
5. Autokey Operations............................................11
6. Public Key Signatures and Timestamps..........................14
7. Autokey Protocol Overview.....................................16
8. Autokey State Machine.........................................18
8.1 Status Word...............................................18
8.2 Host State Variables......................................20
8.3 Client State Variables (all modes)........................21
8.4 Server State Variables (broadcast and symmetric modes)....22
8.5 Autokey Messages..........................................23
9. Error Recovery................................................27
10. References...................................................29
Appendix A. Packet Formats.......................................31
A.1 Extension Field Format....................................32
A.2 Autokey Version 2 Messages................................34
Appendix B. Cryptographic Key and Certificate Management.........43
Appendix C. Autokey Error Checking...............................45
C.1 Packet Processing Rules...................................45
C.2 Timestamps, Filestamps and Partial Ordering...............47
Appendix D. Security Analysis....................................49
D.1 Protocol Vulnerability....................................49
D.2 Clogging Vulnerability....................................50
Appendix E. Identity Schemes.....................................53
E.1 Private Certificate (PC) Scheme...........................55
E.2 Trusted Certificate (TC) Scheme...........................55
E.3 Schnorr (IFF) Scheme......................................55
E.4 Guillard-Quisquater (GQ) Scheme...........................56
E.5 Interoperability Issues...................................57
Appendix F. File Examples........................................60
F.1 RSA-MD5cert File and ASN.1 Encoding.......................60
F.2 GQkey File and ASN.1 Encoding.............................61
F.3 GQpar File and ASN.1 Encoding.............................61
F.4 RSAkey File and ASN.1 Encoding............................61
F.5 IFFpar File and ASN.1 Encoding............................62
Appendix G. ASN.1 Encoding Rules.................................63
G.1 COOKIE request, IFF response, GQ response.................63
G.2 CERT response, SIGN request and response..................63
Security Considerations..........................................66
Author's Addresses...............................................66
Introduction 1. 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
information. Survivability requires protection from faulty public 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 NTP Version 3 (NTPv3) specification [RFC-1305];
a scheme for the distribution of cryptographic keys, nor does it provide however, that specification does not provide a scheme for the
for the retrieval of cryptographic media that reliably bind the server distribution of cryptographic keys, nor does it provide for the
identification credentials with the associated private keys and related retrieval of cryptographic media that reliably bind the server
public values. However, conventional key agreement and digital identification credentials with the associated private keys and
signatures with large client populations can cause significant related public values. However, conventional key agreement and
performance degradations, especially in time critical applications such digital signatures with large client populations can cause
as NTP. In addition, there are problems unique to NTP in the interaction significant performance degradations, especially in time critical
between the authentication and synchronization functions, since each applications such as NTP. In addition, there are problems unique to
requires the other. NTP in the interaction between the authentication and synchronization
functions, since each requires the other.
This memorandum describes a cryptographically sound and efficient This document 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 PKI and related schemes, the end of this document, there is a place for PKI and related
but none of these schemes alone satisfies the requirements of the NTP schemes, but none of these schemes alone satisfies the requirements
security model. The various key agreement schemes [2, 5, 12] proposed by of the NTP security model. The various key agreement schemes [RFC-
the IETF require per-association state variables, which contradicts the 2408], RFC-2412], [RFC-2522] proposed by the IETF require per-
principles of the remote procedure call (RPC) paradigm in which servers association state variables, which contradicts the principles of the
keep no state for a possibly large client population. An evaluation of remote procedure call (RPC) paradigm in which servers keep no state
the PKI model and algorithms as implemented in the RSAref2.0 package for a possibly large client population. An evaluation of the PKI
formerly distributed by RSA Laboratories leads to the conclusion that model and algorithms as implemented in the RSAref2.0 package formerly
any scheme requiring every NTP packet to carry a PKI digital signature distributed by RSA Laboratories leads to the conclusion that any
scheme requiring every NTP packet to carry a PKI digital signature
would result in unacceptably poor timekeeping performance. would result in unacceptably poor timekeeping 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 [MILLS96], [MILLS00]. It is based on a
since then and implemented in NTP Version 4 for Unix, Windows and VMS combination of PKI and a pseudo-random sequence generated by repeated
[11]. It is based on a combination of PKI and a pseudo-random sequence hashes of a cryptographic value involving both public and private
generated by repeated hashes of a cryptographic value involving both components. This scheme has been tested and evaluated in a local
public and private components. This scheme has been tested and evaluated environment and in the CAIRN experiment network funded by DARPA. A
in a local environment and in the CAIRN experiment network funded by detailed description of the security model, design principles and
DARPA. A detailed description of the security model, design principles implementation experience is presented in this document.
and implementation experience is presented in this memorandum.
Additional information about NTP, including executive summaries, Additional information about NTP, including executive summaries,
software documentation, briefings and bibliography can be found at briefings and bibliography can be found on the NTP project page
www.eecis.udel.edu/~mills/ntp.htm. Additional information about the linked from www.ntp.org. The NTPv4 reference implementation for Unix
reference implementation can be found at and Windows, including sources and documentation in HTML, is
www.eecis.udel.edu/~ntp/ntp_spool/html/authopt.htm. available from the NTP repository at the same site. All of the
features described in this document, including support for both IPv4
and IPv6 address families, are included in the current development
version at that repository. The reference implementation is not
intended to become part of any standard that may be evolved from this
document, but to serve as an example of how the procedures described
in this document can be implemented in a practical way.
Security Model 2. NTP 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
which are valid only over designated time intervals; but, time intervals keys which are valid only over designated time intervals; but, time
can be enforced only when participating 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. servers at the root through secondary servers to the clients at the
leaves.
A client can claim authentic to dependent applications only if all A client can claim authentic to dependent applications only if all
servers on the path to the primary servers are bone-fide authentic. In servers on the path to the primary servers are bone-fide authentic.
order to emphasize this requirement, in this memorandum the notion of In order to emphasize this requirement, in this document the notion
"authentic" is replaced by "proventic", a noun new to English and of "authentic" is replaced by "proventic", a noun new to English and
derived from provenance, as in the provenance of a painting. Having derived from provenance, as in the provenance of a painting. Having
abused the language this far, the suffixes fixable to the various noun abused the language this far, the suffixes fixable to the various
and verb derivatives of authentic will be adopted for proventic as well. noun and verb derivatives of authentic will be adopted for proventic
In NTP each server authenticates the next lower stratum servers and as well. In NTP each server authenticates the next lower stratum
proventicates the lowest stratum (primary) servers. Serious computer servers and proventicates (authenticates by induction) the lowest
linguists would correctly interpret the proventic relation as the stratum (primary) servers. Serious computer linguists would correctly
transitive closure of the authentic relation. interpret the proventic relation as the transitive closure of the
authentic relation.
It is important to note that the notion of proventic does not It is important to note that the notion of proventic does not
necessarily imply the time is correct. A client considers a server necessarily imply the time is correct. A NTP client mobilizes a
proventic if it can validate its certificate and its apparent time is number of concurrent associations with different servers and uses a
within the valid interval specified on the certificate. The statement crafted agreement algorithm to pluck truechimers from the population
"the client is synchronized to proventic sources" means that the system possibly including falsetickers. A particular association is
clock has been set using the time values of one or more proventic client proventic if the server certificate and identity have been verified
associations and according to the NTP mitigation algorithms. While a by the means described in this document. However, the statement "the
certificate authority must satisfy this requirement when signing a client is synchronized to proventic sources" means that the system
certificate request, the certificate itself can be stored in public clock has been set using the time values of one or more proventic
directories and retrieved over unsecured networks. 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 network paths.
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
infrastructure for privacy protection and source authentication in the IPSEC infrastructure for privacy protection and source authentication
Internet, The infrastructure includes the Encapsulating Security Payload in the Internet, The infrastructure includes the Encapsulating
(ESP) [4] and Authentication Header (AH) [3] for IPv4 and IPv6. Security Payload (ESP) [RFC-2406] and Authentication Header (AH)
Cryptographic algorithms that use these headers for various purposes [RFC-2402] for IPv4 and IPv6. Cryptographic algorithms that use these
include those developed for the PKI, including MD5 message digests, RSA headers for various purposes include those developed for the PKI,
digital signatures and several variations of Diffie-Hellman key including MD5 message digests, RSA digital signatures and several
agreements. The fundamental assumption in the security model is that variations of Diffie-Hellman key agreements. The fundamental
packets transmitted over the Internet can be intercepted by other than assumption in the security model is that packets transmitted over the
the intended receiver, remanufactured in various ways and replayed in Internet can be intercepted by other than the intended receiver,
whole or part. These packets can cause the client to believe or produce remanufactured in various ways and replayed in whole or part. These
incorrect information, cause protocol operations to fail, interrupt packets can cause the client to believe or produce incorrect
network service or consume precious processor resources. information, cause protocol operations to fail, interrupt network
service or consume precious network and processor resources.
In the case of NTP, the assumed goal of the intruder is to inject false 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, servers
clients with spurious packets that exhaust resources and deny service to or clients with spurious packets that exhaust resources and deny
legitimate applications. 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 document 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
but modified or replayed by an intruder. The cryptographic means of the the intended sender, but modified or replayed by an intruder. The
reference implementation are based on the OpenSSL cryptographic software cryptographic means of the reference implementation are based on the
library available at www.openssl.org, but other libraries with OpenSSL cryptographic software library available at www.openssl.org,
equivalent functionality could be used as well. It is important for but other libraries with equivalent functionality could be used as
distribution and export purposes that the way in which these algorithms well. It is important for distribution and export purposes that the
are used precludes encryption of any data other than incidental to the way in which these algorithms are used precludes encryption of any
construction of digital signatures. 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 spoof and replay attacks.
engineered clock filter, selection and clustering algorithms are The engineered clock filter, selection and clustering algorithms are
designed to defend against evil cliques of Byzantine traitors. While not designed to defend against evil cliques of Byzantine traitors. While
necessarily designed to defeat determined intruders, these algorithms not necessarily designed to defeat determined intruders, these
and accompanying sanity checks have functioned well over the years to algorithms and accompanying sanity checks have functioned well over
deflect improperly operating but presumably friendly scenarios. However, the years to deflect improperly operating but presumably friendly
these mechanisms do not securely identify and authenticate servers to scenarios. However, these mechanisms do not securely identify and
clients. Without specific further protection, an intruder can inject any authenticate servers to clients. Without specific further protection,
or all of the following mischiefs. Further discussion on the assumed an intruder can inject any or all of the following mischiefs.
intruder model is given in [9], but beyond the scope of this memorandum.
1. An intruder can intercept and archive packets forever, as well as all The NTP security model assumes the following possible threats.
the public values ever generated and transmitted over the net. Further discussion is in [MILLS00] and in the briefings at the NTP
project page, but beyond the scope of this document.
2. An intruder can generate packets faster than the server or client can 1. An intruder can intercept and archive packets forever, as well as
process them, especially if they require expensive cryptographic all the public values ever generated and transmitted over the net.
computations.
3. An intruder can originate, intercept, modify and replay a packet. 2. An intruder can generate packets faster than the server, network
However, it cannot permanently prevent packet transmission over the net; or client can process them, especially if they require expensive
that is, it cannot break the wire, only tell lies and congest it. In cryptographic computations.
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 3. In a wiretap attack the intruder can intercept, modify and replay
are discussed at some length in the briefing slides and links at a packet. However, it cannot permanently prevent onward transmission
www.eecis.udel.edu/~mills/ntp.htm and will not be further elaborated in of the original packet; that is, it cannot break the wire, only tell
this memorandum. lies and congest it. Except in unlikely cases considered in Appendix
D, the modified packet cannot arrive at the victim before the
original packet.
1. The running times for public key algorithms are relatively long and 4. In a middleman or masquerade attack the intruder is positioned
highly variable. In general, the performance of the synchronization between the server anc client, so it can intercept, modify and replay
function is badly degraded if these algorithms must be used for every a packet and prevent onward transmission of the original packet.
NTP packet. Except in unlikely cases considered in Appendix D, the middleman does
not have the server private keys or identity parameters.
2. In some modes of operation it is not feasible for a server to retain The NTP security model assumes the following possible limitations.
state variables for every client. It is however feasible to regenerated Further discussion is in [MILLS00] and in the briefings at the NTP
them for a client upon arrival of a packet from that client. project page, but beyond the scope of this document.
3. The lifetime of cryptographic values must be enforced, which requires 1. The running times for public key algorithms are relatively long
a reliable system clock. However, the sources that synchronize the and highly variable. In general, the performance of the time
system clock must be cryptographically proventicated. This circular synchronization function is badly degraded if these algorithms must
interdependence of the timekeeping and proventication functions requires be used for every NTP packet.
special handling.
2. In some modes of operation it is not feasible for a server to
retain state variables for every client. It is however feasible to
regenerated them for a client upon arrival of a packet from that
client.
3. The lifetime of cryptographic values must be enforced, which
requires a reliable system clock. However, the sources that
synchronize the system clock must be cryptographically proventicated.
This circular interdependence of the timekeeping and proventication
functions requires special handling.
4. All proventication functions must involve only public values 4. All proventication functions must involve only public values
transmitted over the net. Private values must never be disclosed beyond transmitted over the net with the single exception of encrypted
the machine on which they were created. signatures and cookies intended only to authenticate the source.
Private values must never be disclosed beyond the machine on which
they were created.
5. Public encryption keys and certificates must be retrievable directly 5. Public encryption keys and certificates must be retrievable
from servers without requiring secured channels; however, the directly from servers without requiring secured channels; however,
fundamental security of identification credentials and public values the fundamental security of identification credentials and public
bound to those credentials must be a function of external certificate values bound to those credentials must be a function 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 6. Error checking must be at the enhanced paranoid level, as network
identified to the server, in NTP the server must be securely identified terrorists may be able to craft errored packets that consume
to the client. In ssh each different interface address can be bound to a excessive cycles with needless result. While this document includes
different name, as returned by a reverse-DNS query. In this design an informal vulnerability analysis and error protection paradigm, a
separate public/private key pairs may be required for each interface formal model based on communicating finite-state machine analysis
address with a distinct name. A perceived advantage of this design is remains to be developed.
that the security compartment can be different for each interface. This
allows a firewall, for instance, to require some interfaces to
proventicate the client and others not.
However, the NTP security model specifically assumes all time values and Unlike the Secure Shell security model, where the client must be
cryptographic values are public, so there is no need to associate each securely authenticated to the server, in NTP the server must be
interface with different cryptographic values. In other words, there is securely authenticated to the client. In ssh each different interface
one set of private secrets for the host, not one for each interface. In address can be bound to a different name, as returned by a reverse-
the NTP design the host name, as returned by the gethostname() Unix DNS query. In this design separate public/private key pairs may be
library function, represents all interface addresses. Since at least in required for each interface address with a distinct name. A perceived
some host configurations the host name may not be identifiable in a DNS advantage of this design is that the security compartment can be
query, the name must be either configured in advance or obtained different for each interface. This allows a firewall, for instance,
directly from the server using the Autokey protocol. to require some interfaces to proventicate the client and others not.
Approach However, the NTP security model specifically assumes that access
control is performed by means external to the protocol and that all
time values and cryptographic values are public, so there is no need
to associate each interface with different cryptographic values. To
do so would create the possibility of a two-faced clock, which is
ordinarily considered a Byzantine hazard. In other words, there is
one set of private secrets for the host, not one for each interface.
In the NTP design the host name, as returned by the Unix
gethostname() library function, represents all interface addresses.
Since at least in some host configurations the host name may not be
identifiable in a DNS query, the name must be either configured in
advance or obtained directly from the server using the Autokey
protocol.
The Autokey protocol described in this memorandum is designed to meet 3. Approach
The Autokey protocol described in this document 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 document. Note that here and elsewhere in this document mention of
broadcast mode means multicast mode as well, with exceptions noted in 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. the NTP software documentation.
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 synchronized to a proventic source values and time values. A NTP packet is accepted for processing only
only when the required cryptographic values have been obtained and when the required cryptographic values have been obtained and
verified and the NTP timestamps have passed all sanity checks. verified and the NTP header has 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
synchronization algorithms. In particular, it must not make unreasonable NTP 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, specifically those 4. It must be resistant to cryptographic attacks, specifically those
identified in the security model above. In particular, it must be identified in the security model above. In particular, it must be
tolerant of operational or implementation variances, such as packet loss tolerant of operational or implementation variances, such as packet
or misorder, or suboptimal configurations. 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
encryption and cookie encryption operations. to signature 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 modes. server, symmetric and broadcast 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 the required cryptographic keys and configuration other than the availability of the required
certificates. cryptographic keys and certificates.
8. The reference implementation must contain provisions to generate 8. The reference implementation must contain provisions to generate
cryptographic key files specific to each client and server. Eventually, cryptographic key files specific to each client and server.
it must contain provisions to validate public values using certificate
authorities and/or webs of trust.
Autokey Proventication Scheme 4. Autokey Cryptography
Autokey public key cryptography is based on the PKI algorithms commonly Autokey public key cryptography is based on the PKI algorithms
used in the Secure Shell and Secure Sockets Layer applications. As in commonly used in the Secure Shell and Secure Sockets Layer
these applications Autokey uses keyed message digests to detect packet applications. As in these applications Autokey uses keyed message
modification, digital signatures to verify the source and public key digests to detect packet modification, digital signatures to verify
algorithms to encrypt session keys or cookies. What makes Autokey the source and public key algorithms to encrypt cookies. What makes
cryptography unique is the way in which these algorithms are used to Autokey cryptography unique is the way in which these algorithms are
deflect intruder attacks while maintaining the integrity and accuracy of used to deflect intruder attacks while maintaining the integrity and
the time synchronization function. accuracy of the time synchronization function.
The NTP Version 3 symmetric key cryptography uses keyed-MD5 message The NTPv3 symmetric key cryptography uses keyed-MD5 message digests
digests with a 128-bit private key and 32-bit key ID. In order to retain with a 128-bit private key and 32-bit key ID. In order to retain
backward compatibility, the key ID space is partitioned in two subspaces backward compatibility, the key ID space is partitioned in two
at a pivot point of 65536. Symmetric key IDs have values less than the subspaces at a pivot point of 65536. Symmetric key IDs have values
pivot 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 the pivot and are expunged immediately after pseudo-random values equal to or greater than the pivot and are
use. 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
three NTP modes: client/server, broadcast and symmetric. All three the three NTP modes: server, symmetric and broadcast. All three
variants make use of specially contrived session keys, called autokeys, variants make use of specially contrived session keys, called
and a precomputed pseudo-random sequence of autokeys with the key IDs autokeys, and a precomputed pseudo-random sequence of autokeys with
saved in a key list. As in the original NTP Version 3 authentication the key IDs saved in a key list. As in the original NTPv3
scheme, the Autokey protocol operates separately for each association, authentication scheme, the Autokey protocol operates separately for
so there may be several autokey sequences operating independently at the each association, so there may be several autokey sequences operating
same time. independently at the same time.
An autokey is computed from four fields in network byte order as shown An autokey is computed from four fields in network byte order as
below: shown below:
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| Source IP | Dest IP | Key ID | Cookie | | Source IP | Dest IP | Key ID | Cookie |
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
The four values are hashed by the MD5 message digest algorithm to The four values are hashed by the MD5 message digest algorithm to
produce the 128-bit key value, which in the reference implementation is produce the 128-bit autokey value, which in the reference
stored along with the key ID in a cache used for symmetric keys as well implementation is stored along with the key ID in a cache used for
as autokeys. Keys are retrieved from the cache by key ID using hash symmetric keys as well as autokeys. Keys are retrieved from the cache
tables and a fast lookup algorithm. by key ID using hash tables and a fast lookup algorithm.
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
shared private value, depending on the mode.
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
without extension fields, the cookie is a shared private value conveyed packets without extension fields, the cookie is a shared private
in encrypted form. For packets with extension fields, the cookie has a value conveyed in encrypted form. For packets with extension fields,
default public value of zero, since these packets can be validated the cookie has a default public value of zero, since these packets
independently using digital signatures. can be validated independently using digital signatures.
For use with IPv4, the Source IP and Dest IP fields contain 32 bits; for There are some scenarios where the use of endpoint IP addresses may
use with IPv6, these fields contain 128 bits. In either case the Key ID be difficult or impossible. These include configurations where
and Cookie fields contain 32 bits. Thus, an IPv4 autokey has four 32-bit network address translation (NAT) devices are in use or when
words, while an IPv6 autokey has ten 32-bit words. The source and addresses are changed during an association lifetime due to mobility
destination IP addresses and key ID are public values visible in the constraints. For Autokey, the only restriction is that the address
packet, while the cookie can be a public value or shared private value, fields visible in the transmitted packet must be the same as those
depending on the mode. used to construct the autokey sequence and key list and that these
fields be the same as those visible in the received packet.
There are some scenarios where the use of endpoint IP addresses may be Provisions are included in the reference implementation to handle
difficult or impossible. These include configurations where network cases when these addresses change, as possible in mobile IP. For
address translation (NAT) devices are in use or when addresses are scenarios where the endpoint IP addresses are not available, an
changed during an association lifetime due to mobility constraints. For optional public identification value could be used instead of the
Autokey, the only restriction is that the addresses visible in the addresses. Examples include the Interplanetary Internet, where
transmitted packet must be the same as those used to construct the bundles are identified by name rather than address. Specific
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. provisions are for further study.
The key list consists of a sequence of key IDs starting with a 32-bit The key list consists of a sequence of key IDs starting with a random
random private value called the autokey seed. The associated autokey is 32-bit nonce (autokey seed) equal to or greater than the pivot as the
computed as above using the specified cookie and the first 32 bits in first key ID. The first autokey is computed as above using the given
network byte order of this value become the next key ID. Operations cookie and the first 32 bits of the result in network byte order
continue in this way to generate the entire list, which may have up to become the next key ID. Operations continue in this way to generate
100 entries. It may happen that a newly generated key ID is less than the entire list. It may happen that a newly generated key ID is less
the pivot or collides with another one already generated (birthday than the pivot or collides with another one already generated
event). When this happens, which should occur only rarely, the key list (birthday event). When this happens, which should occur only rarely,
is terminated at that point. The lifetime of each key is set to expire the key list is terminated at that point. The lifetime of each key is
one poll interval after its scheduled use. In the reference set to expire one poll interval after its scheduled use. In the
implementation, the list is terminated when the maximum key lifetime is reference implementation, the list is terminated when the maximum key
about one hour. lifetime is about one hour, so for poll intervals above one hour a
new key list containing only a single entry is regenerated for every
poll.
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 for 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 autokey used is the last one autokey values are then signed. The list is used in reverse order, so
generated. The Autokey protocol includes a message to retrieve the that the first autokey used is the last one generated. The Autokey
autokey values and signature, so that subsequent packets can be protocol includes a message to retrieve the autokey values and
validated using one or more hashes that eventually match the first key signature, so that subsequent packets can be validated using one or
ID (valid) or exceed the index (invalid). This is called the autokey more hashes that eventually match the last key ID (valid) or exceed
test in the following and is done for every packet, including those with the index (invalid). This is called the autokey test in the following
and without extension fields. In the reference implementation the most and is done for every packet, including those with and without
recent key ID received is saved for comparison with the first 32 bits in extension fields. In the reference implementation the most recent key
network byte order of the next following key value. This minimizes the ID received is saved for comparison with the first 32 bits in network
number of hash operations in case a packet is lost. byte order of the next following key value. This minimizes the number
of hash operations in case a packet is lost.
Autokey Operations 5. Autokey Operations
Autokey works differently in the various NTP modes. The scheme used in The Autokey protocol has three variations, called dances,
client/server mode was suggested by Steve Kent over lunch some time ago, corresponding to the NTP server, symmetric and broadcast modes. The
but considerably modified since that meal. The server keeps no state for server dance was suggested by Steve Kent over lunch some time ago,
each client, but uses a fast algorithm and a private random value called but considerably modified since that meal. The server keeps no state
the server seed to regenerate the cookie upon arrival of a client for each client, but uses a fast algorithm and a 32-bit random
packet. The cookie is calculated in a manner similar to the autokey, but private value (server seed) to regenerate the cookie upon arrival of
the key ID field is zero and the cookie field is the server seed. The a client packet. The cookie is calculated as the first 32 bits of the
first 32 bits of the hash is the cookie used for the actual autokey autokey computed from the client and server addresses, a key ID of
calculation by both the client and server. It is thus specific to each zero and the server seed as cookie. The cookie is used for the actual
client separately and of no use to other clients or an intruder. autokey calculation by both the client and server and is thus
specific to each client separately.
In previous versions of the Autokey protocol the cookie was transmitted In previous Autokey versions the cookie was transmitted in clear on
in clear on the assumption it was not useful to a wiretapper other than the assumption it was not useful to a wiretapper other than to launch
to launch an ineffective replay attack. However, an middleman could an ineffective replay attack. However, a middleman could intercept
intercept the cookie and manufacture bogus messages acceptable to the the cookie and manufacture bogus messages acceptable to the client.
client. In order to reduce the vulnerability to such an attack, the In order to reduce the risk of such an attack, the Autokey Version 2
Autokey Version 2 server encrypts the cookie using a public key supplied server encrypts the cookie using a public key supplied by the client.
by the client. While requiring additional processor resources for the While requiring additional processor resources for the encryption,
encryption, this makes it effectively impossible to spoof a cookie. this makes it effectively impossible to spoof a cookie or masquerade
as the server.
[Note in passing. In an attempt to avoid the use of overt encryption [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 operations, an experimental scheme used a Diffie-Hellman agreed key
stream cipher to encrypt the cookie. However, not only was the protocol as a stream cipher to encrypt the cookie. However, not only was the
extremely awkward, but the processing time to execute the agreement, protocol extremely awkward, but the processing time to execute the
encrypt the key and sign the result was horrifically expensive - 15 agreement, encrypt the key and sign the result was horrifically
seconds(!) in a vintage Sun IPC. This scheme was quickly dropped in expensive - 15 seconds in a vintage Sun IPC. This scheme was quickly
favor of generic public key encryption.] 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 IP source and
destination addresses exchanged. The client generates the message digest
and verifies it matches the MAC in the packet. In order to deflect old
replays, the client verifies the key ID matches the last one sent. In
this mode the sequential structure of the key list is not exploited, but
doing it this way simplifies and regularizes the implementation while
making it nearly impossible for an intruder to guess the next key ID.
In broadcast mode clients normally do not send packets to the server, The server dance uses the cookie and each key ID on the key list in
except when first starting up to calibrate the propagation delay in turn to retrieve the autokey and generate the MAC in the NTP packet.
client/server mode. At the same time the client runs the Autokey The server uses the same values to generate the message digest and
protocol as in that mode. After obtaining and verifying the cookie, the verifies it matches the MAC in the packet. It then generates the MAC
client continues to obtain and verify the autokey values. To obtain for the response using the same values, but with the client and
these values, the client must provide the ID of the particular server server addresses exchanged. The client generates the message digest
association, since there can be more than one operating in the same and verifies it matches the MAC in the packet. In order to deflect
server. For this purpose, the NTP broadcast packet includes the old replays, the client verifies the key ID matches the last one
association ID in every packet sent, except when sending the first sent. In this mode the sequential structure of the key list is not
packet after generating a new key list, when it sends the autokey values exploited, but doing it this way simplifies and regularizes the
instead. implementation while making it nearly impossible for an intruder to
guess the next key ID.
In symmetric mode each peer keeps state variables related to the other. In broadcast dance clients normally do not send packets to the
A shared private cookie is conveyed using the same scheme as in server, except when first starting up to verify credentials and
client/server mode, except that the cookie is a random value. The key calibrate the propagation delay. At the same time the client runs the
list for each direction is generated separately by each peer and used broadcast dance to obtain the autokey values. The dance requires the
independently, but each is generated with the same cookie. There exists association ID of the particular server association, since there can
a possible race condition where each peer sends a cookie request message be more than one operating in the same server. For this purpose, the
before receiving the cookie response from the other peer. In this case, server packet includes the association ID in every response message
each peer winds up with two values, one it generated and one the other sent and, when sending the first packet after generating a new key
peer generated. The ambiguity is resolved simply by computing the list, it sends the autokey values as well. After obtaining and
working cookie as the exclusive-OR of the two values. verifying the autokey values, the client verifies further server
packets using the autokey sequence.
Once the client receives and validates the certificate, subsequent The symmetric dance is similar to the server dance and keeps only a
packets containing valid signed extension fields are presumed to contain small amount of state between the arrival of a packet and departure
valid time values, unless these values fall outside the valid interval of the reply. The key list for each direction is generated separately
specified on the certificate. However, unless the system clock has by each peer and used independently, but each is generated with the
already been set by some other proventic means, it is not known whether same cookie. The cookie is conveyed in a way similar to the server
these values actually represent a truechime or falsetick source. As the dance, except that the cookie is a random value. There exists a
protocol evolves, the NTP associations continue to accumulated time possible race condition where each peer sends a cookie request
values until a majority clique is available to synchronize the system message before receiving the cookie response from the other peer. In
clock. At this point the NTP intersection algorithm culls the this case, each peer winds up with two values, one it generated and
falsetickers from the population and the remaining truechimers are one the other peer generated. The ambiguity is resolved simply by
allowed to discipline the clock. computing the working cookie as the EXOR of the two values.
The time values for even falsetick sources form a proventic total Autokey choreography includes one or more exchanges, each with a
specific purpose, that must be completed in order. The client obtains
the server host name, digest/signature scheme and identity shcme in
the parameter exchange. It recursively obtains and verifies
certificates on the trail leading to a trusted certificate in the
certificate exchange and verifies the server identity in the identity
exchange. In the values exchange the client obtains the cookie and
autokey values, depending on the particular dance. Finally, the
client presents its self-signed certificate to the server for
signature in the sign exchange.
The ultimate security of Autokey is based on digitally signed
certificates and a certificate infrastructure compatible with [RFC-
2510] and [RFC-3280]. The Autokey protocol builds the certificate
trail from the primary servers, which presumably have trusted self-
signed certificates, recursively by stratum. Each stratum n + 2
server obtains the certificate of a stratum n server, presumably
signed by a stratum n - 1 server, and then the stratum n + 1 server
presentes its own self-signed certificate for signature by the
stratum n server. As the NTP subnet forms from the primary servers at
the root outward to the leaves, each server accumulates non-
duplicative certificates for all associations and for all trails. In
typical NTP subnets, this results in a good deal of useful
redundancy, so far not explointed in the present implementation.
In order to prevent masquerade, it is necessary for the stratum n
server to prove identity to the stratum n + 1 server when signing its
certificate. In many applications a number of servers share a single
security compartment, so it is only necessary that each server
verifies identity to the group. Although no specific identity scheme
is specified in this document, Appendix E describes a number of them
based on cryptographic challenge-response algorithms. The reference
implementation includes all of them with provision to add more if
required.
Once the certificates and identity have been validated, subsequent
packets are validated by digital signatures or autokey sequences.
These packets are presumed to contain valid time values; however,
unless the system clock has already been set by some other proventic
means, it is not known whether these values actually represent a
truechime or falsetick source. As the protocol evolves, the NTP
associations continue to accumulate 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.
The time values for truechimer sources form a proventic partial
ordering relative to the applicable signature timestamps. This raises ordering relative to the applicable signature timestamps. This raises
the interesting issue of how to mitigate between the timestamps of the interesting issue of how to mitigate between the timestamps of
different associations. It might happen, for instance, that the different associations. It might happen, for instance, that the
timestamp of some Autokey message is ahead of the system clock by some timestamp of some Autokey message is ahead of the system clock by
presumably small amount. For this reason, timestamp comparisons between some presumably small amount. For this reason, timestamp comparisons
different associations and between associations and the system clock are between different associations and between associations and the
avoided, except in the NTP intersection and clustering algorithms. system clock are avoided, except in the NTP intersection and
clustering algorithms and when determining whether a certificate has
expired.
Once the Autokey values have been instantiated, the protocol is normally Once the Autokey values have been instantiated, the dances are
dormant. In all modes except broadcast, packets are normally sent normally dormant. In all except the broadcast dance, packets are
without extension fields, unless the packet is the first one sent after normally sent without extension fields, unless the packet is the
generating a new key list or unless the client has requested the cookie first one sent after generating a new key list or unless the client
or autokey values. If for some reason the client clock is stepped, has requested the cookie or autokey values. If for some reason the
rather than slewed, all cryptographic and time values for all client clock is stepped, rather than slewed, all cryptographic and
associations are purged and the Autokey protocol restarted from scratch time values for all associations are purged and the dances in all
in all associations. This insures that stale values never propagate associations restarted from scratch. This insures that stale values
beyond a clock step. never propagate beyond a clock step. At intervals of about one day
the reference implementation purges all associations, refreshes all
signatures, garbage collects expired certificates and refreshes the
server seed.
Public Key Signatures and Timestamps 6. Public Key Signatures and Timestamps
While public key signatures provide strong protection against While public key signatures provide strong protection against
misrepresentation of source, computing them is expensive. This invites misrepresentation of source, computing them is expensive. This
the opportunity for an intruder to clog the client or server by invites the opportunity for an intruder to clog the client or server
replaying old messages or to originate bogus messages. A client by replaying old messages or to originate bogus messages. A client
receiving such messages might be forced to verify what turns out to be receiving such messages might be forced to verify what turns out to
an invalid signature and consume significant processor resources. be an invalid signature and consume significant processor resources.
In order to foil such attacks, every signed extension field carries a In order to foil such attacks, every signed extension field carries a
timestamp in the form of the NTP seconds at the signature epoch. The timestamp in the form of the NTP seconds at the signature epoch. The
signature span includes the timestamp itself together with optional signature spans the entire extension field including the timestamp.
additional data. If the Autokey protocol has verified a proventic source If the Autokey protocol has verified a proventic source and the NTP
and the NTP algorithms have validated the time values, the system clock algorithms have validated the time values, the system clock can be
can be synchronized and signatures will then carry a nonzero (valid) synchronized and signatures will then carry a nonzero (valid)
timestamp. Otherwise the system clock is unsynchronized and signatures timestamp. Otherwise the system clock is unsynchronized and
carry a zero (invalid) timestamp. Extension fields with invalid signatures carry a zero (invalid) timestamp. The protocol detects and
timestamps are discarded before any values are used or signatures discards replayed extension fields with old or duplicate timestamps,
verified. as well fabricated extension fields with bogus timestamps, before any
values are used or signatures verified.
There are three signature types currently defined: There are three signature types currently defined:
1. Cookie signature/timestamp: Each association has a cookie for use 1. Cookie signature/timestamp: Each association has a cookie for use
when generating a key list. The cookie value is determined along with when generating a key list. The cookie value is determined along with
the cookie signature and timestamp upon arrival of a cookie request the cookie signature and timestamp upon arrival of a cookie request
message. The values are returned in a a cookie response message. message. The values are returned in a a cookie response message.
2. Autokey signature/timestamp: Each association has a key list for 2. Autokey signature/timestamp: Each association has a key list for
generating the autokey sequence. The autokey values are determined along generating the autokey sequence. The autokey values are determined
with the autokey signature and timestamp when a new key list is along with the autokey signature and timestamp when a new key list is
generated, which occurs about once per hour in the reference generated, which occurs about once per hour in the reference
implementation. The values are returned in a autokey response message. implementation. The values are returned in a autokey response
message.
3. Public values signature/timestamp: The public key, certificate and 3. Public values signature/timestamp: All public key, certificate and
leapsecond table values are signed at the time of generation, which leapsecond table values are signed at the time of generation, which
occurs when the system clock is first synchronized to a proventic occurs when the system clock is first synchronized to a proventic
source, when the values have changed and about once per day after that, source, when the values have changed and about once per day after
even if these values have not changed. During protocol operations, each that, even if these values have not changed. During protocol
of these values and associated signatures and timestamps are returned in operations, each of these values and associated signatures and
the associated request or response message. While there are in fact timestamps are returned in the associated request or response
three public value signatures, the values are all signed at the same message. While there are in fact several public value signatures,
time, so there is only one public value timestamp. depending on the number of entries on the certificate list, the
values are all signed at the same time, so there is only one public
value timestamp.
The most recent timestamp of each type is saved for comparison. Once a The most recent timestamp received of each type is saved for
valid signature with valid timestamp has been received, messages with comparison. Once a valid signature with valid timestamp has been
invalid timestamps or earlier valid timestamps of the same type are received, messages with invalid timestamps or earlier valid
discarded before the signature is verified. For signed messages this timestamps of the same type are discarded before the signature is
deflects replays that otherwise might consume significant processor verified. For signed messages this deflects replays that otherwise
resources; for other messages the Autokey protocol deflects message might consume significant processor resources; for other messages the
modification or replay by a wiretapper, but not necessarily by a Autokey protocol deflects message modification or replay by a
middleman. In addition, the NTP protocol itself is inherently resistant wiretapper, but not necessarily by a middleman. In addition, the NTP
to replays and consumes only minimal processor resources. protocol itself is inherently resistant to replays and consumes only
minimal processor resources.
All cryptographic values used by the protocol are time sensitive and are All cryptographic values used by the protocol are time sensitive and
regularly refreshed. In particular, files containing cryptographic basis are regularly refreshed. In particular, files containing
values used by signature and encryption algorithms are regenerated from cryptographic basis values used by signature and encryption
time to time. It is the intent that file regenerations occur without algorithms are regenerated from time to time. It is the intent that
specific advance warning and without requiring prior distribution of the file regenerations occur without specific advance warning and without
file contents. While cryptographic data files are not specifically requiring prior distribution of the file contents. While
signed, every file name includes an extension called the filestamp, cryptographic data files are not specifically signed, every file is
which is a string of decimal digits representing the NTP seconds at the associated with a filestamp in the form of the NTP seconds at the
generation epoch. creation epoch. It is not the intent in this document to specify file
formats or names or encoding rules; however, whatever conventions are
used must support a NTP filestamp in one form or another. Additional
details specific to the reference implementation are in Appendix B.
Filestamps and timestamps can be compared in any combination and use the Filestamps and timestamps can be compared in any combination and use
same conventions. It is necessary to compare them from time to time to the same conventions. It is necessary to compare them from time to
determine which are earlier or later. Since these quantities have a time to determine which are earlier or later. Since these quantities
granularity only to the second, such comparisons are ambiguous if the have a granularity only to the second, such comparisons are ambiguous
values are the same. Thus, the ambiguity must be resolved for each if the values are the same. Thus, the ambiguity must be resolved for
comparison operation as described below. each comparison operation as described in Appendix C.
It is important that filestamps be proventic data; thus, they cannot be It is important that filestamps be proventic data; thus, they cannot
produced unless the producer has been synchronized to a proventic be produced unless the producer has been synchronized to a proventic
source. As such, the filestamps represent a total ordering of creation source. As such, the filestamps throughout the NTP subnet represent a
epoches and serve as means to expunge old data and insure new data are partial ordering of all creation epoches and serve as means to
consistent. As the data are forwarded from server to client, the expunge old data and insure new data are consistent. As the data are
filestamps are preserved, including those for certificate and forwarded from server to client, the filestamps are preserved,
leapseconds files. Packets with older filestamps are discarded before including those for certificate and leapseconds files. Packets with
spending cycles to verify the signature. older filestamps are discarded before spending cycles to verify the
signature.
Autokey Dances 7. Autokey Protocol Overview
This section presents an overview of the three Autokey protocols, called This section presents an overview of the three server, symmetric and
dances, corresponding to the NTP client/server, broadcast and symmetric broadcast dances. Each dance is designed to be nonintrusive and to
active/passive modes. Each dance is designed to be nonintrusive and to require no additional packets other than for regular NTP operations.
require no additional packets other than for regular NTP operations. The The NTP and Autokey protocols operate independently and
NTP protocol and Autokey dance operate independently and simultaneously simultaneously and use the same packets. When the preliminary dance
and use the same packets. When the Autokey dance is over, subsequent exchanges are complete, subsequent packets are validated by the
packets are authenticated by the autokey sequence and thus considered autokey sequence and thus considered proventic as well. Autokey
proventic as well. Autokey assumes clients poll servers at a relatively assumes clients poll servers at a relatively low rate, such as once
low rate, such as once per minute. In particular, it is assumed that a per minute. In particular, it is assumed that a request sent at one
request sent at one poll opportunity will normally result in a response poll opportunity will normally result in a response before the next
before the next poll opportunity. poll opportunity.
The Autokey protocol data unit is the extension field, one or more of The Autokey protocol data unit is the extension field, one or more of
which can be piggybacked in the NTP packet. An extension field contains which can be piggybacked in the NTP packet. An extension field
either a request with optional data or a response with data. To avoid contains either a request with optional data or a response with data.
deadlocks, any number of responses can be included in a packet, but only To avoid deadlocks, any number of responses can be included in a
one request. A response is generated for every request, even if the packet, but only one request. A response is generated for every
requestor is not synchronized or proventicated. Some requests and most request, even if the requestor is not synchronized to a proventic
responses carry timestamped signatures. The signature covers the data, source, but contain meaningful data only if the responder is
timestamp and filestamp, where applicable. Only if the packet passes all synchronized to a proventic source. Some requests and most responses
extension field tests is the signature verified. carry timestamped signatures. The signature covers the entire
extension field, including the timestamp and filestamp, where
applicable. Only if the packet passes all extension field tests are
cycles spent to verify the signature.
Dance Steps All dances begin with the parameter exchange where the client obtains
the server host name and status word specifying the digest/signature
scheme it will use and the identity schemes it supports. The dance
continues with the certificate exchange where the client obtains and
verifies the certificates along the trail to a trusted, self-cigned
certifidate, usually, but not necessarily, provided by a primary
(stratum 1) server. Primary servers are by design proventic with
trusted, self-signed certificates.
The protocol state machine is very simple. The state is determined by However, the certificate trail is not sufficient protection against
nine bits, four provided by the server, five determined by the client middleman attacks unless an identity scheme such as described in
association operations. The nine bits are stored along with the Appendix E or proof-of-posession scheme in [RFC-2875] is available.
digest/signature scheme identifier in the host status word of the server While the protocol for a generic challenge/response scheme is defined
and in the association status word of the client. In all dances the in this document, the choice of one or another required or optional
client first sends an Association request message and receives the identification schemes is yet to be determined. If all certificate
Association response specifying which cryptographic values the server is signatures along the trail are verified and the server identity is
prepared to offer and the digest/signature scheme it will use. confirmed, the server is declared proventic. Once declared proventic,
the client verifies packets using digital signatures and/or the
autokey sequence.
If compatible, the client installs the server status word as the Once synchronized to a proventic source, the client continues with
association status word and sends a Certificate request message to the the sign exchange where the server acting as CA signs the client
server. The server returns a Certificate response including the certificate. The CA interprets the certificate as a X.509v3
certificate and signature. The reference implementation requires the certificate request, but verifies the signature if it is self-signed.
certificate to be self-signed, which serves as an additional consistency The CA extracts the subject, issuer, extension fields and public key,
check. This check may be removed in future and replaced with a then builds a new certificate with these data along with its own
certificate trail mechanism. If the certificate contents and signature serial number and begin and end times, then signs it using its own
are valid, NTP timestamps in this and subsequent messages with valid public key. The client uses the signed certificate in its own role as
signatures are considered proventic. CA for dependent clients.
In client/server mode the client sends a Cookie request message In the server dance the client presents its public key and requests
including the public key of the host key. The server constructs the the server to generate and return a cookie encrypted with this key.
cookie as described above and encrypts it using this key. It sends a The server constructs the cookie as described above and encrypts it
Cookie response including the encrypted cookie to the client and using this key. The client decrypts the cookie for use in generating
expunges all values resulting from the calculations in order to remain the key list. A similar dance is used in symmetric mode, where one
stateless. The client verifies the signature and decrypts the cookie. A peer acts as the client and the other the server. In case of
similar dance is used in symmetric modes, but the cookie is generated as overlapping messages, each peer generates a cookie and the agreed
a random value. common value is computed as the EXOR of the two cookies.
The cookie is used to construct the key list and autokey values in all The cookie is used to generate the key list and autokey values in all
modes. In client/server mode there is no need to provide these values to dances. In the server dance there is no need to provide these values
the server, so once the cookie has been obtained the client can generate to the server, so once the cookie has been obtained the client can
the key list and validate succeeding packets directly. In other modes generate the key list and validate succeeding packets directly. In
the client retrieves the autokey values from the server using an Autokey other dances the client requests the autokey values from the server
message exchange. Once these values have been received, the client or, in some modes, the server provides them as each new key list is
validates succeeding packets using the autokey sequence as described generated. Once these values have been received, the client validates
succeeding packets using the autokey sequence as described
previously. previously.
A final exchange occurs when the server has the leapseconds table, as A final exchange occurs when the server has the leapseconds table, as
indicated in the host status word. If so, the client obtains the table indicated in the host status word. If so, the client requests the
and compares the filestamp with its own leapseconds table filestamp, if table and compares the filestamp with its own leapseconds table
available. If the server table is newer than the client table, the filestamp, if available. If the server table is newer than the client
client replaces its table with the server table. The client, acting as table, the client replaces its table with the server table. The
server, can now provide the most recent table to any of its own client, acting as server, can now provide the most recent table to
dependent clients. In symmetric modes, this results in both peers having any of its dependent clients. In symmetric mode, this results in both
the newest table. peers having the newest table.
Status Words 8. Autokey State Machine
Each sever and client operating as a server implements a host status This section describes the formal model of the Autokey state machine,
word and an association status word with the format and content shown its state variables and the state transition functions.
below. The low order four host status bits are lit during host
initialization, depending on whether cryptographic data files are
present or not; the next four association bits are dark. There are two
additional bits implemented separately. The high order 16 bits specify
the message digest/signature encryption scheme.
The host status word is provided to clients in the Association response 8.1 Status Word
message. The client initializes the association status word and then
lights and dims the association bits as the dance proceeds. Each server and client operating also as a server implements a host
status word, while each client implements a server status word for
each server. Both words have the format and content shown below. The
low order 16 bits of the status words define the state of the Autokey
protocol, while the high order 16 bits specify the message
digest/signature encryption scheme. Bits 24-31 of the status word are
reserved for server use, while bits 16-23 are reserved for client
use. There are four additional bits implemented separately.
The host status word is included in the ASSOC request and response
messages. The client copies this word to the associatino status word
and then lights additional association bits as the dance proceeds.
Once lit, these bits never come dark unless a general reset occurs
and the protocol is restarted from the beginning.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |L|K|C|A|L|S|E|E| | | |L|S|A|C|P|I|V| | |L|E|
| Digest/Signature NID | Reserved |P|E|K|U|P|I|N|N| | Digest/Signature NID | |P|G|U|K|R|F|A| IDN | |P|N|
| | |T|Y|Y|T|F|G|C|B| | | |T|N|T|Y|V|F|L| | |F|B|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The host status bits are defined as follows: The host status bits are defined as follows:
ENB - Lit if the server implements the Autokey protocol and is prepared ENB - Lit if the server implements the Autokey protocol and is
to dance. prepared to dance.
ENC - Lit if the server has loaded a valid encryption key file. This bit LPF
is normally lit, but can dim if an error occurs. Lit if the server has loaded a valid leapseconds file. This bit can
be either lit or dim.
SIG - Lit if the server has loaded a valid signature key file. This bit IDN
is included primarily for error supervision and can be either lit or These three bits select which identity scheme is in use. While
dim. specific coding for various schemes is yet to be determined, the
schemes available in the reference implementation and described in
Appendix E include the following.
LPF - Lit if the server has loaded a valid leapseconds file. This bit 0x0 Trusted Certificate (TC) Scheme (default)
can be either lit or dim. 0x1 Private Certificate (PC) Scheme
0x2 Schnorr aka Identify-Friendly-or-Foe (IFF) Scheme
0x4 Guillard-Quisquater (GC) Scheme
The client association status bits are defined as follows: The PC scheme is exclusive of any other scheme. Otherwise, either
none or the IFF scheme or the GC scheme or both can be selected.
AUT - Lit when the certificate is present and validated. When lit, The server status bits are defined as follows:
signed values in subsequent messages are presumed proventic.
CKY - Lit when the cookie is first received and validated. VAL 0x0100
Lit when the server certificate and public key are validated.
KEY - Lit when the autokey values are first received and validated. When IFF 0x0200
lit, clients can validate packets without extension fields according to Lit when the server identity credentials are confirmed by one of
several schemes described later.
PRV 0x0400
Lit when the server signature is verified using the public key and
identity credentials. Also called the proventic bit elsewhere in this
document. When lit, signed values in subsequent messages are presumed
proventic, but not necessarily time-synchronized.
CKY 0x0800
Lit when the cookie is received and validated. When lit, key lists
can be generated.
AUT 0x1000
Lit when the autokey values are received and validated. When lit,
clients can validate packets without extension fields according to
the autokey sequence. the autokey sequence.
LPT - Lit when the leapseconds table is received and validated. SGN 0x2000
Lit when the host certificate is signed by the server.
An additional bit LST not part of the association status word lights LPT 0x4000
when the key list is regenerated and signed and dims when the autokey Lit when the leapseconds table is received and validated.
values are transmitted. This is necessary to avoid livelock under some
conditions.
An additional bit LBK not part of the association status word lights There are four additional status bits LST, LBK, DUP and SYN not
when the association transmit timestamp matches the packet originate included in the status word. All except SYN are association
timestamp and dims otherwise. If lit, this confirms the packet was properties, while SYN is a host property. These bits may be lit or
received in response to one previously sent by this association. dim as the protocol proceeds; all except LST are active whether or
not the protocol is running. LST is lit when the key list is
regenerated and signed and comes dim after the autokey values have
been transmitted. This is necessary to avoid livelock under some
conditions. SYN is lit when the client has synchronized to a
proventic source and never dim after that. There are two error bits:
LBK indicates the received packet does not match the last one sent
and DUP indicates a duplicate packet. These bits, which are described
in Appendix C, are lit if the corresponding error has occurred for
the current packet and dim otherwise.
Host State Variables 8.2 Host State Variables
Host Name Host Name
The name of the host returned by the Unix gethostname() library The name of the host returned by the Unix gethostname() library
function. It must agree with the subject and issuer name in the function. The name must agree with the subject name in the host
certificate. certificate.
Host Key Host Status Word
The RSA key from the host key file and used to encrypt/decrypt cookies. This word is initialized when the host first starts up. The format is
It carries the public value timestamp and the filestamp at the host key described above.
file creation epoch. This is also the signature key, unless a signature
key is specified.
Public Key Host Key
The public encryption key for the Cookie request message and derived The RSA public/private key used to encrypt/decrypt cookies. This is
from the host key. It carries the public value timestamp and the also the default sign key.
filestamp at the host key file creation epoch.
Sign Key Sign Key
The RSA or DSA key from the sign key file and used to encrypt The RSA or DSA public/private key used to encrypt/decrypt signatures
signatures. It carries the public value timestamp and the filestamp at when the host key is not used for this purpose.
the sign key file creation epoch.
Certificate Sign Digest
The X.509 certificate from the certificate file. It carries the public The message digest algorithm used to compute the signature before
value timestamp and the filestamp at the certificate file creation encryption.
epoch.
Leapseconds Table, Leapseconds Table Filestamp IFF Parameters
The parameters used in the IFF identity scheme described in Appendix
E.
GQ Parameters
The parameters used in the GQ identity scheme described in Appendix
E.
GQ keys
The public/private key used in the GQ identity scheme described in
Appendix E.
Server Seed
The private value hashed with the IP addresses to construct the
cookie.
Certificate Information Structure (CIS)
A structure including certain information fields from an X.509v3
certificate, together with the certificate itself encoded in ASN.1
syntax and including X.509v3 extension fields. Each structure carries
the public value timestamp and the filestamp of the certificate file
where it was generated. Elsewhere in this document the CIS will not
be distinguished from the certificate unless noted otherwise.
Certificate List
CIS structures are stored on the certificate list in order of
arrival, with the most recently received CIS placed first on the
list. The list is initialized with the CIS for the host certificate,
which is read from the certificate file. Additional CIS entries are
pushed on the list as certificates are obtained from the servers
during the certificate exchange. CIS entries are discarded if
overtaken by newer ones or expire due to old age.
Host Certificate
The self-signed X.509v3 certificate for the host. The subject and
issuer fields consist of the host name, while the message
digest/signature encryption scheme consists of the sign key and
message digest defined above. Optional information used in the
identity schemes is carried in X.509v3 extension fields compatible
with [RFC-3280].
Public Key Values
The public encryption key for the COOKIE request, which consists of
the public value of the host key. It carries the public values
timestamp and the filestamp of the host key file.
Leapseconds Table Values
The NIST leapseconds table from the NIST leapseconds file. It carries The NIST leapseconds table from the NIST leapseconds file. It carries
the public value timestamp and the filestamp at the leapseconds file the public values timestamp and the filestamp of the leapseconds
creation epoch. file.
Digest/signature NID 8.3 Client State Variables (all modes)
The identifier of the message digest/signature encryption scheme derived
from the sign key. It must agree with the NID on the certificate.
Client Association State Variables Association ID
The association ID used in responses. It is assigned when the
association is mobilized.
Peer Association ID Server Association ID
The association ID of the peer as received in a response message. The server association ID used in requests. It is initialized from
the first nonzero association ID field in a response.
Host Name Server Subject Name
The name of the host returned by the Association response. It must agree The server host name determined in the parameter exchange.
with the subject name in the certificate.
Digest/Signature NID Server Issuer Name
The identifier of the message digest/signature encryption scheme The host name signing the certificate. It is extracted from the
returned in the Association response message. It must agree with the current server certificate upon arrival and used to request the next
value encoded in the certificate. item on the certificate trail.
Public Values Timestamp Server Status Word
The timestamp returned by the latest Certificate response, Cookie The host status word of the server determined in the parameter
request or Leapseconds message. exchange.
Certificate Server Public Key
The X.509 certificate returned in the certificate response message, The public key used to decrypt signatures. It is extracted from the
together with its timestamp and filestamp. first certificate received, which by design is the server host
certificate.
Cookie Server Message Digest
The cookie returned in a Cookie response message, together with its The digest/signature scheme determined in the parameter exchange.
Identification Challenge
A 512-bit nonce used in the identification exchange.
Group Key
A 512-bit secret group key used in the identification exchange. It
identifies the cryptographic compartment shared by the server and
client.
Receive Cookie Values
The cookie returned in a COOKIE response, together with its timestamp
and filestamp.
Receive Autokey Values
The autokey values returned in an AUTO response, together with its
timestamp and filestamp. timestamp and filestamp.
Receive Autokey values Receive Leapsecond Values
The autokey values returned in an Autokey response message, together The leapsecond table returned by a LEAP response, together with its
with its timestamp and filestamp. timestamp and filestamp.
Server Association State Variables (broadcast and symmetric modes) 8.4 Server State Variables (broadcast and symmetric modes)
Association ID Send Cookie Values
The association ID of the server for use in client request messages. The cookie encryption values, signature and timestamps.
Send Autokey Values Send Autokey Values
The autokey values, signature and timestamp. The autokey values, signature and timestamps.
Key List Key List
A sequence of key IDs starting with a random autokey seed and each A sequence of key IDs starting with the autokey seed and each
pointing to the next. It is computed timestamped and signed at the next pointing to the next. It is computed, timestamped and signed at the
poll opportunity when the key list is empty. next poll opportunity when the key list becomes empty.
Autokey Seed
The private value used to initialize the key list. It is randomized for
each new key list.
Current Key Number Current Key Number
The index of the entry on the Key List to be used at the next poll The index of the entry on the Key List to be used at the next poll
opportunity. opportunity.
Send Encrypt Values (symmetric modes only) 8.5 Autokey Messages
The encrypted cookie, signature and timestamp computed upon arrival of
the Cookie request message. These data are held until the next poll
opportunity.
Server seed There are currently eight Autokey requests and eight corresponding
The private value hashed with the IP addresses to construct the cookie responses. An abbreviated description of these messages is given
used in client/server mode. It is randomized when the public value below; the detailed formats are described in Appendix A.
signatures are refreshed.
Autokey Messages Association Message (ASSOC)
This message is used in the parameter exchange. The client sends the
request with its host name and status word. The server sends the
response with its host name and status word. If the server response
is acceptable, ENB is lit. When the PC identity scheme is in use, the
ASSOC response lights VAL, IFF and SIG, since the IFF exchange is
complete at this point.
There are currently five Autokey request types and five corresponding Certificate Message (CERT)
responses. An abbreviated description of these messages is given below; In the certificate exchange the client sends the request with the
the detailed formats are described in Appendix A. server subject name and the server responds with the certificate with
that subject name. In the TC identity scheme the client sends the
request with the server issuer name and the server responds with the
certificate with that subject name. In either case if the certificate
is valid, the client lights VAL.
Association Message (1) Cookie Message (COOKIE)
The client sends the request to retrieve the host status word and host The client sends the request with its public key. The server responds
name. The server responds with these values. with the cookie encrypted with this public key. If the cookie is
valid, the client lights CKY.
Certificate Message (2) Autokey Message (AUTO)
The client sends the request to retrieve the server certificate. The The client sends the request to retrieve the Autokey values. The
server responds with the certificate. server responds with these values. If the values are valid, the
client lights AUT.
Cookie Message (3) Leapseconds Message (LEAP)
The client sends the request, including the public member of the host The client sends the request with its leapseconds table, if
key, to retrieve the cookie. The server responds with the cookie available. The server responds with its own leapseconds table. Both
encrypted with the public key. the client and server agree to use the version with the latest
filestamp. When the latest version is identified, the client lights
LPT.
Autokey Message (4) Sign Message (SIGN)
The client sends the request to retrieve the autokey values, if The client sends the request with its host certificate. The server
available. The server responds with these values. extracts the subject, public key and optional extension fields, then
returns a certificate signed using its own public key. If the
certificate is valid when received by the client, it is linked in the
certificate list and the client lights SGN.
Leapseconds Message (5) IFF Message (IFF)
The client sends the request including its leapseconds table, if This exchange is used with the IFF identity scheme described in
available. The server responds with its own leapseconds table. Both the Appendix E. If the server identity is confirmed, the client lights
client and server agree to use the version with the latest filestamp. IFF and PRV.
State Transitions GQ Message (GQ)
This exchange is used with the GQ identity scheme described in
Appendix E. If the server identity is confirmed, the client lights
IFF and PRV.
The state transitions of the three dances are shown below. The 8.5 Protocol State Transitions
capitalized truth values represent the association status word bits,
except for the SYNC value, which is true when the host is synchronized
to a proventic source and false otherwise. All truth values are
initialized false and become true upon the arrival of a specific
response messages, as detailed in the above status bits description.
Client/Server Dance The protocol state machine is very simple but robust. The state is
determined by the server status bits defined above. The state
transitions of the three dances are shown below. The capitalized
truth values represent the server status bits. All server bits are
initialized dark and light up upon the arrival of a specific response
message, as detailed above.
The client/server dance begins when the client sends an Association When the system clock is first set and about once per day after that,
request message to the server. It ends upon arrival of the Cookie or when the system clock is stepped, the server seed is refreshed,
response, which lights the CKY and KEY bits. Subsequent packets received signatures and timestamps updated and the protocol restarted in all
without extension fields are validated by the autokey sequence. An associations. When the server seed is refreshed or a new certificate
optional final exchange is possible to retrieve the leapseconds table. or leapsecond table is received, the public values timestamp is reset
to the current time and all signatures are recomputed.
8.5.1 Server Dance
The server dance begins when the client sends an ASSOC request to the
server. It ends when the first signature is verified and PRV is lit.
Subsequent packets received without extension fields are validated by
the autokey sequence. An optional LEAP exchange updates the
leapseconds table. Note the order of the identity exchanges and that
only the first one will be used if multiple schemes are available.
Note also that the SIGN and LEAP requests are not issued until the
client has synchronized to a proventic source.
while (1) { while (1) {
wait_for_next_packet; wait_for_next_poll;
make_NTP_header; make_NTP_header;
if (response_ready) if (response_ready)
send_response; send_response;
if (!ENB) if (!ENB) /* parameters exchange */
send_Association_request; ASSOC_request;
else if (!CRF) else if (!VAL) /* certificate exchange */
send_Certificate_request; CERT_request(Host_Name);
else if (!CKY) else if (IDN & GQ && !IFF) /* GQ identity exchange */
send_Cookie_request; GQ_challenge;
else if (LPF & !LPT) else if (IDN & IFF && !IFF)/* IFF identity exchange */
send_Leapseconds_request; IFF_challenge;
else if (!IFF) /* TC identity exchange */
CERT_request(Issuer_Name);
else if (!CKY) /* cookie exchange */
COOKIE_request;
else if (SYN && !SIG) /* sign exchange */
SIGN_request(Host_Certificate);
else if (SYN && LPF & !LPT)/* leapseconds exchange */
LEAP_request;
} }
Broadcast Client Dance When the PC identity scheme is in use, the ASSOC response lights VAL,
IFF and SIG, the COOKIE response lights CKY and AUT and the first
valid signature lights PRV.
The broadcast client dance begins when the client receives the first 8.5.2 Broadcast Dance
broadcast packet, which includes an Association response with the
association ID. The broadcast client uses the association ID to initiate THe only difference between the broadcast and server dances is the
a client/server dance in order to calibrate the propagation delay. The inclusion of an autokey values exchange following the cookie
dance ends upon arrival of the Autokey response, which lights the KEY exchange. The broadcast dance begins when the client receives the
bit. Subsequent packets received without extension fields are validated first broadcast packet, which includes an ASSOC response with
by the autokey sequence. An optional final exchange is possible to association ID. The broadcast client uses the association ID to
retrieve the leapseconds table. When the server generates a new key initiate a server dance in order to calibrate the propagation delay.
list, the server replaces the Association response with an Autokey
response in the first packet sent. The dance ends when the first signature is verified and PRV is lit.
Subsequent packets received without extension fields are validated by
the autokey sequence. An optional LEAP exchange updates the
leapseconds table. When the server generates a new key list, the
server replaces the ASSOC response with an AUTO response in the first
packet sent.
while (1) { while (1) {
wait_for_next_packet; wait_for_next_poll;
make_NTP_header; make_NTP_header;
if (response_ready) if (response_ready)
send_response; send_response;
if (!ENB) if (!ENB) /* parameters exchange */
send_Association_request; ASSOC_request;
else if (!CRF) else if (!VAL) /* certificate exchange */
send_Certificate_request; CERT_request(Host_Name);
else if (!CKY) else if (IDN & GQ && !IFF) /* GQ identity exchange */
send_Cookie_request; GQ_challenge;
else if (!KEY) else if (IDN & IFF && !IFF)/* IFF identity exchange */
send_Autokey_request; IFF_challenge;
else if (LPF & !LPT) else if (!IFF) /* TC identity exchange */
send_Leapseconds_request; CERT_request(Issuer_Name);
else if (!CKY) /* cookie exchange */
COOKIE_request;
else if (!AUT) /* autokey values exchange */
AUTO_request;
else if (SYN && !SIG) /* sign exchange */
SIGN_request(Host_Certificate);
else if (SYN && LPF & !LPT)/* leapseconds exchange */
LEAP_request;
} }
Symmetric Dance When the PC identity scheme is in use, the ASSOC response lights VAL,
IFF and SIG, the COOKIE response lights CKY and AUT and the first
valid signature lights PRV.
The symmetric active dance begins when the active peer sends an 8.5.3 Symmetric Dance
Association request to the passive peer. The passive peer mobilizes an
association and steps the same dance from the beginning. Until the
active peer is synchronized to a proventic source (which could be the
passive peer) and can sign messages, the passive peer will loop waiting
to light the CRF bit and the active peer will skip the cookie exchange.
Meanwhile, the active peer retrieves the certificate and autokey values The symmetric dance is intricately choreographed. It begins when the
from the passive peer and lights the KEY bit. When for some reason active peer sends an ASSOC request to the passive peer. The passive
either peer generates a new key list, at the first opportunity the peer peer mobilizes an association and both peers step the same dance from
sends the autokey values; that is, it pushes the values rather than the beginning. Until the active peer is synchronized to a proventic
pulls them. This is to prevent a possible deadlock where each peer is source (which could be the passive peer) and can sign messages, the
waiting for values from the other one. passive peer loops waiting for the timestamp in the ASSOC response to
light up. Until then, the active peer dances the server steps, but
skips the sign, cookie and leapseconds exchanges.
while (1) { while (1) {
wait_for_next_packet; wait_for_next_poll;
make_NTP_header; make_NTP_header;
if (response_ready) if (!ENB) /* parameters exchange */
send_response; ASSOC_request;
if (!ENB) else if (!VAL) /* certificate exchange */
send_Association_request; CERT_request(Host_Name);
else if (!CRF) else if (IDN & GQ && !IFF) /* GQ identity exchange */
send_Certificate_request; GQ_challenge;
else if (!CKY & SYNC) else if (IDN & IFF && !IFF)/* IFF identity exchange */
send_Cookie_request; IFF_challenge;
else if (LST) else if (!IFF) /* TC identity exchange */
send_Autokey_response; CERT_request(Issuer_Name);
else if (!KEY) else if (SYN && !SIG) /* sign exchange */
send_Autokey_request; SIGN_request(Host_Certificate);
else if (LPF & !LPT & SYNC) else if (SYN && !CKY) /* cookie exchange */
send_Leapseconds_request; COOKIE_request;
else if (!LST) /* autokey values response */
AUTO_response;
else if (!AUT) /* autokey values exchange */
AUTO_request;
else if (SYN && LPF & !LPT)/* leapseconds exchange */
LEAP_request;
} }
Once the active peer has synchronized to a proventic source, it includes When the PC identity scheme is in use, the ASSOC response lights VAL,
timestamped signatures with its messages. The passive peer, which has IFF and SIG, the COOKIE response lights CKY and AUT and the first
been stalled waiting for the CRF bit to light and the active peer, which valid signature lights PRV.
now finds the SYNC bit lit, continues their respective dances. The next
message sent by either peer is a Cookie request. The recipient rolls a
random cookie, lights its CKY bit and returns the encrypted cookie in
the Cookie response. The recipient decrypts the cookie and lights its
CKY bit.
It is not a protocol error if both peers happen to send a cookie request Once the active peer has synchronized to a proventic source, it
at the same time. In this case both peers will have two values, one includes timestamped signatures with its messages. The first thing it
generated by one peer and the other received from the other peer. In does after lighting timestamps is dance the sign exchange so that the
such cases the working cookie is constructed as the exclusive-OR of the passive peer can survive the default identity exchange, if necessary.
two values. This is pretty wierd, since the passive peer will find the active
certificate signed by its own public key.
At the next packet transmission opportunity, either peer generates a new The passive peer, which has been stalled waiting for the active
key list and lights the LST bit; however, there may already be an timestamps to light up, now mates the dance. The initial value of the
Autokey request queued for transmission and the rules say no more than cookie is zero. If a COOKIE response has not been received by either
one request in a packet. When available, either peer sends an Autokey peer, the next message sent is a COOKIE request. The recipient rolls
response and clears the LST bit. The recipient initializes the autokey a random cookie, lights CKY and returns the encrypted cookie. The
values, clears the LST bit and lights the KEY bit. Subsequent packets recipient decrypts the cookie and lights CKY. It is not a protocol
received without extension fields are validated by the autokey sequence. error if both peers happen to send a COOKIE request at the same time.
In this case both peers will have two values, one generated by itself
peer and the other received from the other peer. In such cases the
working cookie is constructed as the EXOR of the two values.
The above description assumes the active peer synchronizes to the At the next packet transmission opportunity, either peer generates a
passive peer, which itself is synchronized to some other source, such as new key list and lights LST; however, there may already be an AUTO
a radio clock or another NTP server. In this case, the active peer is request queued for transmission and the rules say no more than one
operating at a stratum level one greater than the passive peer and so request in a packet. When available, either peer sends an AUTO
the passive peer will not synchronize to it unless it loses its own response and dims LST. The recipient initializes the autokey values,
sources and the active peer itself has another source. dims LST and lights AUT. Subsequent packets received without
extension fields are validated by the autokey sequence.
Key Refreshment The above description assumes the active peer synchronizes to the
passive peer, which itself is synchronized to some other source, such
as a radio clock or another NTP server. In this case, the active peer
is operating at a stratum level one greater than the passive peer and
so the passive peer will not synchronize to it unless it loses its
own sources and the active peer itself has another source.
About once per day the server seed is randomized and the signatures 9. Error Recovery
recomputed. The operations are:
while (1) { The Autokey protocol state machine includes provisions for various
wait_for_next_refresh; kinds of error conditions that can arise due to missing files,
crank_random_generator; corrupted data, protocol violations and packet loss or misorder, not
generate_autokey_private_value; to mention hostile intrusion. This section describes how the protocol
if (!SYNC) responds to reachability and timeout events which can occur due to
continue; such errors. Appendix C contains an extended discussion on error
update_public_value_timestamp; checking and timestamp validation.
compute_signatures;
}
Error Recovery A persistent NTP association is mobilized by an entry in the
configuration file, while an ephemeral association is mobilized upon
the arrival of a broadcast, manycast or symmetric active packet. A
general reset reinitializes all association variables to the initial
state when first mobilized. In addition, if the association is
ephemeral, the association is demobilized and all resources acquired
are returned to the system.
The protocol state machine which drives the various Autokey operations Every NTP association has two variables which maintain the liveness
includes provisions for various kinds of error conditions that can arise state of the protocol, the 8-bit reachability register defined in
due to missing files, corrupted data, protocol violations and packet [RFC-1305] and the watchdog timer, which is new in NTPv4. At every
loss or misorder, not to mention hostile intrusion. There are two poll interval the reachability register is shifted left, the low
mechanisms which maintain the liveness state of the protocol, the order bit is dimmed and the high order bit is lost. At the same time
reachability register defined in RFC-1305 and the watchdog timer, which the watchdog counter is incremented by one. If an arriving packet
is new in NTP Version 4. passes all authentication and sanity checks, the rightmost bit of the
reachability register is lit and the watchdog counter is set to zero.
If any bit in the reachability register is lit, the server is
reachable, otherwise it is unreachable.
The reachability register is an 8-bit register that shifts left with 0 When the first poll is sent by an association, the reachability
replacing the rightmost bit. A shift occurs for every poll interval, register and watchdog counter are zero. If the watchdog counter
whether or not a poll is actually sent. If an arriving packet passes all reaches 16 before the server becomes reachable, a general reset
authentication and sanity checks, the rightmost bit is set to 1. If any occurs. This resets the protocol and clears any acquired state before
bit in this register is a 1, the server is reachable, otherwise it is trying again. If the server was once reachable and then becomes
unreachable. If the server was once reachable and then becomes unreachable, a general reset occurs. In addition, if the watchdog
unreachable, a general reset is performed. A general reset reinitializes counter reaches 16 and the association is persistent, the poll
all association variables to the state when first mobilized and returns interval is doubled. This reduces the network load for packets that
all acquired resources to the system. In addition, if the association is are unlikely to elicit a response.
not configured, it is demobilized until the next packet is received.
The watchdog timer increments for every poll interval, whether or not a At each state in the protocol the client expects a particular
poll is actually sent and regardless of the reachability state. The response from the server. A request is included in the NTP packet
counter is set to zero upon arrival of a packet from a proventicated sent at each poll interval until a valid response is received or a
source, as determined by the Autokey protocol. In the reference general reset occurs, in which case the protocol restarts from the
implementation, if the counter reaches 16 a general reset is performed. beginning. A general reset also occurs for an association when an
In addition, if the association is configured, the poll interval is unrecoverable protocol error occurs. A general reset occurs for all
doubled. This reduces the network load for packets that are unlikely to associations when the system clock is first synchronized or the clock
elicit a response. is stepped or when the server seed is refreshed.
At each state in the protocol the client expects a particular response There are special cases designed to quickly respond to broken
from the server. A request is included in the NTP message sent at each associations, such as when a server restarts or refreshes keys. Since
poll interval until a valid response is received or a general reset the client cookie is invalidated, the server rejects the next client
occurs, in which case the protocol restarts from the beginning. In some request and returns a crypto-NAK packet. Since the crypto-NAK has no
cases noted below, certain kinds of errors cause appropriate action MAC, the problem for the client is to determine whether it is
which avoids the somewhat lengthy timeout/restart cycle. While this legitimate or the result of intruder mischief. In order to reduce the
behavior might be considered rather conservative, the advantage is that vulnerability in such cases, the crypto-NAK, as well as all
old cryptographic and time values can never persist from one responses, is believed only if the result of a previous packet sent
mobilization to the next. by the client and not a replay, as confirmed by the LBK and DUP
status bits described above. While this defense can be easily
circumvented by a middleman, it does deflect other kinds of intruder
warfare.
There are a number of situations where some event happens that causes 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 the remaining autokeys on the key list to become invalid. When one of
these situations happens, the key list and associated autokeys in the these situations happens, the key list and associated autokeys in the
key cache are purged. A new key list, signature and timestamp are key cache are purged. A new key list, signature and timestamp are
generated when the next NTP message is sent, assuming there is one. generated when the next NTP message is sent, assuming there is one.
Following is a list of these situations. Following is a list of these situations.
1. When the cookie value changes for any reason. 1. When the cookie value changes for any reason.
2. When a client switches from client/server mode to broadcast mode. 2. When a client switches from server mode to broadcast mode. There
There is no further need for the key list, since the client will not is no further need for the key list, since the client will not
transmit again. transmit again.
3. When the poll interval is changed. In this case the calculated 3. When the poll interval is changed. In this case the calculated
expiration times for the keys become invalid. expiration times for the keys become invalid.
4. When a general reset is performed. 4. If a problem is detected when an entry is fetched from the key
list. This could happen if the key was marked non-trusted or timed
5. If a problem is detected when an entry is fetched from the key list. out, either of which implies a software bug.
This could happen if the key was marked non-trusted or timed out, either
of which implies a software bug.
6. When the signatures are refreshed, the key lists for all associations
are purged.
7. When the client is first synchronized or the system clock is stepped,
the key lists for all associations are purged.
There are special cases designed to quickly respond to broken
associations, such as when a server restarts or refreshes keys. Since
the client cookie is invalidated, the server rejects the next client
request and returns a crypto-NAK packet. Since the crypto-NAK has no
MAC, the problem for the client is to determine whether it is legitimate
or the result of intruder mischief. In order to reduce the vulnerability
to such mischief, the crypto-NAK is believed only if the result of a
previous packet sent by the client, as confirmed by the LBK status bit.
This bit is lit in the NTP protocol if the packet 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
This section discusses the most obvious security vulnerabilities in the
various Autokey dances. Throughout the discussion the cryptographic
algorithms themselves are assumed secure; that is, a brute force
cryptanalytic attack will not reveal the host private key or sign
private key or cookie value or server seed or autokey seed or be able to
predict the random generator values.
There are three tiers of defense against intruder attacks. The first is
a keyed message digest including a secret cookie conveyed in encrypted
form. A packet is discarded if the message digest does not match the
MAC. The second tier is the autokey sequence, which is generated by
repeated hashes starting from a secret server seed and used in reverse
order. While any receiver can authenticate a packet relative to the last
one received and by induction to a signed 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.
In addition to the three-tier defense strategy, all packets are 10. References
protected by the NTP sanity checks. Since NTP packets carry time values,
replays of old or bogus packets can be deflected once the client has
synchronized to proventic sources. Additional sanity checks involving
timestamps and filestamps are summarized in Appendix C.
During the Autokey dances when extension fields are in use, the cookie [RFC-1305] Mills, D.L., "Network Time Protocol (Version 3)
is a public value (0) rather than a shared private value. Therefore, an Specification, Implementation and Analysis," RFC-1305, March 1992.
intruder can easily construct a packet with a valid MAC; however, once
the certificate is stored, extension fields carry timestamped signatures
and bogus packets are readily avoided. While most request messages are
unsigned, only the Association response message is unsigned. This
message is used in the first packet sent by a server or peer and in most
NTP broadcast packets.
A bogus Association response message can cause a client livelock or [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision
deadlock condition. However, these packets do not affect NTP time values 3", BCP 9, RFC 2026, October 1996.
and do not consume significant resources. To reduce the vulnerability to
bogus packets, the NTP transmit timestamp in the Association and
Certificate request messages is used as a nonce. The NTP server copies
this value to the originate timestamp in the NTP header, so that the
client can verify that the message is a response 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 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
needed after the Autokey dance has concluded. The client validates the Requirement Levels", BCP 14, RFC 2119, March 1997.
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 [RFC-2402] Kent, S., R. Atkinson, "IP Authentication Header," RFC-
synchronized to a proventic source. A host does not sign values or 2402, November 1998.
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 [RFC-2406] Kent, S., and R. Atkinson, "IP Encapsulating Security
Payload (ESP)," RFC-2406, November 1998.
Some observations on the particular engineering constraints of the [RFC-2408] Maughan, D., M. Schertler, M. Schneider, and J. Turner,
Autokey protocol are in order. First, the number of bits in some "Internet Security Association and Key Management Protocol (ISAKMP),"
cryptographic values are considerably smaller than would ordinarily be RFC-2408, November 1998.
expected for strong cryptography. One of the reasons for this is the
need for compatibility with previous NTP versions; another is the need
for small and constant latencies and minimal processing requirements.
Therefore, what the scheme gives up on the strength of these values must
be regained by agility in the rate of change of the cryptographic basis
values. Thus, autokeys are used only once and basis values are
regenerated frequently. However, in most cases even a successful
cryptanalysis of these values compromises only a particular
client/server association and does not represent a danger to the general
population.
While the protocol has not been subjected to a formal analysis, a few [RFC-2412] Orman, H., "The OAKLEY Key Determination Protocol," RFC-
preliminary assertions can be made. The protocol cannot loop forever in 2412, November 1998.
any state, since the association timeout and general reset insure that
the association variables will eventually be purged and the protocol
restarted from the beginning. However, if something is seriously wrong,
the timeout/restart cycle could continue indefinitely until whatever is
wrong is fixed.
Clogging Attacks [RFC-2510] Adams, C., S. Farrell, "Internet X.509 Public Key
Infrastructure Certificate Management Protocols," RFC-2510, March
1999.
There are two clogging vulnerabilities exposed in the protocol design: a [RFC-2522] Karn, P., and W. Simpson, "Photuris: Session-key
sign attack where the intruder hopes to clog the victim server with Management Protocol", RFC-2522, March 1999.
needless signature computations, and a verify attack where the intruder
attempts to clog the victim client with needless verification
computations. Autokey uses public key encryption algorithms for both
signature and cookie encryption and these algorithms require significant
processor resources.
In order to reduce the exposure to a sign attack, signatures are [RFC-2875] Prafullchandra, H., and J. Schaad, "Diffie-Hellman Proof-
computed only when the data have changed. For instance, the autokey of-Possession Algorithms," RFC-2875, July 2000, 23 pp.
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
values are refreshed, which happens about once per day. However, in
client/server mode the protocol precludes server state variables on
behalf of an individual client, so the cookie must be computed,
encrypted and signed for every cookie response. Ordinarily, cookie
requests are seldom used, except when the server seed or public value
signatures are refreshed. However, a determined intruder could replay
cookie requests at high rate, which may very well clog the server. There
appears no easy countermeasure for this particular attack.
A verify attack attempts to clog the receiver by provoking spurious [RFC-3279] Bassham, L., W. Polk and R. Housley, "Algorithms and
signature verifications. The signature timestamp is designed to deflect Identifiers for the Internet X.509 Public Key Infrastructure
replays of packets with old or duplicate extension fields before Certificate and Certificate Revocation Lists (CRL) Profile," RFC-
invoking expensive signature operations. A bogus signature with a 3279, April 2002.
timestamp in the future could do this, but the autokey sequence would
detect this, since success would require cryptanalysis of both the
server seed and autokey seed.
Since the Certificate response is signed, a middleman attack will not [RFC-3280] Housley, R., et al., "Internet X.509 Public Key
compromise the certificate data; however, a determined middleman could Infrastructure Certificate and Certificate Revocation List (CRL)
hammer the client with intentionally defective Certificate responses Profile," RFC-3280, April 2002.
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.
An interesting vulnerability in client/server mode is for an intruder to [MILLS00] Mills, D.L. Public key cryptography for the Network Time
replay a recent client packet with an intentional bit error. This could Protocol. Electrical Engineering Report 00-5-1, University of
cause the server to return a crypto-NAK packet, which would then cause Delaware, May 2000. 23 pp.
the client to request the cookie and result in a sign attack on the
server. This results in the server and client burning spurious machine
cycles and resulting in denial of service. As in other cases mentioned
previously, the NTP timestamp check greatly reduces the likelihood of a
successful attack.
In broadcast and symmetric modes the client must include the association [MILLS96] Mills, D.L. Proposed authentication enhancements for the
ID in the Autokey request. Since association ID values for different Network Time Protocol version 4. Electrical Engineering Report 96-10-
invocations of the NTP daemon are randomized over the 16-bit space, it 3, University of Delaware, October 1996, 36 pp.
is unlikely that a very old packet would contain a valid association 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 previously, an intruder could pounce on the initial volley [STIMSON] Stimson, D.R. Cryptography - Theory and Practice. CRC
between peers in symmetric mode before both peers have determined each Press, Boca Raton, FA, 1995, ISBN 0-8493-8521-0.
other reachable. In this volley the peers are vulnerable to an intruder
using fake timestamps. The result can be 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-
bit (4 octet) words in network byte order. The packet consists of three The NTPv4 packet consists of a number of fields made up of 32-bit (4
octet) words in network byte order. The packet consists of three
components, the header, one or more optional extension fields and an components, the header, one or more optional extension fields and an
optional message authenticator code (MAC), consisting of the Key ID and optional message authenticator code (MAC), consisting of the Key ID
Message Digest fields. The format is shown below, where the size of some and Message Digest fields. The header format is shown below, where
multiple word fields is shown in words. the 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 25, line 55 skipping to change at page 32, line 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| Message Digest (4) | | 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 NTPv3 header fields
fields as described in RFC-1305, except for a slightly modified as described in [RFC-1305].
computation for the Root Dispersion field. In NTP Version 3, this field
includes an estimated jitter quantity based on weighted absolute
differences, while in NTP Version 4 this quantity is based on weighted
root-mean-square (RMS) differences.
An unauthenticated NTP packet includes only the NTP header, while an A non-authenticated NTP packet includes only the NTP header, while an
authenticated one contains in addition a MAC. The format and authenticated one contains in addition a MAC. The format and
interpretation of the NTP Version 4 MAC is described in RFC-1305 when interpretation of the NTPv4 MAC is described in [RFC-1305] when using
using the Digital Encryption Standard (DES) algorithm operating in the Digital Encryption Standard (DES) algorithm operating in Cipher-
Cipher-Block Chaining (CBC) node. This algorithm and mode of operation Block Chaining (CBC) node. This algorithm and mode of operation is no
is no longer supported in NTP Version 4. The preferred replacement in longer supported in NTPv4. The preferred replacement in both NTPv3
both NTP Version 3 and 4 is the Message Digest 5 (MD5) algorithm, which and NTPv4 is the Message Digest 5 (MD5) algorithm, which is included
is included in the distribution. For MD5 the Message Digest field is 4 in the reference implementation. For MD5 the Message Digest field is
words (8 octets), but the Key ID field remains 1 word (4 octets). 4 words (8 octets), but the Key ID field remains 1 word (4 octets).
Extension Field Format A.1 Extension Field Format
In NTP Version 4 one or more extension fields can be inserted after the In NTPv4 one or more extension fields can be inserted after the NTP
NTP header and before the MAC, which is always present when an extension header and before the MAC, which is always present when an extension
field is present. The extension fields can occur in any order; however, field is present. The extension fields can occur in any order;
in some cases there is a preferred order which improves the protocol however, in some cases there is a preferred order which improves the
efficiency. While previous versions of the Autokey protocol used several protocol efficiency. While previous versions of the Autokey protocol
different extension field formats, in version 2 of the protocol only a used several different extension field formats, in version 2 of the
single extension field format is used. protocol only a single extension field format is used.
Each extension field contains a request or response message in the Each extension field contains a request or response message in the
following format: 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 | | Association ID |
skipping to change at page 27, line 7 skipping to change at page 33, line 13
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | | Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Signature = = Signature =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each extension field except the last is padded to a word (4 octets) Each extension field except the last is zero-padded to a word (4
boundary, while the last is padded to a doubleword (8 octets) boundary. octets) boundary, while the last is zero-padded to a doubleword (8
The Length field covers the entire field length, including the Length octets) boundary. The Length field covers the entire extension field,
field itself and padding. While the minimum field length is 8 octets, a including the Length and Padding fields. While the minimum field
maximum field length remains to be established. The reference length is 8 octets, a maximum field length remains to be established.
implementation discards any packet with an extension field length over The reference implementation discards any packet with a field length
1024 octets. more than 1024 octets.
The presence of the MAC and extension fields in the packet is determined The presence of the MAC and extension fields in the packet is
from the length of the remaining area after the header to the end of the determined from the length of the remaining area after the header to
packet. The parser initializes a pointer just after the header. If the the end of the packet. The parser initializes a pointer just after
length is not a multiple of 4, a format error has occurred and the the header. If the length is not a multiple of 4, a format error has
packet is discarded. If the length is zero the packet is not occurred and the packet is discarded. The following cases are
authenticated. If the length is 4 (1 word), the packet is an error possible based on the remaining length in words.
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.
If an extension field is present, the parser examines the length field. 0 The packet is not authenticated.
If the length is less than 4 or not a multiple of 4, a format error has 4 The packet is an error report or crypto-NAK resulting from a
occurred and the packet is discarded; otherwise, the parser increments previous packet that failed the message digest check. The 4 octets
the pointer by this value. The parser now uses the same rules as above are presently unused and should be set to 0.
to determine whether a MAC is present and/or another extension field. An 2, 3, 4 The packet is discarded with a format error.
additional implementation-dependent test is necessary to ensure the 5 The remainder of the packet is the MAC.
pointer does not stray outside the buffer space occupied by the packet. >5 One or more extension fields are present.
In the Autokey Version 2 format, the Code field specifies the request or If an extension field is present, the parser examines the Length
response operation, while the Version field is 2 identifying the current field. If the length is less than 4 or not a multiple of 4, a format
protocol version. There are two flag bits defined. Bit 0 is the response error has occurred and the packet is discarded; otherwise, the parser
flag (R) and bit 1 is the error flag (E); the other six bits are increments the pointer by this value. The parser now uses the same
presently unused and should be set to 0. The remaining fields will be rules as above to determine whether a MAC is present and/or another
described later. extension field. An additional implementation-dependent test is
necessary to ensure the pointer does not stray outside the buffer
space occupied by the packet.
In the Autokey Version 2 format, the Code field specifies the request
or response operation, while the Version field is 2 for the 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.
In the most common protocol operations, a client sends a request to a In the most common protocol operations, a client sends a request to a
server with an operation code specified in the Code field and the R bit server with an operation code specified in the Code field and lights
set to 0. Ordinarily, the client sets the E bit to 0 as well, but may in the R bit. Ordinarily, the client dims the E bit as well, but may in
future set it to 1 for some purpose. The Association ID field is set to future light it for some purpose. The Association ID field is set to
the value previously received from the server or 0 otherwise. The server the value previously received from the server or 0 otherwise. The
returns a response with the same operation code in the Code field and server returns a response with the same operation code in the Code
the R bit set to 1. The server can also set the E bit to 1 in case of field and the R bit lit. The server can also light E bit in case of
error. The Association ID field is set to the association ID sending the error. The Association ID field is set to the association ID sending
response as a handle for subsequent exchanges. If for some reason the the response as a handle for subsequent exchanges. If for some reason
association ID value in a request does not match the association ID of the association ID value in a request does not match the association
any mobilized association, the server returns the request with both the ID of any mobilized association, the server returns the request with
R and E bits set to 1. Note that, it is not a protocol error to send an both the R and E bits lit. Note that it is not a protocol error to
unsolicited response with no matching request. send an unsolicited response with no matching request.
In some cases not all fields may be present. For instance, when a client In some cases not all fields may be present. For requests, until a
has not synchronized to a proventic source, signatures are not valid. In client has synchronized to a proventic source, signatures are not
such cases the Timestamp and Signature Length fields are 0 and the valid. In such cases the Timestamp and Signature Length fields are 0
Signature field is empty. Some request and error response messages carry and the Signature field is empty. Responses are generated only when
no value or signature fields, so in these messages only the first two the responder has synchronized to a proventic source; otherwise, an
words are present. The extension field parser verifies that the error response message is sent. Some request and error response
extension field length is at least 8 if no value field is expected and messages carry no value or signature fields, so in these messages
at least 24 if it is. The parser also verifies that the sum of the value only the first two words are present.
and signature lengths is equal to or less than the extension field
length.
The Timestamp and Filestamp words carry the seconds field of the NTP The Timestamp and Filestamp words carry the seconds field of an NTP
timestamp. The Timestamp field establishes the signature epoch of the timestamp. The Timestamp field establishes the signature epoch of the
data field in the message, while the filestamp establishes the data field in the message, while the filestamp establishes the
generation epoch of the file that ultimately produced the data that was generation epoch of the file that ultimately produced the data that
signed. Since a signature and timestamp are valid only when the signing is signed. Since a signature and timestamp are valid only when the
host is synchronized to a proventic source and a cryptographic data file signing host is synchronized to a proventic source and a
can only be generated if a signature is possible, the filestamp is cryptographic data file can only be generated if a signature is
always nonzero, except in the Association Response message, where it possible, the response filestamp is always nonzero, except in the
contains the server status word. Association response message, where it contains the server status
word.
Autokey Version 2 Messages
Association Message A.2 Autokey Version 2 Messages
The Association message is used to obtain the host name and related Following is a list of the messages used by the protocol.
values. The request message has the following format:
1 2 3 A.2.1 Association Message (ASSOC)
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| 1 | 1 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The response message has the following format: The Association message is used to obtain the host name and related
values. The request and response are unsigned and have 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 | 1 | Length | |1|E| 1 | 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Value Timestamp | | Public Values Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Word | | Host Status Word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Name Length | | Host Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Host Name = = Host Name =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the only response that is accepted if the association status The Host Name field contains the unterminated string returned by the
word is zero; otherwise, it is ignored. As this is the first request Unix gethostname() library function. While minimum and maximum host
sent and the response is not from an association, the Association ID name lengths remain to be established, the reference implementation
fields are 0. The Host Name field contains the unterminated string uses the values 4 and 256, respectively. The remaining fields are
returned by the Unix gethostname() library function. The Status Word is defined previously in this document.
defined in previously in this memorandum. While minimum and maximum host
name lengths remain to be established, the reference implementation uses
the values 4 and 256, respectively.
Certificate Message A.2.2. Certificate Message (CERT)
The Certificate message is used to obtain the certificate and related The Certificate message is used to obtain a certificate and related
values. The request message has the following format: values by subject name. The unsigned request 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| 2 | 2 | 8 | |0|0| 2 | 2 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID | | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Time |
The response message has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Values Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subject Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
= Subject Name =
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For the purposes of interoperability with older Autokey versions, if
only the first two words are sent, the request is for the host
certificate. 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| 2 | 2 | Length | |1|E| 2 | 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID | | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Values Timestamp | | Public Values Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 30, line 10 skipping to change at page 36, line 36
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate Signature Length | | Certificate Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Certificate Signature = = Certificate Signature =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The response is accepted only if the association status word is nonzero, The certificate is encoded in X.509 format with ASN.1 syntax as
AUT = 0 and LBK = 1. The certificate is encoded in X.509 format using described in Appendix G. The remaining fields are defined previously
ASN.1 syntax. If the certificate has expired or for some reason is no in this document.
longer available, the response includes only the first two words with
the E bit set. The remaining fields are defined previously in this
memorandum.
Cookie Message A.2.3 Cookie Message (COOKIE)
The Cookie is used in client/server and symmetric modes to obtain the The Cookie message is used in server and symmetric modes to obtain
server cookie. The request message has the following format: the server cookie. The request 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| 3 | 3 | Length | |0|0| 3 | 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID | | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Values Timestamp | | Public Values Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate Filestamp | | Host Key Filestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key Length | | Public Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Public Key = = Public Key =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key Signature Length | | Public Key Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Public Key Signature = = Public Key Signature =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The request is accepted only if AUT = 1, CKY = 0 and LBK = 1. The Public The Public Key field contains the host public key encoded with ASN.1
Key field contains the server public key values to be used for cookie syntax as described in Appendix G. The remaining fields are defined
encryption. The values are encoded in ASN.1 format. The remaining fields previously in this document.
are defined previously in this memorandum.
The response message has the following format: The response 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| 3 | 3 | Length | |1|E| 3 | 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID | | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie Timestamp | | Cookie Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate Filestamp | | Public Key Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Cookie Length | | Encrypted Cookie Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Encrypted Cookie = = Encrypted Cookie =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie Signature Length | | Cookie Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Cookie Signature = = Cookie Signature =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The response is accepted only if AUT = 1 and LBK = 1. The Cookie The Encrypted Cookie field contains the raw cookie value encrypted by
Timestamp, Encrypted Cookie and Cookie Signature fields are determined the public key in the request. The Cookie Signature and Timestamp are
upon arrival of the request message. The Encrypted Cookie field contains determined when the response is sent. The Public Key Timestamp is
the encrypted cookie value according to the public key provided in the copied from the request. The remaining fields are defined previously
request. If CKY = 0, the decrypted cookie is used directly. If CKY = 1, in this document.
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.
Autokey Message A.2.4 Autokey Message (AUTO)
The Autokey message is used to obtain the autokey values. The request The Autokey message is used to obtain the autokey values. The request
message has the following format: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| 2 | 4 | 8 | |0|0| 2 | 4 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID | | Association ID |
skipping to change at page 32, line 14 skipping to change at page 38, line 40
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| 4 | 4 | Length | |1|E| 4 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID | | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Autokey Timestamp | | Autokey Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate Filestamp | | Public Values Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | | Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Number | | Key Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Autokey Signature Length | | Autokey Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Autokey Signature = = Autokey Signature =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The response is accepted only if AUT = 1 and KEY = 0 in the association The Autokey Signature and Timestamp are determined when the key list
status word; otherwise, it is ignored. The Autokey Timestamp, Key ID, is generated. The remaining fields are defined previously in this
Key Number and Autokey Signature fields are determined when the most document.
recent key list was generated. If a key list has not been generated or
the association ID matches no mobilized association, the response
includes only the first two words with the E bit set. The remaining
fields are defined previously in this memorandum.
Leapseconds Table Message A.2.5 Leapseconds Table Message (LEAP)
The Leapseconds Table message is used to exchange leapseconds tables. The Leapseconds Table message is used to exchange leapseconds tables.
The request and response messages have the following format, except that The request and response messages have the following format, except
the R bit is set in the response: that the R bit is dim in the request and lit 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| 2 | 5 | Length | |R|E| 2 | 5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID | | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Values Timestamp | | Public Values Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leapseconds Filestamp | | Leapseconds Filestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leapseconds Table Length | | Leapseconds Table Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 33, line 19 skipping to change at page 39, line 46
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leapseconds Signature Length | | Leapseconds Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
= Leapseconds Signature = = Leapseconds Signature =
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The response is accepted only if AUT = 1 and LPT = 0 in the association The Leapseconds Table field contains the leapseconds table as parsed
status word; otherwise, it is ignored. The Leapseconds Table field from the leapseconds file from NIST. If the client already has a copy
contains the leapseconds table as parsed from the leapseconds file of the leapseconds data, it uses the one with the latest filestamp
available from NIST. In client/server mode the client requests the table and discards the other. The remaining fields are defined previously
from the server when the LPF bit is set in the host status word. If the in this document.
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.
Appendix B. Key Generation and Management A.2.6 Sign Message (SIGN)
The Sign message requests the server to sign and return a certificate
presented in the request. The request and response messages have the
following format, except that the R bit is dim in the request and lit
in the response:
The ntp-genkeys utility program in the NTP software distribution 1 2 3
generates public/private key, certificate request and certificate files. 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
A set of files is generated for every message digest and signature +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
encryption scheme supported by the OpenSSL software library. All files |R|E| 2 | 6 | Length |
are based on a pseudo-random number generator seeded in such a way that +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
random values are exceedingly unlikely to repeat. The files are PEM | Association ID |
encoded in printable ASCII format suitable for mailing as MIME objects. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The file names include the name of the generating host together with the | Public Values Timestamp |
filestamp, as described previously in this memorandum. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate Filestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
= Certificate =
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
= Certificate Signature =
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The generated files are typically stored in a shared directory in NFS The certificate is in X.509 format encoded in ASN.1 syntax as
mounted file systems, with files containing private keys obscured to all described in Appendix G. The remaining fields are defined previously
but root. Links from default file names assumed by the NTP daemon are in this document.
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.
The ntp-genkeys program generates public/private key files for both the A.2.7 Identity Messages (IFF, GQ)
RSA and DSA encryption algorithms with a default modulus of 512 bits.
The host key used for cookie encryption must be RSA. By default, the
same key is used for signature encryption. However, a different RSA key
or a DSA key can be specified for signature encryption.
The ntp-genkeys program also generates certificate request and self- The Identity request asks the server to perform a mathematical
signed certificate files. The X.509 certificate request used by Autokey operation on the challenge and return the results in the response.
includes at the minimum these values and possibly related information The request message has the following format, where 7 is the IFF
needed by an external certificate authority. Autokey expects the subject scheme and 8 is the GQ shseme:
name and issuer name to be the same as the generating host name.
The program avoids the need for a serial number file by using the 1 2 3
filestamp as the certificate serial number. By default, certificates are 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
valid for one year following the time of generation, although these +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
conventions may change. Also, the program assumes X.509 version 1 |0|E| 2 | 7/8 | Length |
formats, although this may change to version 3 in future. Other +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
implementations might have different conventions. | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Values Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
= Challenge (512 bits) =
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
= Challenge Signature =
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix C. Packet Processing Rules The Challenge is a raw 512-bit nonce. The remaining fields are
defined previously in this document.
The Identity response contains the result of the mathematical
operation and is in two parts, the results and a message digest. The
response message has the following format, where 7 is the IFF scheme
and 8 is for the GQ shseme:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E| 2 | 7/8 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Values Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
= Response =
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resonse Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
= Response Signature =
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Response is encoded in ASN.1 syntax as described in Appendix G.
The Response Signature and Timestamp are determined when the response
is sent. The Parameters Filestamp is copied from the request.
Appendix B. Cryptographic Key and Certificate Management
This appendix describes how cryptographic keys and certificates are
generated and managed in the NTPv4 reference implementation. These
means are not intended to become part of any standard that may be
evolved from this document, but to serve as an example of how these
functions can be implemented and managed in a typical operational
environment.
The ntp-keygen utility program in the NTP software library generates
public/private key files, certificate files, identity parameter files
and public/private identity key files. By default the modulus of all
encryption and identity keys is 512 bits. All random cryptographic
data are based on a pseudo-random number generator seeded in such a
way that random values are exceedingly unlikely to repeat. The files
are PEM encoded in printable ASCII format suitable for mailing as
MIME objects.
Every file has a filestamp, which is a string of decimal digits
representing the NTP seconds the file was created. The file name is
formed from the concatenation of the host name, filestamp and
constant strings, so files can be copied from one environment to
another while preserving the original filestamp. The file header
includes the file name and date and generation time in printable
ASCII. The utility assumes the host is synchronized to a proventic
source at the time of generation, so that filestamps are proventic
data. This raises an interesting circularity issue that will not be
further explored here.
The generated files are typically stored in NFS mounted file systems,
with files containing private keys obscured to all but root. Symbolic
links are installed from default file names assumed by the NTP daemon
to the selected files. Since the files of successive generations and
different hosts have unique names, there is no possibility of name
collisions.
Public/private keys must be generated by the host to which they
belong. OpenSSL public/private RSA and DSA keys are generated as an
OpenSSL structure, which is then PEM encoded in ASN.1 syntax and
written to the host key file. The host key must be RSA, since it is
used to encrypt the cookie, as well as encrypt signatures by default.
In principle, these files could be generated directly by OpenSSL
utility programs, as long as the symbolic links are consistent. The
optional sign key can be RSA or DSA, since it is used only to encrypt
signatures.
Identity parameters must be generated by the ntp-keygen utility,
since they have proprietary formats. Since these are private to the
group, they are generated by one machine acting as a trusted
authority and then distributed to all other members of the group by
secure means. Public/private identity keys are generated by the host
to which they belong along with certificates with the public identity
key.
Certificates are usually, but not necessarily, generated by the host
to which they belong. The ntp-keygen utility generates self-signed
X.509v3 host certificate files with optional extension fields.
Certificate requests are not used, since the certificate itself is
used as a request to be signed. OpenSSL X.509v3 certificates are
generated as an OpenSSL structure, which is then PEM encoded in ASN.1
syntax and written to the host certificate file. The string returned
by the Unix gethostname() routine is used for both the subject and
issuer fields. The serial number and begin time fields are derived
from the filestamp; the end time is one year hence. The host
certificate is signed by the sign key or host key by default.
An important design goal is to make cryptographic data refreshment as
simple and intuitive as possible, so it can be driven by scripts on a
periodic basis. When the ntp-keygen utility is run for the first
time, it creates by default a RSA host key file and RSA-MD5 host
certificate file and necessary symbolic links. After that, it creates
a new certificate file and symbolic link using the existing host key.
The program run with given options creates identity parameter files
for one or both the IFF or GQ identity schemes. The parameter files
must then be securely copied to all other group members and symbolic
links installed from the default names to the installed files. In the
GQ scheme the next and each subsequent time the ntp-keygen utility
runs, it automatically creates or updates the private/public identity
key file and certificate file using the existing identity parameters.
Appendix C. Autokey Error Checking
Exhaustive examination of possible vulnerabilities at the various Exhaustive examination of possible vulnerabilities at the various
processing steps of the NTP protocol as specified in RFC-1305 have processing steps of the NTPv3 protocol as specified in [RFC-1305]
resulted in a revised list of packet sanity tests. There are 12 tests, have resulted in a revised list of packet sanity tests. There are 12
called TEST1 through TEST12 in the reference implementation, which are tests in the NTPv4 reference implementation, called TEST1 through
performed in a specific order designed to gain maximum diagnostic TEST12, which are performed in a specific order designed to gain
information while protecting against an accidental or malicious clogging maximum diagnostic information while protecting against an accidental
attack. These tests are described in detail in the Flash Codes section or malicious clogging attacks. These tests are described in detail in
of the ntpq documentation page at the NTP software documentation. Those relevant to the Autokey
www.eecis.udel.edu/~ntp/ntp_spool/html/ntpq.htm. protocol are described in this appendix.
The sanity tests are divided into three tiers as previously described. The sanity tests are classified in four tiers. The first tier
The first tier deflects access control and packet message digest deflects access control and message digest violations. The second,
violations. The second deflects packets from broken or unsynchronized represented by the autokey sequence, deflects spoofed or replayed
servers and replays. The third deflects packets with invalid header packets. The third, represented by timestamped digital signatures,
fields or time values with excessive errors. However, the tests in this binds cryptographic values to verifiable credentials. The fourth
last group do not directly affect cryptographic the protocol deflects packets with invalid NTP header fields or out of bounds time
vulnerability, so are beyond the scope of discussion here. values. However, the tests in this last group do not directly affect
cryptographic protocol vulnerability, so are beyond the scope of
discussion here.
When a host initializes, it reads its own host key, sign key and C.1 Packet Processing Rules
certificate files, which are required for continued operation.
Optionally, it reads the leapseconds file, when available. When reading
these files the host checks the filestamps for validity; for instance,
all filestamps must be later than the time the UTC timescale was
established in 1972 and the certificate filestamp must not be earlier
than the sign key filestamp (or host key filestamp, if that is the
default sign key). In general, at the time the files are read, the host
is not synchronized, so it cannot determine whether the filestamps are
bogus other than these simple checks.
Once a client has synchronized to a proventic source, additional checks Every arriving NTP packet is checked enthusiastically for format,
are implemented as each message arrives. In the following the relation A content and protocol errors. Some packet header fields are checked by
-> B is Lamport's "happens before" relation which is true if event A the main NTP code path both before and after the Autokey protocol
happens before event B. Here the relation is assume to hold if event A engine cranks. These include the NTP version number, overall packet
is simultaneous with event B, unless noted to the contrary. The length and extension field lengths. Extension fields may be no longer
following assertions are required: than 1024 octets in the reference implementation. Packets failing any
of these checks are discarded immediately. Packets denied by the
access control mechanism will be discarded later, but processing
continues temporarily in order to gather further information useful
for error recovery and reporting.
1. For timestamp T and filestamp F, F->T; that is, the timestamp must Next, the cookie and session key are determined and the MAC computed
not be earlier than the filestamp. as described above. If the MAC fails to match the value included in
the packet, the action depends on the mode and the type of packet.
Packets failing the MAC check will be discarded later, but processing
continues temporarily in order to gather further information useful
for error recovery and reporting.
2. In client and symmetric modes, for host key filestamp H, public key The NTP transmit and receive timestamps are in effect nonces, since
timestamp P, cookie timestamp C and autokey timestamp A, H->P->C->A; an intruder cannot effectively guess either value in advance. To
that is, once the cookie is generated an earlier cookie will not be minimize the possibility that an intruder can guess the nonces, the
accepted, and once the key list and autokey values are generated, low order unused bits in all timestamps are obscured with random
earlier autokey values will not be accepted. values. If the transmit timestamp matches the transmit timestamp in
the last packet received, the packet is a duplicate, so the DUP bit
is lit. If the packet mode is not broadcast and the last transmit
timestamp does not match the originate timestamp in the packet,
either it was delivered out of order or an intruder has injected a
rogue packet, so the LBK bit is lit. Packets with either the DUP or
LBK bit lie be discarded later, but processing continues temporarily
in order to gather further information useful for error recovery and
reporting.
3. For sign file S and certificate filestamp C specifying begin time B Further indicators of the server and client state are apparent from
and end time E, S->C->B->E; that is, the valid period must be nonempty the transmit and receive timestamps of both the packet and the
and not retroactive. association. The quite intricate rules take into account these and
the above error indicators They are designed to discriminate between
legitimate cases where the server or client are in inconsistent
states and recoverable, and when an intruder is trying to destabilize
the protocol or force consumption of needless resources. The exact
behavior is beyond the scope of discussion, but is clearly described
in the source code documentation.
4. For timestamp T, begin time B and end time E, B->T->E; that is, the Next, the Autokey protocol engine is cranked and the dances evolve as
timestamp T is valid from the beginning if second B through the end of described above. Some requests and all responses have value fields
second E. This raises the interesting possibilities where a truechimer which carry timestamps and filestamps. When the server or client is
server with expired certificate or a falseticker with valid certificate synchronized to a proventic source, most requests and responses with
are not detected until the client has synchronized to a clique of value fields carry signatures with valid timestamps. When not
proventic truechimers. synchronized to a proventic source, value fields carry an invalid
(zero) timestamp and the signature field and signature length word
are omitted.
5. For each of signatures, the client saves the most recent valid The extension field parser checks that the Autokey version number,
timestamp T0 and filestamp F0. For every received message carrying operation code and field length are valid. If the error bit is lit in
a request, the request is discarded without response; if an error is
discovered in processing the request, or if the responder is not
synchronized to a proventic source, the response contains only the
first two words of the request with the response and error bits lit.
For messages with signatures, the parser requires that timestamps and
filestampes are valid and not a replay, that the signature length
matches the certificate public key length and only then verifies the
signature. Errors are reported via the security logging facility.
All certificates must have correct ASN.1 encoding, supported
digest/signature scheme and valid subject, issuer, public key and,
for self-signed certificates, valid signature. While the begin and
end times can be checked relative to the filestamp and each other,
whether the certificate is valid relative to the actual time cannot
be determined until the client is synchronized to a proventic source
and the certificate is signed and verified by the server.
When the protocol starts the only response accepted is ASSOC with
valid timestamp, after which the server status word must be nonzero.
ASSOC responses are discarded if this word is nonzero. The only
responses accepted after that and until the PRV bit is lit are CERT,
IFF and GQ. Once identity is confirmed and IFF is lit, these
responses are no longer accepted, but all other responses are
accepted only if in response to a previously sent request and only in
the order prescribed in the protocol dances. Additional checks are
implemented for each request type and dance step.
C.2 Timestamps, Filestamps and Partial Ordering
When the host starts, it reads the host key and certificate files,
which are required for continued operation. It also reads the sign
key and leapseconds files, when available. When reading these files
the host checks the file formats and filestamps for validity; for
instance, all filestamps must be later than the time the UTC
timescale was established in 1972 and the certificate filestamp must
not be earlier than its associated sign key filestamp. In general, at
the time the files are read, the host is not synchronized, so it
cannot determine whether the filestamps are bogus other than these
simple checks.
In the following the relation A->B is Lamport's "happens before"
relation, which is true if event A happens before event B. When
timestamps are compared to timestamps, the relation is false if A ==
B; that is, false if the events are simultaneous. For timestamps
compared to filestamps and filestamps compared to filestamps, the
relation is true if A == B. Note that the current time plays no part
in these assertions except in (6) below; however, the NTP protocol
itself insures a correct partial ordering for all current time
values.
The following assertions apply to all relevant responses:
1. The client saves the most recent timestamp T0 and filestamp F0 for
the respective signature type. For every received message carrying
timestamp T1 and filestamp F1, the message is discarded unless T0->T1 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 and F0->F1. The requirement that T0->T1 is the primary defense
dim, the message is not discarded if T1 = T0; that is, old messages are against replays of old messages.
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 2. For timestamp T and filestamp F, F->T; that is, the timestamp must
certificate becomes invalid. The behavior assumed is identical to the not be earlier than the filestamp. This could be due to a file
case where an incorrect sign key were used. Thus, the next time a client generation error or a significant error in the system clock time.
attempts to verify an autokey signature, for example, the operation
would fail and eventually cause a general client reset and restart.
Security Considerations 3. For sign key filestamp S, certificate filestamp C, cookie
timestamp D and autokey timestamp A, S->C->D->A; that is, the autokey
must be generated after the cookie, the cookie after the certificate
and the certificate after the sign key.
Security issues are the main topic of this memorandum. 4. For sign key filestamp S and certificate filestamp C specifying
begin time B and end time E, S->C->B->E; that is, the valid period
must not be retroactive.
References 5. A certificate for subject S signed by issuer I and with filestamp
C1 obsoletes, but does not necessarily invalidate, another
certificate with the same subject and issuer but with filestamp C0,
where C0->C1.
Note: Internet Engineering Task Force documents can be obtained at 6. A certificate with begin time B and end time E is invalid and can
www.ietf.org. Other papers and reports can be obtained at not be used to sign certificates if t->B or E->t, where t is the
www.eecis.udel.edu/~mills. Additional briefings in PowerPoint, current time. Note that the public key previously extracted from the
PostScript and PDF are at that site in ./autokey.htm. certificate continues to be valid for an indefinite time. This raises
the interesting possibilities where a truechimer server with expired
certificate or a falseticker with valid certificate are not detected
until the client has synchronized to a clique of proventic
truechimers.
1. Bradner, S. Key words for use in RFCs to indicate requirement levels. Appendix D. Security Analysis
Request for Comments RFC-2119, BCP 14, Internet Engineering Task Force,
March 1997.
2. Karn, P., and W. Simpson. Photuris: session-key management protocol. This section discusses the most obvious security vulnerabilities in
Request for Comments RFC-2522, Internet Engineering Task Force, March the various Autokey dances. First, some observations on the
1999. particular engineering parameters of the Autokey protocol are in
order. The number of bits in some cryptographic values are
considerably smaller than would ordinarily be expected for strong
cryptography. One of the reasons for this is the need for
compatibility with previous NTP versions; another is the need for
small and constant latencies and minimal processing requirements.
Therefore, what the scheme gives up on the strength of these values
must be regained by agility in the rate of change of the
cryptographic basis values. Thus, autokeys are used only once and
seed values are regenerated frequently. However, in most cases even a
successful cryptanalysis of these values compromises only a
particular association and does not represent a danger to the general
population.
3. Kent, S., R. Atkinson. IP Authentication Header. Request for Comments Throughout the following discussion the cryptographic algorithms and
RFC-2402, Internet Engineering Task Force, November 1998. private values themselves are assumed secure; that is, a brute force
cryptanalytic attack will not reveal the host private key, sign
private key, cookie value, identity parameters, server seed or
autokey seed. In addition, an intruder will not be able to predict
random generator values or predict the next autokey. On the other
hand, the intruder can remember the totality of all past values for
all packets ever sent.
4. Kent, S., and R. Atkinson. IP Encapsulating security payload (ESP). D.1 Protocol Vulnerability
Request for Comments RFC-2406, Internet Engineering Task Force, November
1998.
5. Maughan, D., M. Schertler, M. Schneider, and J. Turner. Internet While the protocol has not been subjected to a formal analysis, a few
security association and key management protocol (ISAKMP). Request for preliminary assertions can be made. The protocol cannot loop forever
Comments RFC-2408, Internet Engineering Task Force, November 1998. in any state, since the watchdog counter and general reset insure
that the association variables will eventually be purged and the
protocol restarted from the beginning. However, if something is
seriously wrong, the timeout/restart cycle could continue
indefinitely until whatever is wrong is fixed. This is not a clogging
hazard, as the timeout period is very long compared to expected
network delays.
6. Mills, D.L. Authentication scheme for distributed, ubiquitous, real- The LBK and DUP bits described in the main body and Appendix C are
time protocols. Proc. Advanced Telecommunications/Information effective whether or not cryptographic means are in use. The DUP bit
Distribution Research Program (ATIRP) Conference (College Park MD, deflects duplicate packets in any mode, while the LBK bit deflects
January 1997), 293-298. bogus packets in all except broadcast mode. All packets must have the
correct MAC, as verified with correct key ID and cookie. In all modes
the next key ID cannot be predicted by a wiretapper, so are of no use
for cryptanalysis.
7. Mills, D.L. Cryptographic authentication for real-time network As long as the client has validated the server certificate trail, a
protocols. In: AMS DIMACS Series in Discrete Mathematics and Theoretical wiretapper cannot produce a convincing signature and cannot produce
Computer Science, Vol. 45 (1999), 135-144. cryptographic values acceptable to the client. As long as the
identity values are not compromised, a middleman cannot masquerade as
a legitimate group member and produce convincing certificates or
signatures. In server and symmetric modes after the preliminary
exchanges have concluded, extension fields are no longer used, a
client validates the packet using the autokey sequence. A wiretapper
cannot predict the next Key IDs, so cannot produce a valid MAC. A
middleman cannot successfully modify and replay a message, since he
does not know the cookie and without the cookie cannot produce a
valid MAC.
8. Mills, D.L. Network Time Protocol (Version 3) specification, In broadcast mode a wiretapper cannot produce a key list with signed
implementation and analysis. Network Working Group Report RFC-1305, autokey values that a client will accept. The most it can do is
University of Delaware, March 1992, 113 pp. replay an old packet causing clients to repeat the autokey hash
operations until exceeding the maximum key number. However, a
middleman could intercept an otherwise valid broadcast packet and
produce a bogus packet with acceptable MAC, since in this case it
knows the key ID before the clients do. Of course, the middleman key
list would eventually be used up and clients would discover the ruse
when verifying the signature of the autokey values. There does not
seem to be a suitable defense against this attack.
9. Mills, D.L. Proposed authentication enhancements for the Network Time During the exchanges where extension fields are in use, the cookie is
Protocol version 4. Electrical Engineering Report 96-10-3, University of a public value rather than a shared secret and an intruder can easily
Delaware, October 1996, 36 pp. construct a packet with a valid MAC, but not a valid signature. In
the certificate and identity exchanges an intruder can generate fake
request messages which may evade server detection; however, the LBK
and DUP bits minimize the client exposure to the resulting rogue
responses. A wiretapper might be able to intercept a request,
manufacture a fake response and loft it swiftly to the client before
the real server response. A middleman could do this without even
being swift. However, once the identity exchange has completed and
the PRV bit lit, these attacks are readily deflected.
10. Mills, D.L, and A. Thyagarajan. Network time protocol version 4 A client instantiates cryptographic variables only if the server is
proposed changes. Electrical Engineering Department Report 94-10-2, synchronized to a proventic source. A server does not sign values or
University of Delaware, October 1994, 32 pp. 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.
11. Mills, D.L. Public key cryptography for the Network Time Protocol. D.2 Clogging Vulnerability
Electrical Engineering Report 00-5-1, University of Delaware, May 2000.
23 pp.
12. Orman, H. The OAKLEY key determination protocol. Request for There are two clogging vulnerabilities exposed in the protocol
Comments RFC-2412, Internet Engineering Task Force, November 1998. design: a encryption attack where the intruder hopes to clog the
victim server with needless cookie or signature encryptions or
identity calculations, and a decryption attack where the intruder
attempts to clog the victim client with needless cookie or
verification decryptions. Autokey uses public key cryptography and
the algorithms that perform these functions consume significant
processor resources.
Author's Address In order to reduce exposure to decryption attacks the LBK and DUP
bits deflect bogus and replayed packets before invoking any
cryptographic operations. In order to reduce exposure to encryption
attacks, signatures are computed only when the data have changed. For
instance, the autokey values are signed only when the key list is
regenerated, which happens about once an hour, while the public
values are signed only when one of them changes or the server seed is
refreshed, which happens about once per day.
In some Autokey dances the protocol precludes server state variables
on behalf of an individual client, so a request message must be
processed and the response message sent without delay. The identity,
cookie and sign exchanges are particularly vulnerable to a clogging
attack, since these exchanges can involve expensive cryptographic
algorithms as well as digital signatures. A determined intruder could
replay identity, cookie or sign requests at high rate, which may very
well be a useful munition for an encryption attack. Ordinarily, these
requests are seldom used, except when the protocol is restarted or
the server seed or public values are refreshed.
Once synchronized to a proventic source, a legitimate extension field
with timestamp the same as or earlier than the most recent received
of that type is immediately discarded. This foils a middleman cut-
and-paste attack using an earlier AUTO response, for example. A
legitimate extension field with timestamp in the future is unlikely,
as that would require predicting the autokey sequence. In either case
the extension field is discarded before expensive signature
computations. This defense is most useful in symmetric mode, but a
useful redundancy in other modes.
The client is vulnerable to a certificate clogging attack until
declared proventic, after which CERT responses are discarded. Before
that, a determined intruder could flood the client with bogus
certificate responses and force spurious signature verifications,
which of course would fail. The intruder could flood the server with
bogus certificate requests and cause similar mischief. Once declared
proventic, further certificate responses are discard, so these
attacks would fail. The intruder could flood the server with replayed
sign requests and cause the server to verify the request and sign the
response, although the client would drop the response due invalid
timestamp.
An interesting adventure is when an intruder replays a recent packet
with an intentional bit error. A stateless server will return a
crypto-NAK message which the client will notice and discard, since
the LBK bit is lit. However, a legitimate crypto-NAK is sent if the
server has just refreshed the server seed. In this case the LBK bit
is dim and the client performs a general reset and restarts the
protocol as expected. Another adventure is to replay broadcast mode
packets at high rate. These will be rejected by the clients by the
timestamp check and before consuming signature cycles.
In broadcast and symmetric modes the client must include the
association ID in the AUTO request. Since association ID values for
different invocations of the NTP daemon are randomized over the 16-
bit space, it is unlikely that a bogus request would match a valid
association with different IP addresses, for example, and cause
confusion.
Appendix E. Identity Schemes
The Internet infrastructure model described in [RFC-2510] is based on
certificate trails where a subject proves identity to a certificate
authority (CA) who then signs the subject certificate using the CA
issuer key. The CA in turn proves identity to the next CA and obtains
its own signed certificate. The trail continues to a CA with a self-
signed trusted root certificate independently validated by other
means. If it is possible to prove identity at each step, each
certificate along the trail can be considered trusted relative to the
identity scheme and trusted root certificate.
The import issue with respect to NTP and ad hoc sensor networks is
the cryptographic strength of the identity scheme, since if a
middleman could compromise it, the trail would have a security
breach. In electric mail and commerce the identity scheme can be
based on handwritten signatures, photographs, fingerprints and other
things very hard to counterfeit. As applied to NTP subnets and
identity proofs, the scheme must allow a client to securely verify
that a server knows the same secret that it does, presuming the
secret was previously instantiated by secure means, but without
revealing the secret to members outside the group.
The Autokey Version 2 reference implementation supports four identity
schemes of varying cryptographic strengths: one using private
certificates (PC), a second using trusted certificates (TC), a third
using a modified Schnorr (IFF aka Identify Friend or Foe) algorithm,
and the fourth using a modified Guillou-Quisquater (GQ) algorithm.
The available schemes are selected during the key generation phase,
with the particular scheme selected during the parameter exchange.
The IFF and GQ schemes involve a cryptographically strong challenge-
response exchange. These schemes begin when the client sends a nonce
to the server, which then rolls its own nonce, performs a
mathematical operation and sends the results along with a message
digest to the client. The client performs a second mathematical
operation to produce a digest that must match the one included in the
message. Still another scheme based on a modified Diffie-Hellman
agreement algorithm described in [RFC-2875], was considered, but the
computation resources required are considerably more than the IFF and
GQ schemes.
Certificate extension fields are used to convey information used by
the identity schemes, such as whether the certificate is private,
trusted or contains a public identity key. While the semantics of
these fields generally conforms with conventional usage, there are
subtle variations. The fields used by Autokey Version 2 include:
Basic Constraints
This field defines the basic functions of the certificate. It
contains the string "critical,CA:TRUE", which means the field must be
interpreted and the associated private key can be used to sign other
certificates. While included for compatibility, Autokey makes no use
of this field.
Key Usage
This field defines the intended use of the public key contained in
the certificate. It contains the string
"digitalSignature,keyCertSign", which means the contained public key
can be used to verify signatures on data and other certificates.
While included for compatibility, Autokey makes no use of this field.
Extended Key Usage
This field further refines the intended use of the public key
contained in the certificate and is present only in self-signed
certificates. It contains the string "Private" if the certificate is
designated private or the string "trustRoot" if it is designated
trusted. A private certificate is always trusted.
Subject Key Identifier:
This field contains the public identity key used in the GQ identity
scheme. It is present only if the GQ scheme is configured.
Certificates are used to construct certificate information structures
(CIS) which are stored on the certificate list. A flags field in the
CIS determines the status of the certificate. The field is encoded as
follows:
Sign 0x01
The certificate signature has been verified. If the certificate is
self-signed and verified using the contained public key, this bit
will be lit when the CIS is constructed.
Trust 0x02
The certificate has been signed by a trusted issuer. If the
certificate is self-signed and contains "trustRoot" in the Extended
Key Usage field, this bit will be lit when the CIS is constructed.
Private 0x04
The certificate is private and not to be revealed. If the certificate
is self-signed and contains "Private" in the Extended Key Usage
field, this bit will be lit when the CIS is constructed.
Error 0x80
The certificate is defective and not to be used in any way.
These flags can also be set by the identity schemes described below.
E.1 Private Certificate (PC) Scheme
The PC scheme uses a private certificate as group key. A certificate
is designated private for the purpose of the this scheme if the CIS
Private bit is lit. The certificate is distributed to all other group
members by secret means and never revealed outside the group. There
is no identity exchange, since the certificate itself is the group
key. Therefore, when the parameter exchange completes the VAL, IFF
and SGN bits are lit in the server status word. When the following
cookie exchange is complete, the PRV bit is lit and operation
continues as described in the main body of this document.
E.2 Trusted Certificate (TC) Scheme
The TC identification exchange follows the parameter exchange in
which the VAL bit is lit. It involves a conventional certificate
trail and a sequence of certificates, each signed by an issuer one
stratum level lower than the client, and terminating at a trusted
certificate, as described in [RFC-2510]. A certificate is designated
trusted for the purpose of the TC scheme if the CIS Trust bit is lit
and the certificate is self-signed. Such would normally be the case
when the trail ends at a primary (stratum 1) server, but the trail
can end at a secondary server if the security model permits this.
When a certificate is obtained from a server, or when a certificate
is signed by a server, A CIS for the new certificate is pushed on the
certificate list, but only if the certificate filestamp is greater
than any with the same subject name and issuer name already on the
list. The list is then scanned looking for signature opportunities.
If a CIS issuer name matches the subject name of another CIS and the
issuer certificate is verified using the public key of the subject
certificate, the Sign bit is lit in the issuer CIS. Furthermore, if
the Trust bit is lit in the subject CIS, the Trust bit is lit in the
issuer CIS.
The client continues to follow the certificate trail to a self-signed
certificate, lighting the Sign and Trust bits as it proceeds. If it
finds a self-signed certificate with Trust bit lit, the client lights
the IFF and PRV bits and the exchange completes. It can, however,
happen that the client finds a self-signed certificate with Trust bit
dark. This can happen when a server is just coming up, has
synchronized to a proventic source, but has not yet completed the
sign exchange. This is considered a temporary condition, so the
client simply retries at poll opportunities until the server
certificate is signed.
E.3 Schnorr (IFF) Scheme
The Schnorr (IFF) identity scheme is useful when certificates are
generated by means other than the NTP software library, such as a
trusted public authority. In this case a X.509v3 extension field
might not be available to convey the identity public key. The scheme
involves a set of parameters which persist for the life of the
scheme. New generations of these parameters must be securely
transmitted to all members of the group before use. The scheme is
self contained and independent of new generations of host keys, sign
keys and certificates.
The IFF identity scheme is based on DSA cryptography and algorithms
adapted from Stimson p. 285 [STIMSON]. The IFF parameters are
generated by OpenSSL routines normally used to generate DSA
parameters. By happy coincidence, the mathematical principles on
which IFF is based are similar to DSA, but only the prime p,
generator g and prime q are used in identity calculations. The p is a
512-bit prime and q a 160-bit prime that divides p - 1 and is a qth
root of 1 mod p; that is, g^q = 1 mod p. The trusted authority rolls
random group key a, computes public identity key v = g^(q - a) and
shares (p, g, q, a, v) with the group members. These values are never
revealed, although only a need be truly secret.
Alice challenges Bob to confirm identity using the following
exchange. Alice rolls new random challenge r and sends to Bob in the
IFF request message. Bob rolls new random k, then computes y = k + a
r mod q and x = g^k mod p and sends (y, hash(x)) to Alice in the IFF
response message. Besides making the response shorter, the hash makes
it effectively impossible for an intruder to solve for k and the
unpredictable nonces make it effectively impossible to solve for a by
monitoring multiple request and response message.
Alice receives the response and computes g^y v^r mod p. After a bit
of modular algebra, this simplifies to g^k. If hash(g^k) matches x,
Alice knows that Bob has the group key a. The signed response binds
this knowledge to Bob's private key and the public key previously
received in his certificate. On success the IFF and PRV bits are lit
in the server status word.
E.4 Guillard-Quisquater (GQ) Scheme
The Guillou-Quisquater (GQ) identity scheme is useful when
certificates are generated using the NTP software library. These
routines convey the GQ public key in a X.509v3 extension field. The
scheme involves a set of parameters which persist for the life of the
scheme and a private/public identity key, which is refreshed each
time a new certificate is generated. The scheme is self contained and
independent of new generations of host keys and sign keys and
certificates.
The GQ identity scheme is based on RSA cryptography and algorithms
adapted from Stimson p. 300 [STIMSON] (with errors corrected). The GQ
parameters are generated by OpenSSL routines normally used to
generate RSA keys. By happy coincidence, the mathematical principles
on which GQ is based are similar to RSA, but only the modulus n is
used in identity calculations. The 512-bit public modulus is n = p q,
where p and q are secret large primes, but not used in identity
calculations. The trusted authority rolls random group key b and
shares (n, b) with the group members. These values are never
revealed, although only b need be truly secret.
When generating a new certificate, group members roll a random nonce
u and compute its inverse v = (u^-1)^b obscured by the group key b.
Thus, each has a private identity key u and a public identity key v,
but not necessarily the same ones. The public key is conveyed on the
certificate in an extension field; the private key is never revealed.
Alice challenges Bob to confirm identity using the following
exchange. Alice rolls new random challenge r and sends to Bob in the
GQ request message. Bob rolls new random k, then computes y = k u^r
mod n and x = k^b mod n and sends (y, hash(x)) to Alice in the GQ
response message. Besides making the response shorter, the hash makes
it effectively impossible for an intruder to solve for b by observing
a number of these messages.
Alice receives the response and computes y^b v^r mod n. After a bit
of modular algebra, this simplifies to k^b. If hash(k^b) matches x,
Alice knows that Bob has the group key b. The signed response binds
this knowledge to Bob's private key and the public key previously
received in his certificate. Further evidence is the certificate
containing the public identity key, since this is also signed with
Bob's private key. On success the IFF and PRV bits are lit in the
server status word.
E.5 Interoperability Issues
A specific combination of authentication scheme (none, symmetric key,
Autokey), digest/signature scheme and identity scheme (PC, TC, GQ,
IFF) is called a cryptotype, although not all combinations are
possible. There may be management configurations where the servers
and clients may not all support the same cryptotypes. A secure NTPv4
subnet can be configured in several ways while keeping in mind the
principles explained in this section. Note however that some
cryptotype combinations may successfully interoperate with each
other, but may not represent good security practice.
The cryptotype of an association is determined at the time of
mobilization, either at configuration time or some time later when a
packet of appropriate cryptotype arrives. When a client, broadcast or
symmetric active association is mobilized at configuration time, it
can be designated non-authentic, authenticated with symmetric key or
authenticated with some Autokey scheme, and subsequently it will send
packets with that cryptotype. When a responding server, broadcast
client or symmetric passive association is mobilized, it is
designated with the same cryptotype as the received packet.
When multiple identity schemes are supported, the parameter exchange
determines which one is used. The request message contains bits
corresponding to the schemes it supports, while the response message
contains bits corresponding to the schemes it supports. The client
matches the server bits with its own and selects a compatible
identity scheme. The server is driven entirely by the client
selection and remains stateless. When multiple selections are
possible, the order from most secure to least is GC, IFF, TC. Note
that PC does not interoperate with any of the others, since they
require the host certificate which a PC server will not reveal.
Following the principle that time is a public value, a server
responds to any client packet that matches its cryptotype
capabilities. Thus, a server receiving a non-authenticated packet
will respond with a non-authenticated packet, while the same server
receiving a packet of a cryptotype it supports will respond with
packets of that cryptotype. However, new broadcast or manycast client
associations or symmetric passive associations will not be mobilized
unless the server supports a cryptotype compatible with the first
packet received. By default, non-authenticated associations will not
be mobilized unless overridden in a decidedly dangerous way.
Some examples may help to reduce confusion. Client Alice has no
specific cryptotype selected. Server Bob supports both symmetric key
and Autokey cryptography. Alice's non-authenticated packets arrive at
Bob, who replies with non-authenticated packets. Cathy has a copy of
Bob's symmetric key file and has selected key ID 4 in packets to Bob.
If Bob verifies the packet with key ID 4, he sends Cathy a reply with
that key. If authentication fails, Bob sends Cathy a thing called a
crypto-NAK, which tells her something broke. She can see the evidence
using the utility programs of the NTP software library.
Symmetric peers Bob and Denise have rolled their own host keys,
certificates and identity parameters and lit the host status bits for
the identity schemes they can support. Upon completion of the
parameter exchange, both parties know the digest/signature scheme and
available identity schemes of the other party. They do not have to
use the same schemes, but each party must use the digest/signature
scheme and one of the identity schemes supported by the other party.
It should be clear from the above that Bob can support all the girls
at the same time, as long as he has compatible authentication and
identification credentials. Now, Bob can act just like the girls in
his own choice of servers; he can run multiple configured
associations with multiple different servers (or the same server,
although that might not be useful). But, wise security policy might
preclude some cryptotype combinations; for instance, running an
identity scheme with one server and no authentication with another
might not be wise.
Appendix F. File Examples
This appendix shows the file formats used by the OpenSSL library and
the reference implementation. These are not included in the
specification and are given here only as examples. In each case the
actual file contents are shown followed by a dump produced by the
OpenSSL asn1 program.
F.1 RSA-MD5cert File and ASN.1 Encoding
# ntpkey_RSA-MD5cert_whimsy.udel.edu.3236983143
# Tue Jul 30 01:59:03 2002
-----BEGIN CERTIFICATE-----
MIIBkTCCATugAwIBAgIEwPBxZzANBgkqhkiG9w0BAQQFADAaMRgwFgYDVQQDEw93
aGltc3kudWRlbC5lZHUwHhcNMDIwNzMwMDE1OTA3WhcNMDMwNzMwMDE1OTA3WjAa
MRgwFgYDVQQDEw93aGltc3kudWRlbC5lZHUwWjANBgkqhkiG9w0BAQEFAANJADBG
AkEA2PpOz6toSQ3BtdGrBt+F6cSSde6zhayOwRj5nAkOvtQ505hdxWhudfKe7ZOY
HRLLqACvVJEfBaSvE5OFWldUqQIBA6NrMGkwDwYDVR0TAQH/BAUwAwEB/zALBgNV
HQ8EBAMCAoQwSQYDVR0OBEIEQEVFGZar3afoZcHDmhbgiOmaBrtWTlLHRwIJswge
LuqB1fbsNEgUqFebBR1Y9qLwYQUm7ylBD+3z9PlhcUOwtnIwDQYJKoZIhvcNAQEE
BQADQQAVZMiNbYV2BjvFH9x+t0PB9//giOV3fQoLK8hXXpyiAF4KLleEqP13pK0H
TceF3e3bxSRTndkIhklEAcbYXm66
-----END CERTIFICATE-----
0:d=0 hl=4 l= 401 cons: SEQUENCE
4:d=1 hl=4 l= 315 cons: SEQUENCE
8:d=2 hl=2 l= 3 cons: cont [ 0 ]
10:d=3 hl=2 l= 1 prim: INTEGER :02
13:d=2 hl=2 l= 4 prim: INTEGER :-3F0F8E99
19:d=2 hl=2 l= 13 cons: SEQUENCE
21:d=3 hl=2 l= 9 prim: OBJECT:md5WithRSAEncryption
32:d=3 hl=2 l= 0 prim: NULL
34:d=2 hl=2 l= 26 cons: SEQUENCE
36:d=3 hl=2 l= 24 cons: SET
38:d=4 hl=2 l= 22 cons: SEQUENCE
40:d=5 hl=2 l= 3 prim: OBJECT:commonName
45:d=5 hl=2 l= 15 prim: PRINTABLESTRING :whimsy.udel.edu
62:d=2 hl=2 l= 30 cons: SEQUENCE
64:d=3 hl=2 l= 13 prim: UTCTIME :020730015907Z
79:d=3 hl=2 l= 13 prim: UTCTIME :030730015907Z
94:d=2 hl=2 l= 26 cons: SEQUENCE
96:d=3 hl=2 l= 24 cons: SET
98:d=4 hl=2 l= 22 cons: SEQUENCE
100:d=5 hl=2 l= 3 prim: OBJECT:commonName
105:d=5 hl=2 l= 15 prim: PRINTABLESTRING :whimsy.udel.edu
122:d=2 hl=2 l= 90 cons: SEQUENCE
124:d=3 hl=2 l= 13 cons: SEQUENCE
126:d=4 hl=2 l= 9 prim: OBJECT:rsaEncryption
137:d=4 hl=2 l= 0 prim: NULL
139:d=3 hl=2 l= 73 prim: BIT STRING
214:d=2 hl=2 l= 107 cons: cont [ 3 ]
216:d=3 hl=2 l= 105 cons: SEQUENCE
218:d=4 hl=2 l= 15 cons: SEQUENCE
220:d=5 hl=2 l= 3 prim: OBJECT:X509v3 Basic Constraints
225:d=5 hl=2 l= 1 prim: BOOLEAN :255
228:d=5 hl=2 l= 5 prim: OCTET STRING
235:d=4 hl=2 l= 11 cons: SEQUENCE
237:d=5 hl=2 l= 3 prim: OBJECT:X509v3 Key Usage
242:d=5 hl=2 l= 4 prim: OCTET STRING
248:d=4 hl=2 l= 73 cons: SEQUENCE
250:d=5 hl=2 l= 3 prim: OBJECT:X509v3 Subject Key Identifier
255:d=5 hl=2 l= 66 prim: OCTET STRING
323:d=1 hl=2 l= 13 cons: SEQUENCE
325:d=2 hl=2 l= 9 prim: OBJECT:md5WithRSAEncryption
336:d=2 hl=2 l= 0 prim: NULL
338:d=1 hl=2 l= 65 prim: BIT STRING
F.2 GQkey File and ASN.1 Encoding
# ntpkey_GQkey_whimsy.udel.edu.3236983143
# Tue Jul 30 01:59:03 2002
-----BEGIN RSA PUBLIC KEY-----
MIGEAkAbYA9K8kpo2ki7Vq6cSkDccqe0RV6MTrFgjt/sp7E8Ki1mng45PJneAq9B
ZO4rlLYrftLoejQY/nJA2q3MK7iMAkBFRRmWq92n6GXBw5oW4Ijpmga7Vk5Sx0cC
CbMIHi7qgdX27DRIFKhXmwUdWPai8GEFJu8pQQ/t8/T5YXFDsLZy
-----END RSA PUBLIC KEY-----
0:d=0 hl=3 l= 132 cons: SEQUENCE
3:d=1 hl=2 l= 64 prim: INTEGER :<hex string omitted>
69:d=1 hl=2 l= 64 prim: INTEGER :<hex string omitted>
F.3 GQpar File and ASN.1 Encoding
# ntpkey_GQpar_whimsy.udel.edu.3236983143
# Tue Jul 30 01:59:03 2002
-----BEGIN RSA PUBLIC KEY-----
MIGFAkEAvojViJ3TowkOKpsb6HBZ50SfzC1M4mAGd51q91WhT7S7IZBfIF/emwXe
yJmZijRqYkCpQj+fp528yRwefq+IowJADgw/uaQ0qU/Q2JeMQ2JtSHKHCTmnVVPE
mXPvH9UU/AnMEuiG0LL6AkdxIZiXRuUrOtXsb22tifzMnc/yrus+2g==
-----END RSA PUBLIC KEY-----
0:d=0 hl=3 l= 133 cons: SEQUENCE
3:d=1 hl=2 l= 65 prim: INTEGER :<hex string omitted>
70:d=1 hl=2 l= 64 prim: INTEGER :<hex string omitted>
F.4 RSAkey File and ASN.1 Encoding
# ntpkey_RSAkey_whimsy.udel.edu.3236983143
# Tue Jul 30 01:59:03 2002
-----BEGIN RSA PRIVATE KEY-----
MIIBOgIBAAJBANj6Ts+raEkNwbXRqwbfhenEknXus4WsjsEY+ZwJDr7UOdOYXcVo
bnXynu2TmB0Sy6gAr1SRHwWkrxOThVpXVKkCAQMCQQCQpt81HPAws9Z5NnIElQPx
Lbb5Sc0DyF8rZfu9W18p4Zb5UH3KYqZfAO4K0GTmxuriFphgS9bELSw5L6ow4t6D
AiEA7ACLlKZtCp91CaDohViPhs7KBdRVq7DG9n88z9MM/gMCIQDrXRQMb2dqR/ww
PHJ7aljkhhTE78mxLpn2Po82PfYI4wIhAJ1VsmMZngcU+LEV8FjltQSJ3APi48fL
L07/fd/iCKlXAiEAnOi4CEpE8YVSytL2/PGQmFljLfUxIMm7+X8KJClOsJcCICgU
1w07kRO2ycicL2QRVh8J8vQL68VfH53H+oobKDCd
-----END RSA PRIVATE KEY-----
0:d=0 hl=4 l= 314 cons: SEQUENCE
4:d=1 hl=2 l= 1 prim: INTEGER :00
7:d=1 hl=2 l= 65 prim: INTEGER :<hex string omitted>
74:d=1 hl=2 l= 1 prim: INTEGER :03
77:d=1 hl=2 l= 65 prim: INTEGER :<hex string omitted>
144:d=1 hl=2 l= 33 prim: INTEGER :<hex string omitted>
179:d=1 hl=2 l= 33 prim: INTEGER :<hex string omitted>
214:d=1 hl=2 l= 33 prim: INTEGER :<hex string omitted>
249:d=1 hl=2 l= 33 prim: INTEGER :<hex string omitted>
284:d=1 hl=2 l= 32 prim: INTEGER :<hex string omitted>
F.5 IFFpar File and ASN.1 Encoding
# ntpkey_IFFpar_whimsy.udel.edu.3236983143
# Tue Jul 30 01:59:03 2002
-----BEGIN DSA PRIVATE KEY-----
MIH4AgEAAkEA7fBvqq9+3DH5BnBScMkruqH4QEB76oec1zjWQ23gyoP2U+L8tHfv
z2LmogOqE1c0McgQynyfQMSDUEmxMyiDwQIVAJ18qdV84wmiCGmWgsHKbpAwepDX
AkA4y42QqZ8aUzQRwkMuYTKbyRRnCG1TJi5eVJcCq65twl5c1bnn24xkbl+FXqck
G6w9NcDtSzuYg1gFLxEuWsYaAkEAjc+nPJR7VY4BjDleVTna07edDfcySl9vy8Pa
B4qArk51LdJlJ49yxEPUxFy/KBIFEHCwRZMc1J7z7dQ/Af26zQIUMXkbVz0D+2Yo
YlG0C/F33Q+N5No=
-----END DSA PRIVATE KEY-----
0:d=0 hl=3 l= 248 cons: SEQUENCE
3:d=1 hl=2 l= 1 prim: INTEGER :00
6:d=1 hl=2 l= 65 prim: INTEGER :<hex string omitted>
73:d=1 hl=2 l= 21 prim: INTEGER :<hex string omitted>
96:d=1 hl=2 l= 64 prim: INTEGER :<hex string omitted>
162:d=1 hl=2 l= 65 prim: INTEGER :<hex string omitted>
229:d=1 hl=2 l= 20 prim: INTEGER :<hex string omitted>
Appendix G. ASN.1 Encoding Rules
Certain value fields in request and response messages contain data
encoded in ASN.1 distinguished encoding rules (DER). The BNF grammer
for each encoding rule is given below along with the OpenSSL routine
used for the encoding in the reference implementation. The object
identifiers for the encryption algorithms and message
digest/signature encryption schemes are specified in [RFC-3279]. The
particular algorithms required for conformance are not specified in
this document.
G.1 COOKIE request, IFF response, GQ response
The value field of these messages contains a sequence of two integers
(x, y). For the COOKIE request, the values are encoded by the
i2d_RSAPublicKey() routine in the OpenSSL distribution. For the IFF
and GQ responses, the values are encoded by the i2d_DSA_SIG()
routine.
In the COOKIE request, x is the RSA modulus in bits and y is the
public exponent. In the IFF and GQ responses, x is the challenge
response and y is the hash of the private value.
RSAPublicKey ::= SEQUENCE {
x ::= INTEGER,
y ::= INTEGER
}
G.2 CERT response, SIGN request and response
The value field contains a X509v3 certificate encoded by the
i2d_X509() routine in the OpenSSL distribution. The encoding follows
the rules stated in [RFC-3280], including the use of X509v3 extension
fields.
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithmAlgorithmIdentifier,
signatureValue BIT STRING
}
The signatureAlgorithm is the object identifier of the message
digest/signature encryption scheme used to sign the certificate. The
signatureValue is computed by the certificate issuer using this
algorithm and the issuer private key.
TBSCertificate ::= SEQUENCE {
version EXPLICIT v3(2),
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
extensions EXPLICIT Extensions OPTIONAL
}
The serialNumber is an integer guaranteed to be unique for the
generating host. The reference implementation uses the NTP seconds
when the certificate was generated. The signature is the object
identifier of the message digest/signature encryption scheme used to
sign the certificate. It must be identical to the signatureAlgorithm.
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
notBefore UTCTime,
notAfter UTCTime
}
The notBefore and notAfter define the period of validity as defined
in and certificate filestamp are summarized in Appendix X.
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
The AlgorithmIdentifier specifies the encryption algorithm for the
subject public key. The subjectPublicKey is the public key of the
subject.
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
}
Name ::= SEQUENCE {
OBJECT IDENTIFIER commonName
PrintableString HostName
}
For all certificates, the subject HostName is the unique DNS name of
the host to which the public key belongs. The reference
implementation uses the string returned by the Unix gethostname()
routine (trailing NUL removed). For other than self-signed
certificates, the issuer HostName is the unique DNS name of the host
signing the certificate.
Security Considerations
Security issues are the main topic of this document.
Author's Addresses
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 USA
web www.eecis.udel.edu/~mills
Email: mills@udel.edu
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society, 2001. All Rights Reserved. This Copyright (C) The Internet Society (2002). All Rights Reserved.
document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist This document and translations of it may be copied and furnished to
in its implmentation may be prepared, copied, published and distributed, others, and derivative works that comment on or otherwise explain it
in whole or in part, without restriction of any kind, provided that the or assist in its implementation may be prepared, copied, published
above copyright notice and this paragraph are included on all such and distributed, in whole or in part, without restriction of any
copies and derivative works. However, this document itself may not be kind, provided that the above copyright notice and this paragraph are
modified in any way, such as by removing the copyright notice or included on all such copies and derivative works. However, this
references to the Internet Society or other Internet organizations, document itself may not be modified in any way, such as by removing
except as needed for the purpose of developing Internet standards in the copyright notice or references to the Internet Society or other
which case the procedures for copyrights defined in the Internet Internet organizations, except as needed for the purpose of
Standards process must be followed, or as required to translate it into. developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 265 change blocks. 
1282 lines changed or deleted 2297 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/