[ntp:questions] Re: Crypto iffpar
kostecke at ntp.isc.org
Fri Dec 23 05:23:37 UTC 2005
On 2005-12-22, Serge Bets <serge.bets at NOSPAM.laposte.invalid> wrote:
> On Wednesday, December 21, 2005 at 13:54:56 +0000, Steve Kostecke wrote:
>> Perhaps _you_ need to use an ntpkey_iffkey_client sym-link, or a
>> 'crypto iff...' directive, to force _your_ ntpd to use the IFF
>> Identity Scheme. I, on the other hand, don't.
> According to the source code, it must be ntpkey_iff_client, and
> "crypto ident iff".
Really? Then explain why all my systems which are running Autokey+IFF
(various versions of ntpd on both Linux and FreeBSD) work just fine
without the ntpkey_iff_client symlink.
Also see the following newsgroup messages:
| Message-ID: <dnfing$pqh$1 at dewey.udel.edu>
| In the expected naming scheme the name of the group key is the name of
| the subject on the trusted certificate held by the trusted host. You
| need a symlink only to truncate the filestamp.
| Message-ID: <dnt4pb$kpe$1 at dewey.udel.edu>
| The issuer or subject name on the trusted certificate denotes a file
| on the client with the name ntpkey_iff_<trusted host name> and you get
| to make that happen by providing the file and link to it with that
> The symlink variant with "key" (as "ntpkey_mvkey_client") is a typo in
> the keygen.html doc. And the commands "crypto iff|gq|mv" don't exist,
> they are also doc typos, in authopt.html this time. In doc versions
> live from the web.
I referred to the Official Docs as a _guide_ when I performed the
testing used in the creation of Support.ConfiguringAutokey. Then I
verfied each step.
>> This suggests to me that something on your end is broken. Perhaps it's
>> your OS or perhaps it's the version of ntpd that you're using.
> Unlikely, but possible: I'm investigating. BTW I upgraded both versions:
> Now Linux Server runs ntp-dev-4.2.0b-20051208.tar.gz, while Win2k Client
> runs ntp-dev-4.2.0b-20051105-nt.zip from Terje Mathisen.
As I've stated before, Support.ConfiguringAutokey is based on my
experience with Linux and FreeBSD systems. I don't use Windows and,
therefore, can't test ntpd on it.
Try setting Autokey+IFF/GQ/MV up a Linux or FreeBSD client and I think
you'll find that Support.ConfiguringAutokey _is_ correct.
> IIANM you run 4.2.0a at 1:4.2.0a+stable-2-r (Debian Sarge?) on server
ntp0 is a Soekris NET4801 which runs FreeBSD 5.3-Release with
> and what on client Stasis?
stasis is a Debian box with ntpd 4.2.0a at 1:4.2.0a+stable-2-r
> Odd not about certs. But about "newpeer" line only coming after 30
> seconds, instead of startup. And the "auto" line. Never had this with
> "server Server autokey". What is it? Incoming broadcast, incoming
> symmetric active packet, ...?
Stasis is usually a multicastclient and I had converted it to unicast
for the previous test; this time I didn't. On Linux and FreeBSD the type
of association does not affect the 'Autokey Dance'.
>> I know what works on all of the systems that I've configured to use
> You keep repeating that all is well in ConfiguringAutokey, and that
> it's hands on experience.
It _is_ based on my experience configuring Autokey with IFF, GQ, and MV
in various combinations. I've even had one system running all three
Identity Schemes at the same time.
I didn't just regurgitate some existing documentation.
> Without really looking at the contrary arguments. Unfortunately this
> closed position makes you miss the flaw.
It has been repeatedly demonstrated that no client symlink is necessary
on Linux and FreeBSD.
Perhaps a client symlink is necessary on Windows. But I have no way of
verifying this fact and would consider it to be a bug.
> Another argument about GQ identity scheme. The official documentation
> http://www.eecis.udel.edu/~mills/ntp/html/keygen.html states:
<snip: You need an ntpkey_gq_client symlink>
> While ConfiguringAutokey on the Twiki states:
<snip: All you need is the ntpkey_gq_client symlink>
> Why this difference with The Only True Official Docs?
Because my experience configuring Autokey with the GQ Identity Scheme
has demonstrated that no client symlink is necessary.
For this article I have reconfigured stasis for an unicast association,
authenticated with Autokey/GQ, with another system.
Test Client: stasis (Debian GNU/Linux)
Test Server: imp (FreeBSD 5.3-Release)
Client ntp.conf (abridged):
(drift file and stats elided)
crypto pw <.......>
server 192.168.19.69 iburst autokey
(other unauthenticated servers elided)
ntpkey_cert_stasis -> ntpkey_RSA-MD5cert_stasis.3343787146
ntpkey_host_stasis -> ntpkey_RSAkey_stasis.3343787146
ntpkey_gq_imp.kostecke.net -> ntpkey_GQpar_imp.kostecke.net.3344301291
Client 'ntpq -pcas':
remote refid st t when poll reach delay offset jitter
*imp.kostecke.ne 192.168.19.4 2 u 58 64 377 0.497 -0.184 0.132
ind assID status conf reach auth condition last_event cnt
1 59540 f614 yes yes ok sys.peer reachable 1
Client 'ntpq -c"rv 59540 flags"':
assID=59540 status=f614 reach, conf, auth, sel_sys.peer, 1 event, event_reach,
53727 16712.382 192.168.19.69 sign imp.kostecke.net 0x3 \
md5WithRSAEncryption (8) fs 3343787146
53727 16940.924 192.168.19.69 newpeer 59540
53727 16940.940 ntpkey_RSAkey_stasis.3343787146 mod 512
53727 16940.941 ntpkey_RSA-MD5cert_stasis.3343787146 0x0 len 311
53727 16941.831 refresh ts 0
53727 16941.832 192.168.19.69 flags 0x80041 host imp.kostecke.net \
53727 16943.834 192.168.19.69 cert imp.kostecke.net 0x3 \
md5WithRSAEncryption (8) fs 3344301291
53727 16945.831 ntpkey_GQpar_imp.kostecke.net.3344301291 mod 512
53727 16945.936 192.168.19.69 gq fs 3344301291
53727 16947.856 192.168.19.69 cook 21f7ee7 ts 3344301747 fs 3344301358
53727 16950.844 update ts 3344301750
53727 16951.887 update ts 3344301751
53727 16951.887 192.168.19.69 sign imp.kostecke.net 0x3 \
md5WithRSAEncryption (8) fs 3343787146
Steve Kostecke <kostecke at ntp.isc.org>
NTP Public Services Project - http://ntp.isc.org/
More information about the questions