[ntp:questions] Re: autokey setup with GQ Identity Scheme
Jean-Francois.Malouin at bic.mni.mcgill.ca
Wed May 31 13:46:05 UTC 2006
* Steve Kostecke <kostecke at ntp.isc.org> [20060530 17:30]:
> 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.
hmmm, that might be part of my problem: right now on these boxes
I have ntp-4.2.0a+stable installed.
> 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_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,
> | hostname="rover", signature="md5WithRSAEncryption", flags=0x87f43,
> | trust="rover", initsequence=62, initkey=0xc293cd34,
> | timestamp=200605302026
> The flags shown above (flags=0x87f43) mean the following (see
> #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.
Thank you Steve for the tips. I'll try that this afternoon and see
what comes up.
> Steve Kostecke <kostecke at ntp.isc.org>
> NTP Public Services Project - http://ntp.isc.org/
> questions mailing list
> questions at lists.ntp.isc.org
More information about the questions