[ntp:questions] Re: autokey setup with GQ Identity Scheme

Steve Kostecke kostecke at ntp.isc.org
Tue May 30 20:59:54 UTC 2006


Jean-Francois Malouin wrote:

> After a few days of reading all sort of doc (mainly
> http://ntp.isc.org/bin/view/Support/ConfiguringAutokey) I have
> convinced myself that I'm missing something crucial in my NTP
> sub-domain setup but I can't put the finger on it... I'll be quite
> happy to give further output/debug to anyone who can help and I 
> appologize if this is too long but it has been a few very frustating
> days...

I ran some tests this afternoon and here's what I learned:

1. You need a "relatively" recent ntp-dev snapshot; it must support the
'crypto ident' configuration option.

2. You must use a shared, or common, password.

3. Generate GQ parameters on each peer:

	ntp-keygen -T -G -p common_password

(append '-q common_password' to the above line if you've already
generated the host parameters.)

4. 'cross copy' the GQPar files between the systems which will be peers
and create the sum-link. In a two peer trust group you would see the
following in each peers' keys dir (in addition to the host parameters):

ntpkey_GQpar_peer1.xxxxxxxxxx
ntpkey_GQpar_peer2.xxxxxxxxxx
ntpkey_gq_peer1 -> ntpkey_GQpar_peer1.xxxxxxxxxx
ntpkey_gq_peer2 -> ntpkey_GQpar_peer2.xxxxxxxxxx

5. In the ntp.conf for each peer:

	* add a 'crypto ident <hostname>' line; where <hostname>
	  is the hostname used in the filename of that system's
	  ntpkey_GQpar_hostname.xxxxxxxxxx file. This line tells ntpd
	  which crypto identity to assume.

	* add a 'peer other_peer_hostname_or_ip_address autokey' line.

6. (Re-)Start both ntpds and _be patient_. Use something like 'watch
-n5 ntpq -pcas' (for each peer) to watch the associations form. If the
authentication is successful you should see the 'other_peer' information
start to appear in the 'ntpq -p' billboard for one of the peers after
1 or 2 poll periods (64 sec) have expired. It may take a few more poll
periods before both peers show an established association. You should
see an 'ok' in the auth column for the 'other peer'.

7. Use ntpq to verify the crypto status. Here's an example:

| steve at stasis:~$ ntpq
| ntpq> as
| 
| ind assID status  conf reach auth condition  last_event cnt
| ===========================================================
|   1 18765  f034   yes   yes   ok     reject   reachable  3
|   2 18766  9014   yes   yes  none    reject   reachable  1
|   3 18767  9614   yes   yes  none  sys.peer   reachable  1

In this case assID 18765 is my Authenticated Peer. So...

| ntpq> ps 18765
| assID=18765 status=f034 reach, conf, auth, 3 events, event_reach,

<snip>

| hostname="rover", signature="md5WithRSAEncryption", flags=0x87f43,
| trust="rover", initsequence=62, initkey=0xc293cd34,
| timestamp=200605302026

The flags shown above (flags=0x87f43) mean the following (see
./include/ntp_crypto.h):

#define CRYPTO_FLAG_ENAB  0x0001 /* crypto enable */
#define CRYPTO_FLAG_TAI   0x0002 /* leapseconds table */
#define CRYPTO_FLAG_GQ    0x0040 /* GQ identity scheme */
#define CRYPTO_FLAG_VALID 0x0100 /* public key verified */
#define CRYPTO_FLAG_VRFY  0x0200 /* identity verified */
#define CRYPTO_FLAG_PROV  0x0400 /* signature verified */
#define CRYPTO_FLAG_AGREE 0x0800 /* cookie verifed */
#define CRYPTO_FLAG_AUTO  0x1000 /* autokey verified */
#define CRYPTO_FLAG_SIGN  0x2000 /* certificate signed */
#define CRYPTO_FLAG_LEAP  0x4000 /* leapseconds table verified */

I've not tested this beyond two peers, so I don't know what will happen
when you add the third.

-- 
Steve Kostecke <kostecke at ntp.isc.org>
NTP Public Services Project - http://ntp.isc.org/




More information about the questions mailing list