Lets Define the technical TERM "Auditing" or "Auditable" - Re: [ntp:hackers] Re: sntp

David L. Mills mills at udel.edu
Tue Aug 29 02:58:32 UTC 2006


"Auditable" came in an exchange between Harland and I and was not 
intended as a technical word. Thanks for the clarification.


todd glassey wrote:

> David - from a technical standpoint, lets create a definition of
> "Auditability" because I think what you were talking about is 
> verifying that
> the code footprint itself executes the protocol standard and nothing else,
> and that is not auditing per se from my perspective.
> Auditing is a process of collecting evidence of something's operations in
> support of an attestation. i.e. some data that backs up some assertion 
> at a
> use level and while you could audit the code itself, I refer to that
> process as "Blueprinting".
> People use blueprinting and modeling or simulating the code's execution to
> certify a particular executables functionality and the scope of its
> capabilities. Blueprinting also involves and antivirus certification 
> scan as
> well as a number of other things including subroutine and external IPC
> linkages or threading interfaces (User level threads and all that).
> And while I understand that this is an issue of serious important to this
> WG - the exact point your were making here - is the SAME POINT I WAS 
> the other day... and that is we need someway of "blueprinting the code 
> that
> is released as the standard prototype" when a formal release is done.
> What I want to apply the term "Auditability" specifically to is the 
> proofing
> that is gained by operating a NTP practice model.
> Todd
> ----- Original Message -----
> From: "David L. Mills" <mills at udel.edu>
> To: <hackers at ntp.org>
> Sent: Monday, August 28, 2006 2:10 PM
> Subject: [ntp:hackers] Re: sntp
>> Harlan,
>> I'm copying this to the hackers list, as others might want to comment.
>> Let me take your points seriously. I use bold here for emphasis as do
>> the rfcs.
>> You assume ntpd is not auditable, from which I gather sntp is supposedly
>> auditable. I conclude that sntp should not use components from the ntp
>> distribution unless those components are auditable. Has someone (Todd?)
>> made that professional judgement? To be auditable a serious claim would
>> be necessary that the implementation conform to rfc4330. The
>> implementers should verify that with the rfc4330 text, especially the
>> best practices section. To preserve audibility, the sntp distribution
>> should be separate and at arms length from ntpd.
>> To conform to the spec, an sntp client MUST NOT function as a server.
>> The only thing it MUST do is send a compliant packet to a legitimate
>> server, receive a compliant packet and set the system clock. As the spec
>> says, it would be NICE to use the ntp on-wire protocol and delay/offset
>> calculations in order to avoid problems with timestamps in different
>> eras. The spec says nothing about timeout/retry other than consecutive
>> calls should be spaced at least 15 seconds with exponential backoff. The
>> spec gives strong advice on the timeout between successive sntp runs,
>> usually expected to be several days. The spec writers were very serious
>> about these things, having been assaulted by the Netgear incident.
>> The sntp client MUST cease operation with a server if a KoD is received
>> and MAY switch to another server as backup. It would be NICE if sntp
>> aborted in response to a ICMP error message. It would be USEFUL if it
>> used something like the ntpd panic and step thresholds (which could be
>> set much higher than ntpd). These are not specified in the rfc.
>> Putting in anything beyond the strict specification is a slippery slope.
>> >From a specification and normalization point of view, it MUST NOT
>> perform additional functions other than specifically allowed in the
>> specification. If it did, the auditors could suspect the additional
>> features could be misused. See where I am going with this? It would
>> certainly be possible that there will be j-random implementations of
>> sntp including additional features, but those implementations cannot
>> claim to be strictly compliant with the sntp specification. If an sntp
>> product leaves these shores, it should be strictly compliant and should
>> so state with emphasis.
>> Some features are certainly possible and maybe even desirable in
>> connection with the operating system, such as those you suggest. They
>> have nothing to do with the protocol specification. It may even be
>> possible to implement additional protocol capabilities, like operate as
>> a server, but they MUST NOT be enabled in the default build and their
>> configuration controls should be banished to a separate page in the
>> documentation. Only if these features are disabled will the auditors be
>> satisfied. Something like, if you break the seal the warranty is voided.
>> Upon review of the spec, I see something broke in the security section
>> markup. It references only a very old Autokey document, long since
>> superseded. The spec says security features are optional, but if they
>> are included, they must conform to that document. The writers intended
>> to say that, if included, they must conform to the MD5 scheme documented
>> in rfc1305 with OPTIONAL extensions in the Autokey document. The spec
>> writers have no shame in this, since it took three years to survive the
>> IETF process.
>> My umbrella is deployed and I expect the rain.
>> Dave
>> Harlan Stenn wrote:
>>> Dave,
>>>> In view of the time to build/test/maintain the software involved, I
> just
>>>> don't see the need to build anything fancy in sntp.
>>> OK, what is "fancy"?
>>>> Is there a compelling reason not to promote ntp for anything but
>>>> absolute bare bones service? Is there something compelling folks not
>>>> to use ntp in sntp mode?
>>> There are number of folks who believe ntpd is "too big" for leaf client
>>> services, or even for intermediate services. They also think it is
>>> overall too complicated and they are concerned about possible security
>>> exploits and the difficulty of doing a code audit.
>>> This drives them to look for something else and/or spread FUD and/or
>>> become nuisances.
>>>> With Sachin's new code, sntp configuration
>>>> will be transparent to ntp. I would rather put people cycles in doing
>>>> that than spinning tires with sntp afterthoughts.
>>> That will help and I'd like to get this installed ASAP. I suspect that
>>> it will not make the 4.2.4 release in the next month or so, but I expect
>>> it will go in to ntp-dev as soon as it is ready after the 4.2.4 release.
>>> H
>>> --
>>>>> Dave,
>>>>> I understand your desire to have a lean and mean sntp implementation.
>>>>> There are a couple of issues that come up, however, and I wonder if we
>>>>> might be better served by either an sntp implemenation that has
>>>>> configurable features, or offering 2 implementations (one lean and
> mean,
>>>>> the other more robust).
>>>>> Here are 2 examples:
>>>>> - Some people like to use some form of crypto keys for all their ntp
>>>>> servers. Ignoring public key for the moment, this would require MAC
>>>>> security and /etc/ntp.keys support for sntp.
>>>>> - many folks have a requirement that if the time is set (stepped) that
>>>>> a UTMP/WTMP entry is made.
>>>>> If we can get sufficient consensus on what neds to be there we can do
>>>>> this with a single program. Otherwise, I think we're gonne end up with
>>>>> either a configurable program or "sntp" and "sntp-lite".
>>>>> What do you think?
>>>>> H
>> _______________________________________________
>> hackers mailing list
>> hackers at support.ntp.org
>> https://support.ntp.org/mailman/listinfo/hackers

More information about the hackers mailing list