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

From: Shane Kerr <[email-masked]>
Date: Wed, 28 Nov 2007 01:42:55 +0100

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.

- --
Shane
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 28 Nov 2007 00:50:29 +0000

Shane wrote:

> 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

In that scenario, yes, that would appear to be the best policy.

If one is going to use DHCP to offer NTP configuration information there
are good reasons to provide IP addresses to certain hosts.  Similarly,
there are good reasons to provide names to other hosts.

Indeed, one may wish to provide a list of servers using a combination of
names and IP addresses.

But this is all true for ntp configuration in general - the same issues
occur regardless of where the configuration information comes from.

H

---

From: Danny Mayer <[email-masked]>
Date: Tue, 27 Nov 2007 23:21:33 -0500

> 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

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 28 Nov 2007 10:01:07 +0900

Shane Kerr wrote:

> It occurs to me that DNSSEC requires accurate time.

DNSSEC requires *SECURE* accurate time.

> It seems like we have to provide IP addresses for NTP servers for this reason.

It is required that DHCP clients and NTP servers allocated by DHCP
*SECURELY* share some information for the DHCP clients authenticate
the NTP servers.

It, in practice, means shared authentication information must be hand
configured in the DHCP clients and associated NTP servers, which
means there is no need for DHCP service provide NTP server for secure
DNS.

						Masataka Ohta

PS

Still, secure DNS is only weakly secure , that is, as secure as
plain DNS that there is no reason to deploy it. That is, just as
plain DNS is vulnerable to compromised intermediate entities such
as ISPs or zone admins, secure DNS is vulnerable to compromised
intermediate entities of zone admins or NTP servers.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 28 Nov 2007 09:11:43 -0800

> It seems like we have to provide IP addresses for NTP servers for this reason.

IP addresses are no more innately secure than non-DNSSEC'd domain
names.

So I don't see how this is different from disabling DNSSEC validation
until the clock is synchronized to the man in the middle.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "David L. Mills" <[email-masked]>
Date: Thu, 29 Nov 2007 00:15:26 +0000

Shane,

One of the reasons Autokey avoids DNS is the time issue you mention. 
However, so far as I know, DNS does not require absolute time, only time 
intervals. To authenticate DNSSEC, the certificate lifetimes must be 
valid, and that requires authentic time. This is something like Autokey, 
in that the protocol must be able to start in speculative mode and 
confirm success only when all the marbles are on the table.

Dave

Shane Kerr wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> All,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHTLmLMsfZxBO4kbQRAvdVAJ4j3CdU7WOIobV7/1shw6nNaX+j9wCfQgY9
> Tu1+WtSfMikoNqked4ceQxc=
> =WxZu
> -----END PGP SIGNATURE-----

---

From: "TS Glassey" <[email-masked]>
Date: Thu, 29 Nov 2007 07:56:04 -0800

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" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, November 27, 2007 8:21 PM
Subject: Re: [ntpwg] [dhcwg] DNSSEC in names vs. numbers for NTP server 
information in DHCP

---

From: "TS Glassey" <[email-masked]>
Date: Thu, 29 Nov 2007 08:06:22 -0800

Ohta-san,

----- Original Message ----- 
From: "Masataka Ohta" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, November 27, 2007 5:01 PM
Subject: Re: [ntpwg] [dhcwg] DNSSEC in names vs. numbers for NTP server 
information in DHCP

> DNSSEC requires *SECURE* accurate time.

yes.

>> It seems like we have to provide IP addresses for NTP servers for this 

Not necessarily, but rather a secured timesetting event which operated 
inside the DHCP process context.

> *SECURELY* share some information for the DHCP clients authenticate

meaning that the DHCP Server itself should also double as the NTP Server for 
its client only. That is the best solution possible with the way DHCP works 
now.

> means there is no need for DHCP service provide NTP server for secure

yes it would. The idea that the DHCP server also double for setting the time 
of day of the requesting DHCP client is a good idea too.