Subject: [dhcwg] Trust model of Client FQDN option

From: Pekka Savola <[email-masked]>
Date: Tue, 3 Aug 2004 21:03:02 +0300 (EEST)

Hi,

(not subscribed..)

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.

The issue is that as the DNS server will be configured to trust the
DHCP server for these updates, how could the DHCP server ensure that
the Client is authorized to insert that FQDN -> IP mapping.  This is
basically deemed outside of the scope of the spec, without providing
the means in the spec to do that properly.

A suggestion is that the DHCP server includes policy information which
updates would be acceptable.  I do not think this addresses the real 
problem: if such policy is available, why does the client need to send 
the FQDN in the first place -- the DHCP server should just be 
configured to update the FQDN corresponding to a particular client to 
map to the IP address of that client; the client doesn't need to 
specify it if this will need to be included in the policy 
configuration in any case.  So, in this kind of scenario, you 
shouldn't actually need the Client FQDN option here, just the magic in 
the DHCP server to update the IP address of a particular client 
automatically.

Therefore, the client should probably be able to insert a TSIG or some
other signature which the DHCP server could use for updating; this
would authorize the update (in case TSIG validation succeeds) or not
without manually configured policy lists.

(A reason why DHCP server could update the FQDN to the DNS server
might be that the ISP wants to restrict access to the DNS updates to a
smaller number of hosts.)

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Aug 2004 15:19:05 -0700

> 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?   
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.

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.

So this is a well-understood problem, with well-understood and widely 
deployed solutions.   You can see an example implementation in the ISC 
DHCP client and server if you're curious, and as far as I know every 
commercial DHCP server also implements this, and I know of quite a few 
sites that use it in practice.  Indeed, it's been deployed at IETF 
meetings in the past (not sure if it's running this time).

---

From: Pekka Savola <[email-masked]>
Date: Wed, 4 Aug 2004 02:05:56 +0300 (EEST)

> 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.

> coming to IETF, people have occasionally raised the very same issue you 

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.

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 3 Aug 2004 20:42:26 -0400

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Pekka Savola
> Sent: Tuesday, August 03, 2004 7:06 PM
> To: Ted Lemon
> Cc: [email-masked]
> Subject: Re: [dhcwg] Trust model of Client FQDN option
> 
> 
> > > 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.
> > 
> 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.
> 
> authorization at all, just talks quite a bit about DHCP 
> authentication and different ways to eliminate DHCP spoofing.
>

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 3 Aug 2004 20:39:25 -0400

Also, it is generally viewed as a bad idea to mix both static and dynamic
DNS resource records in a zone. So, if you want to completely avoid the
problem, keep the zones which contain the administrative DNS information
(www., ftp., pop3., ...) separate from the (dynamic) client information.

- Bernie

> On Behalf Of Ted Lemon
> Sent: Tuesday, August 03, 2004 6:19 PM
> To: Pekka Savola
> Cc: [email-masked]

---

From: Mark Stapp <[email-masked]>
Date: Tue, 03 Aug 2004 18:06:18 -0700

how an administrator controls dns updates is not _really_ a dhcp protocol 
issue. there is no standardized way to express dns update policy, and, as a 
policy issue, it's not really an ietf issue at all, in my opinion. I can 
think of several possible ways that a dns administrator might configure his 
or her dns servers:

1. use a zone-wide TSIG key and allow any update to any name, trusting any 
updater who presents a valid TSIG key

2. provision a different key for each name; only allow an updater to update 
a name if it presents the 'right' key for that name

3. use zone-wide TSIG keys, but prohibit dns updates to some names, period

now (1) is a bit weak, though it is used, and (2) presents a significant 
key-distribution hurdle. (3) is frequently done in the field, and we have 
years of field experience with it in v4.

having a dhcp option that carries an fqdn does not give any client license 
to use the server as a dns update proxy. it also does not relieve dns 
administrators of the responsibility to establish some policy about 
updates. there are sites that don't allow _any_ updates from anyone - 
that's a valid policy too. for many other sites, however, having a dhcp 
server and then a dns server each have an opportunity to apply some policy 
about the names that can be updated is efficient and effective.

perhaps you'd like it if some drafts' security considerations sections 
said: "watch out, because some dhcp client might present 'www' in its FQDN 
option, and you might not want to let that update happen." that'd be fine, 
but that's about as far as it can go, because there is a wide range of 
update policies in place in the field.

-- Mark

---

From: Pekka Savola <[email-masked]>
Date: Wed, 4 Aug 2004 05:56:45 +0300 (EEST)

> The resolution draft still needs additional work for DHCPv6 - it currently

This has some, but relatively little, to do with "Resolution of DNS
Name Conflicts among DHCP Clients", because the main threat is that it
doesn't conflict with another *DHCP client* (though that's imaginable
as well) but a manual entry (or that it might not conflict at all, but
just be something like wwww.example.com (with one extra 'w').

In any case, I think this requires quite a bit more extensive
discussion (and appropriate pointers) in draft-ietf-dhc-fqdn-option
(which seems like the main draft of this bundle) especially from the
*security* perspective.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Aug 2004 20:46:34 -0700

> and different ways to eliminate DHCP spoofing.

The meat isn't missing.   It's just in the draft that defines how the 
server is supposed to do it.   There is a normative reference to that 
draft in the FQDN draft.   The FQDN draft defines the format of the 
FQDN option and what the bits in it mean.   The reason they're in two 
separate drafts is that the IESG asked us to split the draft describing 
how DHCP does DNS updates into three drafts - one to describe the DNS 
RRtype, one to describe the DHCP option, and one to describe their 
interaction.   Are you now asking that we merge the three drafts 
(actually, it's grown to five!) back into one?

As for your question about names that are _already_ in the DNS, this is 
addressed in the DNS name conflict resolution draft (and has been 
addressed in that draft for six years, and was addressed in the joint 
draft before the draft was split into three).   I also addressed it in 
the email to which you are replying.

I would like to encourage you to read these drafts, in their current 
versions, thoroughly.   If you have specific changes you would like to 
suggest, please suggest them.  Include the wording you would like 
changed, removed, or added.  Please make sure that your suggestions 
address the set of drafts, not just one specific draft.   For example, 
if you don't feel that the FQDN draft adequately clues the reader in to 
the fact that they need to read the conflict resolution draft, suggest 
the wording you would like us to add to address that problem.

Otherwise it's impossible to make forward progress - we either have to 
declare consensus without you, or not advance the drafts, and neither 
of these choices is desirable.

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 4 Aug 2004 13:17:37 -0400

Hi:

Ok, perhaps that title of the draft isn't the greatest, but see section
6.3.1:

6.3.1  Initial DHCID RR Query

   When a DHCP client or server intends to update an A RR, it performs a
   DNS query with QNAME of the target name and with QTYPE of DHCID.

   If the query returns NXDOMAIN, the updater can conclude that the name
   is not in use and proceeds to Section 6.3.2.

-> If the query returns NODATA, the updater can conclude that the target
-> name is in use, but that no DHCID RR is present.  This indicates that
-> some records have been configured by an administrator.  Whether the
-> updater proceeds with an update is a matter of local administrative
-> policy.

Now, admittedly doesn't address the situation where there is no existing
"www" name and a client comes along and requests to use that.

If you have a better name suggestion for the draft, please let me know.

- Bernie

> Sent: Tuesday, August 03, 2004 10:57 PM
> To: Bernie Volz
> Cc: [email-masked]; 'Ted Lemon'
> Subject: 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.
> 
> This has some, but relatively little, to do with "Resolution 
> of DNS Name Conflicts among DHCP Clients", because the main 
> threat is that it doesn't conflict with another *DHCP client* 
> (though that's imaginable as well) but a manual entry (or 
> that it might not conflict at all, but just be something like 
> wwww.example.com (with one extra 'w').
> 
> discussion (and appropriate pointers) in 
> draft-ietf-dhc-fqdn-option (which seems like the main draft 
> of this bundle) especially from the
> *security* perspective.
> 
> --

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Aug 2004 10:43:16 -0700

> -> updater proceeds with an update is a matter of local administrative

Hm, this is interesting.   As a point of information, the two 
implementations with which I am familiar do not give the administrator 
a knob to tweak here.  We just assume that if the name is in the DNS 
and doesn't have a DHCID (well, TXT) record, we shouldn't scribble on 
it.

I think a stronger statement here might be better:

Whether the updater proceeds with an update is a matter of local 
administrative policy.   DHCP servers MUST NOT proceed with the update 
unless explicitly configured to do so.

The draft should talk about these two issues in the security 
considerations section, and the FQDN drafts should mention in the 
security considerations section that these security considerations are 
addressed in the resolution draft.   I don't think we can make any 
requirements to address this, but the answers we came up with in 
response to Pekka's query could reasonably go into the security 
considerations section of one or all of the drafts:

1. If the DHCP server does updates, there is no way to prevent one 
client from getting a name after another client had it, but that 
client's lease expired.

2. If the DHCP server does updates, it will be possible for DHCP 
clients to request names that might have special meaning, like www or 
wwww.   This can be handled in one of two ways:
   a. Use a special zone for dynamic names, so that it doesn't
      matter that the client gets www.dyndns.bigcompany.org, or
   b. If the DHCP server provides this capability, set up a
      filter on the DHCP server that prevents certain names from
      being claimed by clients, even if they do not currently
      appear in the DNS.

3. If the DHCP server does updates, and is allowed to override names 
that do not have DHCID records, this can mean that a client will get a 
name that is already registered for some purpose in the DNS.   This 
behavior is required to be disabled by default, so it should not be a 
problem in practice, but we mention it here to raise awareness of the 
implications of configuring your DHCP server to allow it.

Hm, one other problem that occurs to me is that a client could send 
something like "www.students" in the fqdn option, and this could turn 
into "www.students.littlecollege.edu".   That is a vaguely 
official-looking name.   So any filtering that needs doing based on 
specific reserved names like "www" needs to be on the first label in 
the name, not on the entire name.

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 4 Aug 2004 14:18:41 -0400

And, we probably should add a 4th point ... If a DNS server allows dynamic
DNS updates, it is the final authority of what it allows to be added,
removed, or modified in a zone and should have properly configured policies
to prohibit operations that are not intended. Simply assuming that any
update from a trusted source (such as a DHCP server with a valid TSIG key)
should be performed is likely not acceptable.

- Bernie

> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Wednesday, August 04, 2004 1:43 PM
> To: Bernie Volz
> Cc: <[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Aug 2004 12:37:10 -0700

> should be performed is likely not acceptable.

I would expect this to be a rather controversial statement, and I think 
we should leave it out.   It could be equally legitimately argued that 
if you give some entity a key to update a zone, you are trusting that 
entity not to do anything inappropriate with the key, and that if you 
do  not trust that entity, you should not have given it such a key.

I'm not saying either position is correct - they are both valid.   So 
asserting one over the other seems like a recipe for delay.