Re: [dhcwg] Trust model of Client FQDN option

[Pekka Savola <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg