[ntp:questions] Re: Crypto iffpar

Steve Kostecke kostecke at ntp.isc.org
Sat Dec 17 06:17:28 UTC 2005

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

>  On Saturday, December 10, 2005 at 1:44:39 +0000, Steve Kostecke
>  wrote:
>>> You have a ntpkey_iff_stasis
>> No. I really don't
> Trace of loading ntpkey_iff_stasis at startup is visible in the 3rd
> line of your original cryptostats. It points to own IFF parameters of
> Statis. This 3rd line was:
>>>>>> 53712 65898.557 ntpkey_IFFpar_stasis.3342803910 mod 384

This line is from the cryptostats extract which I posted in message
slrndph05q.9at.kostecke at stasis.kostecke.net

In that message I omitted the fact that the client, _at_ _that_ _time_,
had an IFFpar file so that it could serve authenticated time to another
system. The existence of this IFFpar file is the reason why the line
cited above appeared in cryptostats.

The results in slrndph05q.9at.kostecke at stasis.kostecke.net have been
superceded by the results in slrndpkco7.cvv.kostecke at stasis.kostecke.net

> You claim to not have seen it, and repost another cryptostats for
> review.

I reconfigured my test client to be a "strict client" (to use your
terminology) prior to generating the results posted in my message
slrndpkco7.cvv.kostecke at stasis.kostecke.net

> But this important line lacks in repost...

That's because, in the "strict client" configuration, the test client no
longer had the IFFpar file it its keysdir.

> One more thing to oportunely disapear from this discussion.

Opportune disappearance? Next you'll be telling me about the black
helicopters circling overhead.

>> You may be confused by the fact the one of my sets of results was
>> generated while stasis was configured to serve authenticated time to
>> a third host.
> The problem I raised does not apply at all in "autokey both client and
> server" case. Everything works, both for you and me. This is not the
> case of ConfiguringAutokey on "strict client" side.

Really? Every single 'strict client' ntpd I have using Autokey+IFF has
been configured as described* in ConfiguringAutokey. And they _all_ work.

( * There is an exception here, although most of the client parameters
( were generated without '-T', there were a few cases where I did use
( '-T'. However, this has no effect on making Autokey work other than
( changing the status values (e.g. the ones you mention below)

>> 53714 4726.055 ntpkey_RSA-MD5cert_stasis.3342803910 0x2 len 333
> What means this 0x2 at certificate loading? I get only 0x0 on client,
> and 0x1 (meaning trusted cert) on server cryptostats.

This information is documented in stime.pdf

| SIGN 0x01
| The certificate signature has been verified. If the certificate is
| self-signed and verified using the contained public key, this bit
| will be lit when the CIS is constructed.
| TRST 0x02
| The certificate has been signed by a trusted issuer. If the
| certificate is self-signed and contains "trustRoot" in the Extended
| Key Usage field, this bit will be lit when the CIS is constructed.

0x0 indicates an untrusted host cert; the bits are not set when the cert
is loaded. This cert may be signed later by a trusted server, then the
bits are set to 0x3.

Here's yet another extract. For this one I regenerated the client
parameters with 'ntp-keygen -H -p .....' to make sure that we're using
"strict client" host parameters.

| 53721 20760.546 ntpkey_RSAkey_stasis.3343787146 mod 512
| 53721 20760.548 ntpkey_RSA-MD5cert_stasis.3343787146 0x0 len 311

There's that 0x0 ... this an untrusted host cert. It will be signed

| 53721 20761.401 refresh ts 0
| 53721 20767.413 update ts 3343787167
| 53721 20784.972 newpeer 15558
| 53721 20784.972 flags 0x80021 host ntp0.kostecke.net \
| 	signature md5WithRSAEncryption
| 53721 20786.427 update ts 3343787186
| 53721 20786.427 cert ntp0.kostecke.net 0x3 \
| 	md5WithRSAEncryption (8) fs 3315100165

The server certificate was loaded.

The parameters for ntp0 were generated with '-T'. 0x3 means the
certificate signature has been verified and the certificate has been
signed by a trusted issuer.

| 53721 20788.406 ntpkey_IFFkey_ntp0.kostecke.net.3315100165 mod 384
| 53721 20788.453 iff fs 3315100165

The server IFF key was loaded. Note that the file-stamp on this file
matches the file-stamp on the server certificate.

| 53721 20790.435 cook 69e941c3 ts 3343787190 fs 3343744836
| 53721 20792.413 auto seq 98 key 9d782aa0 ts 3343786604 \
| 	fs 3343744836
| 53721 20794.471 update ts 3343787194
| 53721 20794.471 sign ntp0.kostecke.net 0x3 \
| 	md5WithRSAEncryption (8) fs 3343787146

The client cert has been signed by the server. 0x3 means the
certificate signature has been verified and the certificate has been
signed by a trusted issuer (in this case ntp0).

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

More information about the questions mailing list