1 /* -*- Mode: Text -*- */
3 autogen definitions options;
7 #include autogen-version.def
9 prog-name = "ntp-keygen";
10 prog-title = "Create a NTP host key";
13 include = '#include <stdlib.h>';
21 arg-range = '256->2048';
23 descrip = "identity modulus bits";
25 The number of bits in the identity modulus. The default is 256.
35 descrip = "certificate scheme";
38 RSA-MD2, RSA-MD5, RSA-SHA, RSA-SHA1, RSA-MDC2, RSA-RIPEMD160,
41 Select the certificate message digest/signature encryption scheme.
42 Note that RSA schemes must be used with a RSA sign key and DSA
43 schemes must be used with a DSA sign key. The default without
44 this option is RSA-MD5.
54 descrip = "privatekey cipher";
56 Select the cipher which is used to encrypt the files containing
57 private keys. The default is three-key triple DES in CBC mode,
58 equivalent to "@code{-C des-ede3-cbc". The openssl tool lists ciphers
59 available in "@code{openssl -h}" output.
63 #include debug-opt.def
69 descrip = "Write IFF or GQ identity keys";
71 Write the IFF or GQ client keys to the standard output. This is
72 intended for automatic key distribution by mail.
80 descrip = "Generate GQ parameters and keys";
82 Generate parameters and keys for the GQ identification scheme,
83 obsoleting any that may exist.
91 descrip = "generate RSA host key";
93 Generate new host keys, obsoleting any that may exist.
101 descrip = "generate IFF parameters";
103 Generate parameters for the IFF identification scheme, obsoleting
114 descrip = "set Autokey group name";
116 Set the optional Autokey group name to name. This is used in
117 the file name of IFF, GQ, and MV client parameters files. In
118 that role, the default is the host name if this option is not
119 provided. The group name, if specified using @code{-i/--ident} or
120 using @code{-s/--subject-name} following an '@code{@}' character,
121 is also a part of the self-signed host certificate's subject and
122 issuer names in the form @code{host@group} and should match the
123 '@code{crypto ident}' or '@code{server ident}' configuration in
124 @code{ntpd}'s configuration file.
134 descrip = "set certificate lifetime";
136 Set the certificate expiration to lifetime days from now.
143 descrip = "generate MD5 keys";
145 Generate MD5 keys, obsoleting any that may exist.
154 arg-range = '256->2048';
158 The number of bits in the prime modulus. The default is 512.
166 descrip = "generate PC private certificate";
168 Generate a private certificate. By default, the program generates
175 name = password; // was: pvt-passwd;
179 descrip = "local private password";
181 Local files containing private data are encrypted with the
182 DES-CBC algorithm and the specified password. The same password
183 must be specified to the local ntpd via the "crypto pw password"
184 configuration command. The default password is the local
191 name = export-passwd; // Was: get-pvt-passwd;
195 descrip = "export IFF or GQ group keys with password";
197 Export IFF or GQ identity group keys to the standard output,
198 encrypted with the DES-CBC algorithm and the specified password.
199 The same password must be specified to the remote ntpd via the
200 "crypto pw password" configuration command. See also the option
201 --id-key (-e) for unencrypted exports.
211 descrip = "generate sign key (RSA or DSA)";
213 Generate a new sign key of the designated type, obsoleting any
214 that may exist. By default, the program uses the host key as the
223 arg-name = host@group;
225 descrip = "set host and optionally group name";
227 Set the Autokey host name, and optionally, group name specified
228 following an '@code{@}' character. The host name is used in the file
229 name of generated host and signing certificates, without the
230 group name. The host name, and if provided, group name are used
231 in @code{host@group} form for the host certificate's subject and issuer
232 fields. Specifying '@code{-s @group}' is allowed, and results in
233 leaving the host name unchanged while appending @code{@group} to the
234 subject and issuer fields, as with @code{-i group}. The group name, or
235 if not provided, the host name are also used in the file names
236 of IFF, GQ, and MV client parameter files.
244 descrip = "trusted certificate (TC scheme)";
246 Generate a trusted certificate. By default, the program generates
247 a non-trusted certificate.
257 descrip = "generate <num> MV parameters";
259 Generate parameters and keys for the Mu-Varadharajan (MV)
260 identification scheme.
270 descrip = "update <num> MV keys";
273 /* explain: Additional information whenever the usage routine is invoked */
274 explain = <<- _END_EXPLAIN
278 ds-type = 'DESCRIPTION';
280 ds-text = <<- _END_PROG_MDOC_DESCRIP
281 This program generates cryptographic data files used by the NTPv4
282 authentication and identification schemes.
283 It generates MD5 key files used in symmetric key cryptography.
284 In addition, if the OpenSSL software library has been installed,
285 it generates keys, certificate and identity files used in public key
287 These files are used for cookie encryption,
288 digital signature and challenge/response identification algorithms
289 compatible with the Internet standard security infrastructure.
291 All files are in PEM-encoded printable ASCII format,
292 so they can be embedded as MIME attachments in mail to other sites
293 and certificate authorities.
294 By default, files are not encrypted.
296 When used to generate message digest keys, the program produces a file
297 containing ten pseudo-random printable ASCII strings suitable for the
298 MD5 message digest algorithm included in the distribution.
299 If the OpenSSL library is installed, it produces an additional ten
300 hex-encoded random bit strings suitable for the SHA1 and other message
302 The message digest keys file must be distributed and stored
303 using secure means beyond the scope of NTP itself.
304 Besides the keys used for ordinary NTP associations, additional keys
305 can be defined as passwords for the
311 The remaining generated files are compatible with other OpenSSL
312 applications and other Public Key Infrastructure (PKI) resources.
313 Certificates generated by this program are compatible with extant
314 industry practice, although some users might find the interpretation of
315 X509v3 extension fields somewhat liberal.
316 However, the identity keys are probably not compatible with anything
319 Some files used by this program are encrypted using a private password.
322 option specifies the password for local encrypted files and the
324 option the password for encrypted files sent to remote sites.
325 If no password is specified, the host name returned by the Unix
327 function, normally the DNS name of the host is used.
333 configuration command specifies the read
334 password for previously encrypted local files.
335 This must match the local password used by this program.
336 If not specified, the host name is used.
337 Thus, if files are generated by this program without password,
338 they can be read back by
340 without password but only on the same host.
342 Normally, encrypted files for each host are generated by that host and
343 used only by that host, although exceptions exist as noted later on
345 The symmetric keys file, normally called
347 is usually installed in
349 Other files and links are usually installed in
351 which is normally in a shared filesystem in
352 NFS-mounted networks and cannot be changed by shared clients.
353 The location of the keys directory can be changed by the
355 configuration command in such cases.
359 This program directs commentary and error messages to the standard
362 and remote files to the standard output stream
364 where they can be piped to other applications or redirected to files.
365 The names used for generated files and links all begin with the
368 and include the file type, generating host and filestamp,
370 .Dq Cryptographic Data Files
372 .Ss Running the Program
373 To test and gain experience with Autokey concepts, log in as root and
374 change to the keys directory, usually
376 When run for the first time, or if all files with names beginning with
378 have been removed, use the
380 command without arguments to generate a
381 default RSA host key and matching RSA-MD5 certificate with expiration
383 If run again without options, the program uses the
384 existing keys and parameters and generates only a new certificate with
385 new expiration date one year hence.
387 Run the command on as many hosts as necessary.
388 Designate one of them as the trusted host (TH) using
392 option and configure it to synchronize from reliable Internet servers.
393 Then configure the other hosts to synchronize to the TH directly or
395 A certificate trail is created when Autokey asks the immediately
396 ascendant host towards the TH to sign its certificate, which is then
397 provided to the immediately descendant host on request.
398 All group hosts should have acyclic certificate trails ending on the TH.
400 The host key is used to encrypt the cookie when required and so must be
402 By default, the host key is also the sign key used to encrypt
404 A different sign key can be assigned using the
406 option and this can be either RSA or DSA type.
407 By default, the signature
408 message digest type is MD5, but any combination of sign key type and
409 message digest type supported by the OpenSSL library can be specified
413 The rules say cryptographic media should be generated with proventic
414 filestamps, which means the host should already be synchronized before
416 This of course creates a chicken-and-egg problem
417 when the host is started for the first time.
418 Accordingly, the host time
419 should be set by some other means, such as eyeball-and-wristwatch, at
420 least so that the certificate lifetime is within the current year.
421 After that and when the host is synchronized to a proventic source, the
422 certificate should be re-generated.
424 Additional information on trusted groups and identity schemes is on the
425 .Dq Autokey Public-Key Authentication
432 configuration command
433 .Ic crypto pw Ar password
434 specifies the read password for previously encrypted files.
435 The daemon expires on the spot if the password is missing
437 For convenience, if a file has been previously encrypted,
438 the default read password is the name of the host running
440 If the previous write password is specified as the host name,
441 these files can be read by that host with no explicit password.
444 File names begin with the prefix
446 and end with the postfix
447 .Ar _hostname.filestamp ,
450 is the owner name, usually the string returned
451 by the Unix gethostname() routine, and
453 is the NTP seconds when the file was generated, in decimal digits.
454 This both guarantees uniqueness and simplifies maintenance
455 procedures, since all files can be quickly removed
458 command or all files generated
459 at a specific time can be removed by a
463 To further reduce the risk of misconfiguration,
464 the first two lines of a file contain the file name
465 and generation date and time as comments.
467 All files are installed by default in the keys directory
469 which is normally in a shared filesystem
470 in NFS-mounted networks.
471 The actual location of the keys directory
472 and each file can be overridden by configuration commands,
473 but this is not recommended.
474 Normally, the files for each host are generated by that host
475 and used only by that host, although exceptions exist
476 as noted later on this page.
478 Normally, files containing private values,
479 including the host key, sign key and identification parameters,
480 are permitted root read/write-only;
481 while others containing public values are permitted world readable.
482 Alternatively, files containing private values can be encrypted
483 and these files permitted world readable,
484 which simplifies maintenance in shared file systems.
485 Since uniqueness is insured by the hostname and
486 file name extensions, the files for a NFS server and
487 dependent clients can all be installed in the same shared directory.
489 The recommended practice is to keep the file name extensions
490 when installing a file and to install a soft link
491 from the generic names specified elsewhere on this page
492 to the generated files.
493 This allows new file generations to be activated simply
494 by changing the link.
495 If a link is present, ntpd follows it to the file name
496 to extract the filestamp.
497 If a link is not present,
499 extracts the filestamp from the file itself.
500 This allows clients to verify that the file and generation times
504 program uses the same timestamp extension for all files generated
505 at one time, so each generation is distinct and can be readily
506 recognized in monitoring data.
507 .Ss Running the program
508 The safest way to run the
510 program is logged in directly as root.
511 The recommended procedure is change to the keys directory,
514 then run the program.
515 When run for the first time,
518 files have been removed,
519 the program generates a RSA host key file and matching RSA-MD5 certificate file,
520 which is all that is necessary in many cases.
521 The program also generates soft links from the generic names
522 to the respective files.
523 If run again, the program uses the same host key file,
524 but generates a new certificate file and link.
526 The host key is used to encrypt the cookie when required and so must be RSA type.
527 By default, the host key is also the sign key used to encrypt signatures.
528 When necessary, a different sign key can be specified and this can be
529 either RSA or DSA type.
530 By default, the message digest type is MD5, but any combination
531 of sign key type and message digest type supported by the OpenSSL library
532 can be specified, including those using the MD2, MD5, SHA, SHA1, MDC2
533 and RIPE160 message digest algorithms.
534 However, the scheme specified in the certificate must be compatible
536 Certificates using any digest algorithm are compatible with RSA sign keys;
537 however, only SHA and SHA1 certificates are compatible with DSA sign keys.
539 Private/public key files and certificates are compatible with
540 other OpenSSL applications and very likely other libraries as well.
541 Certificates or certificate requests derived from them should be compatible
542 with extant industry practice, although some users might find
543 the interpretation of X509v3 extension fields somewhat liberal.
544 However, the identification parameter files, although encoded
545 as the other files, are probably not compatible with anything other than Autokey.
547 Running the program as other than root and using the Unix
550 to assume root may not work properly, since by default the OpenSSL library
551 looks for the random seed file
553 in the user home directory.
554 However, there should be only one
557 in the root directory, so it is convenient to define the
559 environment variable used by the OpenSSL library as the path to
562 Installing the keys as root might not work in NFS-mounted
563 shared file systems, as NFS clients may not be able to write
564 to the shared keys directory, even as root.
565 In this case, NFS clients can specify the files in another
571 There is no need for one client to read the keys and certificates
572 of other clients or servers, as these data are obtained automatically
573 by the Autokey protocol.
575 Ordinarily, cryptographic files are generated by the host that uses them,
576 but it is possible for a trusted agent (TA) to generate these files
577 for other hosts; however, in such cases files should always be encrypted.
578 The subject name and trusted name default to the hostname
579 of the host generating the files, but can be changed by command line options.
580 It is convenient to designate the owner name and trusted name
581 as the subject and issuer fields, respectively, of the certificate.
582 The owner name is also used for the host and sign key files,
583 while the trusted name is used for the identity files.
586 All files are installed by default in the keys directory
588 which is normally in a shared filesystem
589 in NFS-mounted networks.
590 The actual location of the keys directory
591 and each file can be overridden by configuration commands,
592 but this is not recommended.
593 Normally, the files for each host are generated by that host
594 and used only by that host, although exceptions exist
595 as noted later on this page.
597 Normally, files containing private values,
598 including the host key, sign key and identification parameters,
599 are permitted root read/write-only;
600 while others containing public values are permitted world readable.
601 Alternatively, files containing private values can be encrypted
602 and these files permitted world readable,
603 which simplifies maintenance in shared file systems.
604 Since uniqueness is insured by the hostname and
605 file name extensions, the files for a NFS server and
606 dependent clients can all be installed in the same shared directory.
608 The recommended practice is to keep the file name extensions
609 when installing a file and to install a soft link
610 from the generic names specified elsewhere on this page
611 to the generated files.
612 This allows new file generations to be activated simply
613 by changing the link.
614 If a link is present, ntpd follows it to the file name
615 to extract the filestamp.
616 If a link is not present,
618 extracts the filestamp from the file itself.
619 This allows clients to verify that the file and generation times
623 program uses the same timestamp extension for all files generated
624 at one time, so each generation is distinct and can be readily
625 recognized in monitoring data.
626 .Ss Running the program
627 The safest way to run the
629 program is logged in directly as root.
630 The recommended procedure is change to the keys directory,
633 then run the program.
634 When run for the first time,
637 files have been removed,
638 the program generates a RSA host key file and matching RSA-MD5 certificate file,
639 which is all that is necessary in many cases.
640 The program also generates soft links from the generic names
641 to the respective files.
642 If run again, the program uses the same host key file,
643 but generates a new certificate file and link.
645 The host key is used to encrypt the cookie when required and so must be RSA type.
646 By default, the host key is also the sign key used to encrypt signatures.
647 When necessary, a different sign key can be specified and this can be
648 either RSA or DSA type.
649 By default, the message digest type is MD5, but any combination
650 of sign key type and message digest type supported by the OpenSSL library
651 can be specified, including those using the MD2, MD5, SHA, SHA1, MDC2
652 and RIPE160 message digest algorithms.
653 However, the scheme specified in the certificate must be compatible
655 Certificates using any digest algorithm are compatible with RSA sign keys;
656 however, only SHA and SHA1 certificates are compatible with DSA sign keys.
658 Private/public key files and certificates are compatible with
659 other OpenSSL applications and very likely other libraries as well.
660 Certificates or certificate requests derived from them should be compatible
661 with extant industry practice, although some users might find
662 the interpretation of X509v3 extension fields somewhat liberal.
663 However, the identification parameter files, although encoded
664 as the other files, are probably not compatible with anything other than Autokey.
666 Running the program as other than root and using the Unix
669 to assume root may not work properly, since by default the OpenSSL library
670 looks for the random seed file
672 in the user home directory.
673 However, there should be only one
676 in the root directory, so it is convenient to define the
678 environment variable used by the OpenSSL library as the path to
681 Installing the keys as root might not work in NFS-mounted
682 shared file systems, as NFS clients may not be able to write
683 to the shared keys directory, even as root.
684 In this case, NFS clients can specify the files in another
690 There is no need for one client to read the keys and certificates
691 of other clients or servers, as these data are obtained automatically
692 by the Autokey protocol.
694 Ordinarily, cryptographic files are generated by the host that uses them,
695 but it is possible for a trusted agent (TA) to generate these files
696 for other hosts; however, in such cases files should always be encrypted.
697 The subject name and trusted name default to the hostname
698 of the host generating the files, but can be changed by command line options.
699 It is convenient to designate the owner name and trusted name
700 as the subject and issuer fields, respectively, of the certificate.
701 The owner name is also used for the host and sign key files,
702 while the trusted name is used for the identity files.
706 s Trusted Hosts and Groups
707 Each cryptographic configuration involves selection of a signature scheme
708 and identification scheme, called a cryptotype,
710 .Sx Authentication Options
713 The default cryptotype uses RSA encryption, MD5 message digest
714 and TC identification.
715 First, configure a NTP subnet including one or more low-stratum
716 trusted hosts from which all other hosts derive synchronization
717 directly or indirectly.
718 Trusted hosts have trusted certificates;
719 all other hosts have nontrusted certificates.
720 These hosts will automatically and dynamically build authoritative
721 certificate trails to one or more trusted hosts.
722 A trusted group is the set of all hosts that have, directly or indirectly,
723 a certificate trail ending at a trusted host.
724 The trail is defined by static configuration file entries
725 or dynamic means described on the
726 .Sx Automatic NTP Configuration Options
730 On each trusted host as root, change to the keys directory.
731 To insure a fresh fileset, remove all
737 to generate keys and a trusted certificate.
738 On all other hosts do the same, but leave off the
740 flag to generate keys and nontrusted certificates.
741 When complete, start the NTP daemons beginning at the lowest stratum
742 and working up the tree.
743 It may take some time for Autokey to instantiate the certificate trails
744 throughout the subnet, but setting up the environment is completely automatic.
746 If it is necessary to use a different sign key or different digest/signature
747 scheme than the default, run
757 The most often need to do this is when a DSA-signed certificate is used.
758 If it is necessary to use a different certificate scheme than the default,
768 is run again without these options, it generates a new certificate
769 using the same scheme and sign key.
771 After setting up the environment it is advisable to update certificates
772 from time to time, if only to extend the validity interval.
775 with the same flags as before to generate new certificates
777 However, if the host or sign key is changed,
782 is restarted, it loads any new files and restarts the protocol.
783 Other dependent hosts will continue as usual until signatures are refreshed,
784 at which time the protocol is restarted.
786 As mentioned on the Autonomous Authentication page,
787 the default TC identity scheme is vulnerable to a middleman attack.
788 However, there are more secure identity schemes available,
789 including PC, IFF, GQ and MV described on the
790 .Qq Identification Schemes
793 .Li http://www.eecis.udel.edu/%7emills/keygen.html ) .
794 These schemes are based on a TA, one or more trusted hosts
795 and some number of nontrusted hosts.
796 Trusted hosts prove identity using values provided by the TA,
797 while the remaining hosts prove identity using values provided
798 by a trusted host and certificate trails that end on that host.
799 The name of a trusted host is also the name of its sugroup
800 and also the subject and issuer name on its trusted certificate.
801 The TA is not necessarily a trusted host in this sense, but often is.
803 In some schemes there are separate keys for servers and clients.
804 A server can also be a client of another server,
805 but a client can never be a server for another client.
806 In general, trusted hosts and nontrusted hosts that operate
807 as both server and client have parameter files that contain
808 both server and client keys.
810 only as clients have key files that contain only client keys.
812 The PC scheme supports only one trusted host in the group.
813 On trusted host alice run
817 to generate the host key file
818 .Pa ntpkey_RSAkey_ Ns Ar alice.filestamp
819 and trusted private certificate file
820 .Pa ntpkey_RSA-MD5_cert_ Ns Ar alice.filestamp .
821 Copy both files to all group hosts;
822 they replace the files which would be generated in other schemes.
823 On each host bob install a soft link from the generic name
824 .Pa ntpkey_host_ Ns Ar bob
825 to the host key file and soft link
826 .Pa ntpkey_cert_ Ns Ar bob
827 to the private certificate file.
828 Note the generic links are on bob, but point to files generated
829 by trusted host alice.
830 In this scheme it is not possible to refresh
831 either the keys or certificates without copying them
832 to all other hosts in the group.
834 For the IFF scheme proceed as in the TC scheme to generate keys
835 and certificates for all group hosts, then for every trusted host in the group,
836 generate the IFF parameter file.
837 On trusted host alice run
842 to produce her parameter file
843 .Pa ntpkey_IFFpar_ Ns Ar alice.filestamp ,
844 which includes both server and client keys.
845 Copy this file to all group hosts that operate as both servers
846 and clients and install a soft link from the generic
847 .Pa ntpkey_iff_ Ns Ar alice
849 If there are no hosts restricted to operate only as clients,
850 there is nothing further to do.
851 As the IFF scheme is independent
852 of keys and certificates, these files can be refreshed as needed.
854 If a rogue client has the parameter file, it could masquerade
855 as a legitimate server and present a middleman threat.
856 To eliminate this threat, the client keys can be extracted
857 from the parameter file and distributed to all restricted clients.
858 After generating the parameter file, on alice run
861 and pipe the output to a file or mail program.
862 Copy or mail this file to all restricted clients.
863 On these clients install a soft link from the generic
864 .Pa ntpkey_iff_ Ns Ar alice
866 To further protect the integrity of the keys,
867 each file can be encrypted with a secret password.
869 For the GQ scheme proceed as in the TC scheme to generate keys
870 and certificates for all group hosts, then for every trusted host
871 in the group, generate the IFF parameter file.
872 On trusted host alice run
877 to produce her parameter file
878 .Pa ntpkey_GQpar_ Ns Ar alice.filestamp ,
879 which includes both server and client keys.
880 Copy this file to all group hosts and install a soft link
882 .Pa ntpkey_gq_ Ns Ar alice
884 In addition, on each host bob install a soft link
886 .Pa ntpkey_gq_ Ns Ar bob
888 As the GQ scheme updates the GQ parameters file and certificate
889 at the same time, keys and certificates can be regenerated as needed.
891 For the MV scheme, proceed as in the TC scheme to generate keys
892 and certificates for all group hosts.
893 For illustration assume trish is the TA, alice one of several trusted hosts
894 and bob one of her clients.
901 is the number of revokable keys (typically 5) to produce
903 .Pa ntpkeys_MVpar_ Ns Ar trish.filestamp
905 .Pa ntpkeys_MVkeyd_ Ns Ar trish.filestamp
908 is the key number (0 \&<
912 Copy the parameter file to alice and install a soft link
914 .Pa ntpkey_mv_ Ns Ar alice
916 Copy one of the client key files to alice for later distribution
918 It doesn't matter which client key file goes to alice,
919 since they all work the same way.
920 Alice copies the client key file to all of her cliens.
921 On client bob install a soft link from generic
922 .Pa ntpkey_mvkey_ Ns Ar bob
923 to the client key file.
924 As the MV scheme is independent of keys and certificates,
925 these files can be refreshed as needed.
926 .Ss Command Line Options
927 .Bl -tag -width indent
929 Select certificate message digest/signature encryption scheme.
932 can be one of the following:
933 . Cm RSA-MD2 , RSA-MD5 , RSA-SHA , RSA-SHA1 , RSA-MDC2 , RSA-RIPEMD160 , DSA-SHA ,
936 Note that RSA schemes must be used with a RSA sign key and DSA
937 schemes must be used with a DSA sign key.
938 The default without this option is
942 This option displays the cryptographic data produced in eye-friendly billboards.
944 Write the IFF client keys to the standard output.
945 This is intended for automatic key distribution by mail.
947 Generate parameters and keys for the GQ identification scheme,
948 obsoleting any that may exist.
950 Generate keys for the GQ identification scheme
951 using the existing GQ parameters.
952 If the GQ parameters do not yet exist, create them first.
954 Generate new host keys, obsoleting any that may exist.
956 Generate parameters for the IFF identification scheme,
957 obsoleting any that may exist.
959 Set the suject name to
961 This is used as the subject field in certificates
962 and in the file name for host and sign keys.
964 Generate MD5 keys, obsoleting any that may exist.
966 Generate a private certificate.
967 By default, the program generates public certificates.
969 Encrypt generated files containing private data with
971 and the DES-CBC algorithm.
973 Set the password for reading files to password.
974 .It Fl S Oo Cm RSA | DSA Oc
975 Generate a new sign key of the designated type,
976 obsoleting any that may exist.
977 By default, the program uses the host key as the sign key.
979 Set the issuer name to
981 This is used for the issuer field in certificates
982 and in the file name for identity files.
984 Generate a trusted certificate.
985 By default, the program generates a non-trusted certificate.
987 Generate parameters and keys for the Mu-Varadharajan (MV) identification scheme.
990 All cryptographically sound key generation schemes must have means
991 to randomize the entropy seed used to initialize
992 the internal pseudo-random number generator used
993 by the library routines.
994 The OpenSSL library uses a designated random seed file for this purpose.
995 The file must be available when starting the NTP daemon and
998 If a site supports OpenSSL or its companion OpenSSH,
999 it is very likely that means to do this are already available.
1001 It is important to understand that entropy must be evolved
1002 for each generation, for otherwise the random number sequence
1003 would be predictable.
1004 Various means dependent on external events, such as keystroke intervals,
1005 can be used to do this and some systems have built-in entropy sources.
1006 Suitable means are described in the OpenSSL software documentation,
1007 but are outside the scope of this page.
1009 The entropy seed used by the OpenSSL library is contained in a file,
1012 which must be available when starting the NTP daemon
1016 The NTP daemon will first look for the file
1017 using the path specified by the
1021 configuration command.
1022 If not specified in this way, or when starting the
1025 the OpenSSL library will look for the file using the path specified
1028 environment variable in the user home directory,
1029 whether root or some other user.
1032 environment variable is not present,
1033 the library will look for the
1035 file in the user home directory.
1036 If the file is not available or cannot be written,
1037 the daemon exits with a message to the system log and the program
1038 exits with a suitable error message.
1039 .Ss Cryptographic Data Files
1040 All other file formats begin with two lines.
1041 The first contains the file name, including the generated host name
1043 The second contains the datestamp in conventional Unix date format.
1044 Lines beginning with # are considered comments and ignored by the
1049 Cryptographic values are encoded first using ASN.1 rules,
1050 then encrypted if necessary, and finally written PEM-encoded
1051 printable ASCII format preceded and followed by MIME content identifier lines.
1053 The format of the symmetric keys file is somewhat different
1054 than the other files in the interest of backward compatibility.
1055 Since DES-CBC is deprecated in NTPv4, the only key format of interest
1056 is MD5 alphanumeric strings.
1057 Following hte heard the keys are
1058 entered one per line in the format
1059 .D1 Ar keyno type key
1062 is a positive integer in the range 1-65,535,
1064 is the string MD5 defining the key format and
1067 which is a printable ASCII string 16 characters or less in length.
1068 Each character is chosen from the 93 printable characters
1069 in the range 0x21 through 0x7f excluding space and the
1073 Note that the keys used by the
1076 .Xr ntpdc 1ntpdcmdoc
1078 are checked against passwords requested by the programs
1079 and entered by hand, so it is generally appropriate to specify these keys
1080 in human readable ASCII format.
1084 program generates a MD5 symmetric keys file
1085 .Pa ntpkey_MD5key_ Ns Ar hostname.filestamp .
1086 Since the file contains private shared keys,
1087 it should be visible only to root and distributed by secure means
1088 to other subnet hosts.
1089 The NTP daemon loads the file
1093 installs a soft link from this name to the generated file.
1094 Subsequently, similar soft links must be installed by manual
1095 or automated means on the other subnet hosts.
1096 While this file is not used with the Autokey Version 2 protocol,
1097 it is needed to authenticate some remote configuration commands
1101 .Xr ntpdc 1ntpdcmdoc
1103 _END_PROG_MDOC_DESCRIP;
1109 ds-text = <<- _END_MDOC_USAGE
1112 option specifies the write password and
1114 option the read password for previously encrypted files.
1117 program prompts for the password if it reads an encrypted file
1118 and the password is missing or incorrect.
1119 If an encrypted file is read successfully and
1120 no write password is specified, the read password is used
1121 as the write password by default.
1128 ds-text = <<- _END_MDOC_NOTES
1129 Portions of this document came from FreeBSD.
1136 ds-text = <<- _END_MDOC_BUGS
1137 It can take quite a while to generate some cryptographic values,
1138 from one to several minutes with modern architectures
1139 such as UltraSPARC and up to tens of minutes to an hour
1140 with older architectures such as SPARC IPC.
1142 Please report bugs to http://bugs.ntp.org .
projects / FreeBSD / releng / 10.2.git / blob