+* loopfilter FLL/PLL crossover cleanup from Dave Mills.
+* Documentation updates from Dave Mills.
+* ntp-keygen cleanup from Dave Mills.
+* crypto API cleanup from Dave Mills.
(4.2.5p169) 2009/04/30 Released by Harlan Stenn <stenn@ntp.org>
* [Bug 1171] Note that we never look for -lreadline by default.
* [Bug 1090] Fix bogus leap seconds in refclock_hpgps.
<h3>Authentication Options</h3>
<img src="pic/alice44.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Our resident cryptographer; now you see him, now you don't.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">02:38</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="252">Monday, March 17, 2008</csobj></p>
- <br clear="left">
+ <p>Last update:
+ <!-- #BeginDate format:En2m -->01-May-2009 2:19<!-- #EndDate -->
+ UTC</p>
+<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/authopt.txt"></script>
<p>Alice holds the key.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->26-Apr-2009 15:46<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->30-Apr-2009 23:47<!-- #EndDate -->
</p>
<br clear="left">
<h4 id="descrip">Description</h4>
-<p>This program generates cryptographic data files used by the NTPv4 authentication
- and identity schemes. It generates MD5 keys used in symmetric key cryptography
- and, if the OpenSSL software library has been installed, it generates host keys,
- certificates and identity keys used in the Autokey public key cryptography.
- The symmetric keys file is generated in a format comparable with NTPv3 and also
- used with NTPv4. All other files are in PEM-encoded printable ASCII format so
- they can be embedded as MIME attachments in mail to other sites and certificate
- authorities.</p>
-
-<p>When used to generate symmetric keys, the program produces a file containing
- 16 random keys. If this is the only need, run <tt>ntp-keygen</tt> with the <tt>-M</tt> option
- and disregard the remainder of this page. The file can be edited later with
- purpose-chosen passwords. Each line of the file contains three fields, first
- an integer between 1 and 65534, inclusive, representing the key identifier used
- in the <tt>server</tt> and <tt>peer</tt> configuration command. Next is the
- single character <tt>M</tt> to designate the key as MD5. Finally is the key
- itself from 1 to 31 characters chosen from the printable ASCII set with the
- exclusion of space and #. As is custom, # and the remaining characters on the
- line are ignored.</p>
-
-<p>Generated files are compatible with other OpenSSL applications and other Public Key Infrastructure (PKI) resources. Certificates generated by this program should be compatible with extant industry practice, although some users might find the interpretation of X509v3 extension fields somewhat liberal. However, the identity keys are probably not compatible with anything other than Autokey.</p>
-
-<p>Most files used by this program are encrypted using a private password. The <tt>-p</tt> option specifies the password for local files and the <tt>-q</tt> option the password for files to be sent to remote sites. If no local password is specified, the host name returned by the Unix <tt>gethostname()</tt> function is used. If no remote password is specified, the local password is used.</p>
+<p>This program generates cryptographic data files used by the NTPv4 authentication and identity schemes. It generates MD5 keys used in symmetric key cryptography and, if the OpenSSL software library has been installed, it generates host keys, sign keys, certificates and identity keys used in the Autokey public key cryptography. The symmetric keys file is generated in a format compatible with NTPv3. All other files are in PEM-encoded printable ASCII format so they can be embedded as MIME attachments in mail to other sites.</p>
+
+<p>When used to generate symmetric keys, the program produces a file containing 16 random keys. If this is the only need, run <tt>ntp-keygen</tt> with the <tt>-M</tt> option and disregard the remainder of this page. The file can be edited later with purpose-chosen passwords for the <tt>ntpq</tt> and <tt>ntpdc</tt> programs. Each line of the file contains three fields, first an integer between 1 and 65534, inclusive, representing the key identifier used in the <tt>server</tt> and <tt>peer</tt> configuration command. Next is the single character <tt>M</tt> to designate the key as MD5. Finally is the key itself from 1 to 31 characters chosen from the printable ASCII set with the exclusion of space and #. However, only the first 16 characters are significant. As is custom, # and the remaining characters on the line are ignored.</p>
+
+<p>The remaining generated files are compatible with other OpenSSL applications and other Public Key Infrastructure (PKI) resources. Certificates generated by this program should be compatible with extant industry practice, although some users might find the interpretation of X509v3 extension fields somewhat liberal. However, the identity keys are probably not compatible with anything other than Autokey.</p>
+
+<p>Most files used by this program are encrypted using a private password. The <tt>-p</tt> option specifies the password for local files and the <tt>-q</tt> option the password for files sent to remote sites. If no local password is specified, the host name returned by the Unix <tt>gethostname()</tt> function, normally the DNS name of the host, is used. If no remote password is specified, the local password is used.</p>
<p>The <tt>pw</tt> option of the <tt>crypto</tt> configuration command specifies the read password for previously encrypted files. This must match the local password used by this program. If not specified, the host name is used. Thus, if files are generated by this program without password, they can be read back by <tt>ntpd</tt> without password, but only on the same host.</p>
<p>All files and links are installed by default in the keys directory <tt>/usr/local/etc</tt>, which is normally in a shared filesystem in NFS-mounted networks and cannot be changed by clients. The location of the keys directory can be changed by the <tt>keysdir</tt> configuration command in such cases. Normally, encrypted files for each host are generated by that host and used only by that host, although exceptions exist as noted later on this page.</p>
-<p>This program directs commentary and error messages to the standard error stream <tt>stderr</tt> and
- remote files to the standard output stream <tt>stdout</tt> where they can be
- piped to other applications or redirected to a file. The names used for generated
- files and links all begin with the string <tt>ntpkey</tt> and include the file
- type, generating host and filestamp, as described in the <a href="#fmt">Cryptographic
- Data Files</a> section below</p>
+<p>This program directs commentary and error messages to the standard error stream <tt>stderr</tt> and remote files to the standard output stream <tt>stdout</tt> where they can be piped to other applications or redirected to a file. The names used for generated files and links all begin with the string <tt>ntpkey</tt> and include the file type, generating host and filestamp, as described in the <a href="#fmt">Cryptographic Data Files</a> section below</p>
<h4 id="run">Running the Program</h4>
-<p>To test and gain experience with Autokey concepts, log in as root and change to the keys directory, usually <tt>/usr/local/etc</tt>. When run for the first time, or if all files with names beginning <tt>ntpkey</tt> have been removed, use the <tt>ntp-keygen </tt>command without arguments to generate a default RSA host key and matching RSA-MD5 certificate with expiration date one year hence. If run again, the program uses the existing keys and parameters and generates a new certificate with new expiration date one year hence; however, the certificate is not generated if the <tt>-e</tt> or <tt>-q</tt> options are present.</p>
+<p>To test and gain experience with Autokey concepts, log in as root and change to the keys directory, usually <tt>/usr/local/etc</tt>. When run for the first time, or if all files with names beginning <tt>ntpkey</tt> have been removed, use the <tt>ntp-keygen </tt>command without arguments to generate a default RSA host key and matching RSA-MD5 certificate with expiration date one year hence. If run again, the program uses the existing keys and parameters and generates only a new certificate with new expiration date one year hence; however, the certificate is not generated if the <tt>-e</tt> or <tt>-q</tt> options are present.</p>
-<p>Run the command on as many hosts as necessary. Designate one of them as the
- trusted host (TH) using <tt>ntp-keygen</tt> with the <tt>-T</tt> option and
- configure it to synchronize from reliable Internet servers. Then configure the
- other hosts to synchronize to the TH directly or indirectly. A certificate trail
- is created when Autokey asks the immediately ascendant host towards the root
- to sign its certificate, which is then provided to the immediately descendant
- host on request. All group hosts should have acyclic certificate trails ending
- on the TH.</p>
+<p>Run the command on as many hosts as necessary. Designate one of them as the trusted host (TH) using <tt>ntp-keygen</tt> with the <tt>-T</tt> option and configure it to synchronize from reliable Internet servers. Then configure the other hosts to synchronize to the TH directly or indirectly. A certificate trail is created when Autokey asks the immediately ascendant host towards the TH to sign its certificate, which is then provided to the immediately descendant host on request. All group hosts should have acyclic certificate trails ending on the TH.</p>
<p>The host key is used to encrypt the cookie when required and so must be RSA type. By default, the host key is also the sign key used to encrypt signatures. A different sign key can be assigned using the <tt>-S</tt> option and this can be either RSA or DSA type. By default, the signature message digest type is MD5, but any combination of sign key type and sign digest type supported by the OpenSSL library can be specified using the <tt>-c</tt> option. At the moment, legacy considerations require the NTP packet header digest type to be MD5.</p>
<h4 id="trust">Trusted Hosts and Secure Groups</h4>
-<p>As described on the <a href="authopt.html">Authentication Options</a> page,
- an NTP secure group consists of one or more low-stratum The as the root
- from which all other group hosts derive synchronization directly or indirectly.
- For authentication purposes all hosts in a group must have the same group name
- specified by the <tt>-i</tt> option and matching the <tt>ident</tt> option of
- the <tt>crypto</tt> configuration command. The group name is used in the subject
- and issuer fields of trusted certificates and when constructing the file names
- for identity keys. All hosts must have different host names specified by the <tt>-s</tt> option
- and matching the <tt>host</tt> option of the <tt>crypto</tt> configuration command.
- Host names are used in the subject and issuer fields of nontrusted certificates
- and when constructing the file names for host and sign keys and certificates.
- Host and group names are used only for authentication purposes and have nothing
- to do with NS names.</p>
+<p>As described on the <a href="authopt.html">Authentication Options</a> page, an NTP secure group consists of one or more low-stratum THs as the root from which all other group hosts derive synchronization directly or indirectly. For authentication purposes all hosts in a group must have the same group name specified by the <tt>-i</tt> option and matching the <tt>ident</tt> option of the <tt>crypto</tt> configuration command. The group name is used in the subject and issuer fields of trusted, self-signed certificates and when constructing the file names for identity keys. All hosts must have different host names, either the default host name or as specified by the <tt>-s</tt> option and matching the <tt>host</tt> option of the <tt>crypto</tt> configuration command. Most installations need not specify the <tt>-i</tt> option nor the <tt>host</tt> option. Host names are used in the subject and issuer fields of self-signed, nontrusted certificates and when constructing the file names for host and sign keys and certificates. Host and group names are used only for authentication purposes and have nothing to do with DNS names.</p>
<h4 id="ident">Identity Schemes</h4>
<p>As described on the <a href="authopt.html">Authentication Options</a> page, there are five identity schemes, three of which - IFF, GQ and MV - require identity keys specific to each scheme. There are two types of files for each scheme, an encrypted keys file and a nonencrypted parameters file, which usually contains a subset of the keys file. In general, NTP secondary servers operating as certificate signing authorities (CSA) use the keys file and clients use the parameters file. Both files are generated by the TA operating as a certificate authority (CA) on behalf of all servers and clients in the group.</p>
-<p>The parameters files are public; they can be stored in a public place and sent in the clear. The keys files are encrypted with the local password. To retrieve the keys file, a host sends a mail request to the TA including its local password. The TA encrypts the keys file with this password and returns it as an attachment. The attachment is then copied intact to the keys directory with name given in the first line of the file, but all in lower case and with the filestamp deleted..</p>
+<p>The parameters files are public; they can be stored in a public place and sent in the clear. The keys files are encrypted with the local password. To retrieve the keys file, a host can send a mail request to the TA including its local password. The TA encrypts the keys file with this password and returns it as an attachment. The attachment is then copied intact to the keys directory with name given in the first line of the file, but all in lower case and with the filestamp deleted. Alternatively, the parameters file can be retrieved froom a secure web site.</p>
-<p>For example, the TA can generate IFF keys and trusted certificate using the command</p>
+<p>For example, the TA generates default host key, IFF keys and trusted certificate using the command</p>
-<p><tt>ntp-keygen -p <i>local_passwd</i> -T -I</tt></p>
+<p><tt>ntp-keygen -p <i>local_passwd</i> -T -I -i<i>group_name</i></tt></p>
-<p>Once these media have been generated, the TA can then generate the public parameters using the command</p>
+<p>Each group host generates default host keys and nontrusted certificate usn the same command line but omitting the <tt>-i</tt> option. Once these media have been generated, the TA can then generate the public parameters using the command</p>
<p><tt>ntp-keygen -p local_passwd -e ><i>parameters_file</i></tt></p>
<dd>Enable debugging. This option displays the cryptographic data produced for eye-friendly billboards.</dd>
<dt><tt>-e</tt></dt>
-<dd>Extract the IFF or GQ public parameters from the <tt>IFFkey</tt> or <tt>GQkey</tt> keys file previously specified. Send the unencrypted data to the standard output stream <tt>stdout</tt>. While the IFF parameters do not reveal the private group key, the GQ parameters should be used with caution, as they include the group key. Use the <tt>-q</tt> option with password instead. Note: a new certificate is not generated when this option is present. This allows multiple commands with this option but without disturbing existing media.</dd>
+<dd>Extract the IFF or GQ public parameters from the <tt>IFFkey</tt> or <tt>GQkey</tt> keys file previously specified. Send the unencrypted data to the standard output stream <tt>stdout</tt>. While the IFF parameters do not reveal the private group key, the GQ parameters should be used with caution, as they include the group key. Use the <tt>-q</tt> option with password instead. Note: a new certificate is not generated when this option is present. This allows multiple commands with this option but without disturbing existing media.</dd>
<dt><tt>-G</tt></dt>
<dd>Generate GQ key file <tt>GQkey and</tt> link <tt>gqkey </tt>for the Guillou-Quisquater
<dd>Generate a new encrypted IFF key file <tt>IFFkey </tt>and link <tt>iffkey </tt>for the Schnorr (IFF) identity scheme.</dd>
<dt><tt>-m <i>modulus</i></tt></dt>
-<dd>Set the modulus for generating files to <i>modulus</i> bits. The modulus defaults to 512, but can be set from this value to 2048.</dd>
+<dd>Set the modulus for generating files to <i>modulus</i> bits. The modulus defaults to 512, but can be set from 256 (32 octets) to 2048 (256 octets).</dd>
<dt><tt>-M</tt></dt>
<dd>Generate a new MD5 key file.</dd>
<h4 id="priv">Cryptographic Data Files</h4>
-<p>File and link names are in the form <tt>ntpkey_<i>key</i>_<i>name</i>.<i>fstamp</i></tt>, where <tt><i>key</i></tt> is the key or parameter type, <tt><i>name</i></tt> is the host or group name and <tt><i>fstamp</i></tt> 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.</p>
+<p>File and link names are in the form <tt>ntpkey_<i>key</i>_<i>name</i>.<i>fstamp</i></tt>, where <tt><i>key</i></tt> is the key or parameter type, <tt><i>name</i></tt> is the host or group name and <tt><i>fstamp</i></tt> 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.</p>
-<p>The key type is a string defining the cryptographic function. Key types include public/private keys <tt>host </tt>and <tt>sign</tt>, certificate <tt>cert</tt> and several challenge/response key types. By convention, files used for challenges have a <tt>par</tt> subtype, as in the IFF challenge <tt>IFFpar</tt>, while files for responses have a <tt>key</tt> subtype, as in the GQ response <tt>GQkey</tt>.</p>
+<p>The key type is a string defining the cryptographic function. Key types include public/private keys <tt>host</tt> and <tt>sign</tt>, certificate <tt>cert</tt> and several challenge/response key types. By convention, files used for challenges have a <tt>par</tt> subtype, as in the IFF challenge <tt>IFFpar</tt>, while files for responses have a <tt>key</tt> subtype, as in the GQ response <tt>GQkey</tt>.</p>
-<p>All files begin with two nonencrypted lines. The first line contains the file
- name in the format <tt>ntpkey_<i>key</i>_<i>host</i>.<i>fstamp</i></tt>. The
- second line contains the datestamp in conventional Unix <tt>date</tt> format.
- Lines beginning with <tt>#</tt> are ignored.</p>
+<p>All files begin with two nonencrypted lines. The first line contains the file name in the format <tt>ntpkey_<i>key</i>_<i>host</i>.<i>fstamp</i></tt>. The second line contains the datestamp in conventional Unix <tt>date</tt> format. Lines beginning with <tt>#</tt> are ignored.</p>
<p>The remainder of the file contains cryptographic data encoded first using ASN.1 rules, then encrypted using the DES-CBC algorithm and given password and finally written in PEM-encoded printable ASCII text preceded and followed by MIME content identifier lines.</p>
<p>Note that the keys used by the <tt>ntpq</tt> and <tt>ntpdc</tt> programs are checked against passwords requested by the programs and entered by hand, so it is generally appropriate to specify these keys in human readable ASCII format.</p>
-<p>The <tt>ntp-keygen</tt> program generates a MD5 symmetric keys file <tt>ntpkey_MD5key_<i>hostname.filestamp</i></tt>. 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 <tt>ntp.keys</tt>, so <tt>ntp-keygen</tt> 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. While this file is not used with the Autokey Version 2 protocol, it is needed to authenticate some remote configuration commands used by the <a href="ntpdc.html"><tt>ntpq</tt></a> and <a href="ntpq.html"><tt>ntpdc</tt></a> utilities.</p>
+<p>The <tt>ntp-keygen</tt> program generates a MD5 symmetric keys file <tt>ntpkey_MD5key_<i>hostname.filestamp</i></tt>. 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 <tt>ntp.keys</tt>, so <tt>ntp-keygen</tt> 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. While this file is not used with the Autokey Version 2 protocol, it is needed to authenticate some remote configuration commands used by the <a href="ntpq.html"><tt>ntpq</tt></a> and <a href="ntpdc.html"><tt>ntpdc</tt></a> utilities.</p>
<h4 id="bug">Bugs</h4>
#ifdef OPENSSL
extern int crypto_recv (struct peer *, struct recvbuf *);
extern int crypto_xmit (struct peer *, struct pkt *,
- struct recvbuf *, int *,
+ struct recvbuf *, int,
struct exten *, keyid_t);
extern keyid_t session_key (struct sockaddr_storage *,
struct sockaddr_storage *, keyid_t,
static const EVP_MD *sign_digest = NULL; /* sign digest */
static u_int sign_siglen; /* sign key length */
static char *rand_file = NULL; /* random seed file */
-static char *host_file = NULL; /* host key file */
-static char *sign_file = NULL; /* sign key file */
/*
* Cryptotypes
static int crypto_iff (struct exten *, struct peer *);
static int crypto_gq (struct exten *, struct peer *);
static int crypto_mv (struct exten *, struct peer *);
-static u_int crypto_send (struct exten *, struct value *,
- u_int *);
+static int crypto_send (struct exten *, struct value *, int);
static tstamp_t crypto_time (void);
static u_long asn2ntp (ASN1_TIME *);
static struct cert_info *cert_parse (u_char *, long, tstamp_t);
*
* Side effect: update the packet offset.
*
- * Returns
+ * Errors
* XEVNT_OK success
* XEVNT_CRT bad or missing certificate
* XEVNT_ERR protocol error
struct peer *peer, /* peer structure pointer */
struct pkt *xpkt, /* transmit packet pointer */
struct recvbuf *rbufp, /* receive buffer pointer */
- int *start, /* offset to extension field */
+ int start, /* offset to extension field */
struct exten *ep, /* extension pointer */
keyid_t cookie /* session cookie */
)
char statstr[NTP_MAXSTRLEN]; /* statistics for filegen */
tstamp_t tstamp;
u_int vallen;
- u_int len;
struct value vtemp;
associd_t associd;
int rval;
+ int len;
keyid_t tcookie;
/*
* and association ID. If this is a response and the host is not
* synchronized, light the error bit and go home.
*/
- pkt = (u_int32 *)xpkt + *start / 4;
+ pkt = (u_int32 *)xpkt + start / 4;
fp = (struct exten *)pkt;
opcode = ntohl(ep->opcode);
if (peer != NULL) {
srcadr_sin = &rbufp->recv_srcadr;
}
associd = (associd_t) ntohl(ep->associd);
- fp->associd = ep->associd;
len = 8;
+ fp->opcode = htonl((opcode & 0xffff0000) | len);
+ fp->associd = ep->associd;
rval = XEVNT_OK;
tstamp = crypto_time();
switch (opcode & 0xffff0000) {
*/
case CRYPTO_ASSOC:
case CRYPTO_ASSOC | CRYPTO_RESP:
- rval = crypto_send(fp, &hostval, &len);
+ len = crypto_send(fp, &hostval, start);
fp->fstamp = htonl(crypto_flags);
break;
vtemp.fstamp = ep->fstamp;
vtemp.vallen = ep->vallen;
vtemp.ptr = (u_char *)ep->pkt;
- rval = crypto_send(fp, &vtemp, &len);
+ len = crypto_send(fp, &vtemp, start);
break;
/*
cert_host->last)
rval = XEVNT_PER;
else
- rval = crypto_send(fp, &cert_host->cert, &len);
+ len = crypto_send(fp, &cert_host->cert, start);
break;
/*
if (tstamp == 0)
break;
- rval = crypto_send(fp, &xp->cert, &len);
+ len = crypto_send(fp, &xp->cert, start);
break;
/*
*/
case CRYPTO_IFF:
if ((rval = crypto_alice(peer, &vtemp)) == XEVNT_OK) {
- rval = crypto_send(fp, &vtemp, &len);
+ len = crypto_send(fp, &vtemp, start);
value_free(&vtemp);
}
break;
*/
case CRYPTO_IFF | CRYPTO_RESP:
if ((rval = crypto_bob(ep, &vtemp)) == XEVNT_OK) {
- rval = crypto_send(fp, &vtemp, &len);
+ len = crypto_send(fp, &vtemp, start);
value_free(&vtemp);
}
break;
*/
case CRYPTO_GQ:
if ((rval = crypto_alice2(peer, &vtemp)) == XEVNT_OK) {
- rval = crypto_send(fp, &vtemp, &len);
+ len = crypto_send(fp, &vtemp, start);
value_free(&vtemp);
}
break;
*/
case CRYPTO_GQ | CRYPTO_RESP:
if ((rval = crypto_bob2(ep, &vtemp)) == XEVNT_OK) {
- rval = crypto_send(fp, &vtemp, &len);
+ len = crypto_send(fp, &vtemp, start);
value_free(&vtemp);
}
break;
*/
case CRYPTO_MV:
if ((rval = crypto_alice3(peer, &vtemp)) == XEVNT_OK) {
- rval = crypto_send(fp, &vtemp, &len);
+ len = crypto_send(fp, &vtemp, start);
value_free(&vtemp);
}
break;
*/
case CRYPTO_MV | CRYPTO_RESP:
if ((rval = crypto_bob3(ep, &vtemp)) == XEVNT_OK) {
- rval = crypto_send(fp, &vtemp, &len);
+ len = crypto_send(fp, &vtemp, start);
value_free(&vtemp);
}
break;
*/
case CRYPTO_SIGN | CRYPTO_RESP:
if ((rval = cert_sign(ep, &vtemp)) == XEVNT_OK) {
- rval = crypto_send(fp, &vtemp, &len);
+ len = crypto_send(fp, &vtemp, start);
value_free(&vtemp);
}
break;
* key.
*/
case CRYPTO_COOK:
- rval = crypto_send(fp, &pubkey, &len);
+ len = crypto_send(fp, &pubkey, start);
break;
/*
tcookie = peer->hcookie;
if ((rval = crypto_encrypt(ep, &vtemp, &tcookie)) ==
XEVNT_OK) {
- rval = crypto_send(fp, &vtemp, &len);
+ len = crypto_send(fp, &vtemp, start);
value_free(&vtemp);
}
break;
}
}
peer->flags &= ~FLAG_ASSOC;
- rval = crypto_send(fp, &peer->sndval, &len);
+ len = crypto_send(fp, &peer->sndval, start);
break;
/*
* empty request.
*/
case CRYPTO_LEAP | CRYPTO_RESP:
- rval = crypto_send(fp, &tai_leap, &len);
+ len = crypto_send(fp, &tai_leap, start);
break;
/*
- * Default - Fall through for requests; for unknown responses,
- * flag as error.
+ * Default - Send a valid command for unknown requests; send
+ * an error response for unknown resonses.
*/
default:
if (opcode & CRYPTO_RESP)
rval = XEVNT_ERR;
}
- fp->opcode = htonl((opcode & 0xffff0000) | len);
/*
* In case of error, flame the log. If a request, toss the
#ifdef DEBUG
if (debug)
printf(
- "crypto_xmit: flags 0x%x ext offset %d len %u code 0x%x associd %d\n",
- crypto_flags, *start, len, opcode >> 16, associd);
+ "crypto_xmit: flags 0x%x offset %d len %d code 0x%x associd %d\n",
+ crypto_flags, start, len, opcode >> 16, associd);
#endif
- *start += len;
- return (rval);
+ return (len);
}
* Note: it is not polite to send a nonempty signature with zero
* timestamp or a nonzero timestamp with an empty signature, but those
* rules are not enforced here.
- *
- * Returns
- * XEVNT_OK success
- * XEVNT_LEN bad field format or length
*/
-u_int
+int
crypto_send(
struct exten *ep, /* extension field pointer */
struct value *vp, /* value pointer */
- u_int *start /* buffer offset */
+ int start /* buffer offset */
)
{
- u_int len, vallen, siglen;
+ u_int len, vallen, siglen, opcode;
int i, j;
/*
len += ((vallen + 3) / 4 + 1) * 4;
siglen = ntohl(vp->siglen);
len += ((siglen + 3) / 4 + 1) * 4;
- if (*start + len > NTP_MAXEXTEN - LEN_PKT_NOMAC - MAX_MAC_LEN)
- return (XEVNT_LEN);
+ if (start + len >= sizeof(struct pkt) - MAX_MAC_LEN)
+ return (0);
/*
* Copy timestamps.
memcpy(&ep->pkt[i], vp->sig, siglen);
i += j;
}
- *start += len;
- return (XEVNT_OK);
+ opcode = ntohl(ep->opcode);
+ ep->opcode = htonl((opcode & 0xffff0000) | len);
+ return (len);
}
/*
* Initialize structures.
*/
- if (host_file != NULL) {
- sys_hostname = host_file;
- } else {
+ if (sys_hostname == NULL) {
gethostname(filename, MAXFILENAME);
sys_hostname = emalloc(strlen(filename) + 1);
strcpy(sys_hostname, filename);
* Set host name (host).
*/
case CRYPTO_CONF_PRIV:
- host_file = emalloc(strlen(cp) + 1);
- strcpy(host_file, cp);
+ sys_hostname = emalloc(strlen(cp) + 1);
+ strcpy(sys_hostname, cp);
break;
/*
rand_file = emalloc(strlen(cp) + 1);
strcpy(rand_file, cp);
break;
-
- /*
- * Set sign key file name (sign).
- */
- case CRYPTO_CONF_SIGN:
- sign_file = emalloc(strlen(cp) + 1);
- strcpy(sign_file, cp);
- break;
}
}
# else
* The FLL and PLL frequency gain constants
* depend on the time constant and Allan
* intercept. The PLL is always used, but
- * becomes ineffective at and above the Allan
- * intercept. The FLL is used at and above the
- * Allan intercept.
+ * becomes ineffective above the Allan intercept
+ * where the FLL becomes effective.
*/
if (sys_poll >= allan_xpt)
clock_frequency += (fp_offset -
clock_epoch) * CLOCK_FLL;
/*
- * For the PLL the integration interval
- * (numerator) is the minimum of the update
- * interval and time constant. This allows
- * oversampling, but not undersampling.
+ * The PLL frequency gain (numerator) depends on
+ * the minimum of the update interval and Allan
+ * intercept. This reduces the PLL gain when the
+ * FLL becomes effective.
*/
- etemp = min(ULOGTOD(sys_poll), clock_epoch);
+ etemp = min(ULOGTOD(allan_xpt), clock_epoch);
dtemp = 4 * CLOCK_PLL * ULOGTOD(sys_poll);
clock_frequency += fp_offset * etemp / (dtemp *
dtemp);
* NTPv3, NTPv4 does not declare unsynchronized after one day,
* since the dispersion check serves this function. Also,
* since the poll interval can exceed one day, the old test
- * would be counterproductive. Note we do this even with
- * external clocks, since the clock driver will recompute the
- * maximum error and the local clock driver will pick it up and
- * pass to the common refclock routines. Very elegant.
+ * would be counterproductive.
*/
sys_rootdisp += clock_phi;
/*
* Implement the phase and frequency adjustments. The gain
- * factor (denominator) is not allowed to increase above half
- * the Allan intercept. It doesn't make sense to average phase
- * noise in this case and helps to reduce frequency convergence
- * time.
- */
- adjustment = clock_offset / (CLOCK_PLL * ULOGTOD(min(sys_poll,
- allan_xpt - 1)));
+ * factor (denominator) increases with poll interval, so is
+ * dominated by the FLL above the Allan intercept.
+ */
+ adjustment = clock_offset / (CLOCK_PLL * ULOGTOD(sys_poll));
clock_offset -= adjustment;
adj_systime(adjustment + drift_comp);
#endif /* LOCKCLOCK */
temp32 = CRYPTO_RESP;
peer->cmmd->opcode |= htonl(temp32);
- crypto_xmit(peer, &xpkt, NULL, &sendlen,
- peer->cmmd, 0);
+ sendlen += crypto_xmit(peer, &xpkt, NULL,
+ sendlen, peer->cmmd, 0);
free(peer->cmmd);
peer->cmmd = NULL;
}
*/
if (exten != NULL) {
if (exten->opcode != 0)
- crypto_xmit(peer, &xpkt, NULL, &sendlen,
- exten, 0);
+ sendlen += crypto_xmit(peer, &xpkt,
+ NULL, sendlen, exten, 0);
free(exten);
}
struct pkt xpkt; /* transmit packet structure */
struct pkt *rpkt; /* receive packet structure */
l_fp xmt_tx, xmt_ty;
- int sendlen, authlen;
+ int sendlen;
#ifdef OPENSSL
u_int32 temp32;
#endif
&rbufp->recv_srcadr, xkeyid, 0, 2);
temp32 = CRYPTO_RESP;
rpkt->exten[0] |= htonl(temp32);
- crypto_xmit(NULL, &xpkt, rbufp, &sendlen,
- (struct exten *)rpkt->exten, cookie);
+ sendlen += crypto_xmit(NULL, &xpkt, rbufp,
+ sendlen, (struct exten *)rpkt->exten,
+ cookie);
} else {
session_key(&rbufp->dstadr->sin,
&rbufp->recv_srcadr, xkeyid, cookie, 2);
if (mask == NULL) {
HTONL_FP(&xmt_tx, &xpkt.xmt);
}
-
- authlen = authencrypt(xkeyid, (u_int32 *)&xpkt, sendlen);
- sendlen += authlen;
-
+ sendlen += authencrypt(xkeyid, (u_int32 *)&xpkt, sendlen);
#ifdef OPENSSL
if (xkeyid > NTP_MAXKEY)
authtrust(xkeyid, 0);
DSA *dsa; /* DSA parameters */
u_char seed[20]; /* seed for parameters */
FILE *str;
- int bits;
/*
* Generate DSA parameters.
*/
- bits = modulus;
- if (bits > 1024)
- bits = 1024;
fprintf(stderr,
- "Generating DSA parameters (%d bits)...\n", bits);
+ "Generating DSA parameters (%d bits)...\n", modulus);
RAND_bytes(seed, sizeof(seed));
- dsa = DSA_generate_parameters(bits, seed, sizeof(seed), NULL,
+ dsa = DSA_generate_parameters(modulus, seed, sizeof(seed), NULL,
NULL, cb, "DSA");
fprintf(stderr, "\n");
if (dsa == NULL) {
projects / thirdparty / ntp.git / commitdiff
