[ntp:questions] Re: Crypto iffpar

Serge Bets serge.bets at NOSPAM.laposte.invalid
Sat Dec 24 12:48:20 UTC 2005


 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. 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:

 - TC/IFF success confusion: False.
 - Denied existence of ntpkey_iff_client symbolic link (pointing to any
IFF group key): Once true, but not later.
 - "Omitted" presence of the ntp.conf command: False.
 - Ident leaking from multicast to unicast. Very unlikely.
 - Something special in certificate creation: False.
 - Hosts multi-named: False.
 - Specificity of Debian packages: False.
 - Specificity of 4.2.0a-stable: Yes.
 - 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.


> Also see the following newsgroup messages: [need ntpkey_iff_issuer]

Everybody always agreed on that. That's not the debate.


> Try setting Autokey+IFF/GQ/MV up a Linux or FreeBSD client and I think
> you'll find that Support.ConfiguringAutokey _is_ correct.

I'll get back a spare machine next week, and will try to install the
just released Sarge r1. But I can already guess the result as I could
compare the source of 4.2.0a-stable and ntp-dev-4.2.0b-20051208: The
assoc ident bits management differs. Guess: IFF will work as you,
without client link.


> ntp0 is a Soekris NET4801 which runs FreeBSD 5.3-Release with
> ntp-dev-4.2.0a-20050628

Thanks! Stupid me: I managed to miss the fact that externally visible
ntp0 is not ntp0 but Rover.


> On Linux and FreeBSD the type of association does not affect the
> 'Autokey Dance'.

That's wrong. The Paso Doble is different depending on the association
type, on any platform. Luke at the source code. Look at your own
cryptostats. But differences shouldn't affect ident selection, I think,
so are not relevant to the main debate.


>> you miss the flaw.
> Flaw? It has been repeatedly demonstrated that no client symlink is
> necessary on Linux and FreeBSD.

I have seen on your side one hands on experience, repeatedly stated and
restated. True experience, granted, but not universally true.

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... More than enough to at
least suspect a problem may exist in the Twiki. And begin serious
investigations. But each time you restated: "All is well! All is well!
Follow the instructions, and all will be well".


> 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 real opposition is stable
against dev, or 4.2.0a against 4.2.0b, or some such.


>> Why this difference with The Only True Official Docs?
> Because my experience

Would you say that TOTOD are wrong, or would you say that TOTOD make
sure all daemon versions do work?


> I have reconfigured stasis for an unicast association, authenticated
> with Autokey/GQ, with another system.

OK: This 4th cryptostats looks good, and is convincing. Thank you.
Happy Christmas, Steve: You are (partly) right. :-)


Serge.
-- 
Serge point Bets arobase laposte point net




More information about the questions mailing list