xref: /freebsd/contrib/ntp/html/authentic.html (revision e0c4386e)
1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2<html>
3  <head>
4    <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
5    <meta name="generator" content="HTML Tidy, see www.w3.org">
6    <title>Authentication Support</title>
7    <!-- Changed by: Harlan Stenn, 24-Jul-2018 -->
8    <link href="scripts/style.css" type="text/css" rel="stylesheet">
9    <style type="text/css">
10      <!--
11	  <style1 {
12		  color: #FF0000;
13		  font-weight: bold;
14		  }
15		  .style1 {color: #FF0000}
16		  -->
17    </style>
18  </head>
19  <body>
20    <h3>Authentication Support</h3>
21    <img src="pic/alice44.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
22    <p>Our resident cryptographer; now you see him, now you don't.</p>
23    <p>Last update:
24      <!-- #BeginDate format:En2m -->24-Jul-2018  09:12<!-- #EndDate -->
25      UTC</p>
26    <br clear="left">
27    <h4>Related Links</h4>
28    <script type="text/javascript" language="javascript" src="scripts/hand.txt"></script>
29    <script type="text/javascript" language="javascript" src="scripts/authopt.txt"></script>
30    <h4>Table of Contents</h4>
31    <ul>
32      <li class="inline"><a href="#auth">Introduction</a></li>
33      <li class="inline"><a href="#symm">Symmetric Key Cryptography</a></li>
34      <li class="inline"><a href="#windows">Microsoft Windows Authentication</a></li>
35      <li class="inline"><a href="#pub">Public Key Cryptography</a></li>
36    </ul>
37    <hr>
38    <h4 id="auth">Introduction</h4>
39    <p>This page describes the various cryptographic authentication
40      provisions in NTPv4.  Authentication support allows the NTP client to
41      verify that servers are in fact known and trusted and not intruders
42      intending accidentally or intentionally to masquerade as a legitimate
43      server.  A detailed discussion of the NTP multi-layer security model
44      and vulnerability analysis is in the white
45      paper <a href="http://www.eecis.udel.edu/~mills/security.html">NTP
46      Security Analysis</a>.</p>
47    <p>The NTPv3 specification (RFC-1305) defined an authentication scheme
48      properly described as <em>symmetric key cryptography</em>.  It used
49      the Data Encryption Standard (DES) algorithm operating in cipher-block
50      chaining (CBC) mode.  Subsequently, this algorithm was replaced by the
51      RSA Message Digest 5 (MD5) algorithm commonly called keyed-MD5.
52      Either algorithm computes a message digest or one-way hash which can
53      be used to verify the client has the same message digest as the
54      server.  The MD5 message digest algorithm is included in the
55      distribution, so without further cryptographic support, the
56      distribution can be freely exported.</p>
57    <p>If the OpenSSL cryptographic library is installed prior to building
58      the distribution, all message digest algorithms included in the
59      library may be used, including SHA and SHA1.  However, if conformance
60      to FIPS 140-2 is required, only a limited subset of these algorithms
61      can be used.  This library is available
62      from <a href="http://www.openssl.org">http://www.openssl.org</a> and
63      can be installed using the procedures outlined in
64      the <a href="build.html">Building and Installing the Distribution</a>
65      page.  Once installed, the configure and build process automatically
66      detects the library and links the library routines required.</p>
67    <p>In addition to the symmetric key algorithms, this distribution
68      includes support for the Autokey public key algorithms and protocol
69      specified in RFC-5906 &quot;Network Time Protocol Version 4: Autokey
70      Specification&quot;.  This support is available only if the OpenSSL
71      library has been installed and the <tt>--enable-autokey</tt> option is
72      used when the distribution is built.</p>
73    <p> Public key cryptography is generally considered more secure than
74      symmetric key cryptography, since the security is based on private and
75      public values which are generated by each participant and where the
76      private value is never revealed.  Autokey uses X.509 public
77      certificates, which can be produced by commercial services, the
78      OpenSSL application program, or
79      the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program in
80      the NTP software distribution.</p>
81    <p>Note that according to US law, NTP binaries including OpenSSL library
82      components, including the OpenSSL library itself, cannot be exported
83      outside the US without license from the US Department of Commerce.
84      Builders outside the US are advised to obtain the OpenSSL library
85      directly from OpenSSL, which is outside the US, and build outside the
86      US.</p>
87    <p>Authentication is configured separately for each association using
88      the <tt>key</tt> or <tt>autokey</tt> option of the <tt>server</tt>
89      configuration command, as described in
90      the <a href="confopt.html">Server Options</a> page.
91      The <a href="keygen.html">ntp-keygen</a> page describes the files
92      required for the various authentication schemes.  Further details are
93      in the briefings, papers and reports at the NTP project page linked
94      from <a href="http://www.ntp.org">www.ntp.org</a>.</p>
95    <p>By default, the client sends non-authenticated packets and the server
96      responds with non-authenticated packets.  If the client sends
97      authenticated packets, the server responds with authenticated packets
98      if correct, or a crypto-NAK packet if not.  In the case of unsolicited
99      packets which might consume significant resources, such as broadcast
100      or symmetric mode packets, authentication is required, unless
101      overridden by a <tt>disable auth</tt> command.  In the current climate
102      of targeted broadcast or &quot;letterbomb&quot; attacks, defeating
103      this requirement would be decidedly dangerous.  In any case,
104      the <tt>notrust </tt>flag, described on
105      the <a href="authopt.html">Access Control Options</a> page, can be
106      used to disable access to all but correctly authenticated clients.</p>
107    <h4 id="symm">Symmetric Key Cryptography</h4>
108    <p>The original NTPv3 specification (RFC-1305), as well as the current
109      NTPv4 specification (RFC-5905), allows any one of possibly 65,535
110      message digest keys (excluding zero), each distinguished by a 32-bit
111      key ID, to authenticate an association.  The servers and clients
112      involved must agree on the key ID, key type and key to authenticate
113      NTP packets.</p>
114    <p>The message digest is a cryptographic hash computed by an algorithm
115      such as MD5, SHA, or AES-128 CMAC.  When authentication is specified,
116      a message authentication code (MAC) is appended to the NTP packet
117      header.  The MAC consists of a 32-bit key identifier (key ID) followed
118      by a 128- or 160-bit message digest.  The algorithm computes the
119      digest as the hash of a 128- or 160- bit message digest key
120      concatenated with the NTP packet header fields with the exception of
121      the MAC.  On transmit, the message digest is computed and inserted in
122      the MAC.  On receive, the message digest is computed and compared with
123      the MAC.  The packet is accepted only if the two MACs are identical.
124      If a discrepancy is found by the client, the client ignores the
125      packet, but raises an alarm.  If this happens at the server, the
126      server returns a special message called a <em>crypto-NAK</em>.  Since
127      the crypto-NAK is protected by the loopback test, an intruder cannot
128      disrupt the protocol by sending a bogus crypto-NAK.</p>
129    <p>Keys and related information are specified in a keys file, which must
130      be distributed and stored using secure means beyond the scope of the
131      NTP protocol itself.  Besides the keys used for ordinary NTP
132      associations, additional keys can be used as passwords for
133      the <tt><a href="ntpq.html">ntpq</a></tt>
134      and <tt><a href="ntpdc.html">ntpdc</a></tt> utility programs.
135      Ordinarily, the <tt>ntp.keys</tt> file is generated by
136      the <tt><a href="keygen.html">ntp-keygen</a></tt> program, but it can
137      be constructed and edited using an ordinary text editor.</p>
138    <p> Each line of the keys file consists of three or four fields: a
139      key ID in the range 1 to 65,535, inclusive, a key type, a
140      message digest key consisting of a printable ASCII string up to
141      20 characters or a hex digit string with more than 20
142      characters, and an optional comma-separated list of IPs that are
143      allowed to serve time.  If the OpenSSL library is installed, the
144      key type can be any message digest algorithm supported by the
145      library.  If the OpenSSL library is not installed, the only
146      permitted key type is MD5.</p>
147    <table>
148      <caption style="caption-side: bottom;">
149	Figure 1. Typical Symmetric Key File
150      </caption>
151      <tr><td style="border: 1px solid black; border-spacing: 0;">
152	  <pre style="color:grey;">
153	    # ntpkey_MD5key_bk.ntp.org.3595864945
154	    # Thu Dec 12 19:22:25 2013
155
156	    1  MD5 L";Nw&lt;`.I&lt;f4U0)247"i  # MD5 key
157	    2  MD5 &amp;&gt;l0%XXK9O'51VwV&lt;xq~  # MD5 key
158	    3  MD5 lb4zLW~d^!K:]RsD'qb6  # MD5 key
159	    4  MD5 Yue:tL[+vR)M`n~bY,'?  # MD5 key
160	    5  MD5 B;fxlKgr/&amp;4ZTbL6=RxA  # MD5 key
161	    6  MD5 4eYwa`o}3i@@V@..R9!l  # MD5 key
162	    7  MD5 `A.([h+;wTQ|xfi%Sn_!  # MD5 key
163	    8  MD5 45:V,r4]l6y^JH6"Sh?F  # MD5 key
164	    9  MD5 3-5vcn*6l29DS?Xdsg)*  # MD5 key
165	    10 MD5 2late4Me              # MD5 key
166	    11 SHA1 a27872d3030a9025b8446c751b4551a7629af65c  # SHA1 key
167	    12 SHA1 21bc3b4865dbb9e920902abdccb3e04ff97a5e74  # SHA1 key
168	    13 SHA1 2b7736fe24fef5ba85ae11594132ab5d6f6daba9  # SHA1 key
169	    14 SHA  a5332809c8878dd3a5b918819108a111509aeceb  # SHA  key
170	    15 MD2  2fe16c88c760ff2f16d4267e36c1aa6c926e6964  # MD2  key
171	    16 MD4  b2691811dc19cfc0e2f9bcacd74213f29812183d  # MD4  key
172	    17 MD5  e4d6735b8bdad58ec5ffcb087300a17f7fef1f7c  # MD5  key
173	    18 MDC2 a8d5e2315c025bf3a79174c87fbd10477de2eabc  # MDC2 key
174	    19 RIPEMD160 77ca332cafb30e3cafb174dcd5b80ded7ba9b3d2  # RIPEMD160 key
175	    20 AES128CMAC f92ff73eee86c1e7dc638d6489a04e4e555af878  # AES128CMAC key
176	    21 MD5 sampo 10.1.2.3/24
177    </pre></td></tr></table>
178    <p>Figure 1 shows a typical symmetric keys file used by the reference
179      implementation when the OpenSSL library is installed.  Each line of
180      the file contains three or four fields.  The first field is an integer
181      between 1 and 65535, inclusive, representing the key identifier.  The
182      second field is the digest algorithm, which in the absence of the
183      OpenSSL library must be <tt>MD5</tt>, which designates the MD5 message
184      digest algorithm.  The third field is the key.  The optional fourth
185      field is one or more comma-separated IPs.  An IP may end with an
186      optional <tt>/subnetbits</tt> suffix, which limits the acceptance of
187      the key identifier to packets claiming to be from the described IP
188      space.  In this example, for the key IDs in the range 1-10 the key is
189      interpreted as a printable ASCII string.  For the key IDs in the range
190      11-20, the key is a 40-character hex digit string.  In either case,
191      the key is truncated or zero-filled internally to either 128 or 160
192      bits, depending on the key type.  The line can be edited later or new
193      lines can be added to change any field.  The key can be changed to a
194      password, such as <tt>2late4Me</tt> for key ID 10.  Note that two or
195      more keys files can be combined in any order as long as the key IDs
196      are distinct.</p>
197    <p>When <tt>ntpd</tt> is started, it reads the keys file specified by
198      the <tt>keys</tt> command and installs the keys in the key cache.
199      However, individual keys must be activated with
200      the <tt>trustedkey</tt> configuration command before use.  This
201      allows, for instance, the installation of possibly several batches of
202      keys and then activating a key remotely using <tt>ntpq</tt>
203      or <tt>ntpdc</tt>.  The <tt>requestkey</tt> command selects the key ID
204      used as the password for the <tt>ntpdc</tt> utility, while
205      the <tt>controlkey</tt> command selects the key ID used as the
206      password for the <tt>ntpq</tt> utility.</p>
207    <h4 id="windows">Microsoft Windows Authentication</h4>
208    <p>In addition to the above means, <tt>ntpd</tt> now supports Microsoft
209      Windows MS-SNTP authentication using Active Directory services.  This
210      support was contributed by the Samba Team and is still in development.
211      It is enabled using the <tt>mssntp</tt> flag of the <tt>restrict</tt>
212      command described on the <a href="accopt.html#restrict">Access Control
213      Options</a> page.  <span class="style1">Note: Potential users should
214      be aware that these services involve a TCP connection to another
215      process that could potentially block, denying services to other users.
216      Therefore, this flag should be used only for a dedicated server with
217      no clients other than MS-SNTP.</span></p>
218    <h4 id="pub">Public Key Cryptography</h4>
219    <p>See the <a href="autokey.html">Autokey Public-Key Authentication</a>
220      page.</p>
221    <hr>
222    <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
223  </body>
224</html>
225