[ntp:questions] Re: Crypto iffpar

Serge Bets serge.bets at NOSPAM.laposte.invalid
Wed Dec 7 15:57:23 UTC 2005


Hello David,

 On Wednesday, December 7, 2005 at 1:42:21 +0000, David L. Mills wrote:

> Serge Bets wrote:
>> What is the best way to know for sure which scheme is in use?
> Look at the flags word on the association billboard. The bits are
> decoded in the ./include/ntp_crypto.h file. Look also in the
> cryptostats filegen file, assuming you have one.

Much thanks for your reply. So it is definitely TC. The association's
flags=0x87f03, where 03 means crypto enabled, leapseconds table loaded,
and no specific identity scheme (so default TC). The 7f part means all
verified of public key, identity, signature, cookie, autokey,
certificate, and leapseconds table. All OK. And the cryptostats I had
quoted confirms no IFF key was ever loaded.


>>| cert="Client Server 0x6", expire=200611060128,
>>| cert="Server Server 0x7", expire=200610111252,
>>| cert="Client Client 0x6", expire=200611052220
>>| [assoc:] hostname="Server", trust="Server"
> You certificates don't look valid to me, unless you have a trusted
> server with name corresponding to the issuer name. Ordinarily, you
> would have to construct those certficates by hand.

Good: Server has a trusted certificate with subject and issuer both set
to its hostname. It was done as per ConfiguringAutokey instructions, on
Server with:

| # cd /etc/ntp/keysdir
| # ntp-keygen -T -I -p password

We are in the simplest case: One strict client, one trusted server, one
trusted group, unicast.


Now the point is: To activate IFF scheme, I make on Client a copy (no
symlinks on Win32) of the group IFF key to the name ntpkey_iff_Client,
and restart the daemon. Bingo: Assoc flags=0x87f23 meaning IFF identity
scheme, and cryptostats confirms IFF key was loaded twice:

| $ cat //Client/ntpstats/cryptostats.20051206
| 53710 71663.535 192.168.7.10 newpeer 34767
| 53710 71665.499 ntpkey_RSAkey_Client.3342810008 mod 512
| 53710 71665.503 ntpkey_IFFkey_Server.3340702253 mod 384
| 53710 71665.652 ntpkey_RSA-MD5cert_Client.3342810008 0x0 len 309
| 53710 71665.722 update ts 3342887665
| 53710 71665.722 refresh ts 3342887665
| 53710 71667.375 192.168.7.10 flags 0x80023 host Server signature md5WithRSAEncryption
| 53710 71669.462 update ts 3342887669
| 53710 71669.463 192.168.7.10 cert Server 0x7 md5WithRSAEncryption (8) fs 3340702253
| 53710 71671.337 ntpkey_IFFkey_Server.3340702253 mod 384
| 53710 71671.468 192.168.7.10 iff fs 3340702253
| 53710 71673.378 192.168.7.10 cook 1da7fbf6 ts 3342887673 fs 3342886428
| 53710 71675.463 update ts 3342887675
| 53710 71675.464 192.168.7.10 sign Server 0x6 md5WithRSAEncryption (8) fs 3342810008
| 53710 71677.413 update ts 3342887677
| 53710 71677.413 192.168.7.10 leap 96 ts 3342886428 fs 3331497600
| 53710 71699.474 update ts 3342887699
|
| $ ls -l //Client/c\$/Program\ Files/NTP/etc/ntp.keysdir/
| total 4
| -rw-r--r--    1 Administ None          538 Dec  5 23:20 ntpkey_cert_Client
| -rw-r--r--    1 Administ None          616 Dec  5 23:20 ntpkey_host_Client
| -rw-r--r--    1 Administ None          507 Dec  5 23:15 ntpkey_iff_Client
| -rw-r--r--    1 Administ None          507 Dec  5 23:15 ntpkey_iff_Server

Conclusion: A link or file ntpkey_iff_Client (or "crypto ident iff") is
necessary on Client to activate the IFF identity scheme.

The same requirement goes for ntpkey_{gq,mv}_Client. But for those 2
schemes, it's clearly documented in keygen.html with Alice/Bob examples,
so I guess it's not questionable.


I seem to hear loud disagreement. Especially seeing how some accurate
informations disapeared today from the *Dev page. And how a certain MX
treats my private replies. Call me a spammer, Steve. Come on.


Thankfully, Serge.
-- 
Serge point Bets arobase laposte point net




More information about the questions mailing list