[Git][NTPsec/ntpsec][master] 10 commits: Removed comments for a batch of unused symbols

Hal Murray gitlab at mg.gitlab.com
Mon Jan 8 10:06:21 UTC 2018


Hal Murray pushed to branch master at NTPsec / ntpsec


Commits:
fc31d061 by Hal Murray at 2018-01-08T02:05:30-08:00
Removed comments for a batch of unused symbols

- - - - -
79e7cfc6 by Hal Murray at 2018-01-08T02:05:30-08:00
Remove out of date crypto stuff.

- - - - -
38217f6b by Hal Murray at 2018-01-08T02:05:30-08:00
Use NID_undef rather than depending on it being 0.

- - - - -
fc0f8f7c by Hal Murray at 2018-01-08T02:05:30-08:00
Bug fixes: --enable-debug and -n

- - - - -
f1a19035 by Hal Murray at 2018-01-08T02:05:30-08:00
Add attic/digest.c to print info on available digests.

- - - - -
972ff12a by Hal Murray at 2018-01-08T02:05:30-08:00
Print more info if a keys file uses a non-working digest type.

- - - - -
2c5b0fb5 by Hal Murray at 2018-01-08T02:05:30-08:00
Fix printout of Droproot support.

  It was broken when we changed write_config() to
  remove the symbols it wrote to config.h

- - - - -
c393d629 by Hal Murray at 2018-01-08T02:05:30-08:00
Lots of work on documentation, mostly crypto related.

- - - - -
b8121d2f by Hal Murray at 2018-01-08T02:05:30-08:00
Drop MD5 and SHA1 comments from keys file

They are redundant at best and misleading if you
change the type.

- - - - -
e349aa13 by Hal Murray at 2018-01-08T02:05:30-08:00
More documentation fixes, mostly authentication

- - - - -


17 changed files:

- + attic/digest.c
- attic/wscript
- devel/ifdex-ignores
- docs/authentic.txt
- docs/debug.txt
- docs/includes/access-commands.txt
- docs/includes/ntp-conf-body.txt
- docs/includes/ntpd-body.txt
- docs/includes/ntpkeygen-body.txt
- docs/includes/ntpq-body.txt
- docs/mode6.txt
- docs/msyslog.txt
- docs/ntpkeygen.txt
- libntp/authreadkeys.c
- ntpclients/ntpkeygen.py
- ntpd/ntp.keys-man.txt
- wscript


Changes:

=====================================
attic/digest.c
=====================================
--- /dev/null
+++ b/attic/digest.c
@@ -0,0 +1,80 @@
+/* 
+ * digest.c - Hack to test various digest types.
+ *
+ * Fedora mentions blake2b and friends.  They are in the man page
+ * and header files, but not available via OBJ_sn2n so I assume they
+ * are not interesting and dropped them to reduce clutter.
+ *
+ * If the type column is blank, the OpenSSL package doesn't know
+ * about that digest, maybe because it isn't spelled correctly.
+ *
+ * If the type column is non-blank but the length column is empty,
+ * the library recognizes the type but doesn't support it.
+ *
+ * If the length column is filled in, that's the length of the digest.
+ *
+ */
+
+#include <stdio.h>
+
+#include <openssl/objects.h>
+#include <openssl/evp.h>
+
+#include "ntp_types.h"
+
+
+
+const char* digests[] = {
+  "MD2", "MD4", "MD5",
+  "SHA", "SHA1",
+  "RMD160", "RIPEMD160",
+  "SHA224", "SHA256", "SHA384", "SHA512",
+  "MDC2", "GOST", "DSS1",
+  NULL };
+
+int pkt[10];
+int
+main (
+	int argc,
+	char *argv[]
+	)
+{
+  UNUSED_ARG(argc);
+  UNUSED_ARG(argv);
+
+  unsigned int version = OPENSSL_VERSION_NUMBER;
+  printf("OpenSSL Version is %x\n", version);
+
+  /* needed if OPENSSL_VERSION_NUMBER < 0x10100000L */
+  OpenSSL_add_all_digests();
+
+
+  printf("      name type length\n");
+  for (int i = 0; NULL != digests[i]; i++) {
+    uint8_t digest[EVP_MAX_MD_SIZE];
+    unsigned int length = 0;
+    EVP_MD_CTX *ctx;
+    int keytype;
+    const EVP_MD *md;
+    keytype = OBJ_sn2nid(digests[i]);
+    if (NID_undef == keytype) {
+      printf("%10s\n", digests[i]);
+      continue;
+    }
+    md = EVP_get_digestbynid(keytype);
+    if (NULL == md) {
+      printf("%10s %4d\n", digests[i], keytype);
+      continue;
+    }
+    ctx = EVP_MD_CTX_create();
+    /* libntp/macencrypt.c has an ifdef for this */
+    EVP_MD_CTX_set_flags(ctx, EVP_MD_CTX_FLAG_NON_FIPS_ALLOW);
+    EVP_DigestInit_ex(ctx, md, NULL);
+    EVP_DigestUpdate(ctx, (uint8_t *)pkt, sizeof(pkt));
+    EVP_DigestFinal_ex(ctx, digest, &length);
+    EVP_MD_CTX_destroy(ctx);
+    printf("%10s %4d %6u\n", digests[i], keytype, length);
+  }
+
+  return 0;
+}


=====================================
attic/wscript
=====================================
--- a/attic/wscript
+++ b/attic/wscript
@@ -1,7 +1,7 @@
 def build(ctx):
     bldnode = ctx.bldnode.abspath()
 
-    util = ['sht']
+    util = ['sht', 'digest']
 
     for name in util:
         ctx(


=====================================
devel/ifdex-ignores
=====================================
--- a/devel/ifdex-ignores
+++ b/devel/ifdex-ignores
@@ -74,18 +74,6 @@ HAVE_SECCOMP_H
 HAVE_SOLARIS_PRIVS
 WORDS_BIGENDIAN
 
-# Overrides
-OVERRIDE_BINTIME_CTLMSGBUF_SIZE
-OVERRIDE_FD_CHUNK
-OVERRIDE_FD_PREFERRED_SOCKBOUNDARY
-MAXASSOC		# Can't change this before ntpq library refactoring
-MAXLIST			# Can't change this before ntpq library refactoring
-OVERRIDE_NTIME_MSG
-OVERRIDE_OTIME_MSG
-OVERRIDE_THREAD_MINSTACKSIZE
-OVERRIDE_TIMESTAMPNS_CTLMSGBUF_SIZE
-OVERRIDE_TIMESTAMP_CTLMSGBUF_SIZE
-
 # Constants in time and calendar logic
 DAY_GPS_STARTS
 DAY_NTP_STARTS


=====================================
docs/authentic.txt
=====================================
--- a/docs/authentic.txt
+++ b/docs/authentic.txt
@@ -23,7 +23,6 @@ include::includes/authopt.txt[]
 * link:#algorithms[Algorithms]
 * link:#formats[Data Formats]
 //* link:#windows[Microsoft Windows Authentication]
-* link:#pub[Public Key Cryptography]
 
 '''''
 
@@ -32,32 +31,25 @@ include::includes/authopt.txt[]
 Authentication support allows the NTP client to verify that the server
 is in fact known and trusted and not an intruder intending
 accidentally or on purpose to masquerade as that server.  NTP performs
-authentication via the RSA Message Digest 5 (MD5) algorithm using a
-private key, commonly called keyed-MD5. Either algorithm computes a
-message digest, or one-way hash, which can be used to verify the
-server has the correct private key and key identifier.
+authentication via message digests. It computes a one-way hash, which
+verifies that the server has the correct private key and key identifier.
 
 A detailed discussion of the NTP multi-layer security model and
 vulnerability analysis is in the white paper
 {millshome}security.html[NTP Security Analysis].
 
 Authentication is configured separately for each association using the +key+
-subcommand on the +peer+, +server+, and +broadcast+
-configuration commands. The authentication options described below
-specify the locations of the key files, if other than default, which
-symmetric keys are trusted and the interval between various
-operations, if other than default.
+subcommand on the +server+ configuration commands. The authentication
+options described below specify the locations of the key files and
+which symmetric keys are trusted.
 
 Authentication is always enabled, although ineffective if not configured
 as described below. If a NTP packet arrives including a message
 authentication code (MAC), it is accepted only if it passes all
 cryptographic checks. The checks require correct key ID, key value and
-message digest. If the packet has been modified in any way or replayed
+message digest. If the packet has been modified in any way
 by an intruder, it will fail one or more of these checks and be
-discarded.
-
-The security model and protocol schemes for symmetric key
-are summarized below.
+discarded.  Authentication doesn't prevent replays.
 
 [[symm]]
 === Symmetric-Key Cryptography ===
@@ -66,7 +58,7 @@ NTP allows any one of possibly 65,534 keys, each distinguished by a
 32-bit key identifier, to authenticate an association. The servers and
 clients involved must agree on the key and key identifier to
 authenticate NTP packets. Keys and related information are specified
-in a key file, usually called _ntp.keys_, which must be distributed
+in a key file. More info in {ntpkeysman}. It 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 {ntpqman} utility
@@ -74,53 +66,28 @@ program.
 
 When {ntpdman} is first started, it reads the key file specified
 in the keys configuration command and installs the keys in the key cache.
-However, individual keys must be activated with the trusted command before
+However, individual keys must be activated with the +trustedkey+ command before
 use. This allows, for instance, the installation of possibly several
 batches of keys and then activating or deactivating each batch remotely
 using {ntpqman}. This also provides a revocation capability
-that can be used if a key becomes compromised. The controlkey command
+that can be used if a key becomes compromised. The +controlkey+ command
 selects the key used as the password for the {ntpqman} utility.
 
 [[operation]]
 == Operation ==
 
-A specific combination of authentication scheme (none, symmetric key)
-and identity scheme is called a cryptotype, although not all
-combinations are compatible. There may be management configurations
-where the clients, servers and peers may not all support the same
-cryptotypes. A secure NTP subnet can be configured in many ways while
-keeping in mind the principles explained above and in this
-section. Note however that some cryptotype combinations may
-successfully interoperate with each other, but may not represent good
-security practice.
-
-The cryptotype of an association is determined at the time of
-mobilization, either at configuration time or some time later when a
-message of appropriate cryptotype arrives. When mobilized by a +server+
-or +peer+ configuration command and no +key+ subcommands
-are present, the association is not authenticated; if the +key+
-subcommand is present, the association is authenticated using the
-symmetric key ID specified.
-
-Following the principle that time is a public value, a server responds
-to any client packet that matches its cryptotype capabilities. Thus, a
-server receiving an unauthenticated packet will respond with an
+A server receiving an unauthenticated packet will respond with an
 unauthenticated packet, while the same server receiving a packet of a
 cryptotype it supports will respond with packets of that cryptotype.
-However, unconfigured broadcast or manycast client associations or
-symmetric passive associations will not be mobilized unless the server
-supports a cryptotype compatible with the first packet received. By
-default, unauthenticated associations will not be mobilized unless
-overridden in a decidedly dangerous way.
-
-Some examples may help to reduce confusion. Client Alice has no specific
-cryptotype selected. Server Bob has a symmetric key file.
+
+Some examples may help to reduce confusion. Client Alice has no
+keys fuke. Server Bob has a symmetric key file.
 Alice's unauthenticated messages arrive at Bob,
 who replies with unauthenticated messages. Cathy has a copy of Bob's
 symmetric key file and has selected key ID 4 in messages to Bob. Bob
 verifies the message with his key ID 4. If it's the same key and the
 message is verified, Bob sends Cathy a reply authenticated with that
-key. If verification fails, Bob sends Cathy a thing called a crypto-NAK,
+key. If verification fails, Bob sends Cathy a crypto-NAK,
 which tells her something broke. She can see the evidence using the
 {ntpqman} program.
 
@@ -129,37 +96,26 @@ the same time, as long as he has compatible authentication and identity
 credentials. Now, Bob can act just like the girls in his own choice of
 servers; he can run multiple configured associations with multiple
 different servers (or the same server, although that might not be
-useful). But, wise security policy might preclude some cryptotype
-combinations; for instance, running an identity scheme with one server
+useful). But, wise security policy might preclude some combinations;
+for instance, running authentication with one server
 and no authentication with another might not be wise.
 
 [[keys]]
 == Key Management ==
 
-The cryptographic values used for authentication are incorporated
-as a set of files generated by the {ntpkeygenman} utility
-program, including symmetric key and leapseconds files.
+Shared keys used for authentication are incorporated
+keys files generated by the {ntpkeygenman} utility
+program.
 
 [[algorithms]]
 == Algorithms ==
 
 The NTP standards include symmetric (private-key) authentication using
-the RSA Message Digest 5 (MD5) algorithm, commonly called
-keyed-MD5. This algorithm computes a message digest or one-way hash
+any message digest algorithm supported by the OpenSSL package
+This algorithm computes a message digest or one-way hash
 which can be used to verify the client has the same message digest as
 the server.
 
-All message digest algorithms included in the OpenSSL library may
-be used, including MD5 and SHA1. However, if conformance to FIPS 140-2
-is required, only a limited subset of these algorithms can be used.
-
-Note that according to US law, NTP binaries including OpenSSL library
-components, including the OpenSSL library itself, cannot be exported
-outside the US without a license from the US Department of Commerce.
-(However, these restrictions have been considerably relaxed since 1996.)
-Builders outside the US are advised to obtain the OpenSSL library
-directly from OpenSSL, which is outside the US, and build outside the
-US.
 
 Authentication is configured separately for each association using the
 +key+ option of the +server+ configuration command, as
@@ -187,44 +143,35 @@ as MD5 or SHA1. 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
-_crypto-NAK_. Since the crypto-NAK is protected by the loopback test, an
-intruder cannot disrupt the protocol by sending a bogus crypto-NAK.
+the key concatenated with the NTP packet header fields and the key ID.
+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 _crypto-NAK_. Since the crypto-NAK is protected
+by the loopback test, an intruder cannot disrupt the protocol by sending
+a bogus crypto-NAK.
+
+MD5 digests are 16 bytes.  SHA1 digests are 20 bytes.
+Longer digests don't work yet.  2018-Jan-07
+FIXME: long digests
 
 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 +ntpq+
-utility program. Ordinarily, the +ntp.keys+ file is generated by the
-+ntpkeygen+ program, but it can be constructed and edited using an
-ordinary text editor.
-
-Each line of the keys file consists of three fields: a key ID in the
-range 1 to 65,534, inclusive, a key type, and a message digest key
-consisting of a printable ASCII string less than 40 characters, or a
-40-character hex digit string. 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.
+utility program.  See {ntpkeysman} for details.
 
 .Figure 1. Typical Symmetric Key File
 image:pic/sx5.gif["Typical Symmetric Key File",align="center"]
 
 
-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
+Figure 1 shows a typical keys file. 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 +2late4Me+ for key ID 10. Note that two or more keys files can be
+IDs in the range 11-20, the key is a 40-character hex digit string.
+Any line can be edited to change any field or new lines can
+be added. Note that two or more keys files can be
 combined in any order as long as the key IDs are distinct.
 
 When +ntpd+ is started, it reads the keys file specified by the +keys+
@@ -240,13 +187,21 @@ for the +ntpq+ utility.
 
 In addition to the above means, +ntpd+ 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
+contributed by the Samba Team and is still in development. It requires the
++--enable-mssntp+ option to +waf configure+.  At run time, it is enabled
 using the +mssntp+ flag of the +restrict+ command described on the
-link:accopt.html#restrict[Access Control Options] page. [red]#Note: Potential
+link:accopt.html#restrict[Access Control Options] page. *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.
+with no clients other than MS-SNTP.*
+
+
+== History ==
+
+Old versions of NTP supported Autokey. It is described in RFC 5906.
+It used key ids greater than 64K.
+
 
 '''''
 


=====================================
docs/debug.txt
=====================================
--- a/docs/debug.txt
+++ b/docs/debug.txt
@@ -202,10 +202,10 @@ usually less than a few milliseconds.
 Reliable source authentication requires the use of symmetric key
 link:authopt.html[Authentication Options] page. In symmetric key
 cryptography servers and clients share session keys contained in a
-secret key file In public key cryptography, which requires the OpenSSL
-software library, the server has a private key, never shared, and a
-public key with unrestricted distribution. The cryptographic media
-required are produced by the link:ntpkeygen.html[+ntpkeygen+] program.
+secret key file. In public key cryptography, the server has a
+private key, never shared, and a public key with unrestricted
+distribution. Symmetric kays can be produced by
+the link:ntpkeygen.html[+ntpkeygen+] program.
 
 Problems with symmetric key authentication are usually due to mismatched
 keys or improper use of the +trustedkey+ command. A simple way to check


=====================================
docs/includes/access-commands.txt
=====================================
--- a/docs/includes/access-commands.txt
+++ b/docs/includes/access-commands.txt
@@ -78,10 +78,11 @@
   +nopeer+;;
     Deny packets which would result in mobilizing a new association.
     This includes symmetric active packets when a
-    configured association does not exist. It also includes _pool_
-    associations, so if you want to use servers from a +pool+ directive
-    and also want to use +nopeer+ by default, you'll want a +restrict
-    source ...+ line as well that does 'not' include the +nopeer+ directive.
+    configured association does not exist.  That used to happen
+    when the remote client used the +peer+ command in its config file.
+    We don't support that mode.
+    It used to include _pool_ servers but they now poke a hole in any
+    restrictions.
   +noserve+;;
     Deny all packets except {ntpqman} and queries.
   +notrust+;;


=====================================
docs/includes/ntp-conf-body.txt
=====================================
--- a/docs/includes/ntp-conf-body.txt
+++ b/docs/includes/ntp-conf-body.txt
@@ -224,7 +224,7 @@ include::../includes/misc-options.txt[]
 `/etc/ntp.conf`::
   the default name of the configuration file
 `ntp.keys`::
-  private MD5 keys
+  private keys
 
 One of the following exit values will be returned:
 


=====================================
docs/includes/ntpd-body.txt
=====================================
--- a/docs/includes/ntpd-body.txt
+++ b/docs/includes/ntpd-body.txt
@@ -547,10 +547,10 @@ On most systems, you can send SIGHUP to +ntpd+ with
   # sigkill -HUP ntpd
 -----
 
-If built with debugging enabled (waf configured without +--disable-debug+)
+If built with debugging enabled (waf configured with +--enable-debug+)
 SIGUSR1 will increase the debug level by 1 and
 SIGUSR2 will decrease it by 1.  This may be helpful if you are
-running without +-n+, either just to see the logging on your screen
+running with +-n+, either just to see the logging on your screen
 or with gdb.
 
 [[bugs]]


=====================================
docs/includes/ntpkeygen-body.txt
=====================================
--- a/docs/includes/ntpkeygen-body.txt
+++ b/docs/includes/ntpkeygen-body.txt
@@ -10,17 +10,17 @@
 [[descrip]]
 == Description ==
 
-This program generates the keys used in NTP's symmetric key
-cryptography.
+This program generates a file containing keys that can be used
+in NTP's symmetric key cryptography.
 
 The program produces a file containing ten pseudo-random printable
-ASCII strings suitable for the MD5 message digest algorithm included
-in the distribution.  It also produces an additional ten hex-encoded
-random bit strings suitable for the SHA-1 and other message digest
-algorithms. The message digest keys file must be distributed and
-stored using secure means beyond the scope of NTP itself. Besides
-the keys used for ordinary NTP associations, additional keys can be
-defined as passwords for the link:ntpq.html[+ntpq+] utility program.
+ASCII strings suitable for the MD5 message digest algorithm.
+It also produces an additional ten hex-encoded random bit strings
+suitable for the SHA1 and other message digest algorithms.
+
+The keys file must be distributed and stored using secure means
+beyond the scope of NTP itself. The keys can also be used as
+passwords for the link:ntpq.html[+ntpq+] utility program.
 
 [[cmd]]
 == Command Line Options ==
@@ -32,14 +32,10 @@ defined as passwords for the link:ntpq.html[+ntpq+] utility program.
 [[run]]
 == Running the program ==
 
-The safest way to run the +ntpkeygen+ program is logged in directly as
-root. The recommended procedure is change to the keys directory, usually
-+{prefixdir}/etc+, then run the program.
-
-Installing the keys as root might not work in NFS-mounted shared file
-systems, as NFS clients may not be able to write to the shared keys
-directory, even as root. In this case, NFS clients can specify the files
-in another directory such as +/etc+ using the _keys_ command.
+The simplest way to run the +ntpkeygen+ program is logged in directly as
+root. The recommended procedure is to change to the keys directory,
+usually +/etc/ntp/+, then run the program.  Then chown the output
+file to ntp:ntp.  It should be mode 400.
 
 WARNING: +ntpkeygen+ uses the system randomness source.  On a POSIX
 system this is usually /dev/urandom.  Immediately after a reboot, on any
@@ -53,19 +49,10 @@ run this program on an active host with a lot of available entropy.
 File names begin with the prefix _ntpkey_ and end with the postfix
 _hostname.filestamp_, where _hostname_ is the owner name, usually the
 string returned by the Unix gethostname() routine, and _filestamp_ is
-the NTP seconds when the file was generated, in decimal digits. This
-both guarantees uniqueness and simplifies maintenance procedures, since
-all files can be quickly removed by a _rm_ _ntpkey*_ command or all
-files generated at a specific time can be removed by a _rm_ _*filestamp_
-command.
-
-All files are installed by default in the keys directory
-+{prefixdir}/etc+, which is normally in a shared filesystem in
-NFS-mounted networks. The actual location of the keys directory and each
-file can be overridden by configuration commands, but this is not
-recommended. Normally, the files for each host are generated by that
-host and used only by that host, although exceptions exist as noted
-later on this page.
+the NTP seconds when the file was generated, in decimal digits.
+
++ntpkeygen+ also makes a soft link from +ntp.keys+ to the generated
+file.  +ntp.keys+ is the normal file used in +ntp.conf+.
 
 [[random]]
 == Random Seed File ==
@@ -87,15 +74,14 @@ https://docs.python.org/library/os.html#os.urandom[Python 3.5+].
 [[crypto]]
 == Cryptographic Data Files ==
 
-The +ntpkeygen+ program generates a file of symmetric keys
-_ntpkey_MD5key_hostname.filestamp_. Since the file contains private
-shared keys, it should be visible only to root and distributed by secure
-means to other subnet hosts. The NTP daemon loads the file _ntp.keys_,
-so +ntpkeygen+ installs a soft link from this name to the generated
-file. Subsequently, similar soft links must be installed by manual or
-automated means on the other subnet hosts. This file is needed to
-authenticate some remote configuration commands used by the {ntpqman}
-utility.
+Since the file contains private shared keys, it should be visible
+only to root or ntp.
+
+In order to use a shared key, the line to be used must also be setup
+on the target server.
+
+This file is also used to authenticate remote configuration
+commands used by the {ntpqman} utility.
 
 Comments may appear in the file, and are preceded with the +#+
 character.  
@@ -107,13 +93,8 @@ format:
 |====================================================================
 |Field	| Meaning
 |keyno	| Positive integer in the range 1-65,535
-|type	| MD5 or SHA-1, type of key
-|key	| the actual key, printable ASCII
+|type	| MD5 or SHA1, type of key
+|key	| the actual key, printable ASCII or hex
 |====================================================================
 
-// Recheck.  The code does not check for ' '.  -- Sanjeev 20161203
-// For type MD5, each character is chosen from the 93 printable
-// characters in the range 0x21 through 0x7f excluding space and the ‘#’
-// character.
-
 // end


=====================================
docs/includes/ntpq-body.txt
=====================================
--- a/docs/includes/ntpq-body.txt
+++ b/docs/includes/ntpq-body.txt
@@ -168,14 +168,13 @@ following.
 
 +keyid+ 'keyid'::
   This command specifies the key number to be used to authenticate
-  configuration requests. This must correspond to a key ID configured in
-  +ntp.conf+ for this purpose.
+  configuration requests. This must correspond to a key ID configured
+  with the +controlkey+ command in the server's +ntp.conf+
 
 +keytype+::
   Specify the digest algorithm to use for authenticated requests, with
-  default +MD5+. The digest can be
-  any message digest algorithm supported by the OpenSSL library. The current
-  selections are: +MD2+, +MD4+, +MD5+, +MDC2+, +RIPEMD160+ and +SHA1+.
+  default +MD5+. The keytype must match what the server is expecting
+  for the the specified key ID.
 
 +ntpversion 1 | 2 | 3 | 4+::
   Sets the NTP version number which +ntpq+ claims in packets. Defaults
@@ -184,8 +183,9 @@ following.
 
 +passwd+::
   This command prompts for a password to authenticate requests. The
-  password must correspond to the key ID configured in +ntp.conf+ for
-  this purpose.
+  password must match what the server is expecting.  Passwords longer
+  than 20 bytes are assumed to be hex encoding.
+FIXME: Actually fix the code.
 
 +quit+::
   Exit +ntpq+.


=====================================
docs/mode6.txt
=====================================
--- a/docs/mode6.txt
+++ b/docs/mode6.txt
@@ -512,9 +512,9 @@ The contents of the MAC trailer consists of:
 First, the password entered to use the signing key, then the request
 header fields, then the payload.
 
-The cryptographic hash is normally 16 octets of MD5 hash, but if ntpd
-is built with OpenSSL support it is possible to use and generate
-20-octet-long SHA1 keys as well.
+The cryptographic hash is 16 octets for MD5 and 20 octets for SHA1.
+Longer digests don't work yet.  2018-Jan-06
+FIXME:  long digests
 
 == Compatibility Notes ==
 


=====================================
docs/msyslog.txt
=====================================
--- a/docs/msyslog.txt
+++ b/docs/msyslog.txt
@@ -101,65 +101,6 @@ meaning should be clear from context.
 +kernel time sync status ?+::
   For information only. See the codes in the +timex.h+ file.
 
-== Cryptographic Module ==
-
-=== LOG_ERR ===
-
-+cert_parse ?+::
-+cert_sign ?+::
-+crypto_cert ?+::
-+crypto_encrypt ?+::
-+crypto_gq ?+::
-+crypto_iff ?+::
-+crypto_key ?+::
-+crypto_mv ?+::
-+crypto_setup ?+::
-+make_keys ?+::
-  Usually fatal errors. These messages display error codes returned from
-  the OpenSSL library. See the OpenSSL documentation for explanation.
-
-+crypto_setup: certificate ? is trusted, but not self signed.+::
-+crypto_setup: certificate ? not for this host+::
-+crypto_setup: certificate file ? not found or corrupt+::
-+crypto_setup: host key file ? not found or corrupt+::
-+crypto_setup: host key is not RSA key type+::
-+crypto_setup: random seed file ? not found+::
-+crypto_setup: random seed file not specified+::
-  Fatal errors. These messages show problems during the initialization
-  procedure.
-
-=== LOG_INFO ===
-
-+cert_parse: expired ?+::
-+cert_parse: invalid issuer ?+::
-+cert_parse: invalid signature ?+::
-+cert_parse: invalid subject ?+::
-  There is a problem with a certificate. Operation cannot proceed until
-  the problem is fixed. If the certificate is local, it can be
-  regenerated using the ntpkeygen program. If it is held somewhere
-  else, it must be fixed by the holder.
-
-+crypto_?: defective key+::
-+crypto_?: invalid filestamp+::
-+crypto_?: missing challenge+::
-+crypto_?: scheme unavailable+::
-  There is a problem with the identity scheme. Operation cannot proceed
-  until the problem is fixed. Usually errors are due to
-  misconfiguration or an orphan association. If the latter, +ntpd+ will
-  usually time out and recover by itself.
-+crypto_cert: wrong PEM type ?+::
-  The certificate does not have MIME type +CERTIFICATE+. You are
-  probably using the wrong type from OpenSSL or an external certificate
-  authority.
-+crypto_ident: no compatible identity scheme found+::
-  Configuration error. The server and client identity schemes are
-  incompatible.
-+crypto_tai: kernel TAI update failed+::
-  The kernel does not support this function. You may need a new kernel
-  or patch.
-+crypto_tai: leapseconds file ? error ?+::
-  The leapseconds file is corrupt. Obtain the latest file from
-  +time.nist.gov+.
 
 '''''
 


=====================================
docs/ntpkeygen.txt
=====================================
--- a/docs/ntpkeygen.txt
+++ b/docs/ntpkeygen.txt
@@ -37,18 +37,17 @@ image:pic/sx5.gif[]
 Figure 1. Typical Symmetric Key File
 
 Figure 1 shows a typical symmetric keys file used by the reference
-implementation. Each line of the file contains three fields, first an
-integer between 1 and 65534, inclusive, representing the key identifier
-used in the `server` and `peer` configuration commands. Next is the key
-type for the message digest algorithm, which can be any
-message digest algorithm supported by the OpenSSL library. However, if
-compatibility with FIPS 140-2 is required, the key type must be
-`SHA1`. The key type can be changed using an ASCII text editor.
-
-An MD5 key consists of a printable ASCII string less than or equal to 16
-characters and terminated by whitespace or a # character. An OpenSSL key
-consists of a hex-encoded ASCII string of 40 characters, which is
-truncated as necessary.
+implementation. Each line of the file contains three fields, first
+keyno an integer between 1 and 65534, inclusive, representing the
+key identifier used in the `server` configuration commands. Next
+is the key type for the message digest algorithm, which can be any
+message digest algorithm supported by the OpenSSL library.
+
+For details, see {ntpkeysman}.
+
++ntpkeygen+ just makes a sample file with good random keys.  You can
+edit it by hand to change the keyno or keytype and/or copy lines to
+other key files.
 
 '''''
 


=====================================
libntp/authreadkeys.c
=====================================
--- a/libntp/authreadkeys.c
+++ b/libntp/authreadkeys.c
@@ -148,16 +148,18 @@ msyslog(LOG_ERR, "AUTH: authreadkeys: reading %s", file);
 			*pch = (char)toupper((unsigned char)*pch);
 
 		keytype = OBJ_sn2nid(upcased);
-		if (!keytype && 'm' == tolower((unsigned char)token[0]))
+		if ((NID_undef == keytype) && ('M' == upcased[0]))
 			keytype = NID_md5;
-		if (keytype == 0) {
+		if (NID_undef == keytype) {
 			msyslog(LOG_ERR,
-			    "AUTH: authreadkeys: invalid type for key %u", keyno);
+			    "AUTH: authreadkeys: invalid type for key %u, %s",
+				keyno, token);
 			continue;
 		}
 		if (EVP_get_digestbynid(keytype) == NULL) {
 			msyslog(LOG_ERR,
-			    "AUTH: authreadkeys: no algorithm for key %u", keyno);
+			    "AUTH: authreadkeys: no algorithm for key %u, %s",
+				keyno, token);
 			continue;
 		}
 


=====================================
ntpclients/ntpkeygen.py
=====================================
--- a/ntpclients/ntpkeygen.py
+++ b/ntpclients/ntpkeygen.py
@@ -42,12 +42,12 @@ def gen_md5(id, groupname):
                     if r != ord('#'):
                         break
                 md5key += chr(r)
-            wp.write("%2d MD5 %s  # MD5 key\n" % (i, md5key))
+            wp.write("%2d MD5 %s\n" % (i, md5key))
         for i in range(1, MD5KEYS+1):
             sha1key = ""
             for j in range(MD5SIZE):
                 sha1key += "%02x" % randomizer.randint(0x00, 0xff)
-            wp.write("%2d SHA1 %s  # SHA1 key\n" % (i + MD5KEYS, sha1key))
+            wp.write("%2d SHA1 %s\n" % (i + MD5KEYS, sha1key))
 
 
 #


=====================================
ntpd/ntp.keys-man.txt
=====================================
--- a/ntpd/ntp.keys-man.txt
+++ b/ntpd/ntp.keys-man.txt
@@ -2,7 +2,7 @@
 :doctype: manpage
 
 == NAME ==
-ntp.keys - NTP symmetric key file format configuration file
+ntp.keys - NTP symmetric key file format
 
 == DESCRIPTION ==
 
@@ -27,33 +27,59 @@ where `keyno` is a positive integer (between 1 and 65534),
 `type` is the message digest algorithm, and
 `key` is the key itself.
 
-The `key` may be given in a format controlled by the `type` field. The
-`type` MD5 is always supported.  If ntpd was built with the OpenSSL
-library then any digest library supported by that library may be
-specified. However, if compliance with FIPS 140-2 is required the
-`type` must be 'SHA1'.
-
-What follows are some key types, and corresponding formats:
-
-_MD5_::
-  The key is 1 to 16 printable characters terminated by an EOL,
-  whitespace, or a _#_ (which is the "start of comment" character).
-_SHA1_; _RMD160_::
-  The key is a hex-encoded ASCII string of 40 characters, which is
-  truncated as necessary.
-+
+The file does not need to be sorted by `keyno`.
+
+`type` can be any digest type supported by your OpenSSL package.
+You can probably get a list from `man 1 dgst` or `openssl help`.
+(As of Jan 2018, they lie.  Be sure to try it.  {ntpdman} will
+print an error on startup if a slected type isn't supported.)
+
+The following types are widely supported:
+-----
+  md5, sha1, ripemd160, sha224, sha256, sha384, sha512
+-----
+
+FIPS 140-2, FIPS 180-4, and/or FIPS 202 may restrict your choices.
+If it matters to you, check with your lawyer.  (Let us know if you
+find a good reference.)
+
+The `key` may be printable ASCII excluding "#" or hex encoded.
+Keys longer than 20 characters are assumed to be hex.  The max
+length of a (possibly de-hexified) key is 32 bytes.  If you
+want to use an ASCII key longer than 20 bytes, you must hexify it.
+
 Note that the keys used by the {ntpqman} programs are
-checked against passwords requested by the programs and entered by
-hand, so it is generally appropriate to specify these keys in ASCII
-format.
+checked against passwords entered by hand, so it is generally
+appropriate to specify these keys in ASCII format.  Or you can
+cut-paste a hex string from your password manager.
+
+== USAGE ==
+
+In order to use symmetric keys, the client side configuration file needs:
+-----
+  keys <path-to-client-keys-file>
+  trustedkey <keyno>
+  server ... key <keyno>
+-----
+The server side needs:
+-----
+  keys <path-to-server-keys-file>
+  trustedkey <keyno>
+-----
+
+Note that the client and server key files must both contain identical
+copies of the line specified by keyno.
+
 
 == FILES ==
 
 `/etc/ntp.keys`::
-  a common location of the configuration file
+  is a common location for the keys file
+
+Reminder: You have to keep it secret.
 
 == SEE ALSO ==
 
-{ntpdconfman}, {ntpdman}, {ntpqman}, {ntpdigman}.
+{ntpdconfman}, {ntpdman}, {ntpqman}, {ntpkeygenman}, {ntpdigman}.
 
 // end


=====================================
wscript
=====================================
--- a/wscript
+++ b/wscript
@@ -899,6 +899,18 @@ int main(int argc, char **argv) {
     else:
         ctx.define("BUILD_EPOCH", int(time.time()), comment="Using default")
 
+    # before write_config()
+    droproot_type = ""
+    if ctx.is_defined("HAVE_LINUX_CAPABILITY"):
+        droproot_type = "Linux"
+    elif ctx.is_defined("HAVE_SOLARIS_PRIVS"):
+        droproot_type = "Solaris"
+    elif ctx.is_defined("HAVE_SYS_CLOCKCTL_H"):
+        droproot_type = "NetBSD"
+    else:
+        droproot_type = "None"
+
+    # write_config() removes symbols
     ctx.start_msg("Writing configuration header:")
     ctx.write_config_header("config.h")
     ctx.end_msg("config.h", "PINK")
@@ -915,15 +927,6 @@ int main(int argc, char **argv) {
     msg_setting("LDFLAGS", " ".join(ctx.env.LDFLAGS))
     msg_setting("LINKFLAGS_NTPD", " ".join(ctx.env.LINKFLAGS_NTPD))
     msg_setting("PREFIX", ctx.env.PREFIX)
-    droproot_type = ""
-    if ctx.is_defined("HAVE_LINUX_CAPABILITY"):
-        droproot_type = "Linux"
-    elif ctx.is_defined("HAVE_SOLARIS_PRIVS"):
-        droproot_type = "Solaris"
-    elif ctx.is_defined("HAVE_SYS_CLOCKCTL_H"):
-        droproot_type = "NetBSD"
-    else:
-        droproot_type = "None"
     msg_setting("Droproot Support", droproot_type)
     msg_setting("Debug Support", yesno(ctx.options.enable_debug))
     msg_setting("Refclocks", ", ".join(ctx.env.REFCLOCK_LIST))



View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/fa5b74ae5cc92abde0fc0bef7c3a7c10b3e1da64...e349aa133ab5fc511df9bc5c09a55a78ebfbb1e1

---
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/fa5b74ae5cc92abde0fc0bef7c3a7c10b3e1da64...e349aa133ab5fc511df9bc5c09a55a78ebfbb1e1
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/vc/attachments/20180108/469dc855/attachment.html>


More information about the vc mailing list