[ntpwg] [ntp:hackers] MS-SNTP

[TS Glassey]

OK Luke
but this brings up a larger issue, and that is that there are at least two 
other protocols' which will want to be able to use NTP services and that 
number will likely expand. So perhaps rather than just fixing SAMBA why not 
fix NTP so it can be referred to or called by any other protocol.

To that end in addition to SAMBA I would also suggest that the same 
timesetting requirement's are true for NEA and possibly DHCP protocols as 
well and that any solution which is setup to provide NTP services from 
another protocol should also address these other protocols. Likewise DNS and 
DNSSEC tools would be a powerful resource for time-server and time-token 
distribution in AutoKEY or other crypto-environment's

Todd Glassey

----- Original Message ----- 
From: "Luke Howard" <lukeh at padl.com>
To: "David L. Mills" <mills at udel.edu>
Cc: <ntpwg at lists.ntp.isc.org>; <hackers at ntp.org>
Sent: Monday, March 31, 2008 8:33 PM
Subject: Re: [ntp:hackers] MS-SNTP


>> You say Samba is to simulate an AD controller, which means it would
>> be a
>> MS-SNTP server for that domain. I wouldn't thnk the Samba AD would
>> ordinarily be a MS-SNTP client of another MS-SNTP server in that
>> domaing, but that might happen. On the other hand, the Samba 4 machine
>
> It would happen in larger deployments, because the NTP synchronization
> hierarchy by default mirrors the Windows domain hierarchy.
>
>> For grins, I propose a configuration command to set the default server
>> key ID scheme (ntp/mssntp/...) plus an association configuration
>> option
>> to set the default client key ID scheme. Exceptions can be handled by
>> the restrict mechanism by using the restrict bits to override the
>> default server scheme. I assume an AD will not have addresses
>> scattered
>> all over the place and relatively few address/mask pairs would be
>> necessary. If on the other hand only a few NTP clients are used, the
>> mask can apply to them.
>
> That sounds like a good approach. The patch I initially submitted
> supported multiple authentication providers for different parts of the
> key ID space, perhaps this could be extended to support client address
> ranges too.
>
> -- Luke
>
> _______________________________________________
> hackers mailing list
> hackers at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/hackers