[ntp:questions] Gretchen - in regard to CertifiedTime it never died...
Todd Glassey CISM CIFI
tglassey at earthlink.net
Sat May 2 18:20:23 UTC 2009
Danny Mayer wrote:
> Todd Glassey CISM CIFI wrote:
>> Gretchen Baxter wrote:
>>> in that case, this is good news for everyone in the timing community.
>> We think so - and as CertifiedTime's original founder I am overjoyed to
>> turn CertifiedTime's services back online. The intent when I built
>> CertifiedTime Inc originally was to build a uniform time source which is
>> operated inside of an Audit Practice which meets BOTH the RFC3161
>> requirements (set by ETSI and the EU) for running time service
>> enterprises as well as those through US Law as well. We at Certichron
>> are doing exactly that.
>> This, by the way, is why I keep asserting that the following is
>> necessary because of the sheer number of implementations using any
>> number of OS interfaces including those run-time services added here by
>> the ISC.ORG NTP effort. The same is needed for each commercial release
>> of NTP including all commercial providers since the Audit Community has
>> been formally put on notice this key set of definitions and goal's don't
>> exist, and since they cannot review those test reports they can no
>> longer allow the introduction of un-certified code into production systems.
> I am not aware of any commercial providers of NTP apart from the two
> mentioned above. The O/S vendors include NTP in their O/S's but they do
> not provide commercial NTP.
You mean an outsourced NTP services.
> the above mentioned companies seem to
> provide commercial services of NTP. Who provided the formal notice to
> the Audit Community and what reasons were given? What test reports
> exist? There is an implication here that uncertified code was allowed
> onto production systems but the reality here is that most of the O/S is
> not certified either.
That is exactly what I said Danny.
> Just a formal comment here. The NTP Public Services project which makes
> available the NTP reference implementation does NOT provide any formal
> verification that the source code that it distributes is valid or
> correct nor does it validate any of the time sources beyond what
> protocols like autokey provides.
That means that people that need to rely on a known functional code-base
with proper security auditing cannot use the NTP.ORG sw itself but must
rather rely on the test processes of the vendor's to supply a competent
implementation. The problem we face is more and more of them are laying
the responsibility to test NTP on the NTP.ORG entity, which doesnt
provide that service, meaning that the OS Vendor's themselves are making
their copies also unusable under the existing requirement's for
trust-service tools to be fully tested and their releases managed.
> Autokey merely validates that the
> sender of the NTP packet is coming from where it says it comes from and
> that itself is based on out-of-band keys provided by the provider of
> that source.
True - its only a end-point identity tool. That and the liabilities of
running UDP over the open Internet speak for itself.
> In no case does it guarantee that the time source is
> providing valid time. Furthermore RFC3161 is not supported or
> implemented by the reference implementation of NTP.
Amen to that - which is why there are NO European TS providers today -
the tools don't exist for them.
> Third party providers may provide any or all such features. However it
> is important that you ensure that those providers meet any contractual
> requirements that you may have and the NTP timesources meet the
> standards required of the country where you are providing such services.
Actually the time services need to be appropriate for the jurisdictions
those events would be prosecuted in. They may also need to be
enforceable in other jurisdictions as well meaning a composite
time-scale between those time-bases used in the process would be
necessary, especially if a legal metrological agreement exists between
> You would need to contact the country's national time standards body for
> information about that and what services that they provide.
>> 1) A formal specification of how NTP works with what Kernel
>> resources and what the thread overhead of those controls inside the
>> Run-Time Image ace. The intent is to create a set of metrics which can
>> be used by NTP implementors to tune their releases and to set a 'stake
>> in the ground' for implementors of appliance style NTP systems.
>> 2) A formal specification for testing NTP and a method of specify
>> partial or core compliance since many of the new controls added don't
>> really make sense to keep inside all versions of NTP. (Sorry it is what
>> it is - NTP - IMHO - should not be used for negotiating policy
>> information - only for moving time around).
> This is a very opaque statement and in is not clear what controls or
> policy it is referring to.
No its not. Its a statement that many of the security additions to NTP
are based in implementing control policy as to who can and cannot update
or get time. These are policy controls.
> Policy is not negotiated anywhere within the
> reference implementation of NTP.
Uh gee - the IP control features and the AutoKEY additions are exactly
this policy stuff I am referring to.
> It may be by third-party providers.
>> 3) A formal characterization and operations guidelines so the
>> commercial industry don't get bad advice on the systems and processes
>> needed to generate that court-admissible evidence.
> I have yet to see any requirements for court-admissible evidence by any
> party including the courts.
Which speaks for itself - thanks for documenting my claims regarding
needing a proper time-management practice which is industry approved so
>> Todd Glassey
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.238 / Virus Database: 270.12.13/2091 - Release Date: 05/01/09 17:52:00
More information about the questions