[ntp:hackers] Re: sntp

Harlan Stenn stenn at ntp.isc.org
Tue Aug 29 00:31:48 UTC 2006


Dave,

> You assume ntpd is not auditable, from which I gather sntp is supposedly 
> auditable.

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
security audit.

> 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.

OK.

> 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.

OK.

> 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
not OK.

> 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.

OK.

> 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.

'k.

> My umbrella is deployed and I expect the rain.

Like Gene Kelly, I trust!

H


More information about the hackers mailing list