[ntp:hackers] Re: configuration file rewrite

David L. Mills mills at udel.edu
Fri Mar 3 18:19:28 UTC 2006


Harlan,

1. Don't consider stratum in the access controls. That's what the 
ceiling and floor subcommands are for.

2. Also, I don't understand what it means to accept synchronization from 
peers if only at the same stratum. In such case the protocol would 
ordinarily prohibit that.

3. There seems to be a lot of fritz in the restrict design, but little 
convergence on what the security threats are anticipated. I gave some 
thought to that in the authentication rewrite and model displayed in the 
skeleton and flow charts. An unprotected client is vulnerable to 
unwanted broadcast client and symmetric passive mobilizations and in 
general is vulnerable to a clogging attack. It is vulnerable to a 
hostile remote configuration attack as well, even if password protected, 
especially if public key cryptography is in use.

4. If what you require is protection from masquerade and theft of 
service, that's what cryptography is for. The loopback check is rather 
strong, even if cryptography is not in use. See the notrust and 
nomobilize bits in the restrict mask. The intent is to hide unless the 
packet is cryptographically authenticated by either symmetric or public 
key crytography. So, unless your server or peer is properly 
credentialled, the bad guy doesn't even know you are there.

5. What I would assume the restrict bits would be useful is to control 
access by your friends like the superuser model. I'm not arguing for or 
against such features, but if used the security model should be 
consistent with the host access model. The remote configuration 
provisions are not now consistent with any model used here and probably 
not in most places. More in a followup message.

Dave

Harlan Stenn wrote:

> (Adding Dave to the Cc: line.)
>
> Danny Mayer wrote:
>
>> Hal Murray wrote:
>
>
>>> Speaking of configuration rewrite...
>>
>
>>> Is it on the wish-list to add a minimal (un)restrict entry so that a
>>> server or peer specified in the config file will work correctly even
>>> if there is a blanket restriction that would otherwise block replies?
>>
>
>>> Maybe the restrict keywords should be allowed on the server config
>>> lines with an appropriate default so you can modify the free restrict
>>> line. ???
>>
>
>>> I think this would solve the problem of can't-use-DNS unless it
>>> returns only one IP address.
>>
>
> Danny> I was planning to have any server/peer that was configured,
> Danny> whether as a host/FQDN or as an IP address added to the list of
> Danny> allowed addresses irrespective of the restrict settings unless
> Danny> that address is explicitly denied. It makes no sense any other
> Danny> way. It has nothing to do with the config file rewrite.
>
> Danny, what do you mean by "the list of allowed addresses"? "Allowed"
> to do what, exactly?
>
> Sometimes people list servers that they wish to monitor but they do not
> want to exchange time with them. There must be a way to continue to get
> this behavior.
>
> Regardless, we have no idea what the spec is that Dave is going for.
>
> I will also point folks at:
>
> http://ntp.isc.org/Dev/NewNtpConfFormat
>
> for discussions and wishlist items for the config rewrite.
>
> H




More information about the hackers mailing list