[ntp:questions] Re: Crypto iffpar

Steve Kostecke kostecke at ntp.isc.org
Tue Dec 27 04:27:28 UTC 2005


On 2005-12-24, Serge Bets <serge.bets at NOSPAM.laposte.invalid> wrote:

>  On Friday, December 23, 2005 at 5:23:37 +0000, Steve Kostecke wrote:
>
>> On 2005-12-22, Serge Bets <serge.bets at NOSPAM.laposte.invalid> wrote:
>>
>>> According to the source code, it must be ntpkey_iff_client, and
>>> "crypto ident iff".
>>
>> Really?
>
> Double yes. First, I was here correcting spelling, that you had wrong.
> Second, I repeat that functionally it is needed for IFF.

Not. In. My. Experience.

> One month ago I was unsure, and contacted you to discuss it. I am now
> completely sure.
>
>> 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.
>
> I would like to know that. My successive hypothesis about why your
> experience doesn't match reality were:

Your experience does not match my reality.

>  - Specificity of 4.2.0a-stable: Yes.

Wrong. I've tested this behavior on the stable release and _many_
ntp-dev snapshots.

>  - Not thorough testing of ntp-dev: Very likely.
>
> Compile a recent ntp-dev on Stasis. No need to install, just run. You
> will see The Light.

Do you mean that IFF will then no longer work unless I use the 'crypto
ident ...' directive or a client sym-link?

I've built the 051225 ntp-dev snapshot on one of my FreeBSD systems and
found that the IFF Identity Scheme still works without the use of an
ntpkey_iff_client sym-link.

> On my side I've provided my failed and succesfull logs, results of
> many cross checks, tried different explanations, pointed to the rare
> docs talking about that, pointed to the source...

OK ... we'll look at the source:

imp$ cd /usr/local/src/ntp-dev-4.2.0b-20051225
imp$ find . -name '*.c' | xargs grep -l ntpkey
./ntpd/ntp_crypto.c
./util/ntp-keygen.c

We're only interested in ntpd so we'll ignore ntp-keygen.

Examination of ntp_crypto.c shows, as you've pointed out earlier, that
the string 'ntpkey' is used in two subroutines:

* crypto_setup - load keys, certificate and leapseconds table
* crypto_ident - construct extension field for identity scheme

Note: the following commentary makes liberal use of the comments found
in the Reference Implmentation source. Details not germane to this
discussion have been omitted.

crypto_setup determines the current hostname and attempts to:

- Load required host key from file "ntpkey_host_<hostname>".
- Load optional sign key from file "ntpkey_sign_<hostname>".
- Load required certificate from file "ntpkey_cert_<hostname>".
- Load optional leapseconds table from file "ntpkey_leap".
- Load optional IFF parameters from file "ntpkey_iff_<hostname>".
- Load optional GQ parameters from file "ntpkey_gq_<hostname>".
- Load optional MV parameters from file "ntpkey_mv_<hostname>".

This is where the secret parameters for a Trust Group server are loaded
(as "par" files).

It is also possible to trick ntpd on a trust group client to load a
server's "public" parameters at this point by using an ntpkey_iff_client
sym-link to the server's IFFkey file (testing whether or not this also
works with GQ and MV is left as a exercise for the reader).

crypto_ident determines which identity scheme is in use and constructs
an extension field for that scheme. If the server identity has not been
verified an attempt is made to load the identity file of the certificate
issuer:

- Load IFF parameters from "ntpkey_iff_<peer>".
- Load GQ parameters from "ntpkey_gq_<peer>".
- Load MV parameters from "ntpkey_mv_<peer>".

crypto_ident is only called from two places in ./ntpd/ntp_proto.c in the
following manner:

(!(peer->crypto & CRYPTO_FLAG_VRFY))
exten = crypto_args(peer, crypto_ident(peer), NULL);

crypto_ident is where the "public" parameters for a Trust Group server
are intended to be to be loaded.

As stated above, I have observed that it _is_ possible to trick
ntpd in to loading a Trust Group server's "public" parameters, in
crypto_setup(), through the use of a client sym-link.

But I have also observered that, on the Operating Systems I use, is is
not necessary to use a client sym-link. Further, I don't see anything in
the code _requiring_ the existence of a client sym-link to activate an
Identity Scheme.

>> no client symlink is necessary on Linux and FreeBSD. Perhaps a client
>> symlink is necessary on Windows.
>
> Opposing Linux+FreeBSD to Windows was a fair hypothesis, but it is
> false. The source code is the same.

The underlying Operating Systems are _very_ different.

> The real opposition is stable against dev, or 4.2.0a against 4.2.0b,
> or some such.

I've tested this behavior on the stable release and _many_ ntp-dev
snapshots.

> Would you say that [The Official Documentation] are wrong, or would
> you say that [The Official Documentation] make sure all daemon
> versions do work?

I'm not passing judgement on the correctness The Official Documentation.
And I won't be pulled in to that Tiergrube.

What I've done is test the configuration of Autokey _on_ _the_
_Operating_ _Systems_ _at_ _my_ _disposal_ and documented the results,
cook-book style, in the Community Supported Documentation (the current
content of ConfiguringAutokey was initially published on 15 Aug
2004 with only minor updates since then). My rationale for creating
ConfiguringAutokey is documented in Support.ConfiguringAutokeyDev.

I do not disbelieve your claim that _you_ need to use a client sym-link
(or whatever the equivalent is on your OS) to activate Identity Schemes.

However I take issue with your assertion that there is an _error_ in
ConfiguringAutokey because I do not list a "work-around" needed only for
your OS.

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




More information about the questions mailing list