6.2.2 Certification

Why does 6.2.2.1 need certification?

Most NTP users do not need authentication because the protocol itself contains many filters for bad times. However, certification is still present, and the use of certification is becoming more common. Some of the reasons may be:

You only want to use the time from the source of the trusted event.

An attacker could broadcast the wrong timestamp.

An attacker could disguise itself as another time server.

How is 6.2.2.2 certification applied?

NTP uses keys to implement authentication. These keys are used when exchanging data between two machines. As described in q:6.1.3.3 and 6.1.3.4, some of these usages are related to remote management. The authentication key can be specified when the server or peer is configured.

Usually, both sides need to know the keys. These keys exist in the/etc/ntp.keys typical plaintext and should therefore be properly concealed and not burst. This means that the keys need to be securely posted to all communication partners. The following examples are from html/notes.htm:

Peer 128.100.49.105 key 22peer 128.8.10.1     key 4peer 192.35.82.50   key 6# path for key FILEKEYS/USR/LOCAL/ETC/NTP.K Eystrustedkey 4 6 # define trusted Keysrequestkey    # key (7) for accessing server Variablescontrolkey 15
   # Key (6) for accessing server Variablesauthdelay 0.000094      # Authentication delay (sun4c/50 IPX)

This keyword key specifies the key to use when talking to the specified server. You must trust this key to synchronize time. Because authentication requires additional calculations, this keyword authdelay specifies the calculation time. This calculation can be done automatically in the updated version, however some older versions require an assembly called authspeed to determine the number for DES or MD5.

6.2.2.3 How do I create a key?

A key is just a serial number with a maximum of 8 ASCII codes (some characters that contain special meanings cannot be used).

M key is a serial number up to 41 acii yards.

S Key is a 64-bit value for which the lowest bit of each byte is a parity check.

A key is a 64-bit value where the highest bit of each byte is a parity check.

Now that you know the basic rules of keys, the password is the same as keys. See a valid keys example, see q:6.1.3.3, more information can be found in html/confopt.htm and html/notes.htm.

How does the 6.2.2.4 certification work?

Basic authentication is a digital signature, and there is no data encryption (if this is any different). The usual packet plus key is used to create an irreversible magic number appended to the end of the packet. The recipient (with the same key) does the same calculation and compares the results. If the results match, the certification succeeds.

6.2.2.5 can I add authentication without restarting NTPD?

You can and cannot: you can add the server dynamically by using the authentication key, and you can also trust and not trust any keys through the use of Xntpdckauai. You can also reread the key file with the Readkeys command. Unfortunately, you need basic authentication before using any of the commands.

6.2.2.6 How do I use the public key authentication AutoKey?

    You need extra RSA libraries, like Rsaref.    See Readme.rsa for instructions. You need the utility Ntp_genkeys to generate Key-pairs and the Diffie-hellman parameters file. All generated files has a timestamp suffix, it is recommended to install a symlink from the default name (without the TIM    Estamp extension) to the actual file: $ ntp_genkeys generating MD5 key file ...    Generating RSA public/private key pair (bits) ... Generating Diffie-hellman parameters (BITS) ... $ ls ntp.keys.3174020162 ntpkey_dh.3174020162 NT pkey.3174020162 Ntpkey_nops. belwue.de.3174020162 $ ln-s ntp.keys.3174020162 ntp.keys $ ln-s ntpkey.3174020162 ntpkey $ ln-s ntpkey_dh.3174 020162 NTPKEY_DH $ ln-s ntpkey_nops. belwue.de.3174020162 Ntpkey_nops. Belwue.de in this example, Nops. Belwue.de is the canonical name of the local host. It is automatically appended to the file names by Ntp_genkeys. File Ntpkey_nops. Belwue.de contains the public RSA Key of host Nops. Belwue.de. File Ntpkey contains the private RSA key.    Needless to say that Ntpkey and Ntp.keys must is not being world readable. Create a configuration file ntp.conf and a directory structure like This:crypto keysdir/etc/ntp/keys/etc/ntp/ Ntp.keys. Server noc1.belwue.de AutoKey version 4 server noc2.belwue.de autokey version 4 server Rustime 01.rus.uni-stuttgart.de version 3 peer Nepi. Belwue.de AutoKey version 4 .../etc/ntp//etc/ntp/leap-seconds.3169152000/etc/ntp/ntp.keys-Ntp.keys .3174020162/etc/ntp/ntp.keys.3174020162/etc/ntp/ntpkey-ntpkey.3174020162/etc/ntp/ntpkey.3174020162/e TC/NTP/NTPKEY_DH, Ntpkey_dh.3174020906/etc/ntp/ntpkey_dh.3174020906/etc/ntp/ntpkey_leap, leap-seconds.31 69152000/etc/ntp/ntpkey_nepi. Belwue.de, Ntpkey_nepi. Belwue.de.3174020497/etc/ntp/ntpkey_nepi. Belwue.de.3174020497/etc/ntp/ntpkey_nops. Belwue.de, Ntpkey_nops. belwue.de.3174020162/etc/ntp/ntpkey_nops. belwue.de.3174020162 File leap-seconds.3169152000 was downloaded from ftp://time.nist.gov/pub/. File Ntpkey_nepi. Belwue.de is the public RSA key of peer Nepi.  Belwue.de. File Ntpkey_dh is the same with all authenticated associations, it must be gkfx among all clients and servers of a security compartment. It does not matter on which host it is generated. You see, the public, RSA keys for, and the other, authenticated servers are missing.    They autokey mechanism is able to download these keys from the servers over the net.      If authentication is working, your should has output similar to this:ntpq> PE remote REFID St T when poll reach delay offset jitter =========================================================================           ===== Local (1) local (1) 6 L 377 0.000 0.000 0.000 +noc1.belwue.de DCFP. 1 u 415 1024x768 377 2.071 4.886 0.020 +noc2.belwue.de . DCFP.           1 u 520 1024x768 377 1.936 4.891 0.016 *rustime01.rus.u. Dcfp. 1 u 422 1024x768 377 3.855 3.829 0.037-nepi. Belwue.de rustime01.rus.u 2 U 259 1024x768 376 1.839 8.957 0.217 ntpq> as IND assid status conf reach au   Th condition last_event cnt =========================================================== 1 57740 9014 Yes Yes None reject reachable 1 2 57741 f4f4 Yes yes OK candidat reachable 3 57742 f4f4 Yes y   Es ok candidat reachable 4 57743 9634 Yes Yes none Sys.peer reachable 3 5 57744 f334 Yes    Yes OK outlyer reachable 3 ntpq> rv status=06f4 leap_none, SYNC_NTP, events, EVENT_PEER/STRAT_CHG, version= "ntpd 4.0.99k-r Thu Jul 15:41:30 MET DST (7)", processor= "sun4u", system= "SunOS5.6", leap=00, stratum= 2, Precision=-15, rootdelay=3.855, rootdispersion=25.972, peer=57743, Refid=rustime01.rus.uni-stuttgart.de,   reftime=bd4d0006.7ba24894 Tue, 15:35:02.482, poll=10, Clock=bd4d01be.a8915bdd Tue, 22 2000 15:42:2 2.658, state=4, phase=4.548, frequency=7.357, jitter=1.913, stability=0.016, hostname= "Nops. Belwue.de ", publickey=3174020162, params=3174020906, refresh=3175878685, leaptable=3169152000, tai=32

6.2.2 Certification