From: Harlan Stenn Date: Tue, 28 Dec 2010 06:35:52 +0000 (-0500) Subject: Support for multiple Autokey identity groups from Dave Mills X-Git-Tag: NTP_4_2_7P104~4 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=1c68d1c54de7a6962f5d7db300f56d46ef586a53;p=thirdparty%2Fntp.git Support for multiple Autokey identity groups from Dave Mills bk: 4d198548vegt3M3AZyWZOOUr1PwHkg --- diff --git a/ChangeLog b/ChangeLog index 77c653dc8..48e56a33d 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,5 @@ +* 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 * Add ntpq pstats command similar to ntpdc's. diff --git a/html/autokey.html b/html/autokey.html index 4ecb42ed5..73ce147c8 100644 --- a/html/autokey.html +++ b/html/autokey.html @@ -16,7 +16,7 @@

Autokey Public-Key Authentication

Last update: - 24-Dec-2010 5:45 + 24-Dec-2010 15:06 UTC

@@ -96,54 +96,19 @@ the algorithm must be ether SHA or SHA1. The Autokey message d

It is possible to configure clients of server grundoon.udel.edu in the same way with the server line pointing to grundoon.udel.edu. Dependent clients authenticate to time.nistg.gov through grundoon.udel.edu.

In the above configuration examples, the default Autokey host name is the string returned by the Unix gethostname() 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 -s option of the ntp-keygen program. The default password can be changed using the -p option of the ntp-keygen program and the pw option of the crypto command.

Configuration - Identity Schemes

The example in this section uses the IFF identity scheme. The parent subnet TA generates IFF tidentity files using an ntp-keygen 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 crypto command in the configuration file with no options. In addition, the TH specifies options for the server and ident commands as described in this section.

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

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 ntp-keygen 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 crypto command with no options. In addition, the TH specifies options for the server and ident commands as described in this section.

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

ntp-keygen -I.

Note the TA is not necessarily a trusted host, so may not need the -T option. The nonencrypted client parameters can be exported using the command

ntp-keygen -e >file,

where the -e option redirects the client parameters to file 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

ntp-keygen -q passw2 >file,

where passwd2 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 red. On the other hand, the file name used for the keys file must follow the conventions desdribed on the ntp-keygen page.

To complete the configuration, the TH includes the parameters file name as the ident option on the the server command for the TA assocition

server 1.2.3.4 ident group.

In addtion, if operating as a broadcast/multicast client or a symmmetric passive peer, an ident command is necesary in the configuraiton file

where passwd2 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 red. On the other hand, the file name used for the keys file must follow the conventions desdribed on the ntp-keygen 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.

To complete the configuration, the TH includes the client parameters file name as the ident option of the the server command for the TA assocition

server 1.2.3.4 ident group,

where group is the chosen group name, in this case red. In addtion, if operating as a broadcast/multicast client or a symmmetric passive peer, the TH includes an ident command

ident group,

where group is the name of the file exported with the -e option, in this case is the string red.

Examples

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.

The BLUE TH macabre uses configuration commands

crypto pw qqsv ident blue
- peer mort autokey ident red
- broadcast address autokey

where qqsv is the password for macabre files and address is the broadcast address for the local LAN. 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 keys file. The second generates the public GQ client parameters file, which can have any nonconflicting mnemonic name.

The RED TH mort uses configuration commands

crypto pw xxx ident red
- peer macabre autokey ident blue
- broadcast address 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

The GREEN TH howland uses configuration commands

crypto pw yyy ident green
- broadcastclient ident red blue

where yyy is the password for howland 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 -q zzz >zzz_ntpkey_gqkey_green

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 zzz password.

A client of GREEN, for example YELLOW, uses the configuration commands

crypto pw abc
- server howland autokey ident red

where abc is the password for its files. It generates files using the command

ntp-keygen -p abc

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.

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.

where group is the chosen group name, in this case red.

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 optional 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 @@ -218,7 +183,6 @@ the algorithm must be ether SHA or SHA1. The Autokey message d

* These combinations are not valid if the restriction list includes the notrust option.

Error Codes

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 ntp-keygen - generate public and private keys program.

The following error codes are reported via the NTP control and monitoring protocol trap mechanism and to the cryptostats monitoring file if configured.

diff --git a/include/ntp_control.h b/include/ntp_control.h index 52de472b4..1fe446e1b 100644 --- a/include/ntp_control.h +++ b/include/ntp_control.h @@ -231,7 +231,7 @@ struct ntp_control { #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 */ diff --git a/include/ntpd.h b/include/ntpd.h index d92a7f10b..3b86807c9 100644 --- a/include/ntpd.h +++ b/include/ntpd.h @@ -241,6 +241,7 @@ extern int sys_orphan; 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 *); diff --git a/ntpd/ntp_config.c b/ntpd/ntp_config.c index 10888c813..975156bb2 100644 --- a/ntpd/ntp_config.c +++ b/ntpd/ntp_config.c @@ -3353,7 +3353,7 @@ config_vars( 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 */ diff --git a/ntpd/ntp_control.c b/ntpd/ntp_control.c index e1301d982..f8b93b40c 100644 --- a/ntpd/ntp_control.c +++ b/ntpd/ntp_control.c @@ -208,7 +208,7 @@ static const struct ctl_var sys_var[] = { { 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 */ @@ -245,7 +245,7 @@ static const u_char def_sys_var[] = { CS_LEAPEND, #ifdef AUTOKEY CS_HOST, - CS_GROUP, + CS_IDENT, CS_FLAGS, CS_DIGEST, CS_SIGNATURE, @@ -2118,10 +2118,10 @@ ctl_putsys( 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: diff --git a/ntpd/ntp_crypto.c b/ntpd/ntp_crypto.c index e484fe0c3..2d616a968 100644 --- a/ntpd/ntp_crypto.c +++ b/ntpd/ntp_crypto.c @@ -1617,38 +1617,28 @@ crypto_ident( 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); } @@ -3793,38 +3783,38 @@ crypto_setup(void) } 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_". - */ - 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_". + */ + 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_". - */ - 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_". + */ + 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_". - */ - 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_". + */ + 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. diff --git a/ntpd/ntp_proto.c b/ntpd/ntp_proto.c index 2aaf1cd8a..6ef704d42 100644 --- a/ntpd/ntp_proto.c +++ b/ntpd/ntp_proto.c @@ -90,6 +90,7 @@ keyid_t sys_private; /* private value for session seed */ 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 @@ -840,7 +841,7 @@ receive( 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 */ } @@ -922,7 +923,7 @@ receive( 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 */ @@ -942,7 +943,7 @@ receive( */ 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 */ @@ -1003,7 +1004,7 @@ receive( */ 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 */ }

Autokey Public-Key Authentication

Table of Contents

Configuration - Identity Schemes

Examples

Identity Schemes and Cryptotypes

Error Codes