Autokey Public-Key Authentication

Last update: 19-Dec-2010 22:23 UTC


Table of Contents


Introduction

This distribution includes support for the Autokey public key algorithms and protocol specified in RFC-5906 "Network Time Protocol Version 4: Autokey Specification". This support is available only if the OpenSSL library has been installed and the --enable-autokey option is specified when the distribution is built.

Public key cryptography is generally considered more secure than symmetric key cryptography. Symmetic key cryptography is based on a shared secret key which must be distributed by secure means to all participats. Public key cryptography is based on a private secret key known only to the originator and a public key known to all participants. A recipient can verify the originator has the correct private key using the public key and any of several digital signature algortihms.

The Autokey Version 2 protocol described on the Autokey Protocol page verifies packet integrity using message digest algorithms, such as MD5 or SHA, and verifies the source using any of several digital signature schemes, such as RSA or DSA. As used in Autokey, message digests are exceptionlly difficult to cryptanalyze, as the keys are used only once.

Optional identity schemes described on the Autokey Identity Schemes page are based on cryptographic challenge/response exchanges. Optional identity schemes provide strong security against masquerade and most forms of clogging attacks. These schemes are exceptionally difficulat to cryptanalyze, as the challenge/response exchange data are used only once. They 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 IP 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 and clients are operated outside firewall perimeters.

Auokey is designed to authenticate servers to clients, not the other way around as in SSH. An Autokey server can support an authentication scheme such as the Trusted Certificate (TC) scheme described in RFC 5905, whle a client is free to choose between the various options. It is important to understand that these provisions are optional and that selection of which option is at the discretion of the client. If the client does not require authentication, it is free to ignore it, even if some other client of the same server elects to participate in either symmetric key or public key cryptography.

Autokey uses industry standard X.509 public certificates, which can be produced by commercial services, utility programs in the OpenSSL software library, and the ntp-keygen utility program in the NTP software distribution. A certificate includes the subject name of the client, the issuer name of the server, the public key of the server and the time period over which the the server public and private keys are valid. All Autokey hosts have a self-signed certificate with the Autokey name as both the subject and issuer. During the protocol, additional certificates are produced with the Autokey host name as subject and the host that signs the certificate as issuer.

There are two timeouts associated with the Autokey scheme. The key list timeout is set by the automax command, which specifies the interval between generating new key lists by the client. The default timeout of about 1.1 hr is appropriate for the majority of configurations and ordinarily should not be changed. The revoke timeout is set by the revoke command, which specifies the interval between generating new server private values. It is intended to reduce the vulnerability to cryptanalysis; however, new values require the server to encrypt each client cookie separately. The default timeout of about 36 hr is appropriate for most servers, but might be too short for national time servers.

Autokey Subnets

An Autokey subnet consists of a collection of hosts configured as an acyclic, directed tree with roots one or more trusted hosts (THs) operating at the lowest stratum of the subnet. The THs are synchronized directly or indirectly to national time services via trusted means, such as radio, satellite or telephone modem, or an NTP secure group as described in the next section. Autokey hosts operate as servers, clients or both at the same time.

A certificate trail is a sequence of certificates, each signed by a host one step closer to the THs and terminating at the self-signed certificate of a TH. In general, NTP servers operate as certificate authorities (CAs) to sign certificates provided by its clients. The CAs include the THs and those group servers with dependent clients. In order for the signature to succeed, the client certificate valid period must begin within the valid period of the server certificate. If the server period begins later than the client period, the client certificate has expired; if the client period begins later than the server period, the server certificate has expired. While the certificate trail authenticates each host on the trail to the THs, it does not validate the time values themselves. Ultimately, this is determined by the NTP on-wire protocool.

The requirement that the NTP subnet be acyclic means that, if peers are configured with each other in symmetric modes, each must be a TH.

The Autokey protocol runs for each association separately. During the protocol the client recursively obtains all the certificates on the trail to a TH, saving each in a cache ordered from most recent to oldest. If an expired certificate is found, it is invalidated and marked for later replacement. As the client certificate itself is not involved in the certificate trail, it can only be declared valid or expired when the server signs it.

The certificates derived from each association are combined in the cache with duplicates suppressed. If it happens that two different associations contribute certificates to the cache, a certificate on the trail from one association could expire before any on another trail. In this case the remaining trails will survive until the expired certificate is replaced. Once saved in the cache, a certificate remains valid until it expires or is replaced by a new one.

It is important to note that the certificate trail is validated only at startup when an association is mobilized. Once validated in this way, the server remains valid until it is demobilized, even if certificates on the trail to the THs expire.

Example

gif

Figure 1. Example Configuration

Figure 1 shows an example configuration with three NTP subnets, Alice, Helen and Carol. Hosts A and B are THs of Alice, host R is the TH of Helen and host X is the TH of Carol. Assume that all associations are client/server; so, for example, TH X has two mobilized associations, one to Alice host C and the other to Carol host S. While not shown in the figure, Alice hosts A and B could configure symmetric mode associations between them for redundancy and backup.

Note that host D cetificate trail is D→C→A or D→C→B, depending on the particular order the trails are built. Host Y certificate trail is only Y→X, since X is a TH. Host X has two cetficate trails X→C→A or X→C→B, and X→S→R.

NTP Secure Groups

NTP security groups are an extension of the NTP subnets described in the previous section. They include in addition to certificate trails one or another identity schemes described on the Autokey Identity Schemes page. NTP secure groups are used to define cryptographic compartments and security hierarchies. The identity scheme insures that the server is authentic and not victim of masquerade by an intruder acting as a middleman.

As in NTP subnet, NTP secure groups are configured as an acyclic tree rooted on the THs. The THs are at the lowest stratum of the secure group; they and possibly other hosts in the group run the identity exchange. All group hosts construct an unbroken certificate trail from each host, possibly via intermediate hosts, and ending at a TH of that group. The TH verifies authenticity as a client of a serverin another group.

For secure group servers, the string specified by the -i option of the ntp-keygen program is the name of the secure group. For secure group servers this name must match the ident option of the crypto command. For secure group clients, this name must match the ident option of the server command. This name is also used in the identity keys and parameters file names. The file naming conventions are described on the ntp-keygen page.

In the latest Autokey version, the host name and group name are independent of each other and the host option of the crypto command is deprecated. When compatibility with older versions is required, specify the same name for both the -s and -i options.
gif

Figure 2. Identify Scheme

As shown in Figure 2, an Autokey identity scheme involves a challenge-response exchange where a client generates a nonce and sends to the server. The server performs a mathematical operation involving a second nonce and the secret group key, and sends the result along with a hash to the client. The client performs a another mathematical operation and verifies the result with the hash.

Since each exchange involves two nonces, even after repeated observations of many exchanges, an intruder cannot learn the secret group key. It is this quality that allows the secret group key to persist long after the longest period of certificate validity. In the Schnorr (Identify Friend or Foe - IFF) scheme, the secret group key is not divulged to the clients, so they cannot conspire to prove identity to other hosts.

As described on the Autokey Identity Schemes page, there are five identity schemes, three of which - IFF, GQ and MV - require identity files specific to each scheme. There are two types of files for each scheme, an encrypted server keys file and a nonencrypted client keys file, also called the parameters file, which usually contains a subset of the keys file.

Figure 2 shows how keys and parameters are distributed to servers and clients. Here, a TH constructs the encrypted keys file and the nonencrypted parameters file. Hosts with no dependent clients can retrieve client parameter files from an archive or web page. The ntp-keygen program can export parameter files using the -e option. Servers with dependent clients other than THs must retrieve copies of the server keys file using secure means. The ntp-keygen program can export server keys files using the -q option and chosen remote password. In either case the files are installed and then renamed using the name given as the first line in the file, but without the filestamp.

Example

Returning to the example of Figure 1, Alice, Helen and Carol run TC, internally, as the environment is secure and without threat from external attack, in particular a middleman masquerade. However, TH X of Carol is vulnerable to masquerade on the links between X and C and between X and S. Therefor, both C and S are configured as Autokey servers with, for example, the IFF identity scheme, and X as a client of both of them. For this purpose, both C and S export their IFF parameter files to X as described above.

Configuration - Authentication Schemes

Autokey has an intimidating number of options, most of which are not necessary in typical scenarios. However, the Trusted Certificate (TC) scheme is recommended for national NTP time services, such as those operated by NIST and USNO. Configuration for TC is very simple. For each server, e.g. time.nist.gov, as root:

# cd /usr/local/etc
# ntp-keygen -T

This generates an RSA private/public host key file and a self-signed certificate file for the RSA digital signature algorithm with the MD5 message digest algorithm. Include in the ntp.conf configuration file something like

# disable kernel
# server 127.127.18.1 minpoll 12 maxpoll 17 # ACTS modem
# phone atdt913035547785 atddt913034944774
# crypto
# driftfile /etc/ntp.drift

Note the first three lines are specific to the ACTS driver and NIST modem telephone numbers. The second number will be tried if the first times out. Alternatively, any other reference clock can be used, or even another time server.

For each client, e.g. grundoon.udel.edu, as root:

# cd /usr/local/etc
# ntp-keygen

(There is no -T option). Include in the ntp.conf configuration file something like

# server time.nist.gov iburst autokey
# crypto
# driftfile /etc/ntp.drift

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

For the simplest identity scheme TC, the server generates host keys, trusted certificate and identity files using an ntp-keygen program commadn with options specified in this section, while the clients use the same command with no options. The server uses the crypto command in the comnfiguration file with options specified in this section, while the clients use the same command with no options. Additonia client options are specified in the server command for each association.

It's best to start with a functioning TC configuation and add commands as necessary. For example, the CA generates an encrypted server keys file using the command

ntp-keygen -I -i group,

where group is the group name used by all hosts in the group. This and following commands can be combined in a single command. 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. 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. In either case the file is installed under the name found in the first line of the file, but converted to lower case and without the filestamp

As in the TC scheme, the server includes a crypto command in the configuration file with the ident group option. The crypto command in the client configuration file is unchanged, but the server command includes the ident group option.

In special circumstances the Autokey message digest algorithm can be changed using the digest option of the crypto command. The digest algorithm is separate and distinct from the symmetric key message digest algorithm. If compliance with FIPS 140-2 is required, the algorithm must be ether SHA or SHA1. The Autokey message digest algorithm must be the same for all participants in the NTP subnet.

Examples

gif

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.

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 configured using more than one cryptotype combination, although not all combinations are interoperable. Note however that some cryptotype combinations may successfully intemperate 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.

 

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.

101 bad field format or length
The packet has invalid version, length or format.
102 bad timestamp
The packet timestamp is the same or older than the most recent received. This could be due to a replay or a server clock time step.
103 bad filestamp
The packet filestamp is the same or older than the most recent received. This could be due to a replay or a key file generation error.
104 bad or missing public key
The public key is missing, has incorrect format or is an unsupported type.
105 unsupported digest type
The server requires an unsupported digest/signature scheme.
106 unsupported identity type
The client or server has requested an identity scheme the other does not support.
107 bad signature length
The signature length does not match the current public key.
108 signature not verified
The message fails the signature check. It could be bogus or signed by a different private key.
109 certificate not verified
The certificate is invalid or signed with the wrong key.
110 host certificate expired
The old server certificate has expired.
111 bad or missing cookie
The cookie is missing, corrupted or bogus.
112 bad or missing leapseconds table
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.
115 protocol error
The protocol state machine has wedged due to unexpected restart.

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.