[ntp:questions] Re: Crypto iffpar
serge.bets at NOSPAM.laposte.invalid
Sun Jan 1 16:08:13 UTC 2006
On Sunday, January 1, 2006 at 4:06:14 +0000, Danny Mayer wrote:
> Serge Bets wrote:
>> why IFF would succeed with a client symlink, and TC would succeed
>> without? Outside of the 20051002 change?
> IFF works fine without a client symlink.
In my case, without a client symlink on the 20051225 ntp-dev client, IFF
is not selected, IFF key is not loaded, there is no IFF bit in default
flags, no IFF bit in cryptostats flags, and no IFF bit in association
flags. The server is authenticated via TC scheme, becomes reachable, and
will work very well like that.
Same setup, but with an additional client symlink ntpkey_iff_Client,
pointing to ntpkey_IFFkey_Server.3340702253, or alternatively with an
additional "crypto ident iff" statement: IFF works fine.
Clients are Windows or Linux, with daemon version 20051002 or more
recent (tested up to 20051225). Server platform and daemon version
seemingly don't count. It is fully repeatable.
Thanks to an old hint from you Danny, I removed a typo letter from
ntp_proto.c and became able to compile 20051002 on Woody. Check confirms
Linux is touched, and snapshot 20051002 is the initial version.
So far I do not see anything that could explain such TC/IFF discrepency,
out of the 20051002 change.
> I have no idea what a strict client setup is.
In this thread context, Steve and me have agreed to use the "strict
client" expression for:
- An ntpd that is configured only as a client member of a trust group
and does not serve authenticated time to others. Configured exactly as
per ConfiguringAutokey section 6.6.2.
More precisely a strict client has an untrusted cert, and an IFFkey
ntpkey_IFFkey_Server.3340702253 file imported from Server, with an
ntpkey_iff_Server symlink pointing to it. Essentially it has not any
IFFpar at all.
Serge point Bets arobase laposte point net
More information about the questions