IETF Logo Mail Archive

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

"David L. Mills" <mills@udel.edu> Wed, 14 November 2007 13:11 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 1IsI1f-0003KU-Jp; Wed, 14 Nov 2007 08:11:27 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrmWy-0000jZ-Q1 for dhcwg@ietf.org; Mon, 12 Nov 2007 22:33:40 -0500
Received: from whimsy.udel.edu ([128.4.2.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrmWy-0008Iy-1C for dhcwg@ietf.org; Mon, 12 Nov 2007 22:33:40 -0500
Received: by whimsy.udel.edu (Postfix, from userid 62) id E5E101689; Tue, 13 Nov 2007 03:33:33 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu
X-Spam-Level:
X-Spam-Status: No, score=-2.1 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1
Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id 49EC0149A; Tue, 13 Nov 2007 03:33:31 +0000 (UTC)
Message-ID: <47391B04.8080202@udel.edu>
Date: Tue, 13 Nov 2007 03:33:24 +0000
From: "David L. Mills" <mills@udel.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: ntpwg@lists.ntp.org, dhcwg@ietf.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> <473736A7.5000801@udel.edu> <47387778.4030702@sun.com>
In-Reply-To: <47387778.4030702@sun.com>
X-Sanitizer: This message has been sanitized!
X-Sanitizer-URL: http://mailtools.anomy.net/
X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500
Cc:
Subject: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6
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>
Errors-To: dhcwg-bounces@ietf.org

Brian,

Roaming laptops is what NTP Autokey is designed for. All a properly 
configued laptop would not need anything except a flag that says to use 
it and possibly the public group key. Heck with NTP; use Autokey to 
authenticate the server for anything.

Dave

Brian Utterback wrote:

>
>
> David L. Mills wrote:
>
>> Brian,
>>
>> My model about the keys is that the DHCP server would supply a key ID 
>> for the NTP server(s) as configured, but not the keys themselves. The 
>> keys would have to be configured for the NTP server and client 
>> separately. The DHCP server would be responsible only for the opaque 
>> key ID.
>>
>
> I see what you mean, but I am not sure about the use case here.
> Certainly if the keys are pre-configured on both the clients and the
> servers, then the key id is a must.  But I am concerned about the
> roaming laptop mode here. If I bring my laptop to a network, I would
> like to be able to get enough info from the DHCP server to allow me
> to securely connect to the server and have it be authenticated. Perhaps
> a public key distribution scheme?
>
>> There is an issue about the security of the DFCP server itself; that 
>> is another issue. I'm assuming the DHCP server is behind the firewall.
>
>
> Right. Out of the realm of our discussion.
>
>>
>> The mode specification could be any of the valid NTP modes. If client 
>> (3) it would be an ordinary client/server association. A means would 
>> be necessary to specify broadcast client, as that is not a mode in 
>> the strict sense. It could be symmetric active (1), in which case the 
>> victim would initiate that type association. To specify symmetric 
>> passive (2) means that the victim should wait for a symmetric active 
>> (1) packet. This does not seem useful.
>
>
> If you get a broadcast address to use then you should be a broadcast
> client. I don't see the usefulness of a DHCP client being a symmetric
> anything. Perhaps this is a failure of imagination on my part.
>
>


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

v2.23.0 | Report a Bug | By Email