Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6

"David W. Hankins" <David_Hankins@isc.org> Fri, 16 November 2007 16:58 UTC

Return-path: <dhcwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4WQ-0000mr-Gi; Fri, 16 Nov 2007 11:58:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4WP-0000mh-AH for dhcwg@ietf.org; Fri, 16 Nov 2007 11:58:25 -0500
Received: from the.hankinsfamily.info ([204.152.186.148] helo=hankinsfamily.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It4WM-0004QY-KA for dhcwg@ietf.org; Fri, 16 Nov 2007 11:58:25 -0500
Received: from navarre.mercenary.net (c-24-6-90-99.hsd1.ca.comcast.net [24.6.90.99]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id lAGGwL4P025784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Nov 2007 08:58:22 -0800
Received: by navarre.mercenary.net (Postfix, from userid 1000) id 73B3137FEE; Fri, 16 Nov 2007 05:48:03 -0800 (PST)
Date: Fri, 16 Nov 2007 05:48:03 -0800
From: "David W. Hankins" <David_Hankins@isc.org>
To: dhcwg@ietf.org
Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6
Message-ID: <20071116134803.GB18883@isc.org>
References: <A05118C6DF9320488C77F3D5459B17B7062ED3C6@xmb-ams-333.emea.cisco.com> <4733482A.7020302@sun.com> <A05118C6DF9320488C77F3D5459B17B70634E4E5@xmb-ams-333.emea.cisco.com> <4735A243.6090905@sun.com> <47368636.3070007@udel.edu> <4736F7A7.2090707@sun.com> <473D1BEB.1090102@ntp.org>
Mime-Version: 1.0
In-Reply-To: <473D1BEB.1090102@ntp.org>
User-Agent: Mutt/1.5.9i
X-Spam-Score: -2.6 (--)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: ntpwg@lists.ntp.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1147700197=="
Errors-To: dhcwg-bounces@ietf.org

On Thu, Nov 15, 2007 at 11:26:19PM -0500, Danny Mayer wrote:
> Brian Utterback wrote:
> > Interesting. I agree that a key needs to be specified somehow, but it
> > is not clear to me how to do it. We have to assume that the client
> > does not have the same NTP keys. However, we would like a way to
> > specify a server and keys securely, so that the security of the
> > network depends only on the security of DHCP. Again I am not up to
> > date, *is* there a secure DHCP? If so, then how to get keys to the 
> > clients becomes an issue.

Although DHCPv6 does have a signature verification mechanism, it does
not encrypt carried configuration.

So unless you're transferring public keys for NTP, there's an exposure
problem I'm not sure you're aware of.  Just making sure you know, I'm
not familiar with the keys discussed in this context.


Next, I want to make sure that your expectations of the services
DHCPv6 can provide are set appropriately.

Others have pointed out DHCPv6's authentication mechanism uses shared
secrets; there is also a similar mechanism for DHCPv4, RFC3118
"Authentication for DHCP Messages" (which 3315 says its method is
based upon).  You should know that this has not been well deployed in
DHCPv4, and it shares very similar design features to RFC3315's
authentication.  The primary problem is that for most networks in
operation, "configure a shared secret on all of your clients" defeats
the purpose of the "Dynamic" in DHCP.  If you have to manually
configure all your clients with a key, why bother using DHCP at all?
You may as well manually configure them all with the final
configuration state and skip a lot of needless machinery.

So although it can be done, no one actually does it.

I understand that 3315 authentication has precisely the same barrier,
that the client's keys are distributed "out of band."  I have no
reason to think that IPv6 makes operators more interested in manually
configuring clients to obtain dynamic configuration state than they
have been in IPv4.

This is surmountable I think, it's possible the authentication methods
might be extended and improved to remove this barrier to adoption, but
there have been zero drafts to date which attempt to do so.

So, expectations.


Your expectations should be:  No one will use 3315 authentication as
it is, and therefore you will not have a cryptographically secured
means to deliver this information on real networks.  People will,
however, take special care with their DHCPv6 protocol packets on their
networks (firewalling, etc, just as many always have done in IPv4),
and there exists the potential for improvement and actual deployment
of cryptographic trust here at some future date.

-- 
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
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg