[ntp:hackers] Re: configuration file rewrite
David L. Mills
mills at udel.edu
Fri Mar 3 18:19:28 UTC 2006
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.
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:
> for discussions and wishlist items for the config rewrite.
More information about the hackers