On 2005-12-24, Serge Bets <[EMAIL PROTECTED]> wrote: > On Friday, December 23, 2005 at 5:23:37 +0000, Steve Kostecke wrote: > >> On 2005-12-22, Serge Bets <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> NTP Public Services Project - http://ntp.isc.org/ _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
