Subject: [dhcwg] Restrictions of information flow in leasequery messages

From: Ralph Droms <[email-masked]>
Date: Tue, 06 Apr 2004 20:16:37 -0400

Ted Hardie:

Discuss:
This whole method has "invitation to mischief" printed in large, block 
letters across its
shirt.  After being told repeatedly that there is no restriction on the use 
cases for this
mechanism, this text:

         For this query, the requester supplies only an IP address in the
         DHCPLEASEQUERY message.  The DHCP server will return any
         information that it has on the most recent client to have been
         assigned that IP address.

sets off lots of alarm bells.  If I read this right, *any information* 
associated
with that IP address is returned?  If information used to construct a location
object is present (as in the geopriv dhcp-li draft), that would get returned?
That seems kind of excessive for an access concentrator, but very, very nice
for a black hat.  This whole section on Parameter Request List options:

         The Parameter Request List option (option 55) SHOULD be set to
         the options of interest to the requester.  The interesting
         options are likely to include the IP Address Lease Time option
         (option 51), the Relay Agent Information option (option 82) and
         possibly the Vendor class identifier option (option 60).  In the
         absence of a Parameter Request List option, the server SHOULD
         return the same options it would return for a DHCPREQUEST
         message which didn't contain a DHCPLEASEQUERY message, which
         includes those mandated by [RFC 2131, Section 4.3.1] as well as
         any options which the server was configured to always return to
         a client.

has no restrictions of any type on the return of any data.  Why is all
of this data being made available via this method?

It's too bad that SNMP is off the table here, as that would give you a 
realistic
way to limit data to specific queries and queriers.

Limiting the protocol to a very specific use that fits the
demonstrated need seems like it would make getting the security
mechanisms right easier; if this is meant to be truly general purpose,
it needs a general purpose mechanism that would give it the same level
of security as SNMP would for this same purpose.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 08 Apr 2004 16:52:00 -0400

At 08:16 PM 4/6/2004, Ralph Droms wrote:
>Ted Hardie:
>
>Discuss:
>This whole method has "invitation to mischief" printed in large, block letters across its
>shirt.  After being told repeatedly that there is no restriction on the use cases for this
>mechanism, this text:
>
>sets off lots of alarm bells.  If I read this right, *any information* associated

        I suppose because all of this data is already available on
        the wire (and sometimes broadcast) if you just watch it 
        go by.  Of course, you have to *be* on the wire to see it
        that way.

        What do the rest of you think about this issue?

        Cheers -- Kim

>It's too bad that SNMP is off the table here, as that would give you a realistic

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 9 Apr 2004 12:29:18 -0400

Kim:

I agree with you - this information is generally available.

Perhaps a solution is that a server always has the option of not
returning data it considers too sensitive - such as GEOPRIV information.
Perhaps something like the following should be added to the Security
Considerations:

   In some environments it may be appropriate to configure a DHCP server
   with option numbers that MUST not be returned in response to
   DHCPLEASEQUERY messages because these options are considered to
contain
   sensitive information.

I do think that once security options exists for relay to server
communication, if this was a concern at a site, the site should use
those options (and restrict who the server responds to for a
DHCPLEASEQUERY).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kim Kinnear
Sent: Thursday, April 08, 2004 4:52 PM
To: Ralph Droms; [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] Restrictions of information flow in leasequery
messages

At 08:16 PM 4/6/2004, Ralph Droms wrote:
>letters across its shirt.  After being told repeatedly that there is no

>restriction on the use cases for this mechanism, this text:
>
>associated with that IP address is returned?  If information used to 
>construct a location object is present (as in the geopriv dhcp-li 
>draft), that would get returned? That seems kind of excessive for an 
>access concentrator, but very, very nice for a black hat.  This whole 
>section on Parameter Request List options:
>

        Cheers -- Kim

>realistic way to limit data to specific queries and queriers.
>
>Limiting the protocol to a very specific use that fits the demonstrated

>need seems like it would make getting the security mechanisms right 
>easier; if this is meant to be truly general purpose, it needs a 
>general purpose mechanism that would give it the same level of security

>as SNMP would for this same purpose.
>
>

---

From: "Richard Barr Hibbs" <[email-masked]>
Date: Wed, 14 Apr 2004 10:47:35 -0700

comments in-line

--Barr

> From: Bernie Volz
> Sent: Friday, 09 April 2004 09:29
>
> Perhaps a solution is that a server always has
> the option of not returning data it considers
> too sensitive - such as GEOPRIV information.
>
...I'd suggest that the option of which information to
return be specifically named as a "local policy" issue -- I
still carry the bruises from the discussion about
provisioning servers with client location information, so am
just a bit sensitive to this one in particular.  As I've
been repeatedly told, in some legal jurisdictions physical
location information is required, to be available to
emergency responders and others according to statute or
ordinance.  One method for obtaining this information might
be to use the DHCPLEASEQUERY mechanism, so we need to be
specific, I think, that the data to be returned ought to be
in the realm of local administrative decisions.  In some
jurisdictions, location information would be considered
private or privileged information, while in others it may be
mandated to be publicly available.  Let's stay away from the
policy questions and declared this a local administrative
matter.

> Perhaps something like the following should be
> added to the Security Considerations:
>
>    In some environments it may be appropriate to
> configure a DHCP server with option numbers that
> MUST not be returned in response to DHCPLEASEQUERY
> messages because these options are considered to
> contain sensitive information.
>
...I like this wording....

> I do think that once security options exists for
> relay to server communication, if this was a
> concern at a site, the site should use those
> options (and restrict who the server responds to
> for a DHCPLEASEQUERY).
>
...you're almost suggesting that a more complete security
model be developed for DHCPv4, including Access Control
Lists for DHCPLEASEQUERY requests and responses.  While I
don't object, I think that we should keep in mind what we
might be calling for as a future requirement.