Sound Card Drivers
diff --git a/html/authopt.html b/html/authopt.html
index eed7c391c2..a193b25027 100644
--- a/html/authopt.html
+++ b/html/authopt.html
@@ -13,19 +13,18 @@
Authentication Options
from Alice's Adventures in Wonderland, Lewis Carroll
Our resident cryptographer; now you see him, now you don't.
- Last update: 19:21 UTC Tuesday, September 25, 2007
+ Last update: 15:56 UTC Wednesday, January 02, 2008
Related Links
-
+
Table of Contents
Authentication Support
- Authentication support allows the NTP client to verify that servers are in fact known and trusted and not intruders intending accidentally or intentionally to masquerade as a legitimate server. The NTPv3 specification RFC-1305 defines a scheme which provides cryptographic authentication of received NTP packets. Originally, this was done using the Data Encryption Standard (DES) algorithm operating in Cipher Block Chaining (CBC) mode, commonly called DES-CBC. Subsequently, this was replaced by 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.
- NTPv4 retains the NTPv3 scheme, properly described as symmetric key cryptography and, in addition, provides a new Autokey scheme based on public key cryptography. Public key cryptography is generally considered more secure than symmetric key cryptography, since the security is based on private and public values which are generated by each participant and where the private value is never revealed. With the exception of the group keys described later, all key distribution and management functions involve only public values, which considerably simplifies key distribution and storage. Public key management is based on X.509 certificates, which can be provided by commercial services or produced by utility programs in the OpenSSL software library or the ntp-keygen program in the NTP distribution.
- While the algorithms for symmetric key cryptography are included in the NTPv4 distribution, public key cryptography requires the OpenSSL software library to be installed before building the NTP distribution. This library is available from http://www.openssl.org and can be installed using the procedures outlined in the Building and Installing the Distribution page. Once installed, the configure and build process automatically detects the library and links the library routines required.
- Authentication is configured separately for each association using the key or autokey subcommand on the peer, server, broadcast and manycastclient configuration commands as described in the Configuration Options page. The authentication options described below specify the locations of the key files, which symmetric keys are trusted and other details needed by the optional Autokey protocol. The ntp-keygen program is used to generate the various key files, certificate files and identity files described below.
- Authentication is always enabled, although ineffective if not configured as described below. If an NTP packet includes a message authentication code (MAC), consisting of a key ID and the message digest, it is accepted only if the key ID matches a trusted key and the message digest is verified with this key. Furthermore, the Autokey scheme requires a preliminary protocol exchange to obtain the server certificate, verify its credentials and initialize the protocol.
- The auth flag controls whether new associations or remote configuration commands require cryptographic authentication. This flag can be set or reset by the enable and disable commands and also by remote configuration commands sent by a ntpdc program running on another machine. If this flag is enabled, which is the default, new broadcast/manycast client and symmetric passive associations and remote configuration commands must be cryptographically authenticated using either symmetric key or public key cryptography. If this flag is disabled, these operations are effective even if not cryptographic authenticated. It should be understood that operating with the auth flag disabled invites a significant vulnerability where a rogue hacker can masquerade as a legitimate server and seriously disrupt system timekeeping. It is important to note that this flag has no purpose other than to allow or disallow a new association in response to new broadcast and symmetric active messages and remote configuration commands and, in particular, the flag has no effect on the authentication process itself.
- The security model and protocol schemes for both symmetric key and public key cryptography are summarized below; further details are in the briefings, papers and reports at the NTP project page linked from www.ntp.org.
- Symmetric Key Cryptography
The original RFC-1305 specification allows any one of possibly 65,534 keys (excluding zero), 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 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 and ntpdc utility programs. Ordinarily, the ntp.keys file is generated by the ntp-keygen program, but it can be constructed by hand.When ntpd 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 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 ntpdc. This also provides a revocation capability that can be used if a key becomes compromised. The requestkey command selects the key used as the password for the ntpdc utility, while the controlkey command selects the key used as the password for the ntpq utility.
+ Authentication support allows the NTP client to verify that servers are in fact known and trusted and not intruders intending accidentally or intentionally to masquerade as a legitimate server. The NTPv3 specification RFC-1305 defines a scheme using the Data Encryption Standard (DES) algorithm, commonly called DES-CBC. Subsequently, this scheme was replaced by the RSA Message Digest 5 (MD5) algorithm, commonly called keyed-MD5. Either algorithm computes a message digest or one-way hash which can be used to verify the client has the same key as the server.
+ NTPv4 includes the NTPv3 scheme, properly described as symmetric key cryptography and, in addition a new scheme based on public key cryptography and called Autokey. Public key cryptography is generally considered more secure than symmetric key cryptography, since the security is based on private and public values which are generated by each participant and where the private value is never revealed. Autokey uses X.509 public certificates, which can be produced by commercial services, utility programs in the OpenSSL software library or a utility program in the NTP software distribution.
+ While the algorithms for symmetric key cryptography are included in the NTPv4 software distribution, Autokey cryptography requires the OpenSSL software library to be installed before building the NTP distribution. This library is available from http://www.openssl.org and can be installed using the procedures outlined in the Building and Installing the Distribution page. Once installed, the configure and build process automatically detects the library and links the library routines required.
+ Authentication is configured separately for each association separately using the key or autokey option on the peer, server, broadcast or manycastclient configuration commands, as described in the Server Options page, and the options described on this page. The ntp-keygen page describes the files required for the various authentication schemes. Further details are in the briefings, papers and reports at the NTP project page linked from www.ntp.org.
+ Symmetric Key Cryptography
+ The original RFC-1305 specification allows any one of possibly 65,534 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 and key ID to authenticate NTP packets. If an NTP packet includes a message authentication code (MAC), consisting of a key ID and message digest, it is accepted only if the key ID matches a trusted key and the message digest is verified with this key.
+ Keys and related information are specified in a keys file, usually called ntp.keys, 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 and ntpdc utility programs. Ordinarily, the ntp.keys file is generated by the ntp-keygen program, but it can be constructed using an ordinary text editor.
+ When ntpd is first started, it reads the key file specified by the keys configuration command and installs the keys in the key cache. 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 a key remotely using ntpdc. The requestkey command selects the key ID used as the password for the ntpdc utility, while the controlkey command selects the key ID used as the password for the ntpq utility.
Public Key Cryptography
- NTPv4 supports the Autokey security protocol, which is based on public key cryptography. The Autokey Version 2 protocol described on the Autokey Protocol page verifies packet integrity using MD5 message digests and verifies the source using digital signatures and any of several digest/signature schemes. Optional identity schemes described on the Identity Schemes page are based on cryptographic challenge/response exchanges. Using these schemes provides strong security against replay with or without modification, spoofing, masquerade and most forms of clogging attacks. These schemes are described along with an executive summary, current status, briefing slides and reading list on the Autonomous Authentication page.
+ NTPv4 supports the Autokey security protocol, which is based on public key cryptography. The Autokey Version 2 protocol described on the Autokey Protocol page verifies packet integrity using MD5 message digests and verifies the source using digital signatures and any of several digest/signature schemes. Optional identity schemes described on the Autokey Identity Schemes page are based on cryptographic challenge/response exchanges. Using these schemes provides strong security against replay with or without modification, spoofing, masquerade and most forms of clogging attacks. These schemes are described along with an executive summary, current status, briefing slides and reading list on the Autonomous Authentication page.
Autokey authenticates individual packets using cookies bound to the IP source and destination addresses. The cookies must have the same addresses at both the server and client. For this reason operation with network address translation schemes is not possible. This reflects the intended robust security model where government and corporate NTP servers are operated outside firewall perimeters.
- The specific cryptographic environment used by Autokey servers and clients is determined by a set of files and soft links generated by the ntp-keygen program. These define the required host key, required host certificate and optional sign key and identity keys. The certificate defines the Autokey host name and the selected cryptographic algorithms.
NTP Secure Groups
- NTP secure groups are used to define cryptographic compartments and security hierarchies. All hosts belonging to a named secure group share a secret group key which can be encrypted with individual passwords. Each group includes one or more trusted hosts (THs) operating at the root, or lowest stratum in the group. The other hosts are configured to provide an unbroken path, called a certificate trail, from each host, possibly via intermediate hosts, to one or more trusted hosts.
- When a host starts up, it recursively retrieves the certificates along the trail in order to verify group membership and avoid masquerade and middleman attacks. The trail concludes with the trusted certificate of a TH. The subject name on the trusted certificate defines the group name and name of the identity file used to confirm group membership.
- Secure groups can be configured as hierarchies where the THs of one group can be clients of one or more other groups operating at a lower stratum. In one scenario, groups RED and GREEN can be cryptographically distinct, but both be clients of group BLUE operating at a lower stratum. In another scenario, group CYAN can be a client of multiple groups YELLOW and MAGENTA, both operating at a lower stratum. The THs for each group have encrypted identity keys for that group as well as nonencrypted identity parameters for each of the lower stratum groups. The parameters can be obtained from the trusted agent (TA), usually one of the THs of the lower stratum group. There are many other scenarios, but all must be configured to include only acyclic certificate trails.
- In the IFF and GQ identity schemes the TA generates an encrypted keys file including private keys and public parameters needed to verify identity to a dependent client. The parameters file is a copy of this file with the private keys obscured. A client without the private keys can confirm identity with respect to a server but cannot prove identity to a dependent client.
- Naming Conventions
- It is important to note that Autokey does not use DNS to resolve names or addresses, since DNS can't be completely trusted until the name servers have synchronized clocks. The Autokey names for hosts and groups are used only to verify group membership and create group hierarchies.
- All THs share the same host name, which is also the group name. The host and group name is specified by the host and ident subcommands, respectively, of the crypto configuration command. All other hosts in the group have the same group name, but different host names. If the host name is not specified, the default host name is the string returned by the Unix gethostname() system call. If the group name is not specified, it defaults to the host name, in which case the group is nameless and, while certificate trails are used, identity schemes are not.
- File and link names are in the form ntpkey_key_name.fstamp, where key is the key or parameter type, name is the host or group name and fstamp is the filestamp (NTP seconds) when the file was created). By convention, key fields in generated file names include both upper and lower case alphanumeric characters, while key fields in generated link names include only lower case characters. The filestamp is not used in generated link names.
- The key type is a string defining the cryptographic function. Key types include public/private keys host and sign, certificate cert and several challenge/response key types. By convention, files used for challenges have a par subtype, as in the IFF challenge IFFpar, while files for responses have a key subtype, as in the GQ response GQkey.
+ NTP secure groups are used to define cryptographic compartments and security hierarchies. All hosts belonging to a secure group have the same group name but different host names. The string specified in the host option of the crypto command is the name of the host and in the name of the host key, sign key and certificate files. The string specified in the ident option of the crypto comand is the group name of all group hosts and in the name of the identity files. The file naming conventions are described on the ntp-keygen page.
+ Each group includes one or more trusted hosts (THs) operating at the root, or lowest stratum in the group. The group name is used in the subject and issuer fields of the TH trusted certificate. The host name is used in these fields for hosts other than THs.
+ All group hosts are configured to provide an unbroken path, called a certificate trail, from each host, possibly via intermediate hosts and ending at a TH. When a host starts up, it recursively retrieves the certificates along the trail in order to verify group membership and avoid masquerade and middleman attacks.
+ Secure groups can be configured as hierarchies where a TH of one group can be a client of one or more other groups operating at a lower stratum. In one scenario, groups RED and GREEN can be cryptographically distinct, but both be clients of group BLUE operating at a lower stratum. In another scenario, group CYAN can be a client of multiple groups YELLOW and MAGENTA, both operating at a lower stratum. There are many other scenarios, but all must be configured to include only acyclic certificate trails.
+ Identity Schemes and Cryptotypes
+ All configurations include a public/private host key pair and matching certificate. Absent an identity scheme, this is a Trusted Certificate (TC) scheme. There are three identity schemes, IFF, GQ and MV described on the Identity Schemes page. With these schemes all servers in the group have encrypted server identity keys, while clients have nonencrypted client identity parameters. The client parameters can be obtained from a trusted agent (TA), usually one of the THs of the lower stratum group. Further information on identity schemes is on the Autokey Identity Schemes page.
+ A specific combination of authentication and identity schemes is called a cryptotype, which applies to clients and servers separately. A group can be configured using more than one cryptotype combination, although not all combinations are interoperable. Note however that some cryptotype combinations may successfully interoperate with each other, but may not represent good security practice. The server and client cryptotypes are defined by the the following codes.
+
+ - NONE
+
- A client or server is type NONE if authentication is not available or not configured. Packets exchanged between client and server have no MAC.
+
- AUTH
+
- A client or server is type AUTH if the key option is specified with the server configuration command and the client and server keys are compatible. Packets exchanged between clients and servers have a MAC.
- PC
+
- A client or server is type PC if the autokey option is specified with the server configuration command and compatible host key and private certificate files are present. Packets exchanged between clients and servers have a MAC.
- TC
+
- A client or server is type TC if the autokey option is specified with the server configuration command and compatible host key and public certificate files are present. Packets exchanged between clients and servers have a MAC.
- IDENT
+
- A client or server is type IDENT if the autokey option is specified with the server configuration command and compatible host key, public certificate and identity scheme files are present. Packets exchanged between clients and servers have a MAC.
+ The compatible cryptotypes for clients and servers are listed in the following table.
+
+
+ | Client |
+ Server |
+
+
+ | NONE |
+ AUTH |
+ PC |
+ TC |
+ IDENT |
+
+
+ | NONE |
+ yes |
+ yes* |
+ yes* |
+ yes* |
+ yes* |
+
+
+ | AUTH |
+ no |
+ yes |
+ no |
+ no |
+ no |
+
+
+ | PC |
+ no |
+ no |
+ yes |
+ no |
+ no |
+
+
+ | TC |
+ no |
+ no |
+ no |
+ yes |
+ yes |
+
+
+ | IDENT |
+ no |
+ no |
+ no |
+ no |
+ yes |
+
+
+ * These combinations are not valid if the restriction list includes the notrust option.
Configuration
- Autokey has an intimidating number of options, most of which are not necessary in typical scenarios. The simplest scenario consists of a secure group with one or more THs at the same low stratum. On behalf of the group a designated TH operating as a trusted agent (TA) generates private host keys, a trusted, self-signed public certificate and private identity keys. These media are copied intact to all THs, most conveniently using a tar archive. This insures all certificate trails end with the same credentials.
- All other hosts generate private host keys and a nontrusted, self-signed public certificate. In the intended model, a host sends a mail message to the TA, provides password and out-of-band credentials, and requests the group identity media. For those hosts acting as severs with dependent clients, identity keys encrypted with the password are provided; for those hosts without dependent clients, only an unencrypted subset, called the identity parameters, are provided. Hosts with only the parameters can confirm identity with servers but cannot prove identity to dependent clients. Received files are installed in the keys directory named as the first line in the file, but all in lower case and without the filestamp field.
- All hosts in the group specify the group name by the ident subcommand of the crypto configuration command. Trusted hosts in addition specify the same host name in the host subcommand. Optionally, nontrusted hosts can specify other host names, but all must be distinct.
- Operation
- A specific combination of authentication scheme (none, symmetric key, public 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 NTPv4 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 an NTP packet of appropriate cryptotype arrives. When mobilized by a server or peer configuration command and no key or autokey subcommands are present, the association is not authenticated. If the key subcommand is present, the association is authenticated using the symmetric key ID specified. If the autokey subcommand is present, the association is authenticated using Autokey.
- With Autokey, the cryptotype of the association is determined by the set of files generated by the ntp-keygen utility program. All configurations include a public/private host key pair and matching certificate. Absent identity parameters, this is a Trusted Certificate (TC) scheme. There are three identity schemes, IFF, GQ and MV described on the Identity Schemes page. Each is characterized by a set of private parameters that are distributed to each group host by secure means.
- A group can operate where the cryptotype can be different for each client. One client can elect to use no authentication at all, another with the TC scheme and others with IFF, GQ and/or MV. However, a host cannot prove identity to a dependent client unless it has the corresponding identity parameters.
+ Autokey has an intimidating number of configuration options, most of which are not necessary in typical scenarios. The simplest scenario consists of a secure group with one TH at the lowest stratum. For the simplest identity scheme TC, the TH generates host key and trusted certificate files using the ntp-keygen -T command, while the remaining group hosts use the same command with no options. All hosts use the crypto configuration command with no options. Configuration with passwords is described in the ntp-keygen page
+ When an identity scheme is included, for example IFF, the TH generates host key, trusted certificate and private identity keys files using the ntp-keygen -T -I -i group command, where group is the group name. The remaining group hosts use the same command with no options. All hosts use the crypto ident group configuration command.
+ Hosts with no dependent clients can retrieve public identity parameters from an archive or web page. The ntp-keygen can export these data using the -e option. Hosts with dependent clients other than the TH must retrieve copies of the TH private identity keys using secure means. The ntp-keygen can export these data using the -q option. In either case the data are installed as a file and then renamed using the name given as the first line in the file, but without the filestamp.
Examples
- Consider a scenario involving three secure groups with names red, green and blue. Groups red and blue may be typical of national laboratories providing certified time. These groups run symmetric modes so each can monitor or backup the other should the ions grow dim. Group green may be typical of a large university providing time to the campus population. Green is dependent on both red and blue and, for the sake of this example, shares an Ethernet with red and blue. Blue uses the IFF scheme, while both red and green us the GQ scheme, but with different keys.
- Blue and red include the following commands in the configuration file
- crypto pw passwd host group ident group
- peer IPaddr autokey
- broadcast IPbroadcastaddr autokey
- where passwd is the password for files encrypted by ntp-keygen, group is the group name and IPaddr is the DNS name or IP address of the peer. Blue generates cryptographic media using ntp-keygen and the commands
- ntp-keygen -q passwd -s blue -T -I
- ntp-keygen -q passwd -s blue -e >ntpkey_iffpar_blue
- ntp-keygen -q passwd -s blue -q host >ID_iffkey_blue
- The first line generates the host keys, trusted certificate and IFF keys files. The second generates the IFF parameters file, which can be saved in the same keys directory without name collision. This file is not encrypted and can be moved to a public place. The third line generates a copy of the IFF keys file encrypted with the password host supplied by the requesting host. Note the ID is chosen to avoid name collision should the file be saved in the same keys directory. Ordinarily the file contents are piped to a mail application which returns it to the requesting host. Red and green use a similar procedure, but substitute their group name and use -G in place of -I.
- To set up the network, the identity parameters file for blue is copied to both red and green, while the identity parameters file for red is copied to blue and green.
- Now consider host cyan whose server is green and host magenta whose server is cyan. These are not trusted hosts, so cyan generates cryptographic media using the first two commands above, but omitting the -G and -T options. However, since magenta is a client of cyan, cyan needs the identity keys file for green, which is generated by the third line in green's ntp-keygen script. While in principle the identity encrypted keys file includes the parameters, the unencrypted parameters file is maintained separately, cyan needs both files
+ Consider a scenario involving three secure groups RED, GREEN and BLUE. RED and BLUE are typical of national laboratories providing certified time to the Internet at large. TH mort of RED and TH macabre of BLUE run NTP symmetric mode with each other for monitoring or backup. GREEN is typical of a large university providing certified time to the campus community. TH howland of GREEN is a client of both RED and BLUE. BLUE uses the IFF scheme, while both RED and GREEN use the GQ scheme, but with different keys.
+ BLUE TH macabre uses configuration commands
+ crypto pw qqsv ident blue
+ peer mort autokey
+ where qqsv is the password for macabre files. It generates BLUE files using the commands
+ ntp-keygen -p qqsv -T -G -i blue
+ ntp-keygen -p qqsv -e >ntpkey_gqpar_blue
+ The first line generates the host, trusted certificate and private GQ server files. The second generates the public GQ client file, which can have any nonconflicting mnemonic name.
+ RED TH mort uses configuration commands
+ crypto pw xxx ident red
+ peer macabre autokey
+ where xxx is the password for mort files. It generates RED files using the commands
+ ntp-keygen -p xxx -T -I -i red
+ ntp-keygen -p xxx -e >ntpkey_iffpar_red
+ GREEN TH howland uses configuration commands
+ crypto pw yyy ident green
+ server mort autokey
+ server macabre autokey
+ where yyy is the password for mort files. It generates GREEN files using the commands
+ ntp-keygen -p yyy -T -G -i green
+ ntp-keygen -p yyy -e >ntpkey_gqpar_green
+ ntp-keygen -p yyy -v zzz >zzz_ntpkey_gqkey_green
+ The first two lines serve the same purpose as the preceeding examples. The third line generats a copy of the private GREEN server file for use on another server in the same group, but encrypted with the zzz pasword.
+ Each TH in a group acting as a client of another group retrieves the public client file for that group from a public archive or web page using nonsecure means. In addition, each server in a group retrieves the private server file from the TH of that group, but it is encrypted and so can be sent using nonsecured means. The files are installed in the keys directory with name taken from the first line in the file, but without the filestamp
Authentication Commands
- autokey [logsec]
- Specifies the interval between regenerations of the session key list used with the Autokey protocol. Note that the size of the key list for each association depends on this interval and the current poll interval. The default value is 12 (4096 s or about 1.1 hours). For poll intervals above the specified interval, a session key list with a single entry will be regenerated for every message sent.
- controlkey key
-
- Specifies the key identifier to use with the ntpq utility, which uses the standard protocol defined in RFC-1305. The key argument is the key identifier for a trusted key, where the value can be in the range 1 to 65,534, inclusive.
-
- crypto [randfile file] [host name] [ident name] [pw password]
-
- This command requires the OpenSSL library. It activates public key cryptography and loads the required public/private encryption and sign kyes and public certificat. If one or more files are left unspecified, the default names are used as described below. Unless the complete path and name of the file are specified, the location of a file is relative to the keys directory specified in the keysdir command or default /usr/local/etc. Following are the subcommands.
+ - Specifies the key ID to use with the ntpq utility, which uses the standard protocol defined in RFC-1305. The key argument is the key ID for a trusted key, where the value can be in the range 1 to 65,534, inclusive.
- crypto [randfile file] [host name] [ident name] [pw password]
+
- This command requires the OpenSSL library. It activates public key cryptography and loads the required host key and public certificat. If one or more files are left unspecified, the default names are used as described below. Unless the complete path and name of the file are specified, the location of a file is relative to the keys directory specified in the keysdir configuration command or default /usr/local/etc. Following are the options.
+
- host name
-
- Specifies the host name used in the host key link ntpkey_host_name, sign key link ntpkey_sign_name and certificate link ntpkey_cert_name. The ntp-keygen program automatically installs these links to the most recently generated files.
- ident name
-
- Specifies the group name used in the identity key link ntpkey_key_name, where key identifies the key type described on the ntp-keygen page. The ntp-keygen program automatically installs these links to the most recently generated files.
- pw password
-
- Specifies the password to decrypt files previously encrypted by the ntp-keygen program.
- randfile file
+
- Specifies the string used when constructing the names for the host, sign and certificate files generated by the ntp-keygen program with the -s name option.
+
- ident name
+
- Specifies the string used in constructing the identity files generated by the ntp-keygen program with the -i name option.
- pw password
+
- Specifies the password to decrypt files previously encrypted by the ntp-keygen program with the -p option.
+
- randfile file
- Specifies the location of the random seed file used by the OpenSSL library. The defaults are described on the ntp-keygen page.
- keys keyfile
-
- Specifies the complete path to the MD5 key file containing the keys and key identifiers used by ntpd, ntpq and ntpdc when operating with symmetric key cryptography. This is the same operation as the -k command line option.
+
- Specifies the complete path to the MD5 key file containing the keys and key IDs used by ntpd, ntpq and ntpdc when operating with symmetric key cryptography. This is the same operation as the -k command line option.
- keysdir path
- This command specifies the default directory path for cryptographic keys, parameters and certificates. The default is /usr/local/etc/.
- requestkey key
-
- Specifies the key identifier to use with the ntpdc utility program, which uses a proprietary protocol specific to this implementation of ntpd. The key argument is a key identifier for the trusted key, where the value can be in the range 1 to 65,534, inclusive.
-
- revoke [logsec]
+
- Specifies the key ID to use with the ntpdc utility program, which uses a proprietary protocol specific to this implementation of ntpd. The key argument is a key ID for the trusted key, where the value can be in the range 1 to 65,534, inclusive.
- revoke [logsec]
- Specifies the interval between re-randomization of certain cryptographic values used by the Autokey scheme, as a power of 2 in seconds. These values need to be updated frequently in order to deflect brute-force attacks on the algorithms; however, updating some values is a relatively expensive operation. The default interval is 16 (65,536 s or about 18 hours). For poll intervals above the specified interval, the values will be updated for every message sent.
- trustedkey key [...]
-
- Specifies the key identifiers which are trusted for the purposes of authenticating peers with symmetric key cryptography, as well as keys used by the ntpq and ntpdc programs. The authentication procedures require that both the local and remote servers share the same key and key identifier for this purpose, although different keys can be used with different servers. The key arguments are 32-bit unsigned integers with values from 1 to 65,534.
-
+ - Specifies the key ID which are trusted for the purposes of authenticating peers with symmetric key cryptography, as well as keys used by the ntpq and ntpdc programs. The authentication procedures require that both the local and remote servers share the same key and key ID for this purpose, although different keys can be used with different servers.
Error Codes
Errors can occur due to mismatched configurations, unexpected restarts, expired certificates and unfriendly people. In most cases the protocol state machine recovers automatically by retransmission, timeout and restart, where necessary. Some errors are due to mismatched keys, digest schemes or identity schemes and must be corrected by installing the correct media and/or correcting the configuration file. One of the most common errors is expired certificates, which must be regenerated and signed at least once per year using the ntp-keygen program.
The following error codes are reported via the NTP control and monitoring protocol trap mechanism.
@@ -126,15 +192,15 @@
The leapseconds table is missing, corrupted or bogus.
113 (bad or missing certificate)
The certificate is missing, corrupted or bogus.
- 114 (bad or missing group key)The identity key is missing, corrupt or bogus.
-
+ 114 (bad or missing group key)
+ The identity key is missing, corrupt or bogus.
115 (protocol error)
The protocol state machine has wedged due to unexpected restart
116 (server certificate expired)
The old server certificate has expired.
Files
- See the ntp-keygen page. Note that provisions to load leap second values from the NIST files have been removed. These provisions are now available whether or not the OpenSSL library is available. However, the functions that can download these values from servers remains available.
+ See the ntp-keygen page. Note that provisions to load leap second values from the NIST files have been removed. These provisions are now available whether or not the OpenSSL library is available. However, the functions that can download these values from servers remains available.
from Pogo, Walt Kelly
from Alice's Adventures in Wonderland, Lewis Carroll
ICOM R-72 shortwave receiver and Sure audio mixer
- 
from Alice's Adventures in Wonderland, Lewis Carroll
from Pogo, Walt Kelly
+