[ntp:hackers] ntp Authentification support for X.509v3againstaCertificate Authority (CA)

David L. Mills mills at udel.edu
Thu Jun 22 19:21:36 UTC 2006


Greg,

Good points, but I reiterate the goals of the project precluded and 
still preclude adoption wholesale of all current PKIX methodology, 
unless the clocks throughout the infrastructure can be trusted. Chicken 
and egg.

The original v1 Autokey v1 has in the public distribution, but 
considered experimental at best. The v2 has been in the public 
distribution for some years, but not compatible with v1. The v2 protocol 
has ben stable for some time, although continued testing has exposed 
(and fixed) a bug or two when operating with incompatible modes.

Some folks indeed complain that MD5 symmetric cryptography (only) is too 
weak. In principle, any scheme supported by the OpenSSL library can be 
dropped in; however, for the moment, MD5 is frozen in the interests of 
compatibility. However, considering even a weak MD5, a determined 
middleman has to do. First, it must intercept the client packet and note 
the transmit timestamp, which is used by the client in the loopback 
test. It's really hard to guess or fabricate that, as the nonsignificant 
transmit timestmap bits are fuzzed. Then it must exploit a birthday to 
fool the client hash. It must succeed in doing this for at least 15 
minutes in order to get past the mitigation algorithms.

The driving issue for the v21->v2 transition was indeed the hazard that 
some jerk middleman might avoid reality and substitute its own. The 
public key is indeed transmitted to the server, who then encrypts the 
cookie with that value. This becomes a little tricky in symmetric modes 
to avoid races.

Your comments about the stime days are valid, but those days have long 
gone and I never did get feedback on the v2 document I circulated. No 
the comments I get are the documents are too overwhelming and folks want 
cookbook. The ISC site cooks.

I don't know the details of your TC scheme, like how you generate keys 
and certificates. Since your box would ordinatily be a primary server, 
it would de facto be trusted. Oops; I recall that it can fall back to 
use another server if GPS dims. I would assume when you turn it on it 
generates the host key and trusted certificate and signs an immediate 
descendent certificate if asked. In other words, the clients need to run 
compatible Autokey and roll their own keys and certificates.

Dave

Greg Dowd wrote:

> I do get the TC schema.  What I see is that there is apparently no well
> defined schema supporting a standards based method for using a CA.
> Distributing private keys is taboo, generating self-signed certs which
> can't be verified is appropriate mostly for small installs.  I think the
> reality during the origination of this code is that ca software and
> validation in general weren't really ready for primetime.  And, of
> course, they still have the fundamental failing of considering time as a
> fixed resource which can't go wrong.
> 
> As for testing the code, I did a bit in the early days.  Autokey v1 had
> the barn door problem with the 0 cookie.  Then, if I recall correctly, I
> found huge holes like the public key was xmitted, then the self-signed
> certificate was xmitted and verified, but no code checked if the public
> key in the cert matched the public key being used.  That coupled with
> the fact that the system was basically incestuous and couldn't play
> outside its own sandbox curtailed my testing at the time.  Also, I
> believe then you were generating most of this code in a silo and
> delivering it wholesale into the distro with little explanation of what
> or why.  That and the stime group was spinning around in circles while
> we were trying to invent the trusted time solution which, in retrospect,
> was too far ahead of its time (pun intended).
> 
> As for the current state today, I think few people in the commercial
> world are using the autokey scheme.  I also see that the majority of the
> ones who are have been using it in an island.  Widespread adoption will
> likely not occur until digital identity markets grow.  Or until there's
> a lawsuit or two to update case law.  At that point, it would be useful
> to have a more open authentication scheme.  That is one of the reasons
> why I consistently push for clarifying the extension field mechanics and
> usage rules.
> 
> To the last point, the SyncServer S100 model (released 4-5 years ago)
> had autokey support based on 4.1.0 point release.  However, it is point
> to point as I don't think autokey was maintained in a backwards
> compatible manner.  Honestly, it hasn't been much of an issue.  The
> current product SyncServer S250 (released last year) has support for
> autokey based on 4.2.0.  However, the user interface currently doesn't
> support selection of schema (defaults to TC).  Again, I haven't heard
> much feedback on that feature.
> 
> Some of the customers that I deal with now have explicitly said that the
> v3 cryptochecksum is perceived as too weak (MD5) and the Autokey is
> perceived as too complex and proprietary.  They would like to see a
> standards based approach that considers the zero-proof aspects of time
> that you have espoused tied in with a more open ca infrastructure.
> Whether autokey is really too complex is debatable but the
> implementation can be.
> 
> 
> 
> 
> 
> Greg Dowd
> gdowd at symmetricom dot com (antispam format)
> Symmetricom, Inc. 
> www.symmetricom.com
> "The current implementation is non-obvious and may need to be improved."
> 
> 
> 
> 
> -----Original Message-----
> From: hackers-bounces at support.ntp.org
> [mailto:hackers-bounces at support.ntp.org] On Behalf Of David L. Mills
> Sent: Wednesday, June 21, 2006 8:26 PM
> Cc: Laatz, Erek; hackers at support.ntp.org
> Subject: Re: [ntp:hackers] ntp Authentification support for
> X.509v3againstaCertificate Authority (CA)
> 
> 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
> 
> Greg Dowd wrote:
> 
> 
>>The doc I'm looking at is ~mills/ident.html (linked as Autokey 
>>Identity
>>Schemes) on the NTP Time Synchronization Project Page. This has no 
>>section on TC schema. The book has a description in section 10.3 but 
>>it's actually pretty muddy. It specifies that the certificate is 
>>designated trusted if it has a string trustRoot as an extended 
>>attribute. But it's not really that simple. Typically there is a 
>>client trusted certificate store that the root certificate would need 
>>to be validated against. Otherwise, some scheme for validating the 
>>certificate external to process is recommended or masquerade is an 
>>issue. Also, the book TC scheme states that the trusted certificate 
>>would normally belong to a primary or secondary server. Again, not 
>>typical. If I was implementing this, I would use a token which would 
>>generate a pair of keys and a certificate request. This is important 
>>as I don't get access to the private key myself, just the cert 
>>request. I would then export the cert request and have it fulfilled by
> 
> 
>>a certificate authority. Then, I would take the CA root cert and the 
>>issued cert and load them into my token on the ntp server. At that 
>>point, clients could request the certificate from the server and the 
>>server would respond with a SEQ of certificates, which could be just 
>>the ntp server cert or could be the whole chain up to the CA. The 
>>client would then
>>
>>1) just accept the cert (in which case it's just the PC schema)
>>2) verify the chain to the ca cert and compare the ca cert against a 
>>local trusted store.
>>3) verify the chain to the ca cert and then externally validate the ca
> 
> 
>>cert or
>>4) do 3 and check for a certificate revocation list as well.
>>
>>
>>
>>
>>Greg Dowd
>>gdowd at symmetricom dot com (antispam format) Symmetricom, Inc.
>>www.symmetricom.com
>>"The current implementation is non-obvious and may need to be
> 
> improved."
> 
>>
>>
>>
>>-----Original Message-----
>>From: hackers-bounces at support.ntp.org
>>[mailto:hackers-bounces at support.ntp.org] On Behalf Of David L. Mills
>>Sent: Wednesday, June 21, 2006 7:13 PM
>>To: hackers at support.ntp.org
>>Cc: Laatz, Erek
>>Subject: Re: [ntp:hackers] ntp Authentification support for X.509v3
>>againstaCertificate Authority (CA)
>>
>>Greg,
>>
>>On the NTP project page at www.ntp.org there are three security
>>briefings
>>http://www.eecis.udel.edu/~mills/database/brief/autokey/autokey.pdf,
>>http://www.eecis.udel.edu/~mills/database/brief/secalgor/secalgor.pdf
>>and
>>http://www.eecis.udel.edu/~mills/database/brief/secproto/secproto.pdf,
>>two (large) HTML pages http://www.eecis.udel.edu/~mills/proto.html and
>>http://www.eecis.udel.edu/~mills/ident.html, a 56-page technical
> 
> report
> 
>>http://www.eecis.udel.edu/~mills/database/reports/stime1/stime.pdf, as
>>well as two chapters in das Buch. Which document do you have in mind?
>>The documents might not all be complete, consistent and may have
> 
> errors.
> 
>>The only thing I truly trust is das Buch. Nobody's perfect. Whatever
>>questions you might have should be answered in the docuemnts cited,
> 
> even
> 
>>if they are wordy, intricate and plain boring.
>>
>>The x509v3 certificates are generated, signed and the trails hiked in
>>the same way as PKIX. The trails end on a self-signed trusted
>>certificate held by the same dude that generated the (optional)
> 
> identity
> 
>>key. I expect that, if the PKIX infrastructure was required, very
> 
> minor
> 
>>modifications might have to be made in the extension fields. I would
>>dearly like a volunteer to actually try generating and signing a
>>certificate in the old fashion way and report what breaks in ntpd.
>>
>>Dave
>>
>>Greg Dowd wrote:
>>
>>
>>>Is there something in the doc that talks about how to walk a cert
>>
>>trail?
>>
>>
>>>I think the openssl list is a good place to start. The Autokey doc
>>>mentions more protocol aspect issues such as "distributed via secure
>>>means". Where is the "hiking a CA trail" doc? As far as I know, the
>>>autokey implementation is still just sending a single cert, which in
>>>reality is expected to end in a self-signed cert via proventic check.
>>>In the identity schema doc, there is a mention of 5 schemes in the
>>>first
>>>4 paras, then it drops to 4 schemes and TC goes away, right?
>>>
>>>Typical mechanisms for cert validation and crl distribution are x.500
>>>dirs or ldap. This is typically org specific based on whose ca
>>>software is installed.
>>>
>>>
>>>
>>>Greg Dowd
>>>gdowd at symmetricom dot com (antispam format) Symmetricom, Inc.
>>>www.symmetricom.com
>>>"The current implementation is non-obvious and may need to be
>>
>>improved."
>>
>>
>>>
>>>
>>>-----Original Message-----
>>>From: hackers-bounces at support.ntp.org
>>>[mailto:hackers-bounces at support.ntp.org] On Behalf Of David L.
> 
> Mills
> 
>>>Sent: Wednesday, June 21, 2006 2:44 PM
>>>To: hackers at support.ntp.org
>>>Cc: Laatz, Erek
>>>Subject: Re: [ntp:hackers] ntp Authentification support for X.509v3
>>>againsta Certificate Authority (CA)
>>>
>>>Erek, Danny,
>>>
>>>A full disclosure about the Autokey public key scheme is in the
> 
> January
> 
>>>technical report on the NTP project page linked from www.ntp.org. The
>>>scheme does hike the CA trail to a trusted host acting as a root CA.
>>>However, there is a problem. I suppose you need to use a comercial
>>>authority. Unless they run NTP with Autokey and have their own
> 
> trusted
> 
>>>NTP source, the period of validity cannot be verified.
>>>
>>>The distribution does include means to generate x509v3 certificates
>>>using the the ntp-genkeys routine, which uses the OpenSSL library. In
>>>principle, x509v3 certificates generated by the x509 program in that
>>>library can be used and in principle any other means that uses the
>>>common names assumed by the Autokey model. As now, the common names
>>
>>must
>>
>>
>>>be those provided by the Unix hostname utility. and the must be
> 
> encoded
> 
>>>in PEM with a header giving file name and datestamp.
>>>
>>>Try runningntp-genkeys, making a host certificate, asking a comercial
>>>CA to sign it and using it in your trusted host. Presumably, that
> 
> would
> 
>>>extend the trail to the CA. That would't work with identify schemes,
>>
>>but
>>
>>
>>>it would be interesting to try.
>>>
>>>Dave
>>>
>>>Danny Mayer wrote:
>>>
>>>
>>>
>>>>Laatz, Erek wrote:
>>>>
>>>>
>>>>
>>>>>Dear all,
>>>>>
>>>>>we want to set up a larger environment for around 60 NTP servers in
>>>>>Germany.
>>>>>All these hosts will have the ability to use system specific X509v3
>>>>>certificates issued by a CA. Our idea is to use these certificates
>>>>>also for ntp authentification as we have the requirement to use
> 
> some
> 
>>>>>kind of authentification within the ntp installations.
>>>>>
>>>>>I've looked in several sources but found no idea how to realize a
>>>>>certificate verification against a CA, even found no special hint
> 
> on
> 
>>>>>how to realize it within the autokey protocol.
>>>>>
>>>>>Is there anyone who have an idea how to realize a X.509v3
> 
> certificate
> 
>>>>>verification against a CA?
>>>>>
>>>>>Best gregards, Yours
>>>>>
>>>>>Erek
>>>>>
>>>>
>>>>Dave Mills is the best person to answer these questions but he's not
>>>>on this list, so I have added him to this reply. Have you looked at
>>>>the autokey protocol for details about how it works?
>>>>
>>>>Danny
>>>>
>>>>
>>>
>>>_______________________________________________
>>>hackers mailing list
>>>hackers at support.ntp.org
>>>https://support.ntp.org/mailman/listinfo/hackers
>>>
>>>
>>>
>>
>>_______________________________________________
>>hackers mailing list
>>hackers at support.ntp.org
>>https://support.ntp.org/mailman/listinfo/hackers
>>
>>
> 
> 
> _______________________________________________
> hackers mailing list
> hackers at support.ntp.org
> https://support.ntp.org/mailman/listinfo/hackers
> 
> 



More information about the hackers mailing list