Re: [ntpwg] [dhcwg] DNSSEC in names vs. numbers for NTP server information in DHCP

["TS Glassey" <[e-mail]>]

Shane/Danny
As another possible solution here, let me ask, would it make sense to also 
setup a default Multicast type configuration for use in sites that support 
pre-host registration*** through DHCP... It seems like as setting  the DHCP 
server itself could be peered with the NTP Server they represent, and as 
such it itself could serve a dual role, not per se setting open-client 
requests through NTP but through the DHCP listener.

If the intent is to provide an unsecured time source for calibrating the 
operating clocks of un-plumbed hosts, then perhaps a multicast type 
deployment would work through DHCP for this. Also DHCP could easily be setup 
to do a two layer process, wherein it presets the client to a 'rudimentary' 
state where it could communicate with an authentication server to qualify 
and permit its entrance into a network.

FWIW - I have an updated I-D for DHCP which adds this two layer process, and 
the security model it produces is pretty strong. If anyone is interested 
drop me a note offlist and I will send it to you.

Todd Glassey

----- Original Message ----- 
From: "Danny Mayer" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Tuesday, November 27, 2007 8:21 PM
Subject: Re: [ntpwg] [dhcwg] DNSSEC in names vs. numbers for NTP server 
information in DHCP


> Shane Kerr wrote:
>> All,
>>
>> I was reading the long, long, long thread(s) about putting NTP 
>> information into
>> DHCP, and the focus on whether DHCP servers should provide names or IP 
>> addresses
>> for NTP servers.
>>
>> It occurs to me that DNSSEC requires accurate time. So, we have a bit of 
>> a
>> bootstrapping issue if we ever decide to secure DNS zones that contain 
>> NTP
>> servers in them and expect clients to use the server names to find them.
>>
>> It seems like we have to provide IP addresses for NTP servers for this 
>> reason.
>>
>
> I'm not sure which hat to wear on this one. The first question is
> 1) how accurate? Within 5 minutes like TSIG?
> 2) I assume that this is both ends relative to each other?
>
> We always had a bootstrapping issue. It's only now becoming obvious. I
> had mentioned this in a previous message. One way of avoiding the
> accurate time issue is to use a refclock on the system  and have NTP get
> its time from there.
>
> There are actually three different parts of this:
> 1) DNS Servers using DNSSEC for the zone in which they are authorative
> These will have static IP addresses and DHCP would presumably not be
> involved (though no doubt can provide other data). I would expect that
> it would be set up manually to have ntpd to use servers specified by the
> sysadmin.
>
> 2) Caching DNSSEC-aware servers
> These are presumably the servers responsible for supplying the answers
> to the ultimate clients. These would also presumably have static IP
> addresses and not use DHCP. They too could be manually configured to use
> NTP from their own resources but could conceivably get information from
> DHCP servers.
>
> 3) The clients themselves using a DNSSEC-enabled resolver. These are
> likely to be provisioned with IP addresses, DNS server addresses, etc.
> and presumably get their information from DHCP. These clients are the
> most vunerable since presumably the NTP server would be provisioned by
> DHCP which would need to make sure that they receive authenticated data.
> That's the chicken and egg problem since they presumably need an
> accurate time before communicating with the DHCP server to get
> information about the NTP server addresses to use. If you are concerned
> enough to use DNSSEC you presumably are concerned enough to use only
> authenticatable NTP servers and that means using autokey protocol (now
> in IETF draft). That requires a key and it needs to be distributed OOB.
> The key could potentially be distributed by DHCP but you also need to
> protect the key from modification in flight which presumably needs DHCP
> authenticationc and encryption if that's the distribution method. The
> trick here is to figure out which piece to set up first.
>
> Ideas?
>
> Danny
> _______________________________________________
> ntpwg mailing list
> [e-mail]
> https://lists.ntp.org/mailman/listinfo/ntpwg 


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg