[ntp:questions] Windows Time with NTPv4
martin.burnicki at meinberg.de
Mon Mar 17 09:27:53 UTC 2008
Danny Mayer wrote:
> Martin Burnicki wrote:
>> Evandro Menezes wrote:
>>> But doesn't symmetric association require authorization or is it only
>>> true when there's a keys file?
>> AFAIK peer associations do require authentication configured correctly.
> No, that's not required. It should be required and you can specify key
> on the peer directive line.
Hm, I've been pretty sure authentication had been required for proper peer
operation (unless explicitely disabled, of course).
In RFC-1305, section "Initialization-Instantiation Procedure" mentions:
--- <snip> -----
[...] With the authentication bits set as suggested, only properly
authenticated peers can become the synchronization source.
--- <snip> -----
>> Of course the admin of a NTP server does not want his NTP server's time
>> be changed just because some dumb client sends some packet asking to do
> Set up restrict with notrust on the LAN network addresses.
Of course this would be possible, but the expected behaviour (for me, at
least) would be not to let bad guys doing bad things by default, i.e. not
let them change my time until explicitely given the permission to do so.
>> This is what happens with w32time which under certain conditions sends
>> "peer" requests instead of "client" requests. Since those w32time clients
>> have neither been configured nor authenticated as peers, the question is
>> how they should be handled by ntpd.
>> The default was that ntpd just dropped those requests, i.e. didn't send a
>> response at all, in which case the w32time clients were unable to
>> synchronize to the NTP server, unless they were reconfigured correctly to
>> send "client" requests.
> I think that this is what Dave was talking about where the NTP code was
> allowing it to set the clock.
Even without authentication?
Now the question is whether the behaviour of the current implementation is
by design, or whether it has changed unintentionally in the past, or I've
just misunderstood the RFC.
>> The workaround in ntpd was to send normal "server" responses as it would
>> do for normal "client" requests, so those w32time clients are happy.
> Yes, but the challenge is to identify those systems as sending the wrong
> NTP packet mode.
As long as peering required authentication this should not matter since
those clients would not be authenticated correctly.
More information about the questions