Commit 1b64550b authored by Eric S. Raymond's avatar Eric S. Raymond

Remove and/or fix obsolete references in the documentation.

parent 14f41c66
......@@ -59,32 +59,30 @@ discarded.
The +auth+ flag controls whether new associations or remote
configuration commands require cryptographic authentication. This flag
can be set or reset by the +enable+ and +disable+ commands and also by
remote configuration commands sent by a {ntpqman} program
running in another machine. If this flag is enabled, which is the
default case, new broadcast client and symmetric passive associations
and remote configuration commands must be cryptographically
authenticated using either symmetric key or public key cryptography. If
remote configuration commands sent by a {ntpqman} program running in
another machine. If this flag is enabled, which is the default case,
new broadcast client and symmetric passive associations and remote
configuration commands must be cryptographically authenticated. If
this flag is disabled, these operations are effective even if not
cryptographic authenticated. It should be understood that operating with
the +auth+ flag disabled invites a significant vulnerability where a rogue
hacker can masquerade as a falseticker and seriously disrupt system
timekeeping. It is important to note that this flag has no purpose other
than to allow or disallow a new association in response to new broadcast
and symmetric active messages and remote configuration commands and, in
particular, the flag has no effect on the authentication process
itself.
cryptographic authenticated. It should be understood that operating
with the +auth+ flag disabled invites a significant vulnerability
where a cracker can masquerade as a falseticker and seriously disrupt
system timekeeping. It is important to note that this flag has no
purpose other than to allow or disallow a new association in response
to new broadcast and symmetric active messages and remote
configuration commands and, in particular, the flag has no effect on
the authentication process itself.
An attractive alternative where multicast support is available is
manycast mode, in which clients periodically troll for servers as
described in the 'Automatic NTP Configuration Options' page of the Web
documentation. Either symmetric key or public key cryptographic
authentication can be used in this mode. The principle advantage of
manycast mode is that potential servers need not be configured in
advance, since the client finds them during regular operation, and the
configuration files for all clients can be identical.
documentation. Authentication can be used in this mode. The principle
advantage of manycast mode is that potential servers need not be
configured in advance, since the client finds them during regular
operation, and the configuration files for all clients can be
identical.
The security model and protocol schemes for symmetric key
//and public key cryptography
are summarized below; further details are in the
briefings, papers and reports at the {project-fullname} page linked from
{project-website}.
......@@ -293,9 +291,6 @@ for the +{ntpq}+ utility.
//users. Therefore, this flag should be used only for a dedicated server
//with no clients other than MS-SNTP.
[[pub]]
== Public Key Cryptography ==
'''''
include::includes/footer.txt[]
......@@ -317,9 +317,9 @@ advance and all clients throughout the network can have the same
configuration file.
The use of cryptographic authentication is always a good idea in any
server discovery scheme. Both symmetric key and public key cryptography
can be used in the same scenarios as described above for the
broadcast/multicast scheme.
server discovery scheme. Cryptographic authentication can be used in
the same scenarios as described above for the broadcast/multicast
scheme.
[[pool]]
== Server Pool Scheme ==
......
......@@ -8,8 +8,8 @@
server, then enters the broadcast client mode, in which it
synchronizes to succeeding broadcast messages. Note that, in order to
avoid accidental or malicious disruption in this mode, both the server
and client should operate using symmetric-key or public-key
authentication as described on the "Authentication Options" page.
and client should operate using authentication as described on the
"Authentication Options" page.
+manycastserver+ _address..._::
This command enables reception of manycast client messages to the
......@@ -19,8 +19,7 @@
span of the reply and avoid a possibly massive implosion at the
original sender. Note that, in order to avoid accidental or malicious
disruption in this mode, both the server and client should operate
using symmetric-key or public-key authentication as described on the
"Authentication Options" page.
using authentication as described on the "Authentication Options" page.
+multicastclient+ _address..._::
This command enables reception of multicast server messages to the
......@@ -30,8 +29,8 @@
server, then enters the broadcast client mode, in which it
synchronizes to succeeding multicast messages. Note that, in order to
avoid accidental or malicious disruption in this mode, both the server
and client should operate using symmetric-key or public-key
authentication as described on the "Authentication Options" page.
and client should operate using authentication as described on the
"Authentication Options" page.
+mdnstries+ _number_::
If we are participating in mDNS, after we have synched for the first
......
......@@ -42,8 +42,8 @@ and that file system links, symbolic or otherwise, should be avoided.
+auth+;;
Enables the server to synchronize with unconfigured peers only if
the peer has been correctly authenticated using either public key or
private key cryptography. The default for this flag is +enable+.
the peer has been correctly authenticated. The default for this
flag is +enable+.
+bclient+;;
Enables the server to listen for a message from a broadcast or
multicast server, as in the +multicastclient+ command with default
......
......@@ -22,7 +22,7 @@ clock in decoded ASCII format, where meaningful. In some clock drivers
a good deal of additional information can be gathered and displayed as
well. See information specific to each clock for further details.
+cryptostats+;;
+cdcryptostats+;;
This option requires the OpenSSL cryptographic software library. It
enables recording of cryptographic public key protocol information.
Each message received by the protocol module appends a line of the
......
......@@ -275,8 +275,7 @@ link:access.html[Access Control Support]::
Describes the access control mechanisms that can be used to limit
client access to various time and management functions.
link:authentic.html[Authentication Support]::
Describes the authentication mechanisms for symmetric-key and
public-key cryptography.
Describes the cryptographic authentication mechanisms.
link:rate.html[Rate Management]::
Describes the principles of rate management to minimize network load
and defend against DoS attacks.
......
docs/pic/time1.gif

4.4 KB | W: | H:

docs/pic/time1.gif

2.26 KB | W: | H:

docs/pic/time1.gif
docs/pic/time1.gif
docs/pic/time1.gif
docs/pic/time1.gif
  • 2-up
  • Swipe
  • Onion skin
......@@ -39,9 +39,7 @@ Research Project] web site.
NTP time synchronization services are widely available in the public
Internet. The public NTP subnet currently includes several thousand
servers in most countries and on every continent of the globe, including
Antarctica, and sometimes in space and on the sea floor. These servers
support, directly or indirectly, a total population estimated at over 25
million computers in the global Internet.
Antarctica, and sometimes in space and on the sea floor.
The NTP subnet operates with a hierarchy of levels, where each level is
assigned a number called the stratum. Stratum 1 (primary) servers at the
......@@ -97,22 +95,24 @@ link:leap.html[Leap Second Processing] page.
image:pic/time1.gif[]
Figure 1. NTP Data Formats
Figure 1 shows two NTP time formats, a 64-bit _timestamp_ format and a
128-bit _datestamp_ format. The datestamp format is used internally,
while the timestamp format is used in packet headers exchanged between
clients and servers. The timestamp format spans 136 years, called an
_era_. The current era began on 1 January 1900, while the next one
begins in 2036. Details on these formats and conversions between them
are in the white paper {millshome}y2k.html[The NTP
Era and Era Numbering]. However, the NTP protocol will synchronize
correctly, regardless of era, as long as the system clock is set
initially within 68 years of the correct time. Further discussion on
this issue is in the white paper
{millshome}time.html[NTP Timestamp Calculations].
Ordinarily, these formats are not seen by application programs, which
convert these NTP formats to native formats.
Figure 1. NTP Timestamp format
Figure 1 shows the timestamp format used in packet headers exchanged
between clients and servers. Ordinarily, this timestamp format is not
seen by application programs, which converts it to native formats such
as ISO8601 or RFC822-style Gregorian-calendar dates.
The timestamp format spans 136 years, called an _era_. Conceptually,
it is helpful to think of an absolute dates as being a tuple of one of
these timestamps and an era number. The current era, era 0, began on 1
January 1900, while the next one begins in 2036.
Details on converting between era-timestamp pairs and timestamps are
in the white paper {millshome}y2k.html[The NTP Era and Era
Numbering]. The NTP protocol will synchronize correctly, regardless of
era, as long as the system clock is set initially within 68 years (a
half-era) of the correct time. Further discussion on this issue is in
the white paper {millshome}time.html[NTP Timestamp Calculations].
[[arch]]
== 3. Architecture and Algorithms ==
......@@ -132,7 +132,7 @@ server using the _on-wire protocol_ described in the white paper
the NTP On-Wire Protocols]. The protocol is resistant to lost, replayed
or spoofed packets.
The poll process sends NTP packets at intervals ranging from 8 s to 36
The poll process sends NTP packets at intervals ranging from 1 s to 36
hr. The intervals are managed as described on the link:poll.html[Poll
Process] page to maximize accuracy while minimizing network load. The
peer process receives NTP packets and performs the packet sanity tests
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment