NTP version 4 Release Notes HP-UX 11i v3 (5900-3073, March 2013)

address separately. If the kod flag is used in a restriction, which does not have the limited flag,
no KoD responses will result.
limited: Deny time service if the packet violates the rate limits established by the discard
command.
Burst options
Occasionally, it is necessary to send packets temporarily at intervals less than the poll interval.
With the burst and iburst options of the server command, the poll program sends a burst
of several packets at an interval of 2 seconds. In either case, the poll program avoids sending
needless packets if the server is not responding. The client begins a burst with a single packet.
When the first packet is received from the server, the client continues with the remaining packets
in the burst. If the first packet is not received within 64 seconds, it is sent again for two additional
retries before beginning backoff. The result is to minimize the network load if the server is not
responding.
The iburst keyword in the server configuration command is intended for cases, where
it is important to set the clock quickly when an association is first mobilized.
The burst keyword in the server configuration command is intended for cases, where the network
attachment requires an initial calling or training procedure.
OpenSSL cryptographic library
The OpenSSL cryptographic library has replaced the library formerly available from RSA
Laboratories. All cryptographic routines except a version of the MD5 message digest algorithm
are removed from the base distribution. All 128 bit and 160 bit message digests algorithms are
now supported for both symmetric key and public key cryptosystems.
Authentication support allows the NTP client to verify that servers are in fact known and trusted,
and prevent intruders from masquerading as legitimate servers. Public key cryptography is generally
considered more secure than symmetric key cryptography since, the security is based on private
and public values, which are generated by each participant and where the private value is never
revealed.
Autokey Public Key Authentication
NTP v4 includes support for Autokey Public Key cryptography for authenticating public servers to
clients, as described in RFC 5906. The deployment of Autokey subnets is now considerably simpler
than the earlier versions. A subnet naming scheme is now available to filter manycast and pool
configurations.
Public Key cryptography is generally considered more secure than Symmetric Key cryptography.
Symmetric Key cryptography is based on a shared secret key, which must be distributed by secure
means to all participants. Public Key cryptography is based on a private secret key known only to
the originator and a public key known to all participants. A recipient can verify the originator has
the correct private key using the public key and any of the several digital signature algorithms.
Autokey authenticates individual packets using cookies bound to the IP source and destination
addresses. The cookies must have the same IP addresses at both the server and client. For this
reason, operation with network address translation schemes is not possible. So, the NTP servers
and clients have to be operated outside firewall perimeters.
Autokey is designed to authenticate servers to clients, not the other way around as in SSH. An
Autokey server can support an authentication scheme such as the Trusted Certificate (TC) scheme
described in RFC 5906, while a client is free to choose between the various options. It is important
to understand that these provisions are optional and the selection of option is at the discretion of
the client. If the client does not require authentication, it is free to ignore it, even if some other client
of the same server elects to participate in either Symmetric Key or Public Key cryptography.
Utilities 9