aboutsummaryrefslogtreecommitdiff
path: root/html/authentic.html
diff options
context:
space:
mode:
Diffstat (limited to 'html/authentic.html')
-rw-r--r--html/authentic.html38
1 files changed, 32 insertions, 6 deletions
diff --git a/html/authentic.html b/html/authentic.html
index e529a6d18480..06bb67bc727a 100644
--- a/html/authentic.html
+++ b/html/authentic.html
@@ -46,14 +46,40 @@ required.</p>
<p>By default, the client sends non-authenticated packets and the server responds with non-authenticated packets. If the client sends authenticated packets, the server responds with authenticated packets if correct, or a crypto-NAK packet if not. In the case of unsolicited packets which might consume significant resources, such as broadcast or symmetric mode packets, authentication is required, unless overridden by a <tt>disable auth</tt> command. In the current climate of targeted broadcast or &quot;letterbomb&quot; attacks, defeating this requirement would be decidedly dangerous. In any case, the <tt>notrust </tt>flag, described on the <a href="authopt.html">Access Control Options</a> page, can be used to disable access to all but correctly authenticated clients.</p>
<h4 id="symm">Symmetric Key Cryptography</h4>
<p>The original NTPv3 specification (RFC-1305), as well as the current NTPv4 specification (RFC-5905), allows any one of possibly 65,534 message digest keys (excluding zero), each distinguished by a 32-bit key ID, to authenticate an association. The servers and clients involved must agree on the key ID, key type and key to authenticate NTP packets.</p>
-<p>The message digest is a cryptographic hash computed by an algorithm such as MD5 or SHA. When authentication is specified, a message authentication code (MAC) is appended to the NTP packet header. The MAC consists of a 32-bit key identifier (key ID) followed by a 128- or 160-bit message digest. The algorithm computes the digest as the hash of a 128- or 160- bit message digest key concatenated with the NTP packet header fields with the exception of the MAC. On transmit, the message digest is computed and inserted in the MAC. On receive, the message digest is computed and compared with the MAC. The packet is accepted only if the two MACs are identical. If a discrepancy is found by the client, the client ignores the packet, but raises an alarm. If this happens at the server, the server returns a special message called a <em>crypto-NAK</em>. Since the crypto-NAK is protected by the loopback test, an intruder cannot disrupt the protocol by sending a bogus crypto-NAK.</p>
+<p>The message digest is a cryptographic hash computed by an algorithm such as MD5, SHA, or AES-128 CMAC. When authentication is specified, a message authentication code (MAC) is appended to the NTP packet header. The MAC consists of a 32-bit key identifier (key ID) followed by a 128- or 160-bit message digest. The algorithm computes the digest as the hash of a 128- or 160- bit message digest key concatenated with the NTP packet header fields with the exception of the MAC. On transmit, the message digest is computed and inserted in the MAC. On receive, the message digest is computed and compared with the MAC. The packet is accepted only if the two MACs are identical. If a discrepancy is found by the client, the client ignores the packet, but raises an alarm. If this happens at the server, the server returns a special message called a <em>crypto-NAK</em>. Since the crypto-NAK is protected by the loopback test, an intruder cannot disrupt the protocol by sending a bogus crypto-NAK.</p>
<p>Keys and related information are specified in a keys file, which must be distributed and stored using secure means beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be used as passwords for the <tt><a href="ntpq.html">ntpq</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> utility programs. Ordinarily, the <tt>ntp.keys</tt> file is generated by the <tt><a href="keygen.html">ntp-keygen</a></tt> program, but it can be constructed and edited using an ordinary text editor.</p>
<p> Each line of the keys file consists of three or four fields: a key ID in the range 1 to 65,534, inclusive, a key type, a message digest key consisting of a printable ASCII string less than 40 characters or a 40-character hex digit string, and an optional comma-separated list of IPs that are allowed to serve time. If the OpenSSL library is installed, the key type can be any message digest algorithm supported by the library. If the OpenSSL library is not installed, the only permitted key type is MD5.</p>
-<div align="center">
- <p><img src="pic/sx5.gif" alt="gif"></p>
- <p>Figure 1. Typical Symmetric Key File</p>
-</div>
-<p>Figure 1 shows a typical keys file used by the reference implementation when the OpenSSL library is installed. In this figure, for key IDs in he range 1-10, the key is interpreted as a printable ASCII string. For key IDs in the range 11-20, the key is a 40-character hex digit string. The key is truncated or zero-filled internally to either 128 or 160 bits, depending on the key type. The line can be edited later or new lines can be added to change any field. The key can be change to a password, such as <tt>2late4Me</tt> for key ID 10. Note that two or more keys files can be combined in any order as long as the key IDs are distinct.</p>
+<table>
+ <caption style="caption-side: bottom;">
+ Figure 1. Typical Symmetric Key File
+ </caption>
+ <tr><td style="border: 1px solid black; border-spacing: 0;">
+ <pre style="color:grey;">
+# ntpkey_MD5key_bk.ntp.org.3595864945
+# Thu Dec 12 19:22:25 2013
+
+1 MD5 L";Nw&lt;`.I&lt;f4U0)247"i # MD5 key
+2 MD5 &amp;&gt;l0%XXK9O'51VwV&lt;xq~ # MD5 key
+3 MD5 lb4zLW~d^!K:]RsD'qb6 # MD5 key
+4 MD5 Yue:tL[+vR)M`n~bY,'? # MD5 key
+5 MD5 B;fxlKgr/&amp;4ZTbL6=RxA # MD5 key
+6 MD5 4eYwa`o}3i@@V@..R9!l # MD5 key
+7 MD5 `A.([h+;wTQ|xfi%Sn_! # MD5 key
+8 MD5 45:V,r4]l6y^JH6"Sh?F # MD5 key
+9 MD5 3-5vcn*6l29DS?Xdsg)* # MD5 key
+10 MD5 2late4Me # MD5 key
+11 SHA1 a27872d3030a9025b8446c751b4551a7629af65c # SHA1 key
+12 SHA1 21bc3b4865dbb9e920902abdccb3e04ff97a5e74 # SHA1 key
+13 SHA1 2b7736fe24fef5ba85ae11594132ab5d6f6daba9 # SHA1 key
+14 SHA a5332809c8878dd3a5b918819108a111509aeceb # SHA key
+15 MD2 2fe16c88c760ff2f16d4267e36c1aa6c926e6964 # MD2 key
+16 MD4 b2691811dc19cfc0e2f9bcacd74213f29812183d # MD4 key
+17 MD5 e4d6735b8bdad58ec5ffcb087300a17f7fef1f7c # MD5 key
+18 MDC2 a8d5e2315c025bf3a79174c87fbd10477de2eabc # MDC2 key
+19 RIPEMD160 77ca332cafb30e3cafb174dcd5b80ded7ba9b3d2 # RIPEMD160 key
+20 AES128CMAC f92ff73eee86c1e7dc638d6489a04e4e555af878 # AES128CMAC key
+ </pre></td></tr></table>
+<p>Figure 1 shows a typical keys file used by the reference implementation when the OpenSSL library is installed. In this figure, for key IDs in he range 1-10, the key is interpreted as a printable ASCII string. For key IDs in the range 11-20, the key is a 40-character hex digit string. The key is truncated or zero-filled internally to either 128 or 160 bits, depending on the key type. The line can be edited later or new lines can be added to change any field. The key can be changed to a password, such as <tt>2late4Me</tt> for key ID 10. Note that two or more keys files can be combined in any order as long as the key IDs are distinct.</p>
<p>When <tt>ntpd</tt> is started, it reads the keys file specified by the <tt>keys</tt> command and installs the keys in the key cache. However, individual keys must be activated with the <tt>trustedkey</tt> configuration command before use. This allows, for instance, the installation of possibly several batches of keys and then activating a key remotely using <tt>ntpq</tt> or <tt>ntpdc</tt>. The <tt>requestkey</tt> command selects the key ID used as the password for the <tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects the key ID used as the password for the <tt>ntpq</tt> utility.</p>
<h4 id="windows">Microsoft Windows Authentication</h4>
<p>In addition to the above means, <tt>ntpd</tt> now supports Microsoft Windows MS-SNTP authentication using Active Directory services. This support was contributed by the Samba Team and is still in development. It is enabled using the <tt>mssntp</tt> flag of the <tt>restrict</tt> command described on the <a href="accopt.html#restrict">Access Control Options</a> page. <span class="style1">Note: Potential users should be aware that these services involve a TCP connection to another process that could potentially block, denying services to other users. Therefore, this flag should be used only for a dedicated server with no clients other than MS-SNTP.</span></p>