+* Support for multiple Autokey identity groups from Dave Mills.
+* Documentation updates from Dave Mills.
* Add ntpq kerninfo, authinfo, and sysinfo commands similar to ntpdc's.
(4.2.7p103) 2010/12/24 Released by Harlan Stenn <stenn@ntp.org>
* Add ntpq pstats command similar to ntpdc's.
<body>
<h3>Autokey Public-Key Authentication</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->24-Dec-2010 5:45<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->24-Dec-2010 15:06<!-- #EndDate -->
UTC</p>
<hr>
<h4>Table of Contents</h4>
<p>It is possible to configure clients of server <tt>grundoon.udel.edu</tt> in the same way with the server line pointing to <tt>grundoon.udel.edu</tt>. Dependent clients authenticate to <tt>time.nistg.gov</tt> through <tt>grundoon.udel.edu</tt>.</p>
<p>In the above configuration examples, the default Autokey host name is the string returned by the Unix <tt>gethostname()</tt> library routine. However, this name has nothing to do with the DNS name of the host. The Autokey host name is used as the subject and issuer names on the certificate, as well as the default password for the encrypted keys files. The Autokey host name can be changed using the <tt>-s</tt> option of the <tt>ntp-keygen</tt> program. The default password can be changed using the <tt>-p</tt> option of the <tt>ntp-keygen</tt> program and the <tt>pw</tt> option of the <tt>crypto</tt> command.</p>
<h4 id="ident">Configuration - Identity Schemes</h4>
-<p> The example in this section uses the IFF identity scheme. The parent subnet TA generates IFF tidentity files using an <tt>ntp-keygen </tt> program command with options specified in this section, while the child secure group TH uses the same command with no options. Both the TA and TH use the <tt>crypto</tt> command in the configuration file with no options. In addition, the TH specifies options for the <tt>server</tt> and <tt>ident</tt> commands as described in this section. </p>
-<p> It's best to start with a functioning TC configuration and add commands as necessary. For example, the TA generates an encrypted server keys file for the IFF identity scheme using the command</p>
+<p> The example in this section uses the IFF identity scheme, but others, including GQ and MV, can be used as well. A parent subnet TA generates IFF tidentity files using an <tt>ntp-keygen </tt> program command with options specified in this section, while the child secure group TH uses the same program command with no options. Both the TA and TH use the <tt>crypto</tt> command with no options. In addition, the TH specifies options for the <tt>server</tt> and <tt>ident</tt> commands as described in this section. </p>
+<p> It's best to start with a functioning TC configuration and add commands as necessary. For example, the TA generates an encrypted server keys file and nonencrypted client parameters file for the IFF identity scheme using the command</p>
<p><tt>ntp-keygen -I</tt>.</p>
<p> Note the TA is not necessarily a trusted host, so may not need the <tt>-T</tt> option. The nonencrypted client parameters can be exported using the command</p>
<p><tt>ntp-keygen -e ><i>file</i></tt>,</p>
<p>where the <tt>-e</tt> option redirects the client parameters to <em><tt>file</tt></em> via the standard output stream for a mail application or stored locally for later distribution to one or more THs. In a similar fashion the encrypted keys file can be exported using the command </p>
<p><tt>ntp-keygen -q <em>passw2</em> ><i>file</i></tt>,</p>
-<p>where <em><tt>passwd2</tt></em> is the read password for another host. While the file name used for the parameters file is arbitrary, it is common practice to use a mnemonic group name like <tt>red</tt>. On the other hand, the file name used for the keys file must follow the conventions desdribed on the <tt>ntp-keygen</tt> page.</p>
-<p>To complete the configuration, the TH includes the parameters file name as the ident option on the the server command for the TA assocition</p>
-<p><tt>server 1.2.3.4 ident <em>group</em>.</tt></p>
-<p> In addtion, if operating as a broadcast/multicast client or a symmmetric passive peer, an ident command is necesary in the configuraiton file</p>
+<p>where <em><tt>passwd2</tt></em> is the read password for another TH. While the file name used for the client parameters file is arbitrary, it is common practice to use a mnemonic group name like <tt>red</tt>. On the other hand, the file name used for the keys file must follow the conventions desdribed on the <tt>ntp-keygen</tt> page. The encrypted server keys file is exported to other TAs that may serve the secure group, while the nonencrypted client parameters file can be distributed to all THs by nonsecure means.</p>
+<p>To complete the configuration, the TH includes the client parameters file name as the <tt>ident</tt> option of the the <tt>server</tt> command for the TA assocition</p>
+<p><tt>server 1.2.3.4 ident <em>group</em>,</tt></p>
+<p> where <em><tt>group</tt></em> is the chosen group name, in this case <tt>red</tt>. In addtion, if operating as a broadcast/multicast client or a symmmetric passive peer, the TH includes an <tt>ident</tt> command</p>
<p><tt>ident <em>group</em>,</tt></p>
-<p>where <em><tt>group</tt></em> is the name of the file exported with the <tt>-e</tt> option, in this case is the string <tt>red</tt>.</p>
-<h4 id="exam">Examples</h4>
-<div align="center"> <img src="pic/group.gif" alt="gif"> </div>
-<p>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. As shown ion the figure, RED TH mort and BLUE TH macabre run NTP symmetric mode with each other for monitoring or backup. For the purpose of illustration, assume both THs are primary servers. GREEN is typical of a large university providing certified time to the campus community. GREEN TH howland is a broadcast client of both RED and BLUE. BLUE uses the IFF scheme, while both RED and GREEN use the GQ scheme, but with different keys. YELLOW is a client of GREEN and for purposes of illustration a TH for YELLOW.</p>
-<p>The BLUE TH macabre uses configuration commands</p>
-<p><tt>crypto pw qqsv ident blue</tt><br>
- <tt>peer mort autokey ident red</tt><br>
- <tt>broadcast <i>address</i> autokey</tt></p>
-<p>where <tt>qqsv</tt> is the password for macabre files and <i>address</i> is the broadcast address for the local LAN. It generates BLUE files using the commands</p>
-<p><tt>ntp-keygen -p qqsv -T -G -i blue</tt><br>
- <tt>ntp-keygen -p qqsv -e >ntpkey_gqpar_blue</tt></p>
-<p>The first line generates the host, trusted certificate and private GQ server keys file. The second generates the public GQ client parameters file, which can have any nonconflicting mnemonic name.</p>
-<p>The RED TH mort uses configuration commands</p>
-<p><tt>crypto pw xxx ident red</tt><br>
- <tt>peer macabre autokey ident blue</tt><br>
- <tt>broadcast <i>address</i> autokey</tt></p>
-<p>where <tt>xxx</tt> is the password for mort files. It generates RED files using the commands</p>
-<p><tt>ntp-keygen -p xxx -T -I -i red</tt><br>
- <tt>ntp-keygen -p xxx -e >ntpkey_iffpar_red</tt></p>
-<p> The GREEN TH howland uses configuration commands</p>
-<p><tt>crypto pw yyy ident green</tt><br>
- <tt>broadcastclient ident red blue</tt></p>
-<p>where <tt>yyy</tt> is the password for howland files. It generates GREEN files using the commands</p>
-<p><tt>ntp-keygen -p yyy -T -G -i green</tt><br>
- <tt>ntp-keygen -p yyy -e >ntpkey_gqpar_green</tt><br>
- <tt>ntp-keygen -p yyy -q zzz >zzz_ntpkey_gqkey_green</tt></p>
-<p>The first two lines serve the same purpose as the preceding examples. The
- third line generates a copy of the private GREEN server file for use on another
- server in the same group, say YELLOW, but encrypted with the <tt>zzz</tt> password.</p>
-<p>A client of GREEN, for example YELLOW, uses the configuration commands</p>
-<p><tt>crypto pw abc</tt><br>
- <tt>server howland autokey ident red</tt></p>
-<p>where <tt>abc</tt> is the password for its files. It generates files using the command</p>
-<p><tt>ntp-keygen -p abc</tt></p>
-<p>The client retrieves the 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 keys file from the TH of that group, but it is encrypted and so must be sent using secure means. The files are installed in the keys directory with name taken from the first line in the file, but without the filestamp.</p>
-<p>Note that if servers of different groups, in this case RED and BLUE, share the same broadcast media, each server must have client files for all groups other than its own, while each client must have client files for all groups. Note also that this scenario is for illustration only and probably would not be wise for practical use, as if one of the TH reference clocks fails, the certificate trail becomes cyclic. In such cases the symmetric path between RED and BLUE, each in a different group, would not be a good idea.</p>
+<p>where <em><tt>group</tt></em> is the chosen group name, in this case <tt>red</tt>.</p>
<h4 id="ident2">Identity Schemes and Cryptotypes</h4>
<p>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 optional identity schemes, IFF, GQ and MV described on the <a href="http://www.eecis.udel.edu/%7emills/ident.html">Identity Schemes</a> 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 <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page.</p>
<p>A specific combination of authentication and identity schemes is called a <em>cryptotype</em>, which applies to clients and servers separately. A group can be
</tr>
</table>
<p>* These combinations are not valid if the restriction list includes the <tt>notrust</tt> option.</p>
-<p> </p>
<h4 id="err">Error Codes</h4>
<p>Errors can occur due to mismatched configurations, unexpected protocol 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 <a href="keygen.html"><tt>ntp-keygen</tt> - generate public and private keys</a> program.</p>
<p>The following error codes are reported via the NTP control and monitoring protocol trap mechanism and to the <tt>cryptostats</tt> monitoring file if configured.</p>
#define CS_CERTIF (4 + CS_MAX_NOAUTOKEY)
#define CS_SIGNATURE (5 + CS_MAX_NOAUTOKEY)
#define CS_REVTIME (6 + CS_MAX_NOAUTOKEY)
-#define CS_GROUP (7 + CS_MAX_NOAUTOKEY)
+#define CS_IDENT (7 + CS_MAX_NOAUTOKEY)
#define CS_DIGEST (8 + CS_MAX_NOAUTOKEY)
#define CS_MAXCODE CS_DIGEST
#else /* !AUTOKEY follows */
extern double sys_mindisp;
extern double sys_maxdist;
+extern char *sys_ident; /* identity scheme */
extern void poll_update (struct peer *, u_char);
extern void clear (struct peer *);
break;
case T_Ident:
- DPRINTF(1, ("DLM: ident %s\n", curr_var->value.s));
+ sys_ident = curr_var->value.s;
break;
case T_WanderThreshold: /* FALLTHROUGH */
{ CS_CERTIF, RO, "cert" }, /* 4 + CS_MAX_NOAUTOKEY */
{ CS_SIGNATURE, RO, "signature" }, /* 5 + CS_MAX_NOAUTOKEY */
{ CS_REVTIME, RO, "until" }, /* 6 + CS_MAX_NOAUTOKEY */
- { CS_GROUP, RO, "group" }, /* 7 + CS_MAX_NOAUTOKEY */
+ { CS_IDENT, RO, "ident" }, /* 7 + CS_MAX_NOAUTOKEY */
{ CS_DIGEST, RO, "digest" }, /* 8 + CS_MAX_NOAUTOKEY */
#endif /* AUTOKEY */
{ 0, EOV, "" } /* 57/65 */
CS_LEAPEND,
#ifdef AUTOKEY
CS_HOST,
- CS_GROUP,
+ CS_IDENT,
CS_FLAGS,
CS_DIGEST,
CS_SIGNATURE,
strlen(sys_hostname));
break;
- case CS_GROUP:
- if (sys_groupname != NULL)
- ctl_putstr(sys_var[CS_GROUP].text, sys_groupname,
- strlen(sys_groupname));
+ case CS_IDENT:
+ if (sys_ident != NULL)
+ ctl_putstr(sys_var[CS_IDENT].text, sys_ident,
+ strlen(sys_ident));
break;
case CS_CERTIF:
struct peer *peer /* peer structure pointer */
)
{
- char filename[MAXFILENAME];
-
- /*
- * We come here after the group trusted host has been found; its
- * name defines the group name. Search the key cache for all
- * keys matching the same group name in order IFF, GQ and MV.
- * Use the first one available.
- */
- if (peer->crypto & CRYPTO_FLAG_IFF) {
- snprintf(filename, MAXFILENAME, "ntpkey_iffpar_%s",
- peer->ident);
- peer->ident_pkey = crypto_key(filename, NULL,
- &peer->srcadr);
- if (peer->ident_pkey != NULL)
- return (CRYPTO_IFF);
- }
- if (peer->crypto & CRYPTO_FLAG_GQ) {
- snprintf(filename, MAXFILENAME, "ntpkey_gqpar_%s",
- peer->ident);
- peer->ident_pkey = crypto_key(filename, NULL,
- &peer->srcadr);
- if (peer->ident_pkey != NULL)
- return (CRYPTO_GQ);
- }
- if (peer->crypto & CRYPTO_FLAG_MV) {
- snprintf(filename, MAXFILENAME, "ntpkey_mvpar_%s",
- peer->ident);
- peer->ident_pkey = crypto_key(filename, NULL,
- &peer->srcadr);
- if (peer->ident_pkey != NULL)
- return (CRYPTO_MV);
+
+ /*
+ * We come here after the trusted host has been found. The name
+ * of the parameters file is in peer->ident and must be present.
+ * Search the key cache for all keys matching this name. Use the
+ * first one available. The identity scheme is supplied by the
+ * server.
+ */
+ peer->ident_pkey = crypto_key(peer->ident, NULL, &peer->srcadr);
+ if (peer->ident_pkey == NULL) {
+ report_event(XEVNT_ID, peer, NULL);
+ return (CRYPTO_NULL);
}
+ if (peer->crypto & CRYPTO_FLAG_IFF)
+ return (CRYPTO_IFF);
+
+ else if (peer->crypto & CRYPTO_FLAG_GQ)
+ return (CRYPTO_GQ);
+
+ else if (peer->crypto & CRYPTO_FLAG_MV)
+ return (CRYPTO_MV);
+
report_event(XEVNT_ID, peer, NULL);
return (CRYPTO_NULL);
}
}
hostval.vallen = htonl(strlen(cinfo->subject));
hostval.ptr = cinfo->subject;
- if (sys_groupname != NULL) {
+ if (sys_groupname == NULL)
+ sys_groupname = sys_hostname;
- /*
- * Load optional IFF parameters from file
- * "ntpkey_iffkey_<groupname>".
- */
- snprintf(filename, MAXFILENAME, "ntpkey_iffkey_%s",
- sys_groupname);
- iffkey_info = crypto_key(filename, passwd, NULL);
- if (iffkey_info != NULL)
- crypto_flags |= CRYPTO_FLAG_IFF;
+ /*
+ * Load optional IFF parameters from file
+ * "ntpkey_iffkey_<groupname>".
+ */
+ snprintf(filename, MAXFILENAME, "ntpkey_iffkey_%s",
+ sys_groupname);
+ iffkey_info = crypto_key(filename, passwd, NULL);
+ if (iffkey_info != NULL)
+ crypto_flags |= CRYPTO_FLAG_IFF;
- /*
- * Load optional GQ parameters from file
- * "ntpkey_gqkey_<groupname>".
- */
- snprintf(filename, MAXFILENAME, "ntpkey_gqkey_%s",
- sys_groupname);
- gqkey_info = crypto_key(filename, passwd, NULL);
- if (gqkey_info != NULL)
- crypto_flags |= CRYPTO_FLAG_GQ;
+ /*
+ * Load optional GQ parameters from file
+ * "ntpkey_gqkey_<groupname>".
+ */
+ snprintf(filename, MAXFILENAME, "ntpkey_gqkey_%s",
+ sys_groupname);
+ gqkey_info = crypto_key(filename, passwd, NULL);
+ if (gqkey_info != NULL)
+ crypto_flags |= CRYPTO_FLAG_GQ;
- /*
- * Load optional MV parameters from file
- * "ntpkey_mvkey_<groupname>".
- */
- snprintf(filename, MAXFILENAME, "ntpkey_mvkey_%s",
- sys_groupname);
- mvkey_info = crypto_key(filename, passwd, NULL);
- if (mvkey_info != NULL)
- crypto_flags |= CRYPTO_FLAG_MV;
- }
+ /*
+ * Load optional MV parameters from file
+ * "ntpkey_mvkey_<groupname>".
+ */
+ snprintf(filename, MAXFILENAME, "ntpkey_mvkey_%s",
+ sys_groupname);
+ mvkey_info = crypto_key(filename, passwd, NULL);
+ if (mvkey_info != NULL)
+ crypto_flags |= CRYPTO_FLAG_MV;
/*
* We met the enemy and he is us. Now strike up the dance.
int sys_manycastserver; /* respond to manycast client pkts */
int peer_ntpdate; /* active peers in ntpdate mode */
int sys_survivors; /* truest of the truechimers */
+char *sys_ident = NULL; /* identity scheme */
/*
* TOS and multicast mapping stuff
if ((peer = newpeer(&rbufp->recv_srcadr, NULL,
rbufp->dstadr, MODE_CLIENT, hisversion, NTP_MINDPOLL,
NTP_MAXDPOLL, FLAG_PREEMPT, MDF_UCAST | MDF_UCLNT, 0,
- skeyid, NULL)) == NULL) {
+ skeyid, sys_ident)) == NULL) {
sys_declined++;
return; /* ignore duplicate */
}
if ((peer = newpeer(&rbufp->recv_srcadr, NULL,
rbufp->dstadr, MODE_BCLIENT, hisversion,
pkt->ppoll, pkt->ppoll, 0, 0, 0,
- skeyid, NULL)) == NULL) {
+ skeyid, sys_ident)) == NULL) {
sys_restricted++;
return; /* ignore duplicate */
*/
if ((peer = newpeer(&rbufp->recv_srcadr, NULL,
rbufp->dstadr, MODE_CLIENT, hisversion, pkt->ppoll,
- pkt->ppoll, FLAG_IBURST, MDF_BCLNT, 0, skeyid, NULL)) ==
+ pkt->ppoll, FLAG_IBURST, MDF_BCLNT, 0, skeyid, sys_ident)) ==
NULL) {
sys_restricted++;
return; /* ignore duplicate */
*/
if ((peer = newpeer(&rbufp->recv_srcadr, NULL,
rbufp->dstadr, MODE_PASSIVE, hisversion, pkt->ppoll,
- NTP_MAXDPOLL, 0, MDF_UCAST, 0, skeyid, NULL)) == NULL) {
+ NTP_MAXDPOLL, 0, MDF_UCAST, 0, skeyid, sys_ident)) == NULL) {
sys_declined++;
return; /* ignore duplicate */
}
projects / thirdparty / ntp.git / commitdiff
