RE: [dhcwg] Trust model of Client FQDN option

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