[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