RE: [dhcwg] Trust model of Client FQDN option

"Bernie Volz" <volz@cisco.com> Wed, 04 August 2004 00:53 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27383; Tue, 3 Aug 2004 20:53:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs9wV-0005uv-WF; Tue, 03 Aug 2004 20:47:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs9tn-0004mY-DS for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 20:44:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26625 for <dhcwg@ietf.org>; Tue, 3 Aug 2004 20:44:54 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs9wv-00058D-IX for dhcwg@ietf.org; Tue, 03 Aug 2004 20:48:12 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 03 Aug 2004 20:44:21 -0400
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i740iDxF001583; Tue, 3 Aug 2004 20:44:16 -0400 (EDT)
Received: from volzw2k (sjc-vpn3-608.cisco.com [10.21.66.96]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO96850; Tue, 3 Aug 2004 20:40:58 -0400 (EDT)
From: "Bernie Volz" <volz@cisco.com>
To: "'Pekka Savola'" <pekkas@netcore.fi>, "'Ted Lemon'" <mellon@fugue.com>
Subject: RE: [dhcwg] Trust model of Client FQDN option
Date: Tue, 3 Aug 2004 20:42:26 -0400
Organization: Cisco
Message-ID: <000c01c479bb$eba91af0$c3838182@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.5709
In-Reply-To: <Pine.LNX.4.44.0408040144440.31389-100000@netcore.fi>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.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>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Correct, this appears in draft-ietf-dhc-ddns-resolution-07.txt. This draft
is referenced in the "7.  DNS Update Conflicts" section of the FQDN draft.

The resolution draft still needs additional work for DHCPv6 - it currently
only applies to IPv4.

- Bernie

> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] 
> On Behalf Of Pekka Savola
> Sent: Tuesday, August 03, 2004 7:06 PM
> To: Ted Lemon
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] Trust model of Client FQDN option
> 
> 
> On Tue, 3 Aug 2004, Ted Lemon wrote:
> > On Aug 3, 2004, at 11:03 AM, Pekka Savola wrote:
> > > I'm not sure the v4 or v6 DHC FQDN client options address the 
> > > problem of the trust model for the update content 
> sufficiently well.  
> > > I'd even go as far to say that it might create a false sense of 
> > > security.
> > 
> > Pekka, in the meeting this morning, you said you hadn't 
> read the drafts 
> > having to do with DNS updates on DHCPv4.   Have you now 
> read them?   
> 
> Yes; I scanned through draft-ietf-dhc-fqdn-option and the 
> dnxext dhcrr 
> document.
> 
> > The reason I ask is that for the entire duration of the 
> time I've been
> > coming to IETF, people have occasionally raised the very 
> same issue you 
> > are now raising.
> 
> Maybe this would stop if these issues would actually be 
> adequately addressed?  I promise to bring this up again at 
> the last minute if 
> not.
> 
> What you describe below is very well, and probably addresses 
> most of the issues (to a certain degree, which should be 
> spelled out), but none of this seems to exist written in the 
> clear in draft-ietf-dhc-fqdn-option.
> 
> Let's look at its Security Considerations section (the others don't 
> include anything relevant to this, AFAICS):
> 
> 1st paragraph: generic text about DNS update authentication 
> requirements
> 
> 2nd: notes the two approaches (client vs dhcp updated), and that they 
> depend e.g., on security model (without going into details)
> 
> 3rd: generic text wrt. whether DHCP server would always do 
> the updates 
> or not
> 
> 4th: notes the lack of authentication of the user, given that DHCP 
> authentication is not there or is not deployed.  Ascertaining the 
> identty of the client is difficult. [note: DHCP authentication has 
> very little to do with the authorization of the client to update a 
> specific name]
> 
> 5th: describes scenarios where you might not be able to spoof DHCP 
> packets, and a little text about being able to trust (in some cases) 
> the dhc client id. [note: spoofing or not spoofing DHCP packets, and 
> DHC client id do not yet provide any authorization to update a DNS 
> name]
> 
> I also note that the draft doesn't even mention 
> draft-ietf-dnsext-dhcid-rr-08.txt.
> 
> The actual meat is missing, and does not address *DNS name* 
> authorization at all, just talks quite a bit about DHCP 
> authentication and different ways to eliminate DHCP spoofing.
> 
> > The solution we have adopted, which is widely deployed, allows two 
> > answers to your question.   The first is a more paranoid 
> solution that 
> > requires widespread distribution of individual DNS update 
> keys.   The 
> > second is a more laissez-faire solution that does not require the 
> > distribution of individual DNS update keys.   This second 
> solution is 
> > no more or less secure than the first, but its behavior is 
> different.   
> > Names added by the DHCP server are marked as such, and if a name is
> > present and was not added by the DHCP server, that name can't be 
> > replaced at the request of the DHCP client.   When a client's lease 
> > expires, another client can acquire the previous client's name, so 
> > there's no protection for client names.   You get to pick which 
> > solution to deploy, based on your willingness to distribute 
> keys and 
> > based on whether or not you care whether a DHCP client can count on 
> > retaining its name, once its name is registered.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 


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