Lets Define the technical TERM "Auditing" or "Auditable" - Re:
[ntp:hackers] Re: sntp
tglassey at earthlink.net
Mon Aug 28 23:47:38 UTC 2006
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 MAKING
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.
----- 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
> 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.
> Harlan Stenn wrote:
> > Dave,
> >> In view of the time to build/test/maintain the software involved, I
> >> 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
> >>> 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
More information about the hackers