[ntp:hackers] Re: sntp

David L. Mills mills at udel.edu
Mon Aug 28 21:10:12 UTC 2006


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

More information about the hackers mailing list