B.3 PUBLIC DOMAIN XNTP PACKAGE
A note should be made for those clients not using the public domain xntp package. As defined
by RFC1305, the cryptochecksum takes up 64 bits (8 bytes) in the ntp message. Because the
MD5 algorithm produces 128 bits (16 bytes) of cryptochecksum, the ntp packet is enlarged by 8
bytes to handle the entire cryptochecksum. As this field is the last in the packet, it should not
present any difficulty.
B.4 NTP AUTHENTICATION ONLY
The NTP Authentication ONLY mechanism is an added feature in the TS2000 and not part of the
ntp specification as detailed in RFC1305. This mechanism provides a way to restrict access to
the TS2000. To understand this mechanism, it is pertinent to first understand the way ntp
(RFC1305) defines the authentication process. If authentication is enabled, and a valid
authentication key identifier and cryptochecksum is received, then the ntp packet is filled in and
a new cryptochecksum is computed and added to the packet. The packet is then sent back to the
client. However, if authentication is enabled, and an authentication failure occurs, either because
the key identifier is 0 (defined as no encryption) or unrecognized, or the cryptochecksum is
invalid, the ntp packet is STILL RETURNED, but will contain no authentication data. Many of
our customers have expressed an interest in somehow adapting the authentication mechanism to
allow them to restrict access to the TS2000, for security or administrative purposes. The NTP
Authentication ONLY mechanism provides that capability. If NTP Authentication has been
enabled, and the customer enables the NTP Authentication ONLY mode, the TS2000 will discard
any incoming ntp packet which does not contain both a valid key identifier (not equal to 0) and a
valid cryptochecksum. In this way, the customer can limit access to the TS2000 to only those
clients who have been given the key identifier/secret MD5 key pair.
To Next Page
Loading...
General