[ntp:hackers] ntp Authentification support for X.509v3
againstaCertificate Authority (CA)
David L. Mills
mills at udel.edu
Thu Jun 22 18:47:05 UTC 2006
Erek,
Good questions, but maybe some misunderstanding of the method.
Plan A. Remember, the goal in the original project was that it be
completely self-sustained without external infrastructure services, but
to be configurable in case ifrastructure services were required.
In the default design every host rolls its own certificate and requests
as part of the protocol that the immediate ascending host sign it before
it can be provided to immediate descendent hosts. The proof that the
signature is authentic is in the zero-knowledge-proof identity exchange.
The identity is confirmed by induction to the trusted host that rolled
the group key.
This works fine in sensor nets without ifrastructure services and, I
will argue, in the general case where you can't trust anybody's clock
until the clock has been set from a proventic source. See the notion of
filestamps and timestamps and the required partial order in the
technical report. This is intended to apply to the world at large. This
is probably not what you had in mind.
Plan B. Certificates and CAs and validation services are provided by
external infrastructure. NTP does nothing in and of itself to provide
these services, only to hike the trail and to determine when
certificates have been revoked or expired. It already does that when a
ceertificate expires. Assuming revocation can be added to NTP, this
works, too. In this case there is no need to have an identity exchange
or have a certificate signed to become valid. This is what the TC scheme
was designed for, although the trick to identify the trusted host might
not conform to reality.
Now, ask carefully what the certificate is for. It is to facilitate the
inititial acquisition of a proventic source by induction on the path to
the trusted host. After that the acquired credentials and autokey
sequence proventicate the source. Certificates are loaded when the
daemon starts and then held in memory as long as the daemon is running.
It can and has happened that a certificate expires while the daemon is
running and some dependent host attempts to light up. This of course
fails and the only recourse at present is to restart the daemon. This is
a good idea anyway, as the intent is to refresh the credentials rather
often. There are other ways to do this, of course, and remain for future
refinements.
Dave
Laatz, Erek wrote:
> Dear all,
>
> that was a very encouraged discussion last night, thank you for your kind
> support! Due to a long meeting in the morning it was impossible for me to
> answer earlier:-(
>
> Let me give a short summary of what I've learned in this discussion:
> - Dave links to the stime.pdf paper, where the infrastructure modell is
> referenced. But there's no further description on how to realise the
> certificate verification.
>
> - In my understanding, I have to do the following:
> + create my own host certificate,
> + let it sign by the public CA,
> + use it in my trusted host.
> As Dave wrote, presumably the certificate trail will be extended up
> to the CA. Does it mean, it was not tested before?
>
> - Usually a certificate verification against a CA will be done using
> OCSP or LDAP protocol connected to a X.500 directory.
> Both protocols will not contain into the NTP sources (4.2.0 at 1.116).
> Dave wrote that there's no reason why OCSP could not be used...
> That means (IMHO), that OCSP should work. But how? Would that be done
> by the linked OpenSSL libraries? Ehst about LDAP access?
>
> - If PKIX was required, very minor modifications have to be made in the
> certificate extension fields. I think that might be the URL to the CA,
> e.g. ocsp://ca-root.foo.bar. Do you agree?
>
> - Greg worte, that there has to exist a scheme allowing an external
> certificate veerification. Would that actually handled ba OpenSSL?
>
> - In his last mail Dave relates to the TC scheme but even told us that
> public infrastructure procedures and resources are not specified as
> intended.
>
> Now I'm a little confused... Does it mean that certificate verification
> against a CA is even impossible or not?!..!
>
> Best regards, yours
>
> Erek
>
>
>
> David L. Mills schrieb:
>
>>Greg,
>>
>>The TC scheme described in the briefing, book and technical report, but
>>it was not intended to be secure, as the text says. The public
>>infrastructure procedures and resources are not specified as intended.
>>If there is serious interest in doing just that, I would be most happy
>>if somebody else worked out what needs to be done; I am preoccupied with
>>other aspects of the work.
>>
>>By the way, I caught in one version of your latest product description
>>that the unit supported public key cryptography. Is this true? I got a
>>question about this from my BlueCrossBlueShield consulting clients.
>>
>>Dave
>>
>>Dave
>>
More information about the hackers
mailing list