[ntp:hackers] Re: sntp
stenn at ntp.isc.org
Tue Aug 29 00:31:48 UTC 2006
> You assume ntpd is not auditable, from which I gather sntp is supposedly
No on both counts.
I was relaying that several folks have said that they found the ntpd
codebase to be Large and not written in a style that would make it easy
to audit it (perform a security analysis of the code).
> I conclude that sntp should not use components from the ntp
> distribution unless those components are auditable.
I'm not worried about these points at this time - either the code
"works" and keeps the clock right or it doesn't. If it doesn't, there
is either a bug in the code or a bug in the spec. It gets reported, we
figure it out, we fix it.
> Has someone (Todd?) made that professional judgement?
I have no idea.
> 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.
OK, and we're not there yet. But you are talking about a code audit to
the spec, and I was originally (probably poorly phrased) talking about a
> To preserve audibility, the
> sntp distribution should be separate and at arms length from ntpd.
OK - I have not looked at any of these issues yet.
> 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.
Yes, this runs right up against making a WTMP entry if the time is
changed. However, there are Good Reasons for making a wtmp entry on any
time steps. If there is a "shim" layer between the audited (for some
definition of audit) code and the OS that handles this, fine. But
saying "We cannot make a wtmp entry because it is not in our spec" is
> 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.
Like Gene Kelly, I trust!
More information about the hackers