[ntp:questions] Re: autokey setup with GQ Identity Scheme
David L. Mills
mills at udel.edu
Tue Jun 6 00:41:27 UTC 2006
Steve,
Further to my last: Remember, there must be a valid certificate trail
from every dependent host to a host with trusted, self-signed
certificate. This could be a problem in moderate to large subnets
running in symmetric modes to enhance reliability. If the trusted host
fails, nothing works. It is possible to have more than one trusted host,
but all group hosts need the keys for all of them.
Having said that, how about making all peers trusted and all have all
the keys for. Actually, this is no better and no worse than using the PC
scheme, which itself is no better and no worse than symmetric keys.
Dave
user at domain.invalid wrote:
> Steve,
>
> Very thorough. This of course is the acid test for Autokey - symmetric
> modes and something other than IFF. GQ does have a few quirks, as the
> public group key is embedded in the certificate extension field. If you
> watch the protocol exchange with the -d trace, you might get a surprise.
> The protocol is awesome, as the passive peer has first to authenticate
> the active one, then the active peer has to authenticate the passive
> one. It takes several minutes. Don't use iburst; that really confuses
> the protocol.
>
> The acid test is, once the peers have completed the dance and packets
> have only the MAC, restart one of the peers and verify the protocol
> recovers, then restart the other peerb and verify the protocol recovers.
> Note that restarting the active peer forces the passive one to
> demobilize and then remobilize. Awesome.
>
> Dave
>
> Steve Kostecke wrote:
>
>> 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.
>>
>
More information about the questions
mailing list